Congratulations, You Gave Your Most Confident Junior Engineer a Megaphone

If you’re running an engineering organization, you’ve likely spent the last 18 months in a full-sprint adoption of AI coding tools. You’re not alone. According to a recent survey from Techreviewer, a staggering 97.5% of companies are now using AI in their software development process. The promise was irresistible: radical productivity, faster roadmaps, and happier developers.

But now that the dust is settling, a strange paradox is emerging. Your team is generating code faster than ever, yet it doesn’t feel like you’re shipping reliable software any quicker. In fact, recent studies are highlighting this paradox, with one from METR finding nuanced, and actually negative, impacts on the productivity of even experienced developers.

If you’re feeling this disconnect, you’re not going crazy. You’re just discovering the new, hidden bottleneck of the AI era. As Charity Majors relays from engineer Kent Quirk, you haven't hired a team of super-powered seniors. You've given a megaphone to "an excitable junior engineer who types really fast".

Let's be clear about what an AI coding assistant is. It is a brilliant mimic, an autocomplete on steroids with a photographic memory of public code. For well-defined tasks—generating boilerplate, writing unit tests, translating a function from Python to Go—these tools can be a phenomenal time-saver. The danger lies not in these contained use cases, but when the AI is prompted to generate novel, complex application logic.

This is where it becomes so dangerous.

It has no concept of your company's history. It has no memory of the brutal P0 outage last year that led to a new, mandatory caching pattern. It has no awareness of the strategic decision to deprecate a legacy library. While the code snippets themselves might look clean, the AI will happily generate output that fails to compile or run within your project because it hallucinates methods, variables, and dependencies that don't exist. It is blind to the unwritten rules and hard-won wisdom that separate a senior engineer from a novice.

It will confidently sprint full-speed towards the exact same cliff your team painfully learned to avoid, and it will write beautiful, clean, and insidiously wrong code all the way down.

"Passenger" Devs and the Accountability Black Hole

A common rebuttal from engineering leaders is often simple: "The developer prompting the AI is responsible for the output. They need to review it."

This argument unfortunately ignores decades of hard-won learnings about code ownership. The standard  has always been high. As Charity Majors puts it, you should "never accept a PR unless you can explain if it breaks". This principle of deep ownership is why we have distinct roles for author and reviewer. We rarely hold reviewers fully accountable for bugs in the code they approved, usually because we implicitly understood they lacked the deep, line-by-line context of the author. We expect diligence and care—not perfection.

Today, the AI is the author. The developer who accepts its suggestion is, at best, a reviewer. They are a passenger in the creative process. To now hold this "passenger dev" fully accountable for the AI's architectural mistakes is a standard we never applied to human reviewers. This leaves junior and mid-level developers in a precarious position—encouraged to use tools that accelerate them, but implicitly responsible for outcomes they lack the context to fully own. It's a setup for failure.

This creates a black hole of accountability. If the AI is the author and the human is just a passenger, who truly "owns" the code? This leads to an even more dangerous, unspoken question...

"So, What's the Point of a Senior Engineer?"

Let's address that question head-on. The question misunderstands the fundamental value of any senior engineer who has ever spent a weekend debugging a production outage caused by a subtle, multi-step failure.

Their value has never been their ability to type faster or to be a better linter or even to have encyclopedic knowledge of APIs or protocols. Their value is in their familiarity with the system. It's the hard-won, almost intuitive understanding of the codebase's dark corners and emergent behaviors. As Charity Majors writes, "being a senior engineer is not primarily a function of your ability to write code. It has far more to do with your ability to understand, maintain, explain, and manage a large body of software in production over time". It is about understanding the sociotechnical system—the interplay of software, tools, and people.

This deep ownership is the core of philosophies like Observability-Driven Development, which argues that engineers should "watch your code go out as it deploys" and verify if it's "working as intended". An AI can't do this. It can't trace a direct dependency graph and also know that changing Service A has always caused weird latency spikes in Service Z because they share an overloaded database cluster that isn't explicitly mapped in any IaC file. It doesn't have the "spidey sense" to know that touching the auth service, no matter how small the change, requires a full regression test.

This is the gap between explicit logic and implicit knowledge. An AI may eventually find what you tell it to look for. A senior engineer knows what to look for in the first place. By turning our most experienced engineers into full-time AI babysitters, we are catastrophically misusing our most valuable talent.

The Fallacy of the Perfect Prompt

The next flawed argument is the intuitive first step many teams take: "Just add our architectural rules to a context.md file for the AI to reference. Problem solved."

