Someone asked me recently how many engineers a startup will need in two years. When I said “maybe a tenth of what you’d guess,” they laughed. I wasn’t joking.

Here’s what I believe is happening. In the near future, most of the features in most software systems won’t be written by software engineers. They’ll be contributed by domain experts, in the form of high-fidelity prototypes built with AI. Your head of sales, who knows exactly what the pipeline review should look like, will build it. Your customer success lead, who fields the same complaint every week, will build the fix. Your ops person, who lives in the logistics dashboard all day, will rebuild it the way it always should have worked.

I know how this sounds. We’ve heard the “citizen developer” pitch before, and low-code tools never delivered on it. But those tools failed because they asked domain experts to become bad programmers, dragging boxes around a canvas that could never quite express what they meant. AI changes the interface completely. Domain experts describe what they want in the language they already speak (the language of their domain) and get back working software. Not a mockup. Not a requirements doc that gets translated badly through three layers of tickets. A running, clickable prototype that’s 90 percent of the way to production.

If you think this is science fiction, look at who’s furthest ahead. At Anthropic, the company behind Claude, somewhere between 70 and 90 percent of new production code is now written by AI, and the head of Claude Code says his own number is basically 100. The part that gets my attention is that their legal, finance, and marketing teams use the same coding agent the engineers use, to build their own tools. The frontier labs are a preview of every company, and at the frontier, the line between technical and non-technical employees is already dissolving.

I’m seeing this up close, too. Our top producing startups and our most mature portfolio companies at Techstars are converging on this pattern, and we’ve stopped treating it as an experiment in our own shop. We rebuilt our internal operating system, Techstars OS, this way. Right now I’m one of the top feature contributors to it, and I’m the CEO, not part of the engineering team. I can ship because a small and mighty engineering team built the rails that keep my contributions safe and coherent. (Boring to deploy is the goal. Ask them and they’ll tell you we’re not quite there yet.) That’s exactly the point. Nothing I build would survive a week without them doing everything I’m about to describe.

So the question every founder should be asking is simple. What does your engineering team actually do when this becomes true?

Small and mighty

The answer isn’t that engineering goes away. It’s that engineering concentrates.

The startup that would have needed forty engineers will run on four, and those four will have more leverage than the forty ever did. But the job looks almost nothing like the job today. They won’t spend their days implementing features, because features will arrive from the edges of the company, from the people closest to the problem. Your product velocity stops being a function of engineering headcount. That’s a brand new fact in the history of building companies, and almost no org chart reflects it yet.

You can already see this in how the best teams hire. They’re not recruiting deeper specialists. They’re recruiting generalists and systems thinkers, people who can own something end to end while AI agents fill in the gaps. The old handoff chain (designer to frontend to backend to QA to ops) is collapsing into one person directing a fleet of agents. For a startup this is pure gift. Your seed-stage team was never going to afford six specialists anyway.

So what do the four engineers do? In my view, they own four things.

Data structuring and governance. When everyone in the company can create software, the data layer is what holds the company together. Someone has to decide what a “customer” is, where the canonical record lives, what can be derived and what must be authoritative. That’s engineering’s job now. The schema is the new architecture, and getting it right at 20 people is what saves you from the archaeology dig at 200.

Security. Dozens of prototypes flowing toward production means dozens of new attack surfaces. Your engineers become the immune system. They design the authentication and permission models that every AI-built feature inherits automatically, so your ops lead can’t accidentally build something that leaks the customer database, because the platform makes it impossible. And don’t assume this is a big-company problem. Shadow AI shows up by employee twenty, with people adopting unapproved tools and juggling ten different AI apps at once. Your people are going to build with AI either way. The only question is whether they do it on your platform, under your rules, or in the shadows.

Infrastructure. Somebody has to run the substrate all of this executes on, the environments where prototypes are born, evaluated, hardened, and promoted. Platform engineering already has a name for this: the paved road. Make the safe way the easy way and people stop going off-road. The pipeline from “your ops lead had an idea this morning” to “it’s serving production traffic safely” is itself a piece of software, and it’s the most important piece of software your engineers build. The bottleneck was never writing code. It was knowing the code is right. The teams furthest ahead are attacking exactly that, generating hundreds of tests automatically from declared invariants, so checking a prototype costs minutes instead of a sprint.

