Architecture in the Age of AI - Micheal Carducci

In this talk, Michael Carducci explores the evolving role of developers and architects in the age of AI, emphasizing the significance of architectural thinking and human judgment in software engineering. He argues that instead of merely coding, professionals must embrace constraints to shape outcomes and improve software architecture. Drawing on concepts from notable figures like Fred Brooks and Roy Fielding, he highlights the importance of reducing complexity through deliberate architectural decisions. Carducci illustrates how successful architecture involves understanding the interplay of constraints and capabilities, positioning developers as vital stewards of architecture in an increasingly automated coding landscape. Ultimately, he encourages a shift from traditional perspectives towards a more holistic view of software development, underscoring that the quality of architecture will dictate the success of AI-assisted coding.

Now, what I do as a speaker, as an author, as a trainer, I do something a little bit different than a lot of what exists out there. Because if there's one thing that AI has done, it's seduced us with easy answers and quick fixes. All you need is a prompt and the rest will follow. Is that working for everybody? Yeah. So, what I do is less trying

to tell you what to think. And what I want to give you is tools to help you navigate the future, navigate the uncertainty. In other words, instead of telling you what to think, I want to paint a picture to give you better ways how to think. And I think that's a difference. That's what I really want to dive into. Now, if we haven't met in person yet,

my name is Michael Carducci. I like to call myself a holistic software architect because the problem and the solution is always bigger than it looks. It's always more complex than it looks. There are always more variables than are immediately visible. This is why the human judgment in the process of building software and engineering things, that's why it's priceless. Now, I've spent about 26 years in industry. And

the last 15 or so have been focused on architecture. I wrote a book on software architecture. I'm very proud of it. And it I I'm proud of the fact that it stands apart. It's materially different from everything else that is out there. It's not a cookbook. It's not a set of recipes. It's a set of tools for thinking about architecture so you can be successful, so you

can manage the risk. But all of that stuff, author, speaker, software architect, developer, all the other things. I also have this whole other career that I've been doing for almost the same amount of time that I've been coding. I've been a professional magician. I've traveled the world. I've been I'm an award-winning magician. So, why don't we start with that? A little thought experiment, if you will. Did

you know that if you got a deck of cards and shuffled them, think about this for a moment. If I took a deck of playing cards and shuffled how many What is the likelihood that somewhere in the world there's another deck of cards in that exact same order? Is it possible? Sure. Is it probable? Not really. Because the number of orders of a deck is 52 factorial.

You see, one card can occupy any of 52 places. The next card can occupy any of 51 50 places, and so on, and so on, and so on. That number is 80 thousand vigintillion. I had to look this up. I didn't know the I didn't know numbers went that high, but apparently they do. And I'm told they keep going. But that means there are more possible orders

of a deck of cards than there are atoms in the observable universe, which means something interesting. It means that if every GPU in every AI data center and cloud data center everywhere ran at 100% of all of that computational capacity, and what are we at right now in terms of exaflops? Yeah, we're somewhere between 50 and 60 exaflops of compute. That's unimaginable numbers. And these GPUs were

doing nothing but calculating new orders of 52 cards for every processing cycle that these chips could do and they were doing nothing but completely completing all the different unique arrangements of 52 cards, we would actually reach the heat death of the universe before that software even got before that hardware rather even got 1% of the way through the possibilities which that magic shouldn't be possible. Yet, that's

one of the things that I do both in the entertainment world and in the tech space. I used to think they were different careers. They're not. In fact, Arthur C. Clarke famously said that any sufficiently advanced technology is indistinguishable from magic. So, let's uh let's look at this because entropy is constantly increasing. have a deck of cards. And there's a physicist named Richard Feynman and I heard

him explain this one time. He said entropy is the universe shuffling the deck. But you see engineers software architects and magicians we all try to do the same thing. Try to impose order on the chaos. There are four suits in a deck of cards. There are clubs, there are hearts, there are spades and there are diamonds. Name a suit. Out loud. Go ahead. Oh, I heard way

too many people all at once. That was This was my mistake. This is my bad. Did you say What did you say spades? Spades, okay. Of Of all the spades, there's ace two three four five six seven eight nine ten, there's a jack, a queen, and a king. Now, I have an ace of spades tattooed on my arm, so don't let that influence you. But I want

you to name one of those spades. Yeah, sure. King Oh, king. Okay, yeah, you said it first. You said it second. I like it. There's consensus in the room. Out of all the decks. Now, if we were relying on pure chance of that card appearing exactly where we want it, the odds would be astronomical. But see, architects have a trick. What we do is we reduce the

dimensionality of the problem. So, I'm going to take a bunch of cards out here. See, you said spades, so we don't need any of the red cards. And you said any of the clubs. You said one card. Which we'll put right Actually, we'll put it right over there. You can still see that. Perfect. That's what we do. We introduce constraints into the problem space. That's the key.

