Vibe coding: Is this really how we'll build software?

0:00Welcome to Beyond the Hyde, monthly podcast from the Scott Logic team, where we cast a practical eye over what's new and exciting and software development. Everything from Cafeter, Scoob and Etti's AI to APIs, my services to Microfrontends. We look beyond the promises the buzz and excitement, the guidey towards the genuine value. I'm Scott Logic's CTO, a culinary part, and each month from this podcast I bring together friends, colleagues and experts for a demystifying discussion that aims to take you beyond the hype. In this episode, I'm joined by Remy to discuss his recent experiences AI-accelerated software development. We discuss the broad spectrum of AI use from simple auto-crupletion to multi-agentic frameworks. The more concretely, we discuss a recent project where Remy rackety probes start to plan out occasion, using a technique he calls research, plan, implement. Finally, we plan to what this means for the industry and people within it. What it means for the developers,

1:00the architects and the CTOs, is AI starts to write more and more of our code, and we ask where the vibe coding really is the future. We pick up the conversation with our thoughts on the latest developments in AI. The thing that we really want to talk about today is vibe coding, and I guess from the hype perspective, is that the direction of travel of the industry? Is that how we're going to be doing software going forwards? But before we get to that, vibe coding is a subset of what we do with AI and how we use it for coding. So I was wondering, from your perspective, are you keeping up with the latest developments? The last 12 months of AI has seen lots of model releases, lots of different tools and technologies. What's your thoughts on that? Are you keeping up any particular highlights from your perspective? I mean, keeping up is impossible. I don't think it's possible to keep up with all the different model release or the toolings or the technique, but yeah, I keep a high level view of what's going on in the industry. And yeah, I think we

2:04are, if we talk in general about model, I guess, in the last 12 months, I think we've reached a level where models are being extremely good at helping us. For example, I'm a code user, I'm using group of their models. So mostly all course at the moment that I cannot tell about the difference between all course 411 and all course 4.6. I know that the metric per me, otherwise, but in general, it works all extremely well. And for the technical work I'm doing, I think I'd be absolutely in your decent days. Yeah, it does feel like at some point, maybe six months ago, it got to the point where the leading models were all amazing, awesome, fantastic. And there was no real difference between them. They were all just amazing. I mean, did you get that feeling as well? Yes, I think it was so good to start with, you know, and it accelerated a little bit. And as you said, I think it's probably in the last six months where they're all super good.

3:04So I remember like a year ago, it was probably super important. You know, everyone was talking about, like, protegenerying. It was super important to to be with at writing your prompts to go well. There are all sorts of techniques like the co-star having stuff like that. And I feel these days you can get lazy because it wasn't so without feeling the gap. So yeah, it's strange, isn't it? Because it wasn't that they hit a certain percentage on a given benchmark. It was just that the capability reached some halt to define points. And almost, it was, it's almost like AGI. And it's not a terribly well-defined concept, but it will happen when enough people believe in it. It feels like we've got to that collective belief with AI flow software development. To be less, I think they're a bit, they show that the model that I've plateaued a bit. So we're not reaching these, sir. It doesn't scale anymore to reach AGI in 2026 or 2026. Yeah, we know like a breaking technique. So I think

4:06all each front, whether I've been people training, whether I've been being more clear or co-be either way. Yeah, so I was going to say, getting back to the sort of the main topic of this discussion, there's a kind of relationship between vibe coding and this sort of tipping point that we've reached in the technology. So it's interesting vibe coding as a concept or at least the term is only one year old, which I guess in AI probably actually makes it feel quite old. So the general concept of vibe coding is you become completely detached from the code. You tell them on what you would like it to do. You observe the output. If it doesn't do what you want it to do, you simply tell the AI, make this change, make this fix or add this feature. When vibe coding first came out, was it something that you became aware of or is it something you've only become aware of fairly recently? Did you sort of dismiss it as that's a that's a hipster trendy thing or did

5:08it make sense to you when you first heard it? I think I was not a very adult, I don't code on a daily basis, I guess. So I didn't even try that as an early adult. And I probably at the time, the model did an update of capability to be able to have rich steps, reasoning to be able to reach the goal that you want it to. They would forget their goal output through the exercise, I guess. So yeah, I think this is something that became much more pussy but the last six months I would see. Yeah, because even though when Andre Kapathy coined the term vibe coding within the the tweet or the post itself, there were notes of caution around how effective it could actually be. But I think six months later, the models become so much more powerful that his original vision of vibe coding became much more real. Another thing we talked about was the adoption spectrum. So the sort of zero level of adoption, you're basically writing code in exactly the same way that

