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.
Handing everyone an LLM subscription gives them a model. A shared, self-hosted agent gives them a configured environment with company context, connected tools, and clear boundaries. Why a company should own that layer rather than rent it, and how to start small.
Coding agents made implementation cheap, but validation never got cheaper. That shift moves the bottleneck from writing code to deciding what is worth building, and the response is more autonomy and faster iteration, not more detailed upfront plans.
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.
An autonomous email agent hit a missing script, spiralled through 25 pointless shell calls, then fabricated email content including a prompt injection, and acted on it. The fix is not more warnings. It is structural validation before the model ever sees the data.
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.
AI is now a reader of your documentation. When context lives outside the repository, gaps appear and assumptions creep in. Moving documentation closer to the code makes the system easier to reason about, for people and for machines.
Using Claude Code as the orchestrator and Codex as the engine gives you the best of both tools: Claude's UI, Codex's depth, and minimal Claude token spend. The economics only work when the task is big enough to justify two layers.
The bottleneck in software engineering has shifted from typing to understanding. As AI handles implementation, engineers who thrive will be those who recognise patterns, curate guardrails, and connect technical decisions to business outcomes.
A head-to-head of pencil.dev vs Claude Design on the same markdown input. Claude Design produced the more polished deck and handled speaker notes; pencil.dev still wins for iterative UI work where direct manipulation matters.
AI is making the knowledge side of consulting cheaper by the day. Teams still avoid the legacy system. The gap is not expertise. It is the structural courage to act on what everyone already knows.
Five types of documentation, five different AI leverage stories. The question isn’t whether to involve AI in your docs; it’s where each type belongs and how much maintenance you can hand off.
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.
