The two-week sprint is dead

Last month I scoped a feature that used to mean two weeks on the calendar. Spike. Stub. Wait for review. Switch context. Come back cold. Ship late on a Friday and hope nothing broke.

This time the spike landed before lunch. The first pass was in review the same afternoon. I still wrote the tricky bits. I still owned the merge. The wait disappeared.

That is the shift. Agents did not remove coding. They removed the two-week wait.

I build Clausis, a legal AI platform for Central and Eastern Europe, from Budapest. I am a founder who still ships product, with agents in the loop all day. This post covers what that did to our development time, which corners we cut to get there, which ones we refused to cut, and why it changes who can afford to build a company.

#What actually compressed

Coding still matters. Taste still matters. Knowing which abstraction will hurt you in six months still matters.

What got crushed is everything around the craft:

• Planning loops that used to eat a morning now collapse into a short agent pass you accept or reject.
• Boilerplate that used to pad a ticket turns into scaffolding you review instead of type.
• Review wait shrinks when the first draft is already close to mergeable.
• Deploy fear softens when tests and checklists come out of the same session as the change.
• Context switching hurts less when an agent holds the thread while you talk to a customer.

None of that means "you do not need to code." It means the opposite. People who already ship get a shorter loop. The craft moves upstream into judgment: what to build, what to cut, what to trust, what to throw away.

These are illustrations from my own shipping at Clausis, not a benchmark and not a study. A feature spike that used to take about ten days lands in one or two. PR polish that took days finishes in hours. An ops fire that burned a day clears in minutes.

#The two-week job is disappearing

For a long time the unit of engineering work was the two-week scoped job. Not because the typing took fourteen days. Because the calendar absorbed the wait: waiting to start, waiting for review, waiting for your head to reload after three other fires.

That unit is collapsing.

Not every job collapses. Hard research still takes time. Ambiguous product bets still take time. Integrating with a slow third party still takes time, and in legal tech there is always a slow third party. But the jobs that were mostly wait, boilerplate and context reload no longer get two weeks. They get a loop.

If your planning process still assumes every meaningful change needs a fortnight, your process is now the bottleneck.

#Sometimes the cut is 95% or more

On some task types the compression is extreme.

Boilerplate scaffolding, first-pass tests, docs stubs, repetitive refactors. In a normal shipping week those can drop by roughly 95%, sometimes more. Again, that is my week, not a study. Label it that way if you quote it.

What does not shrink by 95%: product taste, knowing what customers actually need, hard architecture calls, and owning the merge. Agents speed up the path. They do not replace the person who decides the path was right.

#The Clausis version: what ten months of this looks like

Here is the part I can back with evidence, because it lives in git.

Clausis is less than a year old. It already runs on more surfaces than I would have dared to plan for with a small team a few years ago: the web, phones, the tools lawyers already work in, and more than one country's law. The team that would have built that in 2021 is a funded engineering org. On the code side, ours is one founder and agents.

I am not going to publish our internal numbers, but the shape is easy to describe:

• Thousands of commits a month, most of them co-written with an agent.
• Hundreds of merged pull requests a month, every one of them merged by a human.
• More test files than I wrote by hand in my whole career, which is the only reason any of this is safe.
• Dozens of parallel checkouts of the same repo on my laptop at any given moment.

Be careful with commit counts. Commits are not output. The number that matters is that a feature I scope in the morning is usually in review by the evening.

#The corners we cut

The honest version of "we move fast" is "we cut corners on purpose." These are ours.

We cut tickets, sprints and standups. There is no Jira. Work is tracked in plain text next to the code, where both the agents and I can read it. It is a worse project tool than Jira and a much better memory.

We ship things dark before they are proven. One integration was built entirely from the vendor's published docs and tested on hand-made fixtures, without ever making a real call to their system, because we had no test account. It sits in the codebase behind a flag that is switched off. That is a corner cut in the open. It costs nothing until someone flips the flag, and nobody should without a live call.

