Agentic coding is changing the unit economics of building companies

I watched GD review a product backlog that would once have implied at least three hires. A backend engineer. A frontend engineer. A QA contractor, or a patient founding team doing QA at midnight. Instead, the list was broken into loops: generate the endpoint, write the tests, run the tests, fix the failure, open the pull request, explain the tradeoff. The work did not disappear. But the staffing assumption did.

That is the change I think many people still describe too loosely.

The cost curve moved

My claim is simple.

Agentic coding has changed the unit economics of building a software company.

Not the physics of building a company. Not the need for judgment. Not the need to find customers. But the unit economics: how much labor, time, and upfront capital are required to produce a working product increment.

I mean “agentic coding” narrowly. I do not mean autocomplete with better marketing. I mean AI systems that can write code, run code, inspect errors, execute tests, revise their own output, and maintain a bounded loop until a concrete task is complete. In my own work, I find the useful frame is not “tiny employees” but structured tools with narrow loops and clear failure modes, which I wrote about in how I use Ai agents for my work.

That distinction matters. The economics change only when the system can carry a task over the line, not merely suggest a starting point.

Software was always a labor stack

Start from first principles.

A young software company turns capital into product, and product into revenue. In the early phase, the biggest line item is usually skilled labor. Not because servers are free, but because human engineering time is scarce, sequential, and expensive. One founder writes the spec. Another engineer implements it. Someone tests it. Someone fixes the integration issue. Someone rewrites the deployment script. Work waits in queues.

Queues are expensive.

If an agent can collapse some of those queues, then the cost per shipped feature falls. If the cost per shipped feature falls, the amount of capital needed before the first useful product also falls. If the capital needed before revenue falls, more founders can stay in the game long enough to find product-market fit.

This is not mysterious. It is operations math.

Suppose a startup needed [[clear: a representative benchmark for software engineer total cost in the US, India, and Nigeria to compare early team burn]] to ship version one in six months. If agentic coding lets a smaller team ship the same scope in the same time, or the same team ship in three months, the company buys either runway or speed. Often both. The exact ratio will vary by product and by team quality. The direction is what matters.

The old bottleneck was “Can we afford enough engineering capacity to build this?” The new bottleneck, more often, is “Can we specify what we actually want, verify that it works, and get people to trust and buy it?”

That is a different company.

The change is bigger outside the Valley

This matters in the US. It may matter even more in Nigeria and India.

Silicon Valley’s advantage was never just talent density. It was also access to capital that could absorb long pre-revenue periods, plus a labor market deep enough to assemble specialist teams quickly. When labor gets cheaper in effective terms, some of that advantage weakens.

A founder in Lagos, Accra, Nairobi, or Jaipur has always faced a steeper version of the same equation: local engineering talent may be excellent but unevenly available by specialty; customers may be price-sensitive; local capital pools are smaller; imported SaaS tools are often priced in dollars; and every month before revenue hurts more.

Agentic coding attacks that equation at the point of pain. It lets a smaller founding team cover more technical surface area before hiring. A company that once needed a dedicated mobile engineer, backend engineer, and DevOps support may now get further with one strong engineer plus founder judgment and AI tooling. That does not make talent irrelevant. It increases the leverage of the strong generalist.

This is especially meaningful in markets where the first customer revenue matters more than the next venture round.

I have written before about how public rails reshape what can be built locally, in UPI, Pix, and NIBSS: Insurance in Real-Time. The same pattern applies here. When foundational infrastructure improves, the viable company shape changes. Agentic coding is infrastructure for production, not payments, but the logic rhymes: lower coordination cost, lower minimum efficient scale, faster iteration at the edge.

India is a useful comparison. India combines deep engineering talent, lower labor costs than the US, and public digital infrastructure such as Aadhaar, UPI, and ONDC-era thinking that has trained founders to build on shared rails rather than from scratch. Agentic coding compounds that advantage. A small Indian team can now pair lower nominal salary costs with higher tooling leverage and build globally competitive software faster.

Nigeria and much of Africa sit in a different position. The upside is not merely cheaper product development. It is the ability to attempt products that were previously uneconomic at local price points. If you serve SMEs, schools, clinics, cooperatives, or insurers in fragmented markets, your average revenue per customer may not justify a large bespoke engineering team. Lower build cost can make these businesses viable sooner.

