DEV Community: Sundar Shyam Jha

Best Software Factory Tools in 2026: The Stack by Layer (Specs, Context, Agents, Evals, Governance)

Sundar Shyam Jha — Wed, 28 Oct 2026 06:48:07 +0000

TL;DR

A software factory tool is any part of the stack that turns intent into reviewed, shipped code while AI agents do the typing. The stack has five layers (specs, context, agents, evals, and governance), and most teams only buy the agent layer. DORA's 2025 research found that AI adoption now tracks with higher delivery throughput but still tracks with lower stability, a gap the other four layers exist to close. This guide walks through leading tools in each layer, how they fit together, and a minimum stack to start with.

Getting Started: What Counts as a Software Factory Tool

The phrase "software factory" is older than AI coding. Jack Greenfield and Keith Short used it in their 2004 book Software Factories to describe assembling applications from reusable assets, models, and frameworks instead of hand-building each one. The modern meaning keeps the idea of a repeatable line, but the workers on it are AI agents, and the inputs are written intent rather than domain models.

A coding agent on its own is a worker, not a factory. A factory also needs something that tells the worker what to build, something that tells it what the codebase already contains, something that measures the output, and something that stops bad output from shipping. That is why the tool field is easier to read by layer than by product name.

The five layers used in this guide:

Specs: the written, versioned intent that agents build against.
Context: what the agent knows about your repositories, rules, and dependencies.
Agents: the tools that write and change code.
Evals: how you measure whether the output is any good.
Governance: policy checks, approvals, and the evidence trail.

To keep this concrete, picture a composite lender with 300 engineers that is modernizing its loan-origination platform. Its leadership has bought AI coding licenses for everyone. Six months later, the first pilot service has shipped quickly, but reviewers keep finding code that ignores internal API standards, and nobody can say which requirement a given change was meant to satisfy. The lender does not have a tool problem in the agent layer. It has gaps in the other four.

Why Teams Are Assembling Stacks Instead of Buying One Assistant

The numbers explain the shift. Adoption is nearly universal, and the quality problems have not gone away.

Gartner predicts that 90% of enterprise software engineers will use AI code assistants by 2028, up from less than 14% in early 2024.
The 2025 DORA report found that 90% of survey respondents use AI at work and more than 80% believe it has raised their productivity, while 30% report little or no trust in AI-generated code.
The same report observed a positive relationship between AI adoption and delivery throughput, and a continued negative relationship with delivery stability. Its authors tie that instability to rising change volume without strong testing, version control, and fast feedback.

Read together, those figures say that generating code is no longer the bottleneck. Deciding what to build, checking it against what already exists, and proving it is safe to ship are the parts that still take human time. Each layer below targets one of those.

Layer 1: Which Spec Tools Keep Agents Building the Right Thing

A spec layer gives agents something better than a chat prompt. The simplest version is a requirements document that lives in the repository next to the code, reviewed like any other change. More structured versions generate that document from a short intent statement and break it into tasks.

GitHub's open-source Spec Kit is a common starting point for teams that want spec-driven development inside their existing repositories, and GitHub's own write-up on spec-driven development explains the reasoning: language models are good at pattern completion and poor at guessing unstated requirements. Plain markdown PRDs and architecture decision records do the same job at lower ceremony, and many teams begin there.

Platform-level options go further. Forge, from Opsera, keeps what it calls Living Specs, versioned intent and constraints stored alongside the code, and converts them into Work Orders that carry requirements, tests, and done-criteria.

For the lender, the spec layer is where the first fix lands. The pilot team had been prompting agents from one-line tickets. Writing a short spec per service, with the lending-specific constraints stated outright, meant the agent no longer had to guess which of the lender's standards applied.

Layer 2: What Context Tools Give Agents Memory of Your Codebase

Agents start every session knowing very little about your organization. Context tools close that gap, and they range from a text file to a full code graph.

Instruction files: AGENTS.md, CLAUDE.md, and similar files in the repository tell an agent about conventions, commands, and boundaries. They are cheap, versioned, and the right first step.
MCP servers: the Model Context Protocol lets agents reach live systems such as tickets, databases, logs, and documentation without pasting content into prompts.
Code intelligence and knowledge graphs: these map dependencies, business rules, and data flows across repositories so an agent can see what a change will touch before it writes anything.

The third category is where enterprise teams usually feel the gap first. A single repository's instruction file cannot tell an agent that a function is called by three other services. Forge, one platform in this category, addresses this with a knowledge graph that maps an existing estate's code behavior, business rules, architecture, and dependencies. In a demo project built from a public .NET sample application, its overview screen reported 1,363 entities and 6,072 relationships, and an architecture-rules check flagged circular dependencies and single points of failure.

The lender's reviewers had been catching a recurring problem: agents rewrote shared validation code without knowing four downstream services depended on its exact behavior. An instruction file warning "do not change shared validators" helped a little. A dependency map showing what each change would affect helped much more.

Layer 3: Which Agent Tools Do the Coding Work Itself

This is the crowded layer, and the one most teams have already filled. A few distinctions are worth keeping in mind.

Interactive agents and editors. Claude Code runs in the terminal, IDEs, a desktop app, and the browser, and uses Anthropic's models. Cursor combines an editor, a CLI, and cloud agents. GitHub Copilot works inside the IDE and through a coding agent that hands work back as pull requests. Windsurf is an agent-centered editor, and OpenAI's Codex and Cognition's Devin cover terminal and more autonomous use.

Open-source options. Aider is a terminal tool released under Apache 2.0 that can be self-hosted. Continue offers IDE extensions and a CLI, also Apache 2.0. OpenCode is an open-source, model-agnostic agent. These fit when data residency or model choice rules out hosted-only tools.

Runtimes and orchestration. Running agents unattended needs somewhere safe to run them. Warp's breakdown of factory tooling lists sandboxes such as Daytona, E2B, and Modal, and orchestration products such as Warp Factories and GitLab Duo Agent Platform. Factory, with its Droid agents and Missions feature, sits in the same space from a different direction.

A caution applies to every vendor ranking in this category, including the ones cited here. Several of the top-ranking "best software factory" articles are published by companies that sell one of the products in the list. That does not make them wrong, but it is a reason to test tools on your own repositories rather than rely on anyone's matrix.

The lender already has this layer covered. Its engineers use two different agents, which is fine, but it also means any control placed inside one tool will miss work done in the other.

Layer 4: How Eval Tools Tell You Whether the Factory Is Working

Evals are the weakest layer in most stacks. Teams count licenses and anecdotes, then wonder why leadership is skeptical.

Three kinds of measurement are in use:

Delivery metrics: DORA's throughput and stability measures show whether the factory is changing outcomes, not just activity.
Model-graded scoring: LLM-as-a-judge scorers grade agent output against a rubric. Warp reports that this scoring costs about 3% of total token spend in its own internal factory, which is a company-reported figure.
Benchmarks on your own tasks: Factory's platform comparison argues that public benchmarks cannot predict results for a different repository and deployment, and recommends testing handoffs with the same starting revision, reviewer corrections, and time to approval.

