How to Scope a Project When AI Can Already Do Most of the Build

More than most scopes assume — and less than the hype claims. In 2025, Microsoft’s CEO said up to 30% of the company’s code was AI-written (varying by language), and Google reported the share of new code generated by AI climbing steadily through the year. A widely-cited rule of thumb, the “70% problem,” captures the shape: AI gets you about 70% of the way fast, then the last 30% turns hard.

That framing is what should drive a scope. The 70% AI does well — scaffolding, boilerplate, standard patterns — barely needs specifying; it’ll get generated either way. The 30% it does badly — architecture, security, integration, edge cases — is precisely where a vague scope turns into rework. So scope inverts: spend your effort defining the hard 30%, not documenting the easy 70%.

Split the work by how much judgment it needs. Hand AI the low-risk, high-volume parts: UI scaffolding, CRUD operations, boilerplate, standard integrations you can review. These are well-represented in training data and cheap to change if they’re wrong.

Own the parts that are expensive to get wrong: the data model, the architecture, the security and authentication design, and the genuinely tricky business logic. These set the ceiling on how far the product can scale and are painful to change once code depends on them. The table above is a starting split — the principle is that anything costly to reverse belongs to a human, and anything cheap to redo can go to AI.

Shift the spec from “how” to “what must be true.” When code is minutes away, describing implementation in detail is wasted effort — the AI (or engineer) will generate it. What’s scarce is a clear statement of boundaries and non-negotiables: the data model, the security requirements, the performance targets, and the rules the system must never break.

Write acceptance criteria first, and make them testable. The real bottleneck in AI-assisted building isn’t producing code — it’s knowing whether the code is correct. A scope that says “a logged-out user must never see another account’s data” or “checkout must be idempotent” gives both the AI and any reviewer something concrete to build and verify against. Specify the tests, and the implementation can vary freely underneath them.

Assume someone else will inherit this — because they usually do. AI can generate code without leaving a trail of why, so the scope has to carry the reasoning: the decisions made, the constraints assumed, and the parts deliberately left simple. That context is what lets a freelancer, an in-house hire, or an agency extend the work instead of reverse-engineering it.

Practically, that means documenting the data model and the key architectural choices, keeping requirements and acceptance tests versioned alongside the code, and controlling access to repositories and infrastructure yourself. Google’s DORA research is consistent on this: AI amplifies the practices already in place — strong process gets stronger, weak process gets faster at producing mess. A scope built for handoff is how you stay on the right side of that.

If you can write a tight, testable spec and personally own the hard 30% — the architecture, the security, the judgment calls — you may not need an agency at all. Paired with AI tools and maybe a freelancer for volume, a capable technical owner can take a well-scoped project a long way. That’s a legitimate, cost-effective path, and we’ll say so when it fits.

You need more than a scope when the 30% is beyond what you can own — when security, scale, or reliability carry real consequences and no one on your side can be accountable for them. At that point the value isn’t writing code AI could generate; it’s the engineering judgment that decides what to build and confirms it’s safe. That’s the line between scoping a build and needing a team to run it.