The Vibe Coding Security Risk Nobody's Talking About

If human contributed 20% of the work and you think we can still put our name on it and claim that this is our ip, we did it. Can we?

So it's these kind of things. Like at the end of the day, it's more about putting your own stamp on whatever AI generates and making sure that you still feel like it's within your own brand, within your own voice, within your own way of working.

I want to ask you about your opinion on Vibe coding.

I think it makes senior engineers. If they're 10x engineers, they become 100x engineers. If they're 1x engineers, they become 10x engineers. If you know how to use it effectively, it can definitely speed up your workflow significantly.

I remember a Stanford professor mentioned about the most productive way of working with AI is not treating it as AI assistant, but treating as a human like collaborator.

It's something that basically fills in the skills gaps or is something that boosts your strengths. Like right now, the most of the hype at the moment is agentic AI, because AI agents are essentially a system prompt with tools and memory and data sources. You connect together.

If you were to build AI product, what would you build?

I think at the moment the ideas that I had was to hey everyone.

This is two set AI and today I'm sitting down with Ali Parande and who is the author of this book I recently got, which is an amazing book of how to build generative AI services with FastAPI. And today we're going to cover Vibe coding and the reality of agentic AI. So, Ali, welcome, welcome.

Thank you so much for having me. Angelina, thank you very much.

Thank you for coming. And before we jump in, could you share a little bit about yourself and if you're building anything, can you share with us?

Yeah, sounds good. So I'm Ali Parande. I'm actually right now working as head of engineering for an AI data science consultancy based in London. Essentially I come from a mechanical engineering background, chartered engineer with UK Engineering Council. But then essentially I transitioned my career into AI. And throughout this transition I have worked on a lot of data analytics and AI applications, including computer vision, rail tech. And now I've been working mostly around generative AI, in particular working with LLMs, large language models, building generative AI applications for enterprises across variety of sectors. Software, cybersecurity, finance, retail, education, aerospace, all of these different areas and transportation. Effectively, last year I've been basically thought, what if we had like a whole resource where I could have all of this gathered in one place? Especially for people who Do a lot of backend development like build APIs. And essentially the work of that was basically this book building generative AI fast 10 pieces with fast API which puts it all together into one resource for anyone who wants to build production grade AI services on top of these gen AI models.

So this book is 10 years of experience actually building.

It's years of experience building some of these services essentially.

Yeah, yeah. In the last two years you're focusing on AI applications.

Yeah. Basically since ChatGPT came there, most of the focus now have been more around building AI agentic applications around these model providers.

I feel like it's a transition from before ChatGPT. It's more about machine learning, more of the modeling.

Yeah, it was a lot of classical AI modeling and also a lot of software engineering doesn't go away, but it was a lot of classical AI modeling, software engineering, putting it into like services and also computer vision as well. And those things are still very relevant today, especially in engineering sectors. They still used quite a lot in all the other sectors are used quite a lot. But right now the most of the hype at the moment is agentic AI and I think that's basically where there's still a lot of potential to be unlocked.

Yeah, it's the keyword of 2025.

It is the keyword of 2025 exactly.

Yeah. I want to ask you about your opinion on Vibe coding. So I saw a stat that says Y Combinator. They reported 25% of winter 2025 startup batch, had 95% of AI generated code bases. What's your reaction to that?

It's crazy. My own opinion of the fact that is right now, these days I also do wipe coding. I think it makes senior engineers. If they're 10x engineers they become 100x engineers. If they're 1x engineers, they become 10x engineers. If you know how to use it effectively, it can definitely speed up your workflow significantly. The only caveat with the wipe coding is you need to be careful that it doesn't make decisions for you because if you just ask it to build your feature, it's going to make a lot of architectural decisions for you. And if you're not cleaning up after the agent has done its work, if you don't refactor you don't put it into modular places or even don't instruct the agent to put the code in center places, you may end up with a very messy spaghetti like code base that only the agent can now understand. You don't. And that's the Recipe for disaster as you start growing your application.

Absolutely.

So I think it is the way to work. Definitely. Like there are those who don't use it. I wouldn't say they made left behind, but essentially you can actually increase your throughput of how many features you can deliver if you know how to use it effectively.

I remember there was some news about Lovable. Their security concern is pretty high. I remember seeing some stats of 10% of their applications in production are having some security issues as well.

Yeah, it is actually a concern because to give you an example of why it could have security issues, one of the places where you can do white coding, for instance, is when you're building user interfaces. Like for instance, if you're building with a framework called Next js, which is used quite a lot in building dashboards, building dynamic applications. To give you an example, I asked it to connect my form with the backend to submit some data. Like when you're building username password forms, which is like a lot of the time using every app. So that kind of stuff you want to automate to Copilot for sure. Yeah. With Next JS you can actually connect forms on the browser, but what that means is your backend tokens will be exposed to the browser if you're not careful. If you just ask the copilot to build you the form and connect it, it will use the browser to send data and you will expose your API tokens. And you have to know like it's doing it. You have to know how the framework works and ask it to now actually do it on the server, not on browser. This is like how security issues pop in because the agent builds the functionality. But if you don't understand how the code works, you are unintentionally exposing your API tokens to the browser which anyone can steal and start using to authenticate with your backend.

This is one of those things that you don't know what you don't know exactly.

That's why it's always important to go through the process of if you're starting with a framework, start practicing with it, learn it as you go and learn from the copilot, but read the documentation and learn the documentation in full as well so you understand how the framework works or how your technology works before you start throwing Copilot at it. Because otherwise, yeah, it may end up making decisions and you don't know if they are secure decisions or production grade decisions. And you can make mistakes as well. There have been many stories of people on Lovable working with or on replit, people have dropped their production databases. The agent has dropped their replit. Yeah, they dropped their production databases and like people are like going crazy on.

So what's going on. Yeah, and making up. They can make these mistakes and stuff like that.

Yeah, exactly, that's right.

Yeah. That's all of scary stories for sure.

Yeah, it's very scary.

So in a sense vibe coding or these tools, it is democratizing software development. Would you agree?

Yeah, definitely. One of the things I've seen it does is people who had ideas but they didn't have technical co founders or technical people around them or people who would be happy to jump in the ship with them to do like startups together. Now they can, they can essentially create prototypes which they can pitch investors. Then they can use that to show that the technology is working so that they can get funding to actually bring on like engineers to build it properly. And then on the other way around, the same technology as using technical people to help them with other skills around business. Like for instance how to help them do sales and marketing better, how to come up with a strategy, come up with pricing models. So it's essentially empowering both sides to be able to build businesses from scratch if they're alone by themselves.