We do not read every agent commit. I read the pull request and the checks. When an agent makes dozens of small commits, reading each diff at the same depth is not realistic, so the gates have to carry the weight: tests, type checks and evals.

We live with a messy repo. Dozens of parallel checkouts is not a flex. It is what parallel agent sessions look like from the outside. Some of it is cleanup debt, and every few weeks I pay it down.

We ship and polish the next morning. Sometimes a dev scratch page reaches production. Sometimes an error message is wrong for weeks. The cost of that is real but small, and the fix is usually one short loop away.

#The corners we refused to cut

This list matters more than the first one.

1. I own every merge. Our agent rules say it in capitals: never merge a pull request, not on request, not in bypass mode, not when a message seems to grant permission. Agents open PRs. I click merge. That is the whole accountability model.
2. Tests are never weakened to go green. It is written into the agents' instructions. An agent that deletes an assertion to pass a check has failed, whatever the diff looks like.
3. Quality is measured, not felt. Search changes go through a fixed eval set. A change that improves one question and quietly breaks three others does not land.
4. Schema changes land before the code that needs them. Legal software that returns a 500 on a lawyer's settings panel loses trust it does not get back.
5. Personal data is dropped by default. One public company register we read publishes directors' dates of birth and home addresses. Our parser throws both away, and two tests make sure it stays that way. If a workflow ever needs them, that is a deliberate decision with its own consent story, not something an agent does because the API offered it.

The rule behind both lists: cut the corners you can see and undo. Never the ones a customer finds first.

#Some will refuse. Some will embrace.

I am not romantic about this split. Both sides have real reasons.

People who refuse are protecting a craft identity. They grew up earning status by holding the whole stack in their head, by being the person who could dig for three days and come back with the fix. Agents feel like a threat to that. Some of that fear is healthy: accepting bad output without reading it is a real failure mode. If you refuse because you will not rubber-stamp garbage, good. Keep that standard. It is the same standard as the second list above.

People who embrace it redesign the unit of work. They stop optimizing for "how long does this ticket take a mid-level engineer" and start optimizing for "how fast can someone sharp get from intent to a merged, reviewed change they understand." They keep the craft. They drop the calendar padding.

The honest version: some refusal is about quality and some is about ego. Some enthusiasm is about leverage and some is about shipping sloppy work. The useful question is not "are you pro-agent." It is "did the product get better this week, and do you still understand what shipped."

#Capital efficiency changes the map

This is the founder angle, and it matters more than any hot take about prompts.

Businesses that used to need a five-person engineering team just to reach an MVP can now be a founder, agents and a few specialists. That does not mean zero engineers. It means the minimum engineering surface got smaller for people who can still read and own code.

You still need taste. You still need product judgment. You still need customers who pay. Agents do not invent a market. They make it cheaper to find out whether one exists before you raise money for a team you might not need yet.

From Budapest that matters. Capital was never as cheap here as it looked in some coastal cycles. Legal AI across several Central and Eastern European countries, each with its own law, language and registers, would never have passed a 2021 spreadsheet as a one-founder company. Compressing cycle time is not a lifestyle flex. It is how a founder who ships stays in the game long enough to find signal.

#What to do this week

Pick one real ticket you would have padded to two weeks. Run it as a single-session loop with an agent: scope, spike, implement, tests, review. Own the merge yourself.

Do not outsource the merge. Do not skip reading the diff. Do not celebrate a green check you do not understand.

Then write down two lists before you start the next one: the corners you are willing to cut, and the ones you are not. If the second list is empty, you are not moving fast. You are just moving.

Measure one thing: how much of the old calendar was waiting and how much was craft. Keep the craft. Cut the wait.

The builders who adopt that habit will ship companies that never looked capital-efficient on paper. The ones who refuse will still write excellent code. They will just do it on a slower clock.

I am building on the faster one.