That's the idea. We eliminate the black cards. We eliminate or we eliminate the red cards. We eliminate the diamonds. And the problem space becomes much smaller. The great magicians and great architects, we don't rely rely on stochastic chance. We influence the outcome. We stack the deck. You said king of spades. It's a good thing you said that cuz all these red cards are actually blank. All of

the clubs Through the judicious use of constraints, we stack the deck. So, we don't rely on stochastic chance. We stack the deck in our favor so that the outcome that we want and of all the cards you could have inevitable. Thank you. Because that is what software architecture is all about. Now, architecture doesn't really work like or at least that's the architecture historically has always been a

crapshoot. Right? We build it and we hope it turns out the way that we drew it up. And usually it doesn't. We go through a few rounds and usually takes years, but we eventually get to where we want to be or the project runs out of money or something else happens entirely. But now we've handed the dice over to the machine and the machine can roll the

dice faster than we can think. And the thing is and what I want you to remember out of this today is that AI is not an accelerator despite what all of the breath of the breathless voices are saying over and over and over again, it is an amplifier and this one goes to 11. But you know what's crazy? We actually already solved this problem like 35 years

ago. The industry wasn't ready for the answer. So, if you're worried about what the future of engineering is or where your place is it, I've got your next move. There are problems that only you can solve. So, let's talk about that problem because it all comes back to entropy. This is a man named Fred Brooks. I don't know if anybody has heard of him, but he is

an important figure and he has timeless wisdom even now that he's gone. He's left it behind. He was one of the giants of our field. And he worked on one of the most difficult and challenging projects of his time and that was the IBM System/360. He wrote a book, you might have heard of it, it's called The Mythical Man-Month. And in 1986 he wrote an essay called

No Silver Bullet. Accident and essence in software architecture or in software, software engineering rather. We hadn't actually started talking about architecture yet. This came up before architecture. You can believe that. Now, a lot of people remember the title. They remember the headline, No Silver And what he basically said is no single technology is going to make software development magically 10 times easier. And that's actually not the

most important thing in that essay. He said there were two types of complexity. Complexity comes from two different places. He talks about accidental complexity and essential complexity. Essential complexity is the stuff that comes from the problem itself. It is the the essence of what you're doing that is essentially hard. It's the domain, it's the rules, it's the interactions, it's the real world, everything that exists outside of

the confines of the machine. And then there's the complexity that we add. This is stuff we add ourselves usually through languages and frameworks and infrastructure and implementation approaches and often over-engineering. That's a lot of the accidental complexity. And it turns out we're really good at accidental complexity. And if you've been doing this long enough, you've seen it. You've done it. I've done it. I've done it more

times than I care to admit. That was one of my signature moves for a lot of my career. And the thing is we don't just struggle with accidental complexity, we manufacture it. Neal Ford, who's in the other room right now, and I'm so honored that you chose to spend your time with Uh, Neal Ford is very fond of saying that developers are drawn to complexity like moths

to a flame. Frequently with the same result. Now Brooks warned us about this. Although Brooks warned us about it, the thought leaders weaponized it. They told us that all the additional complexity is the only way to go. And funnily enough, when you're drowning in that complexity, the people the loudest voices, the ones who were telling you what to think instead of how to think, they're the ones

that will helpfully step in and sell you more consulting services to help you navigate it. The thought leaders in the consulting firms took this warning and monetized it. The thing is, complexity emerges with or without our help. Brooks understood this. This is what he was warning us about. And in fact, to explain this back in the mythical man-month, back in the 1970s he used a metaphor. And

that metaphor was a historical myth called the Tower of Babel. The story is ancient. Basically, humanity decided they were going to you know, uh, laugh in the face of the gods and build something enormous. A tower that reaches to the heavens. it collapsed. Maybe you've worked on that system. And a lot of times the collapse is inevitable. Not because the builders was lay were lazy, not because

the tools were bad. But because communication broke down. Coordination broke down. Complexity exploded. And the system collapsed under its own weight. Brooks said that is not just part of Western mythology. That is a history lesson that we keep repeating. And all non-trivial systems trend towards a Tower of Babel. Brooks said that systems behave exactly the same way. As the system grows, interactions multiply, understanding fragments, explodes to

the point where nobody understands any of it anymore. And eventually that is inevitable. That is what keeps happening. And now what we're doing is we're adopting approaches where we understand it less. Now, Brooks warned us about this in 1975, but we did we did it anyway. I've done it multiple times. A lot of you have done it. You don't have to raise your hands. It's okay. We

don't have to be proud of our failures, but we can be. The reality plays out constantly. And it was so much so much so that we rediscovered the idea 20 years later. This is Cassandra, by the way. Cassandra was another history from mythology who was supposedly blessed by the god Apollo with the ability to see the future and utter true prophecies that she could tell you what