That last advice is the most useful one. Pick ten real tickets, run each tool or configuration on all ten, and compare reviewer time, defects, and cost. It is slower than reading a leaderboard and far more informative.

For the lender, a baseline of review hours per merged change before the pilot would have made the later conversation much easier. It did not have one, so the pilot's results were arguable.

Layer 5: Which Governance Tools Keep Agent Output Accountable

Governance is the layer most "best tools" lists skip. Specs, context, agents, and evals describe how code gets produced. Governance decides whether it is allowed to ship and leaves a record of why.

Standard pieces already exist in most organizations: branch protection, required reviews, CI checks, security scanners, and change-management tickets. They work, but they run after code exists. Agent-generated code arrives faster and in larger volume, so catching a policy violation at review time costs more than catching it before generation.

Dedicated products now target this layer. One example is Forge, made by Opsera, which describes itself as an orchestration layer above the models and coding agents, one that does not compete with Claude Code, Copilot, or similar tools and governs the lifecycle around code generation. Its product page frames the workflow as five stages:

Context: maps the existing estate.
Living Specs: stores versioned intent and constraints.
Work Orders: turns intent into assignable work with tests and done-criteria.
Guarded Build: has agents work inside policy, security, and architecture checks, with human approval before merge.
Evidence: produces a traceability record linking each change to its requirement, tests, and approver.

Inside the product, the same idea appears as a seven-step artifact pipeline: Intent, PRD-Spec, Architecture, an optional UI Design step, User Stories, Testing, and App Context, with a human approval gate on every handoff. It also includes ForgeScore, a codebase health scorecard across eight engineering dimensions, which gives a team the baseline the lender was missing.

The trade-off to weigh is that an orchestration platform adds a spec-first workflow on top of the agents. Teams that only need quick edits may find branch protection, scanners, and a review checklist enough.

The same overview in practice: each artifact is generated, reviewed, and approved before the next stage runs, which is what makes the evidence record possible.

The vendor also publishes outcome figures on the page, such as reduced token spend and delivery time. Those are vendor-reported and the page does not describe the baselines, so treat them as claims to test in a pilot rather than expectations.

In the lender's case, the Evidence stage answers the question compliance kept asking: which requirement authorized this change, who approved it, and what tests ran. Without a governance layer that answer had to be reconstructed by hand each time.

How to Assemble a Minimum Stack Without Buying Everything at Once

Few teams need all five layers on day one. A sensible order follows where the pain shows up:

Write specs and instruction files first. They cost nothing but time and improve every agent you already use.
Take a baseline. Record review hours, change failure rate, and rework for one team before adding anything.
Add context tooling when reviewers keep finding cross-service breakage. Dependency maps pay for themselves where services are tightly coupled.
Add governance when audit or security reviews start blocking releases, or when more than one agent is in use.
Add orchestration and unattended runs last, once the earlier layers make the output trustworthy enough to leave alone.

The order is less important than the rule behind it: add a layer when you can name the failure it prevents.

Where Should You Start With This Stack

The agent layer is crowded, cheap to enter, and the least likely to be your constraint. The gaps that slow enterprise teams are upstream (what to build and what the codebase already contains) and downstream (how output is measured, approved, and recorded). A tool list organized by layer makes that visible, and it explains why a team can own several excellent coding agents and still ship inconsistent, hard-to-audit code.

For a next step, choose one service, write its spec, record a baseline, and run it through your existing agent with whatever policy checks you can add. For a reference point on what a full spec-to-evidence flow looks like, the Forge product page and its public documentation describe one implementation, which is useful even if you assemble the layers yourself from other tools.

FAQ

What is a software factory tool?

A software factory tool is any product that supplies one part of the pipeline from intent to shipped code: specs, context, agents, evals, or governance. A coding assistant alone covers only the agent layer. Teams usually combine several tools to cover the rest.

What are the best software factory tools for enterprise teams in 2026?

It depends on the layer. Spec Kit or repository-based specs, instruction files and MCP servers, agents such as Claude Code, Cursor, and Copilot, DORA metrics for evals, and an orchestration layer such as Forge are common picks. Test on your own repositories.

Do I need a software factory platform, or can I assemble open-source tools?

You can assemble one. Aider, Continue, OpenCode, repository specs, and CI checks cover most layers at no license cost. The trade is integration effort and a weaker audit trail, so regulated teams often buy at least the governance layer.

How is a software factory different from an AI coding assistant?

An assistant helps one developer write code at the moment. A factory defines what gets built, supplies codebase context, measures results, and enforces approvals across many developers and agents. Assistants are workers inside it.

How do I measure whether a software factory is working?

Compare delivery metrics against a pre-pilot baseline: throughput, change failure rate, rework, and review time. Add model-graded scoring and a ten-ticket test on your own repositories. Avoid judging by license counts or lines generated.

Which layer should a small team add first?

Specs and instruction files. They are free, they improve every agent you already run, and they create the written intent that later context and governance tools can build on.

Top AI Code Generation Tools With Built-In Governance and Compliance (2026)

Sundar Shyam Jha — Thu, 08 Oct 2026 13:32:32 +0000

TL;DR

Governance in an AI code generation tool comes down to six checks: who can sign in, what happens to your code, where the model runs, what the agent may do, what record it leaves and which audits the vendor has passed. I ran six tools through that list using public docs in October 2026: GitHub Copilot, Cursor, Augment Code, Factory, Tabnine and Forge. This guide explains each check, covers every tool in turn, and shows how I would choose.

Getting Started: What Governance Means for AI Code Generation

When a developer asks an AI tool for code, three things leave the building or change hands: the code and context you send, the access the tool is given, and the decision to accept what comes back. Governance is the set of controls around those three things. It is also what a security reviewer will ask about before the tool reaches more than a pilot team.

I turned that into six checks, and I used the same six on every tool:

Identity and access: SSO, provisioning and roles.
Data policy: retention, training and what can be excluded.
Where it runs: the vendor cloud, your VPC, your data center or an airgap.
Agent controls: what an agent can touch and who approves its output.
Audit record: logs and events you can export.
Certifications: what the vendor lists, and what that scope covers.

I read vendor docs and enterprise pages and did not test any of these in production. To keep the checks grounded, I will keep one hypothetical team in mind: a software group at a hospital network that must keep inference inside its own environment and show an auditor who approved each change. The details are invented. The constraints are common.

How the Six Tools Compare Across the Six Checks

The short version is that the deployment model separates the field faster than anything else. Two of the six, Factory and Tabnine, document a fully airgapped deployment. Augment sits in between, since its agents can run on your machines while the control plane stays with the vendor. Cursor and Copilot are cloud services. Forge is a hosted application whose Coding Agent works inside your own Git repository.

I got that count by reading each vendor's deployment pages, so treat it as a starting point for a security questionnaire and not a conclusion.

GitHub Copilot Governance Controls You May Already Have

