How AI is changing software development for startups

Two years ago, the constraint on a small product team was typing. Somebody had to write the CRUD endpoints, the form validation, the migration, the test fixtures. That work was well understood and unglamorous, and it consumed most of a sprint. It no longer does.

What has not changed is everything around it. Deciding what to build, agreeing on what correct means, reviewing the result, and running it in production are all still human-rate activities. The teams getting the most out of AI tooling are the ones who noticed the bottleneck moved and reorganised around its new location.

What has actually gotten cheaper?

Implementation, specifically implementation of things that have been implemented before. A model trained on public code is extremely good at the shape of a paginated API endpoint, a Stripe webhook handler, or a React form with client-side validation, because there are a hundred thousand examples of each.

In practice, the work that has collapsed in cost looks like this:

• →Scaffolding: routes, controllers, schemas, and the wiring between them.
• →Translation: moving a component from one framework to another, or a script from Python to TypeScript.
• →Test generation for code that already exists and already works.
• →Reading unfamiliar code — asking what a 4,000-line legacy module does is now a two-minute question rather than a two-day one.
• →Documentation, which teams historically skipped because it competed with shipping.

That last one is quietly the biggest. Documentation was never hard, it was just never worth the opportunity cost. When the cost drops far enough, teams start doing the things they always knew they should.

What has not gotten cheaper?

Specification. A model will produce exactly the feature you described, including the parts you described badly. The failure mode of AI-assisted development is not incorrect code, it is correct code that implements a misunderstanding — and that failure is much harder to spot in review than a syntax error, because it compiles, it passes tests, and it looks reasonable.

Review has if anything got more expensive. A team that generates four times as much code produces four times as much to read, and the reviewer no longer has the author's context to lean on because there was no author in the usual sense. We have found that review effort, not generation effort, sets the real throughput ceiling on an AI-assisted team.

The bottleneck moved from writing code to being confident the code is right.

Operations has not moved at all. A generated service still needs monitoring, still needs a rollback path, and still wakes someone up at 3am when a dependency fails. None of that is a text-generation problem.

What should a small team actually do about it?

The pattern that works is unromantic: keep the engineering discipline you would have had anyway, and apply AI to the parts of it that are mechanical.

1. 01Write the specification before the code, and make it precise enough that a stranger could implement it. This was always good practice; it is now the highest-leverage hour in the week, because it is the input to everything downstream.
2. 02Keep tests as the contract. Tests written before implementation constrain a model in exactly the way you want, and they are how you tell correct-looking code from correct code.
3. 03Invest in review capacity. Smaller pull requests, better tooling, and an explicit rule that generated code gets read line by line — not skimmed because it looks familiar.
4. 04Automate the operational floor early: CI, preview environments, error tracking. Generation speed is worthless if deployment is still a manual ritual.
5. 05Encode your conventions in a file the tools read. A project-level instructions file that states your architecture rules is the cheapest quality intervention available.

Which tools are worth the time?

The landscape moves fast enough that specific recommendations age badly, so treat these as categories with current examples rather than as endorsements.

• →Agentic coding tools that run in your repository with test access — Claude Code, Cursor, and similar — are where the real gains are, because they can verify their own work.
• →Inline completion still helps, but it is now the smallest part of the picture.
• →Retrieval over your own codebase and documentation matters more than raw model quality once a project exceeds what fits in a single context.
• →Evaluation tooling is underrated. If you ship an AI feature to customers, you need a way to measure quality that is not one engineer's impression.

What this means for a startup deciding how to build

The cost of a functioning v1 has genuinely fallen, which means the interesting question is no longer whether you can afford to build it. It is whether you are building the right thing, and whether you will still be able to change it in eighteen months.

Those are architecture and process questions, and they are the ones a small team most often gets wrong precisely because the code arrived so easily. Speed at the start is only an advantage if the thing you built quickly is also the thing you can keep.