# Cut Delivery from Months to Weeks: What Shrinks, What Won't
The claims say days instead of months. Some of it is true. The rest is where your programme will actually spend its time.
7 min read · Intermediate · Lesson 4 of 13 in Running delivery · Updated 2026-10-02 · By Akash Das
Canonical: https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/cut-delivery-time/
> **In short.** AI shortens the time to *build* dramatically, but delivery also includes deciding, reviewing,
> proving and waiting for evidence. So the programmes that go from months to weeks also redesign
> those: they make decisions per action, route review by risk, cut work so it integrates daily, and
> start lead-time items on day one. They also accept that live evidence still arrives at the speed of
> traffic.
**In this lesson** you'll learn:
- where the time actually goes in an agentic delivery, once building is fast;
- the four waits you can remove by redesign, and the arithmetic for each;
- the two waits you cannot remove, and how to plan around them honestly.
## Sound familiar?
- The agent wrote the feature in two days; the feature launched in three months.
- Every change waits four days for a review, and the answer proposed is another reviewer.
- A launch date was promised before anyone divided the cases needed by the cases seen per day.
AI has moved the bottleneck, not removed it. The time has gone to the parts of delivery that nobody
redesigned.
*The agent wrote the feature in two days and it launched in three months. The time went to the parts nobody redesigned.*
## Where does the time go?
Vendor claims are real about building. AWS describes AI-DLC delivering tasks "in hours or days that
previously took weeks". But research on AI in software delivery is consistent on the rest: DORA's
2025 report found that AI **amplifies** an organisation's existing strengths and weaknesses, and that
speed without stability produces problems faster; METR's 2025 trial found experienced developers
believed they were faster while measuring slower. The throughput of a delivery system is set by its
slowest step, and once AI writes the code, the slowest step is somewhere else.
## Cut the waits, step by step
### Step 1 · Map the flow and time each wait
List every step from request to live (framing, spec, decision, build, review, test, shadow, cut-over) and measure the waiting as well as the working. The build is usually the smallest number on the map.
### Step 2 · Decide per action, not per system
The slowest waits are often decisions. At SkyWays three executives argued for two weeks about how much
"the assistant" should do; recast as four actions, each with a reversibility, the decision took twenty
minutes. Nothing about AI shortened that; the structure of the question did. [Autonomy per action](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/p0-frame/#step-4--set-autonomy-one-action-at-a-time)
### Step 3 · Route review by risk band
Review capacity is fixed by people, so the only lever is how much review each change needs. Queue time
is slots needed divided by slots cleared per day. Nine changes needing two readers each is 18 slots; at
4.5 a day, that is four days. Routing readers by the risk band of what each change touches cut it to 7
slots and **1.6 days**: a 61% cut with nobody reading faster. [Review by risk](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/review-ai-generated-code/)
### Step 4 · Cut the work so it integrates every day
A plan ordered by priority makes day three wait for day seven. A plan cut by dependency (walking
skeleton first, one unknown per bolt) lets every bolt be built and integrated on its day, so evidence
arrives daily instead of at a sprint demo. [Bolts vs sprints](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/bolts-vs-sprints/)
### Step 5 · Start the lead-time items on day one
Some waits sit in someone else's queue: model access, which is granted per model and per region, on
request; security reviews; data-export approvals. SkyWays lost six days nobody had planned: model
access had been granted in one region in week one, everyone assumed that covered the account, and
nobody had requested the region the data had to stay in. Request every one in week one, even if the
work that needs it is weeks away.
### Step 6 · Plan honestly around what does not compress
Live evidence arrives at the speed of traffic: **days = cases needed ÷ (share × cases per day)**. At
240 cases a day, 500 cases at a 5% canary takes 42 days: the arithmetic, not the effort. You can
shorten it only by widening the share, which raises exposure, or by needing fewer cases, which only an
honest bar and lower bound can justify. Put the number in the plan instead of promising around it.
## Where you'll use it
- **Before promising a launch date**: compute the evidence days first.
- **When a programme "stalls" after a fast build**: map the waits; the stall is a queue, not a team.
- **When someone proposes hiring more reviewers**: count the slots and route by band first.
## Why it matters
Programmes that take the build speed-up and leave the rest of the flow untouched ship the same date
with more rework. The ones that go from months to weeks redesign the waits, and plan openly around
the two that no redesign removes, which is what keeps the date credible.
## Try it
A programme expects 200 cases a day. It needs 400 cases of live evidence before widening past its
canary, and plans a 10% canary. The build is estimated at two weeks. **What is the shortest honest
time from start of build to widening?**
Show the answer
**About five weeks, plus the shadow window.** The build takes two weeks, fourteen days. The canary then
needs 400 ÷ (10% × 200) = **20 days** of live traffic, longer than the build, so 34 days in all. With a shadow window fixed in
advance before the canary, the evidence phases are the long pole, not the code. A 20% canary would
halve the 20 days at twice the exposure; the build cannot be made fast enough to matter.