A React island inside a Django page needs three things: a template tag that records rather than renders, one batched call to a render sidecar, and a browser that hydrates only the IDs the server named. Shared state then lives outside React, in a small store or the URL.
You don't need a front-end rewrite to make one screen feel like an app. A small render sidecar lets an existing back-end server render React components, hydrate only the islands that need to be interactive, and leave auth, the ORM, and your templates exactly where they are.
Server actions look like React compiler magic, but underneath they are a name mapped to a function behind one endpoint. You can build the same shape in Django, call it from React or a plain HTML form, and keep validation at the boundary.
Synthetic checks like curl and Lighthouse measure a request your users never make. A HAR file captures the real logged-in flow, and handed to Claude alongside the codebase it turns a wall of JSON into a ranked list of fixes that get implemented in the same conversation.
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.
