The idea came to me here, after reading this guy's post:

Pretty funny — it's actually not just some random dude, it's the great Uncle Bob himself. I remember, 7-8 years ago, reading his books and using his clean code patterns in my work.

I also remember trying to use some of his suggestions about team management and applying them to a small team.

Also, while checking old documents, I found this site:

The reason we don’t clean up code—the reason that software systems rot over time—is that we are afraid that cleaning the code will break the behavior. But if we have a way to clean up code that we know is safe, then we will clean up the code, and our systems will not rot.

— Uncle Bob

Pretty funny, because exactly today I wanted to clean some code and experienced the same feeling: what if I break something, how can it be fixed after, do I have enough tests?

But wait... this article is about reading code, let's think about this a little.

There was a beginning

I'm a happy survivor who still remembers the old times, when we used to open StackOverflow or even some creepy local forum (that still emails me a gift card on my birthday), copy something -> doesn't work -> search again -> find -> doesn't work -> repeat.

Yeah, and the thing was, you had to learn English anyway, because even if you had a big community in your language, the English-speaking community was still bigger.

But back then, when we found code samples, we had to read them, analyze if they worked for us or not — we weren't used to copying them into our project blindly! And that used to teach us how to preview the behavior of the code and whether it resolved the problem or not.

I also remember the time when, at university, professors made us write code on A4 paper, because they were afraid we'd cheat using computers. (No, this wasn't in the 90s, nor the 00s, nor the 10s — damn, that was a super stupid practice to "teach us" to write better code. If only they'd known that it would've been better to teach us English, if only they'd known...)

On top of that, reading Clean Code, Networks, The Dragon Book required reading a lot of code snippets. Sometimes I was like "wtf is written here" and reread it again and again until I understood every line. Imagine — sometimes these snippets weren't just single-line imperative programs; no, it was a huge 3-4 page program where the function A, called on page 1, was implemented on page 3, and so on.

So yes, we had to read code — we were obligated to, we couldn't survive without this skill.

Current time

So, what about today? Do we still need this skill?

Yes and No, and IDK.

The problem is that there's progress happening right now, and it's evolving super fast — we couldn't even have imagined, 3 years ago, that AI would be editing our codebase.

NO

Uncle Bob is right that he's old enough to know a thing or two about programming — he wrote good books that lots of people used to write code. I'm 100% sure that most developers of current AI models have read these books.

I'm more than 100% sure that these AIs were trained on these books.

So, basically, AI is trained to write "Clean Code" by default, isn't it?

If we've read the book, we probably know that "Clean Code" is not only about code clarity, but it's also about how to develop and maintain the project structure:

  • code layers
  • function responsibility
  • function naming
  • test coverage
  • and so on...

So basically, why do we need to read the code if an AI tool will write everything like this? And if we explicitly ask it:

Use "Clean Code" patterns to write X

It would use all these patterns, the same way we can put it in a "SKILLS.MD" file.

And so on — we can keep reading Uncle Bob's Twitter and find that he has plenty more ideas about creating QA and test agents that help review/test/fix code.

YES

Security. That's a scary word, and it's the number one reason to read the code. We don't know if a key has been leaked in the logs during the debugging process. Do we know that the AI tool hasn't been poisoned to create a breach in our code? Can we trust it? And here's the answer: no.

No way I will trust the AI coding tool with my work. I can't tell my boss "it's all AI, it's not me."

Another reason is that most of us aren't English natives, and explaining something to AI in English can cause misunderstandings. But also, you can't speak to it in your native language, because:

  1. You're not foolish enough to do that
  2. You're losing nearly 2x the tokens
  3. You're not foolish enough to do that, you've studied English for so long in your life, you can't just not use it

And yes, the language barrier is tough enough, and AI doesn't always understand what you just tried to ask it to do. And that's a strange feeling, when it writes you something you didn't want.

Of course, tests, QA, praying, and begging should help, but we're losing time... A test finds that there's an issue -> you go fix this issue with AI -> AI misunderstands you again -> tests are failing again... and so on and so on. DUDE, YOU JUST HAVE TO READ THE CODE and understand where the issue is.....

IDK

I really can't imagine what things will be like in 1-2 years. I agree that trying to maintain "Clean Code" with AI means:

  • explicitly telling it to use these patterns
  • having tests for each function
  • writing e2e tests
  • using linters
  • using known libraries

All of this will help us stop reading code, but are we at that point now or not? I don't know. I still feel that AI is very raw. I do try to use some of these patterns where I can (probably soon I'll describe my approach), but AI still makes errors, and we still don't have a real mechanism of accountability. So, as far as it's up to me: I WILL CONTINUE TO READ THE CODE, no matter how smart AI gets.

HOW TO

It would be a damn to finish the article without some ideas on how to read code.

So, idea #1: DON'T PUSH HUGE COMMITS, don't do this. Forget that your AI tool can fix every issue in one commit, just forget about it. Small changes, baby steps. Our brain can't analyze a huge amount of info at once, and mostly, in the AI era, we need everything shipped as fast as possible, so we end up generating shitcode in a single AI prompt.

When could that be fine:

  1. The project is initialized and you've created the project structure: mostly new classes without heavy logic, just the project start + a couple of docker files
  2. When you need to bring in a big feature. For example, you need to connect a new service to your project that will take data from X and put it in Y. Here it's also possible, because we maintain the same project pattern: Client, Data class, Tests. But even then, it's an issue: we have to be careful not to overload it with "fixing bugs"

In other cases: 1 issue -> small solution -> read code.

Next, idea #2: Check the code to see if any logs contain any keys. Don't trust logs blindly — if something is logged, there should be no client/key info in it. If there is, it has to be a debug-level log (which has to be disabled in prod, right?)

idea #3: Check for anomalous patterns. The code you're reading has to be super simple: nothing strange should catch your eye. If service X does job Y, it has to do only that job! No other action should be there.

idea #4: Check algorithms. Yes, most new languages have algorithms under the hood and the golden rule: if something is already written and widely used, you probably don't need to rewrite it. BUT, if you came up with a super algorithm, check it manually, if -> else, ask the AI to write unit tests, then check the unit tests: do they cover everything?

Yes, we are living in a fast-changing world. AI is smarter than we are, and it will be smarter than we expect. But for now, as far as responsibility is on us -> we have to be responsible for our code, of course not read it in full, but try to maintain it clean with the help of AI.