Claude Does Not Write My Angular Architecture

I have read a lot about AI and coding lately, and almost none of it matches what my week actually feels like. The writing falls into one of two camps. Either the machine is about to replace every engineer by Friday, or it is a toy that produces garbage the moment a real codebase touches it. Neither is what the work looks like from where I sit.

I work in a large Angular Nx monorepo. Microfrontends, a shared design system, the kind of project where a single careless change can ripple through twenty libraries. I have been using Claude as a daily part of that work for a while now. It has not replaced me, and it has not slowed me down. It has done something more specific, and more useful, than either of those stories suggests.

Here is the rule that everything else follows from: Claude does not write my architecture. It removes the friction around it.

The architecture stays mine

When I decide how a feature should be structured, which library it belongs in, where the boundary sits between a smart component and a presentational one, how state should flow, that thinking is the job. That is what I am paid for, and that is what I actually enjoy. I do not hand it off.

What I learned quickly is that an AI assistant is at its worst when you ask it to make those decisions for you, and at its best when you have already made them and need to move. The senior part of the work is knowing the difference. If I am unsure about a design, asking the model to decide does not resolve the uncertainty. It just hides it behind confident prose. So I resolve it first, then bring the model in. For example, I decide whether state belongs near the feature, in a shared store, or behind a small facade before I ask it to generate anything around that decision.

That sounds like a limitation. In practice it is the opposite. Once the shape of the work is clear in my head, an enormous amount of what remains is friction: boilerplate, translation between formats, the second draft of something I already wrote once, the mechanical parts of review. That is the territory where I lean on Claude hard.

Where it actually earns its place

This is where it shows up in my week.

Pull request descriptions. Our team has a format. Context, what changed, why, how it was tested, screenshots where relevant. Writing that well takes real attention, and at the end of a long change it is the moment I have the least energy for it. I give Claude the diff and the ticket, it produces a first draft in our format, and I edit. The draft is never the final word, but it gets me past the blank page, and the structure is consistent every time.

Jira comments and status updates. Same principle. I know what I want to say. Turning a pile of half-thoughts into a clear, readable update for people who are not in the code is a small tax I pay several times a day. Handing the model the raw context and getting back a clean version I can edit saves more time than it sounds like, because the cost was never the typing. It was the context switch.

Reviewing AI-generated code. This one is less obvious. A lot of code now arrives already written by some assistant, mine or a teammate's. It has a recognizable failure mode: it over-engineers, it invents imports that point at nothing, it conjures an Nx executor option that sounds exactly like something that should exist, it drifts from the surrounding style, it solves a more general problem than the one in front of it. I use Claude specifically to hunt for those patterns before a human reviewer has to. It is good at catching its own kind of mistake.

Spikes and investigation. When I need to understand an unfamiliar corner of the codebase, a state management pattern I have not touched in months, or weigh two approaches before committing, talking it through with the model is faster than working it out alone. Not because it knows the answer. Because explaining the problem clearly enough to get a useful response forces me to think clearly, and the back and forth surfaces options I would have reached more slowly on my own.

Notice what is common to all of these. The decision is already mine. The model handles the part between deciding and shipping.

The part nobody puts in the demo

The demos skip the part where the model is wrong. You ask, it produces, you ship. Real work is not like that, and pretending otherwise is how people get burned.

The model is confidently wrong on a regular basis. It will reference framework behavior from an older version as if nothing has changed, or invent a configuration option that looks perfectly plausible until you check the docs. If I pasted that in without reading it, I would be debugging a problem the assistant created, which is slower than having written the thing myself. The only reason the workflow is a net gain is that I read everything before it goes anywhere near a branch.

This is also why I do not think it threatens the senior role the way people assume. The model is most dangerous in exactly the spots where judgment matters most, because that is where being wrong is expensive and where its confidence is least earned. You need to already know enough to catch it. The better I get at the architecture, the more value I get out of the tool, not less. It scales with the engineer, not against them.

How I would summarize it to another engineer

If a colleague asked me whether they should work this way, I would say: keep the thinking, delegate the friction. Decide the shape of the work yourself. Use the model for the mechanical distance between that decision and a shipped change, the descriptions, the translations, the first drafts, the second pair of eyes. Read every line it gives you as if a stranger wrote it, because in a sense one did.

The fear is that the tool makes the engineer smaller. My experience is the reverse. It clears away the parts of the day that were never the point, and leaves more room for the parts that were. The architecture is still mine. I just spend less time on everything that is not it.

I write about frontend architecture, AI-assisted engineering, and the kind of engineering habits that only become visible after enough real projects. If that is your kind of thing, the newsletter is where it lands first.