So from that perspective, do you think that is when wipe coding can make sense?

I think for building prototypes or for building, for testing out the technology is definitely the way to go. So these days you have replit, you have lovable that can build applications for you completely with databases and everything. You also have Figma make, which is another web coding platform that takes into account all the nice UI side of things as well. So you can actually get it to wipe code. A whole really nice dashboard and UI that wows people. Like people want to be like oh my God, look at all these animation animated components and look at all these dashboards. And you can also connect it I think on the backend Supabase, which is like a database provider. Right. And you can literally build full on apps but you can't go and tell this enterprise grid, you can't go and sell it to enterprises and say oh give me £100,000 a year and here's an app I built. Yes. Yeah, because you don't know. Yeah. If you don't understand the code and what it's doing and don't prompt it to go down those routes, you don't know how to for instance integrate authentication providers, combine it with other bits and sometimes it doesn't actually follow your instructions really well. So we Call it alignment. Sometimes the alignment isn't good with these barcoding tools and it's all to do with the capability of the models. But their models are getting better and better every day. So we don't know what's going to happen in the future.

So you're saying we can use it for demonstration purposes or startup business before you get a technical co founder, you can build it.

Exactly, yeah.

And then go from there.

Exactly. It's one of the best things for it like at the moment why Combinator keeps telling people to either build or talk to users. Now you can build fast on features that you don't know if it's going to be important to users. You can build that feature quickly on a weekend and then show it to some users and get feedback to whether you should actually invest time and effort into building it properly.

It's good for iteration. Fast.

Exactly. It's really good for iteration or if you're running against deadline. So let's say you have a Sprint and you have a week to deliver. And some of the features, when you sit down and you think about it, it doesn't come to you. You don't really know. For instance, you need to do some kind of data wrangling and write some SQL queries, very complicated. And either you need to go sit down and learn the SQL or you can easily get copilot to write the SQL for you to do some crazy aggregations. And for these kind of things, it's really good. If you're coding inside VS code and you just need a feature implementer, you need an endpoint implemented that will have some complicated logic. You can get it to implement that logic for you, you grab a coffee and you come back and you can see what the logic is and you can clean it up and actually do your own input into it to make it production ready. So a lot of the Pareto principles, which is basically the 8020 principle, applies to this as well, which is it can only take you 80% of the way there. The last 20%, if you want to make it enterprise, Great, the last 20% is going to be still your effort.

And someone who truly have a technical background and who truly understand.

Yeah. And for those who don't, they can actually still use it to build prototypes, they can build applications and actually to some extent some of these applications solves the problem for them as well. So they don't really need to go to enterprise, they don't really need to make it scalable. They might want to. Maybe they want to build Themselves an AI agent that makes them ads, so they can scale at advertising or they can scale their content gen and that's enough. They're not going to sell it to someone, they just want to use it themselves. They want to build AI automations and this kind of stuff. Doing it yourself might be very hard and you have to learn a lot of things, but if you're running against time, you have deadlines, you don't really enjoy the process of building it. You can just literally delegate these things. Now with wipe coding, I feel like.

It'S changing how everybody's working. If you know how to use it.

Yeah, exactly.

Let's not think about scaling it, let's just think about how can you work better or work smarter, more productive.

Exactly.

So definitely has its value. Where do you think the appropriate boundary lies between this rapid prototyping and production development? I saw a quote from Simon William. He says if you have reviewed and tested and understood AI generated code, it's not vibe coding. He doesn't consider that as vibe coding. He said it's just using LLM as a typing assistant.

I think it's very similar to people who write with AI. If you sit down and edit the code and you spend some time like making it your own, at the end of the day I think it's a valid opinion because pretty much if you're going to put it out there as your own, you're going to put your name on it. That means you do the Q and A on that code or you do the Q and A on the content. Even if you're using it to write some copy or some content, as long as you sit down and read it and make sure it's with your own voice or with the way you write code. Yeah, it is a valid approach. You can essentially use that to scale content generation. Scale code. With content, it depends on the policies of your company or the policies. If you're writing a book with a publisher, it's a policy to a publisher. With publishers you can sit down, AI generate the whole book. You need to actually just use AI in certain places if you need to reword stuff, but not necessarily writing the book. And with content, with code it's more simpler because there is logic to follow. But with content it's a bit more subjective. And human generated content compared with AI generated content is quite different because with human generated content, the longer the content becomes, you can still see the flow, you can still see the story. But with AI, it keeps bursting around in different places. You keep switching subjects, it doesn't have the tangents that human content has. So human content keeps jumping to like it goes into some interesting tangents time to time. We call it burstiness and perplexity. So perplexity would be like how varied the vocabulary will be. And burstiness is like how you jump around and how the flow would be around the content. So it's these kind of things. Like at the end of the day, it's more about putting your own stamp on whatever AI generates and making sure that you still feel like it's within your own brand, within your own voice, within your own way of working, essentially.

I really like your analogy between this generated content versus generated code. I feel like essentially the same thing, right? You do have your judgment on what's good content and what is this is garbage or something like that for your work. You have to be responsible for your own work.

Yeah, exactly. It is like you're going to put your name on it. So you need to, even if you use computers to create the output, you need to quality control the output as if to make it your own. And the other thing as well is. But like it's all about productivity too. So Yeah, a generative AI can take you 80% of the way there, but to make that last 20%, it's where a human in the loop comes in. Which means any AI application that you build, any AI apps that are out there, should give users the ability to be in the loop and edit the content, update the content to get from 80% to 20% because Gen AI still cannot take 200% straight away.

The role for humans are playing are going to be more like an editor. We're going to be editors. We're not going to exactly the drafter. The first draft for everything. Perhaps it's for everything.

Yeah, exactly. For instance, with blog posts, instead of sitting down and writing the entire post yourself, what you can do is you can just write the outline of what you want to say and how the flow is going to be. So you write the plan and then the AI drafts the whole thing and then you just edit it to make it your voice. So this is how you save the time. Rather than get the AI to generate the outline and the plan and then you sit down and write the whole draft. So it's going the other way around. Like most people just go to ChatGPT and say, oh, give me a draft, give me a plan for what I need to write on this block. And AI comes up with the idea, but then it should be the other way around. Where you write the entire flow, the entire story, like in terms of an outline and then AI fills the gaps and then you just go in and edit it so, so that it makes it a bit more human. It becomes AI augmented. That's basically where we're going with both the content and code. Yeah, so with code actually your prompts will be very descriptive. You actually need to be like a product manager, explaining the feature and explaining the approach of how to build it. But not necessarily sit down and write the endpoints one by one, like specifying what status goes each endpoint needs to deliver. But you specify, I want you to do a models py, I want you to do schemas py, I want you to put stuff in this, dependencies this way and then do that and then talk to database this way. So you just explain how it needs to work and then the AI will then talk, looks after your code base, figures out how to wire things together and actually does the work for you.

