
Software engineers are spending less time writing code and more time shaping the systems that guide AI tools. This change is forcing teams to reconsider their roles and how they measure success.
The problem with fixing AI-generated code
At PlatformCon London this summer, Patrick Debois, a member of technical staff at Tessel and founder of the DevOpsDays global event series, said developers should stop correcting AI-generated code line by line. They should instead focus on improving the underlying systems that provide context to AI agents.
Debois stated, “If the agent didn’t do what you want, stop correcting the code. Improve the system, not the prompt.” The adjustment reflects a move from predictable workflows to those where results depend on context and iterative feedback.
He compared the transition to the rise of DevOps in the late 2000s. Just as operations teams once adapted to developer practices, engineers now must adjust to AI-driven development. The software development lifecycle, he explained, is becoming a “context development lifecycle.” This lifecycle has grown from a single CI/CD feedback loop to a series of concentric loops around generating, evaluating via test-driven development, distributing context as a package, and observation.
From individual fixes to team-wide systems
The change isn’t just technical. It also requires organizational adjustments. Debois noted that context—such as business rules, API specifications, or team workflows—must be shared and standardized. If one engineer optimizes their AI prompts for personal use, it may not work for the rest of the team.
“When you’re optimizing for A, and we’re optimizing for B, let’s make sure that the whole context that we give is optimized for the whole team,” Debois explained. The aim is to move from temporary fixes to solutions that work across the entire platform, storing context in repositories rather than scattered across messages or individual devices.
Most companies didn’t adopt AI overnight. Like cloud adoption or microservices, the process is gradual. The challenge lies in recognizing when a tool or process is ready to expand. Debois described a common pattern: an engineer experiments with AI, a team adopts it, and eventually, the practice becomes part of the company’s infrastructure.
Related: Mid-2026’s Coolest Semiconductor Startups
Scaling context isn’t just about technology. It also depends on people. Debois said AI tools create opportunities for change, but only if teams work together. “The fundamental change is the system, not the prompt,” he continued. “And then look for collaboration directions from solo to sharing things, and now working on the [context building] as a team together.”
Instead, he recommended building infrastructure that supports reliable, autonomous agents. Over time, agents develop ways to detect failures and adjust without constant human input.
Such systems shouldn’t be built alone. Debois compared them to shared pipelines, where teams agree on testing and verification standards. The result is better coordination—not just between AI agents, but between teams.
The shift resembles earlier industry changes. Just as DevOps broke down silos between development and operations, context-driven development could redefine engineering work. The difference this time is that the tools are learni
Debois also noted the industry’s habit of adding more AI to solve problems. “If there’s a problem with AI, we just use more AI,” he said, describing how some teams rely on AI to evaluate AI-generated code without testing it. That method has limits. A better approach, he argued, is to embed requirements directly into the context so agents understand expectations before generating output.
For now, most organizations are still figuring out the best approach. Multiple pipelines exist, and feedback loops differ between teams. But Debois sees a clear path forward: building systems that don’t just generate code but improve over time.
Similar shifts are happening in other areas of AI development. New models are expanding in scope, requiring teams to rethink how they structure workflows.
