Software’s AI leverage: Small teams, strong anchors
For most of my career, especially inside the startups where I have done my best work, I have relied on a deceptively simple model for building great software organizations: small, independent teams.
The best teams I have seen were small squads with real ownership. They had a clear mission, a product surface area they understood deeply, ownership and autonomy to make decisions, and enough checks and balances to avoid wandering into the wilderness. Product, design, and engineering worked close to the work. Decisions about scope, sequencing, quality, tradeoffs, and timelines lived near the people actually building the thing.
That model works because software is not really a manufacturing process. It pretends to be one sometimes. We borrow the language of factories, pipelines, roadmaps, backlogs, and delivery dates. But software is closer to a living argument.
What should exist? Who is it for? What is the simplest version that is still powerful? What is elegant versus merely clever? What complexity is worth paying for? What should be deferred? What should never be built at all?
The best squads are good at having that argument without turning it into theater. They do not escalate every decision. They do not wait for perfect information. They make progress. They adjust. They build iteratively and incrementally. They gel. They get better collectively as a team.
And in every great squad, there is usually a person who changes the physics of the team. I think of this person as the anchor engineer.
The anchor engineer is not simply the most senior engineer. They are not necessarily the person who writes the most code, although many of them write excellent code. They are not the “10x engineer” caricature: headphones on, socially allergic, producing heroic amounts of inscrutable code while everyone else works around them. The real anchor engineer is a force multiplier.
They are the bridge between product and engineering. They can sit with a PM and hear not just the words in the requirement, but the shape of the customer pain underneath it. They can look at a design and sense whether the interaction has integrity or whether it is a beautiful dead end. They can look at an architecture and feel where it will bend, where it will break, and where the team is about to buy six months of future regret because they want to save six days today.
More importantly, they have taste.
That word matters. Taste is underrated in engineering because it sounds soft. It is not soft. Taste is compressed judgment. It is pattern recognition earned through scars. It is knowing when something is overbuilt or underbuilt, too clever, too timid, too coupled, too magical, too boring, or too likely to collapse under real usage.
The best anchor engineers do not only have technical taste. They have product taste. They have business taste. They know when a customer pain is existential and when it is merely loud. They know when the company needs speed more than elegance, and when moving fast would create damage the business cannot afford. They know when to accelerate because the opportunity is real, urgent, and worth a little mess. They know when to decelerate because the system, the customer, the team, or the brand cannot absorb another poorly considered shortcut. This is what makes them rare; they know which moment they are in.
I believe the greatest productivity boost from AI will be felt by the anchor engineer. And no, not because they will type faster. Typing was never their real leverage.
Writing code is not hard. Writing the right code is - Neal Fachan
Their leverage comes from judgment. From decomposition. From sequencing. From taste. From knowing what should be built, what should not be built, what should be built now, what should be built later, and what should be killed before it becomes a roadmap parasite.
Agents multiply that kind of person.
AI is a leverage amplifier, and leverage amplifies the person holding the lever. Give a weak engineer an agent and you may get more code. Give a confused team an agent and you may get more confusion. Give an organization with poor taste a fleet of agents and you will get mediocrity at machine speed.
But give an anchor engineer agents and something different happens.
They can explore more options. They can prototype more quickly. They can test architectural ideas without turning every exploration into a staffing request. They can send agents down five paths and use their judgment to choose the one worth keeping. They can turn vague product intent into concrete implementation plans. They can create patterns for other engineers and agents to follow. They can keep multiple streams of work moving without personally becoming the bottleneck for every line of code.
That is the important shift. Agents do not make everyone equally productive. They disproportionately benefit the people who know what to point them at.
This is why I do not buy the lazy version of the AI software engineering future: one human, a thousand bots, infinite code, zero friction, and a glowing dashboard where software pours out like electricity.
It flatters the spreadsheet. It is also spiritually dead and operationally naive.
Software output is not software progress. A codebase can grow while the product gets worse. A team can close tickets while losing the plot. An organization can spend $500M on tokens, generate millions of lines of code, and realize $0 of value in return.
Infinite code is not infinite value. Sometimes it is just infinite cleanup.
The mistake is to think agents replace the squad. They do not. Agents change the leverage ratio inside and around the squad. They absorb more of the mechanical work: implementation, tests, documentation, refactors, migrations, dependency updates, debugging, prototypes, and codebase archaeology. They do not sleep. They do not get bored. They do not have bad days. They do not disappear for a week.
That predictability matters. Not because agents are better than people, but because they are different from people. They are a new execution substrate. They give the best humans more surface area to shape.
And that is why the anchor engineer matters more, not less.
In today’s org, one great anchor engineer might anchor one squad. They translate ambiguity into software. They keep the architecture sane. They keep the product grounded. They keep the team honest. They know when to accelerate and when to decelerate.
In the agentic org, that same anchor engineer may be able to anchor three squads. Maybe more. Maybe less. The exact number is not the point. The point is that the ratio changes. Greater than one. Much less than infinity.
The future is not infinite leverage. Context still has gravity. Systems still have coupling. Product quality still requires attention. People still need coaching. Customers still surprise you. The real world remains stubborn.
Imagine one anchor engineer working across three small squads with other humans and a serious agentic development environment around them. Not random chatbots. A real system of agents that can implement bounded tasks, generate tests, inspect code paths, propose migrations, design UI variants, build prototypes, analyze production traces, update documentation, reason over architectural constraints, and prepare changes for human review.
The humans are not sitting around watching bots work. They are directing, shaping, critiquing, composing, and inventing.
The anchor engineer becomes less of a code producer and more of an orchestrator of taste. They decide which problems are worth solving. They decide how work should be decomposed. They decide where agents can run and where human judgment is required. They create patterns agents can follow. They define interfaces, invariants, tests, review standards, and architectural boundaries. They make sure that ten parallel streams of agentic work do not become ten parallel forms of entropy.
This is where the productivity gain comes from. Not from replacing every engineer. Not from making every person “use AI” and hoping magic happens. The productivity gain comes from reorganizing the work around leverage.
The scarce resource shifts from code production to judgment. And the anchor engineer is already the person in the org whose primary contribution is judgment.
I have been noodling on this piece for a couple of weeks during which this post excellent piece by Brian landed. I encourage you to read it.
