The model helps you build, but you decide

The model helps you build, but you decide

---

When I say AI in this post, I mean the current wave: LLMs, agents, coding assistants.

In the previous post I closed with a question: if anyone can build a project, how much quality will it have, or will it be generic? This is my answer. Or at least what I’ve been seeing.

Today the LLM answers everything, so a lot of people think they can build anything. And it’s true, you can. But building anything isn’t building something good. What I see is a wave of products that feel the same. Generic, no identity, nothing that makes them theirs.

On top of that there’s the noise that we’re almost at AGI (a general AI, comparable to a human) and that soon nobody will be needed. That talk makes it easy to believe it’s all simple. And it’s understandable: if they repeat it everywhere, you end up believing it. Until you have to sustain what you built.

It’s not the machine, it’s the craft

The example that comes to mind is being a barber. Anyone buys clippers and scissors. Does that make them a barber? No. They’re missing the craft. The care to do it right, the detail, getting work that comes out professional.

With AI it’s similar. Having the tool doesn’t make you good, everyone has it. What sets you apart is the craft: the discipline, the judgment, the drive to have it come out well made and not just working.

And look, not everyone wants to be a barber, and that’s perfectly fine. Plenty of people prefer to find one they trust and leave the work to someone who knows. Same here. Not everyone has to build everything, and delegating to someone who masters the craft is nothing to be ashamed of.

The tricky part is wanting to build but dumping the whole load on the model. That’s where the mess starts.

Building anything isn’t building something good

As I covered before, programming and doing software engineering aren’t the same thing, and the LLM erased that line for whoever didn’t have it clear. You ask it to build and it builds. But what’s left underneath, when you don’t really know what you’re asking for, is a time bomb.

Code that’s hard to maintain, hard to debug, error-prone. A thousand different ways of doing the same thing, all mixed together. It works until one day it blows up in your face, and then you don’t even know where to start. It working doesn’t matter, any model puts that together. What counts is whether you understand how it’s built. What you don’t understand, you can’t sustain. And it shows the moment something breaks: that’s when you need someone who actually understands, again.

And when the mess tightens, the easy way out is to throw another model on top to patch it and keep going. And that’s where the snowball starts.

The bar went up and quality went down

And here’s something that doesn’t add up. The quality bar went up on everything: performance, security, user experience. And at the same time the average quality went down. They’re moving in opposite directions.

And it’s not just small projects. The biggest services too, the ones half the internet depends on. GitHub, AWS, Claude itself. How many outages we’ve seen lately, things you’d think were rock solid. And it’s public: each one has its status page with the history. I get the impression almost everyone is going through the same thing, and I don’t think it’s a coincidence.

And watch those numbers. A 99.5% sounds perfect, but it’s more than ten hours down in three months. And compared to the standard out there, it falls short: for a critical service, the norm is to aim for 99.9% or more, which is minutes a month, not hours. Let’s be fair, though: Claude has improved a lot, it used to be worse. But it makes clear that sustaining something so big and so reliable is hard, even for the best.

Copying what shines

There’s an easy trap to fall into: copying what looks good somewhere else without asking the basics. Does it fit your product’s identity? Does it actually give the user something? Does it have anything to do with where you want to go?

When you don’t ask yourself those questions, the product slowly fills up with things that aren’t its own. It starts looking like everyone else, and it loses the only thing that made it worth something: its reason to exist. It fills up with things like these:

• An Excel disguised as a web page.
• A whole file system inside a web app, with folders and all.
• Interfaces so loaded they’d need a hundred-page manual to use.
• Features that look good, don’t move the needle, and that you have to carry forever anyway.

You end up with more product and less identity. And I say it because it’s happened to me, not from the outside.

The other side is simpler than it seems: stop adding things just because you saw them somewhere else. And what does belong, give it personality, make it feel yours, not something copied or forced in to fit where it doesn’t. That’s where the product starts to have its own brand.

The model doesn’t decide for you

And to me, this is the important part.

The LLM is an incredible tool. But it has its own inertia. If you let it loose, it takes you where it wants, not where you want. And where it wants is usually the average, what already exists. That’s why I spend more time fighting the model than anything else. It pushes its way of seeing things. And I push back. Let it help me build, yes, but without selling me or deciding in my place.

An example. I wanted to build a feature that bordered on the unthinkable. I spent hours fighting the model, working the angles. It told me it couldn’t be done. It told me more than seven times. I insisted, we found the way, and in the end it worked. It ended up adding enormous value. If I’d listened the first time, it wouldn’t exist.

That’s the difference. The model helps you do, but where to go, you decide.

And there it is, to me, the reason AI often doesn’t deliver as much as you’d like. We treat it like a savior that’s going to do everything, without giving it discipline, vision, context, identity, or purpose. When you don’t have your vision or your product’s identity clear, it’s easy to drift. And out there everyone has an opinion. AI amplifies that: it gives you a thousand paths. If you don’t have your own, you grab the one that sounds most convincing. Which is rarely the right one.

What works for me

Little by little I’ve been improving how I work with LLMs. There’s surely more to it, but this gives the idea of where it points. And although a lot of this comes from code, it works for any project where you use AI, whether it’s sales, finance, fraud, operations, or whatever:

• A fresh session for each new thing. Under the hood, each session resends the whole conversation on every message. If you’ve been at it a while, your tokens go just to recovering the history, before you even write the task. Starting fresh is cheaper and cleaner.
• Back up and validate what matters. Before a big task, I back up (a commit, a stash) and review what it does instead of letting it run on its own. And with something critical, like a database, I follow a fixed flow:
  1. Back up the data.
  2. Ask it for a preview of what it’s going to do.
  3. Confirm before it touches anything.
  4. Validate at the end that everything came out right.
• Keep the memory up to date. So the model loads your context and your decisions between sessions, to avoid repeating it every time.
• Leave your instructions written down and ordered. With skills (short instructions, well structured and split up) the model follows your way of working instead of improvising. They’re like clear notes you don’t have to repeat every session.
• Automate with hooks. You hook up actions so they run on their own when something happens: run the tests or the linter every time it touches the code, back up before a task, ping you when it’s done. That way you don’t depend on remembering.
• Reduce what it has to scan. With something like graphify you build a graph of your project, and it queries instead of rereading everything each time. Fewer tokens, more focus.
• Plan and have a way to pick back up. With plugins like superpowers you plan the work and get back to where you were if you run out of tokens, without starting from scratch.
• Delegate to specialized agents. An agent for each task (QA, frontend, backend) and, if needed, orchestrating them across projects. Each one with its clear assignment gets more done than cramming everything into a single conversation.

I’ll leave these here in case they’re useful to someone.

How you end up here

All of this connects with what I’ve been writing. Learning changed and got incredibly fast. The scarce thing stopped being knowledge and became vision and judgment.

The model can write the code, but it doesn’t know who hurts over what, or why you care. That, you bring.

It’s not AI’s fault, it’s a great tool. It’s just that it still needs someone with judgment and vision, with their hands on the wheel. And that place, at least for now, is still ours.