AI is the ready-made cheat sheet

Have you ever had the feeling that you’re forgetting the code you’ve been writing with AI?

I must confess I still remember good chunks of code I wrote 10 years ago. I remember the folder structure, the tests, the classes and everything else I organized in some of those projects. But these days I find it harder and harder to remember snippets I wrote just days ago.

I have the impression this effect is a lot like when we used to cheat on tests (not that I ever did that). You studied and wrote to make a good cheat sheet, and on test day you didn’t even need it, because you had already understood most of the subject while trying to make the cheat sheet. The learning was in the scheme. Between summarizing the whole subject, perfecting your ant-sized handwriting and rehearsing the perfect fold of that little piece of paper, you ended up studying by accident. Writing code line by line was exactly that, the honest version of the cheat sheet. Today’s AI is the ready-made cheat sheet, you get the answer without going through the process that made knowledge stick.

If you’re writing real code, code that affects companies’ day-to-day, code that can’t fail and has to be resilient, you probably share my concern. How do we deal with this intensity of information and still truly understand the systems we maintain?

I’ve been applying and studying ways to keep my sanity in the times we’re living in. That’s what I want to share here.

The more you understand, the less in the vibe you are

When we talk about vibe coding, I see it as a spectrum. The more you understand the code, the less in the vibe you are.

That’s not entirely bad, depending on the problem you’re solving. But my point is another one. The more you create in automatic mode, the less deep understanding you need to have. Maybe you won’t even need the basic understanding, if your prompt is just “build an app for me”.

This automation creates speed, but it creates lack of knowledge too. And this is where I wanted to get. The amount of code we can produce has become completely disproportionate to the amount we can assimilate. The more code, the less of it you understand.

And it’s not just my impression. An analysis of 211 million changed lines of code showed that, since AI assistants arrived, the volume of new code exploded while refactoring collapsed. It makes sense. Refactoring requires understanding the repository, accepting generated code only requires hitting enter.

Kent Beck, creator of TDD and Extreme Programming, has been describing this phenomenon in his own routine with agents. When AI speeds development past the pace of code review, the bottleneck stops being catching bugs and becomes keeping the structural integrity of the system. In other words, the bottleneck is no longer writing code. The bottleneck is now us, trying to keep up.

Real code

In a dev’s day-to-day, vibe coding is more the exception than the rule. Again, nothing against it, but nothing in favor either. It has its place, which is any code with no commitment to tomorrow. The problem is that code has a habit of outliving its creator. And code that survives without anyone understanding it already has a name, and it’s a name nobody likes to hear. Legacy code. Vibe coding in production is manufacturing legacy code at the model’s speed.

You need to care about what you’re building. You need to understand what’s going into your codebase, need to understand what the AI generated, need to understand whether it fits the style of your codebase. Most of us already in the market work on codebases that aren’t greenfield. They’re codebases that have existed for years and now need to coexist with the AI way of coding. Not that refactoring and modernization aren’t welcome. But done the wrong way, they create another knowledge gap in the team.

I say this because if you let your project’s complexities slip by without paying attention, that will make you not learn. And not learning means retention gets much lower. You can no longer follow the structure, no longer reason about the decisions the AI is making (it will get things wrong, and often), no longer debug when something breaks (yes, there will still be bugs), no longer evolve something you didn’t build.

This problem, by the way, wasn’t born with AI. In 1985, long before LLMs existed, a classic essay already argued that a program is, in practice, the theory that forms in the head of whoever builds it. The theory isn’t in the code or in the documentation, it’s in people’s heads. When the team that understands the system leaves, the program dies, even if it keeps running. What’s new about our era is that now you can produce code without forming any theory at all.

If we’re honest, writing code has always been the easy part of the job. The hard part is understanding, operating and evolving that code over the years it will live. AI solved the easy part. The hard part is still all ours.

The path I’ve been following

Using AI in an assisted way seems to me a much more beneficial path for maintaining a project. You don’t let the AI go on its own, you guide it. It’s not the same as writing code thinking about every line, but it’s much better than seeing no code at all during the process. And that doesn’t mean you can’t use automatic mode. Use and abuse it for tedious tasks.

The value comes when you can follow the output and stay aware of aspects that aren’t exactly evident at coding time. Knowing how to consider the project’s -ilities (scalability, resilience, maintainability and the whole family). Knowing when and how to make tradeoffs. Knowing how to say no to an overengineered solution. Knowing when to go with a pragmatic, pointed solution. None of this comes from memorization. It comes from awareness of the project.

There’s a famous observation that AI quickly gets you about 70% of the way. The problem is that the remaining 30% is exactly the edge cases, the integration with what already exists, the security, the debugging. The part that only comes out of understanding the system. If you didn’t follow the 70%, the 30% becomes a wall.

Less assimilation is something we’re going to have, that seems inevitable at the volume we’re producing. But that doesn’t mean you need to produce code you don’t understand. As a golden rule, think that every piece of code you ship you need to be able to explain. If you can’t explain it, it shouldn’t have been committed.

And use assisted programming sessions to learn too. AI is constantly generating patterns or bringing solutions you don’t necessarily know. Use that moment to go deeper, there’s a fantastic gain living there. Don’t just let the session roll, use it to your benefit.

Making my own cheat sheet

There’s no ready answer for the moment we’re living in. Tools change every month, models get better, and what’s good practice today may be irrelevant next year. The path is open, and each dev and each team will find their own balance between speed and understanding.

What seems clearer and clearer to me is that our capacity to assimilate has become the scarce resource. Code, AI produces in abundance.

At Barte we’ve been building this in practice. The paved road we already wrote about here is part of the answer. The same guardrails that speed the team up, the tests, the review, a standard path to ship code, are what make it safe to put AI to work without losing sight of what’s going into the codebase. AI moves fast, but it moves inside the road.

Ten years from now, I don’t know if I’ll remember the code snippets I’m writing today. But I want to keep truly understanding the systems I maintain. Just in case, I’m still making my own cheat sheet.