Yeah, I remember someone, I think a Stanford professor mentioned about this, how the best, the most productive way of working with AI is not treating it as AI assistant, but treating as a human like collaborator. It's like you're an intern, you gotta teach them how to do it.

Yeah, exactly. Yeah, it is an AI collaborator. So it's something that basically fills in the skills gaps or is something that boosts your strengths. So if you have weaknesses in any areas, whether it's like within, for instance business related skills versus technical related skills, AI can come in and fill those other gaps that you have. So you can either come in and help you speed up your current strengths or you can come in and fill those other gaps that you currently have and help you be able to still deliver the outputs that you need, even though you may not necessarily have that person currently helping you.

Yeah, 100%. If human contributed 20% of the work. And you think we can still put our name on it and claim that this is our IP?

We did it 10 weeks, so it depends. For instance, there is an app called Suno. Now on Suno you can go and drop lyrics, you can describe like the genre of the music and it can create the music for you. Right, but is that music really your IP at that point? Can you call it your ip? Can you then publish it on Spotify?

Yeah, we're talking about blog post code and now music.

Yeah, yeah, because it's content and we're talking about content. Code, music and text. They're all content, they're all data. So if you generate the Data, it depends on the licensing, how that model has been trained. So it becomes a bit like a gray area. Because if a model is generating text versus a model generating music versus a model generating video, what has it been trained on? Has it been trained on for instance, open source data or has it been trained on like private data? Yeah, proprietary data. Because it's just mimicking back the patterns. And if those patterns belongs to someone else, like originally those patterns you can't like really call it yourself. That's why it's always safer option that if you want to put out a book or anything like that, the safer option is to try to make it more human. Like basically make it most your own than necessarily just use AI to help you with rewording things and helping you plan an outline and research than necessarily AI drafting everything. But if you're just posting on social media or like you're doing a blog post on your website or anything like that, like things that people don't really care about, they care about the content more than about the.

Where it's from.

The factual. Yeah, where it's from those things. Yeah, it's fine with those. But if you're trying to sell it, you're trying to create like a textbook or anything specific that's way more academic, those kind of things that needs to be way more human than actually AI generated. So there's a fine line. And also you need to look at the license agreements of whatever model provider you use. So for instance, SUNA doesn't let you keep, doesn't give you full on commercial licenses for doing anything with those AI generated musics. But if you want to just you put their music into an ad or you want to just use it for a music video, yeah, you're fine. But if you want to sell it on Spotify, then you may have restrictions around that both on Spotify side and on the SUNO side.

That makes total sense. So did you use any AI writing this book?

So I didn't use AI to write the book, I used the AI to help me research plan the outline. And I think that wherever there were places where I needed to perform a definition or I couldn't get the paragraphs out, I would use AI to reward it into a simpler manner. Or for instance, one of the problems I faced with the book was when I originally wrote it was 600 pages long and I need to drop hundred pages. So I had to make some bits of it more concise. That meant that I had to go back and perhaps help with the help of AI try to like condensed down saying fair. If I was saying three concepts in three paragraphs, say all the three concepts in one paragraph. So that's how I used AI. 500 pages. Yeah. It is quite like a half a tombstone.

Yeah, exactly. It's pretty.

You can, it is pretty versatile. You can use it as you can read it but then once you finish reading it you can use it as a reference book and put it underneath your monitor if you need to lift it up. It's always exactly works.

I can use the. Right now let me do that. Yeah. Awesome. Do you think engineers. I think you covered a little bit about this but I still want to ask you, do you think engineers or a subset of engineers are going to be obsolete?

So the problem here at the moment is the factual thing is there has been news about it as well. I think it was in Guardian library is that. Yeah, the number of junior engineer jobs have dropped significantly and a lot of companies are doing redundancies because of AI. So the reality is there, the main thing is for people, if they want to future proof their career, it's more important to accept that yes, AI is affecting jobs at the moment, but the main thing is to future proof your career is more about being able to get on their wave and try to use AI and be more like power user of AI. Those people who use AI are the ones that get ahead the most. It doesn't necessarily matter that the jobs, all the roles will be affected to some extent but it can also help junior engineers put outputs out that are similar to cds. So it can also make them essentially produce Apple that are senior quality and make them more versatile in different areas. And if there are any skills gaps they have, they can also use AI to learn patterns that they didn't like. They need a senior engineer to learn from from previously. So it's both an opportunity and a threat I would say at the same time. But it is just a technology. And I think the other thing as well is companies need to understand that for seniors at some point they were juniors. So you can't just have seniors first. So you can. Yeah, you can't just have seniors. You need to also develop the juniors and you need to also bring in juniors to help the develop the company further. Both like developing people's careers from junior to senior. But also for companies it's cheaper to train juniors to become seniors than hiring seniors from outside because the seniors will demand higher salaries. So it's also on the business side it's a more logical decision to also not Just necessarily drop all the junior roles and just focus on seniors. Perhaps if they restructure the business in a way that allows for junior training, they can still bring in juniors, help them put senior level outputs with the use of AI, but then also develop the juniors into seniors over time. Otherwise we have an issue with supply and demand. There will be a lot of demand for seniors and then we don't have enough seniors because yeah, we haven't done the junior training for the juniors.

Yeah, you guys are going to extinct.

Exactly.

You also mentioned about alignment issue. In your experience the through prompt engineering or context engineer, the AI isn't following the instructions. How do we what's your opinion of improving it?

