The Architect-Developer: Orchestrating the AI-Driven Development Lifecycle (AI-DLC)
The ground has shifted under software engineering, and it has happened almost overnight.
In the space of a few months, AI has moved from a clever assistant to a force that is reshaping how we design, build and deliver digital products. The change has been so rapid that it has split opinion across the industry. Some teams are already experimenting, discovering new levels of productivity and creative freedom. Others are wary, questioning the reliability of these tools and the wisdom of trusting them too quickly.
Both instincts are right. The moment demands curiosity, but it also demands scepticism. AI is astonishingly capable, but it is not infallible. It can accelerate delivery, but it can also accelerate mistakes.The organisations that will thrive are the ones that embrace the tools while maintaining a clear sense of responsibility for the outcomes. As one of the most telling observations in this space puts it, a tool does not absolve you of accountability. You are still responsible for what you build.
“The work is yours, not the tools” - Werner Vogels -Amazon CTO
This is the real story of AI in software engineering. It is not a story about replacement. It is a story about elevation.
For the past year or so, AI in development meant autocomplete suggestions and chatbots that could answer basic questions.
That era is already behind us. Modern integrated development environments (IDEs) now contain embedded AI agents that can scaffold entire services, propose architectural patterns, write tests, refactor codebases and reason about multi‑step tasks. The developer’s role has shifted from author to orchestrator. The keyboard is no longer the bottleneck. The bottleneck is clarity of thought and having access to the right engineering and architecture experience.
This shift does not diminish engineering skill. It amplifies it. The better you understand systems, the more powerful these tools become. The less you understand, the more dangerous they are. AI will happily generate an elegant, well‑structured solution to the wrong problem if you let it or generate a mass of technical debt disguised as a solution to your requirements.
The comparison with radiology is instructive. When AI entered that field, many predicted the end of the radiologist. Instead, radiologists became more productive, more accurate and more focused on the complex cases that required human judgement. AI handled the repetitive work. Humans handled the nuance. Software engineering is following the same pattern. AI is not replacing developers. It is freeing them to do the work that actually matters while also highlighting a potential skills gap as the importance of the quality and experience of engineers becomes paramount.
This shift has profound implications for how organisations structure their teams. The old model relied on large groups of developers manually producing code. But as Marc Brooker has pointed out, generating code is now a commodity. The cost of producing code has collapsed. The cost of producing the right code has not.
“The cost of turning written business logic into code has dropped to zero. At best, near-zero” - Marc Brooker - VP/DistinguishedEngineer at AWS
Organisations no longer need armies of coders. They need orchestrators. They need people who can translate business intent into technical direction, who can guide AI agents, validate outputs and ensure that what is built aligns with standards, strategy and long‑term maintainability. At Leighton, this role is known as the architect‑developer.
”20%–60% effort reduction in key coding and delivery tasks is reported in vendor/client evidence and inquiries; variability depend son tool maturity and context.” - Gartner
An architect‑developer is not a traditional architect who draws diagrams and steps away from the keyboard. Nor are they a pure coder. They are a hybrid: a cloud architect who still writes code, an experienced engineer with product instincts, a hands‑on leader who understands AI tooling and a systems thinker who can validate and steer outputs. They are the person who ensures the AI builds the right thing in the right way.
This role is M‑shaped rather than T‑shaped. It requires broad capability across architecture, engineering and product, combined with deep expertise in areas such as DevOps, domain‑driven design, full‑stack engineering and cloud. It is this shape that allows architect‑developers to lead small, high‑impact pods that move faster and deliver more value than traditional teams.
The traditional two‑pizza team – coined by Amazon founder Jeff Bezos – was designed for a world where humans wrote every line of code. But more people mean more communication paths, more handoffs and slower decisions. AI‑enabled teams flip this model. A small pod led by an architect‑developer can deliver at a pace that would previously have required a much larger group.
“Traditional ‘sprints’ are replaced by ‘bolts’– shorter, more intense work cycles measured in hours or days rather than weeks; Epics are replaced by Units of Work.” - AWS
At Leighton, this has resulted in productivity gains of five to six times in some cases. Not because AI is magic, but because it is guided.The pod structure scales like a living system. A senior engineer grows into an architect‑developer, the pod splits, and two pods now operate independently. Juniors grow into seniors. The cycle continues. Specialised AI agents fill capability gaps in areas such as SEO, marketing, and pen-testing. Capability scales without headcount exploding.
This shift also changes how work is delivered. Traditional two‑week sprints feel slow when AI can generate working software in minutes. Leighton had already moved to a faster cadence before AWS formalised the AI‑DLC. When the guidance arrived, it simply gave names to practices that were already working at Leighton. Bolts replace sprints. Value is delivered continuously rather than in scheduled increments. Pods are small, autonomous teams that work with agency and urgency alongside AI agents to amplify the experience and knowledge in the team.
One of the most significant changes is the move towards semantic‑first engineering. Instead of relying on long and cumbersome Jira tickets that are often out of date by the time work begins, teams generate just‑in‑time specifications that capture the current understanding of the requirement. These specifications are refined with AI agents until assumptions are eliminated and approaches aligned. Steering documents ensure that the model builds using the organisation’s frameworks, patterns and standards. We are simply generating the code and solution faster, which was previously done by hand. The quality output is the same.
This approach is faster, more accurate and more aligned with how AI works. It also elevates organisational context to a strategic asset. The most valuable intellectual property in an AI‑driven organisation is not the codebase. It is the source context: the patterns, principles, frameworks and architectural guidance that shape how the AI agent builds. When shared across teams, this context ensures consistent, high‑quality outputs.
The cost of experimentation has also collapsed. Teams can build prototypes in hours, generate UI options live with stakeholders and iterate in real time. Customer journeys can be brought to life quickly and cheaply. This is not agile. It is something beyond agile.
The next frontier is generative‑native architecture. These are systems designed from the ground up to operate with AI in the loop. In such systems, a production issue might be detected automatically, a ticket raised automatically, a fix proposed automatically, code generated, tests written, a pull request opened and a deployment executed. Humans remain in the loop, but primarily as validators rather than executors.
“I built an AI agent which can analyse CloudWatch access logs and use the honeycomb.io MCP server to find root causes. It works extremely well and even correctly suggests the fix for any problems found. Nextup: triggering a Cursor Agent to implement the fix!” - Luc van Donkersgoed -AWS Hero
This is not science fiction. It is already happening. The organisations that adopt this model early will move faster, respond quicker and deliver more value with fewer people.
The future of software engineering is not about typing faster. It is about thinking better. AI has made tasks cheap. Purpose is now the differentiator. The architect‑developer embodies this shift. They are the person who can orchestrate AI, validate outputs and ensure that what is built is aligned with business value, technical standards and long‑term strategy.
”AI is very good at handling tasks, especially those that are repetitive or rule-based. However, it does not replace the core purpose of a role.” - Jensen Haung, CEO Nvidia
One of the most resonant ideas in this space captures the moment perfectly. AI will not replace you, but someone using AI will. The question for every organisation now is whether they are building teams of task‑doers or teams of purpose‑driven orchestrators.
At Leighton we’re working with our customers to help them better understand how they can integrate AI into their teams and workflows through our AI-driven workshop. If you’re interested in exploring how you can better enable your teams to deliver in an AI era we’d love to hear from you: hello@leighton.com.
The ground has shifted under software engineering, and it has happened almost overnight.
In the space of a few months, AI has moved from a clever assistant to a force that is reshaping how we design, build and deliver digital products. The change has been so rapid that it has split opinion across the industry. Some teams are already experimenting, discovering new levels of productivity and creative freedom. Others are wary, questioning the reliability of these tools and the wisdom of trusting them too quickly.
Both instincts are right. The moment demands curiosity, but it also demands scepticism. AI is astonishingly capable, but it is not infallible. It can accelerate delivery, but it can also accelerate mistakes.The organisations that will thrive are the ones that embrace the tools while maintaining a clear sense of responsibility for the outcomes. As one of the most telling observations in this space puts it, a tool does not absolve you of accountability. You are still responsible for what you build.
“The work is yours, not the tools” - Werner Vogels -Amazon CTO
This is the real story of AI in software engineering. It is not a story about replacement. It is a story about elevation.
For the past year or so, AI in development meant autocomplete suggestions and chatbots that could answer basic questions.
That era is already behind us. Modern integrated development environments (IDEs) now contain embedded AI agents that can scaffold entire services, propose architectural patterns, write tests, refactor codebases and reason about multi‑step tasks. The developer’s role has shifted from author to orchestrator. The keyboard is no longer the bottleneck. The bottleneck is clarity of thought and having access to the right engineering and architecture experience.
This shift does not diminish engineering skill. It amplifies it. The better you understand systems, the more powerful these tools become. The less you understand, the more dangerous they are. AI will happily generate an elegant, well‑structured solution to the wrong problem if you let it or generate a mass of technical debt disguised as a solution to your requirements.
The comparison with radiology is instructive. When AI entered that field, many predicted the end of the radiologist. Instead, radiologists became more productive, more accurate and more focused on the complex cases that required human judgement. AI handled the repetitive work. Humans handled the nuance. Software engineering is following the same pattern. AI is not replacing developers. It is freeing them to do the work that actually matters while also highlighting a potential skills gap as the importance of the quality and experience of engineers becomes paramount.
This shift has profound implications for how organisations structure their teams. The old model relied on large groups of developers manually producing code. But as Marc Brooker has pointed out, generating code is now a commodity. The cost of producing code has collapsed. The cost of producing the right code has not.
“The cost of turning written business logic into code has dropped to zero. At best, near-zero” - Marc Brooker - VP/DistinguishedEngineer at AWS
Organisations no longer need armies of coders. They need orchestrators. They need people who can translate business intent into technical direction, who can guide AI agents, validate outputs and ensure that what is built aligns with standards, strategy and long‑term maintainability. At Leighton, this role is known as the architect‑developer.
”20%–60% effort reduction in key coding and delivery tasks is reported in vendor/client evidence and inquiries; variability depend son tool maturity and context.” - Gartner
An architect‑developer is not a traditional architect who draws diagrams and steps away from the keyboard. Nor are they a pure coder. They are a hybrid: a cloud architect who still writes code, an experienced engineer with product instincts, a hands‑on leader who understands AI tooling and a systems thinker who can validate and steer outputs. They are the person who ensures the AI builds the right thing in the right way.
This role is M‑shaped rather than T‑shaped. It requires broad capability across architecture, engineering and product, combined with deep expertise in areas such as DevOps, domain‑driven design, full‑stack engineering and cloud. It is this shape that allows architect‑developers to lead small, high‑impact pods that move faster and deliver more value than traditional teams.
The traditional two‑pizza team – coined by Amazon founder Jeff Bezos – was designed for a world where humans wrote every line of code. But more people mean more communication paths, more handoffs and slower decisions. AI‑enabled teams flip this model. A small pod led by an architect‑developer can deliver at a pace that would previously have required a much larger group.
“Traditional ‘sprints’ are replaced by ‘bolts’– shorter, more intense work cycles measured in hours or days rather than weeks; Epics are replaced by Units of Work.” - AWS
At Leighton, this has resulted in productivity gains of five to six times in some cases. Not because AI is magic, but because it is guided.The pod structure scales like a living system. A senior engineer grows into an architect‑developer, the pod splits, and two pods now operate independently. Juniors grow into seniors. The cycle continues. Specialised AI agents fill capability gaps in areas such as SEO, marketing, and pen-testing. Capability scales without headcount exploding.
This shift also changes how work is delivered. Traditional two‑week sprints feel slow when AI can generate working software in minutes. Leighton had already moved to a faster cadence before AWS formalised the AI‑DLC. When the guidance arrived, it simply gave names to practices that were already working at Leighton. Bolts replace sprints. Value is delivered continuously rather than in scheduled increments. Pods are small, autonomous teams that work with agency and urgency alongside AI agents to amplify the experience and knowledge in the team.
One of the most significant changes is the move towards semantic‑first engineering. Instead of relying on long and cumbersome Jira tickets that are often out of date by the time work begins, teams generate just‑in‑time specifications that capture the current understanding of the requirement. These specifications are refined with AI agents until assumptions are eliminated and approaches aligned. Steering documents ensure that the model builds using the organisation’s frameworks, patterns and standards. We are simply generating the code and solution faster, which was previously done by hand. The quality output is the same.
This approach is faster, more accurate and more aligned with how AI works. It also elevates organisational context to a strategic asset. The most valuable intellectual property in an AI‑driven organisation is not the codebase. It is the source context: the patterns, principles, frameworks and architectural guidance that shape how the AI agent builds. When shared across teams, this context ensures consistent, high‑quality outputs.
The cost of experimentation has also collapsed. Teams can build prototypes in hours, generate UI options live with stakeholders and iterate in real time. Customer journeys can be brought to life quickly and cheaply. This is not agile. It is something beyond agile.
The next frontier is generative‑native architecture. These are systems designed from the ground up to operate with AI in the loop. In such systems, a production issue might be detected automatically, a ticket raised automatically, a fix proposed automatically, code generated, tests written, a pull request opened and a deployment executed. Humans remain in the loop, but primarily as validators rather than executors.
“I built an AI agent which can analyse CloudWatch access logs and use the honeycomb.io MCP server to find root causes. It works extremely well and even correctly suggests the fix for any problems found. Nextup: triggering a Cursor Agent to implement the fix!” - Luc van Donkersgoed -AWS Hero
This is not science fiction. It is already happening. The organisations that adopt this model early will move faster, respond quicker and deliver more value with fewer people.
The future of software engineering is not about typing faster. It is about thinking better. AI has made tasks cheap. Purpose is now the differentiator. The architect‑developer embodies this shift. They are the person who can orchestrate AI, validate outputs and ensure that what is built is aligned with business value, technical standards and long‑term strategy.
”AI is very good at handling tasks, especially those that are repetitive or rule-based. However, it does not replace the core purpose of a role.” - Jensen Haung, CEO Nvidia
One of the most resonant ideas in this space captures the moment perfectly. AI will not replace you, but someone using AI will. The question for every organisation now is whether they are building teams of task‑doers or teams of purpose‑driven orchestrators.
At Leighton we’re working with our customers to help them better understand how they can integrate AI into their teams and workflows through our AI-driven workshop. If you’re interested in exploring how you can better enable your teams to deliver in an AI era we’d love to hear from you: hello@leighton.com.
The ground has shifted under software engineering, and it has happened almost overnight.
In the space of a few months, AI has moved from a clever assistant to a force that is reshaping how we design, build and deliver digital products. The change has been so rapid that it has split opinion across the industry. Some teams are already experimenting, discovering new levels of productivity and creative freedom. Others are wary, questioning the reliability of these tools and the wisdom of trusting them too quickly.
Both instincts are right. The moment demands curiosity, but it also demands scepticism. AI is astonishingly capable, but it is not infallible. It can accelerate delivery, but it can also accelerate mistakes.The organisations that will thrive are the ones that embrace the tools while maintaining a clear sense of responsibility for the outcomes. As one of the most telling observations in this space puts it, a tool does not absolve you of accountability. You are still responsible for what you build.
“The work is yours, not the tools” - Werner Vogels -Amazon CTO
This is the real story of AI in software engineering. It is not a story about replacement. It is a story about elevation.
For the past year or so, AI in development meant autocomplete suggestions and chatbots that could answer basic questions.
That era is already behind us. Modern integrated development environments (IDEs) now contain embedded AI agents that can scaffold entire services, propose architectural patterns, write tests, refactor codebases and reason about multi‑step tasks. The developer’s role has shifted from author to orchestrator. The keyboard is no longer the bottleneck. The bottleneck is clarity of thought and having access to the right engineering and architecture experience.
This shift does not diminish engineering skill. It amplifies it. The better you understand systems, the more powerful these tools become. The less you understand, the more dangerous they are. AI will happily generate an elegant, well‑structured solution to the wrong problem if you let it or generate a mass of technical debt disguised as a solution to your requirements.
The comparison with radiology is instructive. When AI entered that field, many predicted the end of the radiologist. Instead, radiologists became more productive, more accurate and more focused on the complex cases that required human judgement. AI handled the repetitive work. Humans handled the nuance. Software engineering is following the same pattern. AI is not replacing developers. It is freeing them to do the work that actually matters while also highlighting a potential skills gap as the importance of the quality and experience of engineers becomes paramount.
This shift has profound implications for how organisations structure their teams. The old model relied on large groups of developers manually producing code. But as Marc Brooker has pointed out, generating code is now a commodity. The cost of producing code has collapsed. The cost of producing the right code has not.
“The cost of turning written business logic into code has dropped to zero. At best, near-zero” - Marc Brooker - VP/DistinguishedEngineer at AWS
Organisations no longer need armies of coders. They need orchestrators. They need people who can translate business intent into technical direction, who can guide AI agents, validate outputs and ensure that what is built aligns with standards, strategy and long‑term maintainability. At Leighton, this role is known as the architect‑developer.
”20%–60% effort reduction in key coding and delivery tasks is reported in vendor/client evidence and inquiries; variability depend son tool maturity and context.” - Gartner
An architect‑developer is not a traditional architect who draws diagrams and steps away from the keyboard. Nor are they a pure coder. They are a hybrid: a cloud architect who still writes code, an experienced engineer with product instincts, a hands‑on leader who understands AI tooling and a systems thinker who can validate and steer outputs. They are the person who ensures the AI builds the right thing in the right way.
This role is M‑shaped rather than T‑shaped. It requires broad capability across architecture, engineering and product, combined with deep expertise in areas such as DevOps, domain‑driven design, full‑stack engineering and cloud. It is this shape that allows architect‑developers to lead small, high‑impact pods that move faster and deliver more value than traditional teams.
The traditional two‑pizza team – coined by Amazon founder Jeff Bezos – was designed for a world where humans wrote every line of code. But more people mean more communication paths, more handoffs and slower decisions. AI‑enabled teams flip this model. A small pod led by an architect‑developer can deliver at a pace that would previously have required a much larger group.
“Traditional ‘sprints’ are replaced by ‘bolts’– shorter, more intense work cycles measured in hours or days rather than weeks; Epics are replaced by Units of Work.” - AWS
At Leighton, this has resulted in productivity gains of five to six times in some cases. Not because AI is magic, but because it is guided.The pod structure scales like a living system. A senior engineer grows into an architect‑developer, the pod splits, and two pods now operate independently. Juniors grow into seniors. The cycle continues. Specialised AI agents fill capability gaps in areas such as SEO, marketing, and pen-testing. Capability scales without headcount exploding.
This shift also changes how work is delivered. Traditional two‑week sprints feel slow when AI can generate working software in minutes. Leighton had already moved to a faster cadence before AWS formalised the AI‑DLC. When the guidance arrived, it simply gave names to practices that were already working at Leighton. Bolts replace sprints. Value is delivered continuously rather than in scheduled increments. Pods are small, autonomous teams that work with agency and urgency alongside AI agents to amplify the experience and knowledge in the team.
One of the most significant changes is the move towards semantic‑first engineering. Instead of relying on long and cumbersome Jira tickets that are often out of date by the time work begins, teams generate just‑in‑time specifications that capture the current understanding of the requirement. These specifications are refined with AI agents until assumptions are eliminated and approaches aligned. Steering documents ensure that the model builds using the organisation’s frameworks, patterns and standards. We are simply generating the code and solution faster, which was previously done by hand. The quality output is the same.
This approach is faster, more accurate and more aligned with how AI works. It also elevates organisational context to a strategic asset. The most valuable intellectual property in an AI‑driven organisation is not the codebase. It is the source context: the patterns, principles, frameworks and architectural guidance that shape how the AI agent builds. When shared across teams, this context ensures consistent, high‑quality outputs.
The cost of experimentation has also collapsed. Teams can build prototypes in hours, generate UI options live with stakeholders and iterate in real time. Customer journeys can be brought to life quickly and cheaply. This is not agile. It is something beyond agile.
The next frontier is generative‑native architecture. These are systems designed from the ground up to operate with AI in the loop. In such systems, a production issue might be detected automatically, a ticket raised automatically, a fix proposed automatically, code generated, tests written, a pull request opened and a deployment executed. Humans remain in the loop, but primarily as validators rather than executors.
“I built an AI agent which can analyse CloudWatch access logs and use the honeycomb.io MCP server to find root causes. It works extremely well and even correctly suggests the fix for any problems found. Nextup: triggering a Cursor Agent to implement the fix!” - Luc van Donkersgoed -AWS Hero
This is not science fiction. It is already happening. The organisations that adopt this model early will move faster, respond quicker and deliver more value with fewer people.
The future of software engineering is not about typing faster. It is about thinking better. AI has made tasks cheap. Purpose is now the differentiator. The architect‑developer embodies this shift. They are the person who can orchestrate AI, validate outputs and ensure that what is built is aligned with business value, technical standards and long‑term strategy.
”AI is very good at handling tasks, especially those that are repetitive or rule-based. However, it does not replace the core purpose of a role.” - Jensen Haung, CEO Nvidia
One of the most resonant ideas in this space captures the moment perfectly. AI will not replace you, but someone using AI will. The question for every organisation now is whether they are building teams of task‑doers or teams of purpose‑driven orchestrators.
At Leighton we’re working with our customers to help them better understand how they can integrate AI into their teams and workflows through our AI-driven workshop. If you’re interested in exploring how you can better enable your teams to deliver in an AI era we’d love to hear from you: hello@leighton.com.
The ground has shifted under software engineering, and it has happened almost overnight.
In the space of a few months, AI has moved from a clever assistant to a force that is reshaping how we design, build and deliver digital products. The change has been so rapid that it has split opinion across the industry. Some teams are already experimenting, discovering new levels of productivity and creative freedom. Others are wary, questioning the reliability of these tools and the wisdom of trusting them too quickly.
Both instincts are right. The moment demands curiosity, but it also demands scepticism. AI is astonishingly capable, but it is not infallible. It can accelerate delivery, but it can also accelerate mistakes.The organisations that will thrive are the ones that embrace the tools while maintaining a clear sense of responsibility for the outcomes. As one of the most telling observations in this space puts it, a tool does not absolve you of accountability. You are still responsible for what you build.
“The work is yours, not the tools” - Werner Vogels -Amazon CTO
This is the real story of AI in software engineering. It is not a story about replacement. It is a story about elevation.
For the past year or so, AI in development meant autocomplete suggestions and chatbots that could answer basic questions.
That era is already behind us. Modern integrated development environments (IDEs) now contain embedded AI agents that can scaffold entire services, propose architectural patterns, write tests, refactor codebases and reason about multi‑step tasks. The developer’s role has shifted from author to orchestrator. The keyboard is no longer the bottleneck. The bottleneck is clarity of thought and having access to the right engineering and architecture experience.
This shift does not diminish engineering skill. It amplifies it. The better you understand systems, the more powerful these tools become. The less you understand, the more dangerous they are. AI will happily generate an elegant, well‑structured solution to the wrong problem if you let it or generate a mass of technical debt disguised as a solution to your requirements.
The comparison with radiology is instructive. When AI entered that field, many predicted the end of the radiologist. Instead, radiologists became more productive, more accurate and more focused on the complex cases that required human judgement. AI handled the repetitive work. Humans handled the nuance. Software engineering is following the same pattern. AI is not replacing developers. It is freeing them to do the work that actually matters while also highlighting a potential skills gap as the importance of the quality and experience of engineers becomes paramount.
This shift has profound implications for how organisations structure their teams. The old model relied on large groups of developers manually producing code. But as Marc Brooker has pointed out, generating code is now a commodity. The cost of producing code has collapsed. The cost of producing the right code has not.
“The cost of turning written business logic into code has dropped to zero. At best, near-zero” - Marc Brooker - VP/DistinguishedEngineer at AWS
Organisations no longer need armies of coders. They need orchestrators. They need people who can translate business intent into technical direction, who can guide AI agents, validate outputs and ensure that what is built aligns with standards, strategy and long‑term maintainability. At Leighton, this role is known as the architect‑developer.
”20%–60% effort reduction in key coding and delivery tasks is reported in vendor/client evidence and inquiries; variability depend son tool maturity and context.” - Gartner
An architect‑developer is not a traditional architect who draws diagrams and steps away from the keyboard. Nor are they a pure coder. They are a hybrid: a cloud architect who still writes code, an experienced engineer with product instincts, a hands‑on leader who understands AI tooling and a systems thinker who can validate and steer outputs. They are the person who ensures the AI builds the right thing in the right way.
This role is M‑shaped rather than T‑shaped. It requires broad capability across architecture, engineering and product, combined with deep expertise in areas such as DevOps, domain‑driven design, full‑stack engineering and cloud. It is this shape that allows architect‑developers to lead small, high‑impact pods that move faster and deliver more value than traditional teams.
The traditional two‑pizza team – coined by Amazon founder Jeff Bezos – was designed for a world where humans wrote every line of code. But more people mean more communication paths, more handoffs and slower decisions. AI‑enabled teams flip this model. A small pod led by an architect‑developer can deliver at a pace that would previously have required a much larger group.
“Traditional ‘sprints’ are replaced by ‘bolts’– shorter, more intense work cycles measured in hours or days rather than weeks; Epics are replaced by Units of Work.” - AWS
At Leighton, this has resulted in productivity gains of five to six times in some cases. Not because AI is magic, but because it is guided.The pod structure scales like a living system. A senior engineer grows into an architect‑developer, the pod splits, and two pods now operate independently. Juniors grow into seniors. The cycle continues. Specialised AI agents fill capability gaps in areas such as SEO, marketing, and pen-testing. Capability scales without headcount exploding.
This shift also changes how work is delivered. Traditional two‑week sprints feel slow when AI can generate working software in minutes. Leighton had already moved to a faster cadence before AWS formalised the AI‑DLC. When the guidance arrived, it simply gave names to practices that were already working at Leighton. Bolts replace sprints. Value is delivered continuously rather than in scheduled increments. Pods are small, autonomous teams that work with agency and urgency alongside AI agents to amplify the experience and knowledge in the team.
One of the most significant changes is the move towards semantic‑first engineering. Instead of relying on long and cumbersome Jira tickets that are often out of date by the time work begins, teams generate just‑in‑time specifications that capture the current understanding of the requirement. These specifications are refined with AI agents until assumptions are eliminated and approaches aligned. Steering documents ensure that the model builds using the organisation’s frameworks, patterns and standards. We are simply generating the code and solution faster, which was previously done by hand. The quality output is the same.
This approach is faster, more accurate and more aligned with how AI works. It also elevates organisational context to a strategic asset. The most valuable intellectual property in an AI‑driven organisation is not the codebase. It is the source context: the patterns, principles, frameworks and architectural guidance that shape how the AI agent builds. When shared across teams, this context ensures consistent, high‑quality outputs.
The cost of experimentation has also collapsed. Teams can build prototypes in hours, generate UI options live with stakeholders and iterate in real time. Customer journeys can be brought to life quickly and cheaply. This is not agile. It is something beyond agile.
The next frontier is generative‑native architecture. These are systems designed from the ground up to operate with AI in the loop. In such systems, a production issue might be detected automatically, a ticket raised automatically, a fix proposed automatically, code generated, tests written, a pull request opened and a deployment executed. Humans remain in the loop, but primarily as validators rather than executors.
“I built an AI agent which can analyse CloudWatch access logs and use the honeycomb.io MCP server to find root causes. It works extremely well and even correctly suggests the fix for any problems found. Nextup: triggering a Cursor Agent to implement the fix!” - Luc van Donkersgoed -AWS Hero
This is not science fiction. It is already happening. The organisations that adopt this model early will move faster, respond quicker and deliver more value with fewer people.
The future of software engineering is not about typing faster. It is about thinking better. AI has made tasks cheap. Purpose is now the differentiator. The architect‑developer embodies this shift. They are the person who can orchestrate AI, validate outputs and ensure that what is built is aligned with business value, technical standards and long‑term strategy.
”AI is very good at handling tasks, especially those that are repetitive or rule-based. However, it does not replace the core purpose of a role.” - Jensen Haung, CEO Nvidia
One of the most resonant ideas in this space captures the moment perfectly. AI will not replace you, but someone using AI will. The question for every organisation now is whether they are building teams of task‑doers or teams of purpose‑driven orchestrators.
At Leighton we’re working with our customers to help them better understand how they can integrate AI into their teams and workflows through our AI-driven workshop. If you’re interested in exploring how you can better enable your teams to deliver in an AI era we’d love to hear from you: hello@leighton.com.
