AI Hype vs Reality: What Developers Keep Getting Wrong

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well hello and welcome back. We are continuing our season of Building Better Developers, but this actual season is getting unstuck, moving forward, forward momentum, all the important things that you need. Particularly if it's the start of a year, which it more or less is. I guess we're slightly into the first quarter at this point, but that's where this season started. This is Developing Our Podcast, Building Better Developers. I am Rob Brodhead, one of the founders of Developing Our, also the founder of RB Consulting, where we help you essentially get unstuck. If you're about to jump into a big project, you're trying to figure out what to do with all this AI stuff, we're going to say, hold on a second, let's figure out where we are before we dive into whatever this maybe very expensive project is going to be. You can see a lot of stats out there where everybody expects all these AI initiatives to fail and cost a lot of money. So let's make sure that we actually start in a good spot before we do so. Bring me to good thing and bad thing. Good thing is finally, finally, finally, finally, I've been stuck in rain and storms like too many people for too long this year. It just seems like the year of the storms and not a lot of sunlight. Sunlight this weekend, we got a lot of sunlight. It was great. Finally, was able to get a little like that, you know, vitamin D and all that kind of other good stuff that the healthy things that come when you sit out there and actually get a little sunlight into your life. The downside is, is that now the place that I was I'm finally able to enjoy a little bit, I'm going to be leaving in a couple of days, so I'm not going to get the full enjoyment that I was going to. The good news, the better news is you will get the full enjoyment of listening to Michael as he introduces himself. Hey, everyone, my name is Michael Molloch, one of the co-founders of Building Better Developers, also known as DeveloperNur. I'm also the founder of Envision QA, where we create reliable tailored software that helps you work smarter, scale faster and stay in control. Good thing and bad thing. Similar to Rob, we're still in the winter here in Tennessee. We had a wonderful weekend. It actually got up to almost 80 degrees on Sunday. But then, of course, over the evening, we dropped down to 33 degrees. So that was the bad thing. I actually woke up to snow Monday morning. Where I was out in shores doing yard work all day Sunday. So typical Tennessee weather. You throw a rock next, you know, it's another season. Yes, that is the this is the joy of Tennessee is that the weather can change sometimes within minutes. Another joy we have today, another good thing is we have a guest once again that we will be speaking with, do another interview episode, and we will be speaking with Adam today if you go ahead and introduce yourself. Hello, my name is Adam. I'm working for probably too long, almost 20 years. I've been a developer, platform architect, cloud engineer, you name it. And recently, I started recently some time ago, I started collecting my knowledge and publishing both blog and books about this. I really like sharing what I learned, especially from the scope of failure patterns rather than another success story. And I hope I will be able to share something. The best would be insightful, but let's see if I manage. Well, I think we dive right into the insightful because this is a you have a according to your your material, you are a I guess a self-declared BS detector of some sort for the digital age. And given your experience, I think that's like you've lived through this. I've been around for a few years as well. And it's like I think we see cycles, we see trends, we see the like, you know, every few years there's another silver bullet and there's like this is the thing that's going to change the world and everybody's going to be happy about it and everybody is going to just live happily ever after. And then a couple of years later, because it doesn't happen, we get that again. So I'm going to dive right in like you're. How has this latest phase of the A.I. craze, which this this rise of A.I. particularly going back just a little bit before it became, I guess, this latest buzz, but where you started the low code and no code and now getting into A.I. is like, how do you just for a technologist from somebody's been developing for a long time, how do you see that? How do you see that going? How do you see that one working out? That's an interesting question, because from one perspective, this is a revolution. This does bring a lot of capabilities and at the same time, I see it very similar to what we've seen during the end of 20th century. So that combo when suddenly everything would be solved and everything that had com in the name would be a big thing. How it ended? And let me remind you, pets.com or other brilliant ideas like that. Something like that happens now. And it came, there is also an aspect of A.I. worship. But at the same time, let's be clear, during dot com bubble, giants like Amazon and Google were created. So the technology continued, the technology grew. It did create new giants. It did revolutionize the way we think and work nowadays. But a lot of people have to pay a price for it. Similarly, that's literally anything. So many parallels now that it is incredible to me that a lot of people don't know. So with some of those parallels, do you see maybe where there's some things that particularly right now that companies can look at, particularly those that are trying to dive into something that are markers of that success? You know, I would say that it's probably likely obvious that there's going to be another Amazon or another Google or something like that that will come out of this phase of technology. It could be something we know, like, you know, like it could be more Google or more Microsoft or somebody like that, or it could be Open A.I. or whoever it is. There could be something we've not even heard of yet. Is there something that you see as a marker of those that are going to be that are successful? Or do you see it more as a, does it feel more like it's just sort of the right time, the right place and a lot of luck? Or what would you recommend somebody that's thinking about something like this? How do they try to ensure they're going to be around in a few years? So that actually touches a little bit why I decided to write and focus through my narration through the failure, because the thing is that success is always, to a certain extent, luck. It's easy to say another success story to say just mimic whatever, I don't know, Bezos, Zuckerberg, Altman, whoever you want to think of, did and you will be successful. But besides a lot of talent and of course, hard work, there was an aspect of luck, circumstances and so on. So basically we have classic survivorship bias and it's not easy to replicate. But on the other hand, the mistakes that other companies or companies, start-ups that failed did, those are easy to replicate. We don't need to try to replicate them. If we don't learn from them, we will experience. So instead of looking at, I don't know, whatever, I don't know, OpenAI or other, Anthropic did to be successful, it assumed the course. I would suggest to look at what other companies did and weren't successful. Yeah, if when we're talking at Pets.com, that's a maybe nice example, sorry for kicking, if whoever was involved in that project 25 years ago. But they just thought that taking one solution, one problem to totally new area and claiming that it would be successful just because it uses new technology wasn't enough. And similar pattern is visible with AI. In many companies, you can see this trend of we need to use AI. In my first book, which is Pure Satire on IT industry, I even wrote a place, a small comic like, what do we want AI? When do we want it yesterday? What should we do? We don't know. And this is kind of approach. Just slap AI on everything and maybe figure out what it will do for us later. And I've seen that in daily work when suddenly some project, some problem was solved. Let's use AI because it's more modern, more up to date. While my answer, when I saw the solution, I said, yeah, you could do this with a simple bash script that you would write in two hours. And instead of gazillion tokens that you will pay for, you would use, I don't know, half the CPU core or something like that. So that's something to look at. Not how to replicate a success, but how to avoid or protect yourself from repeating the mistake. Yeah, I think that's something that we see a lot is that where people, they lose focus on the why. They're not really solving a problem. They're just using a tool. And as they say, it's a solution looking for a problem. They're trying to find an excuse to use it. Now, there is some level of that though. How do you see the research side of, for example, like using an AI? Because there is, I think with somebody, every time we have this new technology, there is maybe one, there's probably one or two problems that we look at and we can say, yes, that's what we've been waiting for to solve that problem. But there's almost always, there's things that come out of, there's new stuff that comes out of that technology where suddenly there are maybe even problems we didn't know we wanted to solve. I'll give Amazon as a brief example is that we've always had mail and delivery and stuff like that. And Amazon started as just books, but then somewhere along the way, there are now a couple different companies. But one of the big thing people think about with Amazon is they have Amazon boxes that just show up at your door and this instantaneous delivery that really, I don't like anybody was clamoring for, nobody was looking for it before. Everybody now that they, people like, this is great, more or less, but it's not like people were crying for it. So how do you see that? How do you see an approach with like, let's say AI that maybe even how you would approach it to figure out where can I, how can I get to use this tool and get comfortable enough with it so that it will trigger where there's some problems that I see, oh, here's a problem that I can solve with the tool. Where does the whole look? I would say, don't say I want to use AI, what problems can I solve? What problems do you see in your day-to-day basis, in your professional experience, personal experience or whatnot, and then think if you can use AI to solve. So it's a concept of finding your blue option. There's very common, the biggest success stories actually quite often are not about being super creative about being better than competition. It's about finding their blue ocean, their own niche that they could solve. Would it use AI? I don't know. Maybe, maybe to speed up development. For instance, as far as I'm, I wouldn't encourage using AI and famous, by coding to build the real production system, it would be great for validating ideas. In startup phase, it is very important to pay fast, to validate against the market that could speed up. Would it, would the solution use AI? That's actual, as long as you, as it solves real problem for you or somebody you know. Let's be clear. The best entrepreneurs in history find the problems and the people don't even know they have, like you mentioned Amazon. Steve Jobs was great at it. He was just selling the value. Let's be clear. iPod was nothing revolutionary from technological perspective. There were already some Chinese competition, there was Microsoft. If I remember correctly, creative had something, everything was. What Jobs did was he named the problem and solved the, provided the solution instead of 500 megabytes or gigabytes. I think it was 64 million, 4 billion. That's not correct. He said 1000 songs. This was the value that just needed to be. So that's an interesting comparison because innovation is really the driving factor. Right. You know, it's like what essentially becomes like the 1% like those Amazons, those Googles, they find that niche or they find that innovation that everyone can use. The problem is not every application or every business can service everyone. Right. That's not the goal. If you try to service everyone, you don't, you don't have to do that. That's not the goal. If you try to service everyone, you're in this big ocean of competition. So really for a lot of businesses, they have to kind of narrow their focus to become the best at what they do. Essentially, you know, what is your why? What are you trying to solve? It's interesting your comparison back to pets.com and the transition of technology and that I want to circle back around that for a moment. So given like the rise of cloud computing, you know, everything went to the cloud and then we companies were quickly. Oh, we got to be in the cloud. Now it's like, okay, now everything's a is like, hey, we got to use AI. Except I see a difference here from the dot com, the cloud, software as a service to AI where companies are now like throwing everything at AI. It's like here, everything should be using AI. Whereas with the cloud, they spend a little more time investigating, researching, building their architectures in the cloud with AI. It seems companies are just giving their engineers the tools and say here, go play, go figure this out. Do you see or do you have a recommendation for how companies should be applying this or should be figuring out their move to AI better? Yes, I understand. You know, they need to figure out their way. But is there a better way to incorporate AI into their current models to seamlessly integrate it instead of just kind of like, let's throw everything at it and figure out how it works? Well, I'm kind of by experience and belief platform engineer. So in platform engineering, I will skip for a moment entirely conversation about AI. We have various deployment. You have blue green deployment, you have canary deployments and so on. And the most common nowadays in big organizations and sensible is somehow automated canary deployment. So whoever doesn't know that explain what I mean. We do not move everything to the new version right away as a big bank change. We deploy a new version simultaneously and send, I don't know, 1%, 5% traffic to the new version to verify that it still works. Once it works, once we verify manually or automatically, usually automatically with some metrics, then we send, I don't know, 20%, 50% and finally, and everything. My question would be why we cannot do the same approach in AI. You're saying let's throw that companies go with let's throw everything at AI and see how it works. Do not try to throw everything in the new area. Find, I don't know, one process that you think you could improve and see if it works. Maybe if it works, great. Go with the next one. If not, go back. If you revolutionize entire organization, well, maybe you will win, maybe you will not. The probability that you will not is according to looking at the research is a bit higher than that you will be a winner. Oh, thank you. Along those lines, though, I love that approach and I've worked with some companies that have taken that approach where they started simple like, hey, we have this constant report that people have to put together. Let's try to automate that. Ironically, it took them six months to perfect that, but given when they started, AI wasn't quite where it is today. That's one of the challenges I think companies are running into is the fact that the technology is moving very fast. It's like what we're using AI today in six months may be a totally different model that you're working with and it may be faster. It may actually solve the problem you're working with. With these challenges and like you said before, the cost and trying to roll things out in stages, is this one of those times where going slow may be prudent but detrimental to staying competitive in your market? Well, define competitive. That's the first thing because those companies that did six months instead of six weeks, let's be clear, it's not that they just introduced and perfected solution. They built the know-how how to use this solution and then they, well, in meantime, the models, as you said, got better. But the most important, they did have some books to learn the solution without risking and maybe the next process that they would take instead of six months would take, I don't know, three months or even a couple days instead of another couple weeks, let's say. That brings me to another interesting historical example, very for jumping. But at the beginning of 1990s, I'm not that old, that's a historical knowledge, there was there was something interesting phenomenon called productivity paradox. Basically, when the computers entered the offices, companies worldwide, especially in the US, put billions of dollars into computers, not internet but just office tools like, it wasn't called Microsoft Office back then, it was more Locos I think, but basically a word processor, presentations and stuff and everybody expected that there would be productivity boom. And if you look at statistics, what happened was there was a drastic increase in spending on the IT, there was drastic spending on hardware, the companies providing this hardware were earning a lot, but if you looked at the productivity of the enterprises, it's not visible. In 1980s or beginning of 1990s, there's nothing. What the companies needed to do was to establish totally new processes, organization culture, to incorporate this improvement before the gain actually materialized. AI is similar, AI revolutionizes everything we do. Suddenly, from development perspective, software creation, we do not create, our problem is not no longer creating the code in the solution, it is verifying what the AI creates for us in the new organization. You can like it or not, but the shift towards verification is visible everywhere. But that means that we need to establish those new processes, new organization before we really redevelop. Maybe those six months that you mentioned was exactly what we needed for the organization to develop. Interesting. We've talked about that in the past, about your why, developing your processes and procedures, talking about defining your requirements and that. For those of our listeners, what is your recommendation in this new era with your history that you've looked at? What is your best practices or your vision for how an organization or an individual could go about incorporating AI into their flow correctly so that they're not overwhelmed, they're not wasting money, they're not bleeding those tokens, so to speak? I would say always learn the truth first, but not how to prompt, how to write a prompt, agent, but understand the tool, what are the limitations, what are the benefits, what it was designed for before you incorporate it. Basically listen to creators of the tool, not for marketers that are selling that tool to you. As for details of the process, it's really hard for me to answer and I won't be pretending that I know all the answers. I think that's an interesting point. We found this out years ago. Back when there was another boom of tools, there were these, they're called case tools at the time and things like that, which eventually has become low code and no code. As interesting as we were, the people that had built the tools had something in mind, and then the marketing people had something completely different in mind. We were actually utilizing the tool and had a third thing in mind. It was amazing how often we had a conversation with their support and they would say, oh wow, we never thought of the tool doing that. I think that's a really key point and maybe that goes back even to Michael's discussion, the mention of innovation is that maybe that's what we should be looking at is really, let's use a tool without the preconceived notion that either, maybe even that the builder or the marketing people give us and instead just say, okay, here's a hammer. What can I do with it? Because I think that maybe is where we're going to find innovation and new ways to use something that is maybe something nobody had thought of before. Because obviously, if the marketing people are saying this is what it's good for, then somebody's already thought of it. They've already tried to find a problem. The innovation is going to come when you see you're away from that. Yeah, but let me be clear. I'm not saying don't look for different applications of the tool. The creativity, the genius comes from finding those new applications of tools. And that's awesome. Let's be clear. Another example, Slack was one of them was literally created a tool that wasn't designed as an enterprise, the structure of the service that it is right now. It was an internal tool for, I think it was some game studio that wanted some internal tool and then they found out that it was better than the product that they were working. Yes, look for those solutions. And just like people are genius, people creativity is infinite in terms of finding the ways to bring the systems or solutions that we build for them. The same way people's creativity is infinite in terms of finding new ways to use them. That's totally true. And I would strongly encourage for this creativity. That's one thing. However, another thing is to understand the tool and its limitations. So basically, to not read this was designed for one ABC. It's more about ask creators what the tool can do and then figure out. So yes, hammer is a great tool. You can find a lot of user applications of it, but you need to know that it's not the sharpest tool ever. If you try to use a hammer instead of screwdriver or I don't know, a scalpel to remove an appendix, it's probably not the best idea. And here marketers, I'm using this in a little bit negative fashion as an archetype of marketer, not everybody, are great at first highlighting benefits, then even exaggerating them, but staying, but omitting or omitting at best or lying about the limitation. So basically, as a result, you start to look for applications without the understanding of the tool. So if we look at, for instance, AI, large language models, people believe that they could do, I don't know, live coding or write entire books for you. No, they cannot. They are great in generating text, be it natural text or code, but they are not good at keeping the structure required for writing a book or building a software. That's totally different discipline. If you understand that, you understand that they can speed up your productivity as a developer. It will generate a skeleton of the application, implement some simple methods of even entire classes for you. But the entire architecture of the software, entire testing process of the software is something that you still need to do. You cannot automate it, at least with the current level of AI tools. The same with, I don't know, writing. Maybe it could come up with some ideas. Maybe it could drop some nicer sounding words, like a ghostwriter would do, but it will not replay the author that would architect and tell storytelling or even a redacting work at the end. And that actually goes back to, oh, that really follows up well with your earlier first to market versus the rush to market or the, like, if you want to be competitive, it's another reason why just being fast is not necessarily going to do it. If you want to be competitive, a lot of it comes back to solving the right problem and solving it in the right way. So I think that's a great way to sort of circle back and reinforce what you mentioned earlier. And that is where we're going to pause this episode, or actually going to pause this conversation, this episode, we're actually going to wrap this one up. Don't fear, we will be back. We will be speaking with Adam some more. A lot of this is, I apologize if you're not as technical, this is definitely what developers do when they start, especially us old developers. Instead of like the people that used to sit on the porch and talk about old war stories, we talk about our technology war stories. And the neat thing is we've been through multiple generations of them at this point, because it seems like technology cycles every five to seven years. So if you're in there 20 or 30 years, you have multiple cycles and you have a lot that you can talk about, a lot of callbacks to earlier cycles, earlier technologies, and things of that nature. Adam does a great job jumping back 35 years now, basically, maybe a little late 80s and 90s, almost 40 years ago. But we're going to continue in the next episode. So you can rest your arm, shake out those muscles and stuff like that, and be ready for taking notes the next episode. Till then, go out there and have yourself a great day, a great week, and we will talk to you next time. Remember, a little bit of effort every day adds up to a great success. Keep learning, keep growing, and we'll see you in the next episode.