A work item should not become code before the system understands what it is supposed to build.
That question is what pushed us to start building Levi9 SpecForge internally, as our own initiative. We wanted to test something concrete: if a team hands an AI system nothing but a detailed specification, can it carry the work all the way through to deployment – and where exactly does it waste effort, or hit a real wall? Levi9 SpecForge is our attempt at an answer: a spec-driven AI development platform built around a simple but important shift. The specification is not only a document. It becomes the starting point for delivery. Work items, epics, dependency information, review steps, tests, and deployment targets all need to stay connected if AI is going to support real engineering work.
This is not AI as a chat window on the side of the process. Levi9 SpecForge points to a more disciplined model, where AI works inside a delivery flow that can be checked, reviewed, stopped, and moved forward when the right conditions are met.
From unclear requests to usable specifications
Software delivery often starts with a request that still needs shape. Before anything is built, teams need to understand what problem they are solving, which parts of the system are affected, what depends on what, and what “ready” actually means.
Levi9 SpecForge treats the specification as that anchor. It connects work items and epics with supporting information such as decision logs and dependency graphs. That gives the system a clearer picture of the work before implementation starts. Inside the platform, a set of agent personas mirrors how a real delivery team is structured: a Product Owner agent turns the spec into epics and priorities, an architect agent scopes the technical work into sprints and tickets, and Dev, QA, Reviewer, and Security agents carry the implementation itself – each with its own narrow job, the same way a real team would split the work.
The useful shift is simple: the specification is not just context for people. It becomes context the platform can use.
That matters when AI agents are part of the workflow. If the input is vague, the output will be fragile. If the work is structured, the system has a better chance of moving through the right steps in the right order.
Gates keep AI delivery under control
AI-assisted development should not be a straight line from prompt to production. Useful systems need checkpoints.
Levi9 SpecForge is built around the idea of gates: scope review, architecture review, security review, and a deploy gate are treated as parts of the same delivery journey, and each one can be switched on or off. A gate gives the system a reason to pause. Has the work been reviewed? Are tests in place? Is the deployment target clear? Should the work move forward, or does it need another pass?
It is not just a theoretical safeguard. In one test run, the QA agent caught a failing test and sent the ticket back for a fix before it could move on to review – exactly the stop-and-fix loop the gates are meant to produce. In the same run, the Security agent separately flagged that the Dev agent had added a dependency the app did not need, pointing out the unnecessary increase in attack surface – though since it was not rated as a blocking issue, that one passed through rather than stopping the ticket outright. Between the two, it is a useful snapshot of how the gates actually behave: one stops the work, another can flag a concern without hard-blocking it.
The same discipline applies to cost. To stop a feedback loop from quietly running forever, Levi9 SpecForge caps how many review iterations an agent can go through on a single ticket, and sets a token budget per run. Without that kind of limit, a Dev and Reviewer agent could in principle keep sending a ticket back and forth indefinitely – technically “working,” but not producing anything useful, and running up cost the whole time.
A useful AI workflow should not only generate output. It should know when output is not ready to move forward.
That is an important distinction. The value is not in making AI act faster for its own sake. The value is in making the process easier to inspect and easier to control. For engineering teams, that can be the difference between an interesting prototype and something that fits into their actual way of working.
Orchestration turns AI from a task into a process
Levi9 SpecForge brings together orchestration, agent runtime concepts, harnesses, sandboxed execution, and deployment infrastructure. The platform is not described as a single AI assistant doing everything. It is closer to a coordinated system, where different parts of the flow need to pass work, keep track of decisions, and respect the boundaries of the process.
Two choices behind that come directly from how it was built. First, the orchestrator itself is not an LLM. An event-driven, deterministic engine decides what happens next, rather than a model deciding on the fly – the reasoning being that letting a model drive the sequencing risks a flow that cannot be guaranteed or repeated, which defeats the point of having a controllable process at all. Second, the underlying harness was written from scratch rather than assembled from an existing agent framework, specifically to keep the system a “glass box” rather than a black box: every event, every decision, and every exchange between agents stays visible and inspectable, including a running decision log that records why an architect agent made a given call.
Orchestration is the difference between an AI demo and a process teams can repeat.
A single assistant can help with a single task. A platform needs more structure. It needs to know what has already happened, which step comes next, what needs review, what can be deployed, and where human control still belongs.
The platform also points to practical concerns that matter in real delivery, including model choices and budget limits. Not every step needs the same level of reasoning. In early runs, a simple Hello World API was implemented start to finish in under three minutes. A small but extensible calculator app took about ten minutes on a lighter, one-shot prompting setup – and about twenty minutes when run through a fuller agent runtime with session memory and a real iterative loop, which costs more but produces noticeably higher-quality results. Cost and control belong in the architecture, not as an afterthought.
From specification to deployment
The strongest angle is practical: Levi9 SpecForge shows how AI can become part of delivery when the workflow is structured enough to support it.
The platform connects several pieces that engineering teams already care about: work item handling, epic generation, dependency tracking, decision logging, QA and security review, testing, and deployment. It also includes references to deployment targets such as Fargate and wider runtime concepts such as Bedrock AgentCore, GCP, Jira, and MCP. The whole setup is meant to be reproducible: the project is published, and a team with its own AWS account can deploy the full platform themselves through Terraform.
Those details matter because they show where the work is heading. The interesting part is not that AI writes code. The interesting part is that the system connects specifications, review, testing, and deployment into one controlled flow.
That makes the role of AI more realistic. It does not replace engineering judgement. It supports the parts of delivery that benefit from structure, clear context, and repeatable steps. People still define the goals, review the work, and decide what is safe to move forward.
What this means for engineering teams
The bigger lesson is not that every team needs the same platform. It is that AI becomes more useful when teams design the process around it.
Spec-driven AI development starts with a clear description of the work, then uses that structure to guide implementation, reviews, testing, and deployment. That makes the system easier to inspect. It also gives teams a clearer way to decide where AI should help and where human review remains essential.
It also comes with limits that are worth naming rather than glossing over. Microservice environments are the next real challenge – today, the platform maps one project to one service, and splitting that up cleanly is an open problem. Running more than one Dev agent on the same ticket in parallel is not solved either: two agents working the same area of code still need their changes reconciled, so for now only one Dev agent works a ticket at a time. Before building Levi9 SpecForge, the search for existing alternatives also came up short – one comparable platform from another vendor exists but reportedly does not include a deployment step; we were not able to get access to try it directly, and a further candidate has been suggested to test next.
For customers, that is where the business value begins: AI is not treated as a shortcut around delivery discipline. It becomes part of a delivery model that is easier to follow, easier to check, and easier to improve.
***This article is part of the AI9 series, where we walk the talk on AI innovation.***
In this article:
