Claude in the enterprise, from architecture to production.

Why Claude, and why now#

My attachment to Claude is not about magic. It is about range. The same assistant that debates an architecture trade-off in the morning reviews a Java migration before lunch, drafts a runbook in the afternoon and reads a stack trace at the end of the day. Work that used to wait for four different specialists to find a spare hour now starts with one good question.

I also like its temperament. Claude reads before it writes. It asks what the constraint is instead of assuming there is none. And it accepts being told it is wrong, which is more than can be said for some tools and for some engineers, myself included on a bad day.

Architecture: a sparring partner that reads everything#

Enterprise architecture is mostly archaeology. Before you draw the target picture, you have to understand years of accumulated business logic, half-documented decisions and dependencies nobody remembers creating. Claude is the first tool I have used that can actually read all of it, the code and the documents, and hold it in one conversation.

The way we use it is deliberately adversarial: propose three options, then attack each one. Where does it break under load? What does it cost to operate? What does it assume about the legacy system that is not true? A model that argues fluently for the wrong option is dangerous, so the decision always stays with us. What Claude removes is the blank page and the blind spots, not the responsibility.

Code: legacy first, greenfield second#

The public conversation about AI coding is obsessed with greenfield projects. Most enterprise value sits in the opposite place: established applications that must keep running while they are modernized. That is where Claude has surprised me the most.

Upgrading a framework across an application, untangling a class that three generations of developers extended, writing the tests a module never had before touching it: this is patient, careful work, and it is exactly what a tireless assistant is good at. The engineer sets the direction and the invariants; Claude does the long march through the files; the diff gets reviewed like any other diff.

Review, tests and delivery#

A second pair of eyes that never gets tired changes the economics of quality. Our habit is simple: Claude reviews first, humans review with the findings in hand. The human reviewer stops burning attention on the mechanical layer, naming, obvious bugs, missed edge cases, and spends it on what actually requires them: does this change do the right thing for the product?

• Ask for a review before opening the pull request, not after
• Have the tests written or challenged by the assistant, then judged by the author
• Let it read the pipeline: flaky jobs and slow stages are patterns, and it is good at patterns

Production: incidents and runbooks#

Production is where the affection became serious. During an incident, the scarcest resource is a calm reader. Claude reads the stack trace, the recent changes and the logs without panic, and proposes hypotheses in order of likelihood. Afterwards, it drafts the postmortem while the details are still warm, and writes the runbook that everyone agreed should exist and nobody had time to write.

$ claude "read this stack trace and the last three
deploys. rank the likely causes."

Guardrails: what a regulated environment demands#

We build platforms for financial institutions and public-sector organizations. Confidentiality is not a preference here, it is the product. Using Claude in that context is entirely possible, on the condition that the rules exist before the enthusiasm does.

• Confidential and client data stay out of prompts, without exception
• One approved tool and account setup, so there is no shadow AI to discover later
• The same review bar for every change, whether it was typed or generated
• A human owns everything that ships, with their name on it

Adoption is a management job#

Tools do not adopt themselves. What worked for us was unspectacular: start with the engineers who are curious, let them show real sessions to the others, and be honest about the failures as well as the wins. The moment a skeptic watches a colleague untangle in an afternoon something that would have taken a week, the conversation changes on its own.

My conclusion after living with Claude across the whole lifecycle is simple. The point is not that it writes code. The point is that every stage of the lifecycle gains a second brain, and the team decides, deliberately, where that brain is welcome. That decision is engineering leadership now.