This Statement Is False

I've been tuning and refining ui-engine . Man, design choices early on dramatically affect the quality, capabilities, and potential responsiveness of a platform, especially if it has a UI. I've been using a lot of UI experience I've acquired since the 80s and tuning this platform is making me pull out some pretty weird heuristics, like "use a debounce," except in certain situations where that actually interferes with responsiveness. And, yep, I just scrutinized what Claude did and it's starting the debounce timer on the first send after processing a batch, so when processing a batch takes a lot of time, debounce will actually make responsiveness worse by adding yet more of a wait on top of that. Bad decision. My friend says Claude's a lazy coder. Claude does the easy thing if you just tell it, "build X". That's pretty much at every level throughout the system. Even a good design ends up with Claude cutting corners when it writes code becaus...

Frictionless: Claude Code-connected apps What if Claude Code could use apps with you collaboratively? Like, you vibe-code or spec-code or just download an app and as you use it, Claude Code can interact with it too and even alter the app as it runs, without losing information and without needing a restart? Make Claude Code part of your apps... This is Frictionless. No difference between development and deployment and Claude can interact with it while it runs. Build Frictionless apps or download them.  Make dashboards for your Claude Code tasks: track progress, use levers and dials to drive from a UI Make prototypes: prototype production apps in a highly productive environment. Once it works, tell Claude to spec out a production app (hint, consider using [mini-spec](https://github.com/zot/mini-spec)). Improve your Claude Code life and your life beyond Claude Code with personalized expense apps, menu planning, or whatever other non-code, non-work things you do with Claude Don't ju...

Three weeks ago I released mini-spec: a ~93-line skill for spec-driven development. The idea was simple—add a design layer between specs and code so you can catch AI hallucinations before they become phantom features. It worked. But there was a problem: nothing enforced the workflow . Claude could skip the requirements phase. It could forget to link requirements to design artifacts. It could mark things implemented that weren’t. The traceability was only as good as the AI’s attention span. GitHub: https://github.com/zot/mini-spec It’s still the same 3-level process but now the enforcement is way better: Level 1: Specs What you want (human-written) Level 2: Design What the AI understood (requirements, CRC cards, sequences) Level 3: Code What got built The design level makes the AI’s interpretation explicit and reviewable before expensive code generation. Reviewing design documents is far cheaper than reviewing code. What’s new in 2.0 The minispec CLI tool – ...

mini-spec Spec-driven development for Claude in ~93 lines AI hallucinates features you didn't ask for. Sometimes they're great, so good you rely on them. Then you regenerate and they vanish. Mini-spec fixes this. GitHub: https://github.com/zot/mini-spec The three-level approach specs/ What you asked for (human-written) ↓ design/ What the AI understood (reviewable) ↓ src/ What got built (traceable) The middle layer is key . It shows how Claude interprets your specs: what you left out, where the ambiguities are, what you over-specified. Design docs are small and readable compared to code, so you can verify correctness before a single line is written. How it tracks drift design.md serves as the project's status memory. Each design file lists implementation files with checkboxes. When Claude changes code, it unchecks affected artifacts so it knows: A design review is needed Exactly what to look at There's also a "Gaps...

Use claude-crc, Don’t Lose Features to ‘Generous’ Inference 3-Level Spec-Driven Development For Claude The Problem With 2-Level Spec-Driven Development 2-level spec driven development suffers from the same problem as vibe coding – it just takes longer. Which means it bites you after you done a lot more work. I did some hand-rolled, 2-level spec-driven development for an app I’ve been building. By 2-level, I mean you have a collection of spec documents and tell Claude to generate code from it. When you change one set, you tell Claude to check your changes and update the other. It works pretty well as a light-weight alternative to vibe coding. But it’s not a tiny app and I after a while I ran into problems. Claude “generously” inferred things from my specs that weren’t actually in there. I wasn’t as diligent as I should have been with reviewing the generated code – because AI, I suppose. It generates so much code so fast that eventually it becomes easier just to have it auto-approve ...

I just dropped a new repository on GitHub about this -- just wanted to put a pointer here.