AWS AI-DLC — Where It Differs from My View of Agentic Development

TL;DR

• AWS AI-DLC differs substantially from my view of agentic development across concept, process, and implementation.

Introduction

I have long been thinking about how my current role differs from the direction I believe in.

The people I work with are still exceptionally capable and kind, and the company offers substantial stability and opportunity, which is precisely why I have thought about it for so long.

For the past year, I managed to avoid taking the lead in communicating ideas far from my own perspective. I chose other topics, explained only the parts I agreed with, or shared my different view only with a few people close to me.

Then AI-DLC (AI-Driven Development Life Cycle), AWS’s approach to developing software with AI, began spreading with more detailed procedures and tools. It became increasingly difficult to avoid.¹²

Senior employees are expected to understand the company’s direction, help junior colleagues act on it, and deliver the results the company wants.

The problem is that I cannot find the motivation to actively advocate ideas that remain far from my own perspective.

Staying for title and stability while lacking confidence in the direction—doubting it in private while asking colleagues to pursue it in public—would not be honest with either the team or myself.

If I cannot actively communicate a direction I do not believe in, I am not fulfilling the role expected of me as a senior employee.

I want to explain where AI-DLC and my own view diverge, and why that difference has led me to reconsider my current role. These are my personal views, based on public material and my experience, not an official AWS position.

I began as a developer. Even after becoming a Solutions Architect (SA), helping customers choose technologies and design systems, I continued to build, deploy, and operate my own services. I tend to feel a stronger need to run one product over time and live with the consequences of my decisions than to observe a broad range of customer problems.

An SA with a different background and set of strengths may interpret the same role very differently.

My view differs from AI-DLC in three areas: Concept → Process → Implementation.

The future we aim for shapes how we divide and repeat work, and those choices carry through to the tools and environments we build.

flowchart TB
    subgraph A["My interpretation of AI-DLC"]
        direction LR
        A1["Concept<br/>People at the center"] --> A2["Process<br/>Review and approve together at each stage"]
        A2 --> A3["Implementation<br/>Tools prescribe work procedures"]
    end

    subgraph B["The direction I believe in"]
        direction LR
        B1["Concept<br/>Agents at the center"] --> B2["Process<br/>Build a little and get feedback"]
        B2 --> B3["Implementation<br/>Provide tools, permissions, and checks"]
    end

1. The Conceptual Difference — Keeping Humans at the Center

In an earlier post, I chose a way to judge the direction of agentic engineering: giving development work to AI agents that use tools to carry out tasks.

I think the long-term direction of agentic engineering is to remove the human in the loop, or HITL—the need for people to keep stepping in while the agent works.³

That does not mean removing every person immediately, but resolving the work people have to handle because the agent lacks data access, permission to act, or a way to check its results. Looking at tasks that need help from another team in the same way can expand what the agent can finish on its own.

AI-DLC begins from a different premise.

In the official introduction, AI plans and executes while people make important decisions. The team meets to check AI-generated requirements and designs as they are produced, in sessions called Mob Elaboration and Mob Construction.¹

The more recent adaptive workflow chooses which stages are needed and how much detail each requires for the task, so a simple bug fix and a new system do not have to follow the same procedure. This is a clear improvement over the initial version.

Even so, human approval remains central rather than exceptional.

The official article also says people are needed to check whether AI’s results can be trusted, who is responsible, and whether the results are correct. It therefore requires the team to review and approve the results together at every stage.²

This approach can be useful for a team running its first workshop with AI, or for an organization that must make clear who is responsible for what to meet regulatory and audit requirements.

However, I think teams building real services in the future will remove the reasons a person is currently required, one by one.

If data is scattered and a person has to find it, connect it so the agent can find what it needs. If a person has to act because the agent lacks permission, build a tool with only the permissions it needs.

If a person must read every result because it cannot be trusted, define what the result must satisfy, check it with tests, and use logs and measurements to see how the system actually behaved.