was in your cards, what was in your future. What an amazing gift. But the curse, the twist, nobody would ever believe her. That was the catch. And that's why she's standing there in a pile of rubble and a in a ruined city tearing her hair out because she tried to warn us. And that was that was what we discovered 20 years later. Instead of the Tower of

Babel, we took the same idea that already existed, but because we didn't look backwards, we only looked forwards, we rediscovered it, gave it a new name. Joe Yoder and Brian Foote popularized this idea of the big ball of mud because even if you don't know Brooks, you do know the big ball of mud. And they defined it. They said a big ball of mud is as haphazardly

structured sprawling that sloppy duct tape and baling wire spaghetti code jungle. We've all seen them. Information is shared promiscuously among distant elements of the system often to the point where nearly all the information becomes global or duplicated. The overall structure may never been defined if it was it's eroded beyond recognition. That probably sounds familiar to a lot of people in this room. For better or for worse

usually for worse. These are just the inevitable consequences of unconstrained growth. That's what a software system becomes without constraints. Now here's the thing. This used to take years. For almost all of the history of software building the Tower of Babel building a big ball of mud took time years sometimes decades. But we just changed the rules. Today we can generate enormous systems in minutes, which means that

we can build the Tower of Babel at the speed of a prompt. AI hasn't made us better. It just made our problems manifest faster. Because AI is an amplifier. It amplifies the worst aspects of software engineering. They emerge faster. They emerge faster than we can react. And this is why I wrote my book although it was a little bit ahead of some of this stuff. But this

is where software and our architecture starts to enter the picture. Because architecture is not about lines and boxes. It's not about frameworks. It's not about microservices. Architecture is about stacking the deck. These are your architecturally significant decisions. You can call them paved roads if you want to design principles best practices or your standard operating procedures. But the real job of the software architect is to shape the

outcomes. To stack the deck so the outcomes that we want become inevitable. But there's an uncomfortable part to all of this. I mean raise your hand if your main job is producing code, either directly or with the help of AI. So, almost everybody in this room. Uh of the people who raised your hands, how many of you consider yourselves to be software architects? One. Two, three, four,

five. Okay, so very, very, very few. Because to most people, and for most of history, right? That's not That's a reasonable That's a reasonable perspective to have based on history. Because historically, we've all architecture has always been something that architects do. But every significant design decision, every dependency, every abstraction, every API, every prompt is architecture. So, when AI starts generating the systems, those decisions don't disappear. They

multiply. And the issues amplify. But something strange is happening in software development. Because the real for all the people who raised your hand that primarily what you do is produce code, the real work isn't writing code The real work is shifting. It's moving upstream. It's the work that happens before the code exists. Because writing the code right now is cheap. But the hard problems don't disappear. The

essential complexity is by definition essential. They don't disappear. They move upstream to the problem definition, to architecture, to how we stack the deck, which means that the role of the developer is quietly changing. We're spending less time writing code and more more time trying to orchestrate the And I don't mean chaos in a general pejorative, like, "Oh, isn't this whole thing chaotic?" I mean it in the

literal mathematical sense. That these are non-deterministic systems. These are chaotic systems, mathematically speaking. We're spending less time telling the compiler what to do and more time deciding what must be true. And if you are touching the systems that AI codes, then you're the architect now. And it's as simple as that. So, if you're wondering about the future or even if you have a future in this industry,

remember this when code is Judgment, real judgment, human judgment, who can see the whole picture, the big picture, who has the conversations, who interacts with the other teams, all of the stuff that won't fit and can't fit in a context window, this is what you bring to the table. This is what has always been priceless. This is your differentiator in the 21st century. It's not how fast

you type, and yes, I can actually type 136 words a minute for better for worse. For worse, cuz I don't think 136 words a minute. It's not how many frameworks you know. It's your judgment. And the need for deliberate architectural thinking has always been true, but now it is imperative because AI won't solve problems for us. Now, a few years ago the linguist Emily Bender coined a

phrase. You've heard this, I'm sure, the stochastic parrot. A system that generates convincing language by looking at patterns, predicting the next token. And now, that is incredibly powerful. It is very cool. There's a lot of neat stuff there. I'm not trying to put AI down. I think it has value. It has a place, but it's not our place. It's a tool that we wield with judgment and

expertise and wisdom. It's powerful, but this whole idea is powerful, but it means something profound. It means something important when we when we work with LLMs. Entropy is a feature. The systems are designed to explore the possibility space. They generate, they remix, they improvise, they roll the dice, which means that we can't just ask them to write software. We have to do something else. We have to

put a lid on that complexity. We need to constrain the coding in in the the coding agents. We have to shape the system, define the boundaries, design the rules. We have to stack the deck. But here's the magic. If you do this right, and you think in terms of constraining degrees of freedom in your agent, because if you don't, they will generate a big ball of mud

