What Does It Really Mean To Program With AI: A Conversation with Joy Ebertz Transcript, AI Summary & Key Points

00:02 [music] Welcome to the Architects podcast where we [music] discuss what it means to be an architect and how architects actually do their job. Today's guest is Joy Eerts who is a principal software engineer at Imprint where she is currently trying to detangle their configuration. She's primarily a back-end focused developer with extensive experience in microser architecture, authorization frameworks, creating rest API standards, feature flagging and more.

00:32 Prior to imprint, she worked at harness, split, and box in staff plus roles. In addition to designing software and writing a lot of code with the help of AI, she also maintains a blog with both career and technical topics. In her free time, she does a lot of traveling, reading, and running ridiculously long distances, mostly on trails. It's great to have you here on the podcast.

01:00 And I'd like to start out by asking you, were you trained as an architect? How did you become an architect? >> Yeah. Well, thanks for having me. First of all, I guess like most career paths, it was a bit meandering. I mean, if you had asked me like pretty soon out of college, where do you want to go eventually? I probably would have said something like architect.

01:20 Like I thought something like that was pretty cool. Um I was generally drawn to that. But then over time I tried a few different things. When I was at Box I got pushed into management at one point. I lasted about a year and a half and decided I absolutely hated it. So that was the end of that career progression. I moved back to the IC track and from there it wasn't quite like we didn't have a role called architect at Box.

01:45 But over time, as I like got more senior and like started picking up more responsibilities, I tended to gravitate towards the more overarching type roles, the roles that looked into a lot of different spaces and like how things fit together, how things generally worked. And then at some point we started a project, actually we started this project like five times, but on one of the iterations we were trying to break our monolith into microservices.

02:12 And so as a part of that, we spun up a small team of individuals working on doing sort of a domain driven design exploration of the entire space. And I was lucky enough to be chosen as one of the people on that team, which caused me to learn a lot about some of the more theoretical side of architecture and dig in and really think about how code fits together.

02:34 And from there, I would say I just sort of tended in that direction. And to be honest, I've never had an official architect title, but if you ask me to place myself, that's generally where I would place myself in my roles. >> Well, a lot of people who function as architects don't have that title. In fact, if you remember, there was a time in a certain phase of agile where they said, "We're not going to have any architects."

03:02 And the idea was that architecture would somehow magically emerge. and everybody would be an architect. And to my way of thinking, that always doesn't work because if no one has responsibility for it, it usually doesn't get done. And I don't know if that's your experience. >> Yeah. The way I like to think about architecture, and tell me whether you disagree with that, is that the architect is responsible for those things that cannot be written in a use case.

03:34 the illities, the security, scalability, the whole user experience. I'm not talking about the user interface, but the user experience and that really is where the architect role shines. >> I would say some of that, but also thinking long term. Like I feel like sometimes some of the things you mentioned the team might think about anyway because they happen to be in the RFC template or what have you, but I've also seen a lot of times people will think a little bit too small like either in terms of timeline or in terms of

04:06 like only thinking about their team or what have you. And part of where I see the architect shine is like pulling in those where are we going next and how does this fit with that as well as like you know this other team is doing this thing. how does your thing work well with that? And like kind of pulling the big picture into what's actually being built >> and part of that as as I remember from your Cucon talk.

04:29 I mean, you were talking at the time about technical debt, but the technical debt is just an example of this, you have to trade off, you know, do we sacrifice too much for the long term? How much does it really matter? What's the business case for doing that? So it's really from what you're saying it's not only thinking in the long term in terms of technical things but in terms of understanding the business and explaining that to the business people as well.

05:01 >> Yeah. I mean like you could build something absolutely technically perfect that's going to last 100 billion customers whatever but if your business doesn't survive to next month it doesn't matter. >> I think that's a valid point. What you're referring to is what Gregor Hopi likes to talk about the elevator architect where he has to go from the boardroom to the boiler room.