Assuming a person will always check the work makes it easier to leave data access and permission problems unresolved, with people continuing to handle them.

The two organizations may look similar today, but I think they will look completely different in two or three years.

flowchart LR
    S["Today<br/>Work handled by people"] --> A1["Agent-centered organization"]
    S --> H1["Human-centered organization"]

    A1 --> A2["Provide data access, permissions, and checks"]
    A2 --> A3["Reduce work that needs a person"]
    A3 --> A4["More work can be automated"]

    H1 --> H2["AI writes documents and code"]
    H2 --> H3["Humans review · approve each stage"]
    H3 --> H4["Limited by how much people can check"]

Suppose that three years from now it has been sufficiently proven that agents can take over major tasks.

Starting only then to connect data held separately by teams, give agents the permissions they need, and provide ways to check their results may be too late. Models change quickly, but how a company manages data and assigns responsibility does not change at the same pace.

This is where the future I expect and the concept behind AI-DLC diverge.

Kiro’s published Frontier Engineering guide points in the same direction. Its second principle is to maximize agent time while minimizing human involvement, and describes the goal this way:⁴

“The goal is to progressively remove yourself from the loop”

People set the direction and verify the outcome, while agents handle the repeated implementation, testing, and fixes in between.

2. The Process Difference — Making the Big Loop Run Faster

What I have found most powerful about developing with AI is the ability to shorten the cycle of defining requirements, building, testing, and receiving feedback to something close to real time.

In the past, even an attempt to test a small version of a product often stopped at drawing screens on paper or showing a simple screen layout.

Today, even with temporary substitutes for some functions and data, we can connect existing code and real screens to make something close to the service. Users can try it first, then decide what they need next.

The software development life cycle (SDLC) covers planning, building, and operating software. Consider an approach that collects requirements in one batch before design and development: it resembles bending a hundred-meter wire into one large circle.

Requirements are collected, the system is designed, development and testing follow, and the circle closes for the first time only at the end.

My model of agentic development looks more like stacking ten-meter circles into a spring.

Each circle is a small feature built from the screen through to the processing behind it so a user can try it from start to finish, a unit called a vertical slice. The circle can be smaller or larger depending on the problem.

flowchart TB
    subgraph BIG["Compressing one large loop"]
        BR["Many requirements"] --> BD["Design · planning"]
        BD --> BI["Batch implementation"]
        BI --> BT["Integrated testing · review"]
        BT --> BF["Late product feedback"]
    end

    subgraph SMALL["Closing small loops continuously"]
        S1["Small requirement"] --> P1["Working result"] --> F1["User feedback"]
        F1 --> S2["Next small requirement"] --> P2["Next result"] --> F2["Next feedback"]
    end

Because people can try the product, become familiar with it, and decide what they need next, they do not have to list requirements in a meeting room for something nobody has ever seen. This reduces cognitive load: the mental effort of imagining the whole product and making decisions about it.

Reviewers can also inspect one newly added behavior and its evidence instead of reconstructing the whole product at once.⁵

The AI-DLC processes I have experienced felt closer to using AI to make the existing large loop run faster than to replacing it with many small loops.

The process I prefer instead repeatedly closes small loops of requirements, working results, and user feedback.

The official methodology does use short work periods called bolts and divides the work into small Units of Work. The adaptive workflow also skips unnecessary stages.

Yet the people involved still meet at each stage to build a shared understanding of the problem and its background, review AI-generated plans and results, and approve moving to the next stage.

The total duration can fall, but compressing the same volume of requirements, design decisions, and review into less time can increase human cognitive load.

When AI sharply reduces implementation time, coding becomes a small part of the schedule, exposing product decisions, review, and launch approval as the next bottlenecks. I observed the same shift while examining Amazon’s internal Frontier Development cases.⁶

Participants in AI-DLC workshops often said that bringing stakeholders together reduced communication overhead.

That effect matters, but it may come as much from Amazon’s team culture as from AI-DLC itself: the Two-Pizza Team approach keeps teams small so they can decide quickly, while DevOps has teams share responsibility for building and operating the software.⁶

