AI Is Getting Better at Writing Code. That Means You Need More Discipline, Not Less.

The Signal #029 — Dakota’s read on the AI news that actually matters to people running a business.

There is a version of the AI story that goes like this: AI gets good enough to write code, so the hard stuff gets easier, standards loosen, and everyone ships faster with less friction. That story is wrong.

Charity Majors, a well-known voice on the reliability side of software engineering, published a piece on June 15, 2026 that makes the opposite case. When AI gets more capable, the discipline required to work with it goes up, not down.

That is worth sitting with for a minute.

What happened

In “AI demands more engineering discipline. Not less”, Majors walks through what actually shifted in the last year or so of AI development. Her argument starts with a timeline.

For most of 2025, she writes, the mainstream position was that AI-generated code was low quality and might always be. That question was “answered decisively last November.” The model she points to is Opus 4.5, which she describes as a tipping point where AI became able to generate code “approximately as good as that of the median software engineer, at least for common patterns, and much faster and more cheaply.”

But she is careful about what she means by tipping point. The shift was not just one model. Agentic harnesses (the code that wraps a language model in a loop with tools so it can take multi-step actions) became usable in mid-2025. Tool use, function calling, and MCP (Model Context Protocol, a standard for connecting AI agents to external systems) had all been building through the year. By end of 2025, she says, they crested into “real general purpose usability.”

The result: “the economics of code production were turned upside down.” Code went from being expensive and time-consuming to generate, to being “effectively free and instant.” Lines of code went from carefully curated to “disposable and regenerable, practically overnight.”

She also offers a framing that lands hard: the real product of a good software team has always been shared understanding, not code. The code is just where that understanding gets stored. AI disrupts that storage model entirely.

Why it matters for operators

If you are running a SaaS company, a healthcare organization, an agency, or really any business that has software teams or vendors building AI into your operations, this piece is describing your environment right now.

Here is the practical read. When code was expensive to produce, every line got scrutiny. Engineers reviewed it carefully because regenerating bad work cost real time and money. Now that AI can produce large volumes of code quickly, the pressure to slow down and review carefully is easier to skip. The economics push toward shipping fast.

But fast production of code does not mean the code is well understood, well tested, or safely connected to the systems it touches. An e-commerce platform with AI-generated integrations running at speed, without disciplined review of how those integrations behave under edge cases, is not moving fast. It is accumulating quiet risk.

Majors is pointing at something operators in any industry can apply directly: when the cost of generating output drops, the value of the processes that check and validate that output goes up. This is true for code. It is also true for AI-generated contracts, AI-written patient intake summaries, AI-produced financial reports. The volume rises. The stakes on each individual review do not fall.

What most people get wrong

The mistake is treating AI capability improvements as a reason to reduce process rigor. The logic feels intuitive. The tool got better, so the work gets easier, so you need less oversight. Majors pushes back on exactly this.

Her point is that the shift is not just in quality. It is in volume and speed. A team that could previously generate fifty lines of reviewed, understood code in a day can now generate five hundred lines of AI-assisted code. The question is not whether the code is any good on average. The question is whether the team actually understands what they shipped, can debug it when it breaks, and has shared mental models of what the system is doing.

When the output is disposable and regenerable, the discipline has to live somewhere else. In the review process, in the testing harness (the automated system that checks whether code behaves as expected), in the observability tooling (the systems that tell you what your software is actually doing in production). If none of that improves alongside output speed, you have a faster way to accumulate confusion.

For operators, the practical version is this: the vendors and teams building AI into your workflows should be getting more rigorous about process as they move faster, not less. If your AI partner’s pitch is speed and volume, ask what their review and validation loop looks like. That question separates people building durable systems from people building fast ones.

Capability going up and discipline going up are not in conflict. They are what the current moment actually requires.

If you want to think through what disciplined AI adoption looks like for your operation, xovionlabs.com is a good place to start.