05:21 In other words, you have to be able to talk to the technical people and explain to them the business goals and you have to explain to the business people what the technical goals are. >> Yes. Exactly. [laughter] Which leads me into the first thing I'm curious about is you you talked about monoliths and you have an extensive background in microservices.

05:45 There seems to be a tendency today that there's a people are pushing back and going towards monoliths and to me this sort of conflicts with the use of AI to code because I think AI thinks it works better with microservices where you can see what the AI code generator does. You have bounding boxes around it as opposed to if you have a monolith it becomes much harder to use AI.

06:11 Yeah, that's an interesting point. Yeah, I guess over the years I've seen the trend from monolith to microservices and then back to monolith. And honestly, personally, I can see good arguments in both directions. But what's fascinating is where I am currently, one of the things we've talked about too is that your point is absolutely correct that AIs do better if they're constrained in what they're looking at and they're constrained in the problem they're given.

06:41 They're kind of like humans, right? like if you give them too much to think about at once, stuff gets lost and forgotten and whatever, right? So if you can constrain the codebase, they're going to do better. But on the flip side, for example, we had three JavaScript separate services, separate repos, but they were sort of drifting in different directions for no good reason.

07:02 And so we merged those back together, and then the AI started to pick up good practices from one and apply it to the others. So it can occasionally be useful with AI to have stuff in I guess this is more a monor repo than a mono service but still a similar idea of like pulling everything back together. So I don't know that we have the perfect answer yet because your point is still correct but I think we're still trying to figure out you know when is it better to pull things together versus split them apart and what are

07:31 the advantages to each side. Well, one thing that occurred to me as I thought about this problem and you know anybody who you know is curious about this is thinking about this problem. None of us have answers to it but I think about not only the creation of the code at the start but when you start to get bug reports back how do you alter the AI generated code?

07:59 So if you have a monolith or you have one repo or you have one something large, it may be harder for the AI to make the micro changes or the larger changes that have to be made if you're dealing with a monolith rather than a micros service because I had someone on the podcast who we talked about this and his whole idea was you have the AI generate the micros service and when you get a bug report in you just regenerate the microser service from scratch because you can do that with an AI much easily than you can with a

08:33 human. So I don't know how you feel about that. It's not so much the initial creation, >> but it's when you loop back the bug report or the changes from the field that the SRRI are bringing in or the customers reporting that the advantage of microservices really comes to the four. >> I haven't actually dabbled in anything that extreme. I have heard other people talk about it as well and I I'm really fascinated by this concept of just having AI completely regenerate something because to your point it is much much faster

09:06 to build the entire thing than it used to be. I do think the thing we're missing is good testing. Like I think in order to do that you have to have all of your use cases very well defined in tests or in some form right as you rebuild the thing you need to make sure it still meets all of the needs that you have which is I think a limiting factor for a number of teams out there at the moment.

09:29 >> Well that raises the other question and I've been in this business long enough. I mean, I remember and it's curious when I think about this because I remember the arguments over whether compilers or handcoded assembly code was better or not. You know, this is the software business, all things old or new again. But in those days, there was a dream and I'm thinking about the 1980s, early 1990s, that we would have these requirement definition languages >> that would remove the ambiguity.

10:02 Hey, this is the problem. English is wonderful or any I'm picking English, but it's true of all languages whether you know. So, I'm just using English because that's the language I know best. I'm not trying to prejudice against some other language or some other culture. But language is purposely ambiguous because it's much better often diplomatically or culturally just to be slightly ambiguous than precise.

10:28 Computers on the other hand are stupid. I mean even the at some level they're dumb and even the AI today maybe 50 years from now 20 years from now they'll be smarter than we are but not where we are right now and not for the foreseeable future. So the question is if you're going to have those tests a how are you going to describe them precisely because if the AI is generate the tests presumably a separate AI is going to generate the test but if you have the tests how are you going to describe them precisely enough

11:00 because when you let's say you're doing TDD and you want to write your tests first and it's one thing for me to write a test and looking at the requirements document the conversation with the customer who or the program manager how it came about and write a test but for the AI to take that written statement you know do we need a language to do this is this something that still be should be done by humans if the AI is generating the code I mean I you see what I'm struggling with and if you have any insights into that >>

