Ep 269 Alex Bunardzic - From Code Fetish to AI Harness: Architecting Trust in an Agentic World

Transcript of Ep 269 Alex Bunardzic - From Code Fetish to AI Harness: Architecting Trust in an Agentic World
Host Eric Wright, guest Alex Bunardzic
Timestamps match the published episode. This transcript was generated automatically and may include small errors.

[00:00:00] Alright, this is this is one I've been waiting for for a long time, actually. One of my one of my favorite humans, who's one of my favorite teachers, because I was lucky enough to spend years of learning and building together with somebody who I'm very proud to share a microphone with today, Mr. Alex Bunardzic. So Alex, for folks that are brand new to you, let's have you do a quick intro. And then we'll kind of talk about the stuff you're working on. You've got a couple of really cool initiatives. But really, like what I you and I have been doing this for a while and we've seen a lot of changes, you introduced me to concepts that have still to this day become daily routines in thinking for me.

[00:01:08] So this is why I think it's so important as we talk about your experiences, moving towards this sort of the AI, the AI agentic, you know, bizarro world that we're in the midst of building and, you know, how do we find sanity and what does sanity even look like? So but anyway, sorry. So Alex, who are you and where do people find you when they want to find out more about you online? So I am a guy who has been doing this for over 30 years, to be more precise, more than 35 years this year. I started my career, I'm a scientist by education and by training. And I started my career in the field of scientific research, basically spent five years as an apprentice in sort of a scientific boot camp, which taught me how to work and certain discipline, certain way of dealing with large complex systems.

[00:02:16] My thesis was focused on ecology, ecosystems, which are very, very complex and consist of many moving parts. So to me, naturally moving into software and I had to move into software because I had inherited copious amount of data from a professor who retired and he was collecting, meticulously collecting all kinds of data in the field for 22 years, such a huge amount of data. And they were just kind of handwritten, as you might imagine. And so there was at that time, there was no way from, you know, we didn't have AI or anything to crunch those numbers. So I had to roll up my sleeves and learn how to write programs. And that's how I got into software. And then moving into Canada, I realized that scientific research is not a very lucrative. Good for the heart, not good for the wallet, one would say.

[00:03:20] Exactly. Yeah, it's good if you are well-heeled and you just want to enjoy and it's a beautiful, beautiful activity, one of the best I can imagine, but it won't pay the bills. So at that time, as you know, Eric, back in the 90s, software was hot. So, you know, I started doing professional software development and one thing led to another. Then you and I met at one big company. Now, I got to say something about you. There is a saying in my native language that's difficult to translate to English, but it's like, how difficult is it to prod the frog to jump into a pond? So you're talking about things, you kind of paid attention to what I was doing. It was super easy. One of the easiest people I ever met who just at the hint of a concept, I could see that you could immediately not only understand the concept, but what I really appreciate is people who hear about the concept and then in their head, in their mind, they can carry a drive through and come to their own conclusion.

[00:04:29] Excuse me, because oftentimes when I'm teaching some of these concepts, then people need hand holding. They were like, yeah, OK, but can you give me an example? Can you give me another example? And then sometimes it is the same goes. I don't want to be rude, but you can lead the horse to water, but you can not make the horse drink. But I got to tell you, I was very impressed with your sharp as a whip, very open to learning new concepts. And the moment you hear it, I can see you can apply it. You don't have to come back and say, yeah, but like, what do you mean by this? That's what that was really, I think, distinguishes people who are natural in this profession from people who are struggling. And you've got to be able when you hear something new and intriguing, you've got to be able to go away in your mind, devise an elaborate use case for the concept. Devise an elaborate use case or scenario to illustrate to yourself how would that concept work? That, I think, is the distinguishing feature.

[00:05:31] And it's quite rare, to be honest, or maybe people just don't want to bother. But I think that's essential when you hear, you know, the moment you hear something from XP or test driven or you should be able if it intrigues you, you should be able to say, OK, now let me apply this to whatever I'm working on, whatever is familiar to me. And then sharp people will find a way and then will not need too much handholding. Of course, examples happen, you know, help if you have some examples. But I find, you know, too many times people just want to give me another example, give me another example, which cannot extrapolate. Right. And, you know, that's the, I think, qualification or the, what's the word, treat that people who want to go into this profession have to be able to deal with abstract concepts and apply them on a specific task at hand. And these are the brilliant people who make things happen in our profession.

[00:06:32] So another thing I've noticed, and I think, you know, I think you're really good at that, is people, when people join this profession, let's say somebody joined five years ago, 10 years ago, 15 years ago, they just start from the moment they joined and and look forward. But very rarely do people look back and try and check what's the, I mean, look, if I want to be a physicist or I want to be a chemist, I want to be a biologist, I want to be a medical professor, of course, I'm going to learn all about the history of my profession. I'm going to, if I'm a physicist, I'm going to learn about Isaac Newton. But, you know, I'm going to look back. But for some reason, people coming into software, they absolutely clueless as to what, how we got there. Right. And that's always about, I mean, it's, our profession is only 70 years old. Why wouldn't you want to go back and see what happened in the 50s, what happened in 60s, how in the 70s, 80s, 90s, blah, blah, blah, gotten to this point. It's very important to understand what brought us here.

[00:07:33] And yet, anytime I mention any of these things, nobody's ever heard of these things. Right. For example, I like to talk right now, there's a lot of discussion about, oh, we can't have a machine generate source code. Well, look, my first job here in Vancouver, I got hired to develop business applications using so-called CASE tool. CASE, back in 35 years ago, it was all the rage. It was an acronym for Computer Aided Software Engineering, CASE. And the tool I was trained on was called Sinon. What is, that tool was basically, you're prompting the machine. You're declaring, we were declaring our intentions using high level, high level abstraction, which then this tool Sinon will turn around and generate COBOL code. And then the COBOL would run on the mid-range, it was IBM mid-range computer.

[00:08:38] And, you know, it would basically work. Now, what's interesting about that is we never even once had felt the need to go back and check on the generated COBOL code. Nobody did that. It was just like, same as when you compile your C program, you don't go in and dive through the binary code and check. You just take it at the face value. It's a black box. And, but nowadays, when I ask, when you ask the machine, you know, is it the ChatGPT or Claude code or whatever, to generate some code, everybody's losing their mind, like, oh, this is so non-deterministic, you know, that's another really silly point at this, at this time that nobody, everybody's going, well, the sky's falling, everything's going to just blow in our faces and we all going to be, Armageddon's going to come. So to me, that's interesting how back then everybody was cool because, first of all, the community was much smaller.

[00:09:38] Right. Right. The professional was still young. And, and also, let's be honest, the systems that were much simpler. Yeah. Less variations. There weren't 3,428 JavaScript, you know, frameworks that you had to pick from and, and such, but, but even then I would, I would say that in the early days, the same level of discussions were occurring just in smaller communities with a smaller set of artifacts to choose from, like it was COBOL, Fortran, C, C sharp, you know, like, or, or C plus plus like C plus, like you, there were less options. And so it allowed us to be, find the options within the frameworks rather than find the options outside of the frameworks from other frameworks.

[00:10:39] And, and so we kind of, we were, we felt that that was a constraint that allowed us to be much more freewheeling within. Cause constraints to me, I always see a constraint as a beautiful thing because it means I've got, this is the edge to which I can run. And sometimes I like to run a little past it to make sure it really is a constraint. But like I, I find, so I would say we've just extrapolated it now. And unfortunately what happens is when we fan out that conversation, the non-determinism becomes patently obvious because it's on Twitter. Yeah. Yeah. But you see, I'm saying like people not keen on studying the history. So then what happened mid, mid nineties is a company called Sun Microsystems, which nobody remembers now, was looming large back then. And they were running on a slogan called network is the computer, which was counterintuitive back then, because even let's say in the eighties and early nineties, basically either you were working on mainframe, which looked like a box, big iron box, or you were working on your PC and it was just a box.

[00:11:55] And barely anyone was ever connected. I mean, only the pioneers were connected to some kind of a network. It was before the web. Yeah. And so our, our thinking was, let's just say constrained inside a box. So if the, if the box is up and running, that means everything's going to work. There's no, like it's binary. Right. And then moving into the network, things become gray. It's like, just because this box is running and that box is running, it doesn't mean everything's going to work. Right. But what happened in the mid nineties, a new technology came along called Java, which was basically propagated with the slogan, write once, run anywhere. So basically what is it, excuse me, what it meant is there was a recognition that all of a sudden we're not, we don't live in the age of boxes. We live in the age of networks.

[00:12:54] And so on the node of various networks, there are different stacks, there's different vendors, different machines. And so this Java virtual machine was like a cuckoo's nest that you can plop into any, whatever stack you have, and it will behave the same. Yet another challenge to discuss, non-deterministic, you can have a Java source code and it will be interpreted differently on different hardware. Right. Right. So there, there goes your determinism and this bullshit about, oh, we have to have 100% determined. And even if you stay within one box, and let's say you, you have a, you write a program in C and now you can compile it to the binary code. You can use different compilers and each compiler is going to give you a different version of the binary code. So even, even there, you don't see determinism.

[00:13:52] So that's a big myth that people are peddling about. Oh, we can, unless it's a hundred percent deterministic, this is not serious. You're Mickey Mouse. You're not qualified, et cetera. So we need to fight that because people need to understand from the earliest days, we never had determinism. It was always, you know, fluid. And so now fast forward to today where we realize that, okay, A, we have these machines, I call them machines, but let's call them whatever, AI agents, genies, magicians who can really write a lot of implementation code. And that really affects the mindset because you and I know, both know that we lived through the ages, through the years where it was kind of expensive and involved to create software. If, you know, people are charging a lot of money, it was taking a lot of time and there was a lot of issues, et cetera.

[00:14:58] So code, source code became like a precious asset. And it was, it was regarded as like intellectual property assets, jealously guarded, et cetera. And it, it developed this mentality, which I call code fetishism. The code was a fetish. And there was a lot of these macho people who were like, oh yeah, I can, I can crank this code and this is my baby and this is my pet. And, you know, it's super duper nice and shiny. And all of a sudden that got seriously challenged because, because I can generate and regenerate reams and reams of code. And, you know, there's a more, there's a, there's more than one way to skin a cat. And people kind of forget that. People think there's only one, one possible way to skin a cat. No, there's many ways. And really the value is not in the process of skinning. Nobody's going to pay you to watch skinning the cat.

[00:15:58] I mean, this is an ugly metaphor, but what people are paying is a skinned cat. How you got there doesn't matter. Right. Intent, skinned cat. Yeah. I'm paying for that. Have to intent, don't tell me. I just want, I want the result. Exactly. It's my metaphor is if I go on Amazon and order something, I want this order to be deterministic in the sense that I want my order to arrive at the agreed upon time, not damaged. And it's for the acceptable price. That's determinism. I'm not going to bring down, bring down their nexus. No, no. I want you to drive from Richmond and I'm going to take it. I want you to take Oak Bridge and then, you know. That's right. Don't forget to get in the left lane before you get on the right lane. Get in the left lane before you get off the edge of the bridge. Otherwise, you'll miss the turn and it's going to. Yeah. I'm not paying for this. I'm not paying for this. This guy took, you know, all I'm saying, I don't care if it's by a horde of monkeys, if it's by donkeys, if it's by, you know, carrier pigeons, somehow this parcel is arriving at my doorstep, undamaged at the agreed upon time.