faster and cheaper than has ever been done before. Because what defines a big ball of mud? There are no rules, there are no constraints. You can do whatever you want. You want a 30,000 line god class? Have five. You want to make everything public? Do it. You want to make everything global? Why not? There's no But if you've worked on this system, you know they become a

nightmare. You know they're fragile. You know you're dealing with a Jenga tower of code. You touch one thing, the whole thing collapses. And suddenly, your AI is spitting 100,000 line diffs, because it had to regenerate the entire thing, and it can't hold on to that much context. Things go off the rails. It tells you it's done and everything is flawless, and the code doesn't build and your

tests don't pass. And then you point it out, it says, "Oh, great catch. Now you're thinking like an engineer. Let me fix I see what I did wrong. Let me fix it." And the code doesn't build and your test build and And it says, "Ah, I definitely fixed it this time." Have you been in this loop? More times than you can count? Yeah. Yeah. Developers aren't going

to get replaced anytime soon. But if you constrain these agents, if you reduce the degrees of freedom, your architecture just falls out. Architecture actually literally falls out because architecture is not something you bolt on at the end. It emerges from the constraints that you choose. Constraints aren't just the ideas that prevent the next Tower of Babel. That was the lesson. It was unconstrained But they're not just

the things that prevent us from building that. Architecture is constraints. That's all architecture is, fundamentally. Okay, I see a couple people nodding, a few people looking at me. So, I I lost a lot of you, didn't I? Cuz this doesn't show up in a lot of books or conversations around architecture. So, let's reframe it. What is architecture? Well, if you ask 10 architects, you're going to get

at least a dozen different answers. But just like a dev can practice architecture without being called an you can be called an architect regardless of what you actually do. So, if you ask a cloud architect what architecture is, they might talk about high availability clusters, availability zones, Kubernetes, infrastructure as code. Maybe they'll talk about load balancers and subnets. But that's not how an application architect would answer.

That a lot of those concepts might be foreign to that application architect. They're more comfortable talking about abstractions and patterns and frameworks, maybe protocols. Now, we can disagree on definitions. They can disagree on definitions, on what architect means to them, but we have to agree on what that we think about and what both of them think about. Both architects are talking about the same What What are

they really talking about? They're talking about fault tolerance. They're talking about scalability. They're talking about cost and maintainability and deployability and evolvability. Modularity, they talk about complexity. What we're talking about is the non-functional properties of the system, the architectural characteristics, the things that exist and matter independently of the system's functionality. The ilities, the architectural characteristics. I like to call them capabilities. The capabilities of the software. There's

the functionality of the software, the capability of of the software. I don't say non-functional anymore because I realized that whenever I talked to the business people and I say the words non-functional, they stop listening. Well, I don't care about what it doesn't do. I care about what it does do. Okay. Well, let's talk about what else it needs to do. Let's talk about what capabilities the system

has to have. Oh, that's a great conversation. We're talking about the same thing using different words. That's another aspect of software architecture that is useful and valuable and that we're all going to have to level up on how we communicate, how to be able to speak to different people in different parts of the business and speak their language. So, the architecture shapes the system. The cloud architect

uses one set of tools, the application architect might use a different set set of tools, but it's a delicate and deliberate balancing act because every time one capability gets stronger, another capability gets weaker. Every decision is a trade-off. Now, as we do that, sometimes patterns emerge. We find the right combination of decisions that lead to a particular set of capabilities that other people might need and people

share these ideas and suddenly uh we give it a name and it becomes a pattern. And then people at conferences talk about it. How many microservices How many conferences have you been to more than one conference? How many microservices talks have you been to? People talk about this and they talk about microservices like it's architecture because these days architecture is mostly patterns. We've compressed the entire field

down to picking patterns. Which has hurt us enormously. And in fact, this is one of the reasons that a lot of people are so eager to replace developers with AI because we've got a knack for solving the wrong problems or taking the wrong approach. And it's not your fault. This is what everybody has told us what to think. The thing is patterns are a blunt instrument. You

know, we have a handful of patterns, but software doesn't just fit neatly into a couple of different sizes. And that actually leads to a bigger problem. We adopt a pattern, we modify it because we're always tweaking things. So, we adopt pattern, it doesn't deliver the way we hoped it would. So, we tweak it here and there. Maybe we borrow some ideas from other patterns. Maybe we cut

a corner here and there because there's stuff in there that we just don't need that level of rigor or we don't think we need that level of rigor. Now, over time, if we do this mindfully, the individual system gets better, but our pattern ecosystem ends up worse because whatever these organizations end up with, whatever they change, it becomes the new exemplar of that pattern. We did microservices,