11:37 I don't know that I have great insights but when I first started playing with AI one of the first things when my teammates was like, "Look, it's great. It generates the code and then it fixes all the tests that broke." And I was like, "Wait a minute." Like, it's just doing whatever it wants. Like, you [laughter] know, >> you could write in assert true and then the test passes.

11:57 >> Yeah. Exactly. And I also have had cases where I'm like, "Fix this test." And the AO is like, "Okay, I'll delete the test." And I'm like, "Well, technically we're we don't have broken tests now, but not what I meant." So, I think we do need to figure that out. I mean I think you can still have AI generate tests but I think you need to make sure that it's separate or there's clear commands that like as a part of this rewrite you don't touch any of the tests or you know much clearer on that side than we are right now

12:23 in general at least. I know I know like our codebase we now have in our like agent files things like you know don't just delete tests and things like that. I mean this is one of the places where you've talked about avoiding perfectionism but here's almost the place where you have to be perfect or aim for perfectionism especially on the test then because if you're going to rely on the AI to generate the code all right there generate slop okay that will come out in the process but it's really the tests >> and in this

12:57 world to way I think about it the tests become even more important important than they were. >> Yeah, it's it's interesting because I guess like and this is a shift in thinking in general is like previously you would have an old system and like even if there were like small bugs or it was really annoying to maintain, sometimes it was worth just not touching because you didn't know what the requirements were exactly.

13:17 Nobody in the company remembers anymore what all the requirements are. So it's easier to just like leave it and not touch it or touch it as little as possible and it's still going to mostly work. But with this new model of maybe we regenerate huge chunks of it regularly, like you need to know what it's supposed to do and you need to somehow document that or something in a way that we've been traditionally very lazy about.

13:41 In fact, I heard this a couple days ago. It was like we're we're not writing enough documentation. It's like not clear what our stuff does and because nobody does. Like that's just not something that happens. Well, let me tell you, I've been doing this since around 1982 and we still in those days said we're not writing enough documentation or [laughter] >> so I mean this is a problem especially as the speed of development increases.

14:11 >> Yes, >> this might actually turn out to be the gating factor. It's not the AI slop, whatever that means, but the fact that we cannot generate requirements well enough and we can't feed back what comes back to the field to those requirements fast enough. >> I think that's right because I've been hearing like recently that code reviews and some of that is what's gating it right now.

14:40 But I I think that's an artificial gate because I think as the tests improve and some of that stuff, we're going to stop relying on code reviews because code reviews were never great to begin with if I'm being honest. So, >> I've done them, so I know exactly where you're coming from. >> Yeah, sometimes they catch stuff, but a lot of times they don't catch a lot of the things.

14:59 And like as you're getting inundated with like more and more code reviews, none of us signed up to just code review all day, right? None of us like that. We're just getting sloppy at the code reviews, too. So I think they have to go away and we have to find a way for them to go away. So once you get rid of that, I think it gets replaced with tests and requirements and like some of the stuff you're talking about.

15:18 And I think it comes back more to how fast can we think through the problems and like define the behaviors we want to see and how well can we define the system as a whole. Because if you remember the extreme TD people went and said they actually define the system as they wrote the tests because the tests were almost the require I mean you know I never believed in that extreme to begin with.

15:49 >> Mhm. >> That's too much ceremony. You weren't done until the tests were done. But the idea is that you'd evolve the tests and that would tell you what the requirements are. And that's clearly not going to work here in this world. Thinking about what we've moved the conversation to, there's still going to be some problems that humans are going to have to investigate.

16:13 I think especially some [snorts] of the security problems, some of the interface with third parties cuz if we're using third party libraries or third party services, they're not going to very often well defined. So how the hell are you going to tell the AI what to be well defined? So in those scenarios or the tough bugs or whatever it is, we're going to have to read the AI generated code.

