AI writes code now. That is settled. What changes is where the value sits. The routine work of producing functions and boilerplate is being absorbed by machines, and the human job is moving up: deciding what to build, how the pieces fit, and whether the output is actually correct. Coder to architect.
A software architect is the person who decides the structure of a system: how it is split into parts, how those parts talk, where the data lives, what fails safely, and which trade-offs are worth making. That role used to sit above the day-to-day typing. Now the typing is the part machines do best, and the architecture is the part that still needs a human.
What AI genuinely does well
Let me be concrete about the wins, because they are real. In a controlled experiment run by GitHub, 95 professional developers were split into two groups and asked to write an HTTP server in JavaScript. The group using Copilot finished 55% faster, averaging 1 hour 11 minutes against 2 hours 41 minutes, a statistically significant result. That is what AI code generation is good at: well-specified, greenfield, boilerplate-heavy work where the answer is fairly standard and the developer can check it at a glance.
Most developers agree. The 2025 Stack Overflow Developer Survey found 84% of developers are using or planning to use AI tools, up from 76% the year before, and 51% of professional developers use them every day. The tools have gone mainstream fast. They draft the first version, fill in the obvious patterns, and turn a blank file into something you can react to. For a large language model trained on a vast amount of public code, predicting the next plausible line is exactly the task it was built for.
In our work building for small businesses, we have found this matters most at the start. The early scaffolding of a project, the throwaway prototype, the standard CRUD screen: these now take a fraction of the time. That speed is real and we use it every day. It is why we can take a client from idea to a working MVP faster than we could three years ago.
The pattern is consistent. When the task is bounded and the correct answer is conventional, the model is excellent. Write a form validator. Convert this data into that format. Generate the API client from a schema. These are cases where a developer reads the result in seconds and knows it is right, and they make up a large share of any working day.
Where AI quietly falls down
Here is the part the tool demos skip. The same capability that drafts a clean HTTP server struggles inside a large, messy, real codebase.
A 2025 randomised controlled trial by METR put 16 experienced open-source developers to work on 246 real issues in their own mature repositories. Allowing AI tools made them 19% slower. Not faster. Slower. The detail that should stop you cold: those same developers expected AI to speed them up by 24%, and even after finishing they still believed it had sped them up by 20%. They were wrong about their own productivity, in the direction that flattered the tool.
That gap between felt speed and measured speed is the whole game. On a complex system with deep context, the AI proposes code that looks right, the developer reads it, accepts it, then spends the saved time untangling what it got subtly wrong. The Stack Overflow data names the same wound: the single biggest frustration, cited by 66% of developers, is "AI solutions that are almost right, but not quite," and 45.2% say debugging AI-generated code takes more time, not less.
Trust reflects this. Only 3.1% of developers say they "highly trust" the accuracy of AI output, while 45.7% actively distrust it. When developers do reach for a human instead of the machine, the top reason, given by 75.3%, is "when I don't trust AI's answers." The machine is a fast junior who never says "I'm not sure." Reading its work, and knowing where it tends to invent, is now a core technical skill. This is why human review stays in the loop on anything we ship. A model can produce a confident hallucination and present it in the same tone as a correct answer.
The value moves up to architecture
If AI handles the typing, the scarce skill becomes everything around the typing. What should this system do? How should it be shaped so it survives the next two years of changes? Which problem is worth solving at all?
This is the future of software development as we see it, and as a founder I am betting the business on it. The job title that matters is software architect, not code typist. Architecture is judgement under constraints: choosing boundaries, naming the trade-offs, deciding what to keep simple and what to make flexible. A model can generate a thousand lines toward a bad design and never notice the design is bad. It has no stake in the outcome and no memory of why the last approach failed.
Systems thinking is the discipline here. The skill is seeing how a change to billing touches reporting, how a new integration affects load, how a "small" feature creates a support burden later. AI can answer a narrow question well. It cannot hold the whole business in its head and tell you which narrow questions are the right ones. That framing decision, the build-versus-buy call, the choice to use a custom solution over off-the-shelf software, sits with the architect.
The Australian labour market is starting to show this shift. In 2025, Jobs and Skills Australia removed "software engineer" from its national shortage list for the first time since the study began in 2021, while higher-specialisation roles such as cybersecurity engineers and software testers stayed in shortage. The report noted the easing is "consistent with various sectors in the labour market that are integrating artificial intelligence technology". Read it carefully: this is correlation, not proven cause. But the pattern fits. Demand for generic coding is cooling. Demand for judgement and specialism is not.
Directing the machine is the new craft
There is a real skill in getting good output from these tools, and it is not the same skill as writing code by hand. It is closer to managing a capable, literal-minded contractor.
The first half is description. A model produces what you ask for, so the quality of your output tracks the quality of your instruction. Prompt engineering is the obvious layer: stating the task, the constraints, and the shape of the answer you want. The deeper layer is context engineering, giving the model the right surrounding information at the right moment, the existing patterns in the codebase, the data structures, the rules it must respect. Feed it the wrong context and it confidently builds the wrong thing. Feed it the right context and it saves you an afternoon.
The second half is direction. You decide which parts of a system are safe to generate quickly and which parts demand slow, careful human work. A throwaway form, generate it. The money-handling logic, the permissions model, the data migration: those you design first and let the model fill in under tight supervision. Knowing the difference is architecture, not typing. As the tools grow into agentic systems that take multiple steps on their own, this judgement about what to delegate, and what to never delegate, becomes the central part of the job rather than a side note.
Why faster individuals do not equal faster delivery
Here is the trap businesses fall into. They see the individual speed-up and assume the whole pipeline gets faster. It does not work that way.
Google's 2024 DORA report measured this across thousands of professionals. A 25% increase in AI adoption was associated with real individual gains: documentation quality up 7.5%, code quality up 3.4%, code review speed up 3.1%. Good news. In the same breath, that adoption was associated with an estimated 1.5% drop in software delivery throughput and a 7.2% drop in delivery stability. More code, shipped less reliably.
DORA's conclusion is the sentence every owner should tape to the wall: improving the development process does not automatically improve software delivery, and "AI does not appear to be a panacea." It only pays off with the basics in place: small batches and strong testing. If you let AI raise the volume of code without raising the rigour around it, you have built a faster way to ship bugs. The architecture, the testing, the review process: those are what turn raw output into working software, and they are exactly where measuring AI return on investment gets honest.
This is the core of how a serious team delivers in software engineering today. The gain is not the code generation. The gain is the system the code generation runs inside.
Will AI replace software engineers?
Short answer: no, but it will change who counts as one. The work that is purely typing known patterns is being automated, and roles defined only by that work are exposed. The work that is judgement, AI code review, architecture, and understanding the business is becoming more valuable, not less.
The developers who thrive will direct AI rather than compete with it. They will write the spec, set the constraints, generate a draft, then bring the part a model cannot: taste, scepticism, and accountability for the result. The ones at risk are those who never move past producing code on request, because that is precisely the task machines do cheaply now.
There is a deeper point about what AI cannot do. It has no genuine model of your customers, no stake in your reputation, and no way to know whether the thing it built was worth building. It produces fluent output regardless of whether the output is right. Closing that gap is human work, and it pays.
The Enki Approach
We treat AI as a tool that makes good developers faster, never as a replacement for thinking. On every build, the same order holds: understand the problem first through proper discovery, decide the architecture, then let AI accelerate the parts it is genuinely good at, under review.
We measure outcomes, not vibes, because the METR finding proved people misjudge their own AI-assisted speed by a wide margin. We keep a human in the loop on anything that touches real users or real data. And we plan the build before we generate a line of it, so the speed of AI works for the design instead of against it. You can read how we structure that in planning AI builds.
The role is moving from coder to architect. For us that is not a threat. It is a description of the job we already do.