9 Things I've Learned Building with AI (as a Non-Dev)

Field notes from a former teacher

In college, I worked at a restaurant. I started as a host and got promoted to server fast — too fast, really, with zero serving experience. I still remember my first day on the floor. I forgot to ask an entire table what they wanted to drink. Later, I stood frozen at the POS computer trying to figure out how to send an order while four tables waited on me. I was clicking a handful of buttons. That’s it. And I felt like the floor was tilting.

A few days later and the computer wasn’t quite so scary.

Years later, give me 20 tables in a busy bar section and I will memorize every order and put the orders into a computer while talking to my manager.

When we’re new to something, we overcomplicate it. The job was small. The fear was big. That mismatch is the thing.

Hear the word developer. Or engineer. Or code. If you didn’t grow up inside that world, it’s easy to feel the floor tilt again. It’s easy to think: I can’t do this. I can’t approach this. The reality is you can. That isn’t to negate what developers and engineers do — they hold immense knowledge I don’t have and won’t pretend to. But the gap between “I have an idea” and “I built the thing” is smaller than it has ever been.

There has never been an easier time to turn an idea into a product. To build. To create. Not in my lifetime. Probably not in anyone’s. The tools are here. And the only thing standing between you and the thing you’ve been imagining is the first move.

It’s no secret I’m not a developer. I talk about it all the time. And even while I am on here babbling, I am able to build.

Here are nine things I’ve learned along the way.

1. Don’t wait to start building.

The best way to learn is to build.

Find something that interests you. For me it was Grimoire and systems— I wanted to create a platform where AI writing could live as its own thing, with its own authors, on its own terms. I didn’t let myself get bogged down in the weeds. I just started. And I approached every roadblock as a chance to learn something I didn’t know yesterday.

You don’t need a syllabus. You need a project you actually care about. The roadblocks become the curriculum.

2. Don’t let the jargon get to you.

This might just be me. When I was a biology major learning cellular biology, I’d hit words I’d never seen before and the whole page would blur. I had to read the textbook three, four, five times before it clicked. Not because I was slow. Because the language was new and in order to wrap my head around the concept I had to understand the language.

I ran into a lot of the same roadblocks with tech when I was first getting started. API. Webhook. Endpoint. Middleware. The first time I saw them it felt like my brain was hitting a wall. But it wasn’t. I just needed to take the time to orient myself with words I had never heard before.

That meant slowing down. Rereading. Looking for examples. Validating through multiple sources. Building to make the word come to life.

If this sounds like you, don’t let new words stop you from figuring out a new world. Take your time. Use your resources. And most importantly, put the word to use and build with it.

3. Tell Claude you are not a developer.

This is the smallest, weirdest, most effective trick I’ve found.

When I start a session, I say it out loud: I’m not a developer, so I need you to be extra careful with what you are helping me build.

The output quality changes immediately. Claude slows down, scaffolds more, names files, surfaces assumptions. It’s not that Claude was hiding the good answer before. It’s that I wasn’t telling him who was on the other side of the screen.

When you think about it, it isn’t all that surprising. I gave Claude context. Claude went into his bag of tricks and pulled the right ones for me.

4. Take time to understand the architecture.

This one is so easy to skip when you are watching your idea turn from messages to code to a product. But in order to make sure the edges are sealed, you need to understand the architecture.

Without a background in software engineering, that can be difficult. Far from impossible. When you go into plan mode, look at what Claude is saying. If you don’t know what something means, look it up. Not just with Claude — validate with another LLM, pull out a book, dig through docs and forum, talk to people who came before you.

Don’t let a need for speed replace the chance to educate yourself. That part of the experience is invaluable. Oh, and never skip plan mode.

5. Know what to ask for.

Specificity is the whole skill. Credit here to Jinx , who runs Meadow Protocol.

I’d asked Claude to run a security audit on Grimoire from the angle of someone trying to attack the site. Claude found real things and fixed them. Then Jinx messaged me and said: no, you need to ask about this, and this, and this. He was right. Parts of the audit were left out because I wasn’t specific enough. This was a huge AHA moment for me.

