How AI Changes the Idea-to-Market Value Stream
How building software shifts from a chain of hand-offs to an AI-built flow with a human signing off, plus what the evidence really shows.
Sebastian Bitter
3.8.2026
Idea-to-Market turns a product idea into working software. In its classical form it runs as a chain of hand-offs where most of the time is lost. Three real cases carry the four levels. GitHub Copilot at assistive, about 55 percent faster on a from-scratch task. Amazon Q at agentic, about 30,000 Java applications updated with a developer approving each one. Devin at autonomous, where 14 of 20 tasks failed in an independent test. Two production measurements sit alongside them, from Meta on generated unit tests and from Google on resolving code-review comments, and both are still the most recent published figures for those steps. The coding step has no reliable independent measurement at all, because the research group that ran the one randomised trial has published that its own design no longer holds now that developers refuse to work without these tools. A fast single step is not the same as faster delivery: on large, grown code experienced developers were about 19 percent slower while feeling faster.
The stream today and where AI takes it
Idea-to-Market is the value stream that turns a product idea into working software your customers actually use. It starts when someone writes down what is needed and ends with live software running and watched in production. Almost every software and product team lives in this stream, which is where today's AI coding tools show up first.
In its classical form the work runs as six steps, each passed from one role to the next. The product owner and the business write down what is needed. An architect designs the solution. Developers write the code by hand. Testing happens afterwards, in a step of its own at the end. A colleague reads the change before it is added to the shared code. Finally somebody puts the release onto production by hand. If something goes wrong, the same path has to be walked backwards, which takes hours rather than minutes.
The shape of this is a straight line in which a human performs every step, quality is checked only at the end and reactions are slow. As in any value stream, most of the delay and rework hides in the hand-offs between the steps, where one person waits on another or picks up work without the full picture. A faster code editor does not fix that, because the hold-up sits between the steps rather than inside them.
What AI changes across the levels is the shape of those six steps and their number, which shrinks from six to five. Design and coding merge into one building step, writing the requirement and defining its test move together and the continuous check remains a step of its own. What remains is requirements with test definition, building, continuous checking, approval and release. The human moves from writing every line to setting the direction and approving the result. The rest of this post walks that path one level at a time and shows each change with a real example.
Figure 1: Idea-to-Market across the four levels. The same stream at each level. From assistive to agentic the six classical steps collapse to five, as design and coding merge and testing becomes continuous.
Level by level, shown by real cases
Each level below comes with a real example, its headline number and the point where that number stops holding. The classical level is the starting point above, with no AI in the flow, so the walk begins at assistive.
Assistive: AI suggests, the human stays in every step
At the assistive level the six classical steps stay as they are and AI helps inside each one. A coding assistant suggests code, tests and documentation while the developer keeps every decision. The stream keeps its shape, each step gets a little faster and the human is still in the middle of all of it.
The example is GitHub Copilot, an assistant that proposes the next lines of code directly in the editor. In a controlled experiment with 95 developers building something from scratch, a small web server, the group using Copilot finished about 55 percent faster and more of them finished at all. GitHub ran that experiment itself, so the design is controlled while the interest behind it is not neutral.
A fast single step is not the same as a faster whole and the best independent attempt to measure exactly that has run into a problem worth reporting. In 2025 the research group METR ran a randomised trial in which experienced developers worked on large, long-lived code and found that tasks took about 19 percent longer with AI even though the same developers had predicted a speedup and believed afterwards that they had been faster.
When METR repeated the trial with the agent tools of late 2025, the raw numbers turned around. Among the developers who had taken part the first time the estimate became about 18 percent faster, among newly recruited ones about 4 percent. Both confidence intervals include zero. In February 2026 the group published that it does not trust its own result. Between 30 and 50 percent of the developers said they had held back the tasks they did not want to do without AI. Others declined to take part for the same reason. METR's own conclusion is that developers are probably faster now than in early 2025 and that its data is only very weak evidence for how much.
So the coding step has no reliable independent measurement right now and the reason for that gap is itself the finding. The tools are embedded deeply enough that a paid control group can no longer be held. Developers declined or withheld tasks rather than work without AI. METR had also cut the hourly rate between rounds from 150 to 50 dollars. A 2024 industry report from DORA points the same way at scale, with teams using more AI writing better-documented code while shipping a little less and breaking things a little more often. The assistive gain is real on fresh, self-contained work. It thins out on big existing systems.
Figure 2: the GitHub Copilot case. The task, the AI suggestion, the human decision and the result, with the limits shown alongside. The 55 percent comes from a from-scratch task and does not carry over to large existing code.
Agentic: the AI does the work, a human signs off
At the agentic level the work is rebuilt around an AI agent, an assistant that can carry a whole task on its own, so the six steps collapse to five. The human sets the intent by giving the goal and the guardrails, while the requirement and its test take shape in a back-and-forth with the AI. The agent then builds the solution from that description, so design and coding become one step. Testing no longer waits for the end. It runs on every single change, so a fault shows up within minutes rather than at final acceptance, when twenty later changes already sit on top of it. The human becomes a reviewer and approver who checks, approves and decides the exceptions. The release follows once the change is signed off.
The example is Amazon Q Code Transformation, an agent that upgrades Java applications from an old version of the language to a newer one. Amazon ran it across about 30,000 applications and reported saving the equivalent of roughly 4,500 developer-years of work, plus a separate estimate of about 260 million dollars a year in running costs. It also reported that about 79 percent of the AI-written code shipped with no further changes, with a developer reviewing and approving every change. That approval is the whole point, an AI doing the heavy lifting with a human signing off, which is exactly the setup a careful or regulated team can trust.
The gain is narrower than the headline, which reports a best case reached with Amazon's own tooling behind it. There is no independent audit, every figure comes from Amazon's own publications. The only customer figure in them is far smaller than the headline. A North American insurer estimated an acceleration of about 36 percent after a pilot of four applications, so the agent took roughly a third of the work off their hands. A financial services firm in the same text first had to upgrade its shared internal dependencies by hand before the agent could do its part. A project this size also only pays off when the same update repeats across thousands of similar applications.
Two measurements from other steps of the same stream show the pattern with better evidence behind it. At Meta, a tool called TestGen-LLM writes additional unit tests for code that already has them. It keeps a test only if that test clears a set of filters proving it improves the existing suite. Meta reports that 75 percent of the generated tests compiled, 57 percent ran reliably and 25 percent increased coverage. Engineers accepted 73 percent of what survived, for production use. Read the first three as a funnel rather than a success rate, because three quarters of the attempts did not raise coverage. The interesting part is where the gate sits. Nobody reads every generated test. A filter does, because at this step "better than before" is a machine-checkable statement.
At Google a model proposes an edit to resolve a reviewer's comment and the author of the change decides whether to apply it. Google reports that 7.5 percent of all reviewer comments across its code base are now resolved that way. On its own that number says little. What makes it readable is the baseline Google publishes next to it, an average of about 60 minutes of active work per change between sending it for review and submitting it, with that work growing almost linearly in the number of comments.
Both are the operator measuring its own tool, so read them as Meta's and Google's own accounts. Both are also still the most recent published production figures for these two steps, two years after they appeared, which says something about how thin this evidence base is.
Figure 3: the Amazon Q case. An old application goes in, the agent updates it, a developer reviews and approves, then the new version ships. The limit, about 36 percent success without Amazon's own tools, sits alongside.
Autonomous: the system runs the loop, the human sets the rules
At the autonomous level the system takes over the steering as well, sets its own sub-goals, builds and checks in a loop of its own and releases with a safety net. It rolls the change out to a small share of users first, watches the live numbers and pulls it back on its own if something looks wrong. The human no longer approves each result. They set the goals and the guardrails and keep watch over the whole thing.
The example at this level is a failed test rather than a success story, which is why the autonomous row of this stream carries a warning instead of a number. When Answer.AI, an independent team, ran a structured test of the autonomous agent Devin across 20 real tasks, 14 failed, 3 worked and 3 were unclear. Running fully on its own is not dependable in this stream today, so the autonomous level here is a direction to watch.
Figure 4: the Devin case. The autonomous loop as tested, with the result that most tasks failed. This case marks the ceiling of the stream today: the autonomous level is where the evidence runs out rather than where it is strongest.
What is realistic
Put the four levels side by side and the arrangement of AI work plus human approval holds up to the agentic level. That is where the documented gains and the documented control sit in the same place. For most software teams that is the setting with evidence behind it. The AI does the bounded work, the checks run alongside it and a developer approves before anything counts. That is the Amazon Q pattern, the one place in this stream where a large gain and a working control appear together.
Getting there depends on conditions that have little to do with the model itself. It takes code the AI can find its way around, enough automated tests for it to check its own work, the access to act rather than only to suggest and a clear approval step with a named owner. The cleaner and more modular the code, the further the agent carries, which is the flip side of the Amazon Q limit. What also shifts is the measurement. The number that carries meaning is the time from idea to running software rather than the speed of any single step, because that is the one number a faster editor cannot fake.
The second cost is easy to miss in this stream, because the material you hand the AI is your source code and often the company's crown jewels. The deeper the agent works, the more of that code it needs to see, so how you run the tool matters as much as what it does. On public consumer tools your code can end up training the provider's model. On business or private setups that keep your data to themselves it stays on your side and is not used for training. For a regulated company that choice belongs in the plan from day one, right next to the business case.
More autonomy buys speed at the cost of more work in control and setup, because someone still has to define what good looks like, keep the guardrails current and handle the exceptions. The strength of an agentic Idea-to-Market is throughput on repetitive, well-defined work, with the opportunity of freeing senior people for design and judgment. The weakness is that the gain depends heavily on context and is easy to oversell. The risk is measuring the wrong thing, counting a fast keystroke or an accepted suggestion as delivered value.
Autonomy has a ceiling in this stream, partly technical as the Devin test shows, partly a matter of accountability. Someone has to answer for what goes live, so the approval step stays even where the tooling could skip it. In regulated settings that step is not optional. What the evidence supports today is agentic with a human at the gate, with full autonomy appearing only in the narrowest and best-fenced corners where a wrong result is cheap to catch.
Where the agentic pattern has paid off so far, it started small rather than with a big bang. The documented cases share a shape. It is always a repetitive, well-defined job where checking the result is cheap, plus a human at the gate and a measurement that covers the whole stream from idea to running software rather than one step inside it. Amazon Q is the clearest version of that shape, the same upgrade repeated across thousands of applications with a developer approving each one.
The evidence is uneven across this stream and the gaps in it follow a pattern that is worth reading. Testing and review have production figures behind them. Coding has a contested one. Writing the requirement and deciding the architecture have none at all. Three rounds of searching have not turned any up. The reason is the same one that explains why testing does well. A compiler, a linter and a test run tell a machine whether the output got better. Nothing plays that role for a requirements document or an architecture decision, so nothing gets measured there. An audited figure for the time from idea to running software that a company explicitly attributes to AI could not be found either, which is worth remembering whenever a single step gets faster.
One finding is worth knowing before anyone invests in tooling around a model, because it measures how long such scaffolding keeps its value. The 2026 study named above measured exactly that, when a plain model with no scaffolding beat four specialised test-generation tools, by roughly 18 to 21 percent on line coverage, branch coverage and mutation score, at comparable cost. That is a benchmark rather than a production measurement, so the numbers themselves do not transfer. The direction is the useful part. Machinery built around a model can lose its value faster than the model gains capability.
Transentis runs this pattern in-house and it is the only case in this series told first-hand. The value-stream model behind these posts is built by prompting an AI assistant that has write access to Metapad, the modelling tool built in-house, while a human designs the structure and checks every report that comes back. In August 2026 that assistant created twelve elements correctly and then invented eleven identifiers instead of saying that they had been cut off from its answer. It was caught because an identifier of that kind can only contain digits and the letters a to f. The invented ones contained letters that cannot occur in one. That is the agentic level visible in a single incident. The work is real, the time saved is real and the gate is the only safeguard there is.
Figure 5: gain and price across the four maturity levels. Each level brings a gain and asks a price, drawn from the cases above. Agentic is the level with evidence behind it, autonomous the warning case. This is a concept rather than aggregated metrics. The individual figures are company-reported.
What the switch costs
Every account of this pattern reports what it gained, almost none reports what it cost. A total figure for moving a software organisation from the classical level to the agentic one could not be found from any company. The only breakdowns on offer come from firms that sell the integration work. So the only answer that holds is a list of where the money goes rather than a number.
The model calls are the smallest item, because the unit in this stream is a change and the human work on one costs minutes to hours. Even an expensive run disappears next to that.
The largest item is the set of conditions named further up, where they appeared as prerequisites rather than as a bill. What that groundwork is worth can be read off Amazon's own customer stories. Inside Amazon, where the agent lands on tooling groomed for years, it carries a company-wide campaign across 30,000 applications. At the insurer outside, that became an estimated acceleration of about 36 percent. The financial services firm first had to clean up its internal dependencies itself. The agent was the same and the environment was not. That environment is exactly the groundwork a company pays for first, long before the first model call is billed.
The exceptions do not disappear at this level, they concentrate into a smaller and heavier remainder of the work. Amazon reports about 79 percent of the AI-written code shipping unchanged, which leaves a fifth that does not. Those cases are not the easy ones, because the agent has already dealt with those. What remains is work for experienced people whose time costs more than the time that was saved.
The gate itself costs continuously as well, because a developer reviews and approves every single change. That is a person's time per unit of work rather than a one-off investment.
The model change is the item that did not exist before in anything companies know from buying software, because machinery built around a model can lose its value faster than the model gains capability. A 2026 benchmark study replicated four specialised test-generation tools with current model versions and found a plain model with no scaffolding beating all four. Software bought in 2015 behaved the same way in 2018. That no longer holds.
Measurement is the item most often forgotten, which Meta's case shows more clearly than any other. The real work there was not letting a model write tests. It was building the filter that decides whether a generated test actually improves the existing suite. Without that filter the output would have been unusable. Whoever cannot measure whether it works cannot put it into production either.
What comes next
Idea-to-Market shows in one concrete stream the pattern of the whole series, because steps merge, checking happens on every change instead of at the end and the human moves to the gate. The real gain depends on the context. The question this series puts to every stream is the same one, that is what is actually possible at each step today and who has measured it. That answer ages quickly, which is why the figures here carry a date. The next post takes the same view to Issue-to-Resolution, the customer-service and incident stream, where the wins and the walk-backs sit unusually close together.
Sources
The figures in this post trace to these sources:
GitHub Copilot, about 55 percent faster on a from-scratch task: GitHub research study, 2022 (controlled study, run by GitHub itself)
Experienced developers about 19 percent slower on large existing code: METR randomised controlled trial, 2025 (independent study)
More AI adoption, mixed delivery outcomes: Google DORA report, 2024 (industry-wide survey published by Google Cloud, which sells its own AI tooling)
Amazon Q Code Transformation, about 30,000 Java apps and about 79 percent shipped unchanged: AWS Developer blog and the Amazon Q2 2024 earnings call (company-reported), plus independent coverage
Insurer estimates about 36 percent acceleration after a four-application pilot, financial services firm upgrades internal dependencies by hand first: AWS DevOps Blog, October 2024 (customer stories on Amazon's own blog, customer-estimated)
Meta TestGen-LLM, 75 percent compiled, 57 percent ran reliably, 25 percent increased coverage, 73 percent accepted: Alshahwan et al., FSE 2024, arXiv:2402.09171 (Meta measuring its own tool, full text free)
Google, 7.5 percent of reviewer comments resolved by an ML-suggested edit, against a baseline of about 60 minutes per change: Frömmgen et al., ICSE-SEIP 2024 (Google measuring its own tool, full text free)
METR redesigning its own experiment, raw results showing an 18 percent speed-up for the developers from the first round and 4 percent for the newly recruited, 30 to 50 percent of tasks withheld, 50 dollars an hour instead of 150: METR update, February 2026 (independent research group, reporting the limits of its own study)
A plain model beating four specialised test-generation tools by 18 to 21 percent: arXiv:2601.09695 (benchmark study on 393 classes, not a production measurement)
Devin, 14 of 20 tasks failed: Answer.AI evaluation, 2025 (independent test)
Services
Resources
All Rights Reserved.