From AI Coding Assistants to Software Factories: How Engineering Teams Are Automating the Entire SDLC

AI coding assistants changed how developers write code. The next shift is changing how software gets delivered.

For years, AI-assisted development had a relatively simple workflow: a developer writes a prompt, receives a code suggestion, reviews it, and decides whether to use it.

That interaction is changing.

Modern coding agents can inspect repositories, modify multiple files, execute commands, run tests, investigate failures, and open pull requests. More importantly, engineering teams are beginning to connect these capabilities to the wider software development lifecycle (SDLC).

The result is a different operating model: instead of using AI only during implementation, teams are introducing agents into requirements analysis, planning, design, development, testing, code review, security, and maintenance.

This evolution is often described using terms such as AI-native engineering, agentic software development, and software factories.

But what does a software factory actually look like? Which parts of software delivery can agents handle? And what still requires human engineering judgment?

1. From code completion to software delivery

The first generation of AI coding assistants focused primarily on helping developers write code faster.

A typical interaction looked like this:

1. A developer opens a source file.
2. The assistant suggests a function or code block.
3. The developer accepts, modifies, or rejects the suggestion.
4. The developer continues working.

This model improves individual productivity, but the developer remains responsible for almost every other activity: understanding requirements, locating the right files, running tests, debugging failures, reviewing changes, and preparing releases.

Coding agents extend the interaction.

Rather than suggesting the next few lines, an agent can receive a task such as:

Add password reset functionality to the application, including API endpoints, email notifications, validation, tests, and documentation.

It can inspect the repository, identify relevant components, plan changes, modify files, run tests, and iterate when something fails.

The developer is no longer approving every code suggestion. Instead, they are supervising a task that may involve dozens of operations.

The distinction is important:

This does not mean every coding assistant has become fully autonomous. Products differ in their permissions, execution capabilities, and supported workflows. The distinction describes a shift in interaction patterns, not a universal product classification.

2. What is a software factory?

A software factory is an organized system for producing and maintaining software through repeatable processes, standardized tools, automation, and quality controls.

The concept existed long before generative AI. Large engineering organizations already used CI/CD pipelines, automated testing, reusable templates, infrastructure automation, and standardized development environments.

What changes with agentic AI is the amount of cognitive work that can be incorporated into those processes.

Traditional automation follows predefined rules. For example, a CI pipeline can run tests whenever a pull request is opened.

An AI agent can perform a less rigid task: investigate why a test failed, inspect the relevant code, propose a fix, and create a new pull request.

A software factory combines these capabilities into a coordinated delivery system.

A simplified architecture looks like this:

Product idea / Business requirement
              |
              v
      Requirements agent
              |
              v
       Planning agent
              |
              v
       Design / Architecture
              |
              v
      Implementation agent
              |
              v
        Testing agent
              |
              v
       Review / Security
              |
              v
       Human approval
              |
              v
       Deployment pipeline
              |
              v
      Monitoring / Feedback
              |
              +------> New tasks and improvements

This is a conceptual workflow, not a requirement to deploy one agent for every stage. A single agent, multiple specialized agents, or conventional automation may be more appropriate depending on the task.

The defining characteristic is that work moves through a structured system with explicit responsibilities and validation points.

3. The entire SDLC is becoming an automation surface

To understand the shift, it helps to examine each stage of software development separately.

3.1. Requirements: turning ideas into execution-ready specifications

Software projects often begin with incomplete requirements.

A stakeholder might request:

Add a dashboard that shows customer performance.

This is not yet a sufficient specification. Developers need to understand:

• Which customers?
• Which performance indicators?
• What time period?
• Which data sources?
• What permissions apply?
• What should happen when data is missing?
• How will success be measured?

A requirements agent can help transform an initial request into a structured specification.

It can:

• Ask clarifying questions.
• Identify missing requirements.
• Search existing documentation.
• Retrieve relevant product decisions.
• Detect potential conflicts.
• Draft acceptance criteria.
• Identify dependencies and risks.