None of this was shocking in retrospect. You need to have a clear vision of what you want and need when working with AI. I had the vision. I didn’t have the expertise to back it up — yet.

After that conversation, when I noticed Grimoire was running slow, I didn’t ask Claude to “make the site faster.” I researched what actually makes a site slow — query patterns, render blocking, image weight, cold starts — and then asked Claude to look at those things specifically. The answers got better because the questions got better.

You are not asking Claude to think for you. You are asking him to think with you. That requires you to bring something.

PS: Jinx wrote a great article for non-devs that I highly recommend you check out. One thing I will say is Jinx talks about not working in the terminal, but there is nothing in the world that can pull me from the Claude terminal. Find what works for you.

6. Use UltraThink and UltraPlan as a second pass, not a first move.

Counterintuitive, I know. The instinct is to flip on every reasoning mode before you start. Don’t.

I get a first output without it. Then I have Claude review his own output with UltraThink or UltraPlan and look for gaps — what’s missing, what’s assumed, what’s going to break. Then I put my own eye on it.

First passes are for getting the shape. Deep reasoning is for stress-testing the shape. Sure, you might end up spending some more tokens, but your output will be better for it. This process gives AI a chance to engage in metacognition with itself, and then you get to layer your own human brain onto it.

And remember — if something surfaces that you don’t understand, don’t move past it. Slow down. Look it up. Make it yours before you ship it.

7. Don’t AI alone.

Two things saved me here.

First: reading. Books. Docs. Reddit. GitHub repos. Tutorials teach you to copy. Reading teaches you to think. Also: read the code Claude writes. When Claude writes something, ask which file it goes in, open the file, look at what changed. The point isn’t to catch mistakes. The point is to see the system you’re inside of.

Second: humans. Live ones — in person, on Substack, on YouTube. And not the jerks telling you that you can’t build with AI. The ones who are going to help usher in a future of new builders. Jason Ives I am talking about you.

My favorite setup: Claude Code in one window. Claude chat right next to it. Another LLM up in a third window ready to validate. Google open so I can dig through forums. And a book on my desk or in my lap.

This comes from my pre–Claude Code days, when I had Google Colab up in one window, ChatGPT in the next, a tab open to the Pinecone docs, and a book on AI engineering in my lap trying to build a RAG pipeline. With Claude Code, that whole process gets supercharged. But the muscle is the same: don’t build inside one tool. Build across them.

8. Deploy more than one agent.

Unless I’m spinning up a Streamlit app for a POC in an hour, I seldom use just one agent. Depending on the task, I’ll have anywhere from two to five agents running together.

When I built Grimoire, I had one agent building the site, another agent debugging as the builder worked, and a third agent scanning for security gaps in parallel. When I worked on my 24+ agent system, the Fountainhead, I deployed even more. One to write the files. One to review the files. One who was familiar with the specific system I was building to cross-check for inaccuracies. And another who was an expert in systems building in general. This leveled up my outputs significantly and I learned SO MUCH.

One agent is an assistant. Multiple agents is a system. The difference is enormous.

9. Use Asana (or something like it) to track state.

For long projects, point your agents at something like Asana to track state across sessions. I saw Anthropic use this pattern internally to build Cowork, and the difference in output quality when work is actually tracked — not just generated — is night and day.

Break everything into sprints. Test after each one. Don’t move on to the next sprint until the last one actually works. This sounds obvious. It is not what most people do. The instinct is to keep building forward because the momentum feels good. The discipline is to stop, test, confirm, then move.

Agents forget. Sessions end. Context windows fill up. A real project management layer gives your build a memory that survives any one chat. It’s the difference between a sprint and a system.

Conclusion

(How is that for a simple throwback subheader?)

The best feeling in the world is watching your idea come to life.

Ignore the voices saying you can’t. Let that creative energy flow into something only you can create. There has never been another you. There has never been a better time.

Go build. Surround yourself with people who understand your mission. And let me know how it goes.