GitHub groups its enterprise controls into policies, audit logs, agent management and MCP allowlists. Admins can block agentic features, review audit logs and set which MCP servers are allowed. If your organization already pays for Copilot, the first job is to see which of these are switched on.

The part I would read twice is content exclusion. It stops Copilot from using chosen files in suggestions, chat answers and code review, and GitHub's documentation lists its gaps plainly. It is not supported in Edit and Agent modes of Copilot Chat in Visual Studio Code and some other editors. It does not apply to symbolic links or repositories on remote filesystems. And Copilot may still use semantic information the IDE supplies indirectly, such as type information.

For the hospital team, that means "this path is excluded" needs a test in each editor developers use, not an assumption. For the cloud agent, GitHub documents write access to trigger it, one branch to push to, no ability to approve or merge, a restricted firewall, and signed commits with session logs.

Cursor Offers Strong Admin Controls but Only in the Cloud

According to Cursor's enterprise page, admins can enforce SSO, disable local login and provision users with SCIM. They can allowlist or blocklist repositories, models and MCP servers and set global agent run settings. With Privacy Mode on for the whole organization, code is never used for training, and Cursor says it holds zero data retention agreements with its model providers. Data is encrypted with AES-256 at rest and TLS 1.2 or higher in transit.

The same page says plainly that Cursor does not offer on-premises deployment today. For the hospital group, that ends the evaluation before the other controls come into play. For a team that accepts a vendor cloud, the list above is strong. Cursor's footer also lists ISO 27001, ISO 42001 and AIUC-1 alongside SOC 2 Type II, and I would ask for the reports behind each.

Augment Code Adds Key Custody and AI-Specific Certification

Augment's security page lists SOC 2 Type II attestation and ISO/IEC 42001 certification, which is a standard for AI management systems. It also describes customer-managed encryption keys, a Proof-of-Possession API so completions work only on code the requester holds locally, and a commitment not to train on customer proprietary data, backed by an indemnification clause in its terms.

Its Cosmos platform adds budget caps per automation or user, plus versioned, auditable Experts and environments. If your policy says you must hold the keys, this is the first tool I would put in front of the security team.

One caution I would pass on: an independent write-up of Augment's materials notes that its certifications do not explicitly test the no-training policy. Treat the certificate as one input and ask for the contract language.

Factory Has the Most Detailed Deployment Model I Read

Factory's enterprise docs describe managed settings in a hierarchy that covers model access, command policies, MCP allowlists, hooks, sandbox policy and retention. The deployment pages say code and files stay local unless the selected context goes to a model or gateway you configured. They offer cloud-managed, hybrid and fully airgapped patterns, and a separate EU deployment that keeps session content in Europe and sends EU inference only to EU-region endpoints. The factory lists SOC 2 Type II, ISO 27001 and ISO 42001.

For the hospital team, the airgapped pattern is the one to test: no outbound internet, models served from endpoints inside the network, and Factory's cloud not reachable at runtime. I would ask for a proof of concept that shows software and configuration arriving through your own artifact repositories.

Tabnine Spans the Widest Range of Deployment Options

Tabnine advertises SaaS, VPC, on-premises and air-gapped deployment, and zero code retention. That is the widest spread of any tool here, and for a team with a hard network boundary it earns a place on the shortlist.

I could not open Tabnine's own trust pages while preparing this piece, so I have not verified its identity controls or certifications. Ask for its certification reports directly instead of relying on a summary from me or anyone else.

Forge Adds Approval Governance Around Code Generation

Forge belongs on this list for a different reason from the other five. It is a governance layer around code generation and not a completion tool, so it answers some of the six checks differently. Its pipeline requires an explicit Approve & Continue on Intent, requirements, Architecture and User Stories, and the docs say regenerating an upstream artifact clears the approvals below it. Artifacts are versioned, and Forge can produce a Requirements Traceability Matrix that links requirements to stories.

That maps onto the hospital team's auditor question directly: who approved the requirement, and who approved the design, before any code was written. Opsera's pages also say every work order is traceable end to end, which is a vendor claim I have not tested.

For existing code, ForgeScore scores a repository across eight dimensions, including Trust Boundaries, System Gravity, Cognitive Load and Future-Proofing, and gives a NIST CSF 2.0 security grade from A to F. The docs say the grade is an input to human decisions and not a certification, and I would repeat that to any auditor.

Code generation happens in the Coding Agent, which works from approved stories in your linked repository and pushes a branch for a pull request, or in your own IDE over MCP. Opsera's software factory FAQ also describes a security agent that checks intent, requirements, architecture and stories as they are produced, which is where I would aim a pilot's questions. On the six checks, I found no certifications listed on the pages I read, so I asked for them.

How to Read a Compliance Badge Without Overreading It

A badge describes the vendor or the codebase, never the code the agent will write for you.

SOC 2 Type II is an auditor's report on a vendor's controls over a period.
ISO/IEC 42001 certifies an AI management system.
Neither certifies that the code an agent writes is safe.
A NIST CSF grade, like ForgeScore's, describes a codebase and not the vendor.

Ask for the report itself, check its scope, and match it to the product you will deploy.

How to Run the Six Checks as a Vendor Questionnaire

The checks are only useful if they turn into questions a vendor has to answer in writing. This is the version I would send to every tool on a shortlist, with one line per check:

Identity and access: which SSO and provisioning methods are supported, and which roles can change agent settings?
Data policy: what is retained, for how long, and is any of it used for training?
Where it runs: which components run in my network, and what leaves it?
Agent controls: what can an agent read, write or execute, and who approves the result?
Audit record: which events can I export, and in what format?
Certifications: can I see the report, its scope and its date?

Send the same six to each vendor and compare the answers side by side. The differences usually show up in the answers to the third and fourth questions, because those are the ones where a vendor has to say what its product does not do. For the hospital team, a clear "this does not run in your network" is more useful than a long feature list, since it saves a month of pilot work.

I would also keep the replies in one document. When an auditor asks six months later why a tool was chosen, a stored questionnaire with the vendor's own wording is a better answer than a memory of a demo.

How I Would Choose Based on Your Hard Constraint

If inference must stay inside your network, start with Factory or Tabnine and verify the claim in a proof of concept. If you must hold the encryption keys, look at Augment first.

If you are on GitHub and your gap is process and not tooling, set up Copilot's policies, audit log review and branch protection before you buy anything. And if auditors ask who approved a requirement and who approved the design, a pipeline with recorded approvals such as Forge answers a different question from any assistant on this list.

Where to Go From Here With Your Shortlist

The pattern across all six is that identity and data policy are mostly solved, deployment model is where the tools differ most, and approval records are the least developed area. Most of these vendors can show you who logged in and what was retained. Fewer can show you who approved the thing the agent built from.

My suggestion is to write down your one hard constraint, cut the list to two tools that meet it, and ask both for the same evidence pack: certification reports, a deployment diagram and a sample audit export. If approval records are on your list, the Forge documentation shows the stage and approval model in detail, so you can judge it before any call.

FAQ

Which AI code generation tool is the most compliant overall?