So essentially with alignment it depends on first of all, I think as models progress and they get better, a lot of the model providers and model builders like OpenAI, Google, Meta, all of those will try to figure out how to improve the alignment at model layer. So at neural network layer. So as models improve their alignment might improve as well. It might not be necessarily as much of an issue. So as we can see, latest models have way better like more commercial models have way better alignment. So they do follow exactly what you want. They're going to be non deterministic in nature. So every time you prompt them, you might not necessarily get the same consistent output. But alignment is more about whether it has followed all your instructions. The best way to understand alignment is to try to generate images. So if you put, if you describe your dream house and you try to explain in detail, listen to how your dream house should look like and then get a generated output of your dream house, like an image, does it exactly look. Does it actually have all the stuff you described? So if you describe in the image that I want to have a giraffe in the middle of my house, like an area where I can store a giraffe, like I want to have a zoo, does it actually, has it generated it so that you can actually have a giraffe zoo in the middle, right? Or if you want to have five helicopter pads on the top, does it actually have five helicopter pads? So if it doesn't have. Or if you tell it like here's a picture of a wine glass, can you fill it up to the top? And if it actually does that, can it do it and does it have it done it. So alignment is more about has it followed every piece of instructions you've given it? And also the capability of model to follow instructions when you give it some input, has it manipulated that input in a way that you don't want or has it followed your instructions and the constraints you provided. So at model layer it can improve. But the other best way that you can improve the alignment is to not confuse the model by providing it lots of instructions. So treat any language model or any model like a junior intern. So there's very ambitious, very attentive and very motivated intern who's just joined your company, who's working for you, just for you, helping you, like your best employee of the month assistant. How would you describe tasks to them? Like you describe tasks to them in a way that help them understand it's very clear. And you do it step by step. And you don't give them like five pages of documents all at the same time. You try to drop feed it to them. You can do the same with these models. So don't go and give a very vague task with lots of text, maybe perhaps break it down step by step or maybe ask them to think about it step by step. This is called chain of thought, prompt prompted. And some models, some thinking models does that already under the hood. Or you can break down the task and instead of giving it all at the same time to the model, give it to them in separate prompts. So let the model do the work on one task and then give the next task. And then they give the next task and then also provide as much context as you can. So it's called context engineering, essentially. So the more context you can give it, the more examples you can give it as part of it. Here's an example of how you should respond or how should process the output. The more you can explain the reasoning, like for instance, crunch the data like this. For me, those things will essentially help improve the quality of the output and the alignment for you.

That's really good advice. And I wouldn't give my intern 500 pages and say, follow the instructions exactly.

They would just get confused and they would come back to you in five days and say they didn't understand their instructions. Or they may produce something that you didn't want.

The nuance is whether I give him or her two pages or ten pages. That's the nuance. Is your suggestion test it out or is there some framework or best practices out there?

So the best way I found is to always follow the best prompting practices, which is to normally provide tell the model the Persona that they have, like the role. So your role is, for instance, if you're building an AI judging system, tell them you're an AI judge or you're an AI assessor. Provide some context around what their task is and then give them the task or give them the task and then provide some context. So I call it the RCT framework or role context task. And essentially this is the easiest. But then you can also provide other prompt elements. Like for instance, what constraints does the model have? Are there any constraints? Are there any output format you want the model to follow? Is there any tone that you want the model to follow, like for instance, for your brand or things like that? Are there any examples you can give? Can you separate the instructions and the examples and stuff with delimiters? And can you use prompting techniques like chain of thought or few shot prompting, like these kind of like techniques decompositioning or ensembling. So there's all the different techniques. One is about breaking down the prompt into multiple prompts. One of them is about like asking the same, asking them all to do the same job five times and then checking their responses, compare the outputs together. So these are the different techniques that you can follow to essentially help you improve the output quality. With these, with these models.

Did you cover some of these in your book?

Yeah, so I've covered all the prompting engineering. I essentially used the source. I think there was a resource called learnprompting.org I think that people behind putting that source resource together, they also did a overview study of all the prompting papers, all the paper, all the actual academic papers on prompt engineering. They wrote their own paper that was like a high level literature review of all the prompting techniques. And they created like mind bumps. And I basically used that as a. I basically tried to simplify that into a few tables of comparing these different techniques together. And this is essentially the kind of things you will need to do if you're building AI agents. Because AI agents are essentially a system prompt with tools and memory and data sources. You connect together.

Right. There are a lot of human instruction and orchestration.

Exactly.

Deep thinking has to go into the design of that, the whole system. And that's where your brain.

Right, exactly. And like most of the time these days, the coding of AI agents will be essentially writing good system prompts. And there are actually resources on GitHub that have open sourced some of the system prompts of existing tools like ChatGPT or Gemini and stuff as well that you can use to see how the applications, how these application developers have actually written system prompts for their models to be useful for the users. So system prompts are very important. And a lot of the times that developers sit down and create agents, it's more essentially about figuring out how to write the system prompts. And combining that with traditional software engineering.

It sounds like we are guaranteed to have fairly above average good interns. And then we are all learning to be a good manager.

Yeah, it's all about becoming a good manager. So breaking down problems for them, explaining the problem, simply explaining the how approach simply. And the more experience you have, the better prompts you can write because you have more experience explaining how to do a task for the model. So again, domain expertise becomes very important. Because if you don't have domain expertise and you're trying to write a prompt, you just say, build me a chat app. That's your prompt. If you don't have experience, you just say, build me a chat app. But if you sit down and learn about it or if you research about it, then you can essentially break it down a little bit. You might say, okay, instead of building a chat, build me user interface where only two people might chat with each other and it needs to be real time. And then essentially you can edit the chat, explain the requirements a bit more in detail. For the model. Maybe I want to use a postgres database. I want to use a relational database here, maybe just have a messages table and a conversations table and model knows your architectural decisions and it just essentially works against those constraints and gives you something.

Okay, AI agents. I read that Gartner predicts 40% of agentic AI projects will be canceled by 2027. Is that based on what you're seeing in production? Does that number feel optimistic or pessimistic or do you believe it?