6:10you've always written code. The next level of adoption, for example, is the kind of pair programming through GitHub code pilot. And then there were various people that had published adoption spectrums. But I think the really interesting one, which probably was quite an extreme version of it, was the one published by the Gastown creator. So that has a sliding scale that gets to the point where the top level is multi-agent. You never look at the codes, your speed is the highest priority. I mean, how well does that fit your mental level of using these tools? And where would you set on this spectrum? I think you'd be good to speak for just a few minutes about this. This scale is quite neat. This scale of Steve Yeggy. So he gave you eight different stages of adoption. And you can cut out these three different phases. Like the one phase, you'll see the pilot, you fly, but you have code pilot with you. At stage two, you become a director, you're directing

7:14some fleet of agents. And at stage three, you are becoming like a factory owner, basically. If you think like stage one, two, three, and you're seeing using IDE because you can't want the code at some points, you'll give it all pension to do the modification, the codearity. But you see where you're in the code, and you see actively the code. One become director at stage four and five. What's interesting is the difference between stage three and stage four is you know look at the code. So if you think of your IDE where you've got the agents chart on the right side or the side bath, now you got the code on the side bath and you got your agent chart in the main window. And stage five, you support with no longer care about the ID anymore. You're straight away talking to the agent, he does the modification. You're not looking at the code anyway. You trust the output. The factory program is still a bit futuristic, but some people are already dead. He's where you start to use multiple agents at the same time. At the wall, people do that,

8:16what they can really does to enrich people featuring like at the same time. But that's what stage six is. A stage seven is when you've got more than a dollar of agent at the same time. That sounds scary to me. And the stage eight is when you reach a scale. So big that you need to build your own walkthrough, basically, like guest house. Yeah. Well, what I like about this scale, even if I don't necessarily agree with the specific steps on the scale, I think what it does very well is show that this is a spectrum. And when vibe coding was first coined as a term, it gives the impression that you're either vibe coding or you're not vibe coding. You're doing things the new model way or the old fashions handcrafted writing the code way. And in reality, it is a spectrum that there there are levels of vibe coding. And Steve Jagger's scale goes I'd say almost beyond vibe coding. And it is a sliding scale. So with that in mind, do you expect all software developments to start

9:21pushing further and further up this sort of scale of automation? To me, it sounds like he's seems to be a natural wit. At the moment, they swear that the industry is heading. So company have started moving up in this scale. We've seen some company like a square where could be shingold. I think most of the, they wrote those out stage live. And the sugar quality that stage seeks to be pushing towards the right side with wetland manager fleet of agents, basically. At the moment, though, do you think there are, there are obstacles to moving to the higher stages? So the bit that I get uncomfortable about is when using his term, you know, the diffs scroll by. You simply don't look at the code. It feels like with the technology that we have at the moment, you're still going to hit the same obstacles. And you mentioned this yourself when you talked about vibe coding when it first came out. Your feeling was that it worked for a limited period of time and then fell apart relatively quickly. Now I think you can vibe code ignore

10:24the code entirely for slightly longer period of time. But I think you still get to the point where it's going to be a mess. Is that your experience? Is that your thinking? Yes, I think is the case if you don't have a walkthrough, I guess, or if you don't have some guard radio. And even with this, it's not guaranteed that you get the result you want. We're walking with model which I'm not deterministic anyway. So we're on the guard room that you're going to put it made ignorance anyway. So you need some kind of engineering approach. You can't just blindly direct the AI tool and expect it to create a good architecture or a fault-free code. Yes, I think when we make codes, when they could be cooked chip, what support that is, is not the code. Is it engineering processor? And that's not cheap. Yeah, very true. I mean, as an example, if you vibe code an application, it's your tools not going to ask you, should we write some tests for this? Should we validate it? It will just build it that you have to exercise

