Every Generation of Developers Inherits a Higher Floor
Something significant has happened in software development. Not overnight, and not for the first time. But this one is moving faster than any previous shift in the industry.
We have moved up a level of abstraction. And if you lead teams that build products, whether you write code yourself or not, you need to understand what that means, both the opportunities and the failure modes it creates.
This pattern is not unique to software. Every knowledge profession is experiencing it. Lawyers are using AI to draft contracts. Analysts are using it to build financial models. Designers are using it to generate options. The abstraction is rising everywhere. But software is where the pattern is clearest and the consequences most visible, because software has been through this exact cycle before. Multiple times.
The History of Rising Abstraction
The history of software development is a history of rising abstraction. Each generation builds on a platform the previous one created, and the unit of work gets bigger each time.
1950s: Machine code and assembly. Every instruction written by hand. Memory addresses managed manually. You thought in bits and registers. Unit of work: instruction.
1970s: High-level languages. C, Fortran, Cobol. You described logic, not hardware. The compiler handled the translation. An enormous productivity leap. Unit of work: function.
1990s: Object-oriented languages and frameworks. Reusable components, design patterns, libraries. You stopped writing everything from scratch. You assembled systems. Unit of work: component.
2010s: Cloud, APIs, and platform services. Entire capabilities became API calls. Auth, payments, storage, messaging. You integrated, not built. Unit of work: service.
Now: AI-assisted development. You describe the outcome. The AI writes the code. The unit of thought is shifting from implementation to intent. Unit of work: intent.
Each shift followed the same pattern. More people could participate. Experienced practitioners got dramatically more productive. And something got hidden underneath your feet that you used to have to understand yourself.
How AI Is Changing the Work Right Now
Tools like GitHub Copilot, Claude Code, and Cursor are not sophisticated autocomplete. They write whole functions, refactor existing code, explain unfamiliar codebases, and catch obvious bugs before the developer notices them.
The productivity gains are real. I see them every week across the teams I work with. Prototypes that took weeks now take hours. Junior developers are producing at something close to senior speed. Seniors are producing more than they ever did.
Speed of exploration is the biggest change. Teams can test ten directions before committing to one. That used to be expensive. Now it is not. The constraint has shifted from "can we build it" to "should we build it," which is a much more interesting question to be spending your time on. And a much harder one.
What the Productivity Gains Are Hiding
Here is what I also see. Engineers are merging code they do not fully understand. The code looks right, it compiles, the tests pass. But nobody has really read it.
Code review culture is quietly weakening at exactly the moment it should be getting stronger. When generation becomes easy, review becomes the critical skill. Most teams have not made that adjustment yet.
There is also a more subtle risk in the analysis and requirements phase. AI turns vague briefs into structured user stories fast. The output looks complete. It is not always correct. It does not know your business. It does not know what your stakeholders actually mean when they say "flexible reporting." Teams are shipping AI-generated requirements nobody has truly interrogated. Narayanan and Kapoor make this point forcefully in AI Snake Oil: AI systems are routinely deployed with misplaced confidence, in contexts where they lack the situational understanding to perform reliably.1 Requirements generation is exactly that kind of context.
Complexity Does Not Disappear. It Moves.
Every abstraction layer hides complexity. That is the point. But hidden complexity does not disappear. It shifts somewhere you are less likely to look, until something goes wrong and you need to look there urgently.
Fred Brooks made this argument in his 1986 essay No Silver Bullet. He distinguished between essential complexity (the irreducible difficulty of the problem itself) and accidental complexity (the difficulty created by our tools and processes).2 AI removes accidental complexity brilliantly. It handles the boilerplate, the syntax, the wiring. But essential complexity, understanding what to build, why it matters, and how it interacts with everything else, remains untouched. AI is not the silver bullet. It is the best tool we have ever had for accidental complexity, and it changes nothing about the essential kind.
This is a Cynefin insight. AI makes Complex problems look Clear. The generated code compiles, the tests pass, the output looks professional. But the underlying problem, understanding your users, navigating stakeholder politics, making trade-offs between competing priorities, is still firmly in the Complex domain. Teams that treat AI output as if the problem has been solved, rather than as a starting point for human judgment, are treating Complex work as Clear. And as the Cynefin framework shows, that's where catastrophic failures come from.
The engineers I watch most carefully are those starting their careers now who have never had to fight with raw code. They may never develop a feel for what the machine is actually doing. That gap matters rarely. But when it matters, it matters a great deal. Debugging a production incident at 3am is not the moment to discover your team cannot go one level below the abstraction.
Test coverage is another place where the numbers look good but the picture is incomplete. AI generates test cases faster than any human ever did. Coverage metrics are rising across every team that adopts these tools. But coverage is not confidence. A test suite full of AI-generated tests can pass completely and still miss the thing that actually matters. Someone has to check that the tests are testing the right things.
The Skills That Matter Most Now
The skill premium has shifted, and it has shifted fast.
From syntax mastery to architecture judgment. Knowing how to write the code matters less. Knowing what should be built, and how it fits together, matters more.
From knowing the API to knowing when the AI is wrong. The AI will confidently generate plausible code that is subtly incorrect. Catching that requires understanding, not just pattern-matching.
From writing every line to reading and owning what is generated. Code ownership cannot be delegated to a tool. If nobody on your team can explain what the code does, nobody on your team owns it.
From writing boilerplate to framing the problem precisely. Writing a good prompt is not a soft skill. It requires a clear mental model of the problem, an understanding of constraints, and the judgment to evaluate whether the output is actually right. That is engineering. It just looks different from the outside.
From deep specialisation to breadth across domains. AI handles depth well. Humans need to steer across domains: business context, technical architecture, user experience, data integrity.
The engineers who thrive are using AI to think faster. Not instead of thinking.
What Engineering Leaders Need to Do Differently
Raise your standards. For requirements, for code review, for test quality. The bar should go up, not down, precisely because the tools are so capable. The ease of generation is not a reason to review less carefully. It is a reason to review more carefully.
Invest in depth alongside speed. Make sure your teams can still go one level below the abstraction when they need to. Run sessions where engineers have to explain what their AI-generated code actually does. Not because AI is untrustworthy, but because ownership of the codebase cannot be delegated to a tool.
Schedule deliberate retrospectives. AI-assisted incident response wraps problems up too neatly. Someone has to ask the awkward questions about what actually went wrong and why. Do not let the machine do all the sense-making. This is the PDCA cycle in action: plan, do, check, act. The "check" step is where human judgment is irreplaceable.
Think carefully about knowledge transfer. Junior developers learning primarily through AI-generated code are not building the same mental models that senior developers built over years of reading and writing code from scratch. That gap will show up eventually. Plan for it.
Apply an empirical approach to AI tool adoption. Try small things. Measure what actually happens, not what you hoped would happen. Build in feedback loops so you can change course. The organisations getting the most from AI are the ones treating it empirically, not the ones going all-in based on conference keynotes.
The Honest Picture
This is not AI replacing software engineers. It is AI changing what software engineering means.
The transformation is real, and it is mostly positive. But it comes with new failure modes that most organisations are not managing carefully enough. Velocity is up. Complexity is up faster. The bottleneck has moved from writing code to understanding what you have built.
The question for engineering leaders is not "how do we adopt AI tools faster?" It is "what do we need to protect as we do?"
The teams that get this right will be fast and rigorous. The teams that only get the first part will be fast until they are not.
Related reading:
- The Best AI Strategy Is 200 Years Old - why every technology shift follows the same pattern
- Humans in the Loop Is Not a Checkbox - where AI should lead and where humans must
- MVP Thinking in the Age of AI - what happens when building is cheap but learning isn't
- The PDCA Cycle - the learning loop that applies to every prompt
References
1: Arvind Narayanan and Sayash Kapoor, AI Snake Oil: What Artificial Intelligence Can Do, What It Can't, and How to Tell the Difference, Princeton University Press, 2024.
2: Frederick P. Brooks Jr., "No Silver Bullet: Essence and Accident in Software Engineering," Proceedings of the IFIP Tenth World Computing Conference, 1986.
Alun Davies-Baker is an agile coach, trainer, and the founder of Altogether Agile. He works with software and product teams across pharmaceuticals, finance, education, and the public sector, helping them navigate complexity using empirical approaches grounded in Business Agility.