How to build bigger software with AI coding tools

To build bigger software with AI coding tools, widen scope and accept shallow coverage where it does not matter. Cheaper code changes what is worth attempting. It does not remove the need for production controls around authentication, data, or deployment.

What does build bigger software with AI coding tools actually mean?

To build bigger software with AI coding tools means spending the time those tools free up on a wider product surface, not on the same roadmap delivered faster. The claim, argued by Theo Browne in a 2025 talk and video, is that cheaper code writing changes which products are worth attempting at all.

The mechanism is straightforward. Coding agents lower the marginal cost of producing code, so the expensive part of a project shifts to deciding what to build, integrating the pieces, and operating the result. If code was never your bottleneck, faster code writing changes nothing. If it was, scope becomes the variable you can move.

That is why the recommendation is scope rather than speed. A team that ships the same feature list in half the time has bought headroom, and headroom spent on the previous roadmap produces the same business as before.

The distinction matters for evaluation. Tools that generate code quickly are easy to measure. Whether a wider product is coherent, supportable, and worth maintaining is a different question, and the transcript answers it with one developer's experience rather than a study.

The cloud precedent: what AWS changed in 2006

The closest historical parallel is cloud infrastructure. Amazon Web Services opened to the public in 2006, and it moved capacity planning from a capital decision to a variable cost. Before that, adding a service meant predicting traffic accurately, because buying too many servers wasted money and buying too few crashed the product.

That prediction requirement made experimentation expensive. A failed experiment carried the full cost of hardware that was already purchased, and a successful one arrived with a provisioning scramble. Software economics rewarded narrow bets that could be forecast with confidence.

Renting changed the shape of the decision. Teams could start small and scale up, which made trying a new service cheaper than defending the decision not to try it. Whole product categories, from team chat to cloud CRMs, became viable because a customer could adopt a hosted service instead of running hardware.

The lesson for 2026 is about where the constraint sits. Cloud removed the hardware constraint from software startups and left engineering labor as the scarce input. Coding agents attack that second constraint, which is why the same argument reappears with a different input.

Why hiring costs made narrow verticals rational

Before cheap code writing, the binding constraint was engineering headcount, and headcount decisions carry human consequences. Hiring four engineers for both an iOS and an Android app is a bet on relative demand between two platforms that nobody can forecast reliably.

When the bet fails, the correction is a layoff. Browne describes having laid off a team, and the transcript's point is that this social cost, more than the salary cost, suppressed ambitious experiments. Founders avoid large bets partly because failure lands on specific people.

That is a stronger claim than cheap servers. Cloud reduced financial risk. Coding agents, in this framing, reduce the human and organizational cost of a wrong guess, because a wrong guess consumes fewer hires.

The honest limit: the transcript gives no measured reduction in team size, and no external study is cited. Treat the claim as a mechanism argument from a practitioner, not as evidence that teams are shrinking in aggregate. Later sections separate that evidence class from verified product facts.

The Salesforce feature spectrum, and the 5% problem

The transcript's clearest illustration of the old constraint uses Salesforce, the cloud CRM platform, and a three-part model of its feature surface. Every customer needs a small core: authentication, notifications, basic records. Larger companies need a middle band of reporting, permissions, and integrations. A final sliver of features serves less than 1% of customers.

Browne's estimate is that roughly 70% of what Salesforce does is unused by 99% of its users. Those figures are his editorial estimate, not a published measurement, and I could not verify them against a primary source. Use them as an illustration of skew, not as data.

The flip side is what a single customer needs. A given company may depend on ten common features and two unusual ones. A competitor that matches the ten and misses the two loses the deal, because migration risk is not worth it for the customer.

That asymmetry is what made enterprise displacement brutal. You had to build the middle band and the sliver to win accounts, which meant funding a wide feature set with no revenue until near the end. Browne calls that a suicide mission, and the pattern of well-funded CRM challengers stalling matches it.

