AI Code Has No Taste

The shift from writing code to building systems that write code. How to stop optimising for speed and start doing impossible work.

Hey friend 👋,

AI code has no taste.

It doesn’t know why you avoided that dependency. Why you chose that abstraction. Why the naming convention matters. It produces functioning code with no opinion - code that passes review but that nobody wants to maintain.

Most people see this as AI’s limitation. I see it as an invitation.

Because AI code has no taste of its own. It’s waiting for yours.

The rules you’ve built up over years of engineering - the heuristics that live in your head during code review, the patterns you enforce without thinking - they can become explicit. They can become instructions or SOPs.

And once they do, something interesting happens.

Your taste scales.

The Shift

There’s a transition happening that most engineers haven’t named yet.

Most of us are still “in the loop.” Prompting back and forth. Reviewing every output. Tweaking, fixing, regenerating. The AI codes faster, but you’re still the bottleneck.

The shift is stepping out of the loop entirely.

You stop doing the work. You start building systems that do the work - better than you could do it yourself, at a scale you could never sustain.

Not “AI as assistant.” Not autocomplete on steroids. Something more fundamental: you encode your taste, your standards, your judgment into a system. Then you let it run.

The craft doesn’t disappear. It moves. Out of the code, into the rules that shape the code. Out of the output, into the system that produces the output.

This is a different job. And it requires an uncomfortable question.

The Question Most People Aren’t Asking

When I was managing software teams, I saw the same pattern constantly.

A team gets stuck on some tedious process. They brainstorm improvements. They shave 10% off the time. Everyone feels productive.

But that’s not strategy. That’s minor optimisation.

The real question was always simpler: “Why are we doing this work at all?”

I see the same thing with AI now. Most engineers ask: “How can AI help me do my old work faster?”

Fine question. But you’re still in the loop. Thinking small. The constraint isn’t the model. It’s not the tools. It’s you - still reviewing everything, thinking “only I can write this code well”, still the ceiling on what gets shipped.

The better question: How do I use AI to do previously impossible work - at a quality level that reflects or exceeds my standards?

Not “code faster.” Build something that couldn’t exist without the system.

Let me make this concrete.

What This Looks Like

A few weeks ago I built a system that generates ambient electronic mixes - focus music for coding. It produces about 2 hours of original music daily, runs a 24/7 YouTube livestream, and keeps going without me.

I could not do this manually. Not “it would take a long time” - I literally could not sustain this output.

But I didn’t just prompt “generate lo-fi beats” and walk away. That would produce garbage.

I built filter chains to mix audio to my taste - EQ, compression, analog warmth. I listened to hundreds of outputs to tweak parameters. I encoded my standards into every part of the pipeline.

The craft didn’t go into each track. The craft went into the system.

Same principle applies to code. You don’t review every line the agent writes. You encode your standards into the rules it follows - architectural preferences, naming conventions, the stuff you’d flag in PR review. The agent becomes the system. Your taste becomes the instructions.

You build the system that builds the system.

So how do you know if you’ve actually done this, or just built another automation?

Two Tests

The Impossible Test. Could a motivated human do this sustainably - without burning out or cutting corners?

Scheduling a cron job? Automation. An agent that monitors your on-call queue, root-causes incidents, and pushes a fix before you’ve opened your laptop? No human can do that.

Linting code? Automation. An agent that reviews every PR against your team’s architectural principles, catches subtle violations, and explains why it flagged them - across 50 PRs a day, without getting tired or sloppy? Impossible.

The Craft Test. Does the output reflect the taste of whoever built it?

If a different person built this system, would the results be different? If the answer is no, there’s no craft encoded. Just a generic pipeline anyone could spin up.

Scale without craft produces slop. Craft without scale means you’re still in the loop, doing everything yourself.

Scale plus craft is the unlock.

But passing both tests once is easy. Keeping quality high over time - that’s the hard part.

Closed Loops

Every system drifts toward garbage. Entropy always wins unless you fight it.

When you’re coding manually, you are the feedback loop. You notice when something’s off. In a system that runs without you, that loop has to be built in.

Three components:

The Generator produces output - the LLM, the agent, the pipeline.

The Sensor measures quality (evals). Did tests pass? Does it follow conventions? Did latency spike?

The Controller enforces your standards. It rejects bad outputs, adjusts parameters, decides what ships and what gets thrown away.

The craft lives in the Controller. That’s where you encode “good enough” vs “not good enough.”

For code: the Sensor runs your test suite, reviews for coherence across the codebase, checks for simplifications, flags complexity. The Controller decides whether to retry, refactor, or escalate to a human.

Without this loop, quality drifts. Always. This is where most “AI slop” comes from - not bad models, but missing feedback loops.

Build This

Want to try it? Start small.

Pick something repetitive - code review, documentation, test generation. Something you do weekly and see if you can encode it as a system that does the work without you. Before you build the pipeline:

1. Write down your standards. What makes output “good” vs “acceptable” vs “garbage”?

2. Build a sensor. How will you measure whether output meets those standards automatically?

3. Build a controller. What happens when it fails? Retry? Adjust? Flag for review?

You’ll learn more about your own taste by trying to encode it than you ever did by just doing the work yourself.

The New Job

Here’s the thing most engineers haven’t internalised yet:

This isn’t a productivity hack. It’s a different job.

You stop doing the work. You start building systems that do the work - better than you could do it yourself, at a scale you could never sustain.

The engineers who figure this out first will build things the rest of us can’t compete with. Not because they’re smarter. Because they stepped out of the loop.

Different question. Different results.

Have an awesome week :)

---

Want to build these systems alongside other engineers doing the same? I run a community where we work on real projects and share what’s actually working.

👉 Join the AI Engineering Community