We Shipped a Fix for the Wrong Bug

No engineer has ever filed a ticket that says "I wish I didn't have to write code."

In twenty years of tech, I've heard engineers complain about approximately one thousand things. Tickets that arrive as vibes in a text box — no context, no acceptance criteria, no "why this, why now." PMs who disappear after grooming and re-emerge at the demo surprised that the thing they asked for isn't the thing they wanted. Roadmaps that are a list of features with no success metrics, no definition of done, and no answer to "how will we know if this worked?" Legacy codebases that are half Rails, half jQuery, and half existential dread — yes, three halves, the math is intentional. Test coverage that exists in theory and in no other dimension. Documentation that was last updated when someone who no longer works here still cared.

Not once. Not a single time. Has any engineer I've ever worked with, led, or shipped alongside ever looked up from their keyboard and said "you know what would fix all this? If someone just wrote the code for me."

And yet. Here we are.

🐛 The Actual Bug Report

This isn't a mystery backlog. Every one of these has been filed, re-filed, and closed as stale because nobody owned it:

• Tickets arrive half-baked. No context. No acceptance criteria. No "why this, why now." The engineer becomes the product manager by default — which means the PM's job quietly got reassigned to the one person already at capacity.
• Direction is unclear at every level. Not just the ticket. The team. The quarter. The year. "We're focused on growth" is not a strategy. It's a horoscope.
• Signal is everywhere, processed nowhere. Metrics exist. Data exists. Nobody has the bandwidth or mandate to turn them into decisions. Features ship, nothing gets measured, the next sprint starts. The feature might have done nothing. We'll never know.
• Legacy code is a tar pit. Not because engineers are bad — because systems accumulate decisions, and decisions compound. Nobody funded the migration. Nobody scoped the breakup. Everyone just... routes around it and adds a comment apologizing to the next person.
• Test coverage is a promise we break to ourselves. Not because engineers don't know how to write tests. Because tests weren't in the definition of done, the sprint was already behind, and "we'll add them later" is the original sin of software.
• Documentation is a collective hallucination. Either wrong, missing, or written for the person who wrote it. New engineers waste weeks reconstructing institutional memory that should have been written down in 2019.
• Meetings are how we communicate instead of building systems that communicate for us. The meeting is the symptom. The absence of written decisions, async defaults, and durable context is the disease.

These are real bugs. Filed over and over again. In every retro, every engagement survey, every exit interview, every post-mortem where the root cause is "unclear requirements" or "misaligned expectations."

We didn't fix any of them.

🤖 What We Built Instead

We built tools that write the code.

Fully autonomous agents. Models that take a ticket — still half-baked, still vague, still missing the "why" — and produce a pull request. Which an engineer now has to review, interrogate, and defend in a code review, with the added complexity of not being sure if the logic is sound or just plausible-looking. Same amount of cognitive load. Different flavor.

We didn't fix the ticket quality. We automated the response to the bad ticket.

We didn't clarify team direction. We built something that ships faster in whatever direction the team is already going wrong.

We didn't add measurement. We made it cheaper to ship things that won't be measured.

We didn't touch the legacy codebase. The agent is scared of it too.

We didn't improve documentation. We generated more code that will also eventually go undocumented.

We automated the one part of the job that engineers like. The flow state. The craft. The satisfaction of watching something you made actually run. The moment a gnarly problem finally clicks.

In other words: we removed the joy and left the misery.

🔭 The Career Track Theory

Here's where it gets uncomfortable.

I used to believe something pretty clean about engineers who go into leadership: that they did it to fix the environment they'd survived. To make it better for their past selves. To be the engineering manager they wished they'd had. To build the platform, the process, the culture that removes the friction they personally endured for years.

I've updated that belief.

A non-trivial number of engineers go into leadership because they want to stop writing code — and don't want to say that out loud. They weren't burned out by the ambiguity or the people problems or the organizational drag. They were burned out on the craft. They wanted to make decisions. They wanted to be in the room. They wanted the authority of leadership without the submission of sitting down and making something work, one line at a time.

That's a valid career path. Own it.

What's not fine is what happens when those people accumulate enough organizational weight to define what gets built. Because what they build — consciously or not — is a world where they didn't have to write code, and neither should anyone else. Where the messy human act of engineering gets abstracted away. Where the machine does the "real work" and the humans do the coordination, the vision, the "higher-order thinking."

The higher-order thinking they always preferred anyway.

I've been in rooms where this decision gets made. I've watched it get reframed as empowerment, as innovation, as the inevitable arc of progress. The engineers who went into leadership to fix things were somewhere else that day. Or they were in the room and lost the vote.

What they built isn't a better engineering organization. It's a better engineering job — for themselves. Back to building products, but this time without the politics, the red tape, the PM who misunderstands the requirements, the architect who disagrees on principle, the three rounds of feedback before anything ships. No unclear direction, because they set the direction and the agent executes it. No arguing about scope, no negotiating on approach, no explaining the vision to a room full of people with competing opinions. Full authority. High altitude. And — most importantly — never having to do the real work of fixing the environment that made all those engineers miserable. That problem didn't get solved. It got bypassed.

✅ What Was Actually Worth Automating

The target list was right there the whole time. We just aimed at the wrong thing.

Ticket quality. LLMs are extraordinary at taking a vague feature idea and asking the clarifying questions a PM forgot to ask. At generating acceptance criteria from a one-liner. At flagging when a ticket has no success metric and blocking it from being assigned. That's the automation that actually unblocks engineering — at the source.

Documentation that stays current. Not "write a README explaining what the code does." That's already wrong by the time it's written. Try: "here's the PR, here's the diff — write the architectural decision record, update the runbook, flag what changed in the public API." Documentation that gets generated at the moment of change, by the system that knows what changed.

Test coverage on legacy code. Not AI-generated tests for AI-generated code — that's a beautiful infinite regress of untrusted outputs validating untrusted outputs. The actual win is AI-generated test scaffolding for the code nobody wants to touch. The kind of coverage that makes a migration survivable rather than a six-month death march.

Signal processing. Not dashboards that display metrics. Systems that flag anomalies, surface correlations, and draft the post-ship analysis that never gets written because the next sprint already started before anyone looked at the data from the last one.

Meeting artifacts that actually persist. Auto-generated summaries. Decision logs. Action items that don't evaporate the moment the Zoom ends. Not to replace communication — to extract the durable context before it disappears into someone's short-term memory.

These are problems engineers actually have. These are the tickets that were filed. We closed them all as WONTFIX while we built something nobody asked for.

Final Thought

The cruelest part isn't that we automated the wrong thing.

It's that we'll call it progress.

We'll ship the agent, track adoption, watch utilization climb — because of course it will, it's mandated and incentivized from the top — and declare that engineering productivity improved. We'll celebrate lines of code generated per sprint as if that was ever the metric that mattered. We'll watch engineers spend their days reviewing AI output instead of building things they understand, and we'll call that working at a higher level.

Meanwhile the Jira tickets will still be half-baked. The direction will still be unclear. The legacy codebase will still be waiting. The meeting will still be scheduled.

The problems didn't get solved because solving them was never the point. The point was getting back to building — on their own terms, at scale, with the authority to make sure nobody could stop them.