I Made 866 Commits in 5 Weeks. My Understanding Didn't Keep Up

AI has made me dramatically faster at building software. You can see it on my GitHub: a sudden surge of activity at the start of September, several projects started, and a few of them actually shipped.

That part isn't up for debate. I can go from an idea to a working prototype in a day. I can ask questions about an unfamiliar API, generate test scaffolding, trace a bug across a codebase, and get a second opinion on architecture without opening twenty browser tabs. Since the start of September I've used AI to build a desktop pet for Linux, an inventory app for a client, a terminal tool for my writing workflow, a walkable 3D library, and more experiments than I probably needed to start.

Commits per week to Mochi. The week of September 7 averaged about 47 a day.

AI also wrote most of that code.

Somewhere in the middle of all that shipping, I noticed something uncomfortable:

My ability to produce software was improving faster than my ability to explain the software I was producing.

That scared me a little. I don't think using AI makes the work fake. The projects run and people use them. What scared me was that I'd built my whole workflow around one question, "does it work?", and almost never asked the other one: "do I understand why it works?"

This week I got a clear look at how big that gap is.

What the gap looks like

I realized that I'm still missing a lot of CS fundamentals. The biggest holes are in how data gets stored and searched: hash maps, sets, indexes. I have a client app running on PostgreSQL right now, and I couldn't have told you what an index costs. That's not good!

So I sat down to start on hash tables. I got through how they store things and what happens when two keys land in the same slot. Then I opened Two Sum, famously the first "Easy" problem on LeetCode, and my brain filled up. I stopped for the night.

The software in my repos handles things I can't explain yet. That's what happens when the tool writing your code knows more than you do and you never make it show its work.

How AI hides your knowledge gaps

Before coding assistants, not knowing something created friction. If I didn't understand asynchronous JavaScript, database transactions, Linux permissions, or Python packaging, I eventually hit a wall.

The wall was easy to see. You couldn't keep going on the project until you got through it.

The wall was annoying, and it was useful. I had to read the documentation, inspect the error, try something, and be wrong a few times. Eventually a mental model formed.

AI changes that feedback loop. Now I can paste in an error and get back:

Here's the problem. Change these four lines.

Very often those four lines work, which feels fantastic. Then you realize you couldn't have explained the bug five minutes earlier, and you still can't explain it five minutes later.

The error disappeared. The wall disappeared. The knowledge gap didn't.

I thought I was avoiding that trap. I wasn't avoiding it nearly as well as I believed.

Debugging is where I can see it happening

There's a huge difference between these two workflows. The first:

1. Something breaks.
2. Paste the error into an AI assistant.
3. Apply the suggested fix.
4. It works.

5. Keep building.
   And the second:

6. Something breaks.

7. Reproduce it consistently.

8. Write down what I think is happening.

9. Figure out which part of that guess I can test.

10. Inspect the relevant code or logs.

11. Change one thing.

12. Ask AI for help when I actually need it.

13. Understand why the fix worked.

14. Add a regression test if possible.
    The first workflow is much faster. I think we all know this by now, but it also completely bypasses our critical thinking. Ya know? The thing that makes us good engineers.

The second one makes me a better developer. I've been spending most of my time in the first one, so I'm deliberately adding some friction back.

Four rules I've started holding myself to

1. Predict before reveal

Before I ask an AI why something is broken, I make myself write down a prediction. It can be completely wrong. Sometimes it's spectacularly wrong. But I have to write something like:

I think this state update is triggering another render, which recreates the object and causes the effect to run again.

Or:

I think two clients are updating this record from stale state, and the second write is overwriting the first.

Then I investigate, and only after that do I ask the model. Now the AI's response is feedback on my reasoning. That's a lot closer to having a senior engineer next to me saying "you're looking in the right place, but your mental model is slightly off here," and it's worth far more than a patch.

2. Don't accept code I can't explain

I don't need to understand every implementation detail of every dependency. Nobody does. But if AI adds an important chunk of logic to my application, I should be able to answer:

• What problem does this code solve?
• Why is it implemented this way?
• What assumptions does it make?
• What happens when it fails?
• What would break if I removed it? If I can't, I'm not finished. Sometimes I'll literally ask:

Explain this code to me like I'm the engineer who has to maintain it six months from now.

Then I read the actual code alongside the explanation. AI-generated code looks extremely confident, and that confidence makes questionable decisions surprisingly easy to skim past.

3. Ask "what test would have caught this?"

When something breaks and I finally understand why, I try not to stop at "great, fixed." I ask what test would have exposed this before a user did. Maybe it's a unit test. Maybe it's an integration test. Maybe the honest answer is that the failure isn't realistically testable at that layer, and that's fine. The point is to think about the failure mode.

A bug is worth more when it changes the system afterward. Otherwise I'm paying tuition to learn the same lesson twice.

4. Read the code before asking AI to rewrite it

This sounds painfully obvious, and I wasn't always doing it. When you're moving fast, it's tempting to highlight a file and say "clean this up." The model returns something prettier, the tests pass, and you ship it.

But refactoring is where a lot of architectural understanding lives. Why is this function coupled to that object? Why does this state live here? Why are these responsibilities mixed together? So now I try to work out what I dislike about a piece of code before I ask AI to improve it. Instead of "refactor this," I want to be able to say:

This module is doing persistence, validation, and UI state management. I think those responsibilities should be separated. Show me a few ways to restructure it and explain the tradeoffs.

I'm still using AI. I'm just making the engineering decision first.

AI isn't the problem

I'm not planning to stop using AI for development. That would be ridiculous for me. (I literally just paid for Claude Max, so I have to get my money's worth.) These tools let me explore technologies I'd otherwise avoid, find my way around unfamiliar codebases, skip tedious scaffolding, and ship. The tech behind them genuinely fascinates me, too. My mistake was assuming that a tool making me more productive was also making me more skilled. Sometimes those two go together. This month showed me they can come apart.

That puts newer developers in a strange spot. Someone with relatively little experience can now build surprisingly complicated software, which is exciting and somewhat intoxicating. But the complexity doesn't go anywhere just because generating the code got easier. Authentication still has security consequences. Databases still have consistency models. Networks still fail, and users still do things you never expected.

AI will help you implement solutions to those problems before you understand them, so you reach advanced problems earlier than developers used to. That's how I ended up with a production database and no mental model of an index. I don't think the answer is to stay away from hard problems. It's to notice when you've walked into one.

Using AI as a teacher

When I'm building something routine, I'm happy to let AI speed me up. When I'm in unfamiliar territory, I slow down on purpose. I ask questions, read the implementation, read the documentation, make predictions, and test my assumptions.

It's worth saying that the hash table lesson came from an AI. It's the same tool, aimed at what I understand this time and not at what I can output.

Not every line of code needs to become a lesson. That would make development miserable. But every project should leave me knowing something I didn't know when I started. Otherwise I'm accumulating software without accumulating any judgment.

The four rules don't cover writing code from scratch, so there's one more piece to the plan: one tiny problem a day with no AI at all. Count the words in a string. Dedupe a list. Twenty minutes, from an empty file.

The question I keep coming back to

If every AI coding assistant disappeared tomorrow, could I maintain what I shipped today?

I don't mean build it as quickly, remember every API, or reproduce every line from memory. I mean maintain it. Could I debug it? Could I explain the architecture? Could I safely change it? Could I tell when an AI-generated solution is wrong?

My honest answer right now is that I'm not sure, and I need to find out. So that's the next test: pick one feature from one of my own projects and explain it from start to finish by reading the code, with no AI. Wherever I get stuck is what I study next.

My GitHub already looks like it belongs to a better developer than the one who got stuck on Two Sum. I'd like to catch up to it.

Unrelated dev update:

checkout my new mochi designs!! I can't wait to implement. Im trying to figure out how to easily swap them out with the original sprite design without reanimating ALL of his emotes