\u201cI like to think in parallels. In 2009, I was like, what if Ops was more like Dev?\u201d wondered Patrick Debois<\/a>, a member of technical staff at Tessl, coiner of the term DevOps, and founder of the DevOpsDays global event series<\/a>. <\/p>\n His comments came during PlatformCon London earlier this summer, where he told the audience that as context \u2014 the specified knowledge AI uses for tasks \u2014 replaces human code, \u201cthe software development lifecycle becomes the\u00a0context development lifecycle.\u201d \u00a0<\/p>\n 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. This growth is being spurred by a shift in how individual developers, teams, and whole organizations think. And it opens a whole new opportunity for platform engineering<\/a> teams.<\/p>\n \u201cThe mindset change for a developer that I would advocate is that if the agent didn\u2019t do what you want, stop correcting the code. Improve the system, not the prompt,\u201d Debois tells The New Stack. \u201cThat kind of shift is from \u2018I\u2019ll do it together with my agent,\u2019 over to \u2018I\u2019ll help my agent do it better\u2019.\u201d<\/p>\n Debois sees this as a necessary shift from deterministic to non-deterministic and probabilistic systems and workflows. And it\u2019s one that involves as many changes to the way we work as to the technology itself. But it can\u2019t be just done by an individual engineer or at the team level. Like DevOps, it is a change that can only be realized at scale.<\/p>\n How to become a context-driven organization<\/p>\n It may have felt like we flipped a switch and every company was \u2014 wham! \u2014 \u201cAI-first.\u201d In reality, just like DevOps, microservices, and cloud transformations before it, AI is making a continuous transition into the foreseeable future. So how does your engineering organization get onto the right context-driven path?<\/p>\n At the team level, Debois says, a good question to ask is how many touches does one need for agents to work? Different engineers across different teams will feed in different points of context, including:<\/p>\n Codebase<\/p>\n Specifications<\/a><\/p>\n Post-mortems<\/p>\n Documentation Slack messages<\/p>\n Architectural decision records<\/p>\n Code samples<\/p>\n Use cases<\/p>\n Compliance guidelines<\/p>\n For context and therefore agents to scale, you need to know what agents individuals and teams are producing and their outputs.\u00a0<\/p>\n \u201cWhen you\u2019re optimizing for A, and we\u2019re optimizing for B, let\u2019s make sure that the whole context that we give is optimized for the whole team,\u201d Debois explains, including \u201cIf you are optimizing the system for your laptop, can we optimize it for the team workflow? And then you just scale up, like, can we do this on the platform level? Or across multiple teams?\u201d<\/p>\n \u201cIt\u2019s not something you seek out,\u201d Debois tells The New Stack. \u201cMaybe they can speed it up, but you would see the signs of \u2018Oh, I have context, and you have context. Sure, it\u2019s on Slack. What if this was in the repo and I can reuse this?\u201d following the pattern in tech that has any trend spreading from a single enthusiast, to an enthusiastic team, to a couple of teams, and eventually being built into the platform.\u00a0<\/p>\n Like all tool-driven changes, AI is as much about the people and processes as it is the tech. But, he argues, the tools open up possibilities for behavioral changes.<\/p>\n \u201cThe fundamental change is the system, not the prompt,\u201d he continues. \u201cAnd then look for collaboration directions from solo to sharing things, and now working on the [context building] as a team together.\u201d\u00a0<\/p>\n Context engineering evolves to harness engineering<\/p>\n Organizations may think that context is fed into your agentic systems just once, or a couple of times a year when rules change, but, Debois warned, it\u2019s not meant to be Waterfall. It\u2019s iterative. If the context isn\u2019t, then engineers fall back into the bad habit of rephrasing prompts or just fixing the code itself. Relying solely on traditional feedback loops means your AI agent fleet will not return on its investment.<\/p>\n \u201cThere is the industry narrative that if there\u2019s a problem with AI, we just use more AI,\u201d Debois tells the PlatformCon audience. He gave the example of how one large language model (LLM) or AI agent generates some code. \u201cWe ask the LLM to assess this, and it will call almost like a unit test. It hasn\u2019t run the code; it just looks at the code.\u201d<\/p>\n There\u2019s some value in that, perhaps in enforcing API endpoints or other binary quality gates, but, he says, it\u2019s not enough. Instead, if you specify what you need within the context, then that drives how the agent runs and evaluates the code.\u00a0<\/p>\n But it shouldn\u2019t stop there. The next stage of agentic AI maturity, he contends, is grounded in harnesses and loops.\u00a0<\/p>\n Harness engineering focuses on building the infrastructure, guardrails, and tools that wrap around an LLM to support the development of reliable, autonomous agents.\u00a0<\/p>\n Debois defines an agent\u2019s inner harness as logs, metrics, and traces behind query APIs, \u201cso the coding agent sees the consequences and improves,\u201d all of which feed into that living loop of generation, evaluation, distribution, and observation.\u00a0<\/p>\n With this pattern, the agents \u201cautonomically know that something is wrong without you having to tell them all the time,\u201d he says, because \u201cit has sensors in a way that knows what fails, what it improved, and then can go back to improving these walls,\u201d even when engineers are hard-coding something.\u00a0<\/p>\n Again, harnesses should not be built in isolation serving a single developer or team.\u00a0<\/p>\n \u201cThey\u2019re building a harness for the whole world, so imagine the consensus of this is how we do tests, and this is how we do verification, and all the knowledge that is currently in all these different teams,\u201d Debois says. \u201cPeople start building on that same pipeline.\u201d<\/p>\n The reality is that most organizations end up with multiple pipelines, but these loops become the next evolution of each organization\u2019s feedback loops. And thus, building for AI coordination leads to better organizational collaboration.<\/p>\n![\"\"](\"https:\/\/www.newsbeep.com\/il\/wp-content\/uploads\/2026\/07\/495764a7-context-development-lifecycle-1024x549.png\")
<\/p>\n![\"\"](\"https:\/\/www.newsbeep.com\/il\/wp-content\/uploads\/2026\/07\/dc6e7834-agent-inner-harness-1024x563.png\")
<\/p>\n
![](\"https:\/\/www.newsbeep.com\/il\/wp-content\/uploads\/2026\/07\/220bf6cf-jriggins-2025-600x600.jpeg\"\/)
<\/p>\n