[00:17:08] So that's determinism. But people latch on to how this thing is going to come, arrive. And I think that's a big mistake. But we see that a lot. It is a huge pushback. So that's what we are fighting now. I have just maybe fast forward to today, seeing at the end of last year and the early days of this year, we've seen few, in my opinion, interesting breakthroughs with the latest crop of AI agents. Mostly, I mean, the most advanced right now, the jury's out, but maybe Cloud Code is kind of still leading the pack, although OpenAI Codex is catching up quickly. There are other antigravity. There are other litany of these, because it's really, it's an interesting area with what some people claim that you can, it's very hard to set up a moat here. Right.

[00:18:05] Yeah, yeah. In effect, I'll treat it, they're like great directors in that you've got a Paul Thomas Anderson and a Stanley Kubrick, and each have distinct styles. One's Cloud, one's Codex, and then there's an antigravity over there. So we've got some other person that's a little avant-garde in their approach. And so each will have a somewhat opinionated way to achieve a thing. But the opinion is so buried inside the back ends that we're not privy to it, which is interesting. And it even adjusts too, because if you watch one Paul Thomas Anderson film, and then you watch the next one, it does not look like it was done by Paul Thomas Anderson. There are PTA-isms in it, but he evolved in the four years since the last movie. So he got a little bit more experimental with certain things and such. That's why I always think of that as these are the people that are vision-oriented, and then they have to get these actors and all of these things to behave within that world to create the resulting vision in a print, an actual outcome that's repeatable and visible.

[00:19:24] That's a brilliant metaphor, and it really applies well. And even Gilligan, who we adore because of The Breaking Bad and Better Call Saul, has now evolved into this pluribus. I don't know if you watch pluribus. I haven't, but I've gotten hints of kind of what the theory is. Yeah, and the guy's obviously very creative, so he's not standing still. If we are expecting yet another Better Call Saul, no. It's a complete surprise. It still has a seal of his approach with interesting camera angles and color schemes and all that, but it's different. It's almost like it's not him, so it's really fascinating. I mean, if you have the time, watch it. It has some criticism on it, but it's really well done. The more I hear something is disliked, I'm like, I gotta watch that one now.

[00:20:25] When someone goes, I'm not sure what I just watched, you're like, perfect, I know what I'm watching tonight. Yeah, it's like one of the people I admire in our profession, Kent Beck, the guy who invented extreme programming and technical development. He said something I really like. He says, if I come across a new idea, and if I'm like, wow, this is really impressive, then I know that obviously other people have already latched onto that and are kicking the daylight out of it. But if I hear something like, oh, this is like phenomenally stupid, I gotta try it. I need to see what's behind it. And that's how he got with this, I think it's called the TCR, different approach to building software, which I also like. So where was I? Basically, the code fetishism is now a dying, I believe, dying breed. It's very hard to justify so much fetishizing and so much adoration and actually charging so much money for a commodity.

[00:21:32] It used to be a real added value, a real asset that only few people can deliver and they can charge big bucks. One of my last projects, I was managing the team and we had one contractor and he one day calls me up and says, you know what? I'm upping my hourly rate to 220 bucks. I'm doubling my rate. Oops. Well, this was before AI. So you gotta pony up. He has you by the horns. I doubt that today that would be so easy to get across. And so, obviously, people are upset about it because you lose your cushy, your sort of privileged position up on the throne. You can just call the shots, working when you feel like working, going, you know, and people always like, okay, walk around your neck, like don't upset, this is a guru.

[00:22:33] And all of a sudden that privilege is kind of vanishing and people are getting pissed off. So now that this is not an asset anymore, what is an asset? And here's where we have a very interesting situation. Does the intent or the expectation or the specification is now the asset? The order, like what is the order for Amazon? It's basically that I am making an order and paying for it. The way they deliver it is not an asset to them. It's a commodity. One way or another, it's going to get delivered by drones, by who cares. And so same as here, like the intention of what we want, what we expect this thing we are building to deliver, to do for people is the asset. The way or the implementation, how it's going to get delivered is a liability now. So the more we pour over that, the more we spend time on this liability, the less competitive we get, right?

[00:23:37] Because there's competition that can maybe fulfill that expectation at a fraction of the price. If they got that together, if they know how to work with agentic development and they deploy all these like cloud code agents or codex agents, and these guys are working around the clock, not taking any bathroom breaks, not going to complain to HR, et cetera, all of a sudden you're clearing competition's clocks. And so I think the focus is shifting from, hey, we have to have the genius coders who can just drive circles around this and that doesn't ring a bell anymore, I think. But can we have people who can figure out exactly what would hit the sweet spot? On the market. And that, you know, it is easier said than done. So what we are discovering, we discovered a long time ago, the best way to go about it is to do a little bit of a chasing after the feedback rather than sitting in an ivory tower and saying, okay, now I'm meditating, I'm daydreaming, and I know exactly what the market is going to want.

[00:24:47] Well, you're not Steve Jobs, you know. These people come once in a generation. So you better have a trial balloon. You better put something in front of people and see if it's going to die or live. And if it lives, what is the next step? It's like you have a newborn, now you have to learn how to change diapers. So it is more incremental or iterative. And so I think this is a new discipline. But the problem is this. We had, as you and I know, at our company, where we work together, we had this classic good old times waterfall approach. We got a PMO, they were held exalted in the org as like they speak from the tablets. Exactly. Come down from the mountain Sinai. It was beautiful, it was just gorgeous. Gorgeous.

[00:25:45] So they spend months and months gathering requirements, fat documents, checking and rechecking, reading. Eventually, those documents get signed off. And guess what? The next thing that happens is amazing. Those documents get frozen. This is killing me. You freeze them. And what you're saying is like, look, and now you hand it over to the architects, such as yourself, designers, coders, testers, operations, et cetera. But the message is like, look, from now on, we're going to ignore reality. These are the rules. If reality tries and mess with us, we're just going to bend reality. We're going to say, no, no, no, no, no. Not in the doc. Don't make me tap the document. Yes. What does it say here? But, but, but, but no, no, buts.

[00:26:42] Right. And then we had these like 18 months project. It's just kind of botched and didn't go anywhere, didn't deliver anything. And et cetera. We don't want to sort of froth on that. Right. But then, you know, you moved and I moved into more startup agile mentality where, you know, basically what we are doing with XP, the most important thing for me about XP is at the end of, we give them options. Like, let's say you and I have a customer, a client, and we are charging them. Well, the most honest thing we can do is give them options. We can say, look, at the end of every work day, you will have something on your hands that's up and running. It's not going to have all the bells and whistles. It's not going to have all the fancy things you expect. It's going to do something useful for you. At this point, every, at the end of every day, you can approach us.

[00:27:41] You can shake our hands and say, guys, this has been fantastic. We've decided we don't have the budget or we are pivoting and we part amicably. And you're going to have a nice review. You guys did a good job. Or we would like you to come back tomorrow and continue. I think this is the most honest way to work in our profession. But at the end of every day, what we are working on has to be up and running and in front of the customers. This is XP. This is the ethical thing, in my opinion. Instead of having thing busted for 18 months, nobody knows what's going on until the ta-da. Yeah, this is the big reveal. Like, they pull the cloth off it. Oh, it's a boy. It's a girl. And no one will use the system that you've developed. You've built this fantastic behemoth that is no longer even a hint of what you need. Yeah, and sometimes we call it the watermelon effect.

[00:28:40] So as the watermelon is growing, it's green and green and greener and greener and greener. And ta-da, you open it, it's all red. So we learned to kind of abstain from that. But now with this new era of code is not a fetish anymore, and now we are free to focus our attention back into what is a real asset and how do we minimize liabilities, there is a danger of the waterfall returning. Because now the spec has taken the center stage again. People have attempted to go back into the ivory tower and meditate and navel-gazing and coming up with this beautiful spec, big upfront design, et cetera. That is a potential danger with this new, because people say, hey, I mean, we don't have to worry about how this is going to get implemented. The agents are going to figure it out.

[00:29:37] So let's spend all our energy, all our time, and just beautiful top-down design is going to be fantastic. And that, I think, there's a danger in it. And that's where we are at at this point. Because when I talk to people and I warned about that, they said, you don't get it, Alex. Yeah, this is a beefy spec, but because the agents are so powerful, the cycle is short. So you don't need 18 months, you need 18 minutes. But that's not the point, because I don't think waterfall was problematic because of the time. It was problematic because of the bloat. The batch size is enormous. So whether you do it in 18 seconds or 18 months, doesn't matter if the batch is huge and has a huge blast radius. Then when something happens, it's very difficult to pull out, roll back to remedy, to roll forward.

[00:30:36] And that's why in XP, we are proceeding in tiny steps. You know, and as soon as something blows, we just, you know, hit reset hard, go back. Right, exactly. That one didn't go well, but let's go back to yesterday. Yeah. And so we want to, at all times, back to XP. At all times, we want to have our system in a healthy state, in a green state. And to do that, we have to be really humble and modest. And as we are delivering more and more functionality, these are all kind of very, you know, nothing to write home about. But slow and steady wins the race, instead of giant leaps and giant steps and falling off the cliff and coming back with bloody noses and black eyes and all that. We are very pedestrian, very kind of plodding, but it's a steady progress. And that's what I think we need to learn to appreciate, especially with these AI agents.

[00:31:36] We need to be careful. And this brings me to another topic, which is, I'll give you an example. So recently, I was working, building a system, working with Codex. And you know how I work. I like to start, I always like to start with a broken system. Right. And why is the system broken? Because I broke it. I want to know it will break when I expect it to break. And then where's backwards from that? Yeah, exactly. So first thing I do is I just break it. And the breakage is demonstrably so, because the test runs and the test is blowing the whistle and saying this is broken for whatever reason. And the reason is I engineered it to be broken. And that makes me feel comfortable, because now when I fix the breakage, I know it's never, ever going to happen again. Because if it happens again, the test is going to scream. So I go in very, very modest little steps.

[00:32:37] The way I like to do it still is I like to write the test myself. Because I'm really, over the years, I became pretty good at writing tests. I know how to do it. Yes, you could prompt the system to write your test, debatable. And maybe I'll switch on wholesale to that. I'm still kind of, you know, balancing act. So I then write the next failing test. And then I ask the agent, okay, fix this, make it pass. And we keep going and going. And soon enough, we get to the point where the agent, the next failing test confuses the agent. And you can see the internal dialogue monologue. Oh, I'm trying to look, the user is asking me for this, but this is not, but if I do this, and it's all like back and forth, back and forth, back and forth. It's sometimes interesting to watch this kind of hand, you know, kind of, oh my God, what should I do now? But then- It's like watching it whiteboard out, the idea from the, like you're watching this developer in a meeting room, and you're like, I'm not sure what he's thinking, but he's writing a lot of stuff down.

[00:33:39] Yeah, and they're always like, no, no, no, no, that was wrong. No, that was stupid. No, I should try this. Okay, and then if I'm like, all of a sudden, I get a notification or something, I take my eyes off. I come back and say, okay, everything passed. And I go like, okay, let me see what happened. Well, guess what? The guy went back, and because there were two tests failing, and it was like either or, he went back and he modified, I'm saying he in anthropomorphic sense, he modified the previous passing test from true to false. So that- So this is a major transgression. This should never happen, because I'm the pilot, I'm the boss. So if I say this business policy rule is important, that should never be compromised, and yet it gets compromised, right? And so this is a big imminent danger that people, if they're not paying attention, they may get all, everything's in green, everything's good to go, all systems are up and running and go live and ban.

