A Philosophy of Software Design — does strategic vs. tactical still hold with AI coding tools?

41 views
Skip to first unread message

Karmesh Gupta

unread,
Jul 8, 2026, 11:13:43 AM (13 days ago) Jul 8
to ous...@cs.stanford.edu, software-d...@googlegroups.com
Dear Professor Ousterhout,

I'm a software engineer based in India. I recently read A Philosophy of Software Design, and chapter 3's distinction between strategic and tactical programming is the idea from the book I keep coming back to.

I'm writing because that idea keeps colliding with something I'm experiencing firsthand: using Claude Code and similar AI tools day to day. The results are inconsistent — some of what it produces is genuinely well-structured, some of it isn't — and I've noticed a real shift in how I relate to my own codebase. I used to know it line by line; now large parts of it are things I've never actually read. I've watched other developers do the same, often without seeming to notice how much they've lost track of. My honest impression, watching it work, is that Claude Code itself defaults to a tactical style: it optimizes for producing something that runs now, not something built to be lived with later.

This has left me with a question I'd be very grateful to hear your thoughts on, if you ever have a spare moment. Your case for strategic programming rests, if I understand it right, on the idea that investing in good design pays off because someone — a human — has to live with the consequences later. I'm curious whether that argument holds in the same way if it's increasingly an AI doing that living-with, rather than a person. A few possibilities I keep turning over, though I'm sure you'll have a much better sense of it than I do:

1. It could matter even more — an AI reworking code has no tacit memory of why things were done a certain way, so hidden complexity might cost it more, not less.
2. It could matter less — if an AI can absorb messy structure cheaply at any scale, some of the human-centered arguments for deep modules and careful naming may weaken.
3. Or the tradeoff doesn't disappear so much as move — design now matters for a different audience: the AI doing the work, and the human trying to review or trust it.

I'd value your take on this, even a few lines. Thank you again for writing the book — it's one I keep returning to.

Best regards,
Karmesh Gupta

John Ousterhout

unread,
Jul 13, 2026, 3:13:51 PM (8 days ago) Jul 13
to Karmesh Gupta, software-d...@googlegroups.com
Hi Karmesh,

I don't yet have enough experience/data to speak with much conviction about how AI tools will affect the importance of software design (and things seem to be in a state of flux), but I have heard a number of people report that AI tools can produce shallow and complex code. I have also heard claims that AI tools are more effective at managing code that is well-structured than code that isn't. You might find this talk by Matt Pocock interesting: he argues that software design matters more than ever when using AI tools, and he even references APOSD:


But these are anecdotes, rather than conclusive evidence, and even if AI tools produce sloppy code today, who knows what they'll be doing in six months or a year?

One thing that seems likely to me is that design will be the hardest aspect of coding for AI tools to displace; if the tools do end up doing well at every aspect of coding, design will probably be the last thing they take over.

-John-

Reply all
Reply to author
Forward
0 new messages