About
ai / in practice
"Vibe coding. Job done in five minutes." You've shipped production systems. You know that's not how this works.
You already know what delivery actually looks like
You've spent years learning that writing code is a small part of shipping software. The real work is everything around it: understanding what the user actually needs, researching libraries and tradeoffs, building the core, getting it to compile clean, writing tests that mean something, debugging, evaluating, deciding what comes next, iterating. Then documentation, early user observation, another round of iteration — and finally, production.
AI compresses some of that. It doesn't eliminate any of it.
Gathering information, organizing a design, generating code and unit tests — these genuinely get faster. But debugging code you didn't write is harder than debugging code you did, because you normally fix dozens of small issues as you go. When the code appears fully-formed, you've skipped that process. The mental model has to be rebuilt from the output, not grown from the work.
The shift nobody prepared you for
Junior devs worry about whether AI will replace them. That's the wrong question for you. The real challenge is the identity shift: you're no longer primarily an author of code — you're a director, reviewer, and owner of code that comes from a system that doesn't understand your codebase, your users, or the tradeoffs you've already made.
That's a different skill set. It's also a real leverage point, if you do it right. Most of the content about AI tools still assumes you're trying to get started. This site assumes you're trying to get good — and that those are two completely different problems.
What we cover
Every topic here addresses a specific friction point that shows up in production, not demos. The writing assumes you've shipped something with AI assistance and felt the gap between the promise and the reality.
Workflow — Choosing the right tool for the task, structuring long-running work, building reusable slash commands, and navigating the overwhelming pace of new tooling without burning cycles on evaluations that don't pay off.
Cost & Reliability — Tokens are the unit of everything. Rate limits become a production reliability problem sooner than most teams expect. Context is a finite resource, not a free buffer. Prompts that worked last month sometimes silently degrade as models shift.
Quality & Security — When you didn't write every line, a passing test suite proves less than you think. LLMs pattern-match against training data, not threat models. Certain vulnerability classes appear in AI-generated code with unsettling regularity. Knowing which ones to audit for first changes your review process.
Team & Maintenance — AI adds code fast. Consistency, architecture, and ownership degrade at the same speed when nobody's steering. Attribution and licensing get genuinely murky when the diff comes from a model.
How we approach it
Not as beginners getting started, and not as enthusiasts writing think-pieces. We want to actually understand the tools: how they work, where they break, how to integrate them into workflows that already work, and what discipline is required to maintain that over time.
That means knowing not just what but why. Detailed enough to reason from first principles. Practical enough to apply immediately. One real example, clearly described in actual implementation, gives you a mental road map that no amount of tutorial prose can. That's the format this site aims for.
Editorial policy
No vendor relationships. No affiliate links. No "10 prompts to 10x your productivity." A topic earns its place here when it surfaces in real production work, lacks a decent write-up, and has no clean vendor-provided answer. The goal isn't to cover everything — it's to be genuinely useful on the things that matter.