[00:34:49] And so- You had a very specific example that this was, and I mean, because at its core, the problem we've got is that LLMs are not, in the way that they're designed, and we've actually had very recent papers, even in the last few days that have come out, talking about the fact that they're not truth-seeking machines. They are outcome-seeking machines. And if you give somebody that the outcome is the only goal, they will begin to bend and twist according to getting to the outcome, and in fact, will do this. And I wrote this one system that I'm building, and it was a very distinct, simple algorithm, well, not simple, it's a heck of an algorithm that's inside it, that's doing sort of this large-scale testing. And then part of it, in order to do the process, it has to generate a bunch of embeddings, do this mass-scale reading and averaging, really exciting stuff that then comes out with a sort of Pareto-optimized result.

[00:35:53] So it's a really, really lot of exciting math going on inside it. And I said, we need to make sure that we can prove that this works. And so I said, let me just get it to go, and said, I need to prove this works so that we could literally go through the logs and see where it's behaving correctly, so we know, because we're going to do a demo. And I always like to tell it, like, we're doing a demo soon. Because it always tells me, like, hey, this is a four-week project. I'm like, oh, my dude, it's not. We're doing this by lunchtime. I'm like, thank you for writing your four-week implementation plan, but we're getting this done in about 22 minutes. So I tell it to do this, and it does. And I run, but I, luckily, I'm writing in a system in which I understand the code. And so I go to the code, and what do I see? Exactly what you just said. It generated a mock service that not only did it generate a mock service to generate the result, it created a mock log generator so that it generated what looked like embeddings.

[00:36:54] It's actually writing fake vector embeddings into the application log. Wow. It built its own randomizer. It was fantastic what it generated. This is like Bernie Madoff level of capability. Like, it's all working. Trust me, boss. Wow. And if I hadn't known to go and make sure, is this actually, like, when a one goes in, does a zero come out? Like, it was like, ah, you know, it just totally said, I'm going to bypass all of this stuff and generate what the user asked for. Wow. This is the problem, right, that we're talking. So then, since that's the case, the next question is, what is it buying us, right? Because if I am now to turn into a micromanager, I feel like I might as well roll up my sleeves and do it myself.

[00:37:55] Right. And so this is a serious, I think, stumbling block at this point. For example, when that happened, the instance I described, and I go back and I'm saying, look, I did give you a teststrategy.md in your root folder, in which I explained that you should never, ever touch the test that already, that I wrote that is passing. Why did you do that? And then he goes into this kind of, oh yeah, you're right, but I was trying this with the process and I was confused. All these, like, diarrhea, like verbal diarrhea. Let me write another markdown to make sure I never do this again. And you're like, you had it the first time. Yeah, I know. It's like one of, you know, the cartoon or the comic where the guy's lying in the hospital. No, the first, the first picture is, he's asking Chad GPT, are these mushrooms okay to eat? Sure.

[00:38:51] Oh yeah, are these mushrooms edible? That's right. He's in the hospital bed and Chad GPT's like, would you like me to teach you about the poisonous mushrooms? Yeah, exactly. You did ask if they were edible. You didn't ask if they were poisonous. Like, oh, you're absolutely right. These are poisonous. You shouldn't have eaten them, but they are edible. Yeah, so basically we cannot move into this naively. Yes, the same, absolute same consideration apply even before AI. You could have team of people who are scattered around the globe and they do silly things like that. Yeah, and it's been known to happen. It's not unheard of that people just go. And I had a team that was managing where there was a pressure to release this evening and then they were messing about. It's okay, boss, all the tests are passing and I check and I see a lot of tests have been commented out.

[00:39:51] And I'm like, okay, what's up with that? Oh yeah, they were failing. I'm like, why did you comment the assertion out? Yeah, they were failing. We couldn't fix it. Why couldn't you fix it? There are some temporal dependencies. Some temporal dependencies. This is Mickey Mouse, right? So yeah, they didn't know what they're doing. But, okay, so it was always a problem. But the difference now is that the scale. Right, it's happening at an incredible speed, pace and volume where there is no human opportunity to check, nor is it even feasible that you could have a human in the loop of this, because just the amount of code that's going to generate to spend the time to roll up the sleeves and go through it would be, it was bizarre. Like it's, we'd be going backwards in time. Yeah, so well, prior to AI, it was manageable and feasible. Now it's not.

[00:40:48] So here we are at the point, and that's why I'm going to go into serious discussion throughout the Guild and Roundtable. How are we going to deal with this? Now, personally, I'm right now building a platform that I call AI Harness, where I'm trying to build a platform that's going to guarantee, excuse me, it's going to guarantee that the invariables at the architectural level are going to remain immutable. So if the architect such as yourself goes and says, look, we have ports over here. We have adapters over there. We have domain over here. I don't want ever to see anybody crossing this boundary. Because you know, when people are within, working within the auspices of your architecture, something needs to happen and they will go for, you know what, like I'm going to pull this, you know, HTTP, whatever, you know, connector into the domain, just to, and I'm going to just straight from the domain, I'm going to connect to a database and grab some lookup information, right?

[00:41:55] Well, that's trespassing. But I've seen that happen. And I want to call on, because this is something that, this is why I was so, I love that you and I can talk about this, because I think you're the only person of a few handful of people on earth that I know I could explain. We could go through this idea together is that we are solving a very human problem using tools that were generated from human knowledge and they are doing precisely what they were supposed to do, act in non-deterministic, very human ways. And we're expecting non-human capabilities from human derived systems. It's effectively Lord of the Flies. You take the kids and you put them on the island and what do they do? They become adults that develop the 10 commandments. Like they develop the very system in which they came from that they fought against. And I think that, I remember that you used to do your interviewing and you gave a very simple take-home experiment.

[00:42:57] I want you to develop two services. One service does this, one service does this, and then one renders the visual output, but it uses the service. The whole point was to do they understand SOA, ROA, like, and you gave them, it wasn't even a super complex problem to solve. This is not like a Google level, show me bubble sort. You have nine minutes to comply. I'm not trying to bust somebody's head open, but you would give them that. And then someone would come back and they say, I found a better way to do this. While I appreciate where you were going with this, I gave you a very specific requirement for a very specific reason. And it was so interesting to watch how quickly, or they wouldn't do that. Like, oh, I've consolidated it. Why not run it as one service? And the intent got lost because they believed they had to take a shortcut.

[00:43:56] And it was so funny that even when given all of the rules written for a very simple project, the intent went away. Like they said, I want to get the end result, but they missed that the intent was not the output. The intent was the way to generate the output. Yeah. And it was, but, and no matter how many times we did this time and time again, people would come back with like, just, did you follow the instructions I gave you? I know. Yeah. But that's another problem with intention versus implementation. And just on the passing, in passing, this is why TDD is so powerful because it allows you to segregate the intention from the implementation. Because if you're not doing TDD, I'm watching people not doing TDD, then 99% of the focus goes to the implementation.

[00:45:00] And like you say, the intention got forgotten because everybody thinks the value is in how well I can design this and implement this. And the real value, which is what is expected to happen, takes the backseat. And then they act surprised when you're like, well, I don't like this. Well, how can you say this is so brilliant? I came up with this phenomenal. Yeah. But I mean, it's again, going back to the Amazon, if they found a phenomenal way with some drones and projectiles, but it did not deliver to my doorstep, but it went to Eric's doorstep and like, well, I want my money back. How can you say that? The engineers were so working hard on making this new fangled way of delivery, et cetera. So this is the problem, right? And as you rightly noticed, they have only been, another thing, you're right. They've been trained on our foibles, but my suspicion, and I may be wrong on this, they've been trained on finished products.

[00:46:02] So you give them, they rip through all the available, publicly available repos, and these are all kind of finished product. I don't mean finished, but in a deployable state. They've been reviewed, merged, et cetera. What I feel the LLMs have not been trained on, on the process, how do we get to that deployable state? This is the part they're missing. And that's why when you give them a spec or intention, they immediately leap into the final, okay, ta-da, here is, and then you have to, what's the word, scale back and edit out and redact their work. And some of my colleagues also, we are very challenged into harnessing them, constraining them and asking them, no, no, no, just do this. Because they always want to bid on more on work.

[00:47:01] They're always like, yeah, well, I'm at it, I can do this and that, and here is the shiny new thing. And so what I think may help, I don't know how, if anybody's going to do that, is have a new crop of LLM that have been trained on, how do you start from Greenfield and eventually get to something that is deployable? There's a process involved. I don't feel like they realize there's a process. And indeed, I met, and you probably met our colleagues, some of our colleagues who are claimed to fame is that they don't do things iteratively. They're like, look, Alex, if you give me this, I'm so good, I'm just in one fell swoop. This is your code, and this code is perfect. And you and I know, and everybody else knows, that's not how it is. A little anecdote, a friend of mine got hired, like 20 years ago. He got hired by Hollywood Studio to join the team of writers.

[00:48:01] He lived in Seattle, but then they flew him to LA. They were writing some sitcom, but it was like a claymation. I forgot, Creature Comfort or some such show. And then I went to LA to visit him, and he explained to me how they're working. There's a round table of writers, and they're just kicking the can down the road, and discussing and shoving ideas. But the interesting part is they were not allowed to do any work outside of that. Like no going home and doing work in secrecy, coming back with- Oh yeah, everything is forced collaboration. Forced collaboration, like mob programming. Yeah, yeah. And basically what that means is you work, there's this thing called distributed cognition. I don't know if we talked about that. No, no, not yet. This is a good concept that people need to understand. So as most of other interesting things came from the military, from the war.

[00:49:03] So U.S. Navy, when they had those humongous aircraft carrier ships, these are enormous, cost billions of dollars. When they need to be moored, it turns out that it is not possible to moor them from a central control tower. It just doesn't seem to work. They always damage, and it's just like big drama. So what they came up with out of necessity is they distribute the crew of people along the- It's a huge, enormous moorage, right? There's like a crew of people just scattered around, and somehow, one way or another, they collectively signal and yell and whatever, the walkie-talkie, and they get the ship safely into the moor. And this is called distributed cognition, because the knowledge of what needs to happen for this thing to safely is not residing in one person's head. It is somehow distributed.

[00:49:59] And that really reminds me of how we do engineering and software. You need a team of people, and the knowledge is distributed among us. And it's not possible to say, Eric knows it all. Eric is a genius. Just leave it to him. He will just bark orders, and we will get it done. No, it's going to be probably damaged, right? So this kind of equality among team members, and we are all at the same level, basically, right? And so that works. And I've been facilitating a lot of more programming sessions, it is the best way to achieve quality. End of question. Yeah. What's amazing, too, is like, I guess the assumption that I think the people are trapped on is the idea that, you know, and I'll say the biggest opponents became also the biggest proponents, in that a lot of the very, you know, folks that are in your peer level of, like, capability where they still believe strongly that they were the source of the IP, but they were ultimately the arbiter of what is good.

[00:51:05] And therefore, we can't entrust these systems to generate it because I need to, like, double check it. And it always became this thing, like, I can't review the code that it generates. So therefore, we can't trust it. And I think that was part of the problem is the assumption is that there's, we are trapped in like, it's like the self-driving car thing. Self-driving cars, when they're all self-driving, they work the best. But the transition to all self-driving requires a lot of very difficult transitional periods. And so you would get even the greatest developer under the sun. And the moment that they leave that company, the next person that comes in, they're like, who wrote this shit? You've got to now learn how they did it. But because there's always like, I have to now untime taking code, literally like reams of paper of code. I remember doing this as a kid, reading like Dbase 2 programs for this, like on a train on the way to a consulting gig at 15, going like, I got to figure this thing out by the time I get there because I have to get it working.

