--- title: "AI Writes Code But We Own the Consequences | Speedscale" description: "AI writes code faster. Build autonomous verification with deterministic gates and LLM-powered tests to own reliability, scalability, and the consequences." canonical: "https://speedscale.com/blog/ai-writes-code-but-we-own-the-consequences/" --- ![An engineer oversees automated inspection as defective blocks return for repair and verified blocks form a bridge](https://speedscale.com/_astro/featured-image.LTfBDu5-_2b1RVa.webp) # AI Writes Code But We Own the Consequences Nov 10, 2026 [By Matt LeRay](https://speedscale.com/blog/author/matt-leray/) [AI/ML](https://speedscale.com/blog/category/ai/ml/) [DevOps](https://speedscale.com/blog/category/devops/) [Developer tools](https://speedscale.com/blog/category/developer-tools/) * * * Professional engineering now incorporates many of the practices we used to call vibe coding. As a lifelong engineering and product leader, I find this development mildly offensive. Progress continues regardless of my feelings. We take a working demo and call it progress. We are starting to treat a green unit test suite and a simple smoke test as software engineering. This is an embarrassing instinct for someone who knows production exists and that customers pay for our service. Every day that coding agents improve, the temptation to call this engineering grows stronger. When Claude can turn an idea into a working implementation, it becomes easy to confuse how quickly something appeared with how close it is to finished. As implementation gets cheaper, I think engineers need to spend more attention on the “ilities.” Scalability. Reliability. Maintainability. Observability. The qualities that determine what happens after somebody starts depending on our software. When I wrote job descriptions in the pre-AI era, this responsibility was typically reserved for senior or principal engineers, or the platform team. Now, we are all managing agents, and the job increasingly includes building an autonomous verification system that can keep up with the code we produce. ## The demo was the easy part Consider a customer export feature. Click a button, query some records, generate a file, send a download link. At this rate, an agent will build that while using its spare capacity to reverse engineer Microsoft Excel. The demo works, of course, and it gets shipped. But what happens when a customer exports three years of history? It’s an obvious question, but one we can easily skip when the demo looks finished. Does the query compete with interactive traffic? Can one tenant monopolize the workers? What happens when a worker dies halfway through? Does retrying create duplicate jobs? Who can download the file, and when does that access expire? These questions describe the feature just as much as the button does. Senior engineers have always been responsible for answering those questions. I think asking them now needs to become an entry-level skill. The change is how easily we can produce an implementation before making those decisions. ## The constraint isn’t building software [DORA’s March 2026 analysis](https://dora.dev/insights/balancing-ai-tensions/) describes its 2025 finding that higher AI adoption was associated with both greater delivery throughput and greater delivery instability. That is an association, not proof that AI caused the instability. Still, it gives us a reason to measure what happens after the code gets written. [Atlassian’s 2026 developer experience findings](https://www.atlassian.com/blog/developer/developer-experience-report-2026) tell a related story. Eighty-seven percent of developers said AI helped them ship faster. Seventy-two percent reported the same or more friction than before AI. Those are self-reported experiences, rather than production telemetry. If review, testing, deployment, or recovery remains difficult, generating more changes can put additional pressure on the [delivery bottleneck](https://speedscale.com/blog/ai-delivery-bottleneck/). Engineering leaders should make room for teams to improve them. Otherwise, every hour saved writing code risks becoming another hour of work waiting somewhere else. In my experience with large enterprises, some engineering teams are quietly slowing down while forcing every engineer into a miserable life of never-ending code review. ## QA is being reinvented for the AI era Teams that eliminated dedicated QA positions still needed quality assurance. In the microservices era, developers and automation inherited the work. [DORA’s testing guidance](https://dora.dev/capabilities/test-automation/) explicitly distinguishes the tester role from a full-time job and calls for continuously improving tests throughout delivery. We’ve all heard the phrase “test in prod,” sometimes said with a straight face. That distinction matters more as agents produce more code. Every additional change creates something to verify. A smaller QA team can be overwhelmed by the sheer volume. I think the QA function is becoming critical again, but with a different shape. A separate team inspecting finished work at fixed gates cannot be our only answer to autonomous code production. We need continuously updated deterministic gates and LLM-powered tests, running throughout development and delivery. QA expertise belongs in designing and improving that system. Its reach should grow without requiring a person to inspect every change. ## The -ilities need acceptance criteria “Make it scalable” is a wish. For our export feature, we could instead specify: * Large exports must stay within a defined memory limit. * Export traffic must keep interactive request latency within its agreed target. * Retrying a job must preserve the intended result without duplicating side effects. * Downloads must enforce tenant authorization and expire after a defined period. * A failed job must produce enough evidence for someone to diagnose it. The actual limits need to come from the product, workload, and business. An agent can propose them but the team needs to decide whether they make sense. Observability deserves the same treatment. “We added logging” tells me very little. I want to know whether we can distinguish a slow database from a stalled worker, without putting customer data into the logs. Maintainability matters here too, but not in the same way it used to. Could another engineer change the export format safely? Can they understand the dependencies? Can they remove the feature when we no longer need it? Does the repository document enough context for the next AI agent to answer these questions, including the reasoning behind human decisions? The “ilities” belong in the definition of done, alongside the behavior a customer sees. ## Make verification run itself An autonomous verification system needs complementary ways to find and judge failures. **Deterministic gates enforce explicit rules.** Unit tests, API contracts, authorization checks, and [regression tests that assert on behavior](https://speedscale.com/blog/test-behavior-not-choreography/) provide repeatable pass-or-fail results. Controlled load and recovery experiments measure behavior against agreed limits. **LLM-powered tests explore beyond the scripts.** Agents can generate unusual inputs, exercise customer workflows, and propose failure scenarios. Model-based evaluators can assess behavior against a rubric when an exact assertion is impractical. [Anthropic’s guidance on agent evaluations](https://www.anthropic.com/research/demystifying-evals-for-ai-agents) combines deterministic checks with model-based grading and human calibration. Model judgments need validation too. For our export feature, the system should create realistic test data, interrupt a worker, retry the job, and check tenant isolation. It should preserve the evidence and feed failures back to the coding agent for repair and another run. The suite must evolve. A confirmed bug becomes a regression case. A changed requirement updates the relevant checks. Agents can propose additions from incidents and exploratory runs. We should track whether those additions catch known defects, alongside the false alarms they create. Keep the acceptance policy separate from the implementation being tested. A coding agent must not make its own change pass by weakening the gate. Version the tests, rubrics, and policy so results remain explainable. Within that policy, verification should run autonomously: test, gather evidence, reject failures, request repairs, and escalate ambiguous results. Engineers own the requirements, the system’s effectiveness, and the exceptions. Enterprise constraints belong in the design too: permitted customer data, test-environment access, and retained evidence. Teams need shared platforms and time to build this capability. ## Some code shouldn’t exist Additional software creates an operating obligation. Sometimes the better decision is a scheduled job, an existing service, or letting the feature wait. The same restraint applies to quality requirements. An internal experiment and a payment service need different guarantees. Google’s [SRE guidance on embracing risk](https://sre.google/sre-book/embracing-risk/) makes this explicit: reliability has costs, and the appropriate target depends on the business and its tolerance for failure. Engineering judgment includes deciding how much reliability, capacity, and complexity we can justify, then building verification that enforces those decisions continuously. As code production becomes autonomous, our verification system needs to keep pace. Building and maintaining that system is part of owning the consequences. I still want the victory lap, and it’s looking increasingly likely I’ll have it. ## Table of Contents ## Ship AI-generated code with confidence AI writes fast but doesn't know your production environment. Speedscale captures real traffic and verifies AI code against actual API behavior — before it reaches users. [See how it works](https://speedscale.com/features/ai-code-verification/) [Start free trial](https://app.speedscale.com/signup)