I
I have been thinking a lot about AI and software development lately. Not primarily about whether AI can write good code. That discussion is rapidly becoming less interesting. It clearly can, and it is getting better at it.
The more interesting question is what happens to software development when writing the code is no longer the central activity. There is an obvious promise here. AI can remove repetitive work, shorten feedback cycles and let developers spend more time thinking about problems rather than translating solutions into code. Agent-based development can allow several pieces of work to progress in parallel. Better specifications can force us to be clearer about what we actually want. I find all of that genuinely exciting.
But I have also started to wonder whether we are looking too narrowly at productivity. Software development doesn't just produce software. It also produces understanding, experienced engineers and, when it works well, teams. What happens to those things?
A few terms before we start
Spec-Driven Development (SDD)
A development approach where a structured specification becomes the primary description of what should be built. In AI-native variants, the specification provides the intent and constraints from which AI agents can plan, implement and verify software. No single, universally accepted definition of SDD exists yet, and different approaches place very different emphasis on how complete a specification should be before implementation starts.
Agent
An AI system that can do more than answer a single prompt. An agent can work towards a goal through several steps, use tools, inspect code and files, make changes, run tests and react to the results.
Harness
The infrastructure and rules surrounding an AI agent: what context it receives, which tools it can use, what instructions and constraints it follows, and how its work is validated. The model provides the intelligence; the harness shapes how that intelligence operates within the engineering environment.
Hub-and-spoke
An approach for organising the information and capabilities available to AI. The hub contains common context and helps the AI navigate the engineering landscape. A spoke is a microservice that delivers a particular set of capabilities to the wider system. The hub coordinates access to those capabilities without needing to contain all of their implementation details.
Context
The information made available to the AI when it reasons about a task. This can include specifications, source code, architecture rules, documentation, previous decisions and instructions. Context is therefore beginning to look less like a prompt and more like an architectural resource in its own right.
These terms describe a rapidly developing field rather than a settled methodology. That uncertainty is important to the argument that follows.
When implementation becomes a black box
One possible future for software development is increasingly specification-driven. A developer describes what should happen. An AI system decomposes the problem, uses the appropriate context and tools, writes the code, generates the tests and presents the result for verification.
There is something very attractive about this. There is also something strangely familiar. The process starts to look like:
Analyse → Specify → Produce → Verify
We have seen that shape before. One lesson I took from Agile was that software development cannot easily be separated into thinking first and building later. Building is itself part of the thinking.
You implement something and discover that the abstraction is wrong. You run it and realise the requirement doesn't quite make sense. Someone tries the feature and asks a question nobody considered. The code is not merely the output of our understanding. Working with it is one way we develop that understanding.
AI makes implementation cheaper, but it does not make uncertainty disappear. Perhaps cheap implementation should make us experiment more rather than encourage us to specify more upfront. It would be a strange outcome if a technology capable of making experimentation almost free instead helped us rediscover waterfall at machine speed.
The cognitive monolith
Another aspect of AI-driven development worries me. AI needs context, and it's understandable to give it as much as possible.
But software architects have spent decades learning to be suspicious of things that know too much. We split systems into domains. We create bounded contexts. We hide information behind interfaces. We try to minimise coupling.
Then we risk building an AI context containing everything.
In the hub-and-spoke model I am criticising, the hub coordinates a collection of microservices, each delivering specialised capabilities. That decomposition can look modular, but the hub still has to understand and coordinate all of those capabilities. Over time, it can become the place where the knowledge, rules and relationships between them accumulate.
The application may consist of beautifully separated services while the information system responsible for creating them becomes a domain monolith. Perhaps the next Big Ball of Mud will not be source code. It will be context.
This seems especially odd in a microservice architecture. Much of the reason for separating services and bounded contexts is to keep complexity local. If a microservice delivers a specialised capability, why should the hub need to contain the detailed knowledge required to coordinate every capability of every service?
Moving complexity out of code does not necessarily mean that we have removed it. We may simply have moved it somewhere less visible.
The architecture of AI knowledge and capability therefore deserves the same scrutiny as the architecture of the software it can modify.
A surprisingly old problem
Thinking about this led me somewhere I did not expect: Marx and the industrial revolution. Not because I think AI-assisted developers are equivalent to nineteenth-century factory workers. Historical analogies become silly when pushed too far. But there is an interesting parallel.
A craftsperson traditionally had a relationship with much of the production process. Understanding the problem, choosing the method, doing the work and judging the result were connected. Industrial production separated them.
Taylorism made that separation systematic. Knowledge about how work should be performed moved into the design of the production system. Individual workers performed increasingly specialised parts of the process. Productivity improved dramatically, but something was lost as well.
Alienation, in this context
Marx's concept of alienation is broader than dissatisfaction with work. Of particular relevance here is the separation of the worker from the product of their work, the process through which it is produced, and other workers.
The analogy I am making is not between nineteenth-century factory workers and modern software developers. It is between two changes in the organisation of production, particularly the separation of understanding, planning and execution.
That made me look at AI-assisted software development differently.
Software developers have remained surprisingly close to craftspeople. We investigate, discuss, design, implement, test, break things, debug them and change our minds. Agile development arguably strengthened that character by putting more responsibility for the development process into cross-functional teams.
What happens when we separate those activities again?
There is a possible progression from developer as builder, to designer, to specifier, to supervisor, and eventually to approver of things produced by machines. Each step can increase productivity. At some point, though, responsibility for the system may become separated from understanding it. That is where this stops being merely philosophical.
The better AI becomes, the stranger the problem gets
Imagine an AI that produces mediocre code. Developers will inspect it, correct it and argue with it. In doing so, they will continue learning about the system.
Now imagine one that produces excellent code almost every time. There is much less reason to look closely. Over time, there is a possible feedback loop:
Better AI → less direct implementation → less exposure to system internals → weaker human mental models → greater dependency on AI
The uncomfortable part is that this failure mode becomes more plausible as the technology improves.
The important question is therefore probably not whether a human wrote the code. I increasingly think it is whether the people responsible for a system still understand it well enough to reason about what happens when reality does something that was not in the specification.
Production has an annoying habit of doing exactly that.
Where do the next senior developers come from?
Another problem is easy to postpone because it will not show up in next quarter's productivity numbers: junior developers.
Experienced engineers did not start their careers by making high-level architectural decisions and supervising autonomous agents. They fixed small bugs, wrote endpoints, read terrible code and wrote some terrible code themselves. They had it reviewed. They spent half a day debugging something that a senior developer could have found in ten minutes. Eventually they became the senior developer who could find it in ten minutes.
Unfortunately, many of those tasks are exactly the things AI can now do extremely well. We could therefore create a model that makes today's senior engineers spectacularly productive while removing the environment that created them.
An organisation can probably run on accumulated expertise for quite a long time before noticing this. The important question is not simply how much expertise AI allows us to exploit today, but how the organisation will produce expertise tomorrow.
And then there is the team
This may be the part I worry about most. Some of my best experiences in software development have involved several people trying to understand something together. Someone draws something on a whiteboard. Someone else says that it cannot possibly work. A third person asks an apparently stupid question which turns out not to be stupid at all. Eventually the group understands something that none of the individuals quite understood before.
That process is inefficient if measured as individual throughput. It is also how teams develop shared understanding.
Now give every developer an extremely capable AI assistant. Why ask the person sitting next to me when my AI can answer immediately? Why interrupt somebody to discuss a strange piece of code when an agent can investigate it in seconds?
Each individual becomes more productive, but thousands of conversations that used to happen may no longer happen. That leaves another trade-off worth attention: individual productivity versus collective capability.
A collection of highly productive developers is not necessarily a highly capable team.
Do we actually enjoy this?
There is an even softer question, although I am increasingly unconvinced that it is soft at all: is the resulting job enjoyable?
Solving difficult problems brings pleasure. The frustration is part of it. You fail to understand something, explore it, have an idea, discover that the idea is wrong, try again and eventually get that wonderful moment when the pieces fit together.
The cycle is something like:
Problem → Exploration → Frustration → Insight → Solution → Creation
AI can remove an enormous amount of pointless frustration from that cycle, and that is a good thing. But if we optimise too aggressively, it can also remove the exploration and discovery.
We may end up with a highly efficient job that consists largely of specifying work, supervising its execution, and verifying results. Perhaps people will love that job. Perhaps many of the people who love software development today will not.
Job satisfaction affects retention, curiosity, creativity and willingness to take ownership. It deserves to be considered part of an engineering organisation's sustainability.
Shepherds and sheep
When I first started thinking about agentic development, I had a simple mental picture. Developers would become shepherds. We would have a flock of extraordinarily capable AI agents. We would provide direction, exercise judgement and decide where to go while they performed much of the implementation. I liked that image.
I am less certain about it now. If the organisation also defines how we must specify problems, how work should be decomposed, how AI should operate and how its results should be verified, then perhaps the developer is not the shepherd.
Perhaps the process is the shepherd, and we are part of the flock.
That is not an argument against structure. Engineering organisations need constraints, standards and common ways of working. It is an argument for paying attention to human agency when designing them.
The goal should not be to minimise human involvement. It should minimise unnecessary human labour while preserving useful human judgement, creativity, and interaction. Those are very different objectives.
How we introduce this matters
We do not yet know what the best AI-native software development process looks like. The technology is changing too quickly, and we have too little experience of its long-term effects on architecture, learning and organisations. That makes this an unusually uncertain time.
A transformation towards AI-native development should itself be experimental. Try something, measure it, talk about what happened, change the model and try again.
And measure more than throughput. Ask whether people still understand their systems, whether junior developers are progressing, whether incidents are easier to resolve, whether developers still solve problems together, whether people feel ownership and whether they enjoy the work.
If AI makes implementation dramatically cheaper, we have an extraordinary opportunity to make software development more empirical, not less.
What are we trying to optimise?
I am convinced that AI will change software engineering substantially, and I expect many of those changes to be very good. What I am less convinced about is that productivity should shape the resulting profession.
A software organisation produces more than software. It produces software, knowledge, engineers and teams. A development model that increases the first while slowly consuming the other three can look spectacularly successful for quite some time.
So perhaps the question we should keep asking while building this new way of working is not simply whether we are producing more software, but whether we are becoming better at building software.
And, perhaps more importantly:
Can we industrialise software production without industrialising the humans who develop it?
I don't think the answer requires us to choose between AI and the way we work today. I suspect there is another model hiding somewhere between the two, one that takes the capabilities of AI seriously without treating human participation as an inefficiency to be engineered away.
That is the question I want to explore next.
A note on how this text was written
There is an obvious irony in writing an essay questioning some consequences of AI-assisted development with the help of AI. So that is exactly what I did.
The ideas did not start as a prompt asking an AI to write an article about AI development. They developed through a conversation. I brought observations, concerns and half-formed connections: Agile and waterfall, hub-and-spoke architectures, Marx and alienation, industrialisation, junior developers, team dynamics and eventually the image of shepherds and sheep.
The AI challenged some connections, helped name others, and occasionally took an argument further than I had originally considered. I rejected things, changed direction and added new concerns. Over several iterations, a structure emerged. Only then did we turn that conversation into this text.
That seems an appropriate place to stop, because the way we wrote this article also hints at a possible answer to some of the questions it raises.
Comments
Post a Comment