Is the future of AI development spec-driven?
Every developer who has used an AI assistant knows the frustration of its limited memory. While chat-based tools are effective for simple, single-file tasks, they struggle with complex, multi-day projects. As Amit Patel, Director of Software Development at AWS, notes, "It becomes quite difficult to have enough context and enough memory... to remember what you did yesterday or two days ago... sometimes I forget what I told the agent to do three hours ago!"
This "amnesia problem" was the genesis for an agentic IDE built by his team at Amazon, which has quickly grown a vibrant internal community. Instead of an ephemeral chat, this new tool is built on the concept of "spec-driven development"—a formal structure that gives the AI persistent context and a clear plan.
This article explores this innovative approach, from its three-stage spec and structured task list to the developer-centric ergonomics that make it work, all built through a deeply iterative, community-driven process.
Spec-driven development: giving AI a plan and a memory
At the heart of this new approach is "spec-driven development," a formal, three-stage process that mirrors traditional software best practices. "Rather than remembering what the prompts were three days ago," Patel explains, "we're saying is... [we] will allow you to essentially build a plan, a structure for your project." This spec becomes the persistent "memory" that guides the AI agent.
The spec consists of three simple stages: requirements, design, and a task list. This framework provides just enough structure to keep the AI on track, which is key because, as Patel notes, "The less ambiguity you give it, the better the output will be." Developers can iterate on this spec (which is stored in Markdown) via chat or direct editing, preserving traditional workflows while radically accelerating them. This process doesn't circumvent best practices like design reviews; it enhances them. "Typically... it would take an engineer maybe 2, 3, 4 days to write a design doc," Patel says. "The benefit... is that you get the design doc in, you know, 10, 15 minutes and then you can just go and have that meeting."
The most powerful part of this model is the structured task list, which gives the AI its power for complex, multi-day projects. The task list provides a clear, persistent record of completed and remaining work, allowing a developer to step away for days and return, picking up exactly where they left off. Because the AI can see the full requirements, design, and which tasks are done, all of that context is available for the next step. The team validates this approach by "dogfooding" their own product to build new features, including for large-scale production projects like S3 components, proving its ability to handle mission-critical development.
A human-centered process: ergonomics and iteration
Building an intuitive and productive tool was a journey in itself, requiring "six attempts to get there," Patel acknowledges. This relentless focus on developer ergonomics was crucial for balancing the need for structure with the flexibility that different workflows require.
A perfect example of this human-centered design came directly from user feedback. An early tester noted that the agent could take 5-10 minutes to execute a complex task and they didn't want to "keep watching it do its work." They asked for a notification system. The team took this feedback and, in a powerful display of dogfooding, used the tool itself to build the notification system—completing in two days what they had estimated would take three to four weeks.
This focus on accessibility also guided key product decisions. The team made a "larger, more meaningful decision" to allow logins via Gmail rather than requiring an AWS account. This small change dramatically lowered the barrier to entry, making the tool accessible to all developers, not just those already deep in the AWS ecosystem.
This successful process was driven by a direct feedback loop. The team set up a Slack channel with its first 100 adopters, giving them nightly builds and, crucially, the time and space to engage. "We didn't cram the engineer's days with task after task," Patel shares. "We actually allowed them to be on Slack, engage with the customers... and get their inputs." This direct engagement, which expanded to include solution architects and other roles, allowed the team to filter feedback and build a tool developers genuinely wanted to use.
The future of AI is structured
The journey of building this agentic IDE highlights a fundamental truth for the next wave of AI development: a conversational chat interface is not enough. To tackle complex, real-world projects, AI needs what developers have always needed: a plan, a memory, and a clear set of tasks.
Amit Patel and his team at AWS have shown that by embedding traditional software discipline—requirements, design, and task lists—directly into the AI's core, we can solve its context problem. This "spec-driven" approach doesn't replace engineering best practices; it accelerates them, turning a four-day design doc process into a 15-minute review.
By focusing on developer ergonomics and building in lockstep with their community, Patel's team has built more than just a faster tool. They've built a more resilient, context-aware partner, offering a glimpse into a future where AI augments our own structured thinking rather than just reacting to our last prompt.
For the full story on building a structured, agentic IDE, listen to Amit Patel discuss these ideas in depth on the Dev Interrupted podcast.