Integration. Features will come from everywhere, but coherence has to come from somewhere. Engineers make sure the twenty capabilities built by twenty different people compose into one product instead of twenty silos. There’s an architectural consequence here that people are just waking up to. Codebases now have to be legible to machines, not just humans. Explicit boundaries, stable interfaces, contracts written down in plain markdown. The tribal knowledge that lived in your first engineer’s head has to move into the repository, because your new “employees,” the agents, can’t attend the onboarding meeting.

The ground rules are the product

Here’s the part I think almost everyone is missing. The most important artifact your engineering team produces is no longer code. It’s the ground rules.

This is already happening in plain sight. Every serious AI coding tool now reads instruction files (AGENTS.md, CLAUDE.md, and their cousins) that tell the model how software gets built in this system. What patterns to use. What libraries are blessed. How errors are handled. What “done” means. What’s absolutely off limits. An open standard has formed around these files in under two years, and the industry is moving past prompting toward spec-driven development, where a structured spec with explicit acceptance criteria is the artifact humans write and agents execute. Today those files are written by engineers, for engineers. That’s the part that’s about to change.

In the AI-native company, those instructions become the constitution of your software. Your engineering team writes and maintains them, and then everyone builds against them. The engineers themselves, and every domain expert shipping features with AI. When your CS lead builds a new refund flow, it follows the same rules, uses the same design system, respects the same data contracts, and passes the same checks as anything the core team ships, because the same instructions govern both.

Think about what a big shift that is. For seventy years, engineering standards were enforced socially, through code review, tribal knowledge, and the senior engineer who said “we don’t do it that way here.” That never scaled, which is why every large codebase is an archaeology site. Now standards get enforced mechanically, at the moment of creation, by the AI that reads the rules before it writes a line. Codified judgment scales in a way meetings never did.

The engineers who thrive in this world will be the ones who can pull the deep truths out of their system (the invariants, the failure modes, the taste) and write them down so clearly that a machine can follow them. Legislators, not laborers.

What this means for your company

It changes your hiring plan. You don’t need an army, and you never will. You need a few exceptional engineers who think in systems, care about data, and write with precision, because writing the rules is now a core engineering skill. Every engineer you hire should make the platform stronger, not just close tickets faster. Your engineer-to-everyone ratio should look shocking by 2020 standards. If it doesn’t, you’re overbuilt.

It changes your org chart. The wall between “the business” and “engineering” never made much sense at a startup anyway, and now it stops making sense entirely. The relationship starts to look like a city. Engineering builds the roads, the power grid, the building codes, and the inspection process. Everyone else builds what they need on top.

It changes who you hire everywhere else, too. The domain expert who deeply understands the customer and can now express that understanding as working software is a new kind of employee, and for a startup, the highest-leverage hire on the market. Interview for it. Ask your next sales or ops candidate what they’ve built.

And it tilts the field in your favor. Every incumbent you’re up against is carrying an engineering org designed for the old constraint, hundreds of people arranged in a queue between ideas and running software. You get to skip building that entirely. This is the rare platform shift where the startup’s poverty is the advantage. You were never going to out-hire them, and now you don’t have to.

The uncomfortable part

Every previous wave of abstraction, from compilers to open source to cloud, ended with more software and more engineers, not fewer. This wave will end with vastly more software. But not with more people doing what engineers do today, because what engineers do today is mostly translation, turning human intent into machine instructions. That job is going away. The translation layer was never the point.

What remains (judgment about systems, data, security, and coherence) was always the scarce thing. We just buried it under implementation work.

The backlog is dead. The queue of ideas waiting for engineering capacity, the defining constraint of building software since software began, simply dissolves when the people with the ideas can build them. What replaces it is a different constraint: the quality of your ground rules, your data, and your platform. That’s what your small and mighty engineering team is for.

Get this right and you’ll ship at a speed that looks unfair. Meanwhile, the incumbent in your market is still asking its four hundred engineers why everything takes so long.

I’d love to hear how you’re seeing this play out in your own company. Are your domain experts building yet?