Analytics only shows the events you remembered to add, never the ones you forgot. Let Claude instrument features as it builds them, then run a skill that audits your tracking against your own docs and live data, flagging what's missing, noisy, or quietly broken.
Integrating a tool with Claude rarely needs an MCP server. A boring script wrapped as a named, version-controlled skill does the job, and the real value shows up when two skills combine: one tool tells you what happened, another tells you why.
Writing code by hand used to be the job. Soon it will be a hobby, like woodworking or growing your own veg. What a company pays for now is judgment: knowing what to build, catching the answer that looks right and isn't, deciding when it's good enough to ship.
A written style guide is a museum piece nobody enforces. An LLM changes that: it reads rules in plain prose and applies them on every pull request, reaching judgment calls no linter could express. The style guide stops being a document and becomes a runtime.
Hand two developers the same tool and you get opposite verdicts. 'Useless' is rarely a fact about the thing. It's a fact about the person holding it. The rare skill was never operating the tool. It's imagining the door a tool opens before the use is obvious.
Pairing with an AI feels like pair programming. It isn't. There's one prior in the room, and it's trained to agree. This post makes the case for mob programming and spec-driven development as the structural fix.
Errors don't just happen; they land somewhere. Validation, generic, idempotent ignore, warning log, or Sentry: each routes failure to a different audience. Get the routing wrong and either engineers go blind to real bugs, or state corrupts silently.
Your codebase degrades the same way shared resources do: not from malice, but from missing governance. Elinor Ostrom proved the commons can survive. Her principles map to software teams with uncomfortable precision.
Every software company claims to be different. The "we don't need X because we have culture" exemption is special pleading. The four phrases that reveal it, and the questions that break them open.
I used to teach people to code. And looking back, I was teaching students to write it by hand while the tools that write it for them were getting better every single month. So what should a coding classroom actually look like now?
Every legacy codebase is a palimpsest: layers of decisions written on top of each other, none fully erased. Geoffrey Dhuyvetters argues that what looks like technical debt is often stratigraphy, and you read it before you rewrite it.
Half of today's AI best practices are coping mechanisms for temporary scarcity, not timeless engineering insights. Geoffrey Dhuyvetters traces the arc from SMS bundles to token limits, and argues the price curve only goes one direction.
When an AI agent gets a requirement wrong, the mistake lives in the test assertions, not the implementation. Domain knowledge catches it, not coding skill.
"Vibe coding" has become shorthand for bad engineering to some people, but does the label hold up? This post unpacks how a playful term coined by Andrej Karpathy became a verdict, and why that's costing teams more than they realise.
LLMs generate code fast, but knowledge debt accumulates quickly. The fix is living documentation, and this post shows how to turn your LLM into the partner that maintains it automatically.