If good collaboration culture and the effect of the methodology are treated as the same thing, it becomes difficult to know what another organization must reproduce.

3. The Implementation Difference — A Harness That Prescribes the Order of Work

These differences also show up when the way of working is built into tools and their execution environment.

Here, a harness means all the things a model needs to do its work: background information, tools, access permissions, a place to run code, and ways to check the results.⁷

The longer an agent works without a person, the more it needs a good harness, but I think it is useful to distinguish two roles a harness can play.

One approach divides work among agents with different roles, such as a Planner to make plans, a Critic to find problems, a Reviewer to check results, and a Reflection Agent to look back over the work; another has people prescribe how work should be broken down. These procedures can help with problems a model struggles to solve on its own.

A strong model can choose a different first action for each problem.

It may read the error log immediately, run tests first, or look through the code’s change history to find when a problem began. Some problems need a short plan, while for others, writing a long plan is itself a waste of time.

If the harness always forces Research → Plan → Break down tasks → Implement → Review → Reflect, it decides in advance how the model must solve the problem.

I use Harness Debt to describe rules created to help an older model that remain in place and get in a newer model’s way.

Kiro’s tenth principle also says to revisit workarounds for an older model’s weaknesses when a new model arrives.⁸ I read this as a reminder that removing constraints that are no longer needed matters just as much as learning from failures and adding useful instructions and tools.

flowchart LR
    M1["Earlier model<br/>Struggles to solve problems alone"] --> H1["People prescribe a complex work order"]
    H1 --> G["Performance improved at the time"]

    M2["New model<br/>Better at solving problems alone"] --> H2["Old work order is still enforced"]
    H2 --> D["Cannot choose a better approach<br/>Harness Debt"]

    M2 --> E["Provide an environment for the work"]
    E --> T["Provide tools, permissions, and checks"]
    T --> J["Let the model choose the solution strategy"]

Pi, which has recently attracted attention, describes itself as a “minimal agent harness”: a harness with a small set of basic features. Users can add features through extensions, task instructions through skills, and reusable requests through prompt templates to create their own workflows.⁹

That freedom is appealing, but with the latest models, making more changes yourself does not guarantee better results, because a procedure you design may stop the model from choosing a better approach.

Fixed procedures may be needed for payment and financial tasks with work sequences and approval rules that must be followed, but whether all software development should work that way is a separate question.

Because the organizations behind Claude Code and Codex develop both models and agent products, they can test which information and instructions to provide and which decisions to leave to the model with each new release.

Anthropic also says it is difficult to predict what information and instructions future models will need. In Managed Agents, it therefore separates and connects the session, which manages work records; the harness, which helps the model do the work; and the sandbox, an isolated place to run code.¹⁰

OpenAI’s Codex case also includes written plans, reviews between agents, and repeated fixes. What caught my attention was the environment: it automatically checks code structure and rules, and lets agents inspect the application UI and logs themselves.¹¹

A harness should provide the playing field, not decide how the model plays the game.

The harness decides which code repositories the model can read, where it can run commands, which data it can access, which actions are forbidden, and which tests it must pass.

Within those boundaries, the model should choose how to solve the problem whenever possible.

Kiro’s eighth principle similarly recommends limiting access to the files, tools, and network the agent needs, then letting it work without constant supervision. Its statement that “Every guardrail you automate is one less reason to stay in the loop” is close to the role I expect a harness to play.¹² Approval remains for actions that cannot be undone, while the system takes over checks that previously required a person each time.

AI-DLC’s adaptive workflow greatly reduces the problem of applying the same procedure to every task, but the tools still prescribe what to produce at each stage, when to get approval, and when to review the work together. In that sense, I think they still prescribe how the model should think and in which order it should work.

As models improve, I think we should revisit the work sequences and solution strategies prescribed by the harness, and delegate more of those decisions to the model.

4. Real Results Are What Challenge My View Most

