Development

A month ago I wrote about making Claude Code actually ship software. The workflow has been through at least six revisions since I started, but this latest version has been stable. Now it’s packaged as momentum. What This Actually Is Not another “make AI smarter” attempt. This is a workflow that assumes you know what you’re doing and gives you tools to do it faster. A recent post about building Log Carver at C-speed nailed it: “AI is no longer just a productivity booster. It’s a compiler for ideas. But like any compiler, it needs constraints, tests, and a damn good operator behind the keyboard.” ...

TL;DR LLMs are incredible force multipliers for building software. I’m building multiple projects concurrently with Claude Code. They excel at ideation, planning, and code generation when you do it right. But they struggle with predictable runtime behavior. They’re probabilistic systems at their core - you’ll get different results across runs no matter how much you prompt engineer. The variation isn’t a bug; it’s the architecture. Design for their nature, don’t fight it. They can be embedded in software when you account for variability. Great for chatbots, content generation, analysis work where you want different responses. ...

TL;DR Claude Code is powerful, like really.. but chaotic without some structure. Many people probably use it an ad-hoc fashion and there’s nothing wrong with that. I built a systematic workflow that turns it into a shipping machine. The magic is in the command structure. /plan-iteration → /plan-task → implement → /complete-task → /complete-iteration. Each command has specific responsibilities and quality gates. Evidence-based completion prevents the “is it done?” problem. /complete-iteration requires concrete proof that users can access working software. No more marking things “complete” when they’re just coded. ...

TL;DR Context creation was still ad-hoc even with the three-layer memory system in place. Every new language meant manually crafting another CLAUDE.local.md file and repeating the same research process. The research process was repeatable. Looking at what made my Python context effective, I noticed the same pattern: current tools, common mistakes, workflow problems. The structure was consistent across languages. Prompt template generates research-backed contexts. Feed it “python” or “golang” and get comprehensive development contexts through 12-15 targeted searches of authoritative sources. ...

You ask AI to implement something seemingly straightforward. It builds exactly what you asked for. Then you realize it’s not what you actually needed - wrong UX behavior, missing security considerations, breaks existing functionality. There’s a pattern emerging to address this: let the AI interview you first. TL;DR Assumptions hide in seemingly straightforward requests. Even simple tasks like “add email validation” contain multiple implementation decisions that aren’t obvious until you start building. ...

How I discovered that LLM limitations reveal fundamental truths about software architecture in the AI era The Breaking Point Isn’t What You Think After months of AI-assisted development, I hit a wall that had nothing to do with prompting skills or context limits. The problem was deeper and more fundamental: LLMs lose their minds when applications exceed their cognitive capacity. I wasn’t building monoliths. My applications had proper separation of concerns, clean data models, comprehensive tests, and type safety. The repository pattern, service layers, configuration management - all the architectural best practices were there. But as these well-structured applications grew in complexity, something strange happened. ...

AI-assisted development tools are everywhere - systems that understand code, generate tests, fix bugs, and accelerate delivery. But practitioners are hitting a wall. Despite sophisticated prompts, quality controls, and multi-agent workflows, LLMs consistently cut corners on complex work. The problem isn’t training or prompt engineering - it’s architectural. TL;DR LLMs optimize for different objectives than human developers. The “laziness” comes from training to satisfy human approval patterns rather than correctness. My sophisticated workflows work against this optimization. ...

Over the past ten years, I’ve spent considerable time and energy trying to shorten critical time gaps. The time it takes attackers (the good kind) to find bugs, defenders to mitigate, and responders to act when things go sideways. This has always been about data—getting the right people the right information at the right time. I’ve built systems designed to reduce friction, perform the drudgery that bug hunters do at scale (before AI made this interesting), and tackle attack surface problems before ASM was a thing. In every case, success hinged on that fundamental principle: right people, right data, right time. ...

While building my own JARVIS-like assistant (yes, another one of those), I noticed something: AI output is perfectly readable as text, but throw it at a text-to-speech system and… well, let’s just say it’s not winning any audiobook awards. Here’s what I mean. Take this perfectly clear output from Claude: T h e s e r v e r a t I P 1 3 0 . 3 5 . 2 2 9 . 1 2 7 i s r u n n i n g H T T P / 4 4 3 Read that with your eyes? No problem! Crystal clear. But have your TTS system read it out loud and suddenly your technical briefing sounds like a robot having a stroke. ...