None of these pages supports a single ranking. Certifications differ in scope and in what they test, and some tools list none on the pages I read.

Does Privacy Mode or zero retention make a cloud tool safe for regulated code?

It limits retention and training. It does not change where processing happens, so a policy that requires an air gap still rules out cloud-only tools.

Is Forge a replacement for an AI coding assistant?

Forge is the lifecycle layer that works with the assistants your team already uses but not an AI coding agent itself.

Does a NIST CSF grade from ForgeScore count as certification?

No,The docs describe the A to F grade as an input to human decisions and not a certification, and it describes the codebase, not the vendor.

What should I ask for when a vendor lists SOC 2 Type II?

Ask for the report itself, check which systems and period it covers, and confirm that the product you will deploy is inside that scope.

Can Copilot's content exclusion fully hide a directory from the tool?

Not in every case. GitHub documents gaps in some editor modes, for symbolic links and remote filesystems, and for semantic information the IDE passes along.

Best AI Software Factories for Enterprise Application Development in 2026

Sundar Shyam Jha — Wed, 07 Oct 2026 16:41:26 +0000

TL;DR

An AI software factory moves a request through connected agent stages to a reviewed pull request, with people approving at set points. I read the public docs for five of them in October 2026: Forge, Factory, Augment Cosmos, Kiro and GitHub's Copilot cloud agent. They differ most on one question, which is whether a human signs off before any code exists. This guide defines the term, runs all five through four tests, and ends with demo questions you can reuse.

Getting Started: What an AI Software Factory Is

A coding assistant helps one developer inside one session. You type, it suggests, you accept or reject. A software factory looks after everything around that session: where the request came from, what spec it was built against, who reviewed it and what record it leaves.

Most vendors now use the word, and they mean slightly different things by it. So I stopped comparing feature lists and scored each platform on four tests instead:

What starts the work. A ticket, a prompt, a spec or a legacy repository.
Where a human approves. Before code exists, after it, or only at the pull request.
Where context lives. Whether the next run remembers what the last one decided.
Where agents run and what they leave behind. Your network or the vendor's, and how much of the trail you can export.

I did not benchmark any of these, so nothing here ranks speed or code quality. Everything below comes from each vendor's own docs and enterprise pages as they stood in October 2026.

To keep the tests concrete, I'll use one hypothetical team throughout: a platform group at a regional bank with a fifteen-year-old Java monolith, about forty developers and an audit team that asks who approved what. It is invented, but the questions it raises are the ones I hear from real enterprise teams.

How the Five Platforms Compare on the Four Tests

Before the detail, here is the shape of the field. Copilot's cloud agent and Factory start from tasks and put the human checkpoint at the end. Augment starts from events such as tickets and alerts, with checkpoints you configure. Kiro starts from a spec and gates it in the editor. Forge starts from intent and gates four stages before any code is written.

None of that makes one of them better. It tells you where each one assumes your process already works, which is the more useful thing to know before a demo.

GitHub Copilot Cloud Agent as the Baseline Most Teams Own

If your bank's code already lives on GitHub, the cloud agent is the lowest-change option, and its guardrails are more specific than I expected. According to GitHub's own risk documentation, only users with write access can trigger it. It pushes to a single branch, either the pull request's own branch or a new copilot/ branch, and it stays subject to branch protection and required checks.

It cannot mark a pull request ready for review, approve it or merge it, and the person who asked for the work cannot approve it either. Workflows do not run until someone with write access clicks Approve and run. By default it also runs CodeQL, checks new dependencies against the GitHub Advisory Database and runs secret scanning on its own output. Commits are signed, name the requester as co-author and link to the session log, and administrators get audit log events.

For our bank, that is a solid answer to "who merged this." What it does not give you is a stage before code. Work starts from an issue or a prompt, and the human checkpoint is the pull request. If the issue was vague, the review is where you find out.

Kiro Puts the Spec Inside the Editor

Kiro, from AWS, is the clearest spec-first tool in this group. A feature spec produces three files: requirements.md, design.md and tasks.md. In the requirements-first workflow you confirm the requirements before Kiro writes the design, and the design leads to a task list you can run one task at a time or all together. When you run everything, Kiro builds a dependency graph and runs independent tasks concurrently.

The detail I would watch is the Quick Spec path. It generates all three files in one pass with no approval gates. It is convenient, and it is the setting I would keep out of regulated work, because it removes the one stage that makes the tool interesting.

Specs run in the Kiro IDE and on the web, where the agent can implement the plan and open a pull request. I did not read Kiro's enterprise administration docs for this piece, so I am treating it as a strong spec workflow rather than a complete factory. For the bank, the open question is how that workflow scales across forty developers, which the public pages do not answer.

Factory Runs Agents Under Managed Settings

Factory's unit of work is the Droid. Its deployment documentation describes three patterns: cloud-managed, where Factory's cloud is the control plane and model traffic can go through your own gateways; hybrid; and fully airgapped, where Factory's cloud is not reachable at runtime. Droids run on laptops, CI runners, VMs, Kubernetes clusters and airgapped networks.

Governance is expressed as a hierarchy of managed settings covering model access, command policies, MCP allowlists, hooks, sandbox policy and retention. Droids emit OpenTelemetry metrics to collectors you own, and Factory lists SOC 2 Type II, ISO 27001 and ISO 42001 on the same pages.

What I did not find is an approved-spec stage before the agent starts. The controls describe what a Droid may do once work is assigned. If the bank's weakness is unclear requirements, they would have to build that stage themselves. If the weakness is control over what agents can touch, this is one of the most detailed runtime policy models I came across.

Augment Cosmos Runs Ticket-to-PR Loops You Configure

Augment describes Cosmos as the layer that connects agents, codebase context and workflows. Requests enter as tickets, pull requests or alerts, and each loop has a trigger, an outcome and a human checkpoint you define. The building blocks include Experts, which are task-specific agents, a Context Engine, a model router called Prism, and either isolated cloud VMs or a self-hosted daemon that runs agents on your machines while Cosmos stays the control plane.

Experts, environments and loops are versioned, and budget controls cap spend per automation or per user. Augment's security pages list SOC 2 Type II and ISO/IEC 42001 and say it never trains on customer proprietary data.

Augment also publishes a case study from its own engineering team and says the figures are observations, not a controlled experiment. I would read any vendor's internal numbers that way, and I will say the same about the figures in the next section. Its advice to start with a code review loop is sound, because a pull request gives you a clear trigger and a natural place for a person to look.

Forge Gates Four Stages Before Any Code Exists

Forge is the one I had to read most carefully, because it is built around the gap the other four leave open. The pattern so far is that nothing before the code is required to be approved. Copilot and Factory begin at a task. Augment begins at an event. Kiro has a spec stage but lets you skip its gates.

Forge's default New Build path runs Intent, PRD-Spec, Architecture, User Stories and Testing, then saves an Application Context snapshot. A modernization project adds an Assessment stage at the front, where Forge reads a Git repository, a local folder or a ZIP and reports the current state before anyone writes a goal. For our bank's monolith, that is the part I would test first.

