The major increase in the speed of writing software is no longer the only challenge facing development teams. As tools such as Cursor move from suggesting code inside the development environment to executing complete tasks based on specifications and tickets, the problem may become the organization’s ability to determine what is worth building, test it, deploy it safely, and then operate and maintain it.
This is the focus of Hannah Foxwell’s presentation, “Reinventing the Development Team,” which focuses more on the impact of agentic programming on people and processes than on the capabilities of the agents themselves. Foxwell builds her argument around three principles that she believes remain important regardless of how much the tools accelerate.
From a Lack of Speed to an Excess of Capacity
Foxwell describes a trajectory that began with teams releasing software twice a year, then moved through Agile, cloud computing, DevOps, and continuous delivery to multiple deployments per day. She believes that what was once presented as a distant goal—high speed—has begun to become a reality that organizations do not yet know how to exploit.
In the agentic programming model, agents can break down specifications, write code and tests, and then help with deployment and monitoring. But this capability may create reverse pressure on product management: development teams may execute work faster than the organization can provide clear, qualified requirements. Foxwell therefore does not see the solution as accepting every idea or request, because that could lead to bloated products with weak focus.
Principle One: Build What Is Worth Building
Foxwell emphasizes that code is not the goal, but a means of solving a real problem for the user. As the cost of testing ideas falls, it becomes preferable to create prototypes and try them with users before turning them into a long-term commitment within the product.
Among the patterns presented in the article is the “product manager who programs prototypes,” which shortens the distance between an idea and its testing, or pairing a product manager with a developer when an idea exceeds the capabilities of rapid prototyping. It also points to the role of the field engineer, an engineer who works close to the customer and is empowered to solve their problems, as well as the “product engineer,” who participates in shaping the product because they use it or are close to its users.
Foxwell presents experiments involving a reconsideration of team size and composition. Instead of the model of a team consisting of six to eight developers and one product manager, some organizations are testing smaller teams, while Andrew Ng proposed the opposite model, with two product managers for one developer capable of coordinating a fleet of agents. These models are not presented as fixed rules, but as experiments reflecting a shift in the bottleneck from development capacity to requirements clarity and decision-making speed.
At the same time, the article warns against practices such as shipping a feature and immediately moving to another task without reviewing its use, accepting every customer request, or treating the opinion of the highest-paid person as the standard for prioritization. In an environment where writing software becomes faster, user research, user experience, and the ability to verify value may become more important differentiators than execution speed itself.
Principle Two: Speed Needs Safety
The increase in the volume of changes requires a production path capable of keeping pace with them. Foxwell warns that gaps in test coverage and manual steps may turn the deployment pipeline into a bottleneck, causing changes to accumulate before reaching users.
The article therefore connects speed with automated testing, pointing to examples of using agents to create continuous tests and help teams address technical debt, migrate from legacy platforms, and refactor codebases. The idea is not to add artificial intelligence on top of a slow process, but to re-engineer the path to production so that it can handle the new rate of change.
Foxwell stresses that reliability and security are not acceptable trade-offs for speed. She proposes relying on service-level indicators, service-level objectives, and error budgets, along with a written policy defining what the organization will do when the acceptable failure level is exceeded—for example, slowing releases or directing resources toward reliability and resilience.
She also believes that gradual deployment, feature flags, A/B testing, and blue-green deployment help manage numerous changes without exposing all users to them at once. She reconsiders the role of site reliability engineering teams and internal platforms, viewing them as consultative and enabling functions that provide a safe, paved path for development teams.
What Changes in Practice?
The editorial conclusion from the presentation is that agents alone do not prove that development teams will become smaller or that jobs will disappear. What is certain is that the bottlenecks will shift: from producing code to selecting problems, validating value, expanding testing, controlling reliability, and making decisions quickly.
The open question is whether organizations will use the new capability to build better products and test their ideas, or respond to it by piling on more features. The new ratios among developers, product managers, platform teams, and reliability teams are also still experiments, not proven results. For this reason, adopting agentic programming requires measuring its impact on product quality, incidents, and user experience, rather than relying solely on line counts or release speed.