Many organizations are wiring AI assistants into a repo or IDE and letting them scaffold projects and pipelines. Maybe they bolt on a security scanner and declare “AI enablement.” That’s not a governance model, that’s optimism (and not even cautious optimism).

Indeed, a code-generating agent with broad access to your repos, your CI/CD pipeline, and your artifact registries is effectively a hyper-productive and not-very-well-trained junior developer with access to the Internet and no ingrained sense of organizational policies. It can introduce new tools, new dependencies, and new patterns faster than your review processes can handle.

In my personal projects, I’ve started to think of this as what AI coders call a harness-engineering problem. For every agent that’s responsible for building or wiring code, I try to put other agents in the loop that are responsible for tearing it down, at least conceptually. For example, one agent focuses on security and looks for obvious vulnerabilities and bad practices. Another looks at architecture and points out when the app design is veering into unmaintainable territory. A third looks at performance and reliability issues, which are themselves a kind of security concern when you think about things like denial of service and resource exhaustion. Pair this with constitutions that give the agents first principles on architecture, security, and design, and this is no longer vibe coding, it’s harness engineering at scale for all of your projects.