From idea to working software: what the full development lifecycle needs to look like

GitHub's research found that developers using Copilot completed tasks 55% faster than those who didn't. Tools like GitHub Copilot and Cursor, powered by large language models such as Claude or GPT, are designed to automate the tedious parts of programming so engineers can focus on harder, more creative problems. With this. new repos spin up every week. The promise is being kept.

But where are the products?

The constraint moved from writing code to everything around it, shared context, review, collaboration, and a feedback loop that tells you whether what shipped actually worked. 

As Fabien Potencier, Upsun's CTPO and author of the 8 stages of AI engineering maturity, puts it: "It's all about the work before writing the code and the work after." Kateryna Dvornichenko, who leads product for Upsun Dispatch™, adds what that means in practice: "Shipping more code doesn't mean shipping a better product."

So what does the full development lifecycle need to look like to actually close that gap?

Intent before output

The first stage of the lifecycle is the one AI skips entirely. Before any agent writes a line, someone has to know what to build and why. That sounds obvious. In practice, most teams are skipping it in the rush to generate.

Intent is not a spec. It is the answer to whether the idea is worth building at all. Upsun Dispatch™ is ultimately trying to enable fewer failed startups, because teams discover earlier that an idea is bad and drop it before spending significant money building something that will fail from the start. That kind of discovery requires human judgment and genuine user research, not a faster code generator.

This is also where context engineering begins. Fabien's description of the amplifier problem is exact: "If you have a clean, well-tested, well-documented codebase, the LLM is better. If you have a baggy project that is a mess, it produces even more mess, faster." 

An agent's output quality is entirely determined by what goes in. Bad context, vague intent, or a weak codebase upstream produces bad output downstream, faster than a human team would have produced it. Speed amplifies what is already there, good or bad.

The implication is that getting intent right is now more important than it has ever been. Skipping the discovery and spec stage does not save time. It just means the team finds out later, and at greater cost, that they built the wrong thing.

Individual speed does not automatically become team output

Most current AI tools make one engineer faster on their own machine. The gains are real. They also stay on that one laptop.

While testing competitor tools, Kateryna observed that: "Using AI is a very solitary process, and we are yet to get to the point where teams can use it in a nice manner." 

The collaboration gap was present in every tool the team evaluated. One engineer builds a setup: custom prompts, tuned skills, a carefully maintained context file. That setup works well for them and nobody else, because nobody else can see it. If they leave, as Fabien notes, "everything is gone."

This is a structural problem. The skills, prompts, agent memory, and shared context that make an AI setup effective are all personal until they are deliberately moved into a shared layer the whole team can see and run. Until that happens, individual velocity creates a coordination problem rather than a team productivity gain.

The specific things that break when AI stays on individual machines:

• Traceability disappears. When a human and several agents have each touched a piece of code across multiple tools, understanding how it ended up in production becomes an archaeological exercise. A shared, logged workflow solves this by design.
• Review becomes a bottleneck. If only the person who ran the agents can approve the next step, the speed advantage of parallel agents collapses at the first human gate. Review has to be distributed across the team, not owned by one person.
• Cost is invisible. Teams using individual subscriptions have no visibility into what AI is actually spending per feature, per workflow, or per team. The bill arrives at the end of the month. By then, the decisions that drove it are long made.

Code is still the job. The author just changed.

The final and most consequential stage is the one most teams are handling least well.

• Ownership doesn't move. Fabien's framing is direct: "When you ask an LLM to write a line of code, the ownership is not the LLM's. The ownership is yours." Symfony has stayed maintainable for more than twenty years because every line, regardless of who wrote it, was reviewed with that understanding. An agent writing the code doesn't change the obligation.
• What review is for changes. Line-by-line syntax checking is increasingly something a model does. What a human brings is taste. As Fabien puts it: "LLMs don't have taste. You get something that is at most average. You don't want average anything." Taste is the judgment that distinguishes code that passes tests from code that will still make sense in two years. It cannot be delegated to the agent that wrote the output.
• Trust is earned, not granted. At the start of any workflow, human gates are on every significant step, not because agents cannot be trusted in principle, but because trust on a specific workflow has not been established yet. As the workflow proves itself correct, gates come down one at a time. The autonomy is real, but it is accumulated through evidence, not switched on by policy.
• ‘Done’ means it works, not that it merged. The feedback loop that closes review is not ‘the build passed.’ Preview environments running against a production-like copy of the infrastructure, the services, and the data change what ‘done’ means. A product manager can check whether the feature matches what they specified. A designer can see whether the interface makes sense. A performance regression surfaces before production, not as a post-incident review.

The full cycle

The three stages above are not a waterfall. They are interdependent. Clear intent produces the context that makes agent output worth reviewing. Good review, combined with a feedback loop that tests against real conditions, is what builds the trust that lets human oversight gradually reduce. Each stage depends on the previous one.

The teams getting this right are not the ones with the best models or the fastest individual engineers. They are the ones who treat the full development lifecycle as a system, where discovery, context, collaboration, review, and a real feedback loop all function together.

 AI made the middle of that system fast. The rest still requires the work it always did.

What this looks like in practice

This is exactly the problem Upsun Dispatch™ is built to address.

Rather than putting agents on individual laptops where their output, cost, and context are invisible to the rest of the team, Upsun Dispatch runs workflows in a shared layer that the whole team can see and run. Every action taken by a human or an agent is logged and traceable. Cost is visible per workflow before a run starts, not discovered at the end of the month.

Human gates are on every significant step at the start. As a specific workflow proves itself correct, gates come down one at a time. The autonomy builds through evidence, not assumption. And when Upsun Dispatch runs alongside Upsun Cloud, every change gets a preview environment: a production-like copy of the infrastructure, the services, and the data, so "done" means the team can see it work, not just that the build passed.

The result is that the speed AI generates at the individual level starts to become something the whole team can build on. 

• New here? Read the introduction to Upsun Dispatch.
• Want to help build it? Apply to the founding design partner cohort.