we changed a bunch of stuff. We're still calling it microservices, but somehow it's different. Do you see where that all falls apart? And then it becomes the reference architecture for the next project. And all the new people, they learn, "Oh, this is what microservices look like." And then it doesn't deliver on the problems because that software system needs something different. So, we tweak it and modify it,

and we eventually get it to work, and so on. And then that becomes the new exemplar. And the consequence of all of this is that our pattern labels today are meaningless. You say microservices, that doesn't actually mean anything to anyone, humans or AI. And that's why today it's a dead end. So, let's tackle the problem at its core because it's not about patterns, it's about the The

capabilities don't come from the Patterns emerged in the pursuit of particular capabilities. So, where do these capabilities come from? All the ilities. Name Somebody name an illity. Hm? You said scalability, availability. Flexibility. What's the last one? Flexibility. Flexibility. Okay, where does flexibility come from? Uh we are supposed to have flexibility Or any new static to that. Hm? Yeah, no, that's that's that's the goal, but where does

the flexibility come from? What is it that we do in the architecture that makes flexibility appear? Coupling. Decoupled. Yeah, okay, coupling, yeah. Yep. So we're So now what we're doing is we're defining rules around coupling. We define rules around coupling, the flexibility appears. Elasticity. What we do is we define rules about the scope and size of individual modules that can scale independently, and that allows them to

start quickly and scale up and scale down in a very surgical way. They're the rules. So where do the capabilities come from? Well, the long answer is we could get all into philosophy of metaphysics, but I'll leave the philosophical arguments for the philosophers. The short answer is the constraints. That's what we're doing. We're We're putting constraints on coupling to induce flexibility. We're putting constraints on component size

to induce elasticity. We're putting constraints on the structure of the system itself to induce Cuz remember the big ball of mud is a free-for-all. There are no constraints. There is no architecture. Well, there is, but it's typically what we call an accidental architecture. But constraints are more than that. They're actually atomic building blocks of architecture. The constraints themselves are reusable. That That modularity and coupling rules, they

don't just show up in one architectural style, they show up all over the place. We borrow some of these rules from and we apply them to the modular monolith and we get some of the benefits. So, constraints aren't just the atomic primitives, they make up our periodic table of They're the individual building blocks. Add them up and you've got your So, whatever your architecture is, whether you

designed it or not, whether it was expressed or implied, because sometimes you you start a new job and you come in and you see what everybody else is doing, you say, "Oh, I guess this is just how we do it here." Nobody ever said it, you just sort of picked it up as you went. Your architecture's just a set of And this is why software engineering is

safe for now. This is why the 21st century software engineer can't just be a prompt engineer. They need to constrain the agents and they need them to be the right constraints to induce the right capabilities for a given system at a given time. a lot of you are probably hearing about architectural constraints for the first time right now. But, it's not a new idea. I learned this

from a paper that was published 26 years ago. It was Roy Fielding's doctoral dissertation. Maybe you've read it. Has everybody actually read Roy Fielding's dissertation? REST, the REST paper? Yep. Okay, one back there. Hey, good see Uh a couple of people. Okay. Did it teach you anything about APIs? No, not really. No. That's cuz it wasn't about REST. I read that paper trying to learn something about

APIs. I skipped all the way to chapter five because that's where he starts talking about REST. I read it, it didn't tell me anything about whether I should be using POST or PUT. It didn't tell me anything about serialization. It didn't tell me anything about versioning APIs. How can this be the paper on REST if it doesn't talk about rest at all? So, I read it again.

And I was no wiser. And then I went back and read it from the beginning. I thought maybe I missed some earlier context and I'm scanning for that context about APIs. He never mentions APIs once. And then I stopped and I read it again without expectation. And I discovered something that should have been obvious. But it wasn't to me. That the paper wasn't about rest. It was

about architectural styles and the design of network-based software architectures. I don't know how I missed that. But you know what? Reading comprehension is overrated. Yeah, there it is. And that kind of blew my mind. It sent me down a rabbit hole because what he was talking about is architectural design by constraint. And he was building on ideas. So, this sent me all the way back to 1992.

To something called Foundations for the Study of Software Architecture by Perry and Wolf. And this in turn pointed all the way to the Mythical Man-Month and Fred Brooks' warnings about unconstrained building and the Tower of Babel. And when I finally understood that, my my understanding of architecture changed forever. And that's a big concept that is central to the book that I wrote. So, the word might be

new. We might not use that word, but the idea isn't. It's the heart of all architecturally significant decisions. Reducing the degrees of freedom in implementation to induce the desirable properties in the system. The architectural capabilities. So, I'll give you an example. Microservices. Right? Microservices and all of its infinite variations and there are all these patterns emerge to induce certain capabilities and service deployability and testability and agility.

