The conventional engineering team is not the natural shape of software work. It is a coping mechanism for the era when one person could not hold the whole system.
That era is changing. A senior engineer paired with a fleet of AI coding agents can now keep the whole system in view while delegating the volume of implementation work underneath.
The work does not become less rigorous. It becomes more accountable. One person owns the architecture, the tradeoffs, the review, and the production outcome.
That is the shape Lukla Logic is built around. This essay is the argument for why.
The Team Was A Solution To A Constraint
Start with the thing nobody questions.
Building software requires a team. A product manager to decide what. A designer to decide how it looks. Frontend engineers, backend engineers, a QA function, a DevOps function, and eventually a maintenance team for what remains after the original authors move on.
This is so standard that it reads as a description of the work itself. It is not. It is a response to a specific constraint: one person could not produce enough implementation volume to build a real system in a reasonable time, and could not hold enough specialised knowledge to do every part well.
Both halves of that constraint were real. A production system needs frontend, backend, data modelling, infrastructure, security, testing, and operations. Each is deep. One person working alone would take years and would be mediocre at several of them.
So the industry did the sensible thing. It divided the work by specialism and hired people for each division.
Every practice we consider fundamental follows from that decision. Sprint ceremonies exist to synchronise people who cannot see each other’s work. Detailed tickets exist because the person implementing is not the person who understood the requirement. Handoff documents exist because context does not survive a change of owner. Code review exists partly for quality and substantially because no individual can be trusted to have understood the whole.
These are not laws of software. They are the overhead of coordinating specialists.
The Cost Nobody Counted
Here is what makes the arrangement worth re-examining: the coordination overhead was never treated as a cost. It was treated as the weather.
Consider what actually happens to a requirement as it moves through a conventional team.
Someone in the business has a need. A product manager interprets it and writes a ticket. A designer interprets the ticket and produces a mock. A frontend engineer interprets the mock. A backend engineer interprets a separate part of the same ticket. QA interprets the original ticket to write test cases. Each interpretation is reasonable. Each loses a little.
By the time the feature reaches production it has been translated five times, and the person who had the original need is looking at something adjacent to what they meant.
Then measure the elapsed time. A one-line change: raised, triaged, sprint-planned, implemented in four minutes, waiting for review, waiting for a release window. Three weeks elapsed. Minutes of work.
The dominant cost in conventional delivery is not the work. It is the queueing between people who each hold one piece.
Nobody counted this because there was no alternative to compare against. You cannot see the cost of coordination when coordination is the only option available.
flowchart TD
A[Business need] --> B[PM interprets → ticket]
B --> C[Designer interprets → mock]
C --> D[Frontend interprets]
B --> E[Backend interprets]
B --> F[QA interprets → tests]
D --> G[Integration]
E --> G
F --> G
G --> H[Release window]
H --> I[Production]
I --> J{Matches original need?}
J -->|Approximately| K[Iterate]
K --> BWhat Changed
One half of the original constraint has collapsed. The other has not.
Implementation volume is no longer scarce. A senior engineer directing a fleet of coding agents can produce implementation, tests, documentation, migration scaffolding, and refactoring at a rate a conventional team could not approach. The bottleneck that required dividing work across many hands has moved.
Judgment is still scarce. Deciding what should exist, where the boundaries go, which tradeoff matters, what the data means, where the trust boundaries sit — none of this has been automated, and the honest reading of current capability is that none of it is close.
That asymmetry is the whole thing. If both had changed, this would be a story about replacing engineers. If neither had, it would be a story about better autocomplete. Because exactly one changed, the shape of the work changes.
When implementation was scarce, dividing it across specialists was rational even at high coordination cost. When implementation is abundant and judgment is the constraint, dividing the work is precisely wrong — because division is what fragments judgment.
The Agentic Engineer
What replaces the team is not a smaller team. It is a different role.
A Lukla agentic engineer holds one system end to end. They frame the problem with the client. They make the architectural decisions. They decompose the work into missions narrow enough for agents to execute reliably. They review every line that results. They operate the system in production and evolve it.
The distinctive property is that judgment is applied at every point rather than spread thinly across a roadmap.
In a conventional team, a senior engineer’s attention is divided across several projects, a hiring loop, three design reviews, and mentoring. Their judgment touches perhaps a fifth of the decisions in any given system. The rest are made by whoever picked up the ticket — often well, sometimes not, and rarely with the whole system in view.
In this model, the same engineer’s judgment touches every decision in one system, because the implementation volume that used to consume their week is handled underneath them.
That is not a speed argument. It is a quality argument that happens to also produce speed.
The Objection About Quality
The immediate response is that this must produce worse software. It is the right instinct and deserves a direct answer.
The concern usually assumes agents write code and it ships. That is not the model, and where teams do work that way, the concern is correct.
In practice the speed comes from doing more of the right work, not less:
- Test coverage that a time-pressured team would have deferred.
- Documentation written as the code is written rather than never.
- Observability instrumented from the first commit.
- Security review on every change instead of quarterly.
- The refactor done now, because now it costs an hour.
These are exactly the activities that get cut when implementation capacity is scarce and a deadline is close. Every engineer knows the conversation where tests are dropped to make a date. That conversation is a rationing decision, and rationing is what changes when the resource stops being scarce.
The reviewed line count does not increase. That is the binding constraint and we design around it — narrow missions, hard boundaries, small diffs. Generation is unlimited; review is not. Any team pretending otherwise is approving code nobody read, and will find out in about six weeks.
The Objection About Bus Factor
Sharper, and it lands.
One engineer owning a system end to end is a single point of failure. In a conventional team, if someone leaves, others have partial context. Here, if the engineer leaves, who knows the system?
Three answers, in ascending order of honesty.
First, conventional teams are worse at this than they claim. The system where five people each understand one component and nobody understands the whole is not resilient — it is a system where the integration knowledge lives nowhere. Anyone who has watched a team try to reason about a production incident spanning three services has seen this.
Second, we address it structurally. Documentation is a deliverable, not an aspiration — architecture decision records, runbooks, and system documentation are part of scope and written continuously. The client owns all of it from day one. And every engagement has a second engineer with genuine working familiarity, not merely a name on a document.
Third — and this is the honest part — it remains a real tradeoff. We have concentrated knowledge deliberately, because concentrated knowledge is what makes the judgment coherent. We manage the risk. We do not eliminate it. Anyone claiming this model has no downside is selling.
The Objection About Scale
Does this work for a system that genuinely needs fifty engineers?
Not as a single unit, no. There is a real ceiling, and it is the review budget of one person.
But the honest observation is that a large fraction of software built by large teams does not require a large team. It requires a large team because the organisation is shaped that way — because coordination overhead grew until more people were needed to manage the coordination, which added coordination.
For systems genuinely beyond one person’s span, the model composes: several agentic engineers, each owning a bounded system with a clear contract between them. That is a different essay and a harder problem, and we are not going to pretend we have fully solved it.
What we will say is that the threshold at which a system genuinely exceeds one accountable owner is considerably higher than the industry currently assumes.
What This Means If You Are Buying Software
The practical differences are not subtle.
One accountable person. Not an account manager relaying to a delivery lead relaying to a team. The person who made the architectural decision is the person you talk to about it, and they are still there in year two.
Scoping conversations that go somewhere. Because the person you are talking to will build it, will operate it, and will be there when it needs to change, their incentive to talk you out of a bad idea is aligned with yours.
Speed that shows up as accuracy. When a change takes a day rather than three weeks, requests get smaller and more precise. People ask for what they actually want, see it, adjust. The system converges on what the business needs, not because anyone specified better, but because the cost of being slightly wrong collapsed.
Pricing on outcomes. When delivery is an order of magnitude faster, hourly billing means charging less for delivering more — so the model has to change or the incentives go wrong.
Continuity. The engineer who built it maintains it. No handoff to a support team, no knowledge loss, no “the original developer is no longer with us.”
What This Means If You Are An Engineer
The role changes in ways that are not uniformly comfortable.
More of your day is spent on framing, decomposition, and review, and less on writing implementation. For engineers whose satisfaction comes from the act of writing code, that is a genuine loss and worth being honest about.
What you get in exchange is scope. You own architecture, delivery, and operations for a real system, and you see the consequences of your decisions rather than handing them to someone else. Most senior engineers spend careers wanting that and getting fragments of it.
The skills that appreciate: system design, decomposition, knowing what to verify, reading code critically at speed, and the judgment to know when something is wrong even when it passes.
The skills that depreciate: raw implementation throughput, and encyclopedic framework knowledge.
The engineers who struggle are not the ones who dislike AI. They are the ones whose value was concentrated in producing code volume — because that is precisely what stopped being scarce.
What We Are Not Claiming
A few things, plainly.
We are not claiming agents write production code unsupervised. Every line is reviewed by the engineer accountable for it.
We are not claiming this suits every project. Deep research, novel algorithmic work, and systems where the specification is genuinely unknown at the start are poorly served by a model optimised for confident execution.
We are not claiming the industry will look like this everywhere. Large organisations have structural reasons for their shape that have nothing to do with engineering efficiency.
And we are not claiming to have invented anything. The tools are available to everyone. What is uncommon is building an operating model around them rather than adding them to a team designed for the previous constraint — which is where most of the disappointment with AI-assisted development comes from. Agents inside a conventional team give you a slightly faster conventional team, because the coordination overhead was always the dominant cost.
The Transition Is The Hard Part
Most organisations will not restructure around this, and that is reasonable. Teams exist, careers are built on the current shape, and reorganising around an unproven model is a large bet.
What we would suggest instead is smaller: notice where the coordination overhead actually is.
Measure the elapsed time on your last ten changes against the working time inside them. If the ratio is what we usually see, the opportunity is not in making implementation faster. It is in the queue.
Then ask what the smallest thing is that removes a queue. Usually it is giving one person genuine end-to-end ownership of one bounded system and letting them use whatever leverage they can.
That is a contained experiment. It is also how this model tends to arrive in organisations that adopt it — not as a strategy, but as one engineer quietly outperforming the process, until someone asks why.
The Bottom Line
The conventional engineering team was the correct answer to a real constraint: implementation was scarce, and no one person could hold enough of the system.
Implementation is no longer scarce. Judgment still is. When the scarce resource changes, the optimal structure changes — and dividing work across specialists is now actively counterproductive, because division is what fragments the resource that remains scarce.
What replaces it is one accountable engineer with a fleet underneath, whose judgment touches every decision instead of a fifth of them.
The work does not get less rigorous. It gets more accountable. And accountability, in the end, is the thing clients were always trying to buy.