Lorin Hochstein writes about generative AI in the context of incident reports, but the points are more broadly applicable. I have seen a big wave of “don’t let AI do your thinking for you” posts recently¹, so I think lots of folks are pulling back a little bit on the “just let AI do everything” rhetoric (a good thing in my opinion!). As to why Lorin isn’t a fan:

In my view, LLM-generated incident write-ups are more dangerous than using LLM for coding or for AI SRE style tasks. For coding tasks, there’s always a testing step to check that the code exhibits the desired behavior, even if nobody looks at the code itself for meaningful details. For AI SRE tasks, either the LLM output helps you resolve the incident, or it doesn’t. In both cases, Nature is the ultimate arbiter of the LLM output. But incident write-ups aren’t like that. The consequences of a poor report aren’t immediately apparent the way incorrect code or an incorrect operational diagnosis are in the moment. Instead, we get incident reports that have the superficially correct form, but are actually incorrect, with no obvious test for correctness.

Footnotes

1. For examples see No One Else Can Speak the Words on Your Lips, Guidelines for Respectful Use of AI, Writing Is Fundamental to How We Think, and I know you didn’t write this. ↩

In a post about slowing down our agent use deliberately to increase quality and understanding Vicki links to Nolan Lawson’s Using AI to write better code more slowly:

If you’re the kind of developer who uses agents to write multi-hundred-line PRs that you barely understand yourself, I’d invite you to slow down a bit and try this other, slower style of “vibe coding.” Ask an agent how your PR works and how it might fail. Have it write Markdown docs with Mermaid charts if necessary. Use Matt Pocock’s /grill-me skill until you understand the entire PR front-to-back.

You might not be more “productive” in terms of raw lines of code. You might burn a ton of tokens just to find out that your entire plan was wrongheaded from the start. But I find this style of coding to be a more super-powered version of the kind of programming I was already trying to do before LLMs: careful, methodical, quality-obsessed, focused on making things better for the next coder.

So take a deep breath, slow down, try this technique, and see if you don’t enjoy writing better code more slowly.

Vicki concludes:

All of these negate the supposed speed up effects of LLM-generated code in the short-term by adding friction, and yet, in the longer term, make me better at using the tool, because they solidify my own foundation instead of the foundation models’.

We should be more tired than the model.

We should be more tired than the model. When I saw the post in my feed I thought I misread the title (or maybe it was a typo). But after reading it I realized that’s already where I’ve been heading organically myself. I went through my “look how fast I can go weeeeee!” era pretty quickly. While it was fun (check out all these side projects!) it was not just exhausting, I also found myself understanding less and less of what I was doing (which sucks all the fun out of the work anyway).

So I’ve been slowing down as well. Reading and editing even more than before. Challenging the agent for longer. Taking the time to close loops to update skills/context documents before moving on to the next thing. Never skipping the “let’s write a design doc and implementation plan together” step.

I do think I am more tired than the model these days. But I also understand and learn more, which not only improves the quality of the output now, but also makes it better tomorrow. I think the speed trade-off is worth it.

This post is a fascinating look at how botnets actually work. I don’t want to spoil the takeaways so I’ll just quote this (but you should read the whole thing):

Your server isn’t special. Nobody is “targeting” it. Every IP address on the internet is being continuously probed by automated systems. Within seconds of exposing port 22, you will receive login attempts. This isn’t a question of “if” but “when” — and the answer to “when” is “immediately.”

This post on org design really resonated.

Most companies today are using AI the way you’d use a faster horse — to make the existing structure run a little better. The companies that pull ahead will be the ones willing to ask a harder question: what would we build if we were designing this organization from scratch, today, knowing what AI can do?

We have to seriously rethink the SDLC, design it from scratch in the context of how our own organizations work. It’s not about a global “right” process any more. The question now becomes “How can the humans in our team, at our company, at this point in time, work best together to serve our customers?”

Oh, this is very good. On the classic take that the core characteristic of outstanding engineers is “laziness”:

The problem is that LLMs inherently lack the virtue of laziness. Work costs nothing to an LLM. LLMs do not feel a need to optimize for their own (or anyone’s) future time, and will happily dump more and more onto a layercake of garbage. Left unchecked, LLMs will make systems larger, not better — appealing to perverse vanity metrics, perhaps, but at the cost of everything that matters. As such, LLMs highlight how essential our human laziness is: our finite time forces us to develop crisp abstractions in part because we don’t want to waste our (human!) time on the consequences of clunky ones.

The best engineering is always borne of constraints, and the constraint of our time places limits on the cognitive load of the system that we’re willing to accept. This is what drives us to make the system simpler, despite its essential complexity.

This is exactly why I practice Fear-Driven Development, and why everything I do in code includes multiple versions of asking Claude Code “do we need this?” and “is this adding bloat?”

Amol Avasare, Anthropic’s Head of Growth, said on Lenny’s Podcast that maybe PM jobs are not going to shrink as much as we may have thought…

Rather than immediately replacing PMs, AI is currently increasing engineering leverage the fastest, which creates new pressure on PMs and designers. In larger organizations, that may actually increase the value of PMs who can guide priorities, manage alignment, and sharpen decision-making—especially as engineers take on more “mini-PM” responsibilities.

Lalit Maganti writes about building a SQLite parser with AI — a project he’d been putting off for eight years, finished in three months. His comparison of AI coding to slot machines is uncomfortably familiar:

I found myself up late at night wanting to do “just one more prompt,” constantly trying AI just to see what would happen even when I knew it probably wouldn’t work. The sunk cost fallacy kicked in too: I’d keep at it even in tasks it was clearly ill-suited for, telling myself “maybe if I phrase it differently this time.”

Also, I agree that this is still true today, but I’m not convinced it will remain true beyond 2026:

AI is an incredible force multiplier for implementation, but it’s a dangerous substitute for design.

Simon Willison has a practical guide on manual testing with coding agents. Two tips I’ve already started using:

It’s still quick for an agent to write out a demo file and then compile and run it. I sometimes encourage it to use /tmp purely to avoid those files being accidentally committed to the repository later on.

And:

If an agent finds something that doesn’t work through their manual testing, I like to tell them to fix it with red/green TDD. This ensures the new case ends up covered by the permanent automated tests.

As usual, Simon Willison hits the nail on the head here:

If adopting coding agents demonstrably reduces the quality of the code and features you are producing, you should address that problem directly: figure out which aspects of your process are hurting the quality of your output and fix them. Shipping worse code with agents is a choice. We can choose to ship code that is better instead.

Also see Mitchell Hashimoto’s idea of “harness engineering”:

It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.