Fully autonomous AI code generation is the future… for certain types or work. In my Calibrate Autonomy to Stakes article, I talk about the two variables for deciding how autonomous to make your code generation; stakes and reversibility. In this article, we are going to only talk about the work whose stakes are low enough and reversibility is high enough to merit fully autonomous code generation.
AI DLC
Amazon has been experimenting with how to evolve the Agile method into something that addresses the shift in constraints that is occurring due to AI accelerating software development. Some of the more popular Agile methodologies, such as Scrum, are all optimizing around the human constraint.
Amazon’s current answer to this is the AI DLC [details | Github]. AI DLC is a method of software development where 2 week sprints are collapsed to 2 day bolts and teams split into pods with one engineering, one product manager, and one designer. The workflow uses Markdown files to guide the AI, and your pod, through Inception, Construction, and Operationalization phases.
Essentially, it is a structure for Spec-Driven Development [ref | ref]. Spec-Driven Development is just writing up requirements and having the AI build to them. This is not much different than pre-AI methods. However, now the detail and structure of those specs are much more important.
How did AI DLC work for me?
Very well.
My first attempt at using the AI DLC was on a solo project. This might sound against the method but I was fully qualified to act as a solo builder, in this context. I am the product manager and expert on the product that I was building for and I had personally built the prototype that I was intending to mutate. My gap in engineering knowledge for certain parts of the system was actually a boon for this test because it showed off a cool feature of the process.
The project
I manage a Menu product including its web-base menu management application. I had prototyped an MCP server that leveraged HTTP calls and the Chrome browser MCP to interact with the Menu Admin page to create and modify menu items.
This MCP server proved useful enough that we are further investing in the discovery. My next step was to begin understanding how the lower level systems would function and what scope would be needed when it came time for a production build. Therefore, I endeavored to rewrite the MCP using our back-end APIs, including creating new API endpoints, handling authentication, and dealing with eventual consistency concerns that were ignored in the first prototype.
The process
The AI DLC’s “Adaptive Software Development Workflow” is very well thought out and guided the entire experience.
The inception phase includes:
Purpose: Planning, requirements gathering, and architectural decisions
Focus: Determine WHAT to build and WHY
Stages in INCEPTION PHASE:
- Workspace Detection (ALWAYS)
- Reverse Engineering (CONDITIONAL – Brownfield only)
- Requirements Analysis (ALWAYS – Adaptive depth)
- User Stories (CONDITIONAL)
- Workflow Planning (ALWAYS)
- Application Design (CONDITIONAL)
- Units Generation (CONDITIONAL)
I spent around 90 minutes in the inception phase. The AI and workflows worked me through a through extraction of my requirements and many functional and non-functional criteria. The second bullet, Reverse Engineering, was tested thoroughly in this experiment because 1) I asked it to reproduce the same feature surface area as the original prototype, and 2) I asked it to reverse engineering half a dozen services across multiple repositories.
90 minutes is not a lot and the plan was high quality along with me being left feeling fully drained of any context that I could provide it.
The construction phase looped through each pre-defined unit of work in sequence and often paused to interact with me. The uncommon occurrences were to ask for decisions due to newly uncovered information. The most common occurrences were at the end of each unit of work for me to verify and validate it’s progress before granting permission to move forward.
The results
In the end, this was a success. The MCP server worked, it’s architecture fit in with our local development environment and was later connected to another team’s chat bot UX for end to end use case and workflow testing.
The good:
I enjoyed the structure of the experience and I’d love to adopt a lot of the rule sets in the repo along with its method of making rules extensible to any organization or project that has specific needs.
My two complaints:
Single threaded
I do not know how well this would work with a pod of people. I could see collaborative discussion early on when defining requirements. However, there is no means of working in parallel for any small stretch of time. Especially during the construction phase, I don’t see much point for more than one person to manage the AI through it’s build. That person should be the engineer and others could just be pinged if any questions come up.
One iteration
This method seems to lend itself to only a single iteration. You could never automate this process or loop over multiple pieces of work. It also doesn’t seem to be designed to read in project tickets or pull work from any external system. Naturally, you could ask it to do that during your conversation but the flow is assuming that all context will be inputted during the inception phase. Very little, if any, pre-work is assumed. I’m not sure how many product people would define features on the fly like this.
If the goal is to leverage AI to it’s fullest, I think that the future lies with splitting these phases up into very different components or harness. For example, the inception phase might help people document requirements in spec format and build the units of work into Jira tickets or whatever your core work platform is. Then, a loop harness can pull tickets from your backlog and work them. Finally, the operational phase would be a completely different set of instructions and agents that ensure good productionalization prior to release.
In the second part of this series, I will tell you about my experiment building a loop agent to do just that.
Leave a Reply