we constrain that it's highly modular. Different teams own different modules, and the constraints impose rigid boundaries between the modules in service of scalability, and in service of flexibility. It's one of those We have isolated databases. Remove the monolithic database, replace it with a federated model. Each microservice typically owns its own data. Decoupling at the data layer to induce We, in service of elasticity, we have the fine-grained

components. Uh these are some of the constraints, but you put them all together, we get the microservices architectural style. But what is an architectural style? Well, it's just a set of constraints that we use for a given system or given part of the system that has a name. A name-coordinated set of architectural constraints. And this is This also leads to something else. Microservices as a pattern doesn't

mean anything, but an architectural style has a very precise meaning. At least when we're using those words in this way. So, you know, we can do more. We can add more constraints. We can adopt asynchronous communication. We get a hybrid event-driven microservices style. We can take some of those constraints and put them in a monolithic package. And uh we get the modular monolith architectural style. We're modifying

the federated database to say, "Hey, you know, we're going to have one database, but we're still going to separate it the way that microservices separate databases. We decouple at the database layer, uh but we're not going to manage a bunch of different database servers. We still only need one for the scale that we're at." So, this is a really powerful model. And as I started to think

about constraints, I began to realize that it is our periodic table of architecture. And then I look at all the projects and all the failures, and I wonder why we ignore it. And the answer simple, because patterns are easy. You just follow the recipe. Because somebody told me that that's what I should think that I my next project should be microservices. Microservices are the panacea. So, why

don't we go full microservices? Isn't it better? There's no better. There's only trade-offs. And every constraint will improve one set of capabilities at the cost of others. They're always a trade-off. Now, one of the things that Roy Fielding said that I thought was really interesting is he said that the way that the constraints behave in the system is so that we could actually apply numeric weights and

get design time feedback. Perry and Wolf talked about this the same thing. They said, "We just need somebody to come up with a set of units and scale to allow the weights to be derived." And that hadn't happened in the year 2000 or 2010, but in 2020 Mark Richards and Neal Ford, Neal Ford who's here this year in their book precisely defined a pattern for the context

of the book and then gave it a score. And they did it qualitatively we didn't have a model for quantitatively yet. But that was about to change. Yeah, I'll let you take that picture. That was about to change because a new model was beginning to form. All right, I got to keep going. A new model was beginning to form. So, I was evolving these ideas into a

new holistic model for software architecture. And I deduced the weights based on what they had done, and I was convinced that architecture could be far more deterministic than the usual blind trial and error that permeates our field. It doesn't have to be a crap But we have to figure out which constraints matter. So, I came up with a formalized requirements analysis process that is repeatable to figure

out which constraints we need and how to navigate the trade-offs. And I never again did pattern-driven architecture. I focused on decision-driven architecture. And that alone changes the AI-assisted coding game. It changes how we interact with agents the same way it changed how I interact with implementation teams. No matter where the code's coming from, whether it's the bots or the humans, we need to constrain the degrees of

freedom. That's key to delivering not only a software solution, but addressing the long-term maintenance and effort long-term maintenance and effort to evolve the So, architecture is figuring out what constraints matter. Okay, so we've got a process for that. Fantastic. We can figure out what constraints matter. We can define the constraints. We can prescribe the constraints. Architecture is done. But reality is tricky. To quote Mike Tyson, "Everybody

has a plan until they get punched in the mouth." And it turns out not all the trade-offs are technical. I had to learn this the hard way. And one of the biggest was the failed product project that I led as chief architect. I did the work. I came up with the ideal architecture on paper. But in practice, it was a disaster. My model was incomplete because on

paper, microservices were absolutely the right answer. But in practice, we just couldn't get there. We burned tens of millions of dollars before the project was canceled and the division was eliminated. Hundreds of people lost their job. Rest in peace. Ouch. But what did I miss? Well, architecture doesn't just exist in the computer or in a diagram somewhere. Architecture is part of the organization. That's why I call

myself a holistic software architect. See, we look at this and we start realizing things that when you want to break a system apart into tiny pieces, we have to figure out where the seams are. That's a lot of work. And this is in fact why 23 years ago Eric Evans published domain-driven design. Uh for any non-trivial domain like the one that I was in, it's not an

exercise that the architect can perform alone in an ivory tower. Domain experts across the business need to collaborate and require time and effort and will that just wasn't there. And even if you get this right, you have to realize a truth that was first uttered by Melvin Conway in 1967. Organizations that produce systems will inevitably produce systems that mirror the communication structures. The architecture said one thing,

but the org chart said something else. And the efficiency of a team owning a small number of microservices will fall apart when the team focus crosses microservice boundaries and the team overlap the teams overlap. The coordination cost gets out of control. And then even if you So you have to do a complete reorg, not just say, "Oh, this is how we're taking the system apart, but this

