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.

The Subtle Sign You're Growing as a Coder

You know you’re growing when:

• You don’t get stuck on compilation errors for missing semicolons
• You’re not rushing to code without doing some planning
• You know when your code looks or feels funny

But there’s another subtle sign of growth:

You let others into your code and you don’t take critiques on your code personally.

Being an overprotective coder

Oh boy! In my first job, I didn’t want anyone else to touch my code.

Each team member worked solo, with almost no collaboration. And after finishing Clean Code, I thought only my code met all the standards. I didn’t want anyone else to infect it.

Then at my next job, it was almost the same story.

Along with a small team, I worked on the core features of the main app. Only a few touched it. And it hurt to see my code rewritten during the app redesign to make it scale.

Learning not to be one with the code

After moving between projects and companies, I eventually learned that I’m not my code.

Critiquing my code isn’t critiquing me. Bugs happen. Edge cases get missed. Requirements get misunderstood. And when that happens, someone will pick my code and say “Who wrote this crap?” The same way I said that when I inherited somebody else’s codebase.

Get your code in front of others, let them change it, tweak it, and critique it.

That’s the key to growing as a coder. And that’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding. Nobody told junior me that writing simple code others could inherit and improve was part of growing.

Grab your copy of Street-Smart Coding here This is the roadmap I wish I had on my journey from junior to senior.

I'm Launching Street-Smart Coding: 30 Lessons to Help You Code Like a Pro (the Roadmap I Wish I Had Starting Out)

I spent five years in college learning to code.

A stupid dissertation delayed my graduation. But that’s another story.

Most of my five-year program didn’t prepare me for real-world coding. My real coding journey began at my first job, with one Google search: “how to get good at coding.”

I found a lot of conflicting advice:

• “Use comments”
• “Don’t use comments”
• “Do this”
• “Don’t do that”

Arrggg!

It took years of trial and error to learn what worked.

I had to survive on-call shifts, talk to stakeholders, and say “no” politely. More importantly, I had to learn that coding takes more than just syntax.

That’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding Without Losing Your Mind, so you don’t have to go down the same rabbit hole.

I wrote it for every developer who’s ever typed “how to get better at coding” into Google or ChatGPT, just like me back in my first job.

Inside “Street-Smart Coding”

Some lessons inside Street-Smart Coding are conventional. Others were learned the hard way. And a few are weird.

One of the tips will save you from staying at work until 3:00 a.m. That’s on Chapter #21.

Another tip is to watch a TV show. And no, it’s not Mr. Robot or Silicon Valley. That’s on Chapter #29. It will teach you about problem-solving.

But all the tips and lessons are battle-tested.

These are the lessons I wish I had starting out, the lessons I learned over ten years through plenty of mistakes. Now they’re yours.

Get your copy of Street-Smart Coding here