Pip: Thomas Suedbroecker’s Blog has a knack for asking the question everyone is quietly avoiding — and this time it’s a big one: who is actually responsible when AI starts making engineering decisions?
Mara: That’s exactly the territory thomassuedbroecker covers here — how governance, traceability, and human accountability need to evolve as AI moves from coding assistant to active participant in architecture, security, and deployment decisions.
Pip: Let’s start with how that shift actually happens, and why it changes everything about who owns the outcome.
When AI Joins the Decision Table
Mara: The post opens with a direct challenge to the productivity framing that dominates most AI discussion — the assumption that more automation simply means better software.
Pip: And the quote that reframes the whole argument lands early: “The bottleneck is no longer software creation. The bottleneck is software governance.”
Mara: That’s the pivot the post is built around. The post traces three phases: human-centric development, where engineers own every decision; AI-assisted development, where AI suggests and humans approve; and agentic development, where AI begins participating in architecture, security, compliance, and deployment planning itself. Once AI influences those decisions, reviewing them after the fact becomes the hard problem.
Pip: Governing at the speed of generation — that’s a genuinely different engineering challenge than anything a traditional Architecture Review Board was designed for.
Mara: The post makes that structural argument explicit. A human review board might handle five to ten major design decisions per iteration. An AI-assisted environment can produce dozens of implementation alternatives, architectural recommendations, and deployment options within hours. The volume of decisions outpaces the human capacity to review them, which is what the post calls the review gap.
Mara: The proposed response is an Automated Architecture Review Board — not to replace human judgment, but to move governance earlier into the lifecycle, making architecture principles executable review criteria rather than static documents consulted after the fact.
Pip: The post is careful to separate participation from ownership throughout — and that distinction gets its own named principle.
Mara: Right. The Spade Principle: a spade can build a foundation or cause harm, and the tool carries no intent either way. The post applies that directly to AI — capability does not create accountability, and calling AI a partner subtly shifts responsibility away from the humans who must own the consequences.
Pip: Which leads to the governance structure the post proposes — specialized review modes for architecture, security, compliance, and documentation, each focused on a distinct set of obligations rather than concentrating everything in one autonomous agent.
Mara: And then there’s the Gap Detector concept, where the system identifies missing review capabilities, searches authoritative sources, and proposes new review skills — but every generated recommendation must remain traceable to its origin, its reasoning, and the human who approved it.
Mara: The security angle is where the argument gets sharpest. In highly automated environments, the requirement itself becomes the attack surface. The post walks through a concrete example: a request to temporarily disable OAuth validation for testing. A human reviewer asks why, who has access, whether it can reach production. An autonomous system may treat it as a valid implementation task.
Pip: Requirement injection as a threat vector — the attacker targets the decision-making process, not just the code.
Mara: That’s why the post frames traceability as a security capability, not just a documentation practice. Every change should trace back through business requirement, feature, epic, technical task, implementation, and test. Without that chain, basic governance questions — which requirement introduced the risk, who approved the exception — become unanswerable.
Pip: And the practical demonstration of all this is the IBM Bob configuration repository, where custom modes and reusable skills implement exactly this kind of structured, traceable, reviewable workflow.
Mara: The post closes with a phrase worth sitting with: “Governance is not a brake. It is the steering wheel.” The argument is that good governance is what allows innovation to scale — without it, organizations lose trust in their own process and compensate with more meetings, more manual reviews, and less autonomy than they would have had with governance built in from the start.
Pip: The steering wheel framing is the one that sticks — governance not as friction added after the fact, but as the mechanism that keeps acceleration pointed somewhere useful.
Mara: And that’s the thread worth carrying forward: as engineering decisions move faster, the quality of the systems governing those decisions matters more than the speed of the systems making them.
Note: This podcast was AI generated by WordPress.com. My related post From AI Coding Assistants to Autonomous Engineering Systems reflects my own ideas and experience; AI was used only as a writing and thinking aid to help structure and clarify the arguments, not to define them.
#AIEngineering, #AgenticAI, #SoftwareEngineering, #GovernanceEngineering, #AIGovernance, #SoftwareArchitecture, #SpecificationDrivenDevelopment, #SDD, #Traceability, #HumanInTheLoop, #ArchitectureReview, #ResponsibleAI, #AITrust, #AIAccountability, #AIIDE, #EngineeringGovernance, #IBMBOB, #GitHub, #DevOps, #SecureAI
Thomas Suedbroecker's Blog 
Leave a comment