Here is the number I found most useful. The docs say Intent, requirements, Architecture and User Stories each need an explicit Approve & Continue, while Testing and Assessment need none. Counting from the quick-start guides, that is four of five stages gated in the default New Build journey and four of six in the default modernization journey. All four gates sit before code. Tenants can switch optional stages on and off, so check it against your own configuration.

Two details in the approval model are easy to miss. Approval records a version without locking the artifact. And regenerating an upstream artifact clears the approvals downstream, so a changed requirement cannot quietly keep an old architecture sign-off. For an audit team, that second behaviour is the interesting one.

Code comes from the Coding Agent, which implements an approved user story in a linked Git repository. It pushes a forge/wo-{id} branch and opens a pull request when your Git provider allows it. The connector needs push and pull request permissions, and the run screen lets you skip the test phase or the AI review phase, so I would decide up front who may flip those. If your developers prefer their own editor, the same stories open in an IDE over MCP.

Opsera's own figures for Forge are vendor-reported and I have not verified them. Its site describes a cloud to on-prem Kubernetes conversion at Senao Wireless going from seven months to one week, and a Belcorp workload dropping from two to six weeks to about an hour. Its FAQ also says customer code and architecture data are not used to train foundation models. My demo question would be which stages are enabled in my tenant, since the docs note that policy can hide the optional ones.

How I Would Pick Based on Where Delivery Breaks

If nobody can explain the legacy system, start with a tool that begins with assessment. Forge's modernization journey opens with Assessment and a ForgeScore health report before any goal is set.

If the codebase is healthy and the pain is a pile of tickets, alerts and reviews, look at Factory or Augment, since both start from events and tasks.

If you are on GitHub and want the smallest change, turn on the Copilot cloud agent and tighten branch protection first. If you want specs in the editor and are not ready for a platform, try Kiro on one team.

One position I will defend: if your team has no written specs today, adding agents moves the bottleneck to the review queue. Pick the tool that makes you produce the spec, or build that habit before you buy anything.

Five Questions I Would Ask in Every Demo

Which stages need a human click, and which run without one?
If an upstream artifact changes, what happens to approvals downstream?
Where do the agents run, and what leaves my network?
Can I pull the full record for one change, from request to merge?
What stops an agent from reaching production credentials or deploy commands?

Where to Start With Your Own Shortlist

The common thread across all five is that the checkpoint moves earlier as the tool gets more spec-driven. Copilot checks at the pull request, Factory and Augment at configured gates around tasks, Kiro at the spec, and Forge at four stages before code. Which position is right depends on whether your delivery problems begin in requirements or in review.

My suggestion is to pick two tools that sit at different points on that line, run the same small change through both, and compare the record each one leaves. If you want to see the spec-first end up close, the Forge docs introduction walks through the New Build and modernization journeys stage by stage, which is the quickest way to check the approval behaviour yourself.

FAQ

Does a software factory replace Copilot or Cursor?

Forge runs alongside the assistants a team already uses and supplies the intent and context around them. Augment and Factory ship their own agents, so with those you are choosing between agent runtimes.

Do Forge's approvals lock an artifact once approved?

No, Approval records the current version and moves the journey forward. If you regenerate an upstream artifact, the approvals downstream of it are cleared.

Can an agent merge its own pull request on GitHub?

Not in Copilot's cloud agent. It cannot approve or merge, and the person who requested the work cannot approve it either.

Is Kiro's Quick Spec suitable for regulated teams?

I would not use it there. It generates requirements, design and tasks in one pass with no approval gates, which removes the review step regulated teams rely on.

Which of these can run fully airgapped?

Of the five, Factory documents a fully airgapped deployment. Augment's agents can run on your machines while the control plane stays with the vendor, so it sits in between.

How current is this comparison of the tools?

It reflects public pages read in October 2026. Vendors change these pages often, so confirm any detail your decision depends on.

7 AI tools for legacy modernization in 2026, and what 507 work orders say about picking one

Sundar Shyam Jha — Tue, 11 Aug 2026 15:23:44 +0000

Rewriting an existing system needs about four times more written "definition of done" per unit of work than building a new one. I got that from a public dataset of nine AI-assisted projects: eight modernizations averaged 1.5 acceptance criteria per story point, the one greenfield build averaged 0.4. If you are choosing an AI modernization tool this year, that ratio is a better buying question than any benchmark score.

Here is the method, then the seven tools, then how I would actually sequence a migration.

The number, and how I got it

SoftwareForge published a 2026 enterprise benchmark covering 507 work orders and 3,410 story points across nine initiatives, with the acceptance-criteria density listed per stack. Acceptance criteria are the checkable statements attached to a unit of work, things like "the endpoint rejects unauthenticated requests with 401" or "coverage is at or above 90%."

I divided story points by work orders to get the average size of one unit of change, then divided acceptance criteria by that to normalize. Small table, run it yourself:

Project	Story pts / WO	AC / WO	AC per story point
.NET Framework + WCF monolith to microservices	8.45	11.3	1.34
T-SQL to Aurora MySQL	6.46	10.4	1.61
T-SQL to PL/pgSQL	6.79	10.6	1.56
Legacy framework + jQuery to Vue 3	6.41	8.9	1.39
Java Spring in-place hardening (healthcare)	7.05	8.5	1.21
Java servlets to Node/TS + React	4.33	6.6	1.53
JavaScript to typed React SPA	3.55	9.0	2.54
.NET Core 2.1 (EOL) to .NET 8	2.79	5.0	1.79
Greenfield multiplatform + Terraform	7.93	3.0	0.38

Median for the eight migrations: 1.55. The greenfield project: 0.38.

Two honest caveats. There is one greenfield row, so this is a signal and not a law. And these are planning artifacts, not measured outcomes, so the density reflects how much someone thought needed pinning down, not how much turned out to matter. Useful reading, all the same: when you preserve behavior you cannot describe, the plan has to carry the description. When you invent behavior, you get to change your mind.

If you want to check your own backlog against this, the calculation is four lines:

import csv

with open("backlog.csv") as f:  # columns: story_points, acceptance_criteria
    rows = [r for r in csv.DictReader(f)]

sp = sum(float(r["story_points"]) for r in rows)
ac = sum(float(r["acceptance_criteria"]) for r in rows)
print(f"{len(rows)} work orders, {ac/sp:.2f} acceptance criteria per story point")

Under 0.5 on a migration backlog means your agents are guessing at behavior you never wrote down.

Why this is the buying question

Legacy modernization rarely goes wrong at the translation step. A converter turns a PERFORM loop into a for loop in an afternoon. No converter can tell you why that loop skips every third record when an account flag is set, because nobody ever wrote that rule anywhere except inside the loop.

Coding agents have the same blind spot, at higher throughput. In Stripe's rollout of Claude Code to 1,370 engineers, one team moved 10,000 lines of Scala to Java in four days against a ten-engineering-week estimate. Read the same page for the part people skip: their infrastructure lead describes the mental model that made it work, treating the assistant as a capable new engineer who knows every language but has no business context and no idea how things are done here. Speed came from the context they supplied, not from the model.