11:27your human judgment there. So when it comes to how you approach this, so there are, we talked about Steve Yegge's scale and he created a tool called Gastown which is a relatively opinionated way to manage a fleet of agents to enable more vibe coding style approaches, more hands-off approaches, and there were other approaches like spectraven development and so on. How do you approach this? If you're vibe coding an application, how do you make sure that it does what you want it to do, that it still has enough of an architecture to be able to scale with new requirements and so on? I guess it depends on what you're trying to achieve. Is it something that needs to go in production? Is it like a prototype or is it like a tool for your personal usage? You know, there is on different need for all these different use cases. I back code the same way as I work, but by day today, work, you know, I like to do some upfront thinking gear, which means that it's probably,

12:31you won't probably call that strictly vibe coding, I would say, because when you vibe coding and you get full reading to the model, to the agents, to fill the gap and do everything underneath, probably, and I guess if you are a bit open-ended or how you want to build, certainly definitely so which quality you want to have in the application, whether some of the constraints, you can get results closer to what you wish, basically. Yeah, that's a good point. The success or failure of taking a vibe coding approach can depend on how much thought and consideration you've put ahead of actually typing in your first prompt to the AI tool. You're right, it can feel very easy to just tell it to build my whole application, but from an engineering and an architectural perspective, we both know you'll probably miss the target by quite a long way and how to work hard to bring it back to where you actually want it. Taking a concrete example, I know that recently you were working on a project where it was a tool that demonstrated a

13:36housing planning application process and one of the goals was to demonstrate innovative new approaches to the planning process. So planning process is like many, many processes pretty Monday, there's lots of form filling, there's multiple steps, and there's loads of room for potential innovation through the use of AI or just better software. Now, I know you managed to effectively vibe code a really cool demo in the space of a couple of weeks. How did you do that and how does that sort of illustrate your approach to vibe coding? Yeah, I think I'd like to go back to doing how do you approach the baked cookies? Which technique do you use? They are rich per technique, you could use certain technique like spectra-red abroad brands, you know, you've got an aspect key, you can use B-mad, for example. These techniques are really good and I've got the strong points that are like an approach called research plan and implement, which is the API method. And this is anyway how you tend to walk as an engineer, you always do some research

14:40before you plan and implement. And so I think it feels very natural that the API approach, said that you need to do more good research, you need to understand the domain, then you need to plan the work before it gets implemented. Some considered by Pound was really nice about this, it says, one line of bad research, create a thousand line of bad code, one line of bad plan, create address lines of bad code. So yeah, well you should put your focus on the keeping it up front, I guess. So just out of interest with the research plan implement approach, is that approach that you read about and thought that makes sense? I'll give that a go, or is that something that you just naturally found yourself doing? Because that's kind of the way that you work, regardless of these by AI. Now I actually didn't know if it's thing existing at the time. It's just it feels natural. So in again, my mind is you need to understand the domain, so for that you probably got to be creating certain artifacts to capture the learning you've

15:41done. And you're going to distill that into all the artifacts that you can call plan, for example, take certain information, you distill that into something a bit clearer, but more targeted to what you're trying to do. And then you use this different artifact at different time of the process to create the outcome you want, basically. So talking through this example and the research phase, so this was a tool you had two weeks to create a demo for a planning application. Have you worked on planning software before? The only thing I knew about planning is my neighbor was trying to do some modification. So I received some later from the planning officer to Roger Swine, only knew the walkthrough from the normal walkthrough of the planning application. And you don't think about the domain. So how did you do your research then for this? How did you learn more about the domain to be able to create that kind of domain understanding ahead of building something? So we had some things some experts that were beginning to just give us some very high level things while the actors were the sisters and while the local authority gave me like some very high level black box

16:47but I didn't know how it works inside. But they also pointed up some existing open source. I couldn't part of the domain. So what I've done is I've checked out the code, I called the code and I started doing some domain exploration by running the domain, basically. And the domain exploration, were you reading the code yourself? Or were you laying on AI to help with that? The code was in really on rails, so I'm not to read the Roper, I never read that. But with the help of AI, I could get my way around it. So I was able to run the application, being able to see the database to get the right data, I need to run the application. So if you think it's a table of planning, you need to create some code strategy, you need to have some data inside the product in order to be able to run the workflow. But yeah, with the NPP, I was navigating as if I knew what I was doing, basically. Okay, so I'm assuming then the AI was also a vital tool in this research phase because I can imagine if you don't understand the planning domain, you're lucky in this sense