is how we're taking the entire organization apart." And then of course, you've got the burden. If you get this right, you got the burden of managing a complex distributed system. It requires new skills that the teams didn't have. Pipeline development, IAC, Kubernetes, a lot of enabling agile technical practices. So I prescribed an architecture that was out of reach of the teams and it placed unreasonable demands on

them. You're always going to get something. Just like prompting an agent, you're always going to get But it's not always what you hoped for. So I had to go back to the drawing board. I went back to the drawing board with my model to figure out where it all went wrong. Constraints, it turns out, have dependencies. You can't just prescribe constraints. The dependencies are on the teams,

the environment, and the organization. So you can't just say, "Oh, we're doing microservices." Because there are major changes that span everything. And that means you can either change the organization, which is hard, or change your architecture, which is hard. Sometimes one is necessary, sometimes the other is wiser. And so when the architecture says one thing and the organization made something that the architecture said but the organization

made something else And that's what happened. And when I realized it, it was too late. But I didn't stop the work. I said, "Okay, I'm going to learn from these lessons and I want to help other people avoid the same fate." And I wrote a book. It was fully fleshed out a couple of years later in my book Mastering Software Architecture. And I was really excited because

a whole maybe we would be entering a whole new era of thinking about building software. And then the world shifted. Now, personally, I resisted. My early experiments with AI in coding were underwhelming and despite all the rabid voices on LinkedIn, I was sure that my coding chops would always be valuable. Of course, I was wrong. AI-augmented coding isn't going to anywhere anywhere even if it underperforms in

the long term. And the thing is, we're still just fumbling around in the dark. We're excited by speed and apparent simplicity. As coding became more automated, I ran into the same problems that virtually everybody else is running into. Amplified chaos. We're just building big balls of mud faster. And it's not because the models can't produce good code, they can. But we lack a coherent architectural definition language.

But constraints have always been the answer. Now, several years ago I read a paper called Software Architecture Constraint Reuse by composition. It's about the same set of ideas. This is published in 2016. And the authors of the paper saw exactly what I saw. Architecture constraints are specifications, which enable developers or agents to formalize design rules that architecture should respect, like topological conditions of a given architecture pattern

or style. The constraints can serve as documentation to better understand an existing architecture description or can serve as invariants that can be checked after the application of an architecture change to see whether the design rules still hold. So, once I approached integrated this approach to my work, everything changed. Other more hands-off approaches will outperform me always in raw speed, but they're just optimizing the cheap and the

easy part. But, I consistently outperform them in security and reliability and understandability and maintainability and evolvability and longevity and often correctness. See, I'm optimizing for the valuable parts, the expensive part. And when my book came out and everything changed, uh I was pretty sure I was too late to the game, that nobody would ever care about my book. But, then I started to realize The industry is

finally catching up to what Fielding said a quarter century ago, what Perry and Wolf said 35 years ago, and what Fred Brooks was saying 50 Everywhere I turn, the industry is rediscovering forgotten ideas. Usually, more often we're reinventing with new names. But, if you if you take a step back, if you look at the big picture, it's all there. That means you have the answer. It's building

a comprehensive vision that encompasses functionality and capabilities and architecture that can be communicated with precision. And that's the beautiful thing. If you're a developer today, your future is bright if you can bridge the gaps between a vision of functionality and a model of architectural longevity. That's the future of architecture, and this is a this is a practical way to get consistently good results from your agents. Understand

the requirements, read the environment. What is possible? What is practical? Understand the limitations of these tools. And with constraints, you can prompt your agents with precision. So, they're not just generating unconstrained code. You're You're you're giving them constraints to keep the entropy at bay. You're reducing the size and the scope of the solution space. You're stacking the deck so that the right outcome is inevitable. And this

is the new skill set of the developer in the age of AI. Because you're not a coder anymore. We're all architectural stewards, just working at different scopes and different scales. You're no just like me, you're no longer responsible for the implementation, but the result. And that's actually a better and more valuable place to be. And it means that you're going to be responsible, cuz you're already are

responsible for the long-term value of the software systems that you're involved with. That you're accountable for. So, some of you are thinking, "Well, okay, that sounds great, but I don't control the architecture." But the thing is you do control something. And in the age of AI, we need more control, not less. So, if you're an architect, keep doing the hard part. Work with the devs, help them.

And if And help the coding agents understand the constraints. And if you're a dev, understand the architecture, translate that into constraints, and use that to constrain your agents. And if we successfully navigate this shift, we can go farther, not just faster. Ironically, that was slow. I'm going to pretend I'm going to pretend that was deliberate humor. But we can't just set the rules, we have to enforce

them. There's still a need for governance. That's the work that we can check, that we have to check. And some of the work we can delegate to supervising agents, but resist the temptation to delegate everything. Not every problem requires an LLM. Not everything should be delegated to an LLM. The other thing to keep in mind is nobody's really paying for AI yet. Yeah, you might be on