I think it might be like a learning curve that organizations are going through. Normally with any new technology. You need to experiment with it to see what works, what doesn't. And maybe some organizations are optimistic around all the things that it can do and then they realize later, oh, actually maybe they can't do that. And I think there is also the 8020 principle happening here where they felt like, oh, it's going to take us to 100% automation and it doesn't, then might need to be a human interloop process still to quality control the checks. Like for instance, it cannot generate your ads out of the blogs and you can just post those ads. It may not necessarily be good. Those ads, they still might need to do some filming, you may need to do some editing. All of those things that requires human input. Even with the latest image generators and video generators like Neo3 and Nano Banana. The problem, they're like Google models. I think this is basically what's going on with these. And then the other thing as well is a lot of these enterprise language model chat applications that enterprises are building, they may work for small number of data sets, but then as you scale it to millions of documents, that's where you hit scalability issues or you hit like indexing issues with documents when you're trying to index them for the chatbot. And these are the bits that were unknown. There's mostly unknown for a lot of people because not a lot of people have had to deal with these problems before. It's not documented in knowledge bases around the Internet. And I think they're hitting these kind of issues and they realize that, okay, may need way more R and D or made more development costs than we originally thought. Like for instance, as the number of documents increases, it becomes much harder to figure out what to retrieve from the database For a user query, it would get a lot of confusion. So you may need to go back and figure out how to chunk it better, chunk the documents better for indexing or how to index them better. Maybe you need to use a different indexing model, maybe you need to do other things, maybe you need to re rank the documents coming back from a database for better output. So all of these things are things that organizations didn't consider before that might be also specific to the use cases. But I think over time as the community gets more experience with these application architectures and there will be more knowledge bases and sources out there, it becomes like a normal thing. It becomes another discipline in engineering data science for instance, or come to a vision, it becomes just another discipline building AI agents. And it just need, it just needs to be like an expectation management setting when you're defining projects, how much effort might be required. So like some of the adoption barriers with most of the organizations at the moment is either they don't necessarily have the talents that build to help them build scalable applications like this, or the people who are writing the business case to understand the AI as much around their constraints, limitations, capabilities of these technologies that recently came out, either because they haven't had much experience with it, or there is not much resources out there for them to find out about it. It's like very novel and I think these kind of things and then all the data isn't good enough. And so all of these things contribute to barriers to adoption and failure rates.

Essentially based on what you're seeing, what's the maybe average AI literacy there is in organizations for adopting AI? What does it look like? Is, is that a barrier?

It is a barrier. I Think it's also culture as well. But I think it, it's, it's different market to market. So from what I've seen engineering in industries like traditional engineering, the market is still quite young. Like they're still picking up AI and like most of them don't know exactly what it is. Like they don't exactly know how language models work. Like they don't, it's like.

Which industries.

You'Re talking about, like manufacturing, like civil engineering, mechanical engineering, those kind of industries. Well whereas for instance in law or in advertising, marketing, finance, these markets are way more mature when it comes to data science and AI. Like they already have started playing around with these tools way back before ChatGPT. So they are, they have more experience with data science and AI that has been trained on data, like traditional machine learning for instance. So these industries are a bit more ahead in terms of understanding at the business layer what the capabilities of AI is. And even with generative AI they have been more forward in terms of being able to have actual use cases for this. But a lot of the other markets are catching up. So it's like the various market by market and company by company. But I would say a lot of companies these days, especially at the higher levels, at senior leadership level, a lot of them do understand to a basic degree the data literacy and the AI side of things and their capabilities and limitations through either reading blog posts, there's a lot of people on LinkedIn posting about these things and there's a lot of resources out there it constantly use time to time. Maybe not at the detailed level, but at least at the highest level. Most of them have some awareness of this. I would say.

What do you think will be the next use case that's catching up to let's say software development Copilot coding assistant is the first and then maybe like customer service is the second one. Those are the two big ones.

So I think at the moment the thing that's going to get probably more popular adoption is definitely AI assisted programming. So I wouldn't call it vibe coding, I would call it AI assisted programming because it means that even people who have experience with it, they will be using it by coding may not necessarily. Barcoding has a basically the perception that you're just sitting there writing project managing AI. Whereas AI step programming could mean that you're actually writing some code, but you're also like telling AI to do some bits for you, for instance, to write you to fixtures, write you tests, write you like a piece of endpoints that are just Boilerplate, or you don't want to do it yourself, you just want to delegate that. So I think AI assisted programming, which also includes vibe coding, that is becoming, it's going to become the norm a bit more as organizations start playing with it. Even governments have looked at, they investigated the use of AI system programming and I found productivities have increased, like by multiple percentages across all their development teams. And they're considering essentially adopting one of their tools and they're looking at what tools to use for this now going forward as a standard for all of their development teams. So it is here to stay. Like the way, like the whole workflow of working is completely different. I think the other trends that I see happening is essentially not necessarily using AI to do coding for you, but AI living within your terminal. So some people have experimented with cloud code, giving it access to their internal operating system, to their computer's operating system, and then talking to the operating system. For instance, if your computer is slow, you can go to the terminal and say, why is my computer slow? And then AI will look at the processes, reads the processes and reads like the CPU utilization and memory utilization and things like, very cool. And they can essentially tell you, oh, you've got some zombie processes going on. Like, zombie process is basically a process that have been sitting around consuming resources but not doing anything. For instance, let's say you've run a Python interpreter, you forgot to close it, or you're running a node process, you forgot to close it, or it didn't close properly and it kills them for you. And then your computer speeds up. Or like it can find you large files scattered around your hard disk and helps you clean them up if they're not used in the past. These kind of issues, if you have malwares in your computer, you can identify it for you, like, oh, there's this thing, it doesn't have any publisher or anything like that. Like, it looks so suspicious to me. Maybe delete this one. These are like the next trends, essentially. AI not just operating in a code editor, but AI operating at the terminal level. Literally, like helping you organize your files, helping you find issues with your operating system, helping you deploy applications using terminal and writing you, helping you write bash scripts on the fly to do bulk operations on your hard disk, for instance.

What about industry verticals? Are you seeing any trends? Like any industry verticals is up and coming?

Yeah, definitely. I think there is still a lot of niche to be explored with AI. Even some of the existing explored niche, like for instance, Lore already have a lot of people still complaining that the AI hasn't solved their problems even with all of these VC backed companies like they're seeing that these applications that are existing today are not exactly solving their problems and companies are building their in house tools. ChatGPT, Gemini, Perplexity, all of these applications they have been horizontal use cases. So across all the markets they apply. So just general productivity. Copilot is all about general productivity. But what we haven't yet seen is vertical based use cases of generative AI and agentic AI in particular multi agents where they each talk to each other and do stuff for a specific workflow for instance. At the moment the more successful ones happen in logistics, distribution. There have been in law, there have been in like other industries. So basically there will be a lot more opportunities for people to essentially build agentic AI applications in verticals in niche areas. So AIs that do form filling AI that do like a specific AI automation for a specific industry and a specific workflow. So workflow automations using AI in like very niche verticals. And that's basically where we haven't seen. Yeah, we're going to see a lot more innovation.

Yeah, if everybody is automating their own workflows, it's personalized, it's super hyper personalized but it's not scalable, it's not a company coming up with a micro SaaS or small thing that they're selling. It's not coding copilot, it's across all industries or customer service bot. Everybody needs that.