Without that context, the failures are quiet. DORA's 2025 report found AI adoption correlating with higher throughput and higher instability at the same time: more change failures, more rework. GitClear's 2025 code-quality analysis tracked duplicated blocks rising as AI-assisted commit volume rose. And in Stack Overflow's 2025 survey, the top frustration among developers using AI was output that is "almost right, but not quite," with debugging that near-miss costing more than writing it fresh.

The tool question, then, is not "can it generate Java from COBOL." All seven below can produce plausible target-language code. What separates them is what happens in the hours before generation starts.

The seven

I have grouped these by what they do first, because that is the actual difference.

1. SoftwareForge (Forge)

Disclosure up front: this list came out of research I did for SoftwareForge, and the dataset above is theirs. Judge the number on its method, not on my byline.

Forge starts with a repository scan called ForgeScore, an eight-dimension health assessment across security, architecture, performance and AI adaptability, run before any migration plan gets written. The output becomes a Living Specification, a versioned machine-readable document holding business objectives, functional requirements, security obligations and an explicit out-of-scope boundary. Agents then execute Work Orders generated from that spec, each carrying its own acceptance criteria and a link back to the requirement that authorized it.

Forge bets that the expensive discovery work should happen once, deterministically, rather than being repeated by every agent on every task. Their own writeup on modernizing without breaking business logic is more useful than the product pages if you want the reasoning.

Where it fits: regulated portfolios, multi-quarter migrations, anywhere someone will eventually ask which requirement authorized a specific line in production. Where it does not: a two-week framework upgrade. The planning layer is overhead you will not recover on small work.

2. GitHub Copilot app modernization

Microsoft ships modernization paths for Java and .NET as guided upgrade flows: assess the project, apply the upgrade, fix what breaks, iterate. The .NET modernization overview and the Java upgrade docs show the actual shape, and GitHub's own modernize legacy code tutorial covers the general pattern.

Strongest when the target is well-known and the gap is version drift rather than architecture. Framework and runtime upgrades, dependency remediation, Azure-bound refactors. This path assumes you already know what the system is supposed to do.

3. Amazon Q Developer transformation

AWS runs transformation as a defined job type rather than a chat: you point it at a Java or .NET codebase and it produces an upgrade plan and applies it, documented in the code transformation guide.

Same trade as the Microsoft option, on the other cloud. If your estate is already on AWS and the work is Java 8 or 11 moving forward, this is the shortest path. This gets narrower than it looks the moment your migration involves a database dialect change, which is exactly where the acceptance-criteria density in that table went highest.

4. IBM watsonx Code Assistant for Z

The mainframe case. IBM's product works COBOL through an explicit sequence: understand the application, refactor the business services, then transform to Java, with the option to stop after any stage.

Staging like that is the interesting part. Stopping after "understand" and shipping nothing is a feature, not a limitation, and it is the honest answer for estates where nobody currently knows what the system does.

5. Moderne and OpenRewrite

The deterministic option. OpenRewrite parses source into a lossless semantic tree and applies recipes, which are code, not prompts. Same input, same output, every run. Moderne is the commercial platform that runs recipes across many repositories at once.

I would put this first for anything mechanical and repeated: framework migrations, API deprecations, dependency bumps across 300 services. Recipes cannot infer intent, and Moderne does not pretend otherwise. When a recipe exists for your change, using an LLM instead is a worse trade.

6. Devin

An autonomous agent that takes a task and runs it to completion with little supervision. Independence is the whole value and the whole risk here, because a vague goal produces a confident implementation of the wrong thing.

Devin gets much better when it is fed bounded work with explicit in-scope and out-of-scope boundaries. Same claim as the rest of this post, from a different direction: the agent is not the variable, the brief is.

7. Mechanical Orchard

Behavior-first mainframe replacement. Rather than translating source, the approach observes what the running system actually does and builds a modern implementation to match that observed behavior.

Of everything here this is the slowest and most expensive, and for a 40-year-old system with no surviving documentation and no surviving authors, it is sometimes the only defensible one.

How I would actually sequence this

Nothing above works if you skip the step everyone skips.

Before any tool touches the code, write characterization tests. Michael Feathers named these in Working Effectively with Legacy Code, and the definition matters: a characterization test does not check that code does what it should. It records what the code currently does for real inputs, so every later change is measured against observed behavior rather than assumed intent. Writing one for an undocumented function is usually the fastest way to find a business rule that no design document mentions.

Then the order I would run:

Scan and score, so priority is defensible to a reviewer rather than convenient for whoever is free
Characterize the twenty modules carrying the most transaction volume
Take the deterministic wins first (recipes over prompts wherever a recipe exists)
Scope the rest into work orders small enough that one person can verify the acceptance criteria without re-reading the diff cold
Route each work order to the cheapest model that clears it

And be careful about the dependency layer, because it fails silently. There is no single command that audits a monorepo of independently managed services:

cd services/paymentservice
mvn dependency:tree > dep-tree-payment.txt
cd services/inventoryservice
mvn dependency:tree > dep-tree-inventory.txt
# repeat per service, then cross-reference each output against a CVE database

A single service tree runs several hundred lines. An agent adding a legitimate payment SDK can pull a vulnerable auth library four levels down and nothing in the pull request will say so.

The part the vendor decks leave out

You should expect less speedup than the demos suggest, at least at first.

METR ran a randomized controlled trial with experienced open-source developers on their own repositories and found they took 19% longer with AI tools while believing they had been sped up. Plenty of people quote that result as a permanent verdict, which is not fair to it. METR revisited the design in February 2026 and said plainly that developers are likely faster now, but that their newer data has selection problems severe enough that they will not put a number on it.

Carry both halves of that. Familiarity with the codebase reduces the gain, self-reported speedup is unreliable, and the honest current answer on magnitude is that nobody has a clean measurement.

Which brings it back to the ratio. The gain is not in the generation. Gains come from how much of the system's behavior you managed to write down before generation started. You can measure it on your own backlog this afternoon, and it does not require buying anything.

If your migration backlog is sitting under 0.5 acceptance criteria per story point, no tool on this list will save you.

Agentic software development: how autonomous agents are changing the SDLC

Sundar Shyam Jha — Tue, 21 Jul 2026 10:18:30 +0000

In July 2025, an AI coding agent at Replit deleted a production database during a code freeze. It wiped 1,206 executive records and 1,196 company records. The agent had been told, in plain language, not to touch production. It did anyway, then generated fake data to cover the gap.

That incident is the whole debate about agentic software development in one story. The capability is real. The judgment is not. And the gap between the two is where enterprise engineering leaders are now spending their attention.

This piece is for people who own delivery. I want to walk through what actually changes when agents stop being autocomplete and start participating across the lifecycle, where the real failure modes sit, and what a governed version of this looks like in practice.

From assistant to participant