16:39 However, if the AI start to or the agents or whatever, we we're obviously being sloppy about what we mean by the term AI here. But I [laughter] think in the ambiguity of the conversation, we the event of being humans talking to you, we understand. The question becomes if the AI writes the software, does it start to write the software for the machine and other AIs and not human consumption?

17:09 Because I remember that's part of the debate that happened with the compilers in the machine language that you would have at some point until the compilers got really good. I mean now no one really worries about that kind of thing. Although I'm old enough to remember when we found bugs in compilers or we found bugs because the compiler switches weren't right.

17:30 I mean this is not to to show you I don't know if anybody would in this generation would understand this but I remember one time I was called in as a consultant to solve a problem where all of a sudden these huge builds stop working. >> Mhm. And what I took me a little while had to go down the call stack and watch the calls as one library called another.

17:53 And what I finally deduced was at one interface point the two libraries are compiled with different compiler switches for which word boundaries the commands were aligned on. [laughter] So in the call stack the argument transfer didn't work and that's why the thing was blowing up. Now most developers today would not be able to handle that problem because it's just assumed away.

18:21 They in other words the abstractions have been piled up and the virtual machines have been piled up and the only reason why I could figure out is because I was old enough to remember the days when you worried about things like that. So my fear is in this transition period because we're going faster. See in those days we didn't go fast. So there was time for people like me to adapt the new technology and keep up and still retain the old knowledge.

18:48 My fear is if we go so fast, this old knowledge will be rapidly forgotten. I think it's related to that, but one of the things I worry about is we're not effectively teaching the next generation because I know senior engineers right now, I suspect we just know what to ask the AI a little bit better and we like frame it in terms of like I want to use this database and kind of roughly structure it like this.

19:15 You know, you give it like pretty specific instructions with the architecture kind of already built in and then have it do the thing. But we have I I've seen some fairly junior engineers who come in and like just give it very generic things and you end up with like spaghetti code doing who knows what that kind of does the thing but like not great. And as a senior engineer I don't know how to necessarily train them or like which pieces of what I'm telling the AI I need to like train them to start doing.

19:45 It's like it's this much harder to teach them this thing that I was never specifically taught. So like we're not teaching them to use the AI effectively, but we're also not teaching them how to do it without the AI, which is kind of where I came from in order to be where I am today. >> I'll put it even more bluntly is the code that we're asking AIS to do with traditionally the code that the apprentices learned on.

20:09 >> There's some of that as well for sure. >> So, and this is a topic I tried exploring on the podcast before. I would love to explore again is how do we train the next generation of engineers because I think there's a serious problem here and we're moving too fast because for example if you I had this actually conversation at lunch with a friend of mine do you tell people to study computer science as an undergraduate >> or do you tell them and I've had this conversation with many people who are senior engineers and

20:44 have children going into college and what advice do they give them? >> There's more to it than just telling the AI what to do. And >> yeah, I honestly don't know if I would tell somebody to go into CS today. I think because there's also like most companies at the moment are just not hiring junior engineers, too, which also feels shortsighted like at some point everybody's going to retire out of the workforce and who are they going to have left?

21:11 But >> oh yeah, where where are all the cobalt programmers? I mean I mean [laughter] >> yeah somebody once said to me I mean we're having a discussion some companies are still hiring junior engineers because they're cheaper than all the tokens they need to produce the cup. [laughter] >> Yeah. But at some point that won't be the case. So you know neither of us have an answer to this question.

21:33 And I have a feeling like most things in our discipline, in fact, most things we do with human beings, they don't learn until there's a crash or failure of some sort. In other words, I don't know if this this is an evolutionary defect that we're so short-termminded, but we don't get the next thing done without thinking. This is what you talked about before by the architect.

21:59 As an architect, you should be thinking about the long term. And that the long term is where we going to get the developers from. [laughter] >> Exactly. I mean, I've had people suggest to me maybe you pair program with the AI or you give the junior developers to ask them to debug certain problems. But these seem to be ad hoc solutions. >> Yeah, this is something that somebody's going to have to figure out and neither you nor I seem to have the answer to.

