The more I work with AI in real development, the less I care about how much code it can write. I think far more about what its capabilities will do to the way we put together teams and entire technology companies.
When we talk about AI in development today, we often end up at productivity.
What percentage of the code AI can handle. How many hours developers save. How much work one person can do compared with the past.
That is understandable. It is easy to measure.
But in my own work I am starting to see something that strikes me as strategically far more interesting.
It is not only the amount of work one person can handle that is changing. It is the scope of the problem one person can hold together.
And if the range of the individual changes, perhaps we should reopen the question of how we build the whole organisation around them.
If I forgot how we have built teams for the last twenty years
Sometimes I try asking myself a simple question.
If I were building a software company entirely from scratch today, without today's roles, departments or ways of working in my head, would I build it the same way?
I am not sure.
Take the creation of a new business application.
Until recently I would naturally have assembled around it an architect, several developers, testers and, as needed, an analyst, UX, DevOps and other specialisms.
Each of them holds a part of the problem.
It is a model we know and know how to manage. But it has one cost we barely notice any more.
Context is constantly travelling between people.
Someone understands the customer's need. Someone else analyses it. Someone designs the interface. The architect creates the technical solution. A developer builds it. A tester verifies the result.
Each individual step may be done very well.
Even so, at every handover we explain something, interpret it and piece it back together.
For a long time we accepted this cost, because one person simply could not manage all of these activities.
Today I am starting to doubt whether that still holds to the same degree.
I think AI mainly expands a person's range
Imagine an experienced person who understands development, architecture and product, and can talk to the customer.
In the past they might have had sufficient knowledge in all of these areas, but they ran into a simple problem.
Capacity.
They could not design the system, create the screens, implement every part, write the tests, check the result and deal with operations all at once.
AI is starting to move that boundary.
They can hand part of the execution over to agents.
Suddenly they do not have to physically produce every output. They can focus far more on decisions, direction and checking whether the individual parts still make sense together.
And that, I think, changes the essence of their work.
Their greatest value no longer has to be:
How much can they create with their own hands?
But:
How large a part of the problem can they understand, keep in context and carry through to an outcome?
This shift seems far more important to me than the speed of writing code itself.
Perhaps we do not need owners of parts. We need more owners of the outcome.
When I take this idea further, a slightly different picture of the experienced person in a technology company begins to emerge.
It is not just a programmer with AI.
Nor is it the traditional architect who designs a solution and then hands its implementation over to someone else.
It is a person who can be with the problem from the start.
Understand what the customer is trying to solve.
Help structure the problem.
Turn it into a product.
Make the main architectural decisions.
Build a large part of the solution with the help of AI.
And take it all the way into production.
Their responsibility does not end with handing over a diagram or a user story.
It ends with a working outcome.
And this is where I begin to see one of the ways technology organisations could change.
Fewer people who own only one part of the process. More people who can carry responsibility for the whole.
But breadth must not pretend to be depth
This is an important boundary for me.
I do not think AI will create a person who is at once the best UX designer, enterprise architect, security specialist, database expert, marketer and developer.
Nor would I try for that.
I see it rather differently.
An end-to-end person needs enough of an overview to make sensible decisions and to recognise when their knowledge is no longer enough.
At that moment they need a specialist.
They can design a large part of the UI and bring in a UX person for a complex process.
They can create the architecture and open up the fundamental decisions with other architects.
In security there may be areas where I do not decide on independent review by gut feeling, but have it as a fixed part of the process.
That is why I do not think specialists will disappear.
Rather, I am starting to imagine that we will not need them at the same intensity inside every single team.
They can become a shared layer of expertise for the company.
And that matters in one more way.
I do not want the dialogue between one strong person and AI to become a closed world.
I need them to have someone to test their decisions against.
I need the company to keep sharing experience.
And I need individual projects not to lose their common direction.
So what might such a company look like?
Here I help myself with a thought experiment.
I imagine a company of fifty people that builds software for customers and then develops it over the long term.
I do not take the following numbers as a recommended organisational structure. I am more interested in the proportions and, above all, in the reason why I would separate the individual types of work.
Perhaps I would use ten people for creating new systems.
They would be very experienced people with a wide range. Technically strong, but also able to work with the customer, the product and uncertainty.
Their job would not be to spend the next five years developing the same application.
I see their greatest value in the situation where it is not yet clear what the solution should actually look like.
They would take the problem, create the foundation of the system, and set the rules, the components, the infrastructure and the way of working with agents.
And then would come what I consider one of the most important moments of the whole model.
They would hand the system over.
The best person does not have to make every subsequent change
Once the application is standing, its architecture is stable and further development takes place within known rules, the nature of the work changes.
For a new piece of business functionality I may no longer need a person who can create an entire enterprise system from nothing.
I need an experienced developer who can find their way around the system, knows how to direct AI agents, can check their work and recognises when a requirement starts to go beyond the current architecture.
In my model fifty-person team I would therefore set aside another part of the capacity for exactly this work.
Not as a cheaper substitute for the people who created the system.
But as a different role in a different phase of the product's life.
This is where I start to see interesting economics.
The biggest saving need not come from paying the experienced person less. It comes from using their most expensive ability only on the problems that really need it.
Once the path is known, someone else can carry on.
The person who knows how to find a path is needed again where there is none yet.
And where would I move the freed-up capacity?
This is where the whole reflection stops being only about IT for me.
If, thanks to AI, I need less human work for the execution itself, the first question does not have to be:
Who do I no longer need?
Perhaps a more interesting one is:
Where can I move this capacity so that the company creates more value?
I would want a large part of it closer to the customer.
Today support is often reactive.
The customer reports something. We fix the problem.
But if an application measures its own behaviour well and AI can help interpret it, we can see some problems before the customer has even put a name to them.
That, I think, opens up a far more interesting role.
Not a person who merely takes a ticket.
But a person who can ask:
What is the customer actually trying to do here?
Why are they not succeeding?
What do they need?
And is there something in it that we could solve not just for them, but perhaps for other customers too?
In such a world, part of support naturally moves closer to customer success.
And perhaps to sales as well.
But something is still missing between the problem and development
Seeing a customer's need does not yet mean I should build it straight away.
Someone has to think it through:
Does this problem carry enough value?
Who else does it affect?
Is its solution repeatable?
Does it belong in the product?
Can it be monetised?
Or would we just be expensively automating one customer's exception?
That is why I would keep some people right between the customer and delivery.
People who can turn an unclear signal into a concrete opportunity.
This is where technology, product and business start to meet for me.
And perhaps this is where, in future, I would move part of the capacity we currently use up on the production of software itself.
So in reality I am not just changing the team. I am changing the flow of work.
When I strip the whole model of specific headcounts, it starts to look fairly simple to me.
Somewhere we discover a need.
Someone understands it and decides whether it is worth solving.
If it is an ordinary change within an existing system, it goes on to the people who develop that system.
If it is something that changes its foundation, it goes back to the people able to work with uncertainty and design a new whole.
They create the change.
Stabilise it.
And hand it over again.
So it is not so much about a particular organisation chart.
It is about the company's ability to send a problem to the level of experience it needs at that moment.
That seems to me a far more interesting way of thinking than a plain "AI will increase our developers' productivity by X per cent".
But this is exactly where a new problem arises
The whole model has one fairly fundamental weakness.
The wider the scope we give one experienced person, the greater the dependence on them we may create.
They know the customer.
They know the product.
They designed the architecture.
They know why the components are the way they are.
They set up the agents.
They remember decisions that are not written down anywhere.
And because they are very productive, it is tempting to keep leaving everything with them.
At first glance the result may look great.
A smaller team. Higher speed. Less coordination.
But then the person moves to another project and we find that every more important requirement comes back to them anyway.
At that point, I think, we have not created a new organisation.
We have merely swapped a large team for a very efficient single point of failure.
And this is the point where, for me, strategy starts to translate into a concrete way of working.
A company's capability only emerges once someone else can carry on
If I really want to scale this model, it is not enough for one person to create an excellent system.
I need them, while they work, to be creating the conditions for their own handover.
And that suddenly makes things we might previously have seen as mere technical discipline far more significant.
- Standards
- Consistent architecture
- Reusable components
- Naming
- Tests
- Observability
- Recorded decisions
- Instructions for agents
Suddenly they are not just a matter of code quality.
They are part of how a company reduces its dependence on an individual.
I want to address this part separately, because I believe it decides whether the whole model can work.
In a follow-up article I will therefore look at how I would tell that someone else can genuinely take the system over:
AI in development: turning one person's performance into a capability of the whole company (coming soon)
For the CEO, I think this raises different questions
When I look at it from the perspective of company leadership, I suddenly stop caring only about the number of people in development.
I start asking differently.
Where in our process is value really created today?
Which people are we using for work that no longer needs their level of experience?
How much capacity do we use up on production itself, and how much do we devote to finding further customer needs?
How do we reward a person who, thanks to AI, can carry several times more responsibility?
And one question seems even more important to me.
How will we bring up more people like that?
If AI gradually takes over part of the work we traditionally let juniors grow on, it is not enough to change delivery alone.
We will also have to change the way experience is formed in the company.
In the end, I think this may be a bigger organisational problem than the introduction of AI tools itself.
I think a similar change awaits the CTO from the other side
For the CTO, I think it is not only the technology that shifts.
The very purpose of the company's technical environment shifts too.
If I want a few people to handle a larger scope safely, I need to prepare an environment for them that is predictable.
The more unique each project is, the more it will depend on the person who created it.
The more I can unify principles, building blocks, the approach to observability, security, delivery and the work of agents, the more easily the experience from one project can carry over to the next.
So the CTO, I think, will not only be dealing with:
Which technology will we use?
But increasingly:
How do we create an environment in which one capable person can safely cover a larger whole without becoming its sole bearer?
Perhaps we are not building a smaller version of today's company
For me this is probably the most important point of the whole reflection.
I am not convinced that the right answer to AI will simply be today's organisation with fewer people.
When a technology arrives that fundamentally changes what an individual can do, I think it makes sense to forget, at least for a moment, what the company looks like today and to look again at the problem we are solving.
What do we actually need?
- We need to understand customers' problems.
- Choose the ones worth solving.
- Design a meaningful solution.
- Build it.
- Operate it safely.
- Develop it.
- And look for further value again.
Historical roles are just one way we have divided this work up.
AI may allow us to create another.
Not necessarily a more correct one for every company.
But, I think, different enough to be worth starting to explore.
The question I would start with
If, as a CEO or CTO, I had to take the first step, I would not start by counting AI licences or working out how many developers we can save.
I would take one real project and ask myself:
If I were building it from scratch today, with the possibilities we have, would I divide responsibility among the same people in the same way?
If so, fine.
If not, it becomes interesting to look for why.
Where do we still need deep specialisation?
Where does AI allow us to combine responsibility?
Which handovers no longer add value?
And where, conversely, do we need to add human discussion, review or contact with the customer?
My aim is not to know the right organisational structure in advance.
My aim is not to start automatically from the assumption that the structure which made sense before AI is also the best structure for a time with AI.
That is where I would start looking today.
What comes next
In this article I have deliberately stayed with strategy and the distribution of work.
But the whole model rests on one practical condition:
the person who creates an entire system with AI must not become the only person who can carry on with it.
In the follow-up article I will therefore go one level down and look at how I would actually verify that a system can be handed over — from the work of another senior, through agent-based tests, to signals in the repository itself.
AI in development: turning one person's performance into a capability of the whole company (coming soon)