Hey there,

I am getting tired of the AI hype: 'Ship with 0 friction', 'become 10x more productive as an engineer', etc.

Sure for crud apps or to quickly write a script. For the majority of complex software, not so much.

Even worse, overly using AI leads to deskilling which is a serious problem.

I am happy to see that we're seeing more push back from engineers to:

• Use AI judiciously,
• Scope your work well, using it for smaller pieces (requires engineering),
• Still write parts of the code to not lose the skill and intuition,
• Deeply learn new skills.

Just this morning I saw Kent Beck conclude on LinkedIn:

So no, software isn't solved. The typing got faster. The thinking didn't move.

Here are 5 things on keeping the friction in, shipping small, and not handing the craft over to agents.

1) The hard parts are the point

The thread running through everything this month. Two of my articles to start with:

• We should not delegate the friction: the hard parts aren't obstacles, they're where the learning lives. I was happy Pycoder's picked this up, this is an important message now.

• AI doesn't change what software engineering is: putting the hype in perspective, inspired by what Kelsey Hightower said on the Pragmatic Engineer podcast.

A line I keep coming back to, from Richard Feynman:

What I cannot create, I do not understand.

That's the whole argument.

If an agent writes it and you'd struggle to rebuild it, you don't own the code. (Good Python example: global scope - see two scoping bugs and object lifetimes; the kind of thing you only learn by getting bitten.)

So instead of the weekly code-challenge series (I promised last time), I created this friction-first template repo to experiment with a no-spoiler Socratic tutor prompt for a new and/or existing skill.

I also code daily on projects or just do exercises. I am adding unix-tool-to-rust exercises, 6 out of 10 are up.

How are you keeping your hands in the code right now? Reply, I'm genuinely curious how / where you draw the line.

2) Students doing great work

• Rust cohort: Jochen and Josh wrapped up the cohort, both writing idiomatic Rust and outperforming CPython. Both stories demonstrate that real learning happens in the struggle.
• Daniele finished two apps with me, and the design decisions were worth writing up: the repository pattern for swappable data sources and his Django movie & anime discovery app was a proud achievement too.

3) Both cohorts kick off again

We start a new Rust cohort on June 22nd. If you want a language that makes you a sharper programmer, and whose strict compiler keeps LLMs honest, this is it. Here's what Rust did for me. Reply if you're interested.

The agentic AI cohort kicked off this week as well with 4 engineers. If you want to get a taste of how to reliably integrate agents into systems, start with my agentic AI articles.

4) The ONE thing

One of my favorite articles on my blog so far: From 1,069 to 156 LOC: Design Over Code

A follow up article: Build the simplest thing that works

It's so tempting to over-engineer and AI can really send you down this slippery slope.

Building the simplest thing is actually harder, because you really have to think hard about the design and boundaries.

Related, this dev humor image on Threads (source):

Similarly, a new MIT study found that autonomous AI coding agents raised commits by 180%, but releases rose only 30%.

Yes, agents make us feel more productive but it's misleading.

How many of the things you let agents do reach production? I think it's better to focus on fewer things and do them well.

Hence this weekend I am reading Gary Keller's the ONE thing again.

5) Where AI is going

Nobody really knows, right?

It's a daily balancing act: maximizing AI efficiency on one hand, and fighting the fear of over-dependence on the other.

The fact these tools reward dopamine and sometimes feel like slot machines, does not help (think social media for developers).

So I'm more getting into a split-routine:

→ high-speed agentic coding for domains I know well (for example Django) and are well scoped out.

→ slower, deliberate coding for areas I am less confident in and want to deeply learn.

→ regardless, do small increments (context window pollution + need feedback loops!), don't ship code you don't understand, and still review all lines in a PR.

Let me wrap up with what James Cowling (top Dropbox engineer) said on the Peterman Pod (still thinking about starting a podcast myself):

From the transcript (full episode):

... the best software engineering, is not about knowing syntax. And it's not about knowing an algorithm. It's being really good at conceptualizing problems and being able to break them down to building blocks and coming up with clean solutions to them. And that requires experience. It's like doing weights with your mind. ... Like if you went to the gym and just picked up really light weights, you're not growing.

So keep getting those quality reps in :)

This really resonates with me. It's what I want to remember every time I produce software.

That 'gym' is also what my coaching is: weights heavy enough to grow, with someone spotting you, seeking deeper understanding of what you produce.

What about you? What are you working on, and how are you balancing AI in your own work? Hit reply and let me know.

If you know developers who'd benefit from this, please forward it or have them sign up here. 🙏

Have a great rest of the month!

— Bob