the $200 a month plan. You're spending $200 a month to go through $20,000 worth of compute and electricity. That's not going to last forever. It's long-term. You want to be the type of developer that can get the most consistently good results using the fewest tokens. That's an important thing to keep in mind. One of the biggest shifts that I'm seeing is how the non-text technical constraints, the

team, the environment, the organizational constraints change. One of the most impressive wins that we building things like robust pipelines and other kind of platform tooling that used to require an entire team to do. Now you can get that knocked out before lunch and then start focusing on the real value. I can individually adopt constraints that I would never have been able to do before without one or

more very capable teams backing me up. In other words, AI handles my weaknesses. I can focus on my strengths and I can handle AI's weaknesses. I can do the stuff that AI currently can't do. So the that's the real value that I bring. The architectural judgment, the solid engineering skills, the fundamentals, the way of thinking about the problem, understanding the problem, communicating with other teams and stakeholders.

So developers aren't doomed. This doesn't mean that long-term there's going to be fewer jobs for engineers and architects. There won't. There's a There's a principle called Jevons paradox that when something gets cheaper, we use more of it, not less. And the biggest challenge right now is organizations can now move faster than they can plan, than they can think, than they can ideate. But that's temporary. Things are

going to accelerate. And they're going to need us more than ever. So we don't need fewer engineers. We don't need fewer architects. We just need fewer coding coders. And if you're in this room right now or you're watching on this video, I see you. Then uh that's not you. Code was never the value that you brought to the table. It was just the most visible thing that

you did. So, it's time to dust off some of the old technical practices because the good Agile technical practices are still Test-driven development, behavior-driven development, these things still matter. I pair program with my agents. Old school. Like I I Now, a lot of For a lot of people a lot of people heard the term pair programming and they're like, "Okay, yeah, pair programming. That means two developers,

one computer." And that's as far as we thought about it. And then we tried it a couple times and we're like, "This is stupid." Because either you're trying to explain everything and you're trying to talk as fast as you think and that doesn't work. Or you're just sort of coding with an audience quietly and they don't really know what's going on and they're not really paying attention.

You know, your pair programming partner's kind of watching you type and then eventually they're Yeah, no, it's good. Oh, it's my turn? So, we want to dust these practices off. This is what I do. I do strong style pair programming. Strong style pair programming follows the driver-navigator paradigm. The driver, person doing the typing. Guess what? That's not really me I'm the navigator. I'm the one controlling the

driver, telling them where to go. So, I work in small batches. I learn from old ideas like XP. Work in small batches, continuous integration, test-driven development, things like that. And then suddenly that constrains the entire process. Makes me a little bit slower, but a lot more effective. It's a lot more endurance. Because it's not a sprint, it's a marathon. And then every now and again we get

into that loop. Remember the loop we talked about? Oh, I definitely fixed it this Did you not notice that the project is still not building? Oh, great catch. You're an eagle eye over there. I see what I did wrong and you realize that that was like five iterations ago and now you're just back in an infinite And sometimes what people are doing is they're saying, "Well, that's

okay, you know, I've got I've got a I've got an agent to be me and an agent to do the coding and then I multiply that five or 10 times and then I just burn tokens all night." And then you wake up the next morning to an email from Anthropic that "Hey, your account's been nuked." It's happening now, a lot. But now when I get in that

loop, you know what I say? I say it's okay. I say, it's time we switch." And I switch my co-pilot into ask mode. And we set the context. I say, "Okay, I'm going to take over here and you're going to navigate me and I'm going to push back." So, we switch back and forth. There's a lot of good stuff in there. And also the TDD type approach,

actual test-driven development, not maybe test after code, not generate all the code then generate a bunch of tests. It's tempting, believe me. I've done it. And I every single time I wished I hadn't. So, that's kind of what I'm doing is I'm re- I'm dusting off all the old technical practices and I'm teaching my code needed coding agents cuz my goal is not to check some code

coverage checkbox. My goal is to remove the bottleneck to prevent a local optimization from disrupting the overall flow. So, I'm stepping into the role of the architect. Think you should step into Now you're mentoring a bright but occasionally misguided junior. Model the good practices. Say, "This is just how we do it." Because the model will say, "Okay." When I was an architect and I said, "Hey, this

is how we're going to do it now." Most developers like, "Well, I've always done it the other way." I'm like, "Okay, well, you're not there now, you're here. Well, I've always done it that way. What does that have to do with anything? I don't know, but I've always done it that way. And they fight and they push back. The agents are a little more agreeable, sometimes too

agreeable. So, teach your coding agent, model the good practices and use them to bring value the value that they were designed for. But just remember, you're the magician. You need to stack the deck. And just make sure that you stack the deck in such a way the outcome that you want isn't chance, but inevitable. >> [music]