The Real Problem With AI Writing All Our Code

AI might promise speed and productivity. But it comes with serious issues.

The other day I found a senior coder quitting AI coding after finding out that:

1. AI was like a sloppy coder who bypassed tests and wrote bad code
2. AI had stolen all the joy of solving problems from him

After experimenting with AI, I realized I was becoming lazier than usual. Since then, I’ve set simple rules to avoid losing my skills.

But those aren’t the biggest problems.

A failed experiment revealed a more serious problem

Today I found out about the experiment of a team of coders that revealed a deeper problem.

After trying to write a feature at work only by prompting, they realized:

[Even when AI is capable of writing all of our code], a huge issue remains: I lose my mental model of the codebase. … Until I can trust the AI completely, I need to keep my own mental model alive. Otherwise, every time I need to do something myself feels like joining a new company.

It takes time to get familiar with a complex codebase. At past jobs, it took me about a year to feel confident. Of course, your mileage may vary.

But when that happens, you feel like driving through familiar streets with only one hand on the wheel:

• You know the architecture, the folder structure, and even a rough sketch of code blocks.
• You know how modules connect and what to touch or avoid.
• You can even remember file and function names.

You’ve built the mental models and gained all the context. Without them, you feel like walking into a dark room.

When AI writes our code, it’s stealing the context and the feeling of knowing a codebase like the palm of your hand.

Use AI if you want, but be the one dictating what to do. Draw the boundaries of the solution, then let AI fill in the details. Be the pilot and let AI be your copilot.

When AI can handle syntax, it’s time to work on skills it can’t, like collaboration, clear communication, and problem-solving. That’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding, the roadmap I wish I had on my journey from junior to senior.

Get your copy of Street-Smart Coding here

Three Things to Remember When the Haters Show Up

Future me:

Yesterday I woke up to a comment on a coding post we reposted on Medium. It said, “you are just marketing your book.” It included some profanity, but I’m not adding it here.

I just launched Street-Smart Coding last week. And yes, I’ve been promoting it by turning every post into a sales rep. Hey, singers promote their concerts and writers go on podcast tours, right?

Here are three reminders for you, future me:

#1. Remember the 30/30/30 rule

Keep in mind that no matter what you do:

• 30% will love it
• 30% will hate it
• 30% won’t even care

Well, technically it’s 33.333333%, but you get the point. That commenter was just part of the second 30%.

And good or bad publicity is still publicity. That hateful comment was signaling Mr. Algorithm to promote your post even more.

#2. Remember why you started

There’s a hill to die on:

Either you sell something (even a $1 pdf) or sell your time in a 9-5. You’re not going to like one of the two.

And if you choose to stay away from a 9-5, you’ll have to embrace sales and marketing. You have to be your own sales team.

#3. Fight your negativity bias

A single negative comment will make you forget the thousands of positive ones.

Open your victories file and your book sales. That’s your first 30%. Show up for them. Here’s a small victory…and another one here.

You spent years building somebody else’s dream and business. Now build yours. Don’t be ashamed of promoting your own work. Influencers and millionaire writers do it. You can do it too.

Let them talk. You keep doing your work.

Read this as many times as you need.

AI's Hidden Gift: We're Rediscovering the Practice of Coding

We’re searching for the best way to get working code from LLMs.

To avoid falling into the vibecoding trap, some developers are turning into structured approaches.

The other day, while catching up with some friends, one of them preached Spec Kit and its Specify/Plan/Tasks/Implement process like the holy Gospel. That’s GitHub’s approach to coding with AI.

More recently, I found The AI development trap that wastes your time on dev.to. It includes these four questions to regain control after drifting from too much prompting:

Do I understand exactly the specifications I’m trying to implement, or the bug I’m trying to solve? Do I have an exact plan for implementing my changes? What is the current abstraction level to which I should be prompting now? Which other information am I lacking?

Spec Kit and those four questions capture the essence of coding.

So to better code with AI, we have to do what we’re supposed to do as coders in the first place:

1. Understand the problem to solve
2. Decompose that problem into smaller ones
3. Think at the right level of abstraction
4. Ask enough clarifying questions

Ironically, AI is making us go back to the mindset we should have never left behind.

Context comes before coding, with or without AI.

That’s why one of the principles I included in my book, Street-Smart Coding: 30 Ways to Get Better at Coding is “Don’t rush to code.” (That’s on Chapter #3.) That’s even more helpful with AI as your coding assistant.

Coding isn’t just about syntax. It’s about clear communication, thoughtful problem-solving, and knowing what questions to ask.

Grab your copy of Street-Smart Coding here

Friday Links: Coding like a surgeon, surviving a stroke

Hey there.

Here are 4 links I thought were worth sharing this week:

#1. I’ve been thinking about how to adopt AI. I don’t want to outsource coding. I still want my hands dirty. I thought we should be like the lead surgeon in an operating room. But I’m not the only one thinking to code like a surgeon (6min).

#2. We can reduce the whole clean code discussion to a few principles, like “separate specific code from generic code” (That’s the one I cover in Street-Smart Coding, by the way). But there’s a similar one: pure core, impure shell (3min).

#3. The tech industry made me sick last year, literally and figuratively. It was life-changing, though not as serious as surviving a stroke (5min). Even if you haven’t had health issues, that’s worth reading. You can always find a new job, but not a new body. You need boundaries.

#4. With big corporations eager to make money, the dream of running what we want in our devices seems to be gone (10min).

Also on my blog this week, I shared about the subtle sign you’re growing as a coder (2min) and 5 lessons from a mentor that helped me become senior (4min).

(Bzzz…Radio voice) This email was brought to you by…

If you’re looking to level up your coding skills, Street-Smart Coding: 30 Ways to Get Better at Coding is here. No more “preorder” or “just 5 tips to get you started.”

Some of the lessons inside are conventional. Others were learned the hard way. And a few are weird. (One of the tips is to watch a TV show. That’s on Chapter #29.) But all the tips and lessons are battle-tested.

Grab your copy here. Just for a few days, you can pay what you want (even $1 or $2). No tricks or treats.

See you next Friday,

Cesar

Want to receive an email with curated links like these? Get 4 more delivered straight to your inbox every Friday. Don’t miss out on next week’s links. Subscribe to my Friday Links here.

TIL: Always Wrap Collections in API Responses

Note to future me:

You’ve learned this before. But it’s easy to forget or let teammates (or clients) make the same mistake.

Always return collections wrapped inside a response object from your APIs.

Adding fields, like pageNumber and itemCount, won’t break the UI or other clients. This is one of the few places where you should forget about YAGNI. Remember You Aren’t Gonna Need It? Is that still a guideline in the future with AI? Anyway…

Please, don’t do:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () =>
{
    return new[] { "Titanic", "Terminator" };
	//     ^^^^^
	// Please don't.
	// Otherwise a cute baby panda dies in the forest
});

app.Run();

Instead, please do:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () =>
{
    return new
    {
        Items = new[] { "Titanic", "Terminator" }
        // ^^^^
        // OK, with a proper object.
        // You know we're lazy with the examples
    };
});

app.Run();

Just today, in a client project, I realized we let this mistake happen and we had to update almost a dozens pages in a Blazor app.

Make this an API commandment.