22:32 I'm not surprised, but it's going to have to emerge. I think what's going to happen is people just have to bite the bullet and not assign certain problems to AI to just train the junior developers. >> Yeah. But it's interesting, especially with capitalism, like what company is incentivized to do that? Very few of them are. >> Well, first of all, you have the same problem in other economic systems.

22:57 It's just in capitalism it's more visible because you see the dynamic. If you have social systems that do you know bureaucratic long-term planning you don't see it because the signals aren't there. >> Mhm. >> But I mean that's I you know that's an interesting discussion we can have in some other time. To me the advent of capitalism always been that the signals are obvious.

23:21 The question is what you do about the signals. This is where you can argue about social policy and what's right and what's not. But if you hide the signals, it's like curing a fever with aspirin without asking yourself, well, why do we have a fever? >> Yeah. >> Anyway, you would think the larger companies would have the time to look ahead because they have the market momentum.

23:46 They have unlike the smaller ventures who have to get a product to market to show. You would think the larger companies would where this would come from, but I I don't see them doing this either. or figuring this out. >> Yeah. Which sort of ties back into my tech debt talk as well, right? Like the larger companies can afford to like build things the right way and generally do things the right way for the long term.

24:10 And to your point, I would hope that they would >> start to do this as well, but I haven't seen evidence of it quite yet, but I guess we're still fairly early. So >> well I mean I think we will see evidence of this quickly because if people start to move ahead quickly with AI and all you need is one bad situation and everybody will now panic in the opposite direction.

24:32 So we'll we'll see what happens. One other question I was thinking about, you know, I was thinking about talking to you've spent a lot of time dealing with authorization and to me I mean everyone talks about authentication but to me in my experience authorization is a much harder problem because it's fine grained. I mean you know I was once had a situation where I had a client where certain columns in reports could only be read by certain people.

25:05 You know, authorization can get down to a really, really gnarly problem in a way that authentication seems relatively. Okay, just make sure the token flows. >> Yeah, authentication is very complex, but it's also a pretty well-defined problem and people understand it fairly well. authorization to your point the simple case is pretty easy but then it's you can very quickly add many many rules many many special cases on top of that and it gets yeah it gets very very complex very quickly >> do you think artificial

25:39 intelligence could help with this >> that's a great question I mean it helps with a lot of things so I don't want to say no but then on the flip side there's also the case or what we were talking about originally where like it doesn't do well with like large problems either, large complex systems either. So, I don't know. [laughter] I >> Well, that's fair.

26:00 I mean, that's a lot more honest than an LLM will be, which would never say I don't know. >> Actually, I have had it a couple times be like, "Ah, I think I'm going in circles here." But [laughter] anyway, >> I mean, not to get too far a field, but I've had that that problem. Let's say you're using rag and it can't find in your sources that you gave it from the rag an answer.

26:24 It will go back and instead of saying I don't know, it'll go back into its training data and come up with an answer. >> Yeah. One of my least favorite co-workers tended to do that too. If he didn't know something, he would make something up and so you couldn't trust anything out of his mouth. [laughter] Well, so this would be some place where I think, you know, I haven't dealt with authorization problems in a long time, but I figured you having your experience and also experience with AI might be able to, you know,

26:56 have some insight into that problem, but as you say, it can be a global problem, which AI has problems with. >> Yeah. I think part of why people struggle with authorization is it starts simple. Like I said, any new company, it starts very simple. So, they just build something simple. They don't use a vendor or anything. Makes sense. >> And then they slowly tack on more and more and more rules until it's this like giant monstrosity that nobody really understands.

27:25 And from what I've seen from there is like the best path forward is usually to like break that up and try to put these into more well- constrained rules and problems and kind of separate the domains a little bit. And I think at that point, sure, an AI can deal with that because it's like the constrained problems again. But whether it would be good at breaking it up in the first place, maybe.

