AI delivery needs a platform, not just a prompt.

The lesson from 2025

Faster code generation is easy to notice. Faster delivery of a useful, dependable change is harder to establish. A developer can generate an implementation in minutes and still wait days for a usable environment, an owner to review it, or a path to release.

DORA’s 2025 State of AI-assisted Software Development report describes AI as amplifying the organization around it. Its summary emphasizes the underlying organizational system rather than tools alone. That finding is a useful starting point; the delivery design below is our interpretation of how a team might respond to it.

Give each change a delivery contract

Our recommendation is to start with an explicit contract between a request and the delivery workflow. Define what the change should accomplish, how someone will verify it, which repository it belongs to, and who can approve a release. This is valuable for any change, whether written by a person or an AI system.

A useful contract is small enough to review. It should not attempt to capture an entire project in one specification. Choose one behavior and write the observable result: which input is accepted, which output should appear, and what must continue working.

Change brief
  Outcome: users can see the owner of a service
  Acceptance: ownership appears on the service page
  Verification: tests + review of the rendered page
  Owner: platform team
  Release authority: designated maintainer

Connect the stages, keep the evidence

We would connect a delivery run in five stages: clarify the request, prepare a plan, implement, validate, and hand off for review. Each stage should leave an artifact that the next stage can inspect. A plan without acceptance criteria is unfinished; a change without validation evidence is still a proposal.

AI assistance can sit inside these stages. It might draft a plan, prepare code, explain a failing test, or assemble review notes. The surrounding workflow should still define permissions, record the change, and enforce the review boundary. A generated explanation should point to actual test results rather than substitute for them.

For a first pilot, use a repository and a low-risk change that your team knows well. That gives reviewers a meaningful baseline for identifying incorrect assumptions and missing context.

Measure the whole journey

We recommend recording elapsed time from an accepted brief to a reviewable change, the effort reviewers spend fixing it, and defects found after release. Treat generated lines of code as an activity measure, not the outcome.

If implementation gets quicker but review expands, investigate the handoff. If tests pass but reviewers repeatedly find the same misunderstanding, improve the acceptance criteria and evaluation cases. If environment setup dominates, improve that path before adding more agent autonomy.

This is the product direction behind Software Factory and Evolith Portal: coordinate the work and the platform it depends on, while keeping the result reviewable. Both are in development; this article describes an engineering approach, not results from a customer deployment.