The future of coding in the age of AI

Picture a feature request you understand well. You describe it to an agent, let it inspect the repository, and come back to a working first draft. The satisfying part is obvious. So is the uncomfortable question: if it can do this much, what happens to the job?

I think that question deserves to be taken seriously. Learning to build software takes time. Watching a tool do something you worked hard to understand can be exciting and unsettling in the same afternoon.

I don't have a date for when coding jobs disappear, or a promise that they never will. What interests me is the work that's changing already, and what I would choose to get better at while it changes.

The first draft is becoming a different kind of work

For many familiar tasks, an agent can give you something concrete to inspect: an endpoint, a component, a test, or a proposed refactor. You can start arguing with an implementation much earlier.

That changes how a developer spends the day. There may be less time spent remembering a library's syntax and more time deciding whether a proposed abstraction belongs in the application. A feature that once seemed too tedious to explore may be worth trying.

I find that possibility appealing. There is plenty of useful software that never gets built because the first attempt costs more time than someone can spare.

But a working draft also creates obligations. Somebody has to understand the extra dependency, the new database query, and the error that only appears when the request is retried. The draft has joined a system that other people depend on.

In its March 2026 analysis of engineering workflows, DORA describes engineers spending some of the time saved on code generation on auditing and verification. Its research also associates greater AI adoption with both higher delivery throughput and more delivery instability. That doesn't settle the value of AI for every team. It does give us a reason to look beyond how quickly the first version appeared.

Understanding the problem still changes the result

Take a booking system. Generating a calendar is one part of the work. Deciding what should happen when two people book the last slot at the same time is another. So is figuring out what a cancellation means after a payment has already settled.

An agent can help explore those questions and implement the answers. Someone still has to notice which questions matter in this particular system, find the people who can answer them, and check that the decisions hold together.

That is engineering work I want to keep getting better at. It draws on understanding the domain, reading the existing code, and knowing where a seemingly small change can travel.

Anthropic's June 2026 study of Claude Code sessions found an association between task expertise and successful sessions. People typically made more of the planning decisions, while the agent made more of the execution decisions. The study measured signals inside those sessions, not whether the resulting software succeeded in the world. I read it as useful evidence about collaboration, rather than a guarantee about anyone's career.

It also complicates an easy reassurance for developers. Domain expertise belongs to plenty of people who don't write software for a living. If those people can increasingly build their own tools, engineers will need to be clear about the additional value they bring.

The team has to make room for the change

Imagine a team where three people can now produce substantial changes in a morning. If one person still has to review all of them on Friday, the queue has simply moved.

The same applies to an unreliable test environment, a staging server nobody understands, or a requirement that changes after implementation. Faster code generation can make those problems harder to ignore.

Kiro's account of teams reorganising their work around agents puts attention on shared context, explicit requirements, and checks that agents can run during development. Those are ideas I would take seriously regardless of the tool a team uses. The reported productivity figures come from particular teams and projects, so I wouldn't turn them into a target for every engineering organisation.

The useful question is what work we can make easier to finish. That might mean documenting an awkward service boundary, fixing a flaky test, or keeping changes small enough that another person can review them properly.

There is a measurement problem here too. In February 2026, METR explained why it was changing a developer productivity study: some developers didn't want to participate in work without AI, and some withheld tasks for the same reason. The researchers said those selection effects made their new estimates an unreliable guide to the overall effect. A productivity number needs its context, even when it agrees with what we hoped to hear.

For my own work, I'd rather track the time and effort needed to get a useful change accepted and running. That includes review, revisions, and whatever breaks afterwards.

Learning needs a little more intention

One concern I have is what happens to the small tasks through which people learn a codebase.

A modest bug can teach you how a request moves through the application, where state lives, and why an old test looks strange. If an agent completes it before you investigate, you get the patch without necessarily getting that understanding.

I don't think the answer is to make learning artificially miserable. An agent can explain unfamiliar code, suggest experiments, and help you get past an error that would otherwise consume an afternoon. That's useful.

I do think it helps to leave some room for your own reasoning. Before accepting a fix, predict what it will change. Trace the relevant path through the code. Change an input and see whether the result matches your expectation. Ask why a simpler alternative would fail, then check the explanation.

For someone starting out, being able to show a working application remains valuable. Being able to explain a decision, reproduce a failure, and make a change without losing your way adds something different. A conversation about those details tells me more than a list of tools.

Teams will need to take that seriously too. If agents absorb more of the work traditionally handed to newcomers, someone has to design a useful path from being new to being trusted with a system. That won't happen automatically.

I expect the work to get broader

My expectation is that more engineers will move across parts of the stack that used to feel expensive to enter. A frontend developer may be able to investigate a backend problem sooner. A backend developer may have a better starting point for building the interface a small tool needs.

That doesn't mean all specialisation disappears. Being able to produce a plausible change in an unfamiliar area is different from understanding its failure modes. There will still be decisions where I want someone who knows the area deeply.

It does make me interested in engineers who can follow a problem across boundaries. Someone who can move from a user report to a browser trace, through an API, and into a slow query has a useful view of the system. AI can assist along that route, but the route still has to make sense.

I also expect some teams to ask fewer people to cover more ground. That could create opportunities for small teams and put pressure on hiring elsewhere. I don't know how those effects will balance. It would be too easy to turn a personal preference for these tools into a confident prediction about the labour market.

What I want to keep building

I want to become better at framing a problem, making a change that fits the existing system, and recognising when the evidence isn't good enough to ship. I also want to stay close enough to the code to understand what I'm asking an agent to do.

That means practising with the tools, reading their output carefully, and continuing to build things that have to work beyond a demo. It means keeping the parts of software development that make me curious, including the occasional afternoon spent figuring out an awkward bug.

I expect to type less of some implementations. I still want to understand why they work, where they might fail, and what the person using the software actually needed.

That's the kind of engineer I'm trying to be as the tools change.

I've described the practical side in how I build with AI agents, including a task brief you can adapt to your own setup.