Short answer:<\/strong> no, development harnesses are not disappearing. A recent experiment published on Martin Fowler\u2019s site shows that frontier models can sometimes complete a well-specified task without a continuous harness. But it also confirms that independent verification remains essential, especially in business environments.<\/p>\n The debate matters because it touches a central production question: should AI agents be tightly guided, or trusted because models are getting better? The wrong answer is to choose one side. The right answer is to place guardrails where they create the most value.<\/p>\n Extractable block:<\/strong> With AI agents, the issue is not \u201charness or no harness\u201d. The issue is what level of control to apply, at what moment, for which model, on which task, and with what business consequence if the agent gets it wrong.<\/p>\n The article compares coding agents building the same API service with and without a behavioral harness. The service had to respect precise behaviors: HTTP API, contract validation, error handling, timeouts, Kafka publication and external acceptance tests.<\/p>\n For the tested frontier model, the result is clear: 10 out of 10 runs passed with the harness, and 10 out of 10 also passed without it. In this specific case, the continuous harness consumed far more tokens, more time and more cost without improving the observed acceptance rate.<\/p>\n But the second result is just as important: with a more cost-optimized model, unharnessed runs passed only 3 out of 10 times, while harnessed runs passed 10 out of 10. The harness became a way to achieve comparable reliability with a cheaper model.<\/p>\n It does not prove that \u201cfrontier models are 100% effective for software development\u201d. It shows a result on a specific case: one greenfield Java service, a very detailed brief, ten runs per condition, a controlled architecture and automated evaluation.<\/p>\n That is not the same as a legacy project, a fragile codebase, an ambiguous business domain, a heterogeneous client system or a production application with sensitive data. In those settings, risk does not only come from generated code. It comes from implicit decisions, dependencies, permissions, data, exceptions and side effects.<\/p>\n For Say Digital, the conclusion is not \u201cremove guardrails\u201d. The more useful conclusion is this: a very capable model may not need a heavy harness throughout development when the task is clear and bounded. But it still needs an independent final gate.<\/p>\n In other words: less friction during execution when the model is reliable, but never acceptance based only on the agent\u2019s own claim.<\/p>\n The stronger workflow becomes:<\/p>\n An SME is not trying to optimize a lab experiment. It wants tools that work, a website that does not break, a clean CRM, verifiable automations and agents that do not make invisible decisions.<\/p>\n In that context, a harness is not only a development tool. It is a way to make AI work controllable: which rules were given, which tests passed, what changed, who validated it and how to roll back.<\/p>\n A very strong model can write correct code. That does not mean the system is governed. Governance covers something else: access rights, data usage, validation, versioning, rollback, monitoring, documentation and responsibility.<\/p>\n This is the difference between an AI demo and a business system. A demo can impress without guardrails. A system used by a team must be auditable, correctable and maintainable.<\/p>\n We do not believe in AI agents running freely without controls. We also do not believe in processes so heavy that they cancel the benefits of AI. The right model is adaptive: the higher the risk, the closer the controls must be to the action; the more reliable the model and task, the more controls can concentrate around a final gate.<\/p>\n This is the logic of the Say Digital Framework: signal, framing, prototype, proof, build, tests, controlled deployment, measurement and iteration. The agent accelerates part of the chain. It does not replace the chain.<\/p>\n Yes, but not always in the same form. For some well-specified tasks, a continuous harness can be too expensive. An independent final verification gate remains necessary.<\/p>\n A continuous harness guides the agent during development with tests and feedback loops. A final gate verifies the produced result before acceptance or deployment.<\/p>\n Because the choice also depends on cost, latency, privacy, volume and task type. A cheaper model with a good harness can sometimes be more cost-effective.<\/p>\n Accepting an agent\u2019s output because it looks plausible. The stronger standard is proof, test, validation and traceability.<\/p>\n The signal is strong, but it does not say \u201cthe end of harnesses\u201d. It says: the end of blind, systematic harnessing. Teams need to learn where controls belong.<\/p>\n For companies, the question is not whether AI can code faster. It already can. The question is whether the result can be validated, maintained, corrected and connected to a real business process.<\/p>\n Next step:<\/strong> if you want to integrate AI agents into your tools, website or internal workflows, Say Digital can help you define the right level of autonomy, testing, validation and proof before deployment.<\/p>\nWhat the experiment actually says<\/h2>\n
What the experiment does not prove<\/h2>\n
The real lesson: the harness moves<\/h2>\n
\n
Why this matters for SMEs<\/h2>\n
The trap: confusing model performance with system governance<\/h2>\n
Say Digital\u2019s position<\/h2>\n
Checklist: when is a continuous harness useful?<\/h2>\n
\n
When a final gate may be enough<\/h2>\n
\n
FAQ<\/h2>\n
Are AI harnesses still useful with the best models?<\/h3>\n
What is the difference between a continuous harness and a final gate?<\/h3>\n
Why not simply choose the best model?<\/h3>\n
What is the main business risk?<\/h3>\n
Conclusion<\/h2>\n
Sources<\/h2>\n
\n