For example, it might produce:

Feature: Customer performance dashboard

Acceptance criteria:

• Users can filter results by date range.
• Only authorized users can access customer financial data.
• Revenue and order volume are calculated from approved data sources.
• Empty results display a defined empty state.
• Dashboard loading time remains below the agreed threshold.

The agent does not decide what the business should build. It helps make the requested outcome explicit enough for implementation and testing.

This is particularly valuable because vague requirements create downstream problems. An implementation agent cannot reliably satisfy constraints that were never defined.

3.2. Planning: breaking large tasks into manageable work

Once requirements are clear, the work needs to be organized.

A planning agent can analyze the codebase and propose a sequence of implementation tasks.

For example, the dashboard might require:

1. Database changes.
2. Backend API development.
3. Authentication and authorization.
4. Frontend components.
5. Data visualization.
6. Automated tests.
7. Documentation.

It can also identify dependencies. The frontend may depend on an API contract, while the API depends on a database migration.

The resulting plan can become tickets or implementation tasks assigned to agents or developers.

This is where context becomes important. Planning against an abstract description is different from planning against the actual repository, architecture, existing APIs, and project conventions.

Atlassian's October 2026 account of its AI-native SDLC work emphasizes grounding planning in organizational and codebase context rather than starting from an isolated prompt. Its approach connects code, documentation, decisions, and work items to provide agents with a more complete picture of the system.

The practical lesson is straightforward: an agent needs to understand the project before it can plan changes responsibly.

3.3. Design and architecture: exploring solutions before implementation

Architecture is more difficult to automate than repetitive implementation because it involves trade-offs.

An agent can still contribute by:

• Comparing possible designs.
• Identifying existing architectural patterns.
• Finding dependencies between components.
• Drafting API contracts.
• Producing architecture diagrams.
• Highlighting security and scalability concerns.
• Identifying compatibility risks.

Consider a team introducing a notification service.

An agent could compare synchronous API calls, asynchronous queues, and event-driven architecture. It could examine the existing system and identify which option aligns with current infrastructure.

However, the final decision depends on business priorities, reliability requirements, operating costs, organizational constraints, and long-term maintenance.

The agent can prepare the decision. The engineering team remains accountable for it.

3.4. Development: implementing the approved changes

Implementation is currently the most visible application of coding agents.

A development agent can:

• Read and modify source files.
• Create new components and functions.
• Implement API endpoints.
• Update database schemas.
• Refactor existing code.
• Add unit and integration tests.
• Update documentation.
• Run development commands.
• Create branches and pull requests.

The important change is that the agent can work across multiple files and interact with the development environment.

This makes task-level delegation possible.

Instead of asking an agent to write a function, a developer can assign a bounded issue with acceptance criteria and repository-specific instructions.

The quality of the result still depends on the specification, available context, tool permissions, and validation process.

3.5. Testing: turning verification into a continuous activity

As code generation becomes faster, testing becomes even more important.

A development agent can generate code quickly, but speed does not guarantee correctness.

Testing agents can help with:

• Unit test generation.
• Integration test creation.
• Regression testing.
• Edge-case discovery.
• Test failure analysis.
• Reproducing reported bugs.
• Test coverage analysis.

For example, after implementing a payment endpoint, an agent could test:

• Valid payment requests.
• Invalid amounts.
• Missing authentication.
• Duplicate requests.
• Network failures.
• Unauthorized access.
• Unexpected payment provider responses.

A stronger workflow does not simply ask the agent whether its implementation works. It executes independent tests and checks their results.

This distinction matters because an agent can misunderstand its own implementation or generate tests that only confirm the behavior it has already written.

Testing should therefore include independent checks, representative test data, and clear acceptance criteria.

3.6. Code review: managing the growing volume of changes

More generated code means more changes to inspect.

