From consumer to builder

The first way of relating to AI is the natural one: ask, receive, repeat. You open the chat, type what you need, and ten seconds later you have an answer. It's fast, it's useful, and if you ask good questions, it goes a long way.

But it has a ceiling. I hit it, and I think almost everyone eventually does:

1. Every conversation starts from zero. The AI doesn't know you've been on a project for three weeks, or how you like to work. Every session is introducing yourself again.
2. You always have to be there. It works when you call it. Close the window, it stops. You can ask, but you can't delegate.
3. The value evaporates. That brilliant answer at 11 PM gets lost in the history. Nothing accumulates.

I'll say it upfront: these ceilings are far less noticeable today than a year ago. Modern harnesses, your Claudes and Codexes, ship with memory, skills, automations and execution loops out of the box, and they solve more and more of this without you putting in effort. But the mindset jump I want to tell you about is still the same one, and it's exactly what lets you truly take advantage of all that.

For a long time I assumed those ceilings were just how it was. And then, almost without noticing, I crossed a line.

Changing the question

The jump from consumer to builder is not technical. It's changing the question you ask:

Instead of "how do I use AI to solve this problem?", you ask: "how do I build something that solves this kind of problem, once?"

Sounds small. It isn't. The first symptom that you're crossing over is that you start thinking in systems instead of answers: you see a problem you solve with the chat every week and think "I shouldn't have to ask for this every time".

How it went for me, in three steps

First, persistent context. The first thing I did was write down, in a few files, who I am, what I'm working on, how I decide. Sounds silly. The effect isn't: the agent stopped needing my life story every session and started giving answers that seemed to understand me. Not because the model got better, but because the context did. This was harder than I expected, by the way: it forces you to know what you want, and that's not always written down. Not even in your own head.

Second, the first automation. Going from "ask and receive" to "design and trust". For me it was a morning summary: every day, without asking, a message with what happened, what's coming, what arrived. The first time, it felt like magic. It's not: it's a scheduled job and well-written instructions. But the experience is completely different from opening a chat and asking.

Third, actually delegating. This was the hardest step, and the strangest one to talk about. At some point I started leaving tasks prepared for an agent to move forward without me, with limits, with verification, with my review at the end. The first time I found finished work I hadn't started, my reaction was to go check it. Not out of distrust... ok, yes, out of distrust. It was fine. That mix of "this is so weird" and "this is good" is the line. Before that, I was using AI. After that, I had a system.

What it asks of you

It's not free, and I'd rather say it plainly:

Writing down how you think. With enough detail that someone who doesn't know you could act on your behalf without embarrassing you. It's the hardest part and the most useful one: even if you never build anything, walking away knowing what you want is already worth it.

Accepting ambiguity (and fencing it in). LLMs are non-deterministic by nature: the same request can give you one output today and a different one tomorrow. That's not a bug, it's how they work, and fighting it will only frustrate you. The engineering work is elsewhere: first, know it. Second, box it in as much as you can. How? With guardrails that limit where the agent can go, with verification and validation on every step that matters, and by handing to deterministic processes (scripts, tests, plain old checks) everything that can be deterministic. And for whatever still slips through: review before anything important gets applied, logs of what happened, and a way to undo. It's not about avoiding every mistake. It's about making sure that, when they come, they're cheap.

Investing before seeing results. A good prompt gives you an answer in 30 seconds. A system can cost you a weekend, or quite a bit more if you want it good and well defined. The curve flips afterwards: the system works when you're not there. The prompt doesn't.

This is no longer just for developers

And here comes the part that's a bit uncomfortable for my guild: the criteria game now has room for far more people than it did when building required knowing how to program. I see it more clearly every day: someone who doesn't know (and doesn't want to know) what writing a line of code feels like can end up shipping a product where you can't tell the difference. Because the person brings the judgment, and the model brings the craft.

So where does technical knowledge fit? Look, I honestly can't quite see it yet, and I'd rather tell you straight: I believe people who know will still be needed, but I can no longer tell you exactly why or for what. What I will commit to is this: if you're reading this and you're not technical, the barrier between you and building is lower today than it has ever been. And it keeps dropping.

Where to start

You don't need anything sophisticated, and you definitely don't need anyone's setup (mine included).

Find the problem you solve with AI at least twice a week. Not the most important one: the most repetitive one. Write the instructions you'd give a new collaborator who had to do it for you. Save them somewhere you can reuse them. And when that works, make it run on its own.

That's it. Everything builds from there.

The difference between using AI and building with AI comes down to one question: do you want better answers, or do you want a system that works on your behalf? Both are valid, honestly. But only one gives you time back.