Geoffrey Litt

Just had a weird experience: I jammed with Claude on a spec doc for a prototype (including mockups) -- and then I realized that the spec itself was sufficient to share with my team 🤔 In fact, the spec is better in some ways because it encodes a lot of written design intent!

I remember having my mind blown 3 years ago the first time I made an LLM agent that self-corrected based on a natural language error message. Wild that now we take this completely for granted today!

Yeah... I think the closer AI gets to the creative core of what I do the more care/reflection is needed (eg: AI coding is great but need to be very mindful of process) whereas automating toil / meta-work is soo clearly a win (what is toil vs creative can itself be tricky...)

We need a shorthand way of saying: "An AI did the work, but I vouch for the result" Saying "I did it" feels slightly sketchy, but saying "Claude did it" feels like avoiding responsibility

📞 @mschoening and I sometimes have meandering calls about malleable software and AI. This morning we tried recording one! We talked about cognitive debt, why CLIs are having their moment, what comes after files, and reverse-engineering smart homes... 06:55 - How software promotes agency 19:21 - Composable tools 25:00 - Smart home lighting hacks w/ Claude 33:20 - The subtle magic of CLIs 39:35 - Maintenance costs for personal software 43:19 - Avoiding cognitive debt with AI-generated explanations

"AI code review" should be about teaching people how the code works, not just verifying that it's correct We can now generate essays, diagrams, and explorable explanations on demand!! Why are we still reading raw code diffs as the primary UI?

Pro tip: AI code review can be an essay, not a diff! Here's an example I showed @danshipper yesterday: a whole doc explaining a *single line code change*. Starts with background info and intuition, ends with a quiz to check my understanding. https://youtube.com/live/5YBjll9XJlw?si=……

One of my favorite patterns for coding with AI... Software Construction Kits!

Prototyping UIs has always been a good fit for vibe coding, because code quality matters less than when shipping to prod. But with the latest models, things have gotten kinda ridiculous… Opus 4.6 Fast can ask me 50 interview questions about a spec in rapid succession. That process reaches such clarity that it can then one-shot a big feature roughly aligned with the vision in my head, at an adequate quality level to feel out the concept and share the idea. Further iterations happen in seconds. Sometimes the integration tests for thousands of LOC pass on the first try which makes me chuckle—that’s not human level performance! In the past few days I’ve made two prototypes in a large codebase at work. Each one took a few hours from the initial seed of the idea to working demo, in total flow the entire time. I predict they would have taken days without AI (partially due to my unfamiliarity with the large codebase). In fact, without AI I would have chosen a different medium at this early stage. With modern tools, I find prototyping in prod code is often the fastest way for me to feel something out. Surprisingly the upfront interview is one of the most valuable parts — it feels amazing to have design decisions and judgment pulled out of me, without needing to stumble into the questions as I build; it feels like having a super sharp dev at the project kickoff. The faster model also promotes single-tasking focus which I love. For creative prototyping work (where figuring out what to build is the goal), I’m not a big fan of slow models and parallel multitasking; flow matters. Overall, production engineering has a ways to go with LLMs, but it feels like this problem of “UI prototyping assistance” is close to solved. The main bottleneck is my own decision making and judgment. While my main feeling is one of tremendous excitement and relief that I can validate the ideas in my head so quickly now, I do always worry a bit about the unintended consequences of such dramatic process change. Prototyping is a delicate art of working with a material and having reactions to it. There are no shortcuts; spending time is necessary to have good ideas. So I’m trying to keep an eye on that: what are the moments in my personal prototyping process that matter and must be preserved, and what are the parts that can be fast-forwarded? Tentatively things feel OK to me—using the draft UI and reacting to it is where the magic happens, I think, and the faster I can iterate on that UI the faster I can build intuition, without getting stuck in the mud of broken code. But it’s hard to know for sure, and as things speed up further I expect I may need to add more speed bumps to the process to ensure the same level of depth.

Is software dead now? A 4-part blog series: 1/ Malleable software in the age of LLMs (2023). Why GUIs still matter when we have ChatGPT, and how spreadsheets illuminate the path forward: geoffreylitt.com Malleable software in the age of LLMs All computer users may soon have the ability to author small bits of code. What structural changes does this imply for the production and distribution of software?

A workflow I'm enjoying for managing coding agents on a kanban board: When an agent needs your input, it turns the task red to alert you that it's blocked! And then you can respond right there on the card to unblock it