THE CHANGING SHAPE OF SOFTWARE DEVELOPMENT TEAMS

Agile software development framework has been the standard for highly collaborative and productive software development teams for twenty plus years. Two-week sprints, daily stand-ups, demos, and retrospectives have become the norm. Software developers were collaborating on the same codebase. That level of coordination and collaboration required a structure that focused on task requirements and coordinated, planned management. It broke big, ambiguous problems into small, achievable chunks. What everyone received from engineers to stakeholders was transparency of work being done and steady cadence of feedback.  

But the times, they are a-changin’ and the Agile operating construct is suboptimal for spec-driven development. Not only has the cost and speed of writing code changed dramatically, but more senior engineers are working independently and at a different cadence than other engineers working on the same product. When a senior engineer can orchestrate an army of AI agents to generate large amounts of working code, the point estimation and sprint planning doesn;t represent the new reality. The snippet of code that addresses a single task does not then get checked in or handed off to a Front-end engineer or designated QA engineer. So much of agile sprint planning is about defining capacity and workflow coordination between team members. That is no longer the measure of productivity, nor the coordination necessary between stakeholders. What every technical and business leader needs to understand is that spec-driven development, and the emergence of the forward-deployed engineer, is a different beast altogether.

From Sprint Planning to Spec Writing 

In Agile Sprints, the scope of every ticket is small, purposely broken down so that it can be confidently estimated and resources can be appropriately assigned.Someone usually writes a user story. The team together estimates it, and the details get worked out in the conversations that follow. It’s a really good approach when the person who is doing the coding is able to ask the questions, validate their assumptions, and course correct as they develop. Working with AI agents doesn’t work that way. An AI agent will consume a lot more data and produce more code in a lot less time. An agent will also run with ambiguous instructions. The output may be plausible-looking code, but it may not reflect what was actually intended. The ambiguity in requirements gathering and the questioning of business logic and data sources used to be worked out in conversations between collaborators. Now AI agents will plow through without any question. The cost of that ambiguity is now potentially in thousands of lines of code that may be subtly or significantly incorrect. 

This does not mean that we are going back to Waterfall development, but it does put the onus up front in the development process. We can no longer write brief requirements for a specific task. Instead, we must define a structured specification up-front. This will need to capture requirements, the business logic, the edge cases, and the validation criteria. The result must yield something that both a human and an AI agent can act on with clarity. The spec not only becomes the source of truth, but in essence it becomes the product. 

In practice, this is absolutely a redistribution of the effort. It is also a different skill set that is required to build software, or rather, it is valuing different skill sets for building software. Critical thinking and communication are core to this front-loaded phase. This is generally better demonstrated by more senior engineers. It also means that this phase is going to take longer than what we’ve become accustomed to with sprint planning. The execution of code writing is much faster, but the planning and the subsequent code reviews are going to be the more critical components. So don’t think that because we’ve been able to articulate product specifications extremely well and our agents are delivering them while we sip our coffee, that the review of that code is cursory. If anything, it raises the bar on those reviews.  

Someone still has to validate that the code actually does what the spec says. There is a common scenario where the code generated by AI is “almost right, but not quite”. Recent research bears this out. Sonar surveyed over 1.100 developers worldwide to see how software engineering is evolving. Nearly all developers (96%) express doubts about the reliability of AI-generated code. They acknowledge that AI often produces output that looks correct at first glance but contains subtle errors or hidden flaws. A Stack Overflow Developer Survey found that 66% of developers say they struggle with AI solutions that are close, but ultimately miss the mark. That leads to one of the most cited pain points: debugging AI-generated code, which 45% of developers say takes longer than writing it themselves. This doesn’t mean that AI is bad at coding. It means that the specifications it was given were lacking. This is very much the garbage in, garbage out scenario. 

The Forward-Deployed Engineer 