But there is a limit here. You cannot copy India’s public digital stack overnight. You also cannot code your way around weak identity systems, patchy enforcement, or low-trust market conditions. Software leverage is real. Institutional leverage is rarer.

Some things did not get cheaper

This is where hype usually begins, so I want to be plain.

Agentic coding does not change distribution.

If nobody knows you exist, faster coding does not help much. In fact, it can hurt by flooding markets with more undifferentiated software. Search, partnerships, sales, brand, and embedded channels still matter. Distribution may now matter more because product construction is less scarce.

Agentic coding does not create trust.

In financial services, healthcare, education, and government-facing software, users do not buy only features. They buy reliability, recourse, and institutional confidence. A bank does not care that your onboarding flow was built in two days if your controls are weak. A clinic does not care that your dashboard is elegant if patient data handling is suspect.

Agentic coding does not erase regulation.

It may help teams implement compliance faster. It does not reduce the need for licenses, audits, approvals, local hosting constraints, or governance. In some sectors, the minimum company shape is still set by law, not by engineering productivity.

And agentic coding does not repeal Conway’s Law or basic software entropy. More code generated quickly can become more code maintained badly. If the loop optimizes for “works today” rather than “can be understood next quarter,” the economics can reverse. Cheap code is only good if the maintenance burden does not explode later.

That is why I am careful with the word “agentic.” The value is not infinite generation. It is bounded execution under human judgment.

The labor market will split

I expect the market for technical labor to become more barbelled.

At one end, strong product-minded engineers become more valuable because each one can supervise more output, move across the stack, and translate ambiguous business needs into well-bounded loops for AI systems. At the other end, purely routine implementation work gets compressed.

This does not mean “fewer engineers forever.” It means different timing and composition of hiring. Startups may delay specialist hires until later revenue. They may hire fewer junior engineers for rote tickets and more senior engineers who can design systems, review architecture, and manage reliability. That is a real economic shift, even if headcount grows later.

The football analogy is modest but useful. A good youth coach can get more out of 11 players by improving spacing, decision rules, and repetition patterns. That does not abolish talent. It changes how much talent you need before the team can play coherent football. Agentic coding is like better training structure, not a magic striker.

Geography still matters, but less

I do not think geography disappears. Customers, regulation, language, and trust remain local in stubborn ways. But the gap between “close to capital and elite engineering labor” and “far from both” narrows when software production itself becomes cheaper.

That is why this shift matters disproportionately for founders outside the usual centers. Not because every local startup will now win globally. Most will not. But because more founders can reach the stage where reality gives them an honest answer. More shots on goal. Lower cost per shot.

That is a unit economics story.

My confidence is medium

Medium.

I am confident about the direction. I am less confident about the magnitude and durability.

The direction is already visible in product workflows, team design, and founder behavior. The durability depends on whether these systems keep improving at real task completion, not just benchmark theater, and whether maintenance costs stay controlled over multi-year codebases.

I am also cautious because software history is full of tools that moved work around rather than eliminating it. Some complexity may simply migrate from writing code to specifying, testing, reviewing, and securing it.

Here is the falsifiable test

I would change my mind if, over the next [[clear: choose a time window, likely 24-36 months]], early-stage software startups do not show a sustained reduction in the technical labor required to reach first revenue or meaningful product maturity.

More concretely, I would look for evidence like this:

• Seed and pre-seed companies reaching launch or first revenue with smaller engineering teams than similar companies in [[clear: a pre-agentic baseline period]]
• Faster median time from founding to first usable product in software categories where regulation is not the primary bottleneck
• Lower early burn devoted to engineering labor without a corresponding collapse in reliability or retention
• Stronger outcomes for geographically distributed founders relative to previous cohorts, especially in markets with thinner local capital pools

I would also change my mind if maintenance debt overwhelms the gains: if products built this way systematically suffer worse uptime, security, developer handoff, or rewrite rates after the first year.

The test is not whether AI can produce a dazzling demo. The test is whether a smaller company can build a durable product business with less upfront capital.

That is the principle I keep coming back to. In startups, tools matter most when they change the minimum viable company, not merely the speed of a coding session.

Sources

• Quantifying GitHub Copilot’s impact on developer productivity and happiness - GitHub Research
• Generative AI at Work - NBER Working Paper No. 31161