"Shipping is easy. Being right is hard."

I ran 179 AI coding sessions in 25 days. Not toy projects - production Android, real PRs, real code reviews.

Here's the honest version of what that looks like.

The Slop Pipeline

Here's what I'm seeing everywhere. A PM spits out a PRD from an LLM.
An engineer then feeds that PRD into a coding agent. The agent spits out code. The engineer ships it. Nobody in that chain actually thought about the problem.

AI-generated specs turned into AI-generated code, reviewed by AI-generated summaries. The output looks plausible enough that nobody stops to ask if it's right. Users don't care how fast you shipped. They care that the app works. And quality has dropped - not because the tools are bad, but because the whole pipeline is optimized for throughput over judgment.

I'm not anti-AI. I ran 179 sessions in 25 days. But I'm trying to use it without becoming another slop cannon. That's what this post is actually about.

The Correction Tax

The biggest difference is speed of iteration. But it comes at a price.

We ship faster and care less about end results. The point of failure shifts - "Claude wrote it" is the new deflection. You stop owning output the same way when you didn't write it line by line.

Before, boilerplate and syntax ate your time. Now that's free. So I spend way more time on "what and why" than I used to. I'm more deliberate about design before I even open the IDE, because it's really easy to code yourself into a corner when generating code is cheap.

There's a correction tax on almost every session now. 100+ commits in 25 days sounds impressive until you realize a chunk of those are fixing what the previous few commits got wrong. The cleanup isn't an exception anymore. It's the workflow.

Speed lets you iterate toward good enough and call it done. That's the part nobody talks about, and the engineers who don't notice it are the ones most at risk.

The Skill That Actually Matters Now

Orchestration. Wiring things together.

The skill that matters now isn't writing code - it's building the harness around the AI that makes it actually useful for your context. Tooling, workflows, feedback loops.

I built ComposeProof because no visual testing tool got Compose previews right. Kartograph because I needed a semantic search across repos. Rebound because nobody was measuring recomposition budgets. Nobody asked for these. I built them because the AI couldn't operate effectively in my context without them.

300+ automated sub-tasks. CLAUDE.md is onboarding docs. Slash commands are SOPs. Hooks are guardrails. The whole setup is a system where the AI is one component you orchestrate, not the thing doing the orchestrating.

The engineers who'll struggle aren't the ones who can't prompt. It's the ones who can't build the scaffolding around the prompt - the MCP servers, the CI hooks, the custom workflows that catch drift before it compounds. Closing that gap between what AI does by default and what your codebase actually needs? That's the job now.

The Fundamentals Didn't Change

Don't let the AI write code you don't understand yet.

When I was debugging a 25.8% API failure rate from dual-SIM DNS resolution, there was no API for it. No Stack Overflow answer. No AI that could help. I had to trace network calls and figure out how Android's connectivity manager actually works across 50+ device models. Took weeks.

But that's exactly why now, when AI suggests a network fix, I know in seconds whether it's right or nonsense. That's the return on the slow work.

The fundamentals haven't changed. Read the error before you Google it. Understand what the code does before you ship it. Know why the architecture looks the way it does, not just that it compiles.

What changed is that the boring middle is gone. Boilerplate, syntax lookups, scaffolding. That stuff used to force you to learn things as a side effect of typing them out. Now you have to be deliberate about it, because the AI will happily let you skip the understanding and go straight to the output.

Pick one thing a week and build it without AI. A custom view. A network interceptor. A state machine. Not to feel the friction for its own sake, but so when AI confidently gives you the wrong answer, you'll know. That's the only way to stay in control of code you didn't write line by line.

The Hard Truth

If AI makes your role obsolete, the role was already fragile.

I watched a god-object ViewModel survive for months - 3,500 lines, authentication and profile and session logic all tangled together - because nobody had the judgment to say 'this is wrong, break it apart.' AI didn't write that mess. AI couldn't have fixed it either. You need someone who understands the domain well enough to know where the seams should be.

If your entire value is translating Figma to Compose, yeah, that's getting commoditized. But if you're the person who catches that your retention metrics are measuring FCM delivery instead of actual usage - no model catches that. That's not a data problem. It's a judgment call about what the numbers were supposed to mean in the first place.

Here's the hard truth: a junior with AI can now produce what a mid-level produced two years ago. If you've been coasting at that level, you're right to feel the squeeze. But the answer isn't to race AI at code generation. Go deeper. System design. Debugging things that have no Stack Overflow answer. Knowing your platform well enough to build tooling that doesn't exist yet because nobody else needed it badly enough.

AI does the "how." Your job is knowing what to build, why it matters, and when something's wrong that nobody else has noticed.