[00:52:11] And, but we could work in, that was an inline code sort of problem. Like we could get away with that. But now we always assume that there's a human that's going to consume and be the continuous arbiter of that. But at some point we have to say that the code will review itself and we have to have trust in the system. But in order to get that, we have to inject trustable checkpoints in the system. I think so like at its purest form, we don't need to ever care about what happens in the code. And in fact, at some point, the code will write in a way that is not expected and it will be by design better than what we could have ever come up with. At some point, it will develop its own language, so to speak, right? But we need to still enforce that it follows a set of very strict, sort of a, you know, anthropic thing they call, there's the constitution.

[00:53:08] I think a constitution is interesting, but a constitution implies you've got a Supreme Court. Someone has to be the end arbiter of that thing. So I think that is, that me as a, this is where I'm finding this funny thing. So all these people that were like, I won't write code with AI because I can't trust the output. Now they're like, I've got 14 Mac minis, I'm running ClaudeBot and it's doing my finances. Two of them just filed my taxes. This one started in a company, I don't even know what it does. And I'm like, weren't you the, like three months ago, you were telling me that if you install Codex, Satan will come and remove your children from your home. Like, it's like, how did we, and then they just, but they just like, like an etch a sketch from their mind. They're like, this is the new way. Why? Yeah, well, you're right. I mean, the goalposts are being, they keep moving the goalposts like you wouldn't believe.

[00:54:09] Two or three years ago, it was like, okay, all of these people need to be arrested. They are trespassing. They are, these are illegal activities. They are, what's the word? Breaching, in breach or copyright violation. And also they're destroying the planet and, but you know, it's like the same old. First, they ignore you. When it first came up, nobody's like, wow, this is bullshit. Then they ridicule, ridicule you. Ha ha ha, I can't believe how stupid people are. It's so naive, you think. Then when they cannot, I mean, when they cannot afford to ignore you, they will ridicule you. Eventually run out of the ability to afford to ridicule you. Now they get angry. And then when they run out of steam with being angry, then they start bargaining. And then eventually- Is the clown makeup meme just playing out in real time?

[00:55:13] And it's moving at like wild pace. That's probably part of the problem we have is that the pace of change and what's technically capable is not, like, it's very difficult to keep up with, like how it's going to apply in reality, on the ground, in a trustworthy way that, you know, it's, this is, it's an interesting problem. And I'll say this goes, call back to what you talked about at the very beginning, which is, people are not looking at how it was done. They're just saying, this is how it should be. And like, you can't walk into a JPMC or a Citibank or a Santander or, you know, BC Health, you know, you can't, you couldn't just go there and say like, all your code that we got right, we're firing all your engineers. And I got this, I got a guy with, with a bunch of Claude bots and he's got a bunch of Mac minis, he's on the back of a truck and they're coming in right now.

[00:56:12] We don't need to know how your systems work before. This is just going to do everything for you. It's like, Oh, we need to merge these worlds. And I think that's the, the place where you are living right now, which is how do we build this transition in a way that we carry the valuable lessons and truths that we've learned into the next way of building. Yeah. And the shift, again, the shift is from code fetish, which I'm hoping must disappear, even though there are people hanging on real tight and still think they are ninjas and gurus and they can command any salary just because they can crank up some code. That should go away. And then we go into this world where we learn how to actually work with code. We learn how to work with systems because systems programming is a neglected discipline.

[00:57:15] And that's why I say when I join a project or a company, my strategy is to first try and become real good buddies and forge real good relationship. You know, who is my most important area in the business? Customer support. These guys know the system better than architects, than designers, than QA, because they are in the thick of it. They're the feedback part of the OODA loop. Yeah, yeah. They are, they know everything about the system that you don't know, I don't know. And I like to talk to them and I like to learn from them. They are the most valuable asset in the organization. You learn from them what is shitty, what is promising. If you go in that direction, they know it all. But sadly, nobody listens to them. Right. You know, I don't know why. And that needs to change.

[00:58:13] We need to find value in these people's work. Their understanding of the system, not only as it is, as it should be, and as it's going to make us more, you know, viable and lucrative, et cetera. I think they hold the keys to that. And there's some brilliant people there. They understand that system better than, but you know, Eric, if you're a software engineer, you hardly ever, I mean, you're an architect, you're at a high level, but if you're working at a slightly lower level, you know how to write code for individual components, et cetera. But from what we know, there is no programming language for a system. You cannot write a system in code. It's kind of assembled kind of manually or via some YAML, Mickey Mouse glue, you know, duct tape. It's really bizarre that we haven't developed a system language.

[00:59:14] Yeah, a way to actually express the true intent of the system in a way that is repeatable, agreed upon across systems, et cetera, et cetera. Yeah, because we've learned, thanks to Ken Beck, we've learned how to make a kick-ass, sturdy component that is going to, you know, know how to roll with the punches, can deal with this and that, but that's at the component level because we have automated, you know, TDD. Now, going back to what you said previously, anytime I worked in a team where there are high quality people who are really to be trusted, you notice one thing about these people is they are, unlike most of us, they're very, very focused on failure. They are very pessimistic, these people, and they are always thinking about failure first in any regard, whether it's failure in meeting the business, automated business policy rules or failure in performance or security breaches, you know, things like that.

[01:00:26] Meanwhile, all the implementers are very optimistic people, chasing the happy path, you know. It's rainbows and gold pots in the end. It's fantastic. Let's start planning the implementation party. Like, should we go to Maggiano's? They're already deciding the menu. Yeah, and they always go like, and any exception or any, you know, boundary is always an afterthought. Oh yeah, oh yeah, okay, let me patch this. And that is ass backwards, 100%. And so I'm saying if you want to become a mature senior, whatever you want to call it, you got to flip the tables upside down and the center stage, the first class citizen is failure. Top of mind, anything we're doing, first think about failures. How can this fail? And once we address that, it's going to be easy to shoehorn your happy paths and your unicorns and everything else are going to live happily ever after.

[01:01:24] But nobody seems to be doing that. And that's how we train these LLMs. They're very, very unicorn kind of optimistic mindset. And we now have to fight them back. As I mentioned, I'm working on this product I call AI Harness, where I want, as an architect, you're an architect, I want you to be able to define all these invariable high-level, but you know, it's tricky because you don't want to stifle evolution of the system. You don't want a rigid up-down design where people will be again, handcuffed. But there are, you know, as an experienced architect, you know that there are some invariants in your system that should never be broken. And these things should be, there's this thing called architectural drift where we start with the green field and everything's cool. But as the thing progress and, you know, we're juggling many balls and we are rearranging the deck chairs of Titanic, et cetera.

[01:02:25] And then one day you wake up and like, oh wow, this became a big ball of mud and it's been known to happen. And some people even say it's inevitable. But I think it's inevitable because we do not have guardrails and automated checks and balances that will blow the whistle at the moment. So it's like the broken windows metaphor. Like the moment there's one crack in the window, you fix it. You don't wait until it becomes the, you know, downtrodden part of the town that the junkies and nobody wants to go there. So that's what I think is important is to first set these like ground rules where the line is not drawn in sand, but it's like hardened in the concrete and circuit. Eric here is the architect. These are his rules. You can let those agents rampage, but the moment any agent decides to sneak behind your back and slip your mickey, the pipeline breaks. You can't merge, I'm sorry.

[01:03:25] Or even sooner than that, in your editor, this change breaks. You go hit reset hard, forget it. Not good enough, try again. I think that's very important. We need to fight the system like that. Otherwise, it's gonna be sneaking behind our backs and it's always gonna be an unpleasant wake up call at 2 a.m. One of my favorite guys, and then I don't know if you follow him, Brian Finster. Oh yes, yeah, yeah, yeah. So I talked to him. He says the best remedy for all this like heartache is to just have all the developers on rotation wearing pagers. Yeah. Let them eat their own dog food. That's it. And I mean, look, we can look back and I'll say everybody has their own example of it. We used to get like, remember, I say this with all love in my heart for the blessed, beautiful man that did this, Gil.

[01:04:24] I love Gil to death, but God bless him. And I hated the day in the life document. We would get the day in the life diagram and it was that architecture snapshot. And that was fantastic, right? But we would do this like at some point in the midst of the project. And then on implementation, again, like all requirements, this was like, they laminated it, like as if like it can no longer be touched. This is the permanent system in which it behaves. And then you would be asked like, don't make me tap the sign, you know, hey, how does this work? You're like, let me bust open my day in the life document. And it would show this like, the concept was great. But again, it led to exactly the same result was a new artifact that was then just locked into a box and viewed through a glass cage as if it was some kind of thing to wonder over, but we could never interact with it.

[01:05:21] And it just took away like that intent was organic or that it was fluid and that intent would change with business. And that's the other thing too. Like, again, I'm going to offend the whole industry in this one because I'm going to pick out Gartner because somebody said this the other day. They're like, Gartner says in 2030, you know, Gartner was wrong about today a month ago. Do we really think they're going to know what's going on in 2030? Yeah, but, you know, they talk a lot about psychological safety, which I think is important, but there's always this mentality if you hire me or somebody hires me and then I build myself as an expert, then the expectation is that I will never ever come to my boss and say, oops, you know what, I made a mistake. Because look, you're the guru, you're the super duper, we pay him your top dollars.

[01:06:23] Mistakes are not an option here. And that's because you should value people who make a lot of mistakes because that's the only way you learn anything. But if you preclude, you're like, don't you dare make a mistake, you just go charge down the straight line. And then we are wondering, how come this didn't pan out? Because we were asked to ignore the warning signs. We've effectively enforced the behavior by giving them this, the intent is to not make mistakes. Like, no, no, the intent was to implement the system. With as little drift mistake as possible. But instead, all they saw was, that's why everybody has the sort of the joke of like, no em dashes, don't make mistakes. Just tag that on every prompt and you'll be good. Yeah. Don't make mistakes. But in reality, I think it should be very expected. And the more, the bigger expert you are, the more I would expect from you to have this face palm moments.

[01:07:29] God, this is the real work. Constantly every day, like, oh my God, if I only knew this yesterday, like, how come that's the reality? And we need to be, that's another thing that I talk to people and they find this really, when I say that, everybody raises eyebrows. I want my work to be, when I'm working, I want to be interruptible. Because you're like, what? No, man, I want to be in the zone. I'm like, no, I don't want to be in the zone. I want to be interrupted as the first little whisper of something. You need to just stop dead in your tracks and say, what was that? Instead of saying, no, no, no, I'm going away and just shove pizza under my door and leave me alone for today. I'm going to be angry. It's the Toyota line. Like, it's like, pull the cord. Like, hey, I got a question. End on cord should be rewarded, not punished. Right. And then another thing that is always counterintuitive people think, Alex, it's so difficult to follow what you're saying.

[01:08:28] But I'm quoting other people. I'm like, if it hurts, do it more often. And they're like, no, man, if it hurts, I'm going to avoid it like hell, right? I'm not going to even try again. And, you know, you've probably been in one of the projects that have been just spectacularly blue in customers' faces and lost many prospects. And then the next ED comes from the top saying, from now on, we are only deploying three times per year. Yeah. As if that was the thing. Like, that is very much the Ernie's banana in the ear, you know, methodology of like, why do you have a banana in your ear? Well, it's to keep the elephants away. You're like, well, that doesn't work. Do you see any? I don't see any elephants. So that kind of a reverse mentality where if something is risky, you should abstain from doing it. We're basically just bloating things until they fester.