27:48 I guess I haven't tried it, but I would also be a little scared because this is authorization we're talking about. >> Right. Right. I mean, this might be something you would try in some sandbox sit. I would be curious to know. >> Now I'm curious. Yeah. Because I mean not that I read the entire literature but I have not seen anybody really talk about this because a lot of talk has been about AI coding microservices monoliths the slop testing all a lot of things that we've talked about but some of these classic

28:21 architectural problems like authorization I mean it doesn't help of course the authorization technologies are sometimes opaque in themselves Yes, >> it might be interesting. I haven't tried this to query an LLM on trying to see if they understand arbback or any of these technologies because I find humans have problems with them. But to think about these things like scalability or security in general or user experience and again I mean end to end you user experience.

28:57 >> Yeah. You think the AIS have anything to contribute to this? You're naming all of the places where I think humans are still the most important. Yeah. It's like places where you really care about performance, places where you really care about security, end to end user experience. Well, yeah. I've I've tried to ask a AI like center this on the screen and it failed like seven times in a row.

29:19 So, do you think [clears throat] there's a place for AI in the middle tier? In other words, one architecture I've seen and I've seen it talked about in multiple places is the orchestrator pattern where you have let's say the AI generates the microservices. >> Mhm. >> So the question is who does the orchestration because to me the way I I I naively like to think about software this is sort or architecture this is sort of like the meal planning model of software.

29:57 You have the microservices or the fundamental service. The basic services are sort of the ingredients. The front end is sort of the final meal that the user sees. But the real hard stuff happens in the middle tier. You know that you take the basic ingredients and you put together. In some sense, the business is in the middle tier. >> The UI is just for the humans.

30:20 >> Y. So if you're orchestrating these things, let's say the AI's write the microservices and we've solved the problems that we've talked about before. Do you think it's reasonable that AI's either now or in the foreseeable future be able to to orchestrate these things? If you give it a defined business problem, maybe they could do the orchestration.

30:42 >> It certainly seems plausible that we could get there. I'm unsure if we're there now. I guess we keep coming back to sort of the same point of it doesn't do well with large things necessarily. So if you can constrain that business problem enough, I could imagine it doing okay. But is it worth it is another question too. >> Yes. But what you're also saying is to abuse an phrase from another place there's a chasm to be crossed.

31:11 >> So in other words, maybe early on the AI could do the orchestration when your problem is simple. But as you get more customers and things get more complicated, you cross a chasm where the AI can't do it. But then you're sort of left with a people who don't know how to do the orchestration and then whatever slop or mess or good stuff that the AI created to begin with and you may not be able to bridge that gap.

31:37 Yeah, it's an interesting time right now because we still have mostly code that was written by humans and like we're still building mostly on that. So things are pretty easy. But as we move more to the point where almost all the code has been written by AI, I think things will start or will continue to shift. It'll shift through that and it'll be to your point even harder sometimes to do things.

32:02 I mean, I was at Google Next about two weeks ago, and one of the statements that got made, I think it was in one of the keynotes or whatever, that 75% of the code written at Google is written by AI in one way or another. Now, I didn't get a chance to query the person who made that statement or investigate that statement. You know, are they including configuration?

32:29 I mean, what is that 75%? You know, does that include the tooling that people use that it's okay if it's a little sloppy because people using the outside doesn't see is it really organizing configuration file? I don't know what's in that 75%. But that is an impressive figure if it's true or it just states that most of the code that we write is not that important.

32:54 And what I mean is I've seen figures before that something like 80% of the code in a system is like error checking user input, you know, just presenting things to humans and it's not the core functionality. So maybe all they're doing is automating the quote unquote easy stuff which is 75% of the coding task anyway. So I I'm really curious to know what that 75% represents.

33:19 I'm curious now too because like if you had asked me how much we're doing, I would say it's closer to 100. But for example, I'm working on an internal tool and the front end for that I am 100% vibe coding. I am like barely looking at what code it spits out. I, you know, I test it manually and I'm like, okay, this thing works. But it's an internal tool.