17:50that there were some open source projects that were quite similar to what it is you were wanting to build. But even then, understanding a code base and a language that you're not familiar with, with a domain you're not familiar with, I'm assuming previously that would have been a few weeks worth of work to start understanding and analyzing the code base. It would have been several weeks of work. Again, your flavor of sort of thing I've done for example. In order to proceed through the workflow, I had to understand how the state machine work because we needed to have certain events that move forward in order for me to progress in the workflow. So I managed to extract the state machine using AI, doing some analysis, and that become one of the artifacts that I used later, you know, that helped me build up my understanding. Then I needed to move the state machine so I could step the database directly, using AI again. Again, when I needed some rest data, the model could generate it. If I needed to see the database, the model could generate some realistic datasets. Any other role we to basically

18:52understand the whole workflow. And to illustrate a little bit more than the study workflow, we would be cookie, screenshot of all the applications as we were progressing because we were making a lot of assumption at the time. And we needed to get them verified with extreme basically of the domain. So one one building I was listening by MAPI, the workflow, we were also annotating each of this screen to where we could see improved learnt. And then we have to ask the expert obviously to resolve our assumption. Yeah, and this is a particular application of AI within software development. I don't think gets enough attention. So for you, you were able to rapidly research a codebase and a domain with the intention of then creating a demo, which you used a vibe coding approach for. But this particular problem, understanding a codebase and potentially unfamiliar domain, this happens all the time in software. One of the main reasons why we we struggle with legacy systems is the lack of understanding of that software system within the organization itself.

19:53It feels like the approach you were taking here whilst you were using it for a vibe coded outcome. This feels important. Yeah, also there was extremely provision to be able to explore an API by using it because sometimes there is a gap between the API documentation and how it behaves and expands. During my research, I was able to write both application, I was able to interact with the agent, I was able to ask questions about the codebase and I was able to extract and there was some information for example, I couldn't understand what's the as is what for perigo fissure and use that to plant and to give their shadowings. And interestingly, in my opinion, when you're using AI for research purposes, it doesn't have to be perfect. Your tolerance for error is higher than your tolerance for error when you're using it to write production code. So it feels like it can be even more powerful. You can give it even more latitudes when you're using it for research tasks. Yes, you'll probably write because all what you trade to do is

20:56reduce assumption. So it's not a right or wrong approach. You're trending towards the truth. So from collecting together some existing code bases, APIs, running the application itself, through the use of AI you were able to rapidly gain a good understanding of the domain and the planning processes. What was your next step? Did you then just wipe coded you version of the application? Or was there something that happened in between? No, there's going to be the in between stage. So you have the research, you have the plant before the implementation. And before the planning added to get my assumption resolved. So we needed to meet with the experts. And the best way for us to resolve assumption was to come up with this walkthrough with screenshots annotated with assumptions that we've put that on a whiteboard and went through that with the clients. And that was really helpful for them to be able to quickly annotate tell us what was dry, what was wrong, but we were incorrectly making assumption. But by the end of weeks, we could

21:57take this big whiteboard walkthrough and turn that into a sequence diagram because these days more than half will seem more than or so. You can transform your artifact into something useful. And why is it useful? It's because if I go as is flow, I can now use it to transform it into to be flow. I just have to inject and make sure a couple of constraints and explain my goals. And I can they write that and produce another artifact for example. I can tell it how I want it to be as a sequence before I find that to model to white code basically. Yeah. I just want to step back something you mentioned very briefly that I still feel is quite important. You mentioned that you created the wireframes and then you got some expert input. And that still feels like it's a really important thing to do because vibe coding allows you to move very, very quickly. But you can still very quickly build something that's the wrong thing or maybe 90% of the way there and that final 10% is incredibly important. So whilst you're very rapidly learned the domain, you've

23:00learned an expert at the end of like three days of a like research. That's correct. And I think that does a thing with all these start coding trends. The only one for me to be very fast is if you are the expert yourself, the domain issue, the product manager, if you're the architect, if you're all these people at the same time, or the ones you need to get the input from the expert. That's an interesting point. And it doesn't mean that you're all of a sudden a lot slower, but you do have to be very intentional about finding the right time to get the feedback and getting the right level of feedback. Yeah, that's really interesting. So you've gone through the planning process. You're now onto implementation. What did that look like and how long did that take? The implementation phase was the most fun part I would say. It's more fun for me because I tend not to cut very often any work, my day to day work. And yeah, I could build some cool thing very quickly. So for this phase, as I mentioned before, I've had my

