I’ve been having a lot of conversations with senior developers and engineers over the past year or so. Good conversations. The kind where people are actually trying to work something out.
The question underneath most of them is the same. Should I become an architect? And under that, a harder one. What does that actually mean in 2026?
Those two questions are showing up together for a reason.
AI code generation tools are changing what software development looks like economically. Not in a theoretical future sense. Right now. If a team knows exactly what needs to be built, the technology is chosen, and the requirements are clear enough, a significant fraction of the implementation work moves to tooling. That fraction is going to keep growing.
The work that doesn’t move to tooling is the work that precedes the specification.
Someone has to understand what the system actually needs to do. Not what the first requirements document says. What the business genuinely needs, what the stakeholders actually want when you get past their initial framing, what the organizational context makes feasible, and what the structural decisions will cost over the next five years. That work requires sitting with real people who have incomplete information and competing interests and extracting enough coherent understanding to make design decisions from.
If you are considering becoming an architect or learning more architectural skills, the Iasa BTABoK is the only open-source practitioner-led body of knowledge in architecture. In addition we also hold Core Architecture courses (one is starting tomorrow) to develop the skills you will need to understand intent, structure, form and stakeholders. https://education.iasaglobal.org/homeThat’s architectural work. It’s always been architectural work. What’s changed is that the work around it is getting absorbed by tooling, which makes the work itself more visible.
The BTABoK describes design as the deliberate act of shaping solutions to fit context, constraints, and objectives. Deliberate. Constraints are not self-evident. Objectives shift. Context has to be developed through engagement over time. None of that is automatable because none of it exists in a form the AI can read before the architect has done the work of extracting it.
Here’s what I think is actually drawing technical people toward architecture right now. The best engineers already think this way to some degree. They’ve always been the ones asking why before asking how. They’ve been the ones who couldn’t leave a design decision alone when it felt structurally wrong even if it passed the tests. They’ve been the ones who got frustrated watching technical debt accumulate because the organization kept choosing speed over integrity in ways that made perfect local sense and terrible system sense.
Architecture is that instinct applied at scale and made into a professional practice.
The BTABoK’s concept of whole system design captures the scope of it. An architect takes a systems-based approach to understanding scope, impact, opportunities, and risks across the business model, the operational environment, the technology landscape, and the financial and regulatory context at the same time. That requires more technical depth in some ways than feature-scoped development work does, because the structural properties of a distributed system built by multiple teams over a decade are genuinely harder to reason about than any single component of it.
At the same time, the profession is requiring more commercial literacy than it ever has. The BTABoK Business Strategy competency describes architects as technology strategists. The meaning is specific. Architects are expected to be in the room where strategy is shaped, providing insight on which digital choices make which strategic positions possible. That requires understanding value, investment decisions, stakeholder priorities, and organizational constraints in business terms, not technical ones.
This convergence isn’t recent. Organizational systems and technology systems have been merging structurally for years. A hospital’s compliance posture depends partly on its data architecture. A retailer’s competitive position depends partly on its personalization infrastructure. These aren’t technology details supporting a business. They are the business, or close enough that drawing a line between them is mostly organizational silliness.
What AI is doing is removing the parts of software work that could sit comfortably between business intent and technical execution without requiring anyone to bridge them properly. When code generation was slow and expensive, teams could afford to have the architect’s work done informally, by the senior developer who happened to think at that level, without any formal professional practice around it. The economics of AI tooling are changing what it costs.
The engineers reconsidering their career path are thinking correctly. A role that requires structural reasoning at system scale, real stakeholder engagement, and the ability to connect design decisions to business outcomes is not going to be absorbed by tooling in any near-term timeframe. The BTABoK has been describing that role for twenty years. The market is arriving at the same conclusion from a different direction.
The huge part of the conversation, and the part a lot of people want to skip, is that becoming an effective architect requires building professional competencies that most senior engineers have never needed. The BTABoK identifies around 42 of them. Most engineers have deep technical competencies and almost no depth in business valuation, stakeholder engagement, or value communication. Those don’t come automatically from coding experience. They have to be built deliberately.
The transition can take years. The people doing it well are the ones who treat it as a second professional education, not a lateral move.
It’s worth it. But it’s worth being clear about what it actually is.