This creates a potential bottleneck: even if agents can implement tasks faster, human reviewers may not be able to examine every change at the same speed.

Review agents can inspect pull requests for:

• Logic errors.
• Inconsistent implementation patterns.
• Missing tests.
• Potential regressions.
• Security vulnerabilities.
• Performance problems.
• Violations of architectural rules.

GitLab's July 2026 release illustrates this direction. Its Security Review Flow analyzes merge requests for issues such as authorization failures, information disclosure, business-logic errors, and race conditions. GitLab states that the flow does not approve changes on its own; a human retains the final decision.

This is an important design principle: automated review can increase coverage, but high-impact changes still need accountable approval.

3.7. Security: integrating DevSecOps into agent workflows

Security should not be treated as a final checkpoint after implementation.

An AI-native development workflow can integrate security analysis throughout the lifecycle.

Agents can help:

• Inspect dependencies for known vulnerabilities.
• Identify exposed credentials.
• Review authentication and authorization logic.
• Analyze suspicious code changes.
• Suggest dependency upgrades.
• Investigate security findings.
• Generate remediation pull requests.

Traditional security tools remain essential. Static analysis, dependency scanning, secret detection, and policy enforcement provide deterministic checks that complement model-based reasoning.

The strongest approach combines both.

An agent may understand the context of a business-logic vulnerability, while a conventional scanner can reliably detect a known vulnerable package version.

GitLab's 2026 product updates provide an example of this combination: agentic security review, dependency remediation, existing approval gates, and audit events are brought into the development workflow.

3.8. Deployment and operations: connecting development to production

The SDLC does not end when code is merged.

Software must be deployed, monitored, maintained, and improved.

Agents can participate in operations by:

• Summarizing deployment failures.
• Investigating application logs.
• Identifying anomalies.
• Correlating incidents with recent changes.
• Suggesting rollback or remediation steps.
• Preparing incident reports.
• Creating follow-up engineering tasks.

For example, suppose a service experiences a sudden increase in response time after deployment.

An operations agent could inspect recent deployments, examine traces and logs, compare performance metrics, and identify likely causes.

It could prepare a remediation proposal or create a pull request.

However, production actions require stronger controls than ordinary development tasks. Rollbacks, database changes, infrastructure modifications, and customer-impacting operations should be governed by explicit policies and approval requirements.

4. What does an agentic software factory look like in practice?

Let's consider a practical example.

A product team wants to add a subscription management feature to an existing web application.

In a conventional workflow, the product manager writes requirements, developers estimate and implement the feature, testers verify it, reviewers inspect the changes, and DevOps handles deployment.

An agentic workflow can distribute some of these responsibilities across specialized agents.

The agents do not need to operate as a fully autonomous team.

Some tasks can be triggered automatically by workflow events. Others can be assigned by developers. Some require explicit human approval before proceeding.

The objective is not to eliminate every handoff. It is to make routine work more consistent and reduce the amount of manual coordination required.

5. Real-world signals: the transition is already underway

The idea of an AI-powered software factory is no longer purely theoretical. Several developments in 2026 illustrate different parts of this transition.

OpenAI: engineering around agents rather than manual coding

In February 2026, OpenAI published an account of an internal experiment in which Codex was used to build and ship an internal software product without manually written code.

The team reported approximately one million lines of code across the application, infrastructure, tests, documentation, and internal tooling, with roughly 1,500 pull requests opened and merged over five months.

The most important part of the account was not the code volume. It was the change in engineering work.

The team focused on making the repository understandable to agents, creating usable development environments, exposing logs and metrics, and establishing feedback loops.

When agents struggled, the response was generally to improve their environment or capabilities rather than simply repeat the instruction.

This is an example of harness engineering becoming a core engineering activity.

GitLab: agentic automation across DevSecOps

GitLab's July 2026 release expanded agentic automation beyond code generation.

Its updates included:

• Dependency vulnerability remediation.
• AI-powered security review.
• Multi-step agentic workflows.
• Custom flows triggered by GitLab events.
• Audit events for AI-assisted actions.
• Organization-level controls for agent behavior.

This demonstrates how agents can be integrated into existing software delivery infrastructure rather than operating as isolated coding assistants.

Anthropic: the changing software development lifecycle

Anthropic's 2026 Agentic Coding Trends Report examines how software development is shifting from writing code toward coordinating agents that perform more implementation work.

It highlights changes in engineering roles, multi-agent coordination, human-AI collaboration, and the expansion of agentic coding beyond engineering teams.

The report also emphasizes the gap between early experimentation and organization-wide adoption, particularly around oversight, quality, and security.

Atlassian: connecting planning, development, and review

In October 2026, Atlassian described its AI-native SDLC direction as a connected system spanning planning, development, review, and maintenance.

Its approach emphasizes shared organizational context, coordination between agents, and measurement of outcomes.

Atlassian reported that 94% of engineering leaders in its 2026 AI SDLC study said their teams were already using AI, while only 6% said they had systems to scale and govern it across the organization.

These are survey figures reported by Atlassian, not universal measurements of the industry. Nevertheless, they illustrate a recurring challenge: adoption is easier than operationalizing AI across an entire lifecycle.

6. Why automating the SDLC does not automatically make software better

A software factory can increase throughput while also increasing the volume of defects.

If an agent generates more code than a team can review, the bottleneck moves rather than disappears.

Several risks deserve attention.

The review bottleneck

More implementation output creates more pull requests, tests, and architectural decisions to inspect.

If review capacity remains unchanged, work accumulates.

Teams need automated checks, risk-based review, clear ownership, and better ways to identify high-impact changes.

Context fragmentation

An agent may understand a code file but not the architectural decision that explains why it was written that way.

Without access to relevant documentation, product decisions, dependency relationships, and project conventions, it can produce locally reasonable but globally incorrect changes.

Repository instructions, structured documentation, retrieval systems, and connected project context can reduce this problem.

Technical debt at higher speed

Agents can reproduce existing patterns, including poor ones.

They may introduce unnecessary abstractions, duplicate logic, inconsistent error handling, or excessive dependencies.

The ability to generate code quickly makes architectural consistency and maintenance more important, not less.

False confidence in automated testing

An agent can write a test that passes while missing the actual business requirement.

For example, a test may confirm that a payment endpoint returns a successful response without verifying whether the correct amount was charged.

Testing must validate outcomes, not merely confirm that generated code behaves as expected.

Security and excessive autonomy

Agents that can access repositories, credentials, deployment systems, and external services introduce new security concerns.

A development agent should not automatically inherit unrestricted production access.

Least privilege, isolated execution, approval checkpoints, audit logs, and credential management remain essential.

These risks explain why a software factory needs more than agents. It needs a reliable execution environment, governance, observability, and independent quality controls.

7. How should engineering teams adopt an AI-native SDLC?

A complete transformation does not need to happen at once.

A practical adoption strategy is incremental.

Phase 1: Automate bounded, verifiable tasks

Start with work that has clear inputs and outputs:

• Writing unit tests.
• Updating documentation.
• Fixing small bugs.
• Explaining unfamiliar code.
• Resolving straightforward dependency updates.
• Preparing pull request summaries.

These tasks provide opportunities to measure reliability without granting broad autonomy.

Phase 2: Connect agents to the development workflow

Give agents access to the tools and context they need:

• Version control.
• Issue tracking.
• Documentation.
• CI pipelines.
• Test environments.
• Relevant development tools.

Define what each agent can read, modify, execute, and approve.

Phase 3: Introduce task-level delegation

Move from isolated prompts to complete, well-scoped engineering tasks.

For example:

Implement the requested API endpoint, add unit and integration tests, run the relevant test suite, and open a pull request with a summary of the changes and known limitations.