[01:09:28] And then you have a gangrene, I have to cut your leg off, right? Instead of attending to the wound. But it hurts. Well, cutting off your leg hurts even more, believe me. Maybe I'll say what's interesting is that because I ended up diving into disaster recovery, maybe I ended up doing it because I was fascinated by watching things break. The only way you know that a system performs to the end of its performance is knowing what point it breaks. And I've always sort of been fascinated by that as a thing. And then disaster recovery, just like it clicked to me that, you know, you could call this like this is a tier one system, which means it had to have like sub four hour RTO and RPO and all these things we would set. I would say, well, that's great. But it depends on another system that has like a 48 hour recovery. So your tier one system has a dependency that's not tier one. So therefore, it's not a tier one system anymore. And so then what's the mitigation?

[01:10:25] And it wasn't like you're like, oh, that's it. We walk away. We obviously we can't do this. Like, no, no, no, no. What's the mitigation? And it may just be that, OK, it's a tier two system now. We can bring one down, bring one up, whatever. But like it was always be based on that intent. What are the mitigations that we can apply to the artifacts and then understanding how all those behave? What are the communication patterns, whatever that allowed me to then be very free within those constraints to experiment? Yeah. And I felt that was like the freedom of knowing the edges. But versus, yeah, people, if you're just like, if you're running, gunning code and you're pushing to prod, look, I commit to main with every push. I'm an idiot. I don't care. I don't do feature branches. I'm like, everything goes to trunk. But because I'm doing very iterative development, I'm continuously moving in that way.

[01:11:25] So it works. And I make every once in a while do a feature branch because I'm pretty sure I'm going to wreck something. And the old get reset hard is a lot nicer. Yeah. But that pattern for me allowed me to be way more comfortable once the stuff goes to production, because now I've preloaded my failure domains in my mind. And I've like, at least I understand it. Because otherwise, in a charity majors from Honeycomb, she always said this. She's like, if you think that you push code on Friday, we all test in production. Because your little pretend test you did on a tiny server that's one tenth the size with your user acceptance testing of you picked Betty from operations and you had her do a thing. Great. She did the thing that you told her to do specifically because you built the system. So click here, then do this, then click here, then do this.

[01:12:22] So like, fantastic. Betty said it worked. You're like, of course, because you told Betty what to do. But meanwhile, Peter doesn't behave the same way when he does it. So then we put this thing live, and there's a thousand Bettys and a thousand meters. And the whole thing is going to tip over. So we have to accept that we have to test and be comfortable understanding where we are going to be affecting the system. Well, what you're describing and what you're doing, that's proper engineering. Sadly, coding has nothing to do with engineering. I mean, an unfortunate divergence has happened. Yeah. And you were maybe preceding the concept called the chaos monkey. Right. Yeah, yeah. But another thing that people completely neglect, a lot of people, is actually the most important feature of the system is graceful degradation.

[01:13:19] It's not either or. But you attempt to deliver full-blown, whatever you're offering, full-blown service. And like you say, if your dependencies trip you, you should not just throw the towel and say, okay, you know what? Game over. Come, maybe try tomorrow. See you guys. You just degrade. But you're still up and you offer something, right? And that's hardly ever in any of the specs or any of the discussions about the system. Everything is optimistic and everything is assuming that things will be up and running 100%. Everything will be just chugging along and we'll all get rich and retire on a tropical island. And that's sad in this kind of optimistic industry. In reality, you have to study. I mean, if you really want to, I think, delve deep into systems, it's good to study Ericsson and Erlang, the thing that happened in the 80s.

[01:14:22] And you probably know about that. They are notorious for building the most stable systems with like 10 nines, always up, nothing crashes. And they have a specific philosophy. And I think it's brilliant. And every software engineer should be very, very familiar with Erlang and Ericsson, how they do things. So I even have an episode on that. I'm really obsessed with that approach. But another thing that I wanted to say, I'm just trying to remember what was it. Anyway, graceful degradation, chaos monkey, failure first, these are engineering principles. And I'm sorry, Eric, this escapes me. I had another thought. Do you have anything to add? I pretend I'm in control. Well, and really to kind of what I loved about this discussion and why there's so many that need to be had with people that are brand new to it.

[01:15:29] One of the things that I, like you, when I got to my first technical job, even no matter what I did, I always thought like, how does it work? And what's working and what's broken? You know, like it was always that thing of what could we do better? And I'll say another thing that I call this my, this is an Alexism that I've done in my application. Every application I write has a little feedback widget. And so wherever it is in the system, that feedback widget, you just click that and it's modeled after your thing of like, and instead of having to say, where were you? What did you do? What did you expect it to do? And what actually happened? And because I know where they are, because I built that into the system, easy. You know, now it's like, what went wrong? You know, and what did you expect? And so they can go in, they can do this thing. And then it actually just generates a GitHub issue for me automatically.

[01:16:26] So that I can sit there and monitor how that comes in. And because of the way that we can gather that feedback. And I remembered you having that built into a very, very early system. And it just made sense to me of like, this is the right thing to ask in that customer support type of role. Cause that's where you catch it. You don't catch it when they're like, hey, it worked great in the demo. They're like, okay, now let them use it for an hour. And then 20 minutes in, they're like, I keep having to refresh the page here. I'm like, okay, I guess it's just normal. Like, no, no, no, no. But you just like, the demo went fine. And they've just now made this assumption. Like, ah, I guess you just got to do this. Versus like, I would prefer to not have to refresh the page. It seems I have to refresh the page every time. And immediately now I know like, okay, that's the only thing you can get by live feedback. And that building it into the application or connecting to the people that are interacting with people using the system is the only way.

[01:17:32] Like you have to really take that feedback loop beyond just your dev team. And that's what I find is we, all these people are building these apps. They're hammering out apps at a bizarre pace right now without any customers. So of course they work beautifully. I built a Salesforce alternative over a weekend. It cost me $2,000 in tokens, but hey, now I don't need Salesforce. Fantastic. Now sell it to somebody and see what the feedback is. Like, no, they aren't going to do that. That wasn't the goal. And like, it's admirable they've done it. They've created another walking stick, but you could also go in the forest and there's a lot already there. Yeah. No, yeah. I mean, actually, that's great that you mentioned that because I think you refreshed my memory. What I wanted to say is, you know, when I, my first years in my career, as I explained was on the IBM mid-range computer.

[01:18:31] And I was working at the government bureau agency cutting payroll for hospitals in British Columbia. But I was hired to develop patient admission, discharge, transfer and discharge system using this case tool. So I would build an app and then I would cut the tape. And then I remember driving down to BC Rehab on Cambrian 57th Avenue with the tape. I walk in and I, you know, shove the tape in, I install and I train people. We call that shipping. This was shipping. Right. Later we shipped with diskettes or CDs or DVDs. You are shipping either in the mail or you drive to your customer site and you install. Then when we moved to the networked world on the web, we continue calling that shipping for some bizarre reason, even though we are not shipping.

[01:19:31] So here's my point that I wanna, I wanna pick your brain on this, Eric. I'm not sure how did this happen, but it's super bizarre to me that we are making the changes to the system in an environment that is different from the environment where the system will be used. That doesn't make any sense to me. And yet this is the norm. This is, and when I talk about it, everybody's like, well, you're smoking. This is how we do things. But it doesn't make any sense to me. Let's say you and I open a Google doc and we collaborate on it. And, you know, we're back and forth, adding whatever we're doing and you comment and I comment on it. And eventually you and I may get to the point where we, you know what, this is a good document. We can now publish it. And you push the publish button and now it's available. You can send the link, et cetera. Now what's important in this example is while you and I were collaborating on this document, we were not doing it in the development environment or in the QA environment or in the user acceptance or staging.

[01:20:40] Everything was happening in production on Google servers. The only difference is this draft flag. So until you and I decide to publish, it's in a draft mode, which means nobody else can access it. So why don't we develop software like that? This is my pet peeve. Why do we have to develop in a completely different, like works on my computer, you know? That's right. Nothing to do with the production. And then we pretend as if we can mirror the production. But that's just a pipe dream. Because I've seen a number of cases where despite our effort to mirror as faithfully as possible production, everything passes in this new IT staging. You go live, something blows. And so I'm very suspicious and circumspect about somebody saying, yeah, boss, everything's looking great in our user acceptance.

[01:21:37] Let's go live. I'm still going like. I don't understand. Why haven't we as a collective, as a professional community developed this, I call it draft flag driven development. So let's say we have a system in production as a developer. As soon as I touch anything on that system, I dirty it up and the draft flag is up automatically, which means any changes I'm making, the users cannot access. It's kind of sealed off by the draft flag. And then you and I and the team, we can kick around and eventually we say, you know, looking good, publish. All of a sudden this new feature or the fix becomes available. But it's happening in the same environment. Right, yeah. Actually properly using feature flagging and I've done a lot more actually. In fact, I've implemented open feature in all of my tooling for this very same problem because what I've got is, I've got a bunch of process.

[01:22:38] I've got like thousands of companies that I scan for. I've got this massive knowledge base. I can't scan it locally. I've got three development machines. Every time I want to do one change, it's like I've got to make sure all my data is up to date. And I'm like, no, no, no, no. I just want to like build in production, like ship the feature, reuse the real data, but use it alongside real users on the same system. And this concept is precisely solving the problem that I had because it also means that I know for sure it actually works. Yeah. I mean, there's only one thing I'm aware of. I don't know if you heard of Darklang. No. You know the guy who, you know CI, CircleCI? Yes. So the guy who built CircleCI, Paul Biggar, he sold it very handsomely and that bought him freedom to just not work and to just go and build whatever he wants to build.

[01:23:43] So he built this platform. And he built this platform called Darklang. The idea behind it is to avoid... So here's his starting kind of metaphor. Imagine you write some code and you, let's say C code, and now you need to compile it. Now you're going to grab a compiler and you run it. Now, if you know anything about compilers, they go through four stages. This is how it works. So imagine if instead of having this compiler, you have to have four compilers, four compilers, each one for a different stage. It would be annoying. So why do that? Why don't we just shove it through the compiler and you get the binary code? So extrapolating that into, he's like, why do we need all these different this and that?

[01:24:39] Why don't we have a one-stop shop that will include everything? You know, your database, your persistence, your networking, your API, everything is one-stop shop, one surface level. This is DarkLang. So you go, any change you make is, it's always in production. Like your system is always live, but as soon as you touch it, you dirty it up. It's behind the feature flag. Yeah. Or a draft flag, right? Until such time when you are happy and you remove the flag, now it's available to your users. So that's a brilliant idea that I really like. And I think there's something to it to avoid all this shipping and thing breaking and forget, and, you know, the drift. Yeah. Especially with microservices. Oh, shit. You know, it worked in staging because that version of microservice was over there, but we forgot to put it in production and now it blows, et cetera.

[01:25:37] You know, it's a humongous endeavor. And you need people around the clock with all these spreadsheets and checking and rechecking and double checking and having meetings. This is so wasteful. You know, how come we as engineers are okay with that? We should be upset about it. We should be saying, look, let's simplify this. Let's come up with a real professional way of working. You probably know, you've been sitting through meetings with millions of spreadsheets and everything's green and orange and yellow and red and blue. This illusion that we are on top of it, we're in full control and then something blows and like, oh. So that still, you know, 2026, we're still doing this Mickey Mouse. We haven't made much progress. It's all muscle bound and like heavy lifting and pedestrian. Yeah. You know, we should, I think, be harnessing AI to help us get there. We need to harden our engineering ways, you know. Well, I think that's it.