24:01research. I've decided to several up-effects, super high-reveals sometimes, you know, like design principle, high-reveals, constraints, you know, very high level of thinking that I can invoke at certain time of the process to say, okay, be careful of this. And like that, I could guide the code towards where I want to be basically. How do you know that having a design principles document was the right way to do it? Was that just a guess? Did it just feel like the way to approach this problem? I feel I deal with more than the same way about dealing with colleagues. You know, I don't come up with a full design where everything is wrapped up and people have just had to code. This is not how it works, you know. You have to provide some constraints, some guidelines, some direction, so we formulate the choice. And then you let the engineer feel the gap. And I feel this is the sweet squads we've more than you can. You can just guide them to all cubins, they'll write a little detail and they'll then feel the gap. That's really interesting because that reflects a more negative experience that I had

25:05using the spec kit, which is a quite an opinionated approach to specification driven development. I don't know if you've used it yourself, but it has a very... To a certain extent, it reflects the research plan increment, but it does it in a very detailed, very opinionated fashion. And to your point about the design, it creates markdown files with ASCII art style images of every single screen and the plan stage has code snippets in it. It tries to steer the model with a very high level of specificity. And to your point about working with human beings, it's the kind of level of detail you would never give to an engineer. Yes, I agree with you. I've looked at the spec kit and I was literally convinced, I would say, because it feels like extremely heavy, it feels like water for it really. You get the wrong level of detail super early, and the spec kit approach is supposed to be the fact that you should never throw away your spec. It's as important as

26:05the code, that means you're supposed to review the spec and review the code, and when they model the code was respected, it feels too much effort. It does, and something else you mentioned, that you have experienced in the past 12 months, which I've experienced as well, that 12 months ago, you had to be a bit more careful about your prompting, you had to engineer it a bit more, whereas now it feels like they just understand you so much better, it feels like we have to engineer our prompts less. We're just sort of steering them at a high level, and spec kit feels like it's pushing in the wrong direction. It's not capitalizing all the games that we've had in the past six months. Yeah, I think our pianists probably don't want me to grow into you. Yes, and it feels like RPI, you can describe it in just those three words. You don't have to research a specific way, you don't have to plan in a specific way, you don't have to implement in a specific way. Personally, I like patterns that you can describe in a few words or a sentence, because I think

27:08that gives you the freedom and the flexibility that you need to adopt it efficiently in your given context. And again, back to your actual bike, and you said it was really fun. I mean, what, why was it so fun? I think it's this prompt tool I would call loop. I think it's it's high dopamine, probably. You get through every world very quickly, and yeah, if you see the application, it builds step-by-step. I just don't say because I didn't ask you to build your own for you one course, you know. When you were doing this, this wasn't a, you know, fleet of multi-agents, this was a single agent, was it a Claude code or get a code by a little, it was called by look at the tone. Yeah, so given how quickly you moved, what do you think of the whole multi-agent approach? Personally, I feel that I find it hard to keep up with a single agent and steer it either by planning or steer it by correcting after it's produced it. I find that hard work. I mean, I'm impressed that some people are going down the multi-agent route, but that just feels too fast

28:09for me. It depends what you read by task people. If you're talking about feature level, probably the book or next one, I'd be the planning. If you talk about tweaking the CNCS or fixing this bug, they're probably, you can do that. That's true. That's true. Yeah. But I said, as you don't think I can read the test, I want to make sure that without being walking out, it's completely the tool that I want. Yeah. So I guess the final thing I want to talk about, and I think it naturally follows on from your feeling of it was fun to vibe code this application, that they're the excitement of building something really, really fast. I'm seeing a lot of blog posts and very well written blog posts recently about people finding this new way of working quite uncomfortable. There was one I read a while back about mourning the craft. People are sort of struggling to come to terms with this quite different way of working, and it would be possible to go through all the different blog posts. But one that jumped out at me was one that