The agent should return verifiable evidence, not just a description of its work.

Phase 4: Automate workflow transitions

Once individual tasks are reliable, connect agents to workflow events.

Examples:

• A new issue triggers requirements analysis.
• An approved specification triggers implementation planning.
• A pull request triggers code review.
• A failed pipeline triggers failure investigation.
• A security finding triggers remediation preparation.

Human approval should remain in the workflow where business, security, or production risk requires it.

Phase 5: Measure the entire delivery system

Do not evaluate the transformation using code volume or number of agent sessions alone.

Measure outcomes such as:

The DORA metrics provide a useful foundation for measuring software delivery performance. They help teams evaluate the delivery system rather than treating the number of generated lines as a productivity measure.

8. The engineer's role is changing, not disappearing

The move toward software factories changes where engineering effort is concentrated.

When agents take on more implementation and coordination work, engineers can spend more time on:

• Defining requirements.
• Designing system architecture.
• Breaking down complex problems.
• Evaluating agent-generated changes.
• Improving development environments.
• Establishing security and quality controls.
• Managing production reliability.
• Making decisions involving business trade-offs.

This does not mean that understanding code becomes unnecessary.

Engineers still need enough technical depth to identify incorrect assumptions, evaluate architectural decisions, recognize security risks, and understand the consequences of changes.

In fact, higher automation can make technical judgment more valuable because mistakes can propagate faster.

The strongest engineers will not necessarily be those who write the most code or delegate the most tasks. They will be those who can define the right problem, build reliable workflows, and verify that the resulting software actually works.

9. The software factory is a system, not a collection of agents

The most common mistake is to think that building an AI-native engineering organization means assigning a separate agent to every SDLC stage.

That can create unnecessary complexity.

A better starting point is to identify the actual bottlenecks in the existing delivery process.

If requirements are unclear, adding a coding agent will not solve the problem.

If tests are unreliable, generating code faster will increase risk.

If code review is already overloaded, more implementation capacity may simply create a larger backlog.

If agents lack project context, adding more agents will not improve their understanding.

The right architecture combines agents, conventional automation, human judgment, and measurable quality gates.

A software factory is not autonomous because it has many agents. It is effective because work moves through a controlled system where each stage has clear inputs, outputs, responsibilities, and verification.

Conclusion: from writing software to engineering its production system

AI coding assistants introduced a new way to interact with source code. Coding agents extended that interaction into multi-step implementation. The next evolution connects these agents to the broader software development lifecycle.

Requirements can be clarified, tasks can be planned, implementations can be generated, tests can be executed, changes can be reviewed, and operational issues can be investigated within connected workflows.

But automation does not remove the need for engineering discipline. It increases the importance of specifications, context, architecture, independent verification, and governance.

The software factory of the future will not simply generate more code. It will coordinate people, agents, tools, and automated systems to deliver software with measurable quality and controlled risk.

The competitive advantage is not having an agent for every task. It is designing a delivery system in which agents can complete useful work reliably.

Sources and further reading

1. OpenAI — Harness engineering: leveraging Codex in an agent-first world — A detailed engineering account of agent-driven development, repository legibility, feedback loops, and changing engineering responsibilities.
2. Anthropic — 2026 Agentic Coding Trends Report — Research on changes to the SDLC, multi-agent coordination, and human oversight.
3. GitLab — GitLab 19.2 brings governed agentic automation to the backlog AI coding creates — Examples of agentic workflows, security review, dependency remediation, and governance.
4. Atlassian — Bringing the AI-native SDLC from playbook to production — How connected context and agents can support planning, development, review, and maintenance.
5. DORA — Software delivery performance — Research and measurement framework for evaluating software delivery performance.
6. OpenAI — Building an AI-native engineering team — Practical guidance on integrating coding agents across planning, implementation, testing, review, and operations.
7. Microsoft Research — Agentic Coding in the Wild — Production-scale research into the workload patterns of AI coding agents.