Yeah, everybody needs that. So horizontal is all about everyone. It's all about like use workflows that everyone, everyone writes emails, everyone needs to go to events, everyone needs to go on meetings. These are all like horizontal. So if you build something around that, there's also a lot of people building on that. So you will have a lot of competition. But there's also a lot of, and there might be a lot of tools for everyone to choose from like AI meeting transcribers. Like there is a lot of tools. Most consumers will have difficulties choosing which one to use. Horizontal is very popular because also a lot of people use, but you also have a lot of tools and a lot of competition. Vertical is where there isn't a lot of competition, there's not much knowledge. But you also need a lot of domain expertise to understand the workflow to be able to build with it. You also need private data that you may not have access to. So in order to actually write the system prompts for AI agents, you need to understand the Workflow, but also have data to show it. And that data you may not have access to it because it's locked behind the company's internal systems that you are not an employee of to have access to. Yeah.

If you were to build up AI product, what would you build?

That's a good question. I think at the moment the ideas that I had was to essentially do verticals. I'm still doing research in these areas, but I think maybe I do something for the legal market, for procurement markets or like essentially a B2B area, if I work on any B2C might be around education. So essentially helping more traditional engineering companies learn more about data science and AI and essentially scaling my education that way because my background is mechanical engineering. So I know there is a lot of use cases to be unlocked in engineering sectors and key sectors in the uk, which is construction, transport, manufacturing, those kind of sectors that are still new to AI and like they need a lot of education before they can start using it in more engineering use cases. But also I think in a lot of areas where we have a lot of text being produced, unstructured data, AI language models can be really used these days to provide structure to unstructured data. And agents can really use help with AI automation, especially if it's multi agentic applications where each agent specializes in one thing. If you can build platforms that can automate things but also give human in the loop, give humans who are responsible for those workflows the ability to audit and Q and A and take their outputs from 80% to 100%. These are essentially the kind of tools I would say I would work on. And I think at the moment I have. I don't really know which one will work.

Are you going to build some?

Yeah. So essentially next year I'm planning to work on a few of these and see which one sticks. I have a few project ideas and I'm actually going to try to see and invest my own time and money into building some of these prototypes and see which one sticks.

Yeah, when you're ready to build or when you're already building in the middle, come back and then chat with us and then share.

Yeah, definitely. I will show you demos of this.

So.

So the thing is I know both backend and front end so I can build really nice dashboards and like really nice user interfaces. But also I know how to build the back inside of it, use a fast API and models and maybe perhaps fine tune something to actually make it work. So I would be able to build, I think my biggest Problem. Normally my skill is not in marketing. In sales, I don't really know how to. Yeah, I don't really know how to do. I need training to understand how to do sales and distribution or how to do customer research, this kind of stuff, partnerships. So I think I'm more like a builder than I guess, sales and marketing, that kind of skill set. I guess I have to develop our.

Audience really love the design thinking into building these things. So share how you design it, how you're thinking about doing it is really valuable.

Yeah, exactly.

Can you share your recommended tech stack for building reliable, production ready AI agents?

Oh, absolutely.

So Fast API is one.

I know.

What else?

Definitely. The thing is, I've written a book on Fast API, so I'm going to be biased and say Fast API. If you're a Python developer, Fast API is definitely the way to go because it also comes with all the ecosystem of AI libraries. So if you need to do custom ML saving, custom ML models, saving open source models from Hugging face, which has 2.5 million models on there, you can just pick one and start saving it. I would say Fast API is really good for general purpose backends that also can be built into AI services. So these days I just use backends mostly in Python, but I'm also exploring looking at backends written in Go because Go can compile into a binary, a very small binary. And I've seen startups run their entire backends on a free instance on cloud environments. These startups are charging enterprises 200 grand a year, but their entire backend runs for free. They have 80 tables and they have like hundreds of endpoints on these backends and they are running the entire thing for free because it's been written in Go. So I would say yeah, Go is good, definitely the back end language. But if Python. The thing with Python is you can both do data science and then you can do application development in it. So my tech stack these days is Fast API and I've built it in production. I've built several apps in production with fastapi that are being used today with generative AI and I can attest to it. It's really good and it's the modern tooling stack for building backends on the front end. I have experimented with Astro JS as a framework, I have experimented with Remix and I've experimented with Next js. And I would say these days I would just go with Next JS as a Go to. It's a framework built on top of React, which is a library for building user interface components and the framework gives you the ability to implement page navigation, routing, page routing, caching and having an API inside the front end if you want. So it's actually a framework that can allow you to build the entire full application on the front end without needing a proper backend. But you can also just not have used the API layer and just focus on building user interfaces on top databases. I normally use postgres or relational databases but sometimes you need to use non relational. For instance if you need to have a content management system, right? If let's say you're building a course platform for Those I use MongoDB or one of these document based database. If I'm using AI agents and they need to have an indexed series of documents, I use a vector database. There are many options here. My pick would be Quadrant is a nice good production grade vector database or whatever the cloud providers provide some of the time cloud providers also provide their own vector databases that might be more well integrated within the ecosystem. And for cloud stack I would go with either Azure or Google Cloud. Most people might have built with aws. My preference is normally Azure because enterprises, a lot of enterprises use the cloud. If you build on Azure it also helps you basically sell to enterprises much much easier and it deploy for them much easier. But also some enterprises use Google workspaces so if you build on Google you're also good to go. A lot of startups use AWS because most devs is one of the first cloud providers to come and a lot of developers are more comfortable with it.

Good point. I wanted to ask you. This is a kind of a digression. I've been experimenting with NAN for orchestrated AI agents. What do you think of nan? It's great for prototyping I have to say. But reading your book, right? Yeah, tell me.

So NATN actually provides you an open source. So it is open source to some extent. You can actually deploy it self hosted N8N platform and I think it's N stands for nodemation. That's what N8N stands for. So N and then the 8 is basically the characters in automation. So it's called nodemation because it's a node based platform. So it's nodomation. That's basically what the founder described it as.

Okay.

I think at the moment is the most advanced AI automation platform that gives you lowest level access that you need to have to build automation. So if you're a non coder and you want to have a lot of flexibility in type of automations you build N8N is the way to go. If it's too much for you, you can always use nic.com which is another AI automation platform, but it's way more beginner friendly and it allows you to learn how to build automations, even more complicated ones. And it also gives you the mental models that you need to build automations. For instance, how developers need to work with APIs of model providers. Once you're more comfortable and advanced with make.com you can then graduate to N8N because NHTEN also allow you to code like it's called a low code automation platform. So not no code but yeah, it's.

