Software Architecture Insights and AI/ligned

Your team is shipping faster than ever. The sprint board is clearing. AI coding tools have turned hours of boilerplate into minutes. Leadership is happy. And quietly, your codebase is accumulating a bill it hasn’t paid yet, and perhaps can never afford to pay. GitClear’s 2026 research report, “The Maintainability Gap,” tracks seven code quality signals across 623 million analyzed code changes from 2023 to 2026. The report does not argue that AI writes bad code. What it finds instead is both...

Every software architect who’s been in the field for more than a few years knows about Conway’s Law. The observation that organizations tend to build systems that mirror their communication structures is so well-established at this point that it shows up in the opening slides of conference talks about microservices, team topologies, and domain-driven design. But there’s a version of the Conway’s Law insight that gets almost no attention. This version operates a level above the organizational...

This article is a reprint of the article I wrote last week on The Software Conductor substack. Let me give you the numbers straight, because I think the industry has done a lot of hand-waving around them and that isn’t helping anyone. Programmer employment in the U.S. fell more than 27% over the past two years. Entry-level technology hiring at the largest firms is down 25% year over year. These aren’t rounding errors or statistical noise. They represent hundreds of thousands of people who...

You've probably read a dozen articles about how AI tools are changing software development. Code generation. Developer productivity. Faster PRs, smaller backlogs, fewer boilerplate hours. Most of this coverage focuses on what developers do with their time, which is genuinely interesting. But there's a different question that matters more for your architecture practice. What happens to the architecture team when AI absorbs the execution layer of software work? That question has a different...

I started writing this book three times. The first two attempts were what I thought a software architecture book was supposed to be. Frameworks. Diagrams. Bulleted lists explaining the difference between a developer and an architect. Sections with titles like "Characteristics of Effective Architecture Practice." The book was technically correct. It was also completely lifeless. I called the publisher and canceled the contract. That was three years ago. The reason it was lifeless took me a...

There’s a phrase you’ve probably typed into a ticket at some point in your career. Maybe someone filed a bug. Maybe a customer complained. You looked at the system, traced the behavior, and confirmed that the output was exactly what the logic should produce. So you closed it: Working as intended. It’s the cleanest possible resolution. It means the system did what the system was supposed to do. It means the problem, if there is one, belongs to someone else: product, policy, legal, whoever...

If you worked on web applications fifteen or twenty years ago, you remember SQL injection. You'd be doing a code review, spot a line where the user's input was being concatenated straight into a SQL query, and feel a small chill. You knew what could happen next. You'd file a bug, talk to the developer, and replace the concatenation with a parameterized query. Over time, the industry made SQL injection hard to get wrong. Frameworks handled queries for you. ORMs treated raw SQL as a thing to...