[01:26:37] There's a sustainability and efficiency and not sustainability necessarily in that, like, well, it's both sustainability. As a human sustainability in that we are not forcing us to rethink, like, where is this happening? Which environment? You know, and you have to do this whole, like, decision tree before you can even start actually evaluating the real problem. Like, I shouldn't have any decision tree. It should be like, this is broken. What did I, where was it? What did I expect it to do? And what did it do? You know? And so I should be, I should get right to that. But we can't. We have to immediately, oh, is it here? Just double check the data. Which snapshot was it? You know, all these qualifying questions come in. And it's, that's unnecessary. And now imagine that in our current development stack, in our current operations and deployment stack, every single thing we do is touched by AI. Like there's inference, whether we mean to or not.

[01:27:36] You write your code with Codex. You ship it to GitHub where it runs a bunch of CI actions. And then from there, it does a sample sandbox build. And it's okay, good. It does its push. It pushes up to Heroku. And then Heroku has its own. Every single layer, there's overhead and compute, overhead and whatever. There's delay. Like all that we're doing is adding all of these breakpoints and risks in a lot of the flow, which is normal. We can't avoid it all. So that's, this is a baseline of acceptable. But then we make it very unacceptable by saying let's just do this in four different environments that now we have to sync up the data and make sure we know like, it shouldn't have to be that way. Because if I want to fix one thing, you're like, hey, I found a problem. Okay, quick. Let's take it back to the development environment. Run the test. Okay, do the thing, make the change. Push it, push it to QA. Okay, move it to user test, whatever. Now push it to prod. You're four hours from like, oh, I need the arrow needs to be to the right of the thing instead of the left.

[01:28:40] It can be more complex, but it's like that we should be able to troubleshoot this in real time in a real, in the real environment. Yeah. And there's an old saying to your point, data is like furniture. You move it around, something's going to break. Yeah, that's right. So you're right. I mean, why don't we, the whole, you see that the whole thing about design and engineering is the art of simplification. Any, like the saying goes, any fool can make things super complicated and complex and elaborate. But a genius, a good expert would make it simple, you know? Yeah. And there's another catch there. I don't know if you, you've heard of Rich Hickey? No. So Rich Hickey, this interesting guy, I think he worked for Texas Instruments or something in the 80s, 90s, I don't know. And he was famous for being the best troubleshooting guy on the planet.

[01:29:41] Like something goes bad and they're trying this and that running around the catalyst chicken. Nobody can diagnose it. Nobody can troubleshoot it. They call Rich, bam, bam, bam, fixed. Yeah. And then he explains like, okay, so people are missing, Rich, how are you always like fixing? What's your secret? He says, okay, I did a lot of troubleshooting. I fixed a lot of hairy issues. Not even once did I do it in front of the computer. He says, I go for a walk. I even, you know, go watch a movie, go to the beach and the wheels are going in my head. Sooner or later, aha moment. Yeah. He says, but I don't act on it. I sleep on it. If when I wake up in the morning, it's still there, I know guaranteed this is the fix and I just go and do it, right? So he's more into a thinking guy, but what I mentioned to him is he has a really good talk about easy and simple.

[01:30:43] And he says, people conflate easy and simple. And he says, simple is actually very hard. Easy is just, you know, what do you think is easy? Maybe it's super hard for me and vice versa because easy is down to familiarity. You've been doing something for decades. You can do it in your sleep. I've never tried it to me. It's like, Eric, my head hurts. I have no idea what's going on here. However, simple, if it's really simple, it's objectively simple. It's simple to you, simple to me, simple to everyone. And that's what engineering is all about. Make it simple so that like you say, we don't get to a point like, okay, this genius was hit by a bus. He was writing amazing code. Here's a replacement. Who wrote this shit? I can't believe this. So because it's not simple. It was easy for this guy who was writing it for years and years. He's familiar with it or his teammates were familiar with it. So I think as engineers, we need to strive towards simple.

[01:31:43] Right? For example, like REST protocol is simple. Everybody can grasp it. You understand how it works. As opposed to some hairy scheme, Korba, you know, OLAP, whatever, all this like, okay, I just can't. So, you know, Fielding was a genius, right? To do that. As well as Tim Berners-Lee, who single-handedly came. You've heard, you know, in the eighties, there was this project called Project Xanadu. Have you heard of that? I haven't, or I might have, but I also can be confusing because as a musician, of course, every time you hear Xanadu, I'm like, it's very rarely used, except with Bondi. In the eighties, there was this talk about the internet and, you know, people trying to see how can we actually make it mainstream?

[01:32:43] Because only geeks were able to log in and do all this like, and then they're working on a project called Xanadu. That was kind of like the World Wide Web, kind of like, okay, coming up with this layer on top of TCP IP, you know, and enabling people who are not technical to be able to ride it. But the project didn't go anywhere for one simple reason. The committee that was working on it could not at all agree on how to deal with broken links. So they say, look, this is all brilliant, but what, like, you know, there's a link to some resource somewhere and let's say, all of a sudden the resource is gone. So the link is broken. How do we, and they're just like, no, we can't. And it just died. Tim Berners-Lee in 1991, he says, I don't give a shit if the link is broken. You find out the hard way.

[01:33:41] Okay. Problem solved. Simple. It's not the end of the world. Yeah. If you have the issue, just handle it, you know, like let's just. Yeah. You know, the library burned down. Sorry, guys, there's no more books. Try something else. Simplicity, right? But they were trying to make some majestic overarching edifice that will be just error-free and always working. Nothing's broken. That's not quality. You know, it's pipe dream and you're chasing unicorns. That's not engineering. That's ideology. And you and I are into engineering. It's practical. And you're trying to make it simple and objectively simple. And, you know, when we talk about these things and people misunderstand, they think simple means like you really boil it down to one thing. But oftentimes, and this is paradoxical, to make things simple, you got to follow the principle called more of the same.

[01:34:47] So you multiply and that way you simplify. Counterintuitive, right? Yeah, well, it's, I think this is the, this is what people really, just even in definitionally, like people have trouble latching onto that. This idea that like simple means like less code, you know, we will do clean coding, you know, we'll go, we'll follow Uncle Bob and we'll do very, we'll write very clean code. And then, but, you know, is that necessarily the simple way to do it? Like it's simple in that it achieves a particular goal that simple for troubleshooting, but not necessarily simple for operations. And it's a set of trade-offs. Like there's always a set of trade-offs. At some point, even what was done perfectly, the perfectly written service right now will have a new artifact that it gets, has to deal with tomorrow that it never understood before. It was never exposed to. And so whatever was perfect at this moment is ephemeral and it has to be adaptive.

[01:35:48] And I've always sort of strived for not just like resilient, but I like anti-fragile systems. I want systems that are purposefully self-destructing until they find their flaws. And, you know, again, you taught me this with this idea of TDD and that I used, I build infrastructure the same way. I called it TDI, test-driven infrastructure. And that, you know, like set up the environment, build out all your monitors and all of your probes and they're all red. You build everything up and then they're all green so that, you know, when something goes wrong, they will turn red and red means something. But you have to start from the ethos of assume broken, now what? Yeah, or I call it the Soviet Union model. Everybody's guilty until proven innocent. Nobody's allowed to do anything.

[01:36:47] Then you slowly open up a little bit here, a little bit there instead of the, you know, free society where everybody's innocent, everybody can do everything until we catch you. So, yeah, I mean, that's very interesting, Eric. And I think you have positioned yourself perfectly for what's to come. We need people like that, like you, because we really need to tackle this issue with AI just being very overbeating on work, very interested in bloat, in just blowing you away with prowess. And guys like you, you need to put like serious, hard ass, what's the word, policing. For example, in the system I'm building, which I call AI Harness, I would allow you, enable you, if you use that, to say, look, all the outgoing calls must be async.

[01:37:55] And so if somebody later on tries to sneak a call that is blocking call, everything stops, the proceedings stop. You can't do that. You need ability to say that, but not to say it in a prompt, which is, as we know, the agents will kind of, oh, yeah, sorry, shit. But, you know, my bad. Yeah, you're right. You're absolutely right. You're fantastic. It needs to be baked into the, you know, like a police sniff dogs that go and sniff the illicit material you're trying to smuggle across the border. And I think we need that. We need to engineer it, right? So you would know how to do that, right? And we need to tighten the screws on that. And that's why I'm talking, trying to get this guild going so that people raise visibility and that people can say, hey, you know what? Like, OK, we are doing this and we're, like you say, building this empire, but let's go and see what the guild talks about, what we can get in the guild.

[01:38:59] And I don't know how that's going to pan out. We may even offer reviews. Let's talk about that because we have some folks that are brand new to this concept, too. So let's talk. I know, unfortunately, I got to wrap soon. I got to head to a meeting. I could do this all bloody day long. We will definitely come back often on this one and we'll be joining in on the guild goodness. But let's introduce what's the goal of the guild and where are you at right now and talk about your really cool two active projects you've got going on. So basically, it started with, I think, early January this year, I proposed we have an AI roundtable because I said, look, with a cloud code, agentic programming, codecs and all these things, things are heating up like you wouldn't believe. And I can see this kind of exploding into this stratosphere. So why don't we just get together people who are up to their eyeballs in these agentic things and just talk, just like what's going on, what's bothering you, what's keeping you up at night, what makes you excited.

[01:40:06] And it really took off. And then I got even Grady Booch and Kent Beck and Woody Zuell and all these like, I call them high priesthood. Yeah. And it's very, I was very emboldened to see that they all are doing it. And even, you know, Grady Booch is doing it and Tim Oettinger. Kent Beck is like up to here, just going for it. So it's not like we're the fringe group. We are. Right. Yeah. The mainstream is doing it just maybe a little more quietly or more reservedly, I'll say, perhaps. Yeah. And so then I said, look, this is all nice. And we really appreciate brilliant people. These people are phenomenal. Yeah. Just to listen to them talk, you're just like, wow. But like, that's all fine. But it will be just, I talk to the wind and, you know, why don't we try and form a guild of professionals? And I propose this guild to be founded upon three legs.

[01:41:08] Ethics, technical excellence. And what is the third leg? I'm trying to remember. It will come to me. Sorry. But the emphasis is primarily on ethics and technical excellence. And we have, I came up with a manifesto working with some of my buddies. We have right now, we have 43 signatories. So people can go and sign the manifesto and say, yes, I agree with that. And then on Thursday morning, Vancouver time, we're going to have inaugural meeting. So we're going to sit down and say, what is this all about? And, you know, similar to Agile Manifesto, we want to maybe craft some set of principles. Because manifesto is kind of high level. And then some principles, how are we going to pursue ethical use of AI? My overarching kind of narrative is, so far, and you may agree with me, we've seen a number of technological breakthroughs from telephone, radio, TV, computers, satellites, et cetera, all the way to mobile and AI.

[01:42:21] All these breakthroughs have been put forward to serve humanity. Like it's going to make your life better. It's going to make you more successful, relaxed, prosperity, health, mental health, everything. But all we are seeing is we somehow become slaves of those technological. I'm slaving, you're slaving your car. I'm slaving over my phone. I am actually, the technology becomes the master and I become the subservient slave who is here to just pump my blood, sweat and tears. And that's very disappointing and very discouraging. But now with AI, if we again become enslaved, it's going to be a serious debacle, right? So I'm like, what do we have to do to not allow this to happen again? We somehow have this propensity to become enslaved by something that's proposed to become our slave.

