I used to type most of my code. Now I read it.
An AI coding tool writes the first version. I explain what we need, review what it built, and decide whether it goes live. That shift happened within nineteen months of starting at beWirken, a German nonprofit working on education.
The rest of the job stayed. The website, learning platform and servers still need to work. Someone still has to decide who can see which data. Generating the code doesn't settle any of that.
This is where I think IT work is heading: more responsibility for the whole system, even as typing becomes a smaller part of the day.
In this article
The tools are already here
JetBrains surveyed more than 15,000 professional developers between May and July 2026. Ninety percent reported using coding agents at least weekly.[1] That's widespread use among the people surveyed. It doesn't tell us whether the resulting software is better.
That distinction gets lost whenever a working demo becomes a prediction that nobody will need developers. A demo usually shows what happens when everything goes right. A real service gets old data, missing permissions and someone clicking the button twice.
Those are the problems I still have to think through, however the code gets written.
Who gets to learn the job?
The part that worries me is the first rung of the career ladder.
Stanford's August 2026 analysis found a 19 percent relative employment gap for 22-to-25-year-olds in jobs with many tasks AI can perform, compared with the path of peers in jobs less exposed to AI. The data ran through June 2026; the gap appeared mainly in hiring. This is an observed pattern, not proof that AI caused it.[2]
Small fixes and routine coding are also how people learn. Hand all of those tasks to agents, then demand experienced engineers, and you've created a fairly obvious problem: where should the experience come from?
Teams need to give newcomers real work, feedback and increasing responsibility. “Review what the AI did” is a tough first assignment if you've never learned what good looks like.
Five kinds of work
I split my job into five responsibilities. These are my labels for work people already do. One person may cover several; I cover all five in a small organization.
01 / The builder
The builder turns a request into something people can use.
My work starts with specifics: which data may leave the server, which tools we already use, and what the person in the school office should see. An agent can implement that. It cannot rescue a requirement I never thought through.
Knowing what “finished” means matters more in my week than remembering syntax. Can the right person use the tool? Can the wrong person access it? Does it fit the way the organization actually works?
That's also useful for people commissioning software. A clear description of the problem gives a developer far more to work with than a list of fashionable features.
02 / The maintainer
Someone has to understand the software six months after the exciting demo.
For me, that means a WordPress shop, a learning platform and several applications sharing infrastructure. Changing one part can break another. An agent can suggest an update; knowing what depends on it is the hard part.
The useful work is making those dependencies visible: what must keep working, how to test it, and how to recover if the change fails. That knowledge needs to survive the person who happens to remember it.
If you own the budget, ask how the software will be kept running after launch. The first version is only the start of the bill.
03 / The scanner
The scanner checks whether a result deserves trust. Testers, security people and researchers already do this.
Sonar's January 2026 survey found that 96 percent of respondents didn't fully trust AI-generated code to be correct, while only 48 percent said they always checked it before adding it to their code. These are self-reported habits.[3] Still, that's quite a gap between suspicion and action.
I want the attention to follow the consequences. A color change needs a quick check. Changes to logins, payments or personal data need someone testing what happens when things go wrong.
A confident answer is easy to get. Establishing that it is right takes work.
04 / The idea-shaper
When prototypes get easier to build, people outside development can show what they mean. That's useful: the person doing the work often knows exactly where the process falls apart.
The harder questions remain. Who needs this? What must it never do? Who will own it? Would fixing the process make the new app unnecessary?
Being able to generate a tool makes that last question awkward. I'd still ask it before giving an organization another system to look after.
05 / The operator
If a teacher cannot log in on a training morning, someone has to get the service working again. They also need to decide what to stop and whom to inform.
I run the servers. Agents can help inspect logs, suggest fixes and apply updates. But permission to investigate a problem is different from permission to change a live service. Those boundaries need to be set before an incident.
Who can stop the automation? Where is the backup? Can we restore it? These questions are less exciting than the demo. They're much more interesting during an outage.
What I'd focus on
I'd build skill around a part of the work I can judge: why a system fails, what a department needs, or whether a change is safe to release. Then I'd learn enough of the neighboring work to take a useful idea further.
I'd also measure whether the tools help. In METR's randomized study, 16 experienced open-source developers took 19 percent longer in projects they already knew with early-2025 AI tools, despite thinking they were faster.[4] Its February 2026 follow-up couldn't give a reliable estimate for newer tools because participation was skewed and time tracking unreliable.[5] The result depends on the setting. My own feeling of speed is a poor stopwatch.
For now, my priorities are simple:
- Define finished. Write the outcome and checks before asking an agent to build.
- Stay able to fix it. Understand the result, the backups and how to stop it.
- Talk to the people using it. Find the problem before choosing the tool.
- Let people learn. Give newcomers practice, feedback and real responsibility.
For someone outside IT, I'd ask one question before adopting the next impressive tool: who understands it well enough to take responsibility when it fails? A convincing answer should include a person and a plan.
Where today's IT jobs fit — expand the career table
| Today's job | Where the work is heading | Experience that carries forward |
|---|---|---|
| Frontend, backend, or full-stack developer | Builder; increasingly scanner of generated code | Turning requirements into behavior, integrating components, debugging |
| Integration or automation engineer | Builder, with operator responsibilities | Knowing what happens when a workflow fails |
| Legacy developer, database administrator, ERP specialist | Maintainer; often also operator | Dependencies, history, and the consequences of a change |
| Systems or cloud administrator | Operator or maintainer; builder where automation dominates | Access, infrastructure, upgrades, recovery |
| QA analyst or test automation engineer | Scanner; builder of evaluation harnesses | Test design, failure patterns, release risk |
| Security analyst or penetration tester | Scanner; operator during incidents | Finding weaknesses, separating signal from noise |
| Product manager, business analyst, UX researcher | Idea-shaper who now prototypes | Needs, assumptions, choosing outcomes |
| Solutions architect or technical consultant | Idea-shaper and builder | Connecting business constraints with technical choices |
| IT or application support specialist | Operator; paths into scanner and idea-shaper | Diagnosing real problems, spotting recurring friction |
| DevOps, platform, SRE, MLOps engineer | Operator, builder, and maintainer, now supervising agents | Automation, deployment, reliability, lifecycle |
| Data engineer or data analyst | Engineer: builder and maintainer. Analyst: scanner and idea-shaper | Dependable data flows; evidence and its meaning |
Sources
- JetBrains, AI coding agent adoption 2026, August 2026. ↩
- Brynjolfsson, Chandar, and Chen, Canaries in the Coal Mine, August 2026 update, Stanford Digital Economy Lab, 12 August 2026. ↩
- Sonar, State of Code 2026: the verification gap, 8 January 2026. ↩
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 10 July 2025. ↩
- METR, We are Changing our Developer Productivity Experiment Design, 24 February 2026. ↩