top of page

If AI Becomes the Coder, Who Becomes the Architect?

Writer: Sonia von der Lippe
Sonia von der Lippe
Aug 8
3 min read

Updated: Oct 23


I've been thinking about vibe coding differently lately.


AI can be an incredibly fast junior engineer. It can generate code, assemble components, troubleshoot errors, and accelerate development in ways that would have been difficult to imagine just a few years ago.


But if you don't understand the architecture you're building, that speed can become dangerous.


We used to spend millions of dollars deconstructing decades of spaghetti code. With AI-assisted development, we may be able to create the same problem in six months.


We've accelerated the ability to build software. Have we accelerated our ability to understand what we're building?


Speed Doesn't Replace Architecture

Software architecture is more than organizing code into components or selecting technologies. It requires understanding the domain, the relationships between systems, the assumptions embedded in their interfaces, and the consequences of design decisions over time.


AI can produce code that works. That doesn't necessarily mean the resulting system is coherent, maintainable, extensible, or appropriate for its intended purpose.


A component can function correctly in isolation while introducing inconsistencies across the larger architecture. An interface can be technically valid while misrepresenting the meaning of the information being exchanged. A design decision that solves today's problem can create tomorrow's integration challenge.


These are not simply coding problems. They are architectural problems.


And generating code faster doesn't make them disappear.


How Do We Develop the Next Generation of Architects?

This raises a harder question for computer science education and the engineering profession:

How do we develop the architect when AI increasingly becomes the coder?

Traditionally, software architecture was something you grew into. You learned to code. You built systems, maintained them, made mistakes, worked through integration failures, and lived with technical debt. Over time, those experiences helped develop the judgment necessary to understand how systems should fit together. Just as importantly, you developed an understanding of the domain in which those systems operated.


That experience matters. Architecture requires more than familiarity with programming languages, frameworks, and design patterns. It requires understanding why a system exists, what it must accomplish, and how its decisions affect everything around it.

What happens when AI compresses—or removes—much of that learning journey?


If engineers can produce sophisticated applications without understanding the underlying implementation, how will they acquire the experience necessary to evaluate architectural decisions?


And if the traditional progression from developer to architect changes, what replaces it?


AI Changes More Than the Development Process


In our upcoming I/ITSEC 2026 paper, co-authored with Alethea Duhon, PhD, Jim Gump PhD, and Marc Banghart PhD, we examine a related concern: AI doesn't simply add capability to an existing architecture. Its introduction can change the behavior of the architecture itself.


I'm beginning to think the same principle applies to the engineering profession.

AI-assisted development doesn't simply make engineers more productive. It may fundamentally change how software engineers learn, how they work, and how they develop the judgment required to design complex systems.


That has implications for education, professional development, systems engineering, and ultimately the quality of the systems we produce.


We may need to place greater emphasis on architectural reasoning, domain understanding, integration, verification, and the ability to challenge AI-generated solutions rather than simply accept them.


The Question We Need to Answer

I'm not arguing against AI-assisted development. Its potential is enormous.

But productivity cannot be measured solely by how quickly we generate code.

We also need to consider whether we're producing systems that can be understood, maintained, integrated, and evolved.


And we need to consider whether we're developing engineers capable of making those judgments.


If AI changes what it means to build software, we may also need to rethink how we develop the people responsible for architecting it.


Because if AI becomes the coder, we still need someone who understands the system.

And that expertise doesn't develop automatically.


Comments


bottom of page