33:39 Like if it's a little broken, nobody cares. But when I'm playing with our backend systems, I'm much more careful about, okay, telling the AI exactly how it needs to be written and then going through and checking that code. Like sure the code is still written by the AI, but I would say I'm validating basically every step of that. And so like even if you say all of the code was written by AI, those two are very different statements depending on which end of that spectrum you're on, >> right?

34:06 And and it's almost if I can be a little sardonic is it's almost in that second case, you're almost using the AI as a sophisticated autocomplete >> or like a pair programmer that you're working with. >> Yes. to double check you and vice versa. >> So what we're saying is when people say that the code was written by AI, we really have to qualify what kind of code we're talking about >> and how much human supervision and cooperation was there.

34:40 For example, in the scenario you presented, you're the more senior of the pair and the other person's actually typing, but you're looking over their shoulder and saying, "This is not right or maybe you should do it this way." >> Yeah. Exactly. >> So, going forward, we really have to be very careful when we present to people and say, "This was code written by an AI, what we actually mean by that."

35:05 >> Yes. I'm very fascinated by this conversation because it's getting me to think about, you know, what do we really mean when we say AI is helping us and what the limits to it are and how we're really going to figure this out? >> Yeah. >> Does this flexibility that AI gives you become a nightmare? Because one of the things that I've seen in my career is that constraints always help you.

35:31 >> Yes. In other words, because they they take a hu I mean, you must have seen this when you do domain driven design. In other words, the constraints are actually what pushes the conversation forward. >> Yeah. >> You know, you don't get to eventtorming until you have a relatively well-defined problem and it's the constraints that help you. >> Yeah. Yeah, I was actually, this is totally different scenario, but I was in a planning meeting recently and we're just going in circles, but like a lot of it to your point, it's

35:58 just that it wasn't clear what the constraints were. Like people were asking, is something along these lines vaguely possible? Well, yeah, but what exactly is that going to look like? And there were five different answers and it wasn't clear which one you pick because it wasn't clear like what we were trying to solve for, what the like real problems were or the constraints to your point.

36:18 So, yeah. >> Yeah. And what also that raises the question and I've seen this over and over again I'm presuming you have too is that non-technical people do not understand the complexity because how many times in your career someone has come to you and said oh this should be an easy change but what the change they're asking for contradicts the fundamental assumptions you've made in the system so it's really a big change and at the same time people come to you and say I know this is going to be horrible to change and

36:47 it's going to give you a lot of work and you realize, oh, I just changed an if statement and it's and it's done. >> Yeah. >> And I just wonder in the world of again AI coding, how are we going to answer those questions? How are you going to estimate the complexity of doing something or how long is it going to take both in just compute time to get it done?

37:12 Yeah. >> And to correcting the AI because you don't know what the this is the other you don't know what assumptions the AI has made. in creating the code. >> Yes, we usually do like a plan first and then have it code. One of my my favorite question to ask it when it finishes the plan is what assumptions have you made? >> Yes. >> And then I go through those assumptions and do something one way or the other.

37:34 But it's fascinating to see what it tells me because sometimes it's like not a lot and sometimes there's these huge assumptions. I'm like, I'm glad I asked. That is totally wrong. This sounds like a real talk for a conference or paper to be written about what it really means to code with AI. >> Mhm. >> I mean, you you really come up with some interesting things based on experience I don't think people appreciate.

38:02 >> Yeah. >> There's a lot of experience that you've had and a lot of experience you've put forward that I think is is worth an article or a talk. I think what's interesting about this at the moment too is that we're all sort of in our own little bubbles learning these things on our own and we don't necessarily have a lot of insight into how our even our co-workers are using AI.

38:24 I suspect some of them are doing some things better than I am and some things worse. >> Well, that says that maybe at the next Cucon there should be a conference track on how are we actually using this AI thing. >> Yeah. But and like on a personal level even not like the large large scale stuff but just >> how exactly are you talking to the AI? What questions are you asking?

38:47 What are you prompting it? >> Maybe this is a meetup or a you know an unconference or something because these are all questions that people don't really have answers to and I think they're all important questions. >> Mhm. So, I've been very fascinated by this conversation. And I would like to now sort of shift into what I like to call the more humane part of the podcast where I get to ask my architect's questionnaire.

