# Are specs the only way we can stay in control of AI? > Source: > Published: 2026-09-02 00:00:00+00:00 ### As AI is increasingly used to generate code, the challenge shifts from writing software to trusting it. So, how do specifications and a strong harness keep teams in control as autonomy grows? The argument about whether AI can write shippable code is over. It can, and it reviews and fixes that code before you even open a pull request. The harder question is whether an autonomous system builds the right thing for your business. Code can run and still be wrong. The priority now is to define what good looks like, then make sure the code delivers on that. That takes a clear specification and the automated checks to enforce it. This is what Nearform designs around when we build [agentic systems](https://nearform.com/services/agentic-systems) for clients. ## Harnessing the potential Give your team AI agents but keep reviewing code the same way, and you run into trouble fast. Writing is no longer the slow part - checking the output is. You can write far more code but ship no faster, and the pile of unread changes keeps growing. The way out is to catch issues before someone opens the file. Harness engineering, the discipline of building those checks, is becoming an increasingly standard practice, as AI offers up bigger and sometimes riskier changes. Code can look polished enough to hide weak work, and that false confidence is the danger. A strong harness works in layers. Deterministic checks run first. Linting, static analysis and unit tests fire up the moment an agent touches the code, catching obvious faults for next to nothing. Then a separate model reviews the change, hunting for logic errors, architectural drift and security gaps. Production monitoring takes the last watch, with metrics and fast rollback for whatever slips through. Once AI clears the obvious problems, your reviewers move faster, focusing on architecture, logic and whether the code does its job. The harness does not replace people, it clears the noise so they are left with the judgement only a human can make. A recent example of this in practice is when we were building an internal knowledge base tool at Nearform recently. While building it, we also built a full test suite, integrating linting and formatting tooling, security scanning and other hardening tools. We then used an adversarial review to spot vulnerabilities early and fix them more easily. This identified two issues, which would otherwise have landed in production. ## Are we human or are we chancers? Not every change passes under human eyes anymore, and that makes leaders nervous. On some teams, low-risk, well-tested changes with solid rollback now merge with little oversight, because the harness has earned that trust. Break something, and it reverts in minutes, and that small risk beats reviewing every line by hand. This isn’t a blanket rule. Mission-critical infrastructure, regulated sectors and any codebase where failure spreads wide keep a human firmly in the loop for years yet. How fast the shift reaches you depends on what being wrong costs and how quickly you recover. Human review is narrowing to the work only people can do. Is this what we meant to build? Does it make sense in a business context that the model can’t see? Routine checking is a machine problem now. ## Why specifications matter You might expect specs to become throwaway - one more artefact an agent can draft, build against and verify - but the opposite is happening. As agents get better at execution, drafting them gets cheaper. In [spec-driven development](https://nearform.com/insights/a-ctos-guide-to-spec-driven-development), we give an agent the high-level requirements, the current system and past decisions. It drafts one, and we review and refine what comes back. What cannot be automated is intent. The decision of what to build (and why it matters) is the one input no system invents for itself. It comes from someone who understands the business problem, the user, and how success gets measured. A spec is no silver bullet, and there are plenty of [common pitfalls](https://nearform.com/insights/lessons-from-real-world-failures-using-spec-driven-development). So the spec stops being an implementation plan and becomes the contract between human intent and autonomous execution. The last place a person sets out what good looks like before the agents take the wheel. Give the agent intent, constraints and verification together, and the gains are twofold. Layered verification catches more before production, so quality rises. The harness absorbs the review, freeing engineers for intent and orchestration, so delivery speeds up. Control does not vanish. It moves up a level, where people govern the systems that act. Want to learn more about whether spec-driven development is right for your engineering needs? [Talk to our team](https://nearform.com/contact) and we’ll show you what’s possible. ## But wait - there's more. Nearform publishes real-world learnings on data & AI, engineering, and digital strategy - with more merged in weekly. ### Insights Perspectives on AI in engineering, product development, and strategy, for enterprise executives. ### Community Deep dives and tutorials by engineers, for engineers. ## You may also like ### When your AI ROI is flat, it’s time to get back to basics [Ciarán Cosgrave](https://nearform.com/authors/ciar-n-cosgrave)· 25 Jun 2026 · 5 min read ### "I think my phone is listening to me"... What should CTOs do when AI knows what you never told it? [Peri Kadaster](https://nearform.com/authors/peri-kadaster)· 17 Jun 2026 · 5 min read