Optional, you can add a lot.

It's way more powerful. It is definitely way more powerful because you can give agents memory, you can give agents databases, you can connect agents together, create workflows, create loops. So you can pretty much build what actual developer might build, but without coding by just connecting nodes together and defining conditions and defining iterations.

But would you say that for personal use it's great for internal use it's good, right? And for scalability? I don't know, I haven't thought about that. It's mostly for personal use. I think this is easy to look at what I'm doing and easy to look at my design and improve the results rather than focusing on coding.

Yeah, I think if you're a business for your own business, yeah, it's definitely useful. You can even like scale it to internal employees and I think you would scale it enough for everyone. If you're a startup that like building an AI SaaS app.

Right.

I think it depends on the scalability of N8N as a compute provider. So you're essentially relying on N8N to provide the compute for you so that you can essentially scale that as number of users for your startup grows, number of your customers grow, I think it might be scalable. I wouldn't know that. You can sell it as enterprise solution to enterprises. You might be able to depend on the licensing agreements and also depends on the scalability there. But I think it might be something that you can monetize for sure. You can essentially create an automation there and then package it into a product and sell it. But because they also provide you the ability to self host, you can essentially create your own AI automation with a self hosted instance which can scale on the cloud. So you can essentially scale the compute and not buy compute from anything directly, but essentially just buy the compute from the existing cloud providers. But that does require some essentially deployment knowledge and DevOps knowledge for sure.

And one of the things that I feel some of the audience will ask because a lot of people are transitioning from different careers to AI engineer. Like for instance, maybe they're data scientists or traditional software engineer or machine learning engineer, especially for DS or ML es. They're not thinking of security. This is not their scope.

Yeah, it's not previously.

So how do I even start thinking about security when I build an AI application?

Yeah, I think pretty much if you're going to try to build applications to sell, you need to have security baked in. If you don't consider security, enterprises will not buy from you. Like they will have questions that will get you and then they basically won't buy. And B2B is where you can actually generate enough revenue to sustain yourself. It may not matter as much with B2C but at the end of the day, because you're handling personal information, it might be handling GDPR data or data from users. If you don't have security in mind, you will get into a lot of legal trouble. And essentially the fines that you may get and all of those things and the trust that you lose, all of those will essentially could damage your reputation. And it can also basically fail the endeavors that you have. So it is actually very important, especially the more you go try and try to sell to enterprises, they will definitely ask you questions about that. And language models are have vulnerabilities, same as web applications. So there is a really good working group on the Internet, they called OWASP that they have cataloged all the vulnerabilities of language models and generative AI along with vulnerabilities of applications. So in web applications you still have vulnerabilities around SQL injection, cross site scripting attacks, cross request forgery. These are all various popular vulnerabilities that you normally need to take care of when you're building apps. But with language models you also have securities around agents. So if you're building agentic applications, people can still do prompt injection. They can try to override your system prompts, they can try to inject code into prompts which then the model executes on downstream services and cause problems. They can try to steal your model system prompts, which can be an intellectual property of your application. They can try to send too many requests to your application that your model fails to respond to other users that need it. So it's called model denial of service. If you give your agent too much autonomy, it's called excessive agency. If you give your agents excessive agency, what ends up happening? Is the agent can drop your database table makes a mistake. And if you're given the agents right access to your database, it can end up dropping your database table because some user ask about cleaning their data, for instance, they may think that they gonna need to truncate their data. Let me just truncate the entire users table, right. So it can make these kind of mistakes because the LLMs have these kind of vulnerabilities. Like we do need to make sure that you have guardrails in place. So guardrails to check for hallucinations on the output side, guardrails to check for competitor mentioned for toxic outputs. Like sometimes the agents may go wrong, especially if using open source model that is uncensored. They may go rogue and start insulting the user or saying things or going off topic. These are essentially things you can do to guardrail the model, but you can also guardrail the model on the input side. So validate the inputs coming in, validate and make sure that there is no malicious code in there. There is no malicious attempts at prompt injection. And even if it's not necessarily related to security, people can still misuse your systems. So people may use it to generate propaganda, they may use it to perform cheating on exams, or they may cheat with things, cheat interviews, cheat exams, cheat processes. And they may also use it to be dishonest to scam people. Like some companies have been scammed millions of pounds because other people have used image generators and video generators to fake themselves against some other person in the company. You will receive way more scam emails that are super realistic because of AI.

And images and even videos and sound that people.

Exactly. And all of those things could get you in trouble. As an application provider to building applications.

It'S more vulnerable than hardware.

Or it is. The other thing is with code like traditional software, you run code and it always gives you the same output. If you run a random function, it will always give you the same random number within something. If you go and ask AI to give you random numbers, you may not necessarily get something random. Also if you rerun the same prompt multiple times through AI, it will always give you something slightly different. Models are getting better at being consistent, but they may also make slightly different. So if I ask a model to give me a score between 0 and 10 and I don't specify how you should give me score, sometimes it may say three and sometimes it may say three 10, three out of 10. So if I'm doing some kind of regex to extract scores, I may not necessarily be able to grab One of them, because sometimes the output might be slightly different. So I always need to do more prompting, provide jsons to it and stuff to make the output a bit more consistent. So these are like the kind of problems you will face with these type of models. They're not deterministic. Every time you run them, they may give you slightly different outputs.

The other thing is it's hard to expect what can go wrong, right?

Yeah. And also you don't know how people might use it. You don't know how the model would do this. So observability becomes very important. There are tools out there, like there is pydantic lockfire that can really help you with pydantic AI to really see how your agents are communicating with each other, understand, observe and evaluate models. Different models might also perform differently. So you always need to have lots of good logging and monitoring and error handling in place around this type of models. And then the other part is because security is important, you also need to have good testing strategies in place. You have the normal traditional software testing that do unit testing, integration testing, end to end tests. But one of the types of tests that are quite new, and this is I think based on a paper called the Checklist Framework, it's called behavioral testing. And you need to perform three types of separate tests that I talk about in the book. One is called monument functionality testing. So what do you really need your agent to do and just test on that. So does the agent actually return the apples that you expect? That's called minimum functionality testing. You have two other types of tests. One is called invariance testing. If you play around a little bit with the inputs, do you confuse the model or not? So if you expect the model to give you the same outputs, it's called invariance testing. So you those type of tests that you just change the input slightly, but the output should not change. If I change the vocabulary from American English to British English, the results shouldn't change. That's an example of an invariance test.