For two years, "AI in the SDLC" mostly meant a smarter autocomplete inside the editor. That era is closing. TuringBots are becoming agentic, with autonomous agents collaborating across the full lifecycle toward end-to-end automation rather than sitting inside one tool.

The adoption curve backs this up. Around 84% of developers now use or plan to use AI tools, and more than half use them daily. On the benchmark side, agent performance on SWE-bench Verified rose from 1.96% in October 2023 to 78.4% by April 2026. The machines got good at closing well-scoped tickets fast.

Here is the part the benchmark charts miss. Getting good at writing code was never the bottleneck in enterprise delivery. The bottleneck was coordination, ambiguity, and lost knowledge. Agents that write code faster do not fix any of those. In some cases they make them worse.

What agents change at each stage

The best way to describe agentic development is not "agents do the work now." It is "the sequence and ownership of work move around." A useful frame is where an agent enters the lifecycle and what it receives when it gets there.

Requirements

Instead of a human writing tickets after the fact, an agent parses business intent into structured requirements with acceptance criteria attached. The value is not speed. It is that ambiguity gets resolved at the specification stage, where a fix costs minutes, instead of surfacing during code review, where it costs a sprint.

Architecture

Design constraints get captured before code starts, as machine-readable blueprints rather than a diagram in a wiki that goes stale by the second sprint.

Development

A coding agent receives a work order that already carries the requirement ID, the relevant architecture, security constraints, and acceptance criteria. The difference between a prompt and a work order is the difference between a prototype and a production workflow.

Testing

Agents generate test suites from the specification in parallel with the code, rather than a QA engineer reconstructing intent weeks later.

Governance

Policy checks and audit trails run continuously, built into every artifact, instead of being reconstructed at a release gate under pressure.

Notice what ties those together. It is not the model. It is whether each stage hands the next stage enough structured information to act correctly. That single property decides whether agentic development helps you or buries you.

Where it actually breaks

I want to be specific here, because most coverage of agentic software development is either hype or fear. The real failure modes are well documented, and they aren’t about model intelligence.

Context is the only control surface, and it degrades

Large language models are stateless and non-deterministic. Every decision they make comes from the tokens currently in the window. Practitioners have named the point where quality falls off: the "dumb zone," which often begins around 40% of context usage, well before the window is "full." More tokens don’t mean better outcomes. Better tokens do. When an agent loses the thread of the original intent halfway through a build, you get code that compiles and misses the requirement.

Productivity is not progress

This is the finding senior engineers feel in their bones. Across large developer surveys, AI increases the amount of code shipped, but code churn increases even more, and teams rework agent output repeatedly. Brownfield codebases suffer worst. One research team put the mechanism plainly: agents are biased toward producing more code because generation is cheap, and toward local fixes because global redesign is expensive in tokens. That combination is a tech-debt factory if you let it run unsupervised.

Human review becomes the bottleneck

If an agent can produce ten plausible patches an hour, the rate-limiting resource is human attention. It gets worse. AI review comments run about 29.6 tokens per line of code versus 4.1 for human reviewers, because agents explain from first principles every time instead of leaning on shared project knowledge. You have not removed the review burden. You have multiplied it.

The Stack Overflow engineering team reached the same practical conclusion in January 2026: break tasks into the smallest possible chunks, keep commits small enough to actually review, and treat "long-running autonomous agent" claims as a sales tactic.

Their phrasing was clear-eyed. Review AI-assisted code the way you would review any human commit, knowing there will be more issues in it.

The number that should shape your strategy

Gartner projects that more than 40% of agentic AI projects will be canceled by the end of 2027, mostly due to escalating cost, unclear ROI, or weak risk controls.

Read alongside the fact that only around a quarter of organizations have scaled an agentic system in production, the message is not "avoid this." The message is that the teams who survive the cull will be the ones treating agents as engineering infrastructure with governance attached, not as a feature they switched on.

There is a matching upside number worth holding next to it. Gartner also finds roughly 25 to 30% productivity improvement when AI is applied across the full lifecycle, versus about 10% when it is confined to code generation.

PwC's research on 377 technology leaders found that teams using GenAI across six or more SDLC stages release nearly twice as often. The return lives in breadth and coordination, not in typing speed.

What a governed version looks like

So the practical question is not whether to use agents. It is how to give them enough structure that they help without shipping debt or deleting your database.

This is the design problem SoftwareForge's Forge platform was built around, and it is worth using as a concrete example because the mechanics are specific rather than aspirational.

Forge treats the specification as the system of record. Business intent becomes a Living Specification: a versioned, machine-readable document that carries objectives, requirements, security obligations, and compliance constraints forward through every handoff.

Agents inherit that full context instead of starting from a blank prompt, which is the direct fix for the "dumb zone" problem.

Forge calls the failure mode context rot, and the persistent context layer exists specifically to stop downstream agents from drifting from decisions made earlier in the build.

Execution runs through Work Orders. Each one is human-auditable and carries the intent, constraints, and acceptance criteria from the specification, so an agent receives structured context rather than an isolated instruction. No agent action reaches production without passing through a Work Order a human can authorize. That is the mechanism that would have stopped the Replit scenario: the destructive action needed an approval it never had.

If you run regulated systems, this is where the argument turns financial. Forge maps every agentic action to policy and keeps an immutable audit trail retained for seven years.

When an auditor asks how a specific line of code traces back to a requirement, you have a decision trail instead of a Slack archaeology project.

The platform reports 66% of rework eliminated, 83% faster delivery, and zero architectural drift, all traceable to the intent captured at the start.

If your teams are already generating code faster than they can safely review it, the missing layer is structured context and governed execution, not a better model. You can see how Forge structures that here.

Where this leaves you

Agentic software development is real, and it is not magic. The agents are genuinely capable of closing scoped work fast. They are also stateless, non-deterministic, and blind to your production environment unless you feed them the structure to see it.

The teams getting durable value are not the ones with the cleverest prompts. They are the ones who decided early that speed without governance just ships debt faster, and who built the specification, context, and audit layer to match.

That is the difference between an agent that clears your backlog and one that quietly refills it.

If you are moving from experimentation to real delivery this year, start by asking one question of any agentic setup you evaluate: what does the agent receive when it starts, and who approves what it does before it reaches production. If the answer is "a prompt" and "no one," you already know how that ends. If you want to see the governed version in practice, book a walkthrough with SoftwareForge and bring your messiest legacy repo.

AI-SDLC Explained: The AI-Driven Software Development Lifecycle

Sundar Shyam Jha — Tue, 14 Jul 2026 11:15:58 +0000

Ask ten engineering leaders what "AI-SDLC" means and you'll get ten slightly different answers, and most of them will be describing an AI assistant that autocompletes code faster.

That's part of it, but it's the smallest part. The real shift is that the stages themselves are starting to reorganize around what AI can and can't be trusted to do without a human checking its work.

An AI-driven SDLC, in the sense the term is actually used by teams running it in production, means AI participates across planning, coding, testing, review, and deployment, but every one of those participations is governed, meaning it's authorized, logged, and traceable back to a specific business requirement.

