This is a follow-up of an article I wrote in 2024.

What Has Not Changed

AI still excels at automating the repetitive and time-consuming. Code generation, test scaffolding, documentation, boilerplate mapping — all of this is handled faster and more reliably by AI-assisted tools than by hand. That frees experienced developers to focus on architecture, business alignment, and system-level thinking. The Microsoft and GitHub Copilot productivity study I referenced in 2024 has since been followed by several others, and the consensus is consistent: productivity gains are real, measurable, and weighted toward less experienced developers in terms of raw output volume.

The co-pilot analogy still holds. You remain the pilot. The AI handles execution detail. The moment you hand over the controls, the system drifts.

What Has Changed

From Autocomplete to Autonomous Agents

The tools are more powerful and the stakes are higher. In 2024, the dominant use case was inline autocomplete — accepting or rejecting a suggestion line by line. By 2025, autonomous agents that open terminals, edit dozens of files, run test suites, and submit pull requests are in daily use across engineering teams. The productivity ceiling has risen dramatically. So has the risk surface.

The Learning Paradigm: Accelerators vs. Blockers

The learning concern is no longer theoretical. When I wrote the original article, I noted that AI could serve as a learning accelerator for junior developers. That is still true if used intentionally. What has become clearer — and what I did not emphasise enough in 2024 — is that AI can just as easily become a learning blocker. A junior developer who uses AI to generate a working solution without understanding it has closed a ticket, not built a skill. The process of breaking down and truly comprehending the AI's output matters enormously over a three to five year career horizon. I have seen it play out in both directions on teams I have worked with directly.

Whether skipping that process is acceptable depends entirely on your career stage and your willingness to invest the time to understand the output. For a senior engineer with strong mental models, skipping the syntax lookup is pure efficiency. For a junior engineer still forming those models, skipping the debugging process is trading short-term velocity for long-term competence.

A rule I've started applying with juniors on my own team: after using an agent to build a feature, they need to be able to walk through the core logic without the tool open — not perfectly, but well enough to explain why it works, not just that it does. In code review, that shows up as a different question than the one we used to ask. Instead of checking whether the pull request works, I ask why it was built this way instead of another way. If the answer is "that's what the agent gave me," the ticket isn't actually done.

The Stack Overflow analogy I used in 2024 — that good developers don't blindly copy without understanding — remains the right mental model. But I would extend it now. Stack Overflow gave you a targeted answer to a specific question you had already diagnosed. AI gives you a complete solution to a problem you may not have fully understood yet. That distinction changes the discipline required. The developer who googled a solution in 2018 had already formed a hypothesis, read error messages, and narrowed the problem space before finding the answer. The developer who prompts an AI in 2025/26 can skip all of that and still get working code.

The Disruption of the Mid-Level Engineer

The role of mid-level developers has shifted in ways we did not anticipate. The 2024 article focused on seniors and juniors. The middle tier has been most structurally disrupted. As junior developers generate more code faster, mid-level engineers are increasingly being pulled into full-time code review roles rather than active feature development. That is a problem for their growth that the industry is only beginning to reckon with.

The Return of Structured Specifications

Requirements and specifications are now the primary leverage point in modern engineering. To understand why, we have to look at how we got here. In the pre-Agile era, software was built using heavy, plan-driven methodologies like Waterfall. Teams spent months drafting massive, rigid "Software Requirements Specifications" (SRS) documents before a single line of code was written.

When the Agile Manifesto emerged in 2001, it fundamentally shifted the industry. Agile prioritised "working software over comprehensive documentation," replacing formal, structured requirements with lightweight, adaptable user stories and continuous iteration. While this made teams incredibly flexible, it often led to a decline in disciplined, rigorous technical documentation.

Now, the pendulum is swinging back. With the rise of generative AI, structured specifications are making a crucial comeback — but with a completely new purpose. We are no longer writing documentation just for human sign-offs; we are writing it as a blueprint for machine execution.

If your technical specification is ambiguous, AI will generate functional garbage at speed. If it is precise, AI can scaffold a well-structured system in hours. The ability to write clear, logically complete technical requirements has become one of the most valuable engineering skills of this decade — far more so than it was in 2024. In an AI-augmented workflow, the developer's primary role shifts from being a manual coder to being a precise systems architect.

There's a second-order risk in this shift worth naming. If every team is prompting broadly similar models with similarly generic requirements, the software that comes out tends toward the same defaults. A team that treats AI as a way to skip writing a precise, opinionated specification isn't just risking bad output — they're risking indistinguishable output, the kind that solves the problem exactly the way every other team's AI-assisted build already does. The advantage was never in producing code faster. It's in the specific, sometimes unusual decisions a real specification still has to make, the ones a generic prompt won't arrive at on its own.

Conclusion

The pilot and co-pilot analogy still captures it best, though the shape of the job inside that analogy keeps moving. What has changed is the co-pilot's capability. In 2024 it was a helpful assistant. In 2025/26 it can fly large sections of the route autonomously — which means less of the job is manual flying and more of it is deciding whether the autopilot made the right call. That makes the pilot's judgement — about when to engage, when to override, and when to take manual control — more consequential than ever, not less.

AI is not here to replace you. But it will expose, very quickly, whether you are actually engineering or just directing traffic.