Architecture Is About Making Easy Things Harder

In iOS development, there’s always been a fight over Controllers. The path of least resistance, when you have a piece of new logic to add, is to just throw it in the Controller. Every Apple WWDC for years would pretend this is how you add this new API. Drop in three lines, ship it.

The right answer was almost always: don’t. You take two steps down that path and you end up at a 5,000 line ViewController with zero tests and no way to add them. So instead you define an abstraction, move the logic to a service, wire up the interfaces, etc. Now it’s not three lines, it’s three files. The natural path forward got harder, on purpose.

Good architecture is about having the discipline to make the easy thing harder.

What it looks like when it works

I spent several years on a B2C app with a wonderful architecture. The separation of concerns was clean enough that the codebase guided you. You knew where new logic went. You knew where to look for existing logic. Adding a feature felt like following a Lego instruction booklet: each step clicked into the next, and at the end you had the thing you wanted.

The team didn’t get to keep that for free. We worked at it. When Apple introduced a framework that resisted unit testing (cough Sign in with Apple cough), we added abstraction layers that allowed us to create a testable surface. That was extra work. Sometimes more work than code that used the new service. But it was done on purpose to ensure the architecture remained a joy to use.

What it looks like when it breaks

The opposite is also true. If you add one developer who doesn’t care about the cleanliness of the architecture or the presence of unit tests, it can all crumble so easily. Not because someone is malicious or lazy, but simply because the path of least resistance is almost always the wrong path.

I always use the analogy of a woodshop. If you’re there and all the tools are well taken care of, neatly put away, and everything has a sense of where it’s supposed to be, you feel an obligation to not be the person who leaves something out. You clean up after yourself. And you get to enjoy the benefits. When you need a tool, you know exactly where it is.

But when one or more people stop caring for it, it doesn’t take long to snowball. The less conscientious people see an excuse to do less. The people who really care start to look for a way out. You can’t enjoy the architecture because you never know when your hard work in tidying up will be made useless by someone taking a shortcut.

Why this conversation is different now

The reason this is worth writing about in 2026 and not 2016 is that the cost calculus has shifted.

The argument against rigorous separation of concerns was always partly about effort. Yes, the architecture is cleaner if you define an interface, write a service, mock it for testing, document its contract. But that was a lot of typing. “We’d love to do it the right way, but we don’t have time.”

AI as a tool changes that math. As I wrote earlier this year, AI is a fantastic tool for amplifying judgment, not replacing it. The busywork that used to be the cost of architectural discipline (boilerplate interfaces, test scaffolds, documentation, repeated patterns) is the kind of work an AI assistant is genuinely good at while being indefatigable.

On our current project, we have a well defined architecture with a clean separation of concerns. We encode all of that as instructions in AGENTS.md along with specific markdown files for different areas of concern (UI, localization, persistence, etc). When using agents to help us, they already know to enforce the rules and take the harder path, even when we’re up at project speed.

The argument “we’d love to do it the right way, but we don’t have time” is becoming harder to make in good faith.

The principle

Architecture isn’t elegance for its own sake. It isn’t a checklist of patterns. It’s the intentional friction you put between today’s easy path and tomorrow’s mess. The shortcuts you resist this week shape the codebase you’ll be working in a year from now.