Earlier this week, Cindy Sridharan tweeted something that sparked some interesting reactions:

To create my claude.md, I had it read:

  • my favorite programming books + blogs
  • the best oss projects
  • the code of the engineers I respect the most

Claude (when given proper instructions, constraints, and context) now writes better code than me, almost always.

She was quote-tweeting someone arguing that:

“[AI models have] been trained on all the code of the internet, it knows almost every trick in the book, all the design patterns of every domain, every single low-level detail, every bit-twiddling hack, it’s read every single blog post from every cracked engineer that ever existed […] do you really think you can beat it? do you really think you can be more creative than it?

unless you are 99th percentile expert in some niche domain of software, it simply is not possible. sorry.

Most replies opened the same way—“this is useless, it already knows all that and more”—but then split into two camps: “stop wasting your tokens, AI is better than you” and “and yet it still writes garbage code, AI will never be good.” As different as these conclusions are, I think their shared premise misses the point.

I’ve worked extensively with AI coding systems since 2023, both generating code and reviewing it. LLMs have known practically every notable programming book, article, and design pattern for years. That didn’t start with the coding-agent epiphany of 2025.

Today’s models have far larger context windows, better reasoning, and vastly more effective agentic tooling. Much of what we built back then is now redundant. Most of our effort went into using RAG to feed models only the relevant context, or building elaborate approximations of what eventually became native tool calling. But the problem those systems were solving never went away.

Read ten books on how to write great software and you’ll come away with eleven different, often antagonistic, opinions. The model knows every documented way to implement a database access layer. How does it choose the right one for this application?

Left to their own devices, models old and new generally follow the patterns they find in the existing codebase. When they can’t find a pattern to follow, they usually produce the simplest implementation that works. Sometimes that’s because this really is the first time you’re solving the problem. Surprisingly often, it’s because the agent doesn’t realize you already solved something similar four modules over.

Either approach can be exactly what you need or a liability, depending on the context. Copying existing patterns might be fine, unless what gets copied is legacy code you’ve been trying to get rid of for years. Starting from scratch with a simple urlopen() call might be all you need, or it might open you up to SSRF, leave sockets hanging without timeouts, or evolve into a retry storm against downstream services. All because the model didn’t realize you’d built a hardened, safe-by-default HTTP client that happens to live in a module the agent hasn’t discovered yet.

Then there’s the flip side: the model tries to get ahead of your future needs, throws the book at the problem, and you end up with AbstractSingletonProxyFactoryBean.

A lot of this can be solved, or at least eased, by tooling. Back in 2024, before coding agents went mainstream, one of our clients was a startup building one of the earliest AI code review tools. We built their system to support either explicit instructions or instructions ‘automagically’ learned by analyzing previous pull requests, review comments, and what engineers accepted or rejected, attempting to infer the implicit architecture and coding conventions of an organization.

Something like this is straightforward to build with today’s agentic tooling. In fact, since I work across a bunch of unrelated projects, I’ve extended my Pi agent harness to do exactly that. Still, even if the agent can learn which direction to take, it needs something to learn from.

In AI circles, the ability to make these choices is often called taste. People love to say that “taste will become the most important skill in an AI world.” Maybe that’s true, but my problem is that so many people think taste is something you’re born with, something you “have an eye for.” Anyone who has been around tech for a while has seen the startup founder or CEO who thinks they’re the reincarnation of Steve Jobs and keeps micromanaging designers because they believe they were born with “taste.”

Architects (the kind who design buildings) have known since Vitruvius that taste is a skill developed through study and practice. That’s why Cindy and other seasoned engineers have read entire books of design patterns they might never use. Not because they need encyclopedic recall of every possible solution—even before AI, they could just walk over to the bookshelf and look things up—but because studying different approaches, understanding their tradeoffs, and learning when to apply them is how we develop taste.

The instructions we leave to our agents are taste, made actionable in a particular context. Until the next big leap in AI, that’s what much of hands-on engineering will be: cultivating taste and distilling it into artifacts.