AI and the Future of the Engineering Profession
If a machine can write most of the code, what's the engineer's value then? Here's the shift from producing code to building systems: what AI already takes over, why architectural thinking and verification get more expensive, what happens to junior and senior roles, and why accountability for what ships still sits with a human.
Introduction: AI is changing not the tools, but the profession itself
It's easy to mistake AI coding for another turn in the long history of developer tooling: a new framework, a new IDE, another plugin that gets forgotten in a couple of years. The difference is that AI can take over a substantial share of the technical work itself, not just speed up how that work gets done the same way it always has. So the changes here don't touch a set of individual skills that go stale and get swapped for new ones. They touch the underlying structure of what counts as an engineer's job in the first place.
Which raises the question this whole piece is built around: if a machine can write a significant share of the code, where does the engineer's value actually sit? The answer doesn't come down to lines written per day. It comes down to framing the problem, architecture, working with constraints, verifying the result, and taking responsibility for it. What follows: what AI already takes off an engineer's plate, what gets more valuable as code gets cheaper, how the junior and senior roles shift, what happens to team size, and what stays constant no matter how far the automation goes.
From writing code to solving engineering problems
For a long time, code was the primary, most visible artifact of an engineer's intellectual work. Code is what got checked in interviews, code volume and complexity served as a proxy for skill level, and lines in a repository were the thing you could actually point to as the result of your work. That wasn't an accident: before AI tooling, producing syntactically correct code genuinely was the bottleneck every engineering idea had to pass through on its way from concept to a working system.
AI is gradually separating the engineering problem from the direct production of code, and as that separation happens, elements that always mattered but stayed less visible next to the act of writing the program itself move to the front: understanding requirements, decomposing a problem into solvable pieces, choosing an architecture, modeling data, explicitly naming trade-offs between competing approaches, working with constraints nobody wrote down, and verifying that the result actually solves the original problem. None of this is new. What's new is how much more each of these elements is worth as writing the code itself gets cheaper.
The scale of the speedup here isn't abstract. In a controlled 2022 study, GitHub had developers with access to Copilot implement an HTTP server in JavaScript, and they finished 55.8% faster than the control group. That doesn't mean engineering work overall sped up by the same amount: the task itself was narrow and well-specified, exactly the kind of work that automates fastest. But the number gets the direction right: wherever a task is formalized and easy to check, the speed of producing code doesn't go up by a few percent, it multiplies.
Code gets cheap, engineering decisions get expensive
With AI, the cost of producing code drops, and it drops fast and visibly, not gradually by a few percent a year the way earlier tooling improvements played out. But that doesn't automatically mean the cost of building a product drops too, because most of the real complexity isn't in syntax, it's in picking the right solution.
There's an old principle from an adjacent field that carries over here almost unchanged: Tesler's Law, named after Larry Tesler, an engineer at Xerox PARC and later Apple, holds that every system has an irreducible minimum of complexity, which can be moved around but never eliminated. Applied to AI coding, that means cheaper code doesn't make a product's underlying complexity cheaper too. It just moves that complexity out of the syntax people used to type by hand and into the decisions about what to build and how, which are what actually create or prevent that complexity at the architectural level.
It's worth being explicit about the difference between "get working code" and "get the right system." AI can produce a working implementation fast, often in seconds where a person would've needed an hour. But the engineer still owns whether the result matches business requirements, whether it's secure, how it performs under real load, whether it stays maintainable months later, and what the long-term consequences of a given architectural choice turn out to be. I laid out this thesis in more depth in AI for developers: writing code is getting cheaper and will keep getting cheaper, while understanding what actually needs to be built, and verifying that what got built is correct, stays the bottleneck even with perfectly capable AI tools.
The engineer as an architect of context
Context becomes a new professional resource in a literal sense. AI can only produce a solution based on the information it's given, so the ability to correctly frame a task, its constraints, its requirements, and its quality bar turns into a standalone engineering skill, not a side step before the "real" programming starts.
Surface-level prompting isn't enough here. What matters more is understanding the system well enough to know exactly what information the model needs, which assumptions it can't be allowed to make on its own, and which parts of a solution have to stay under direct human control no matter how confidently the model offers to handle them itself.
Programming keeps moving to a higher level of abstraction
There's a clear historical line behind this shift. The move from assembly to high-level languages didn't remove the programmer's job, it removed the need to hold processor registers in your head to solve an ordinary application problem. The move from writing your own data structures by hand to using standard libraries didn't remove the job either, it shifted the value from being able to write a good search tree to being able to pick the right ready-made structure for the task. Every one of these transitions didn't shrink the number of developers, it changed what counted as their work.
AI continues the same process, it just pushes the level of abstraction higher still, and does it noticeably faster than earlier transitions did. A new development loop is taking shape: a person states intent and constraints, AI produces an implementation, the engineer verifies it, the system runs tests, the person adjusts direction, and the loop repeats. What matters now is managing that loop as a whole, not manually writing out every element inside it.
Why knowing how to program still gets more important
There's a paradox here that looks like a contradiction at first glance but isn't one. The more code AI writes, the less practical value there is in memorizing a specific language's syntax by rote, and at the same time the higher the value of genuinely understanding how programming works underneath it all.
Without understanding algorithms, architecture, networking, databases, concurrency, operating systems, and general engineering principles, an engineer is physically unable to properly judge what AI hands back. They'll still be able to generate a lot of code through someone else's hands, but they won't be able to tell whether that code is actually good, whether it's secure, whether it scales, or whether it's hiding a problem that only shows up under real load six months after launch.
The new skill: verifying AI's work
Verification deserves its own emphasis. AI can produce code that looks convincing, reads smoothly, and appears at first glance to solve the stated problem, while still containing logic errors, wrong assumptions about how the system behaves, and problems hidden behind an outwardly correct structure. The ability to critically examine that output stops being a nice-to-have and becomes part of the core engineering skill set.
The role of tests, static analysis, observability, benchmarks, code review, and architectural checks isn't shrinking here, it's growing. AI doesn't remove engineering oversight, it makes that oversight matter more, because the volume of code that needs checking grows faster than the number of people available to check it.
The changing role of code review
If a substantial share of a project's code comes from AI, the traditional review model of reading every line of a diff top to bottom becomes a weaker fit: it's good at catching typos and local mismatches, but it doesn't scale well against the volume an agent can produce in a single working cycle. I covered the mechanics of AI review itself in a separate piece on AI code review, including how to automate that first layer of checking.
Review's focus shifts toward architectural decisions, correctness against the original requirements, security, the boundaries between components, error handling, performance, and long-term maintainability. Review gradually turns into a check not so much of the code as text, as of the decision behind it: whether the right approach got picked, not just whether it got implemented correctly line by line.
What happens to junior developers
This is probably the most sensitive question in the whole piece, because it touches specific people at the earliest, most vulnerable stage of a career, not an abstract industry as a whole. AI automates, with particular force, exactly the tasks that used to fall to entry-level developers: routine, well-specified, easily checked pieces of work done under a senior's supervision. That genuinely narrows the classic path into the profession through small tickets done under watch.
A junior can no longer build a career purely on doing small, isolated tasks, because those are exactly the tasks an agent now does faster and cheaper. But the junior level disappearing entirely isn't an inevitable outcome: what changes is how learning and experience get acquired, not the fact that they're still needed, and AI can just as easily become a tool for accelerated learning as a tool for replacement.
Worth naming separately: the risk of pseudo-competence. A developer can quickly get working solutions through an agent without genuinely understanding why those solutions work, and rack up months of tenure that never actually turns into depth of understanding.
How the senior engineer changes
AI potentially increases a strong engineer's leverage: an experienced developer can explore more options in parallel, spin up prototypes faster, and get feedback on a hypothesis faster than before.
Responsibility grows right alongside that. If the speed of producing code goes up, architecture-level mistakes can scale up faster too: a bad decision made at the start now propagates through the system faster, because implementing that decision takes less time. So the quality of the decisions made matters more than an individual's raw coding speed, not the other way around.
Small teams get more room to operate
Automating a large share of routine implementation work cuts the number of hands needed for a lot of product types. This is a real shift in how development gets organized, not just a local speedup of individual tasks inside the same old team structure.
There's a plausible, already-visible shift toward small teams with a high degree of technical autonomy: one engineer, or a small group, can now cover a volume of work that would've taken a much bigger team just a few years ago. I go into how this actually plays out in practice, including my own failures and working solutions, in the piece on how I build AI products solo, including the real trade-offs that come with solo speed and the lack of a second opinion a team usually provides.
But productivity isn't the same as how much code gets generated
Here's a critical caveat that's easy to trip over with a shallow read of the topic. A rise in the volume of code produced can't automatically be counted as a rise in productivity. AI can just as easily speed up building unnecessary functionality, add to technical debt, and make a system more complex as it can speed up building something genuinely useful, the volume by itself says nothing about which direction it was spent in.
Value comes down not to commit count or lines of code, but to how fast a team or an individual engineer delivers the actual needed outcome at an acceptable level of risk and complexity. "How much code got produced" measures activity, not results, and mixing the two up is a reliable way to optimize the wrong number.
Which skills become especially valuable
Systems thinking. The ability to see how a system's components interact and to predict the consequences a local decision has in some other, not-obviously-connected part of it.
Architectural thinking. Knowing how to pick a system structure that actually fits the task, and understanding the trade-offs between different structural options rather than defaulting to a template.
A solid computer science foundation. Algorithms, data structures, networking, databases, operating systems, concurrency, and distributed systems: the layer of knowledge without which it's impossible to properly judge a solution AI proposes.
Working with uncertainty. The ability to act and make decisions where requirements are incomplete, contradictory, or still changing, rather than waiting for a clarity that may never arrive.
Verification. Knowing how to prove to yourself and your team that a solution AI produced is actually correct.
Communication. The ability to turn vague, imprecisely stated requirements into precise technical tasks, and to align on decisions with everyone else on a project, including people who never read the code directly.
What an engineer's workday might look like in the future
Rather than a specific scenario, it's more useful to conceptually show the shift in how time gets spent during a workday: less manual implementation, more framing of tasks, analyzing an existing system, working with several parallel AI agents, checking results, and deciding what happens next.
In this picture, the engineer becomes something closer to an operator of a complex development loop than the author of every individual line. AI acts as one of the active participants in that loop, not just an advanced autocomplete tool. I covered a similar shift in how the workday and attention get organized around agentic work in AI coding assistants: setup, task framing, and reviewing an agent's output take up the space that used to belong to typing out code directly. The same logic applies to how a codebase itself gets organized: building project structure so it's easy to work with for an agent as well as a human is covered in architecture for AI-driven development.
AI doesn't remove accountability
This section matters for the balance of the whole piece. Even if a specific piece of code or an architectural proposal came from AI, accountability for that system shipping to production in that shape still sits with the team and the organization, not with the tool they used.
The higher the cost of a mistake, the fewer real options there are to fully delegate a decision to AI: in security, privacy, compliance, reliability, and any business-critical piece of infrastructure, human verification and a human decision stay a required link in the chain, not an optional one.
This isn't an abstract point. Working on this exact site, a real bug surfaced: the CMS threw an error whenever a post got re-saved, caused by a mismatch between a boolean field's type on the backend and the frontend. The code where that mismatch crept in was written together with Claude Code, but the fact that the bug reached production was on me, because I merged it without a test for that exact scenario. A similar story played out with a slug-generation bug tied to transliterating Cyrillic titles, where the "hard sign" and "soft sign," letters that modify pronunciation and have no Latin equivalent, weren't being dropped from the generated URL the way they were supposed to be. Both cases share the same underlying failure shape: the code technically worked in the obvious scenarios and broke in a non-obvious edge case that neither I nor the agent thought of at the time it was written. In neither case did it make sense to blame the tool for not anticipating a scenario I never explicitly stated myself.
Will the programming profession disappear
A binary answer here would be deceptively simple, so it's worth splitting two different concepts right away. "Programmer" as someone whose value lies in turning an already fully specified task into syntactically correct code: that role, in the narrow sense, really is shrinking fast. "Engineer" as someone who builds and maintains technical systems as a whole, including architecture, verification, and accountability for the outcome: that role isn't shrinking, it's changing shape.
The main takeaway from that split: the value of manually producing code as a standalone competency is likely to keep dropping, while the value of engineering judgment, accountability, and the ability to solve complex, poorly specified problems will hold, and by some measures grow.
How to adapt as an engineer
It's more useful to talk about directions of growth than about a specific list of AI tools that'll be stale in a year and a half: strengthen the fundamentals, learn to treat AI as a genuine engineering tool, dig deeper into architecture and systems, deliberately build verification skills, and spend more time on real, complex problems, not just isolated practice exercises.
"Get better at writing prompts" isn't a strategy on its own. I've written about how a genuinely productive system around AI-agent work actually gets built in productivity systems and in focus and deep work: the ability to hold attention on a hard architectural problem without breaking for every minor snag to consult an assistant remains exactly the skill that separates an effective operator of an agentic loop from someone dependent on constant prompting. It's also worth guarding against anxiety about your own replaceability: it's closely tied to the impostor syndrome I wrote about in burnout prevention, and trying to offset that anxiety with constant overwork usually damages exactly the systems-thinking and attentiveness skills that remain the most valuable part of the job. The real goal is becoming an engineer who uses AI to increase their own leverage, not a specialist dependent on AI to solve every individual task.
The core shift: from code producer to system builder
Everything above comes down to one concept. The main shift in the profession can be described as a move from producing individual software artifacts, functions, files, commits, to designing, managing, and evolving systems as a whole.
AI lowers the cost of implementation and, at the same time, raises the bar for how well a problem gets framed and a result gets checked. So the engineering profession isn't disappearing, what's shifting is where human intelligence gets applied: from typing out program text to defining what needs to be built, and to verifying that what got built actually works the way it was meant to.
Conclusion
Back to the question from the introduction: if AI can write the code, what's left for a person? Choosing a direction, understanding context, working with constraints nobody wrote down, making architectural decisions, verifying the result, and taking accountability for the system as a whole: none of that reduces to the syntax of a given programming language.
The final thesis here isn't "AI will replace programmers" and it isn't "AI changes nothing." Both are equally convenient because they remove the need to think through the details. Closer to the truth: AI makes writing code a less uniquely human ability, and at the same time raises the value of genuine engineering judgment, the kind that never reduced to typing syntactically correct text quickly in the first place.
Comments
No comments yet. Be the first.