Why breadth is cheaper to attempt now than in 2015

The transcript's second model is a two-axis map of any software category. The horizontal axis is range: which capabilities you cover, such as hosting, auth, storage, or video encoding. The vertical axis is depth: how far you go inside one capability.

AWS competes on range, with a working product in nearly every developer category. Vercel, the deployment platform, competes on depth inside full-stack web hosting, and it runs on top of AWS infrastructure while taking a slice of that market. Building AWS's full range used to be the suicide mission.

The claim is that agents invert which axis is expensive. If breadth is cheap because an agent can produce a functional version of each capability, then the rational move is a shallow horizontal product that lets customers go deep on their own where needed.

That is an architectural stance, not a measured outcome. It works only if the platform exposes primitives good enough for users to extend, and if the shallow version is genuinely functional rather than a demo. The transcript's own evidence for this is one 2026 product and one anecdote about users extending it in unintended ways.

What the current agent and hosting stack actually supports

Claims about agent-built software need a reality check against the tools as they exist in September 2026. Agentic coding tools can scaffold and deploy applications, but the surrounding services still determine what is possible without custom work. The table below compares the roles these products play, based only on their own documentation.

Product	What it is	Role in an agent-built app	Notable limit
Claude Code	Anthropic terminal-based agentic coding tool	Runs long implementation tasks on a repository	Work proceeds in a terminal session you manage
Cursor	AI-first code editor built on VS Code	Batch-scaffolds projects and runs agent tasks	Editor-bound workflow rather than headless
Vercel	Deployment platform for frontend and full-stack web apps	Hosts preview and production deployments	No first-party database; pair with an external provider
Clerk	User management and authentication platform	Handles sign-in, sessions, and user records	Auth only; other platform pieces stay separate

The row about Vercel databases is the transcript's own observation, and it is the kind of seam that forces extra integration work rather than removing it.

A second seam appears in agent signatures. WorkOS, an enterprise auth vendor, announced Auth.md, a proposed standard for letting agents register accounts on a user's behalf, with Cloudflare and Firecrawl named as initial partners in the video. That claim comes from the sponsor segment, so attribute it to the vendor: I did not verify the standard's current adoption status against a primary specification for this article.

The practical read for September 2026 is that agent tooling is real and usable, while the integration layer between services is still where projects stall. That integration layer is exactly what the transcript says it abandoned.

A dated benchmark of the transcript's own claim

The transcript's only concrete performance claim is self-reported, and its configuration matters more than the number. Browne says he ran Cursor's agent with a cheaper, faster model to scaffold ten small apps against his own platform, and that the batch deployed in roughly eight minutes, while a parallel Claude Code run took much longer.

That is a speaker-reported demonstration on one machine against one pre-release platform, with no published task list, no success rate, and no independent reproduction. Ten apps in about eight minutes is a throughput observation, not a benchmark of agent coding in general. The comparison between the two tools reflects one configuration on one day, not a general speed ranking.

The surrounding numbers are more useful as a before-and-after of integration cost. A topic-tracking service called Marker Thing took three days for its first version, then one day for a rewrite, roughly 30 to 40 hours in total, with about three hours spent deploying and wiring auth, database, and environment configuration.

Do the arithmetic on his own framing. If a comparable app now takes about 30 minutes to build and deployment still takes about three hours, then deployment went from under a tenth of the work to a large share of it. That is the seam argument stated as a ratio, and it is the most defensible figure in the transcript because both endpoints come from the same person describing the same app.

When a horizontal rebuild is the wrong call

Reinventing the runtime, bundler, database, and hosting layer is presented as the logical end of the seam argument, but it is an unusually expensive response. The transcript is explicit that the project is early, shipping is hoped for rather than done, and some components were still being written by agents during recording.