It's like the traditional in finance. We have a lot of stress testing. We stress test the more it is.

A part of stress testing, but we call it behavioral testing because the test case could be slightly different to how you do it. Like for instance, I may put some dictation mistakes in there and it should still give me results. Or I may change the British English to American English and it should give me results. Your use case might be different. This is just like a general generic use case. And then the last type of Testing is called directional expectation testing, which is about changing the direction of the input and the output should be change in a certain direction that you expect. To give an example, if I ask the model to give me a simpler simplify this text I should expect the output to be shorter in length. So that's how the direction would change. So you can write actual unit tests. You can write actual tests that can be automated to run these kind of tests for you on a model in case that you decide to change the model in the future. And you can even do test driven development with this type of tests on language models. They're still not going to be 100 there. Sometimes you need to run your MFD test your minimum functions test like 10, 10 times again and again on a model to make sure that every time you're getting consistent, you get a statistical confidence that the model is working. Because they are probabilistic models, they are statistical under the hood.

What you said in the past five minutes, I don't think a non technical vibe coder would know. It would have.

Yeah, this is. This might be something we caught for like a technical.

Exactly. So it's a good starting point. For instance, like reading a book like this. Like your book will help them to at least have a decision tree, have a path. AI is very helpful in learning so we can learn everything, like learn anything much more easily. If I don't understand paragraph in your book, I would pass it to AI and then have it explained to me and exactly be a foundational knowledge. It can help me. In the old days, I don't even know who I can go and ask. Like I don't even know what level of the question. I can just check stack overflow and things like that. Now I get answer directly. So I find that really useful.

Yeah, it's really good because it can either help you simplify a piece of text, elaborate on it, or even give you examples. If I talk about a concept and you don't really get it, you're like can you give me examples? And you can generate examples straight away on that piece.

So I think what typical users or practitioners are looking for is not the details. We're looking for guidance. If for instance your book lay out the path of teaching me where to go, what to look out for, what question to ask is more important than just giving me the answer.

Yeah, all right.

Yeah. Yeah. Thanks so much. Thanks for sharing your book again. I really enjoy reading the book. I feel like I could build something just by reading through your book because you covered Pretty much the end to end on building an application or using Python. So I find it really helpful. So thanks for sharing that.

You enjoyed the book and it helped you. Hopefully it was clear enough for you to be able to get the whole process end to end. And yeah, the way I tried to write the chapters was like concept and then practice, concept, practice. So even people who don't necessarily have a technical coding background, they can always just read the conceptual stages and then move to the next chapter without missing much because the practice stage is more about four people to see. Oh, so this is how it's done in actual code.

Yeah, and I can hybrid use it as well. For instance, I don't. And let's say I need to catch up on security and let's say I'm using NAN to build my pipeline or my backend, I can still use the knowledge in the book to look for what should I do to beef up my security in whatever I'm building.

Exactly, yeah. You can use it as a reference because it's summarizing the research in all the areas. If a chapter is about testing, it gives you a summary of the whole field and then the AI related bits.

I feel like you shared a lot in five minutes. I feel like we can have a whole course talking about online security vulnerability and the solutions and everything and show examples.

I think it can be like a whole. It can be like a whole mini episode on itself.

Yeah, I know, I know it's running late for you. I really appreciate your chatting with me today, Ali. I really enjoyed chatting. I feel like I learned so much.

Yeah, it was really good. I think it was like a combo of both technical and non technical in all the different areas. So it's quite good. I know we originally said we would like to cover two episodes but one. Right.

We can have multiple. Yeah, we can definitely. There are other topics like how to productionizing your application and things like that.

Yeah, that would be good.

Yeah, that could be a good one as well. So you can talk more about the technical details and even show some demos and whatever you're building as well, right?

Yeah, definitely. I think from what I've seen in the past, like companies reaching out, they were actually interested to see like the more of the technical side around real time models, concurrency testing, security, that kind of stuff that they were really interested in.

I'm curious, are they asking these questions because they want to build in house?

They're building in house and their devs don't necessarily know these bits. Like they don't know like they only know about HTTP protocol. They don't know what websockets are or they don't know what server sent event is. Like these are protocols that are still on that are used on the web but not as much. They're mostly used in real time apps. But you can actually stream tokens to the browser for when you go on.

ChatGPT and you get streaming the chat.

Without those protocols, like you're sitting and waiting for one minute for all the text to generate. But you don't necessarily need to do that because the user can just get the tokens coming into them. So these are the bits that they were interested in because those bits were how you can actually stream the model to the browser directly.

I see. Okay. It's very nuanced thing.

It's very nuanced, yeah. Or like how can you save one model to 10 users at the same time? That kind of stuff. Like your GPU can only fit in so much. So these are the bits that people are interested in. Like they don't want to get 10 users, nine users waiting while one user is being saved.

You should plan a course. But I feel like it's a whole lot to cover.

It's a lot to cover. Yeah. I think I covered it to some extent in the book. But yet these things can expand really nicely. They can be whole course on itself. I think one of the things I was planning next year is when I have a bit more free time I would essentially I have a book website, it's called buildinggenai.com and I would try to expand more content on there on this. So expand what? AI concurrency is how to build your own MCP servers in fast API.

That's a good topic. I want to. I don't think I have time. There's MCP, there's ACP, there's A2A.

Yeah.

It's like a protocol is also complex. So what are we gonna do?

I know. There is also another one I learned today. Google did is payment protocol or something. I don't know, Agentic payment protocol, apc.

All right. Okay. That's crazy.

Oh, it's horrendous. Too many to be fair. I think all of them are just. They're patterns. They're not protocols. They call it protocol HTTP is a protocol. Not these things. It's just patterns, I think.

Yeah, yeah. Anyway, this one sounds cooler. Yes. It's definitely. It's very confusing for practitioners who are just getting and trying to learn to build more time spent on learning and then fixing things and observability and maybe all those things rather than writing boilerplate cold. So that's the reality of a developer today. Yeah. Thank you so much. I'll let you go. I really enjoyed chatting with you. One last question. Do you have any discount code you can share with my audience?

Yeah, we can, we can do a reply all to Nicole and her and basically say we just did the podcast together. Is there a discount? But from O'Reilly, we can share with the audience.

Okay. Awesome. Sounds good. Thank you so much. And talk to you.

Yes, thank you very much, Angela.