The agentic software development life cycle, or agentic SDLC, is an emerging software-delivery model in which AI systems move beyond passive code assistance and become active participants in multistep engineering work.
These agents may:
Explore repositories Analyze issues Create implementation plans Generate and modify code Run tests and linters Prepare documentation Open pull requests Address technical debt Monitor systems Coordinate with other specialized agents Thoughtworks argues that the shift must be understood as an organizational and operating-model transformation, not merely a tooling upgrade. Its framework identifies four foundational elements: A multi-agent system composed of agents specialized for different engineering tasks
A knowledge network containing persistent, historical, and temporary organizational context Value-stream design that aligns teams with products and business outcomes Governance that establishes guardrails, accountability, auditing, reliability, and cost controls
Thoughtworks also predicts several changes to engineering organizations:
Agents will evolve from passive tools into active team contributors. Software engineering will remain nondeterministic because agents can make mistakes, lose context, and produce plausible but incorrect work. Engineers will move from direct code production toward architecture, prioritization, review, auditing, and orchestration. New roles may emerge, including knowledge architects, agentic architects, and agent-reliability engineers. Some specialized development roles may consolidate into broader full-stack or product-engineering positions. Smaller, stream-aligned teams may become more autonomous as agents supply reusable knowledge and self-service capability. Governance will increasingly move from humans reviewing every change to humans supervising the reliability of the overall agentic workflow. Junior-engineer development will require new methods because routine learning tasks may be performed by AI. Current software-development platforms already demonstrate parts of this model. GitHub documents a cloud coding agent that can independently inspect a repository, plan work, fix defects, implement incremental features, improve test coverage, update documentation, address technical debt, execute tests in an isolated environment, and prepare changes for human review. GitHub also supports specialized agents, repository-level instructions, tool connections, validation hooks, and usage metrics. Agentic systems should nevertheless be used selectively. Anthropic recommends beginning with the simplest effective architecture. Well-defined tasks may be handled more reliably through deterministic workflows or ordinary language-model calls, while autonomous agents are better suited to tasks requiring flexible decision-making, tool use, iteration, and feedback. Coding is particularly suitable because outputs can often be tested automatically and agents can use failures as feedback.
A mature agentic SDLC therefore requires much more than an agent capable of generating code.
It needs:
Clear specifications Repository context Architectural constraints Secure sandboxes Limited permissions Automated testing Policy-as-code Software supply-chain controls Agent logs and traces Human accountability Cost measurement Failure recovery
Talent development The practical transition can be understood through five maturity levels. Level One: Assisted development AI provides completion, explanation, drafting, and local coding assistance. Level Two: Task delegation Agents complete bounded issues and return proposed changes for review. Level Three: Workflow participation Specialized agents participate across analysis, implementation, testing, documentation, and security. Level Four: Agent orchestration Multiple agents coordinate across a value stream while humans supervise goals, architecture, exceptions, and outcomes. Level Five: Continuously adaptive delivery Agents help maintain and evolve software continuously in response to defects, business changes, regulations, security threats, and operational signals.
Most organizations should progress gradually rather than attempting immediate end-to-end autonomy.
The most important preparation steps are:
Improve repository and documentation quality. Create explicit engineering standards. Break work into bounded, testable units. Strengthen automated testing and delivery pipelines. Build secure agent execution environments. Establish identity, permissions, logs, and policy controls. Define human accountability at every stage. Train engineers in specification, review, evaluation, and orchestration. Rebuild junior development pathways. Measure business outcomes, quality, cost, and reliability together.
The central principle is:
Agentic development does not remove the need for engineering discipline. It makes engineering discipline executable at machine speed.
1. From Coding Assistant to Software-Delivery Participant
AI-assisted software development initially appeared inside the editor. The developer wrote code.
The model suggested:
A function A completion A test An explanation A refactoring The human remained continuously involved. The emerging agentic model is different.
An agent may receive a task such as:
Investigate why password-reset emails fail for users with internationalized addresses, propose a fix, implement it, add tests, and prepare a pull request.
The agent may then:
Search the repository Inspect relevant services Review issue history Form a hypothesis Modify several files Execute tests Revise the implementation Generate a change summary Request human review GitHub’s current cloud-agent documentation already describes this form of autonomous repository research, planning, implementation, testing, documentation, technical-debt work, and pull-request preparation. This is no longer autocomplete. It is delegated engineering execution.
2. What Makes a Development System Agentic?
An AI feature is not necessarily an agent.
A useful distinction is:
Assistant Responds to the developer inside an interaction. Workflow Follows a predetermined sequence. Agent Chooses actions dynamically to pursue an objective.
An agentic development system commonly includes:
A language or reasoning model Access to tools Repository context Memory or retained state An execution environment Feedback from tests or other systems Rules and permissions A stopping or escalation condition OpenAI describes agents as applications that can plan, call tools, coordinate specialized components, and maintain enough state to complete multistep work. The important change is agency over the route to the outcome. The human defines the objective and constraints. The agent determines at least part of the execution path.
3. The SDLC Becomes a Hybrid Production System
Traditional software delivery usually separates several stages:
Discovery Requirements Design Architecture Development Testing Security review Deployment Operation Maintenance Agentic systems can participate in every stage. That does not mean one general-purpose agent should control the entire lifecycle.
A stronger architecture may use specialized agents for:
Requirements analysis Codebase research Architecture review Implementation Testing Security Documentation Migration Operational investigation Thoughtworks describes this as a multi-agent operating model supported by shared knowledge, value-aligned team design, and governance.
The SDLC becomes a hybrid production network containing:
Human product leadership Human engineering judgment Autonomous agent execution Deterministic automation Policy controls Shared organizational knowledge
4. Why Software Development Is Especially Suitable for Agents
Software engineering provides conditions that are unusually favorable for agentic work.
Code can often be:
Parsed Compiled Tested Linted Benchmarked Scanned Compared This creates feedback loops.
An agent can:
Generate a solution. Run the test suite. Observe a failure. Modify the solution. Test again. Anthropic identifies coding as a strong agentic use case because the problem space is structured, outputs can be verified, and agents can iterate using automated feedback. This does not make coding agents infallible. It makes them more governable than agents operating in environments where success cannot be measured clearly.
5. Do Not Use an Agent When Simpler Automation Is Better
Agent enthusiasm can produce unnecessary complexity. A task does not require an autonomous agent merely because an agent can perform it.
Use a deterministic script or workflow when:
The steps are known Inputs are structured Rules are stable Variability is low Failure consequences are high Reproducibility is essential
Use an agent when:
The path cannot be completely predetermined The system must inspect context Tool choice varies Iteration is required Multiple solutions may be acceptable Human-like judgment is useful Anthropic recommends starting with the simplest workable pattern because frameworks and agent abstractions can make systems harder to understand and debug. The objective is not maximum autonomy. It is the minimum autonomy required to produce the desired value. Part I: How the SDLC Changes
6. Product Discovery
Agents can support discovery by:
Reviewing customer feedback Clustering support issues summarizing analytics comparing competitor capabilities drafting opportunity statements identifying unresolved questions The product manager’s role does not disappear.
It moves toward:
Choosing which evidence matters deciding which customer problem deserves investment resolving conflicting signals setting product direction accepting opportunity cost AI can increase the amount of information processed. It cannot independently determine what the company should value.
7. Requirements and Specification
The quality of the agent’s work depends heavily on the quality of the specification. Vague tasks create broad search spaces.
A request such as:
Improve authentication. is difficult to evaluate.
A better task defines:
User problem Existing behavior Desired behavior Constraints Acceptance criteria Security requirements Out-of-scope areas Agentic development increases the importance of executable specifications.
Specifications may include:
Examples Tests Schemas interface contracts policies performance thresholds The specification becomes an engineering asset rather than a temporary planning document.
8. Architecture
Agents can assist architects by:
Mapping dependencies identifying patterns reviewing proposed changes generating diagrams comparing alternatives locating architectural drift
The architect still needs to make decisions involving:
Strategic direction Business tradeoffs Long-term maintainability Platform boundaries Regulatory requirements Organizational capability Agentic systems can make local changes quickly. Without architectural control, they can also create inconsistency quickly. Architecture must therefore become more explicit and machine-readable.
Useful mechanisms include:
Architecture decision records Dependency rules Approved patterns Interface standards Repository instructions Policy checks
9. Implementation
Implementation is the most visible area of change.
Agents may handle:
Scaffolding Routine feature work Bug fixes Refactoring Dependency updates Migration assistance Documentation GitHub currently describes agents that can implement incremental features, improve tests, address technical debt, and resolve merge conflicts in isolated environments before returning changes for review.
Human engineers increasingly focus on:
Defining the task selecting the design reviewing the result investigating exceptions managing integration ensuring fitness for purpose
10. Testing
Testing becomes both more automated and more important.
Agents can generate:
Unit tests Integration tests Property-based tests Test data Edge cases Regression suites But agent-generated tests can reproduce the same misunderstanding as agent-generated code. If one model generates the implementation and validates it using assumptions derived from the same context, correlated errors may survive.
A stronger assurance model uses:
Independent evaluation agents Deterministic test suites Human-designed critical tests Mutation testing Security testing Production monitoring Thoughtworks recommends specialized validation and compliance agents capable of challenging the work of other agents.
11. Code Review
Code review must evolve when the volume of generated code increases. Reviewing every line manually may become impractical.
Reviewers should increasingly examine:
Intent Architecture Security Risk Test quality Behavior Unintended scope Dependency changes
The review question changes from:
Is every line written exactly as I would write it?
to:
Does this change satisfy the specification safely and coherently? Human review remains essential for high-impact changes. For low-risk, highly testable work, humans may supervise the review system rather than inspect every edit.
12. Security
Agentic coding expands the software attack surface.
Risks include:
Insecure generated code Exposed secrets Malicious dependencies Prompt injection through repository content Excessive tool permissions Unsafe command execution Supply-chain compromise
Security controls should include:
Isolated execution Least privilege Secret management Dependency scanning Static analysis Software composition analysis Signed artifacts Protected branches Required approvals GitHub’s agent model uses isolated development environments and supports hooks that can run security scans, logging, and validation during agent execution.
13. Deployment
Agents can assist with:
Release preparation Configuration changes Deployment plans Canary analysis Rollback preparation Release documentation Direct production authority should be introduced conservatively.
Deployment permissions should depend on:
Change risk Environment Reversibility Test coverage Operational maturity A low-risk documentation update may be merged automatically. A payment-system migration should require senior human approval.
14. Operations
Agents can support operations by:
Investigating incidents Correlating logs proposing remediation drafting postmortems updating runbooks identifying recurring failure patterns Operational agents must be designed carefully because actions may affect live systems.
Autonomy should be restricted through:
Read-only modes Approved actions Rate limits Environment boundaries Human confirmation Automatic rollback
15. Maintenance and Modernization
Maintenance work is well suited to agentic assistance because many tasks are repetitive but valuable.
Examples include:
Dependency updates Deprecated API migration Documentation repair Logging improvements Test-coverage expansion Simple refactoring GitHub explicitly positions agentic coding as a way to address backlog items and technical debt that teams might otherwise postpone. This creates an opportunity to improve software health rather than using all productivity gains only for new feature production. Part II: The Agentic SDLC Operating Model
16. Multi-Agent Systems
One general-purpose agent may be easy to begin with. Larger engineering environments may benefit from specialized agents.
Possible roles include:
Planning agent Repository-research agent Coding agent Test agent Security agent Documentation agent Architecture agent Compliance agent
Specialization can improve:
Context instructions tool selection evaluation accountability It also increases orchestration complexity. Teams should introduce specialization only where it produces measurable value.
17. Orchestration
Orchestration determines:
Which agent receives the task How work is divided How outputs are passed Which failures trigger retries When humans intervene When the process stops A weak orchestration design may produce agents endlessly revising one another’s work.
A strong design defines:
Clear responsibilities Success criteria budgets time limits escalation final ownership
18. Shared Knowledge
Agents need context.
That context may include:
Code Documentation Historical decisions Coding standards Architecture Product rules Security policies Domain knowledge Thoughtworks describes a shared memory and knowledge network that allows agents to draw on information that would otherwise remain fragmented across the organization. The quality of the knowledge network will strongly influence agent performance. Outdated or contradictory knowledge can produce confident but incorrect work.
19. Repository Readiness
An agent-ready repository should contain:
Clear setup instructions Reproducible builds Reliable tests Coding standards Architectural documentation Ownership information Dependency guidance Security requirements GitHub notes that agents become more effective when repositories provide richer information about code, tools, and organizational standards through instructions and retained repository knowledge. Poor repositories create poor agent performance. Agent adoption therefore exposes engineering hygiene problems that were previously absorbed by experienced humans.
20. Value-Stream Alignment
Thoughtworks expects agentic delivery to support smaller, more autonomous, stream-aligned teams. Agents and shared platforms may reduce dependence on specialist teams by offering self-service knowledge and technical capabilities. A stream-aligned team owns a continuous flow of value for a customer, product, or service.
It should contain enough capability to:
Understand the problem build the solution operate the solution improve the solution Agents can expand the team’s effective capability. They should not erase accountability.
21. Platform Teams
Platform teams become more important, not less.
They may provide:
Secure agent runtimes Approved models Tool integrations Context retrieval Validation pipelines Observability Cost controls Reusable agent skills The platform should reduce cognitive load for product teams. It should not become a centralized approval bottleneck.
Platform-as-product principles remain essential:
Clear users Roadmap Service levels Documentation Feedback Adoption metrics
22. Human Accountability
An agent cannot hold organizational accountability. Every agentic workflow should have a human owner.
That owner is responsible for:
Purpose Permissions Performance Risk Escalation Retirement Thoughtworks explicitly places accountability for agent results with the human team and recommends audit records that allow humans to monitor and correct agent behavior. Part III: Governance
23. Why Governance Becomes More Important
Agentic systems can operate quickly. They can also create errors quickly.
Potential failures include:
Incorrect code at scale Security vulnerabilities Architectural drift Uncontrolled cost Inconsistent standards Untraceable decisions Traditional governance often relies on human review meetings. That may not scale to agentic delivery speed.
Governance must become more:
Automated Embedded Continuous Evidence based
24. Policy as Code
Thoughtworks recommends policy-as-code as a foundational safety layer for nondeterministic agents. Deterministic rules can enforce minimum requirements even when agents dynamically choose their execution path.
Examples include:
No unencrypted sensitive data No prohibited dependencies Required test thresholds Required approvals for critical files No direct production deployment Mandatory security scans Policies should be versioned, tested, reviewed, and owned.
25. Sandboxed Execution
Agents should operate inside isolated environments. A sandbox limits the effect of mistakes or malicious instructions.
Controls may include:
Ephemeral environments Restricted network access Limited credentials Resource quotas Filesystem boundaries Command allowlists GitHub documents the use of ephemeral, isolated environments where agents can inspect code and execute tests without direct uncontrolled access to developer machines or production systems.
26. Agent Identity
Every agent should have a traceable identity.
The system should record:
Which agent acted Which model was used Which tools were called Which files changed Which human initiated the task Which approvals were granted Shared generic credentials make accountability difficult. Machine identity should be managed as seriously as human identity.
27. Least Privilege
An agent should receive only the permissions required for its task. A documentation agent does not need deployment access. A test agent may need execution access but not permission to merge code.
Permissions should be:
Task specific Time limited Environment limited Revocable
28. Auditability
Thoughtworks recommends audit records and reliability metrics for monitoring agent performance and behavioral drift.
Useful records include:
Prompts Plans Tool calls Outputs Test results Approvals Cost Failures Corrections
Audit data supports:
Incident investigation Compliance improvement accountability
29. Trust Registers
Thoughtworks proposes the concept of a central register containing approved agents and information about their reliability or risk.
An enterprise agent registry may contain:
Owner Purpose Model Tools Permissions Data classification Reliability Approved use cases Known limitations Last review This prevents uncontrolled proliferation.
30. Human in the Loop Versus Human on the Loop
Human in the loop A person reviews individual outputs or actions. Human on the loop A person supervises the overall system, performance, and exceptions. Thoughtworks expects predictable areas to move increasingly toward human-on-the-loop supervision because reviewing every agent-generated change may become impractical. The appropriate model depends on risk. High-risk changes may still require direct human approval.
31. Agent Reliability Engineering
A new discipline may emerge around agent reliability.
Responsibilities may include:
Evaluation design Failure analysis Drift monitoring Context management Tool reliability Retry policy cost optimization incident response Thoughtworks identifies agent reliability engineering as a possible emerging role in the agentic development organization.
32. AI FinOps
Agentic work consumes:
Model tokens Compute Execution time External APIs Storage Human review Thoughtworks argues that organizations need AI FinOps to track agent costs and evaluate return on investment and workforce implications.
Useful cost measures include:
Cost per completed task Cost per merged change Cost per accepted test Cost of failed runs Human review time Rework cost A cheap model producing unreliable work may be more expensive overall than a stronger model. Part IV: Team and Role Transformation
33. The Engineer Becomes a System Thinker
Thoughtworks describes a shift from the “hero developer” toward the system thinker. Professional value moves away from syntax mastery alone and toward problem definition, architecture, and auditing.
The engineer of the agentic SDLC increasingly asks:
Is the problem defined correctly? Does the agent have sufficient context? Which constraints matter? How can the result be verified? What are the system-level consequences? Coding knowledge remains important. Its role changes from exclusive production to direction and validation.
34. Experienced Engineers
Senior engineers may move toward:
Architecture Agent orchestration Governance Evaluation Platform design Mentoring They may supervise larger effective delivery capacity because agents perform more routine execution. The risk is overloading senior engineers with constant review. The organization needs strong automated assurance to avoid turning senior engineers into approval bottlenecks.
35. Midlevel Engineers
Midlevel engineers may pursue several paths:
Systems architecture Product engineering Agent development Reliability Security Governance Technical leadership Thoughtworks identifies dual pathways toward architecture and governance or deeper agent-development specialization.
36. Junior Engineers
Junior development is one of the hardest issues.
Routine tasks traditionally helped engineers learn:
Code structure Debugging Testing Version control Review Production responsibility If agents perform these tasks, junior employees may lose essential experience. Thoughtworks recommends pairing and mob programming and suggests that agents may operate in learner or pairing modes to support junior staff.
A stronger junior-development model may include:
Guided code review Simulation environments Debugging exercises Architecture walkthroughs Agent-output critique Rotations Production observation Junior engineers should not become passive prompt operators. They need deep enough knowledge to detect when the agent is wrong.
37. Product Owners and Analysts
Product owners and business analysts remain essential because they contribute:
Customer knowledge Business context Prioritization Tradeoff decisions Value definition Thoughtworks expects these roles to remain important because of their insight and empathy for users and the broader business environment. Their work may become more technical as specifications increasingly guide autonomous execution.
38. User-Experience Professionals
UX professionals may use agents for:
Prototype generation Research synthesis Accessibility checks Design alternatives
Their central human responsibilities remain:
Understanding users interpreting behavior identifying unmet needs protecting usability challenging technology-driven assumptions
39. Quality Engineering
Quality engineering may move from executing tests toward designing assurance systems.
Future responsibilities include:
Evaluation strategy Risk-based testing Independent validation Production-quality signals Agent-quality measurement QA becomes a strategic discipline rather than a final delivery stage.
40. Security Engineering
Security engineers will need to govern both:
The software being created The agents creating it
New responsibilities include:
Agent permissions prompt-injection defense tool safety provenance supply-chain integrity model-risk assessment
41. Knowledge Architecture
Thoughtworks identifies knowledge architecture as a possible new role because agents depend heavily on organizational context.
A knowledge architect may define:
Sources Ownership Metadata Retrieval Freshness Access Conflict resolution Knowledge architecture becomes part of software-delivery architecture. Part V: Culture
42. Healthy Skepticism
Teams must trust agents enough to delegate work. They must remain skeptical enough to detect failure. Thoughtworks describes healthy skepticism as a core cultural requirement.
Two unhealthy extremes are:
Blind trust The team accepts plausible output without sufficient validation. Total distrust The team redoes every agent task manually and realizes no benefit. Healthy skepticism means calibrated trust based on evidence.
43. From Individual Heroics to Collaborative Supervision
Agentic development weakens the mythology of the lone engineer who holds the entire system in their head.
Shared knowledge, automated controls, and multi-agent workflows reward:
Collaboration Documentation Explicit decisions Collective ownership Thoughtworks expects more swarming, pairing, and mob programming rather than isolated silos.
44. Learning From Failure
Agentic experimentation will produce failures.
Teams should examine:
Why the task failed Which context was missing Which guardrail failed Whether the task was appropriate How the evaluation should improve Thoughtworks recommends treating unsuccessful experiments as learning opportunities. This does not mean tolerating reckless production failures. It means creating safe environments for experimentation.
45. Avoiding Cultural Fragmentation
More autonomous teams can increase speed.
They can also create divergent:
Standards architectures agent configurations product assumptions Thoughtworks warns that increased team autonomy and decoupling may create cultural fragmentation, making whole-product focus and strategic alignment more important.
Organizations need shared:
Engineering principles Platform standards Product strategy Communities of practice Architecture governance
46. Co-Location Versus Distributed Work
Thoughtworks suggests that fast-moving agentic teams may benefit from close collaboration or co-location because humans need to clarify ambiguous situations quickly. This should not be interpreted as proof that all agentic teams must return to offices full time. The underlying requirement is high-bandwidth coordination.
That can be achieved through:
Co-location Structured remote collaboration Shared workspaces Mob sessions Clear asynchronous documentation The workplace model should follow the work. Part VI: Metrics
47. Avoid Measuring Lines of Code
Agentic systems can generate vast amounts of code. Lines of code are not a measure of value.
More code may mean:
More functionality More duplication More complexity More maintenance The correct goal is effective software, not maximum code production.
48. Delivery Metrics
Useful measures include:
Lead time Deployment frequency Time to merge Time to restore Escaped defects Change-failure rate GitHub provides agent-related pull-request metrics such as created and merged pull requests and median time to merge. These can support analysis, but they should be connected to quality and value.
49. Agent Performance Metrics
Possible measures include:
Task-completion rate Acceptance rate Test success Retry rate Escalation rate Human correction rate Cost per task Reliability drift Thoughtworks specifically identifies task completion and behavioral-drift monitoring as important governance measures.
50. Review Burden
An agent may produce changes quickly while consuming large amounts of human review time.
Measure:
Review hours Number of revisions Rejected changes Cognitive difficulty Reviewer bottlenecks The net productivity gain matters more than generation speed.
51. Business Value
Engineering metrics should ultimately connect to:
Customer outcomes Revenue Risk reduction Reliability Time to market Cost Product learning An agentic SDLC is not successful because agents are active. It is successful when software creates greater value more safely and efficiently. Part VII: A Practical Adoption Framework
52. Phase One: Engineering Hygiene
Before introducing autonomous agents, strengthen:
Build reproducibility Automated tests Documentation Repository structure CI/CD Ownership Agentic adoption will amplify weak engineering foundations.
53. Phase Two: Assisted Development
Introduce low-risk assistance for:
Explanation Drafting Documentation Local testing Code completion
Focus on:
Safe usage Privacy Verification Developer education
54. Phase Three: Bounded Delegation
Delegate well-defined tasks such as:
Documentation fixes Test generation Dependency updates Small defects Simple refactoring
Require:
Sandboxed execution Automated tests Human review Audit logs
55. Phase Four: Specialized Agents
Create agents for:
Testing Security Documentation Migrations Repository research
Establish:
Agent registry Owners Permissions Reliability measures Cost budgets
56. Phase Five: Workflow Orchestration
Allow multiple agents to coordinate across selected workflows.
Introduce:
Policy as code Independent validation Human-on-the-loop supervision Agent observability Failure recovery
57. Phase Six: Continuous Agentic Delivery
In mature environments, agents may help continuously:
Detect issues propose changes update dependencies strengthen tests improve documentation respond to operational signals
Human leaders remain responsible for:
Product direction Architecture Risk Customer value Accountability A 90-Day Team-Preparation Plan Days 1 - 30: Establish readiness Inventory current AI use. Select low-risk repositories. Assess tests and documentation. define prohibited data and tasks. create initial engineering guidelines.
train engineers in review and verification. Days 31 - 60: Pilot bounded agents Choose small, testable tasks. create secure sandboxes. require branch-based changes. add automated tests and scans. track review time and acceptance. gather developer feedback. Days 61 - 90: Build the operating model Define agent owners. create an agent registry. establish permission levels.
formalize reliability metrics. design junior-engineer learning pathways. decide which pilots to scale. A 12-Month Roadmap Quarter One: Foundation Improve repository hygiene. create AI usage standards. strengthen CI/CD. select approved models and tools. establish baseline metrics. Quarter Two: Task delegation Deploy agents for low-risk work.
build secure execution. introduce automated policy checks. train reviewers. establish cost tracking. Quarter Three: Specialization Add testing, security, documentation, and research agents. build shared knowledge services. create agent-reliability roles. update role and career architectures. Quarter Four: Orchestration Pilot multi-agent workflows. introduce human-on-the-loop supervision.
integrate agent metrics into engineering dashboards. refresh team topologies. scale only where quality and value are proven. Common Failure Patterns
58. Deploying Agents Into Weak Repositories
Poor tests, documentation, and build systems produce unreliable agent behavior.
59. Maximizing Autonomy Too Early
Large tasks with unclear boundaries create errors and review burden.
60. Using Agents Where Scripts Are Better
Nondeterministic systems are introduced into predictable workflows unnecessarily.
61. Measuring Generated Code
Output volume is mistaken for engineering value.
62. Ignoring Review Capacity
Agents generate more changes than experienced engineers can assess.
63. Giving Excessive Permissions
Agents receive broad access beyond the requirements of the task.
64. Trusting Agent-Generated Tests Completely
Implementation and validation may share the same mistaken assumptions.
65. Neglecting Junior Development
Routine learning tasks disappear without replacement pathways.
66. Treating Context as an Afterthought
Agents receive outdated, fragmented, or incomplete knowledge.
67. Ignoring Cost
Model usage, retries, execution, and human review exceed the economic value created.
68. Allowing Agent Proliferation
Teams create unowned agents with inconsistent permissions and standards.
69. Removing Humans From Accountability
The organization assumes the machine is responsible for errors.
70. Preserving Old Team Structures
Agents are added without redesigning roles, dependencies, or value streams.
Key Takeaways
The agentic SDLC moves AI from coding assistance into active software-delivery participation. Agents may research repositories, plan work, write code, test changes, update documentation, and prepare pull requests. The transformation affects architecture, talent, team structure, governance, and culture - not merely tooling. Thoughtworks identifies four foundations: multi-agent systems, knowledge networks, value-stream design, and governance. Software development is well suited to agents because code can often be tested and verified automatically. Agents should not be used when deterministic workflows or simpler model calls are sufficient. Specification quality becomes more important as execution becomes more autonomous. Architectural rules should become explicit and machine enforceable. Testing must combine deterministic controls, independent evaluation, and human judgment. Code review will shift toward intent, architecture, security, behavior, and risk. Agents require secure sandboxes, limited permissions, identities, and complete audit records. Policy-as-code provides deterministic boundaries around nondeterministic workflows.
Human accountability remains essential even when humans no longer inspect every change. Engineering roles will shift from direct code production toward system thinking, orchestration, review, and governance. New roles may include knowledge architects, agent architects, and agent-reliability engineers. Junior-development pathways must be rebuilt as routine tasks become automated. Smaller, stream-aligned teams may become more autonomous through agentic self-service. Platform teams will provide shared agent infrastructure, knowledge, governance, and reusable capabilities. Organizations should measure net business value, quality, review burden, reliability, and cost - not code volume. The safest path is gradual progression from assistance to bounded delegation, specialization, and then orchestration.
Frequently Asked Questions
What is an agentic software development life cycle?
It is an SDLC in which AI agents independently perform or coordinate multistep engineering tasks while humans define goals, constraints, architecture, governance, and accountability.
How is an agent different from a coding assistant?
A coding assistant responds during a human-led session. An agent can plan, use tools, execute actions, evaluate results, and continue working toward an objective with greater independence.
Can coding agents create pull requests?
Yes. Current coding agents can inspect repositories, make branch-based changes, execute tests, and prepare pull requests for human review.
Can agents replace software engineers?
Agents can automate substantial parts of implementation and maintenance, but engineers remain necessary for problem definition, architecture, judgment, security, integration, review, and accountability.
Which tasks should be delegated first?
Good early tasks include:
Documentation Test generation Dependency updates Small bug fixes Bounded refactoring Repository research
Which tasks should remain human-led?
High-risk areas include:
Major architecture Security-critical changes Irreversible migrations Product strategy Sensitive production decisions Regulatory accountability
What is a multi-agent system?
It is a system containing several specialized agents that collaborate or divide responsibilities across a workflow.
Do companies need many specialized agents?
Not initially. A smaller and simpler architecture is generally easier to debug, govern, and maintain.
What is a knowledge network?
It is a governed layer of code, documentation, decisions, policies, and organizational context that agents and humans can use.
Why is repository quality important?
Agents rely on available code, tests, documentation, and instructions. Weak repository hygiene produces weaker and less reliable results.
What is policy as code?
It is the expression of governance rules in automatically enforceable form, such as required tests, prohibited dependencies, or approval requirements.
What is human on the loop?
It means people supervise the reliability and behavior of the full system rather than approving every individual action.
Do humans remain accountable?
Yes. Organizations and designated human owners remain responsible for the outcomes of agentic systems.
What is agent reliability engineering?
It is the practice of evaluating, monitoring, and improving agent performance, cost, context quality, drift, failure recovery, and operational safety.
What is AI FinOps?
It is the management of model, compute, tool, execution, and review costs associated with AI systems.
How do coding agents affect junior engineers?
They may automate traditional junior tasks, requiring new development models involving pairing, simulations, guided review, and supervised agent use.
Will teams become smaller?
Some may. Agents can increase effective capacity and reduce dependencies, but the appropriate team size depends on product complexity, risk, and business demand.
Will specialized engineering roles disappear?
Some boundaries may blur, but deep specialization remains important in areas such as security, architecture, reliability, data, and complex platforms.
How should agentic code be reviewed?
Review should emphasize:
Requirements behavior architecture security tests unintended scope operational risk
Should an agent be allowed to deploy directly to production?
Only in carefully controlled, low-risk, reversible environments with strong policy, monitoring, and rollback. High-impact changes should retain human approval.
What should engineering leaders do first?
Strengthen tests, documentation, repository setup, delivery pipelines, and governance before expanding agent autonomy.
Conclusion
Agentic software development represents a deeper change than the introduction of another programming tool. The traditional developer used software tools to create code.
The emerging developer increasingly directs a production system containing:
Models Agents Execution environments Tests Policies Knowledge Human reviewers This system can inspect repositories, create plans, produce changes, validate results, and iterate. Its potential is substantial.
Organizations may:
Deliver faster address technical debt improve test coverage modernize legacy systems expand engineering capacity reduce repetitive work
The same capability can also create:
Larger volumes of insecure code architectural drift uncontrollable cost review bottlenecks false confidence weaker junior development The difference will be determined by the operating model. Thoughtworks is correct to frame the agentic SDLC through multi-agent systems, shared knowledge, value-stream alignment, governance, talent, team structure, and culture rather than treating it as a narrow technology deployment. The shift changes the professional identity of software engineers. Syntax and direct code production remain relevant. They are no longer the complete center of engineering value.
Greater value moves toward:
Problem definition Architecture Context design Evaluation Orchestration Security Accountability This raises the standard for engineering judgment. It does not eliminate it. The strongest teams will not blindly trust agents or reject them defensively.
They will build calibrated trust through:
Tests policies logs controlled permissions independent evaluation measured performance They will also redesign careers. If agents absorb the work through which junior engineers once developed expertise, organizations must create new forms of apprenticeship and deliberate practice. The future senior engineer cannot emerge from a workforce that was never allowed to learn the underlying system. The agentic SDLC should therefore be introduced progressively. Begin with engineering hygiene. Move to bounded delegation.
Add specialized agents where value is proven. Develop orchestration only after governance, knowledge, and assurance are mature.
The defining question is not:
How much code can our agents generate?
It is:
How should people, agents, platforms, knowledge, and controls work together so that the organization can produce better software faster without losing reliability, security, professional judgment, or the ability to develop its next generation of engineers?
Relevant Articles and Resources
Preparing Your Team for the Agentic Software Development Life Cycle - Thoughtworks The foundational article describing agents as team contributors, nondeterministic engineering, shared memory, multi-agent systems, value-stream design, governance, role changes, junior development, and engineering-culture transformation. About GitHub Copilot Cloud Agent - GitHub Documentation Official documentation describing repository research, implementation planning, code changes, testing, technical-debt work, pull-request preparation, isolated environments, specialized agents, instructions, hooks, metrics, permissions, costs, and limitations. Building Effective AI Agents - Anthropic Engineering Primary engineering guidance recommending simple, composable agent architectures, selective use of autonomy, clear success criteria, feedback loops, and meaningful human oversight. Agents SDK - OpenAI Developer Documentation Official documentation describing agents that plan, use tools, coordinate specialist components, maintain state, and execute multistep workflows. Preparing for Agentic Transformation - Thoughtworks Looking Glass A broader examination of how agentic workflows change human roles from direct task execution toward supervision, judgment, and governance. Agentic AI at Work - Thoughtworks Guidance on building AI literacy, mapping workflows before automation, and identifying where agentic systems create meaningful value.
Integrating Agentic AI Into the Enterprise SDLC - GitHub Documentation Official guidance showing how organizations can use planning modes, custom agents, repository standards, and enterprise workflows in AI-assisted software delivery. Effective Harnesses for Long-Running Agents - Anthropic Engineering Primary engineering research on structuring state, context, progress, and execution for agents working on extended engineering tasks. Harness Design for Long-Running Application Development - Anthropic Engineering Current technical guidance on the importance of harness architecture for long-running autonomous software-development work. The Next Evolution of the Agents SDK - OpenAI Official information on sandbox execution and infrastructure for secure, long-running agents that work across files and tools.