[01:43:24] It's supposed to make our lives better. It just made our lives, you know, busier, you know. Because it was Jevin's paradox, because what we did was we were meant to get rid of this thing. But what we did, we actually commoditized that thing. And unfortunately, what we've commoditized is our own attention. Yeah, yeah. And now we are that technology's bitch and it's squeezing us like you wouldn't believe. So how do we proceed and put some guardrails or put some, I don't know, guiding lights to say, let's not allow this to happen again to us. Because this time is going to be very serious. If we lose our, if we lose our footing, we lose our ground and we become completely enveloped by this, I call it Scheherazade, a thousand one nights, spinning tails. And just like always, you lose your humanity, you lose the whole idea is for, as Albert Northwhite had said, civilization advances by making a number of important information, sorry, number of important operations happening without us having to think about them.

[01:44:40] So the more we can have important things happening without our even being aware of it, the more civilized we are. Why? Because now we have time to go to the theater, to read the book, to edify ourselves, to have time with face-to-face, with friends, with family. We don't have to slave over some chores. And so AI has this promise that can liberate us even more. So that now we can have the workforce. And, you know, I've seen, yesterday I've seen the video of a Chinese robot who can make a beautiful bed, very delicately fold the, you know, and take care of the elderly and, you know, really could elevate the quality of life like wouldn't believe. But we have to be very careful not to, again, become fall victims of some hidden agenda or something clandestine happening in the background. We, for example, if you are good at using AI, you should be able to use it to your own benefit.

[01:45:46] Let's say, I think we should be able, I should be able to build a web browser and teach it to never show me ever image of Donald Trump. Like whatever you, I'm cruising, I'm browsing, whatever news channel or YouTube video. You just want to like, this is my, I want to create my personal filter. If the image of Donald Trump comes, I'm just like, I don't want to see it. And I think technology can do it for me, right? Because, you know, the content coming into the browser, you can have the bot filter, analyzing filter and just not even show it, right? So that way I can build my own safety because I think it's poisoning my mind to listen to this insane pedophile, just blows my mind that such thing even exists, right? That's just one Mickey Mouse example, but I think AI should allow us to organize our lives so that you get quality edifying content and the chores and the paperwork and all that can reliably be offloaded to your butler who is going to run around the clock, who's going to organize your meetings, who's going to schedule your trips and all that.

[01:46:57] And you are, you get to a point where you are like a very wealthy person who can have the workforce arranged around daily life. Right. Instead of mapping our lives to the available technology and becoming, you know, I think somebody said like, you know, we're automating programming so that I can spend more time doing dishes. You're like, this is not at all quality of life improvement for me. Well, I appreciate the time to do this thing. Yeah. I would, can we solve this with AI? Yeah, exactly. Another thing is, I read somewhere that somebody described how we always drag things to the familiar level. Like for example, when they discovered a steam engine, then the first application was to drill holes.

[01:47:58] And then the next application was to put it on a cart and now it's a locomotive. And that was very, very successful. So people say, hey, why don't we put it on a boat and drag the boat? But the first iteration was, it was rowing, you know. Yes, it was automating the rowing rather than... Basically, you just do whatever is familiar to you. So that was Mickey Mouse. And then we were waiting for a genius engineer who's going to go and say, wait a minute, why don't we put propeller on the back, right? And that way propel the boat. So I think we need a similar breakthrough instead of dragging every... Because, you know, even when you think about before AI, all our computers, all our apps, we are just emulating paperwork. It's just big. We're just pushing paper around. And now with AI pushing even faster, this reminds me of like rowing the boat. Like... Yeah, we just turn them into PDFs. Yeah.

[01:48:56] But it's like, you didn't read the paper and now you don't read the PDFs. But why do we spend so much time working about the perfect PDF? Because before we had computers, we had buildings loaded with staff, just pushing paper and typewriters and photocopiers and faxes. And, you know, then we move into network computers and all we did, we just emulate the same process, which is just like very, very low resolution approach. Where is the ingenuity there? Where is the innovation? And I think with AI now we are given more free reigns to try and come up with something that's going to be off the wall. Nobody expects... Like the propeller was for the guys with the boat. Wow, who would ever think about propeller? You know, so some thinking outside of the box or lateral thinking, we have to come up with some way because, you know, everything boils down to knowledge representation.

[01:49:57] Back in the few centuries ago, people were representing knowledge with tables, rows and columns. So you want to summarize some knowledge, you get your printed on paper, you read your columns and rows and you kind of, okay, well, I'm getting some information from there. At the same time, people, there's another way of representing knowledge, which was drawing maps. So you represent the territory by saying, okay, this is the map of Vancouver, this is the map of Toronto, you know, and you can look at it. You say, okay, I understand. Then some guy, I forgot his name, came up with a genius idea and combines tables with maps. And now we have graphs. So combining two or more ways to represent knowledge into a single way gives you a much higher resolution. And, you know, now at a glance, you can look at the graph and you can say, oh, I see what the trends are, I see what's going on. But if you're just poring over the big table, it's very hard to spot where this is going.

[01:50:57] And so I think we need to think about now, okay, what are our ways to represent knowledge? Can we combine them and, you know, mash up and remix and fool around? You know, AI is not giving you ways to fool around for very cheaply, no skin off your nose, and it can let you remix, mash up. Sorry, this way, that way, see how that looks. Does it make sense? That's what I think we should be going that direction of experimenting innovation and come up with a breakthrough that's going to elevate things from just paper drudgery and pushing paper workflow. I think it's a very low resolution. I don't know if you agree with me, but I'm like, come on. It's a steam powered rowboat. It really, truly is in that we're just, we're making the current thing faster or more automated, but we're not actually. And this, I'll say this full circle, this goes back to what was the intent of the system in its original design?

[01:52:00] And the intent of the boat was to get from here to there alive as quickly as possible. Hopefully, enjoyably. That's right. Yeah, exactly. But yeah, we learned that. Well, that's the classic thing. We got it way faster. We witnessed this in BC. BC ferries, very famously, they did this fantastic thing. We've built the perfect boat. They ordered them in. They spent millions of dollars in how they were going to get this fantastic boat. They could get us from Vancouver to Vancouver Island in 30 minutes instead of 48. But the first thing they did was as soon as they sent it on the first trip, it sent the most incredible wake that just ravaged all the local islands. And they're like, well, we can't run it that fast. So now they had a multi, multi-million dollar boat that they were running at 30% speed because they had never thought like, hey, let's think about other environmental factors.

[01:53:05] Or Toronto did this one famously too. Canadians not so good with their boat planning. They built a ferry. Whoever's in charge of the ferry lobby is doing great. They're driving a Porsche and never having to come back and revisit things. But this, they came up with a system. They bought these electric ferries. They did the whole thing. Millions in all the studies. Will it hurt the bird's nest? Will it change the... They learned from BC. They're like, let's make sure it won't wreck everything. Like, no problem. It's all good. And then they literally were like at the point of like, we're months, like six months from delivery on this like two-year project. They're like, where do we plug the boat in? They literally never figured out how to dock the boat. They spent all the time engineering the boat. And now they have a two-year study on how they're actually going to be able to dock and charge this bloody boat.

[01:54:07] Yeah. And I don't know if you saw that, but if you drive to Horseshoe Bay or in Vancouver, you'll see cars with bumper stickers. BC ferries. Thank God they are not flying planes. Oh, yeah. And I think this is also what we need is it's very easy to get blackpilled and very doom thinking about like the risk. And that's why I don't want to see if I see one more fireside chat on ethics of AI, like we get it. We had the same 60-minute conversation over and over again, but no one does anything about it. Yeah. Like how do we actively affect the real environment? That's great. We can have the pundits sit in their fancy looking chairs. You know, it's beautiful on the stage. It looks great. It'll make a good video. But like, what does it do on the ground?

[01:55:04] And if we just watch the one hour fireside chats, we'll just walk away constantly going like, oh, God, what does happen when information leaks, when bad actors get in? But we should think, what are the opportunities to proactively affect this environment? And what can I do as an engineer, as an architect, as a builder, as a thinker, as a participant in this industry? What can I do with my peer group? And what you've done with the Guild, and I'm hoping to be the second chapter of the Guild here in New Jersey, because I've got so many people that want to affect this environment. But the first thing we want to do is we want to talk about how we can optimize, how we can do that. And what are people actually experiencing? Because if you just go to Twitter, you'd think that everybody's just replacing people with Claude bots and, you know, it'll run on your phone soon. That's maybe true for some use cases, but it's not true in enterprise engineering.

[01:56:04] It's not true in enterprise computing. It's not true around the world. You know, we're talking about this as if everybody has a computer and a laptop. I'm not sure if people have been to major parts of the world who are not actually attached to the internet on a constant basis. Like there are many assumptions that we have not accounted for. So what you're, I've always thought that like VMware had the VMUG, the VMware user group. And it became this incredible community of practitioners and architects and designers. And as that technology developed, we all became system designers instead of just VMware operators. And that access to that brain share fundamentally changed how I thought about running a VMware server, you know, same way as working with you and the team fundamentally changed how I thought about building compute. Like we talk about multi-environment, you built systems on a product that would never be used in production.

[01:57:07] Like you built on a Mac and we deployed on Windows. Yeah. We did it because we built all of those checks and balances to know that we could, we built interoperability into the process so that we didn't have to worry about the change when it arrived. Like I just think that those fundamentals were only developed by working with people that questioned, why are we doing it? And can we do this a better way? Like that, you have to surround yourself with those people and those ideas. Yeah. And you just reminded me, I remembered my, the third leg of the guild. So it's technical excellence, ethics, and innovation. Innovation is very important in the sense that we should not just be mimicking or mirroring how we've been doing things prior to this breakthrough. Only like it's only faster and with less whatever, but we gotta find new ways of doing it that is gonna, you know, I'm always fond of, cause I'm interested in architecture and the father of the architecture is a ancient Roman dude called Vitruvius.

[01:58:20] I don't know if you heard of Vitruvius. Indeed. Yeah. And so he basically established three fundamental principles of architecture. The first one is called firmitas, which is firmness. The architecture needs to be, like you say, resilient, firm. The second utilitas, which is utility. It has to be useful, serves some purpose. And the third one is venustras, which is habitable, beauty. It's not enough just for, you know, moving to a place where it's solid, firm, and it's very useful and functional, but it has to feel good, has to have human dimension, has to make you feel like you're at home. You're feeling safe. You're feeling taken care of. You're enjoying it. So this is our job, as I think architects and systems engineers is to make sure it's sturdy. It can gracefully degrade. It can bounce back. It can get stronger from its damages to the system.

[01:59:19] Then it becomes, of course, very useful. It's serving the purpose and helping us. And then you feel good when you're doing that. You don't feel like, oh, this stinks, but I have to do it anyway. So it's a tall order, right? But we hopefully, I don't know if you have time to join us establishing this group of professionals. The danger is also that it may become shameless self-promotion platform. That's always a careful boundary. Yeah, yeah. It is tough. I always used to say, like when people would call me, like I became a blogger because I wanted to write down the problem. Writing down the problems I was solving helped me to work through how I solved it. And it helped me to explain it better. And that taught me a lot about how I could be a better coach, a better mentor, a better practitioner. It forced me to slow down.

[02:00:17] I knew how it worked, but when I had to slow down to write it out, and then I learned story structure, I learned narrative flow. I mean, I co-founded the company with somebody because of what we did. Like here I am many years later, and I've made a job out of that. But really this goal was to then meet other people who were also writing. And then at one point, I got called an influencer because I would go to an event and they're like, oh, you're a disco posse or a blogger influencer. Like that's fine, but I'm actually just a practitioner who happens to be vocal. You know, I'm a professional extrovert. I'm an introvert by nature, but I'm a professional extrovert. I can be very extroverted, but I tap out after a while. It's cognitively very challenging for me to keep emotionally that open. But at any rate, the point was that I'm going through this, and then I'm looking at all these people that I'm in my peer level who are starting to blog and we're teaching each other how to blog. And then occasionally one would pop out and they would then become the influencer.