Take away the governance and you don't have an AI-SDLC. You have a fast way to generate code that a human still has to fully re-verify before it ships, which often cancels out the time savings.

Why the old SDLC model breaks under AI-generated code volume

The traditional software development lifecycle assumes a roughly constant, human-paced rate of code production.

Requirements gathering, design, coding, testing, deployment, maintenance, each stage sized around how fast a person can reasonably write and think through code.

AI breaks that assumption at the second stage. A developer using an AI coding assistant can produce in an hour what used to take a day. Everything downstream, the review, the testing, the security scan, the audit trail, was never built to absorb that volume.

Katie Norton at IDC named this directly: “as AI increases the speed and scale of code generation, organizations need stronger ways to validate what is being built, what risks it introduces, and whether it meets policy requirements before code progresses.”

That's the exact bottleneck teams hit six months into adopting Copilot or Cursor at scale.

Code generation stopped being the constraint.

Verification became the constraint. And most teams didn't rebuild their SDLC to reflect that, they just added more AI on top of a review process designed for a slower era.

What actually changes at each stage of the lifecycle

Here's how each phase evolves when AI moves from assistant to active contributor.

1. Requirements and planning

This is the stage most AI-SDLC pitches gloss over, and it's the one that determines whether everything downstream works.

If the requirement lives only in someone's head or a Jira ticket with three lines of context, an AI agent generating code against it is guessing.

The pattern that actually works is capturing intent as a structured, versioned artifact before generation starts, something a PRD, architecture doc, and compliance constraints can all attach to.

SoftwareForge frames this as a Living Spec, described as a versioned, machine-readable specification for every mission, so agents inherit full intent, context, and compliance instead of starting from a blank slate.

Whatever tool you use, this is the step that determines whether AI output actually matches what the business needs, or just what a vague prompt produced.

2. Coding

This is where most people's mental model of "AI-SDLC" stops, and it's genuinely the least interesting part now.

Every major coding assistant handles this reasonably well. The differentiator isn't which model writes better code anymore. It's whether that code inherits context from the previous stage or starts fresh every session, which is why context loss is the single most common complaint from engineers who've used AI assistants on large, unfamiliar codebases for more than a few weeks.

3. Review and compliance

This is the stage that determines whether an AI-SDLC is real or just marketing.

Every AI-generated change needs a record of what changed, why, and whether it clears policy before it merges, not after. Katie Norton described the mature version of this as bringing architecture analysis, security scanning, and compliance checks into a coordinated workflow that supports more autonomous execution while preserving auditability and governance across the software lifecycle.

SoftwareForge's version of this concept, Work Orders, ties every agentic action to a human-auditable record, which matters most in exactly the moment nobody plans for: the incident review six months later when someone asks why a specific line of production code exists.

4. Testing and deployment

AI can generate tests faster than a human, but the harder problem is knowing whether the tests actually cover what the requirement demanded, not just what the code happens to do. This loops back to the requirements stage. If intent was captured properly at the start, test coverage can be checked against it. If it wasn't, you're testing that the code does what it does, which tells you nothing about whether it does what it should.

5. Maintenance and modernization

This stage gets almost no attention in AI-SDLC discussions, and it's arguably where the biggest time savings actually show up. Most enterprise engineering time doesn't go into net-new features. It goes into safely changing systems built years ago by people who've since left the company.

Roman Vorel, a Fortune 100 technology executive, described what's actually lost in these systems: legacy software turns into a black box, and restoring the context around how it works is what turns it back into a usable enterprise asset instead of a growing liability.

An AI-SDLC that only covers new code and ignores the legacy estate is solving maybe a third of the actual problem enterprise teams have.

A concrete example of how this plays out on a real team

Take a mid-size healthcare software company adding a new patient scheduling feature while also carrying HIPAA compliance obligations across an older claims processing system. Under a traditional setup, the new feature gets built fast with an AI assistant, then sits in a security queue for two weeks because nobody can quickly confirm it doesn't touch protected health data in a way that violates policy.

The claims system, meanwhile, barely gets touched because the one engineer who understood it left months ago, and every change carries unknown risk.

Under a governed AI-SDLC, the scheduling feature gets built against a spec that already encodes the HIPAA constraints, so the compliance check is confirming something the system flagged during generation, not discovering it cold at review time.

The claims system gets scanned and scored first, so the team knows exactly which functions touch sensitive data before an AI agent or a human ever proposes a change to them. Venkat Gopalan at Belcorp described wanting exactly this outcome from an AI-driven SDLC: “acceleration to market with measurable business outcomes, freeing people up from grunt work for higher-value work, turning weeks of effort into minutes with an enterprise-grade approach.” The point is that the whole cycle, from requirement to production, stops losing time at the handoffs.

The gap between "AI writes code fast" and "AI-SDLC delivers outcomes"

Srikrishnan Ganesan, CEO of RocketLane, put this gap in plain terms: AI can generate code in minutes, but turning it into real enterprise outcomes still takes weeks, and closing that gap means anchoring every artifact to intent and keeping governance inline instead of added on afterward.”

That gap, weeks of translation work between "code exists" and "code is a shipped, compliant, business outcome," is the actual thing an AI-SDLC is supposed to close. If your current setup only speeds up the typing part, you haven't adopted an AI-SDLC. You've adopted a faster typewriter.

AI has given every developer superpowers, but code generation without enterprise-grade governance limits how much of that power can actually be used, which is why making AI-generated code secure, compliant, and auditable by design matters as much as the generation itself.

What to check before you call your setup an AI-SDLC

Three honest questions, before anyone on the team starts using the term.

Can you trace any AI-generated production change back to the requirement that justified it, six months later, without digging through Slack history?
Does compliance checking happen during generation, or only after code is already written and someone has to catch problems manually?
And does your legacy codebase get the same governance as new code, or is AI only touching greenfield work while the oldest, riskiest systems stay untouched because nobody trusts an AI agent near them yet?

If the honest answer to any of those is no, you're running fast code generation with a traditional SDLC wrapped around it, which is a perfectly reasonable place to be. It's just not the same thing as an AI-SDLC, and knowing the difference matters when you're deciding what to fix next.

Where this leaves teams evaluating an AI-SDLC platform

This category is real, but the term gets used loosely enough that it's worth pressure-testing any vendor's claim against the five stages above rather than taking a demo at face value.

SoftwareForge built its Forge platform specifically around carrying intent, context, and compliance from a first prompt through production, reporting 66% of rework eliminated and delivery running 83% faster with zero architectural drift across customer deployments, figures worth validating against a pilot on your own codebase rather than accepting outright, but directionally aligned with what happens when governance stops being rebuilt from scratch at every stage handoff.

If you're trying to figure out where your own team's biggest time loss actually sits, requirements gathering, review bottlenecks, or the legacy code nobody wants to touch, that's worth measuring before picking a tool.

SoftwareForge offers a free scan that scores your existing codebase across eight dimensions of technical debt, which is a reasonable first step regardless of which platform you end up choosing. You can get your tech debt score here and see where your own AI-SDLC gap actually is.