The Forward Deployed Engineer, or FDE, seems to be gaining popularity in conversations with tech executives. It is now becoming a topic multiple times a week with existing customers.If this term is new for you, it is a niche role defined by Palantir some time ago. At its core, this is a senior technical person embedded directly with a customer or business unit. This gives the engineer direct access to the end user, with no detail of the request lost in translation, and the ability to see the problem first hand. This puts the business logic. Closer to an engineer than the traditional agile development process would. FDEs are therefore empowered to build integrations and customizations before a “real” product feature exists for it. They also act as the feedback loop between what a customer actually needs and what the broader engineering organization builds next.  

The connection between FDEs and spec-driven development is not a coincidence. They both are the result of an underlying change. That change pushes more responsibility to more senior engineers who can translate business context into technical requirements. People who are the most capable at bridging the gap between what the business needs and what the software can do. The FDE is in effect doing spec discovery in real time. The hope is that they can quickly turn that discovery into a spec that agents can act on. This significantly compresses the time between when a problem is known and when a solution is delivered. Two-week sprint cycles can seem like an eternity when you have that level of access and the proper tools in hand. 

Why This Looks Different From What We’re Used To 

Agile sprints work well with distributed work across larger teams. It requires discrete tasks, frequent interactions, and allows for iterative refinement during development. Spec-driven development, where AI agents do the majority of the coding, is a more isolated endeavor. The reality is that we see more senior people with a much heavier investment in defining requirements and validation criteria long before the agents are given the orders to code. 

[Text Wrapping Break]This doesn’t mean that agile is going away, nor does it mean that the transition is going to happen rapidly across all development teams, companies, and industries. Most companies will find a blend where larger, more established products and codebases will continue to leverage their development teams in agile sprints as they work to modernize their applications. It is very likely that many of the new Greenfield projects will take on the spec-driven development model. And one can see how Forward deployed engineers can be used highly effectively for customer-facing issues, embedding the FDEs at call centers and in the field with representatives. [Text Wrapping Break][Text Wrapping Break]In Netcorp’s article, AI-Generated Code Statistics 2026: Can AI Replace Your Development Team? They lay out a number of insightful statistics. They put approximately 80% of software developers using AI coding tools daily or weekly. Another survey of engineering managers found that 90% of teams were already using AI in their workflows. This represents a 30% jump from last year. We are not at the early stages of adoption, but The development community is very much near all-in on AI-driven development. It is in your organization, it is in your code, and it is our responsibility to understand how to get the most out of it and protect any downside from AI-generated code. 

What This Means for Your Team — and What to Do About It  

The implications go far beyond the engineering process. Business executives who budgeted software development efforts against sprint velocity and headcount need to account for this front-loaded investment in spec-driven development. It likely means higher salaries or costs per hour for more senior engineers, but it will require fewer engineers and should translate into better quality products delivered faster at an overall lesser cost. That first phase in spec-driven development, the completed validated spec, is now a meaningful deliverable. It’s not just paperwork, but it can be difficult, as this is not a visibly ready demo that stakeholders are used to.  

Here are a few concrete steps worth considering:  

1. Determine where ambiguity lies. Look at your last few projects and identify where requirements were unclear at the start and where that ambiguity caused rework later. Those are your best candidates for a spec-driven pilot. 
2. Protect the time of your senior people. The engineers best suited to lead spec-driven work are often your busiest people. They are the ones called to fight fires and perform code reviews. If you want this shift to take hold, you need to free up these critical resources.
3. Build validation into your definition of done. As agents generate more code, your review and testing discipline needs to get stronger. Design your QA process around validating against the spec, not just checking that the code runs.
4. Consider where an FDE-style role could close your gap. If your team is consistently building the wrong thing because requirements get lost in translation between business stakeholders and engineers, an FDE approach may be just the ticket. Try embedding a senior technical person with the client or user and forgo simplifying hiring another implementation engineer.  
5. Set realistic expectations for the timeline. The front-heavy phase of a spec-driven project will take longer than the traditional sprint kickoff. Stakeholders will need to understand that the payoff happens in phase two: the build. Track that progress from your first project and socialize the results.  

Success here will not be measured by which teams adopted the most AI tools the fastest. It will be measured by the teams that figured out early how to get the thinking right, And who they leverage with enough proximity to the business to make that thinking count.