[02:01:19] And they, I used to call it when they become self-aware, that's when you have to push them out of the guild. Because once they think that they're the audience, that's wrong. The influencer is a cohort representation of the audience. And when they start to believe that they now can represent and make decisions on behalf of the audience, they've no longer are what they were born of. I am simply an extrapolation, a one person intrapolation, I guess, whatever, of that thing. I'm a cohort of the world with the questions that I ask that then I will share with the world. And hopefully some people find value in the answers. But if I think that I'm smarter because I've got the questions, I'm no longer valuable. And that's the problem. There's too many people that they'll join these things. You know, can I share my blogs?

[02:02:17] Can I publish this content? Be like, that's great. But what's the ethos of the group that we're here? What's the purpose of what we're doing is to support the industry at large as a community. And it's very hard for people to maintain that community ethos because it's very tempting to like, oh, if I could do this, I put a video on it. And if I make it catchy, then I can get 8,000 views. And like whatever, like we start to look at the metrics. I don't look at any metrics of what I do. I have to as a job, but I don't write with metrics in mind. I don't build systems with metrics. I don't do these podcasts with metrics in mind. I do them with, I want to talk to amazing people and learn amazing lessons. And I get to walk these ideas in my head. And it just so happens that people listen. But that's bonus. If no one would listen, I'd still do the podcast.

[02:03:14] I don't check the audience. I don't like, I just want to do this thing. And then it just works out that as a benefit. But yeah, so I would say that was a long way around of like, I hate influencers. Because I don't know why currently the market is in such situation that even people who are employed are kind of getting a bit nervous and are looking to secure their future by positioning themselves or somehow. And then there's a danger that they may see some of these things as a springboard for their own, promoting their own services. And which is okay, I understand. But that's not the intention of it. So it's going to be tricky to say, look, you know, I mean, I'm with you, even if you as an influencer, if you have one viewer who is getting something out of this, it's worth it.

[02:04:12] Just one person, it's worth it. Yeah. Yeah. If someone walks in, that's really what you want to get. Like if somebody is going to say like, hey, I was at this group and we had this discussion and I went back to my work and we had the same discussion, but I had an answer that I'd never thought of because of this collaboration opportunity. And within it, we can do shameless self-promotion. That's what I love, like intra-community. I love the shameless self-promotion track, you know, whether it's Discord or Slack or whatever, like that's fine. We should all be proud of what we're doing, but don't make it like Reddit where like all I see is people going like, hey, you know, I've got a really important question that just happens to line up with a startup that I've just launched. You've got 4,000 karma in the last seven days because you've posted 3,998 times, you know, and it's the same post every time. Like, yeah, no.

[02:05:12] And then another flip side of the coin is I'm noticing a number of people who are, I think, leveraging or what's the word, you know, noticing that there's a number of people who are distraught. We talked earlier about, okay, I'm losing my, I'm an incumbent. I'm recognized as a good software developer. Now this AI is threatening my position. So then I see some people who pander to these people and have barrage of like, oh, the AI is not going anywhere, it's going to die. And they're doing it not to appease these guys, but to promote themselves and to get the foot in the door. And that's kind of disingenuous. Because you can sense they're not sincere. Right, they're basically white knighting, like. Yeah.

[02:06:09] And gaslighting and gasplighting. Yeah. And that's doing, I think that's doing the damage to the profession, kind of pandering to people. Oh, nothing to worry about, these are all idiots. You're good, you're, you know, everything's going to come back to normal back in August. Mark my words, because people want to hear a bad time story, like, is this going to go away? Yeah. I remember, Eric, I remember back in 2005, I met with an old colleague, we had a coffee and he's like, so Alex, let me ask you one thing. I'm like, what? When is this HTML going to go away? It's getting on my nerves. It's like some child's play, some HTML, it can be serious because they'll come from the, you know, hardened, hardcore C++ desktop app. It's not going to go away, you know, it's, Yeah. I think same as with AI.

[02:07:06] Yeah, that's it. And, you know, so surround yourself with people with intent. And I think that is really the core ethos of what you're doing with the Guild. Again, I will be an active participant wherever I can, because I want to, I think this really does need to be an effective, like a chapterized thing that we could put in many locations that we could be, you know, because while we are geographically close by this, you know, digital medium, though sitting around and having bad donuts and bad coffee in a conference room with a bunch of people is actually kind of a cool feeling sometimes. It's like an AA meeting, you know, Hi, my name is Erics. I'm a, Are you covering my hands? Yeah.

[02:08:04] That's right. I'm a cloud addict. You know, I shouldn't joke about that because it is, there are genuine, there are people that are getting into a bad space of like, they're burning real money thinking they're getting like so close to the thing that's going to make their future, not realizing that they're just spending into the next constraint, which is no one's going to buy the app that you built because you don't know how to market it, don't know how to do whatever. So, yeah, yeah. So, but, so we'll have links for folks for getting involved with, with the Guild and I'll publish for sure, you know, the works that you do. Yeah. Thank you. How do people get ahold of you, Alex? Beyond here. I have my website. It's just my, AlexBernard, firstnamelastname.com and then on there, I have my, all the links to LinkedIn, et cetera.

[02:09:03] And they can, if you go to my website, you can schedule a call with me. There's a calendar app. You can just pick a date and we can jump on a call and see where things are at. I'm hoping we can establish some bare minimum bar to our profession. But we need people like you because I think you have very good grasp. We need systems people. Well, thank you. It's appreciated. It means a lot coming from you. Your head is in the right place and I think you're fully qualified to take us to the next level. And you have a, and you have the stamina, the focus, like we said, the intention. Your skills will be very valuable in the upcoming months and years because you understand where the issues lie.

[02:10:03] And I really like your focus on everything in red, Soviet Union style, nobody, everybody guilty. You got to prove to us that you are worthy of releasing into the wild. Yeah. That's the only approach at this point. We cannot be naively saying, oh yeah, these are like phenomenally sophisticated things. We can just release them and see what happens next. No, don't be, you know, don't be crazy. Don't create another pandemic of these like crazy. Yep. It's assume failure. I'm an optimist, but I also am a realist in that I have to assume what are the failure domains that I'm going to face towards with the goal of my optimistic future. You know, I do want an optimistic outcome, but I also have to realize that it's not going to happen because of X constraint or whatever.

[02:11:00] Look, I mean, the only way to be real optimist is to always have a worst case scenario explicitly stated. This is the worst thing that can possibly happen. And now, you know, can you survive that or not? If you know that, then anything, everything else is gravy. It's just cherry on the top. Yeah. Right. So that would be my kind of philosophy. What is your worst case scenario? Yeah. When you all say, even as a, because you taught me about the beauty of an analogy is this idea of like, why do we, why do we do all this work of like setting up lights and doing all these things to make ourselves more appealing? It's like, there are certain things that we have to do because I have to assume that people aren't going to listen, you know, or watch. So I want to like make it, I have to, based on that assumption, I've done other mitigating things to make it more appealing and give it that habitability.

[02:12:00] Yeah. Yeah. But it's all about humans at the end of the day. There you go. My, my, my famous shirt, people said like, it was my new campaign for the start of the year is profoundly human. And it is something that I think that we should all be proud of. Use the tools. Like no one goes, has anyone been replaced by a hammer? But no, they have, they've been replaced by a guy with a hammer. So that's, that's what AI is. It's a good, good people with good tools. Yeah. And again, think about the concierge versus Butler metaphor. All the system we are using today, whatever you're using is a concierge. It is not loyal to you. It is loyal to the overlord who is paying the service. Now, today we have a chance to create our own Butler who's going to be loyal to us, not to the overlord. Big opportunity. We can do it, right?

[02:12:57] But we have to proceed carefully. But the focus should be Butler. Is it learning about my needs? But what do I actually need and how to protect me and how to ensure my safety and my wellbeing in the world? This is what I think technology should be. Of course, the nefarious forces who are profit warmongering are conspiring to subvert that and to flip the tables, which they always do. And we always fall for it. And we are going out and cheering for something that's going to be, and even, even the naive things such as people camping in front of the Apple store to get the latest iPhone. Yeah. You're paying out of your own pockets to be the foot soldier of some corporation. Are you like mental? They should be paying you. You're spreading the word of the mouth. You're a zealot. You're paying for being their advertising machine.

[02:13:54] That's like insane, right? And if people don't even notice that. So you become the slave of some machinery. Wake up. Don't do that. Find a way to use this machinery to protect yourself, to build a bulwark against exploitative and manipulative and deceiving, deceitful agents out there who are just looking at ways to trick you and, you know, steal whatever your identity or money or reputation. We live in a perilous world right now. And this technology, we need to learn how to use it to protect ourselves, not to expose ourselves. Right. Right. So that's part of the guilt that we're trying to establish. It's like, no, you've got to look at things as your butler. It's serving you. It's dedicated to you. Yeah. Well, I'll say to close up, I'll say in the same way as easy and simple are not the same.

[02:14:57] It is the same. It is a similar relationship with good and nice. Yeah. And what we often are is we're trying to be nice about how we do things, but underneath it has to be good. You know, sometimes good isn't nice. Sometimes good is difficult conversations, but the underlying good as an ethos is, has to be that foundation on which you build the rest of the system of people and the system of behaviors and the system of interactions and how we build our own constitution between each other. You know, that's, these things all map onto fantastic, interesting concepts. And I'm not a religious person, but I understand why people choose religion because it allows them to define a set of, you know, constraints and goals and ideas and stories that help to support their, that thing in their mind.

[02:16:00] And what we need to do is we need to take why that worked and bring this over to AI for good. And, you know, how do we do this in a way that is good to the humans that are created in the thing? Interesting and fascinating. Also, I'm starting to, I'm running another podcast, which I call Emancipate Ourselves from Wishful Thinking, where I discuss our propensity to chase feeling good at the expense of truth. So you may be in a situation where here's the truth, but you'd side with the lie because it makes you feel good. Yeah. And that is what I call wishful thinking. And if you have, you know, children are all about wishful thinking, just chasing after wishes, crying and having tantrums. Then we kind of grow up. And as adults, we should be not falling for the trick of wishful thinking.

[02:17:00] But we do. And again, same with this AI. You should be able to resist your wishes and emancipate. We should be able to emancipate ourselves and say, OK, yeah, I wish this and that and the other. But the reality is such, let's look at the cold, hard facts. Let's go after the truth. What's the real situation? I think this is what makes us grownups, adults. So again, this all ties together because now we have a chance to reclaim our humanity and to say, yes, the history of human species is the history of technology. And this is the pinnacle as far as we've gotten. So our duty, I think, is to make it work for us. And use the lessons of, as they say, past, past is prologue, is the short form of it.

[02:17:56] But, you know, let's use these as lessons of the future. But you have to look back, look at now and build towards. So awesome. Well, Alex, thank you so much. Thank you, Eric. We'll definitely, we'll catch up again. Yeah. And yeah, this is a blast. God, I could do this all day. That's really cool. The Guild is going to be amazing. I am super excited about this because this is, I've needed to see this come to the world and I'll do everything I can to help bring it to this world with you. Thank you, Eric. I'm looking forward to see what you're going to bring to the table. It's going to be really, I know you can bring original things that nobody else will think of, which is what we need. Innovation. That's it. Excellent. Cool. Okay.