Two risks deserve naming. First, a platform that owns authentication, storage, and deployment also owns the failure modes, and security review of a one-person platform is a hard problem; Browne himself says he may keep a project private until a model can help verify its security. Second, users pay switching costs when primitives change, and an early product's primitives will change.

There is also a scope trap. Breadth purchased by making every capability shallow can produce a product that is worse than the best vertical in each area while costing more to operate than glue between existing services. The transcript's answer is that users can go deep themselves, which shifts engineering work to customers.

A safer default for most teams in 2026 is to widen one axis, verify the seams, and keep the option to go deeper later. The transcript's framing is a reason to attempt larger things, not a reason to rebuild infrastructure you do not intend to operate.

FAQ

• Is it true that most Salesforce customers only use a small fraction of its features? That is Theo Browne's editorial estimate in the video, not a published measurement. He suggests roughly 70% of Salesforce's functionality goes unused by 99% of its users, and that around 95% of customers need about 5% of features. Treat those numbers as an illustration of a skewed feature distribution rather than verified data.

• Did AWS really make experimentation cheap for startups? AWS launched publicly in 2006 and moved server capacity from a capital purchase to a variable cost. That did reduce the cost of trying a new service and made scale available to small teams. It did not remove other costs, such as engineers, security review, and operations, which is why the coding-agent argument addresses a different constraint.

• What did the 10 apps in 8 minutes demonstration actually measure? It measured one developer's agent run against his own pre-release platform, using a cheaper model in Cursor's agent, with no published task list and no independent reproduction. It shows that batch scaffolding is fast under those conditions. It does not establish a general speed ranking between agent tools.

• Can a shallow horizontal platform replace incumbent services? Only where the missing depth is something customers can supply themselves through exposed primitives. If a customer needs a specific capability that the platform lacks and cannot build it, they will not migrate, which is the same feature-gap problem that stopped CRM challengers before.

• Should small teams rebuild their runtime, bundler, and database to remove integration work? Usually not. Rebuilding removes seams but transfers security, reliability, and migration risk onto a small team. A narrower approach is to widen the product surface first, then rewrite only the layer that repeatedly blocks you.

• What is the most reliable signal that a seam is worth fixing? Measure the share of project time that goes to wiring rather than building. In the transcript's own example, deployment and integration took about three hours out of 30 to 40 hours before agents, and roughly the same three hours afterward. A stable absolute cost paired with a shrinking build cost is the clearest signal.

• Does cheaper code writing mean teams should hire fewer engineers? The transcript argues it changes what is worth building rather than how many people you need. No headcount data is provided. Hiring decisions still carry the layoff risk described in the video, and that risk is a social cost that cheaper code does not erase.

• Are coding agents suitable for production deployment decisions today? They can scaffold, implement, and deploy code, as the transcript's demonstration and current tool documentation show. Production readiness still depends on the platform layer, including authentication, secrets, data handling, and rollback. Agents change who writes the code, not which controls are required.

• What happens if an agent-built app gets real traffic? Nothing about agent authorship changes capacity planning. You still need hosting that scales, a database that survives load, and a support path. The transcript's framing targets internal tools and small projects, which is exactly the range where those requirements are light.

Turning a talk about scope into a written piece

The thread running through this article is a decision about scope: cheaper building makes larger, shallower bets defensible, and the hard part moves to the seams between what you build and what you buy. If you have worked that decision out in a conference talk, a recorded walkthrough, or a long stream, the reasoning already exists in spoken form.

Skalablog turns that recording into a written article. Paste a YouTube URL, let it transcribe the video, and review the result as a draft you can publish. That is all it does: the video becomes text, and the judgment about what to keep stays with you.

Many teams keep their thinking inside recordings for exactly the reason this article describes. Writing it down takes time that feels better spent building. Skalablog removes the transcription and structuring work so the argument reaches readers who will never watch the video.

If you would rather see the toolchain this article was framed with, Gustavo Dev Doido maintains a TypeScript stack at CrazyStack TypeScript.

Source video