Software “Architecture” is still needed in an age of AI

Software Architecture and why this is still important in 2026 and beyond.

Understanding the architecture and the "why" of your app especially if vibe coded, is still a valid skill in 2026 because you still need to understand what is the overall direction and general function of your app. If you sloppily throw stuff together, the context will rot and you won't know enough to see/say what broke, why or how to reproduce the issue in a non-production environment.

So, having certain functionalities like logging, metrics, Microservices, Separation of Concerns, DRY, and other principles are still important and significant for your app. These patterns and principles just makes it easier to debug when things go wrong. AI may be able to type code really fast, but it struggles to keep all that context in mind when your app gets to a certain level. SDLC is also important but I will have a video dedicated to that.

Let's dive into some things about architecture that still make sense to know.

Software Architecture

Understanding the architecture of your app will go a long way to being able to drive agents, build your own systems and keep a high level understanding of the app, not just a detailed low-level understanding of the app and also avoid the trap of giving a million instructions that may conflict and result in a pile of poop that causes outages at 02:00A and you scrambling to figure out what went wrong.

I've spent enough mornings and ruined my sleep enough to know that I don't want you experiencing the same toll. So I'm here to help you gain as much wisdom and foresight as possible to keep your app running as smooth as possible.

An example of this could be your dependency tree. Not just the external software and libraries you need, but also the components in your code itself. I've seen AI create 3-10 versions of the same class all with slightly separate fields, keys and either in the same file or in the same directory. This not only creates an entire layer of cruft it has to sift thru, costing you precious tokens and dollars, but it's also mental strain for anyone reviewing the code. It's also excessive compute on the systems running it with the extra compile times and bloat in the software itself.

Some of my best code was written with my backspace key.

I'm not suggesting you delete all the code and throw the baby out with the bathwater. What I am saying is if a single class called CustomerSchema is sufficient, then why do we need ClientSchema, ClientLean, ClientSchema2, OldCustomer, Customer2. People are so scared of deleting something when it's clearly no longer used. AI is even worse at this unless you explicitly tell it to do so. And yes, I have seen people rename a class to "old" to just keep it around instead of relying on the Git history to refer to a past incarnation of a data structure 🤦🏾‍♂️

Language Syntax & Organization

It's still valuable to understand how to organize your code and when to use various components of a language. While the models can type really fast, they often use deprecated techniques and functions due to being trained on outdated examples. They are also only ever trained on software techniques that are the most heavily documented and supported due to their availability on the Internet (ReactJS, I'm looking at you). If you are working in a niche (niche being... literally anything other than ReactJS) software framework or language that isn't one of the top-supported, you are likely going to run into issues with the models until they can get trained up to that level.

Grouping related functionality by folder, placing tightly coupled components into the same file will help organize your code and layer your instructions so you can keep track of what's where. In this way, if you leverage an AGENTS.md file, you can put one at each layer and indicate what level of detail the model should have on the code contained at this level. So top-level stuff can remain high-level and the deeper the folder structure, the deeper the details.

This adds onto something else I came across that was explained really well when it comes to another software fundamental. That's modular implementation with a clean interface. Basically you create basic functions that provide a toolbox of functionality with an easy-to-use interface. You build up by leveraging the toolbox into more modular designs that leverage the low-level operations and continue to build your way up from there.

I typically use /lib as the root code folder. Many projects use /src as the root folder. You can use whatever you want, just be consistent and predictable.

Example folder structure:

lib
└── mkzforge
    ├── __init__.py
    ├── __main__.py
    ├── _version.py
    ├── cli
    │   ├── __init__.py
    │   ├── build.py
    │   ├── new.py
    │   ├── normalize.py
    │   ├── publish.py
    │   └── web.py
    ├── const.py
    ├── filter_complex.py
    ├── genimg.py
    ├── grive.py
    ├── i18n.py
    ├── metadata.py
    ├── notify.py
    ├── schema.json
    ├── subtitles.py
    ├── types.py
    ├── utils.py
    ├── videos.py
    └── webserv.py

This is the directory structure into my video editing project MKZ Forge as a practical example. Note how things related to the command line are in the /lib/mkzforge/cli/ folder. Other modules are top-level so they are in the root of the library.

Design Patters

There are a plethora of software design patterns! Understanding things like singletons, factories, adapters, registries, (H)MVC, difference between models and modules, and how all these play a role in your app will help with structure and scaffolding.

You have to be critical and careful of using design patterns. While it's great to learn about them, I've been known to over engineer my software because I was too happy and crazy about using a new technique to get the hang of it. I would later discover it's not appropriate to use that specific pattern because it was just the wrong design choice.

It's also important to note the distinction between visual design or graphic design and architecture design or code design. These are different uses of the overloaded word "design" that I want to point out here. Graphic design and visual representation are a separate topic for another post.

Systems/Infrastructure Architecture

Systems architecture is like building a city or a factory. It flows like the blood in your veins. It's often messy and unorganized, but somehow still gets the job done. It's build organically and no two systems are ever built the same.

You gain insights and lessons from each implementation. Each iteration incorporates more of those lessons. As you progress thru your career, you'll encounter situations you've never seen before, try something, fail at it, learn stuff, and iterate until something stable emerges. Once the stability is there, you ship. Once you ship and it's no longer right in front of you, it becomes clear what data is missing from troubleshooting or debugging. You add more visibility and metrics into the product and ship again. You realize a bottleneck where some constraint in the system prevents it from scaling or it fails. You release that bottleneck by providing the scale, untangling the data and increasing throughput. You see how it has grown and now the whole system causes adjacent things to fail. You break it down into Microservices so at least the stable parts are persistent and the new features are the only thing failing. You realize you missed some metrics and logging in the previous release of the Microservices so you go back and add them, but also update your boilerplate/template for a new application and continue to iterate from there.

It's a process. It takes iterations. It takes repetitions.

You can read all the docs you want all day long, but typically sysadmins are less formulaic than developers. That's just a common pattern I've seen in the industry thru my years. Sysadmins want to just make things work while programmers favor order and perfectly square boxes. Having an understanding of both of these disciplines is rare and the result of things like IaC (Infrastructure as Code) and pipeline software like Jenkins, Travis, CircleCI, GitHub Actions and many others.

Process Architecture

The SDLC or Software Development Life Cycle is still relevant in 2026 and beyond. It may be tighter, more compressed and faster to iterate, but the structure is still there.

Some argue that the SDLC is dead and all that matters is shipping code. I would argue that it's important to document your deployments. Know what went well, what failed and where you can improve. Understand "why" something failed as well. If you understand rather than just guess, you can make structural changes to your process to avoid the mistake in the past. This is why things like testing, code reviews and documentation exist and are necessary.

It's important to understand the key principles of software engineering and architecture that are still important and relevant in today's age of AI. Everyone is talking about the cost of developing software is going down. I would argue the cost is going up because the value-add software architects and engineers do is rising to higher and higher stakes. It's aligning with business insights that weren't previously tracked. It's tightening the communication loop between customer, architect, PM and engineer. Being clear about the full description of the project is more important than ever. Asking the "why" behind something is what will drive customer success, not number of lines of code (LOC) written or number of PR's opened up in a short space of time. LOC and PR count are like views, follows and likes -- vanity metrics.

Be clear about what you want as the outcome and you'll thrive much better than the neighbor tokenmaxxer who's trying to prove they're "AI-first" just to satisfy their ego.