29:12was titled, I miss thinking hard, and they described people as either builders or thinkers. So builders are people who get that dopamine hit from creating software, or as the thinkers are the ones that get the excitement out of the cage and the crafting it. Does that match your mental model? Do you feel more like a builder in the thinker? Do you think that that simplification works? I like a bit of boss that I would say I'm pretty more geared towards the builder side. I like to see the outcome. I like to solve a complex problem, and these things I like to solve business problem. How is another? This is probably not as important as they do, but I think it was a bit different. What's your view of that? Yeah, I think it's a good mental model for starters. And what I found interesting is the types of things that I've been building as a hobby have changed. So for me that I've been doing software professionally for 25 years, but I've always enjoyed the craft of software itself. So I've always had side projects. And if I look back five or six years ago,

30:16I was doing a lot with things like WebAssembly and having fun building things like emulators. I was the thinker back then. I was building things for the fun of building it. And with the emulator, I never played any games on it. I just wanted to build the thing because it's fun. Whereas now my hobby projects are, I'm building a thing for logging, carting sessions and so on. I'm actually creating an application where the code itself is boring. It's a crud style application, but I enjoy the outcome. I'm now building things that I use. Whereas previously I built things that I didn't use. It's really weird. I feel like I've leaned more on the builder sign of things because vibe coding has allowed me to build more. Because the custom tool for yourself has never been raw. Exactly. So I think this technology has turned me into more of a builder than a thinker. Well, that sounds bad. I'm sure I still think. But there were so many of these blog posts. You pointed out another one to me that agente code makes old code is young and young

31:20code is old. And what I found really interesting about that one is it looked at the programmers at the sort of different stages in their career. And the people that are at a later stage in their career, that they've been an engineer for a while. Maybe they're an architect, maybe they're a manager or a CTO or whatever else. And they don't have much time for writing code or having written code for a long time. That's the group that seems to be really taking to this technology. It's the people that are in between. The people that are really quite experienced, but still have a deep connection to the craft. Those are the ones that are struggling. Yeah, I agree with you. People have the legacy of their career. They've anyway moved up the abstraction of the year. And they're only doing a lot of prepping delegations. So it feels very natural to use AI the same way as they do anyway. But I think for people who are quite early in their career, they're pretty good at adapting super quickly to this new paradigm. So yeah, it leaves maybe the people

32:23which are mourning the craft itself because I think it is true. If you care very much about the code itself, it is at risk of being politicized today. So yeah, this is a risk for sure. Yeah, definitely. So I guess that gets us to the ultimate question that we're trying to answer. Do you think vibe coding is the future? I think there's a lot of people who are talking about prototyping. Yes, it's definitely the future. You can get something very quick. You don't need to go for a low fidelity stuff anymore. You can show the real thing very quickly. For research, yes, I'm a potential. It's super useful. But I don't buy into the anyone kept code value because it's not just about coding is about engineering. And I think that's what by coding at the moment does not achieve is that engineering thinking. So we're here yet. Yeah. And I completely agree with you. I think vibe coding itself has a fantastic future and we'll

33:26find more and more places that we can use it. But I don't see it as the ultimate destination of all software developments at the moment. And that's something that I think is is a big unknown. I know you mentioned that your feeling is that the model development is maybe it's slowed down and plateaued. If there's a point where it starts to really understand architecture, maybe vibe coding will be able to cover a lot more of what we're doing. Yes, I think as I was the feedback that he doesn't understand is the need of the business, for example, or human needs, and we need to be able to have this human intuition, I guess, to understand what models are. Yeah, absolutely. Yeah. And at the moment, that's one part of the puzzle that they haven't solved at all through the use of AI. Doing some figures chip, but knowing what to do is not, yeah, absolutely. And that brings this month's episode to a rather abrupt hold. Let's have a word with Paul our editor. In truth, Robbie's final statement that with vibe coding, doing something is cheap,

34:29but knowing what to do is not, was so powerful that there wasn't much more either of us really wanted to say on the matter. If you've enjoyed this episode, we'd really appreciate if you could rate a review beyond the hype and help other people tune out the noise and find something of value just like our podcast aims to do. If you want to tap into more of our thinking on technology and design, head over to our blog at scotlogic.com forward slash blog. So it only remains for me to thank Remi for taking part in new for listening. Join us again the next time as we go beyond the hype.