Architecture

It is not producing diagrams away from delivery. An architect whose output ends at a document and a few slides has no feedback loop, and that is precisely how architectures go wrong. It is also not a governance role that approves other people's work from a distance, and it is not permission to stop writing code: most effective architects still build, just less and more deliberately, prototypes, reference implementations, the hard integration nobody else wants. And it does not come with authority. You almost never get to mandate, so the actual work is convincing teams who could ignore you.

• —Choosing and documenting system boundaries, integration patterns and data ownership, together with the reasoning behind them.
• —Making trade-offs explicit: cost, performance, complexity, operability, time to market, and what you are deliberately not optimising for.
• —Reviewing significant designs from teams early enough that the feedback is still cheap.
• —Prototyping the riskiest part first, so decisions rest on evidence rather than confidence.
• —Owning cross-cutting concerns that sit on nobody's roadmap: authentication, observability, migration paths, data flows, vendor dependency.
• —Translating in both directions between engineering reality and commercial expectations.

A strong senior engineer is accountable for a system they can hold in their head and see working within weeks. As an architect the consequences of your decisions can take a year or more to appear, often on teams you do not work with, and sometimes after you have moved on. You trade the satisfaction of building for the discipline of being right about constraints, and much of your day becomes reading, asking questions and writing rather than typing code.

• —That it is a diagram job, and that the artefact matters more than the decision behind it.
• —That architects stop coding. The good ones write less code in more important places.
• —That the role comes with authority to decide for teams; in practice it comes with the obligation to persuade them.
• —That more abstraction means more architecture. Removing options is usually worth more than adding them.

Agentic coding makes plausible code cheap to produce, which raises the value of the things a model cannot supply: clear boundaries, explicit contracts, tests that mean something, and written intent. Codebases with well-defined seams and decent documentation are exactly the codebases models work well in, so architectural clarity has turned from a long-term nicety into an input to team throughput. The review and verification load grows, and the failure mode shifts from we could not build it to we built four slightly different versions of it very quickly. In practice an architect now also owns questions like where models are allowed in the system, what context they are given, and how their output is verified.