Software engineering teams have never had more tools intended to make them productive than they do today. AI coding assistants, inline completions, chat interfaces, autonomous agents, and intelligent development environments are now embedded across the software development lifecycle. Yet widespread access to these tools has not produced consistent results.
Some engineering teams report incremental productivity improvements. Others are delivering features several times faster than before. The difference is rarely access to a better model or another IDE extension. It is how completely the organization has restructured its development process around AI. That distinction matters as engineering capacity becomes increasingly constrained.
In this episode of AppDevANGLE, I spoke with Deepak Singh, Vice President of Developer Agents and Experiences at AWS, and Steve Terza, Director of Software Development at Amazon, about why AI tools alone do not guarantee productivity and how engineering teams are beginning to redesign software delivery around agents, specifications, structured context, and continuous automation.
Our conversation explored the gap between incremental and transformational AI adoption, the growing importance of spec-driven development, why trust is becoming the currency of AI adoption, and how software engineering may evolve as developers move from writing every line of code to coordinating fleets of increasingly autonomous agents.
AI Adoption Is Exposing a Software Productivity Paradox
The software industry is experiencing an unusual productivity paradox. AI development tools have become broadly accessible, but the performance gap between engineering teams continues to widen. Some organizations are seeing modest improvements of 15% to 30%, while others report gains measured in multiples.
According to Singh, the difference comes down to whether organizations treat AI as an additional tool or as the foundation for a redesigned engineering workflow. “You can use the same tools, but the results you get can be dramatically different,” Singh said.
Teams that apply AI to existing processes usually improve those processes incrementally. They write code faster, generate tests more quickly, and reduce some repetitive work, but the underlying structure of software delivery remains unchanged.
The larger gains appear when teams step back and reconsider the entire workflow. “The teams that have seen extraordinary gains are the ones that step back and rethink how things are done,” Singh explained.
This includes reconsidering how requirements are captured, how work is decomposed, how agents receive context, how tasks are handed off, how results are validated, and how developers interact with software systems throughout the day.
Terza described a similar pattern across Amazon engineering teams. Teams that “sprinkled” AI throughout their existing processes improved, but usually by percentages. Teams that rebuilt processes around AI achieved much larger changes. “The teams that said, ‘What if I started from scratch?’ and figured out the outcome they were trying to get to, but did that with AI at the center, really saw those step changes,” Terza said.
Across dozens of teams, Terza said the median improvement reached approximately 4.5 times the previous speed of feature delivery. The implication is clear: AI productivity is not primarily a tool deployment problem. It is an operating model problem.
Specifications Are Becoming the Interface Between Humans and Agents
As agents take on more software development work, specifications are becoming increasingly important. Traditional software development often relies on context distributed across meetings, tickets, design documents, code comments, chat conversations, and individual experience. Human developers can fill in many of those gaps through judgment and institutional knowledge. AI agents cannot reliably do the same unless that context is made explicit.
Singh described specifications as a mechanism for clearly communicating intent to an agent. “How can we give agents intent? How can we make sure they really know what to do? How can we give them the right context?” he said.
Instead of asking an agent to write a function or complete a narrow coding task, spec-driven development begins by describing the problem, requirements, expected behavior, constraints, and desired outcome. The agent can then break the work into tasks, implement the changes, and validate the result against the original intent.
This changes the developer’s role. Rather than spending most of the day translating requirements directly into code, engineers increasingly spend time defining outcomes, reviewing specifications, structuring context, and evaluating results.
Terza offered a practical example involving Amazon’s “Add to Order” feature, which allows customers to add another product to a shipment already in progress. The feature was delivered approximately two months earlier than its original estimate after the team adopted spec-driven development. The team still completed a design phase, but it documented the desired behavior, visual experience, and feature requirements before handing execution to Kiro.
“They had to shift the way they thought about developing,” Terza said. “They wrote down, ‘This is what I want it to do. This is what I want it to look like,’ broke it down into features, and handed it off.”
This does not eliminate human oversight. Developers still review outputs and confirm that implementations meet expectations. However, it allows teams to delegate larger units of work without continuously guiding the agent through every step. The result is a shift from synchronous coding assistance toward asynchronous engineering execution.
Context Is Becoming a Core Software Engineering Asset
The quality of an AI agent’s output depends heavily on the quality of the context it receives. Foundation models may contain broad knowledge about programming languages, frameworks, and common development patterns. They do not inherently understand an organization’s architecture, coding standards, deployment practices, internal tools, business requirements, or team norms.
“What we see happening and working very well is the teams that focus on getting the process knowledge that is in folks’ heads written down and shared,” Terza said. That knowledge may take the form of steering files, specifications, markdown documents, custom agents, architectural guidelines, or repositories of reusable instructions.
The format matters less than the outcome: organizational knowledge must become legible to machines. This requires deliberate effort. “It’s not free,” Terza said. “You have to put the time into getting this into the right place. But it pays off multiple times in dividends.”
Once teams document their workflows and expectations, agents can complete tasks with greater accuracy and consistency. Instead of returning code that is technically valid but operationally misaligned, the agent is more likely to produce something that matches the organization’s actual intent.
Singh described how teams at Amazon are beginning to encapsulate internal processes inside custom agents that combine Kiro with metadata, steering files, and organization-specific context. Those agents can understand a particular team, application, codebase, or business domain.
The broader market implication is significant. For years, enterprises treated documentation as an important but often neglected engineering artifact. In an agentic development model, documentation and structured context become production infrastructure.
Organizations with well-maintained specifications, clear architectural standards, and machine-readable development practices will be able to delegate more work to agents than organizations whose knowledge remains trapped in meetings and individual employees’ heads.
Context is therefore becoming a compounding asset. Every process captured today can improve the performance of future agents, tasks, and engineering teams.
Trust Is the Currency of AI Adoption
The productivity benefits of autonomous development depend on whether engineers trust the results. Without trust, developers will continue to supervise every action, inspect every intermediate step, and effectively babysit the agent. That limits the amount of work an agent can absorb and reduces the potential productivity gain.
“To stop babysitting an agent, you have to trust it,” Singh said. Terza expressed the same principle more directly. “Trust is the currency of AI adoption,” he said. “If you can’t trust the agents, if you can’t trust the outputs, nobody’s going to use it.”
Building that trust requires more than better prompts. Agents need high-quality context, clear requirements, deterministic validation where possible, automated testing, and mechanisms for identifying ambiguity before implementation begins. Singh described an example in which an agent receives requirements indicating that something should have webbed feet and a tail. Those details could describe either a duck or a platypus. A reliable system should identify the ambiguity and ask clarifying questions before proceeding.
This is where AWS is applying what Singh described as neurosymbolic and automated reasoning techniques. Large language models remain probabilistic, but more deterministic methods can evaluate requirements, identify inconsistencies, and improve assurance around generated outputs.
That combination may become increasingly important as AI-generated code moves into production systems. Enterprises will not rely exclusively on probabilistic models for software assurance. They will combine generative agents with testing, policy enforcement, formal validation, security controls, and deterministic reasoning.
The goal is not to remove humans from engineering. It is to create enough confidence that people can move from supervising every keystroke to evaluating outcomes.
Developers Are Becoming Coordinators of Agentic Workflows
As agents become capable of running for hours or days, the interface between developers and software development systems will also change. Today, most AI development tools remain centered on the IDE or command line. Developers typically interact with agents from a laptop, watch them execute, and respond when intervention is required.
That model becomes less practical as agents operate for longer periods and multiple agents run concurrently. “The best customers that we have spend their days setting things up, and then for hours they run these things,” Singh said. This begins to resemble an operational control problem rather than a traditional coding workflow. Developers may need dashboards that show what agents are doing, which tasks are blocked, where human approval is needed, and whether outputs are meeting policy and quality requirements.
Singh compared the emerging experience to air traffic control. Kiro Web represents one direction for this evolution. According to Singh, tasks can run in cloud sandboxes rather than on a local laptop, allowing developers to submit work, close their computers, and continue monitoring execution from another device. The deeper significance is not the device itself. It is the separation of software execution from the developer’s immediate presence.
When agents can securely operate in remote environments, access approved repositories, follow team-specific steering instructions, and run independently, software development becomes increasingly asynchronous. Engineers may begin their day by defining objectives and launching tasks, then spend their time reviewing designs, resolving ambiguity, making architectural decisions, and approving completed work.
Singh also described an internal workflow in which an agent reviews Slack conversations, tickets, and meeting notes overnight before producing a prioritized task list for the team’s next stand-up. This example illustrates how agentic development extends beyond code generation. Agents can support planning, triage, documentation, testing, modernization, and operational coordination across the entire engineering lifecycle.
The future developer experience may therefore be less about writing code faster and more about orchestrating a portfolio of intelligent systems that perform engineering work continuously.
Analyst Take
AI coding assistants are quickly becoming standard. AI-centered software delivery is not. That distinction explains why organizations using similar tools can produce radically different outcomes. Incremental adoption improves individual tasks. Developers can write code faster, generate documentation, produce tests, and troubleshoot problems more efficiently.
Transformational adoption changes the structure of the work itself. It replaces implicit knowledge with machine-readable context. It moves requirements into formal specifications. It allows agents to execute larger tasks without constant supervision. It applies automated reasoning and validation to increase trust. It separates development work from the physical IDE and enables agents to operate asynchronously.
The most important shift may be the changing role of the software engineer. Developers are not disappearing, but the highest-value engineering activities are moving further away from routine implementation. Architecture, intent definition, context management, validation, orchestration, and judgment become more important as agents absorb more execution work.
This transition also creates a new divide between organizations. Enterprises with fragmented documentation, inconsistent processes, unclear ownership, and large amounts of tacit knowledge will struggle to scale agentic development. Their agents will require more supervision and produce less reliable results.
Organizations that invest in specifications, reusable context, automated assurance, and AI-native workflows will be able to delegate more work and compound productivity gains over time. The next phase of AI software development will not be won by the teams with the most coding assistants. It will be won by the teams that redesign how software gets built.