If I were completely certain up to this point, I could simply continue in my own direction. The hardest part is something else.

More cases than I expected keep appearing in which teams built real services and achieved results with AI-DLC.

An AWS article connects AI-DLC with parts of the process used by six people to build Bedrock Mantle in 76 days. The article also describes an early adoption case at a European financial institution, where one product owner and three developers delivered up to 35 features per sprint—a fixed period of work.¹³

But Mantle’s success alone does not prove that the full AI-DLC methodology caused those results.

The project combined excellent engineers, fast decisions, and good internal tools with the chance to build a new system rather than change an existing one. The public article itself carefully says that some of the processes and tools used for Mantle are now parts of AI-DLC.

The result still exists.

Whenever I hear similar stories, I wonder whether I have missed another reason for those results. I also question whether I am assuming that what happened in my personal projects applies to other teams.

At times, I cannot tell whether I am overvaluing my experience or undervaluing the results described inside the organization.

I do not think I can resolve that question from my current position, because my role is closer to explaining AI-DLC and helping customers adopt it than to running one product and team for years and taking responsibility for the results.

I do not want to decide which approach works better under which conditions from presentations and workshop reactions alone.

I want to choose a real customer problem, lead a team, launch a service, and experience the outages and problems within the organization that follow before reaching a conclusion.

I think I need to run a product with a real team and live with the consequences of my decisions to find the limits of my perspective.

5. Breadth Alone Has Not Satisfied My Need for Depth

There is a video from a 1992 MIT talk in which Steve Jobs discusses consultants.

Jobs argues that seeing many companies is not enough if you never implement your recommendations or live with their results and failures over time. His analogy is that you may have seen many pictures of fruit without ever tasting it.¹⁴

I do not want to turn that into a judgment of every SA. Working with customers over time and revealing recurring patterns and options across companies are real forms of expertise.

But one question remains for me: Do I experience the operational consequences of my recommendation? I invest my own time and money in services with roughly 200,000 and 100,000 lines of code and take responsibility for their operations, but they are not official customer cases.

Working on a range of customer problems as an SA has been valuable. What I need now is the experience of leading a team and running a product over time, then using the failures and operational results to inform my next decisions.

I have also seen people in product organizations who only complete assigned tickets and collect a paycheck without caring about the outcome. Owning an outcome requires staying involved from problem definition through operation.

As AI narrows the differences in people’s ability to write code, I think it becomes more important for a team to share the problem and its background, check results, and improve the harness so the same failures do not happen again. Amazon’s account also describes changes in these working practices among the teams with larger gains.⁶

I want to work with a team that runs a product together and uses what went wrong to inform its next decisions.

Conclusion

AI-DLC can be a practical answer for organizations adopting AI for the first time or needing strict control over approvals and responsibilities. I still believe, however, that agentic engineering will move toward removing the reasons people were required in the system rather than positioning them more effectively at its center.

What exhausts me most is not disagreement itself, but having almost nowhere to discuss these ideas comfortably. Before we can talk about the customer problem, I spend most of my time and energy explaining why people should have to step in less often, and why we should build small pieces and get feedback frequently.

A team with firsthand experience of agentic engineering would not need to agree on every conclusion. Having been through similar work would let us focus more on how to solve the customer problem and change the way we work and the harness we use.

My goal is therefore to change jobs by the end of the year. More than a company name or title, I want a team that takes customer problems seriously and shares responsibility for operations. I would also like to learn new development practices and share them with colleagues on a team whose view of AI’s future fits mine.

If I cannot find such a team, I am also considering starting a small company that uses AI to try the Lean Startup approach of building something small, seeing how customers respond, and using that to decide what to do next.¹⁵ Taking responsibility for everything from choosing the customer problem to developing and operating the product would let me find out whether my ideas work.

I am now looking for a team where I can find out whether my ideas hold up when we work on real customer problems.

• #career
• #ai
• #agent
• #agentic-development
• #ai-dlc
• #harness-engineering
• #hitl
• #solutions-architect