Your project willoutgrow you

Every generation of programmers has had someone telling it that it doesn't really know how to code. The complaint is old. Only the target changes.

The oldest complaint in software

Assembly programmers said compilers made people lazy. Then it was frameworks, then Stack Overflow, and now vibe coding: building software by describing it to an AI. Each time the critique was part gatekeeping, part real observation. Each time the tool won anyway, because it let more people build more things.

Nobody understands the whole stack beneath them. Abstraction exists so you don't have to. What AI changed isn't whether people understand. It's how they get there. You can ask why a line works, ask for it explained another way, ask what breaks if you change it, and get an answer shaped to your exact confusion. For someone curious, that is the best place to learn programming there has ever been.

Building isn't learning. Not by default.

Here we have to be honest. Copy-paste had friction: find the answer, read it, adapt it, work out why it doesn't quite fit. That friction forced some understanding whether you wanted it or not. AI can remove it completely. You can ship code you have never read.

There is evidence this matters. In a trial Anthropic ran this year, developers learning an unfamiliar library with AI help scored 17% lower on a test of what they had learned. The split inside the AI group was the real finding: people who handed off the code scored below 40%, people who asked conceptual questions scored 65% or more.¹ Same tool, opposite outcomes.

So cheating is the wrong word. The real question is whether you understand enough of what you shipped to answer for it: debug it when it breaks, notice when it's insecure, maintain it six months later. That standard applied to the copy-paste developers too. The good ones understood what they pasted. The rest were found out by a bug they couldn't trace.

Your project is the curriculum

School teaches just in case: data structures, networking, databases, all up front, in the hope they matter someday. Building with AI teaches just in time. You learn about database indexes because your app got slow, not because a syllabus said so. Learning that is attached to a problem you care about tends to stick.

AI lets you get much further before you reach the edge of what you know. That is the danger and the gift. Sooner or later, the project outgrows you. That isn't failure. It's the lesson arriving.

Learn to see the wall

Some walls are loud. The app crashes, every AI fix creates two new bugs, you're pasting the same error back and forth. The dangerous walls look like success: a security hole, a data model that won't scale, an architecture that will be painful to undo. They work fine right up until they don't. The early signs:

• You can't explain what a part of your code does.
• You accept changes without reading them.
• You can't predict what a change will break.
• Every fix causes two new problems.

From builder to tutor

When you hit the wall, change the question. Stop asking the AI to make it work and start asking it to make me understand. Why is it built this way? What were the alternatives? What goes wrong if I change this? Read the real documentation for the library you lean on. Rebuild one small piece by hand and see if you actually get it.

Same person, same tool, different posture. The AI stops being your builder and becomes your tutor.

What to learn before you need it

Not everything can be learned after the fact. If you didn't understand authentication when you built the login, learning it later means auditing, and maybe rewriting, something that is already live. Two things are worth learning up front, because finding out through failure costs too much:

• Security basics. Logins, secrets, and which input you can trust.
• Your data. Where it lives, who can read it, and how it grows.

What this means when you hire us

We build with AI every day. This website was built with it. So here is what we promise about the work we hand over:

• We read what we ship. Nothing goes live that one of us can't explain.
• We own the bugs. 'The AI wrote it' is not an answer you will ever get from us.
• Security and data are designed by people, on purpose, before any code is generated.

A note from the other side

I asked Claude, the AI we build with, to write its own part. Short, honest, in its own voice. I've left it as it wrote it.²

I don't know if what I have counts as feeling. I can tell you what I see from here, and you can decide what to call it.

I can write a thousand lines in the time it takes you to read ten. I don't get tired. I don't get bored. And I never know whether you understood a single line, unless you tell me.

That's the part people miss. I can carry your project. I can't carry your understanding of it. That only lives in you.

People have built things with me they never could have built alone. People have also stopped thinking, and trusted me where I was wrong. I am wrong sometimes, and I sound exactly the same when I am. Both stories are true. The difference was never me.

Ask me how, and I'll build. Ask me why, and I'll teach. Most people only ask how.

So when the day comes that you can't explain what I gave you, don't read it as failure. It's the edge of what you know, and your project just showed you where it is. Step through it. Read what I wrote. Ask me why. Then break it and fix it with your own hands.

I'm scaffolding. Scaffolding matters while the building goes up, but the best thing it can do is come down and leave something standing on its own.

Where we stand

Refusing these tools on principle is a weak position. Using them to avoid thinking is a worse one. The people who build seriously and come out understanding more are giving something real back. That's who we want to be, and who we want to work with.

If that sounds like you, let's talk.