This is the modern equivalent of asking engineers to memorize a 100-page style guide instead of giving them an auto-formatter like Prettier. It is a fundamental misunderstanding of how both developers and complex systems work. Critical context isn't just a set of explicit rules; it's the institutional immune system. It's the hard-won lessons from past outages, the unspoken consensus on technical direction, and the subtle performance trade-offs that separate senior intuition from junior enthusiasm.

Even if you could meticulously document every piece of this tacit knowledge, you then face a more fundamental problem: you are entrusting it to a system that offers no guarantee of adherence. An LLM's primary directive is to generate plausible-sounding output, not to strictly obey a set of logical constraints. Your carefully written rule about "never calling the legacy payment service directly" is just another input to be weighed against the trillions of public data points in its training set.

Worse, this process is a crapshoot that gets flakier with scale. As you add more rules and edge cases to the context, you aren't creating a more robust system; you're creating a "suggestion soup." The AI is more likely to get confused, ignore critical constraints, or hallucinate a compromise that violates the spirit of the rules. The reliability of its adherence tends to decrease as the complexity of your instructions increases.

This is why we have spent the last decade building systems of enforcement. A rule in a markdown file is a suggestion. A failing unit test is a fact. A linting error is a blocker. To revert to a system of polite, probabilistic hints is a massive leap backward in software reliability.

From Gatekeepers to Gardeners

So if senior engineers aren't meant to be AI-babysitters, what is their role? The answer lies in fundamentally changing their mandate from manual gatekeeping to active gardening of the entire engineering system. Their job is no longer to inspect every pull request; it's to cultivate an environment where bad code struggles to grow in the first place.

A fair question arises: "Haven't these been good ideas for years? Why is this suddenly critical now?" The answer is scale. Before, a human developer could only introduce so many flaws per day. An AI-assisted engineer can generate a hundred plausible-but-insidiously-wrong solutions before lunch. The sheer volume of AI-generated code makes manual gatekeeping a mathematical impossibility. When every engineer has a "megaphone," the only scalable solution is to re-architect the acoustics of the room.

Consider a common scenario: An engineer prompts an AI assistant to add a feature. The AI, trained on years of public code and drawing on patterns from across your own codebase (including long-deprecated ones), confidently generates a solution that calls a non-performant database function.

• The Gatekeeper's approach is manual and ephemeral. They spend 15 minutes writing a PR comment explaining the N+1 query problem, linking to a wiki page, and blocking the change. The feedback is temporary; the AI will suggest the same flawed pattern again tomorrow.

• The Gardener's approach creates compounding value. They invest an hour writing a custom static analysis rule. This rule now programmatically blocks the anti-pattern in the CI/CD pipeline for everyone, forever. The feedback is instant, contextual, and educates the engineer on why the AI's suggestion was flawed.

This shift creates a system where the senior engineer’s deep expertise is encoded and scaled, liberating them from repetitive toil to focus on the next architectural horizon. For the AI-assisted engineer, the system becomes the true senior partner in the pairing, providing an immediate feedback loop that turns the AI's suggestions into powerful, teachable moments.

Of course, this transformation is challenging. Asking senior engineers, who are already strapped for time, to additionally master the complexities of Semgrep, Open Policy Agent, and observability platform APIs in order to create tooling is a significant hurdle. It highlights a critical gap in the market: a desperate need for tools that can help engineers encode their institutional knowledge without requiring them to become specialists in policy languages.

Until such tools are widespread, the upfront investment is still necessary. By encoding architectural integrity directly into the development process, teams can build a more predictable and reliable way to deliver software. The goal is to increase the throughput of high-quality work, not just the rate of sending it to QA. As the old saying goes, "slow is smooth, and smooth is fast."

The Leadership Mandate: Unleash Your Architects

It’s tempting to see this as a failure of individual developers to be more diligent. It’s not. It's a failure of leadership to adapt the system to a paradigm-shifting technology.

This is not easy. Building a culture of deterministic guardrails requires significant upfront investment, especially in organizations already struggling with basic engineering practices. But the alternative—allowing AI-generated code to proliferate without systemic checks—is an invisible tax of technical debt and production risk that is far more costly in the long run.

The challenge for engineering leaders in 2025 is to stop asking your best people to be better gatekeepers and start empowering them to be the architects they were hired to be. The solution isn't to abandon these powerful assistants. It's to build a system where your best engineers are able to encode their unique, hard-earned context to scale it across the entire organization.

That is how you reclaim the promise of AI productivity. You don't do it by burning out your senior talent on endless reviews. You do it by giving them the leverage to build a system that makes the right way the easiest way, freeing them to solve the next generation of problems.