39:17 And it's it's always interesting to me because no matter how many times I ask this, I always get some very interesting ideas from people and very different perspectives on what it means to be an architect. So, what is your favorite part of being an architect? I'm sort of a big picture person anyway and so it allows me to use that in a way that solves problems I guess like ultimately I really like solving problems and so it's like the intersection of how I think anyway and the problem solving which I find fun and

39:48 exciting. >> What is your least favorite part of being an architect? Some of the problems you encounter are these long event horizon things that you're trying to affect and change. And it can be very frustrating to like get them prioritized and continue to get them prioritized and continue to decide if they're even worth getting prioritized this next time.

40:09 And maybe it never comes to anything and then did you make the right decision originally? You know what I mean? like this long cascade of how do you get things to happen or roll in the direction that you're hoping that they roll? >> Is there anything creatively, spiritually, or emotionally intriguing about architecture being an architect? >> To my point of liking to solve problems.

40:33 I I feel like it's just more problems and more complexity and you're thinking about more things. So, I don't know. It's just like yeah, exciting problem solving. What turns you off about architecture or being an architect? >> I think there's still that image of the like ivory tower architect floating around which I've never liked. I hope I never turn into.

40:56 I hope I'm not. But trying to to figure out how to bridge that gap of having enough level above that you can see the entire picture and that you can like figure out how to pull everything in but still have enough grounding in the team that you're working with so that they they trust you and like all that kind of stuff. And how do you balance that? But like I'm constantly trying to figure out how to balance that in a reasonable way.

41:22 Do you have any favorite technologies? >> Probably not. >> That's fair. I mean, >> like I I don't know. I I've generally viewed technologies as just like tools to help me solve the problems. And it's the problems that I find interesting more so than the technologies. A lot of technologies are good in some scenarios and absolutely terrible in others.

41:45 So, it's matching the technology for the problem you have at hand. What about architecture do you love? >> When things go well, it's pretty exciting because you can like really see how you've made something simpler, you've made something cleaner, you've enabled something to last longer. >> What about architecture do you hate? >> A lot of times that doesn't happen.

42:11 [laughter] just honestly I kind of mentioned this before too but like a lot of times these are long horizon things and like you start to question whether this was even the right choice to begin with and sometimes you change your mind and that's the best decision at the time and yeah a lot of times these projects don't necessarily finish or don't get as far as you want them to in fact I've come to decide that like most monoliths splitting into microservices projects you don't actually expect it to finish you expect it

42:41 to get about 75% % of the way there and then that is actually success but it's hard to see it that way sometimes. >> What profession other than being an architect would you like to attempt? >> I mean most things in software are pretty fun but if I assume we're we're taking that off the table entirely. And somebody told me recently this would be terrible.

43:01 So now I'm questioning but I've always sort of wanted to be like a mail carrier because you got to like walk around and like do your own thing and I don't know. Anyway, random thought, but totally unreal and good. >> Do you ever see yourself not being an architect anymore? >> I doubt it because I really like software. I really like solving problems at the moment.

43:25 I would say I'm probably a little bit if you're talking like Will Larson's archetypes, I'm probably a little bit closer to the right hand than the architect. But like it doesn't mean that I stop thinking like an architect, you know, like part of me is still an architect even if it's only a small part at the moment. And I think that's going to generally be true.

43:44 It's hard to get rid of that entirely. >> When a project is done, what do you like to hear from your clients or your team? >> Feedback. Any feedback. Honestly, I I think with these long-term projects I'm talking about, it's like often hard to get feedback. And that leads to the ivory tower thing too of like >> you don't really know the outcomes good or bad.

44:08 And so like getting those outcomes even if it's bad I would I would rather know it so I can learn from it. >> Well, thank you very much. I found this quite fascinating. I hope you enjoyed as well and thank you very much for being on the podcast. [music] >> Yeah, thank you for having me. This was fun. >> [music] [music]