Why the Author of a Coding Bestseller Says Stop Learning to Code | Paul Iusztin, Founder@Decoding AI

In our particular use case, everyone was using MCP everywhere. If you have hammer, you see nails everywhere. Load all the data into the context window, it will just sum up to 64,000 tokens at maximum. The model, if it doesn't find the answer, it will start to query the memory again and again. Zigzag adds extra latency. If I use Cloud Code and I just want to hook to my Gmail, I still think it's amazing. But when you build an application where you have full control over, I would just skip it. Usually answer was more in simplicity.

Today I'm sitting down with Paul Yustin, author of the bestselling LLM Engineer's Handbook. If you have it with you, show us your book. Yeah, yeah, awesome. This book. And he's also the founding AI engineer at a San Francisco startup. He also has a very famous newsletter called Decoding AI, where 40,000, more than 40,000 engineers are learning how to actually ship AI out. That Works. Paul, thanks for joining.

Yeah, thanks you. Thank you for inviting me, Angelina. It's a pleasure to be here.

I mean, you've shared so many interesting things about yourself and I read your blog posts. I have to tell you that you gave me a few laughs reading your blog posts. You told me last time when we met that you haven't done a traditional job interview in 5 years, but you're now a founding engineer at a San Francisco startup. Like, how did that happen? How did you get a job?

I don't think that it's really 5 years, but let's say 3 years-ish, maybe more.

3 years?

But I guess that's not the point. Yeah, so basically I realized that like this LeetCode job interview path is kind of hijacked because there's a lot of competition, you know, if you go in that path there. Many, many smart people who basically will compete with you on the same job positions. And at the same time, even now with the era of AI, like it's just a numbers game. So I realized this like 5 years ago, and especially because like I'm coming from a different background, like from Romania, where I don't necessarily want to apply to positions located here in my country because there are not many positions and the ones that are here are not really that interesting. I realized that I need to go more into the like contracted freelancing route. And very quickly I realized that while doing these interviews, it was really impossible to say what I know in like 30 minutes or a couple of minutes or whatever, right? It's just the game is not under your advantage. And also in the AI space, there are so many dimensions that people can actually ask you questions that is impossible to be prepared and not waste time getting prepared for these interviews and getting asked questions that don't really matter. They're just like robotic questions and robotic definitions that don't really matter. And I'm sure that many people resonate with this. I started like outputting everything that I know on the internet. That's actually my first drive on how I started creating content online. Like I did not have any dream like being a content creator or things like that. I just love to learn. And I did not have really a great time saying what I know in those 15, 30 minutes. And I just started outputting everything that I learned online. That's basically, that was like building in probably public is magic, I would say. I mean, there's no secret recipe. You just need to be like excited about what you learn and just share it online on LinkedIn, on your blog post, on YouTube, or whatever makes more sense to you. And if you keep doing that and you're actually having something relatively interesting to say, like you don't have to invent the wheel or be a genius or anything. You just have— the thing is that many people are going through the same process as you are going while learning. So they will be very interested in what you have to say, even if it's not new, just the experience itself is valuable.

Is that how you land your job?

Yeah, mostly. And the thing is that because my jobs are framed as contracting positions or freelancing positions, I'm not going to the like big tech route. Most people just come to me and these interviews are very basic and they don't necessarily ask me like definitions, like the classic interview to ask me questions to see if I know things because it's obvious that I know these things because of like my online portfolio. And basically they just ask me, how can I help? It's more a business-oriented type of questions. Like how can I help in how much time can you deliver? Yeah. And like, what are the costs for you to deliver these things? So it's more like friend as a service. Then as a job, if you start selling things like this, you basically, you don't go the interview route. It's just, you're just seen differently in the team setup, let's say. Because the reality is that if you go this route, you're not necessarily part of the team very often. It depends a lot from company to company. And I guess it's like somewhere in between, like being a, like the classic interview where you basically just want to be an employee and more the entrepreneurship. It's not necessarily 100% entrepreneurship because ultimately you're just having one client or two clients, which ultimately it feels like a normal job. Like internally, it's kind of the same, but how you sell yourself and how you position yourself in the market is completely different. And again, I don't think this works everywhere. Like if you, what you strive is big tech, most probably it won't work or it will work in very siloed situations. If they really need, they don't want necessarily to fully hire an expert on something, they just need it for a specific project that can exist, but it's not like the, I don't know, the standard big tech dream that many, many people have. No, yeah, personally I don't like corporate, I don't like that fact. So it's just a personal—

when did you, when did you start writing? You publish a lot of content.

Actually, I started quite a while ago, like I think 4 years or so, something like that. But in the beginning it was very basic, like I, I actually started writing a paper out of my master's degree, my project, and I kind of got pretty bumped By the whole academic process. Again, I did not really like it. And I found like this more social media medium, Substack kind of writing a lot more fun and entertaining. And I took that path around for 4 years or so. But at the beginning, it was very basic, not serious. But as things got traction more and more, I started to do it more often. And now I write like on average 1 article per week or something like that.

You also built a large following on LinkedIn. I mean, when you first started posting on LinkedIn, let's say, what did you think was going to happen? What were you hoping for?

Or— I do not know. Like I had zero strategy. I just said, okay, I like to learn. I like to learn new things. I'm really passionate about software and AI. And I just started posting randomly without zero strategy, zero. As I said, I just wanted, like in my mind. I was imagining that I would create like exposure and I will get easier like this, these contracting jobs. But I would have never imagined that will end up like in a content creation education type of thing, which is now like, I did not plan for this at all. It just intuitively got here. Yeah.

Yeah. Was it, was it, was there a moment that you realized that the social posting was actually working? Was there a moment that you feel like, oh, there's a pull?

Yeah, actually, I think the biggest moment was when I managed to like meet people from all over the world and this slowly opened a lot of doors. Like I started to meet people from all over Europe, then started to meet people from the US and got into this, slowly got into this AI community, which felt like amazing. I had these amazing conversations. I felt I was there in the game. It was a lot easier for me, like, to basically stay up with everything that's happening inside the industry. And yeah, to be honest, it's also very engaging to create these LinkedIn posts and see how they perform, how they go, what works.

I really like your post because you have a, you're very good with visuals. I really like your visuals. I feel self-explanatory.

Oftentimes I'm a visual learner. For me, it's very hard to put actually think my thoughts into words, but like visually is a lot easier. It's very intuitive.

Is there a tool that you're using for creating those diagrams?

Yeah, I'm using Canva for now and I'm still doing them manually like a caveman for now. I kept trying to automate this with all these AI tools, but I don't know, it feels like they take a lot of the magic out of it.

How long does it take for you to create one on Canva?

Well, it depends on the complexity, but on the more complex ones, sometimes I stay like 30-45 minutes. Yeah. It depends. Like, it can take me from 5 minutes to 45 minutes. It depends a lot on the complexity of it, on my inspiration, on everything.

Cool. Let's talk about what you're building at the startup. Are you doing full-time right now?

Actually, no, I'm part-time. Otherwise, I did not have time for everything I want. So we were building a vertical AI agents for finance. Like we kept pivoting many, many times because of how the market performs. But yeah, basically we are working in this financial advisory space where advisors need to stay in touch with clients. And there are many things that, many steps that are very like document-based, report-based, document-based. That's a lot of manual work, which can easily be automated basically with, it's not that sexy, you know, but it's exciting. Like the tech behind it, it's exciting because ultimately you need to build a system similar to any other domain. And I think this vertical AI agent space, it's actually pretty like how you build them is pretty much the same with small variations from application to application. In my mind, they're like the new web apps, websites of probably, I expect that these processes will be a lot more templatized as the years go.

Yeah, yeah, that's very— actually, that's enlightening. I mean, it sounds like this is just financial advisors are providing this customer service to their clients and then you're just automating that.

So yeah, in this particular use case. Yeah. But I was saying that I expect that all this vertical AI agents applications, regardless if they're like in finance, medicine, e-commerce or whatever, I expect that many of these applications will be the same as time time goes and how you should build them will become more and more, uh, templated and we will find a blueprint that, that works like similar to how at some point people realized that, I know that these MVC CRUD systems are the best to build like web, normal web servers.

Yeah. Do you, are you saying these templates are going to be like productized? You know, do people are just, you know, instead of, so that non-engineers or non-developers can in the future.

Not necessarily templatized, but like frameworks will find more like go-to methods on how to build them. Probably with all these coding tools that we have today, it's hard to tell, you know, how easy it will be for non-technical people to implement them. That's a very hard question to ask, to answer right now, in my opinion. It's hard to guess, but what I'm saying that just like the framework, the mind map, that you need, like the steps that you need to take to implement these type of things will be more and more known, right?

Yeah.

Because I know one year ago when we started building this, we had no idea how to build vertical agents to like properly do RAG on multiple data sources like documents, images, text, or how to properly do like agentic RAG on top of them. How to plug in at some point audio into all of this and how to expose this to multiple integrations and all of this. And that's basically my article, what it's all about. Like we tried all these fancy algorithms hoping it will work best, but we realized that usually the answer was more in simplicity than following all these fancy algorithms.

What went wrong with RAG in that application? You said you killed RAG.

Yeah, we killed it for not entirely, but for many scenarios we ended up not using because for example, in our particular use case, like every user could like through the UI and UX that we've built could easily like silo the information it has in one chat at a time, right? So that's like how we guided the user. So basically, let's say that the memory itself that's like loaded or you can do RAG on top of, it's siloed by default. And after we really understood our business use case, we realized that for this particular use case, like for most of our use cases, if we load all the data that an advisor has into the context window, it will just sum up like 64,000 tokens at maximum if they load everything they have. And in these scenarios, it's just easier just to load everything into the context window and just pass it to the model. And basically you don't need to do RAG to query only what you need and all of that. And why is that actually ended up doing RAG actually ended up costing more or being slower? Because when you do RAG, you have this retrieval problem, which is actually pretty complicated that you need to pull in the right data. And the model, if it doesn't find the answer in the data it pulled, it will start to query the memory again and again and again until it finds. And this is if you're lucky enough and the agent realizes that it doesn't have the right data and it doesn't start to hallucinate. So it's basically this agentic loop, which is like a zigzag, which just adds extra latency and potentially even extra costs because you do a lot, many more LLM calls to answer your question. And If you do like, if you just load everything inside your context window and you answer directly based on that, yeah, it takes longer and it costs more per that LLM call than doing RAG. But ultimately, if you sum up everything, it's faster and cheap, many times, not every time, cheaper.

And you have agents deciding, making a decision whether, okay, did we get information or not? Then this is like talking to a human, right? If I ask my intern, like, you know, get this file and then make sure, make sure, double check if it's actually the stuff that I want, the data I want, most likely I think the human will go back and double check, right?

Yeah, that's a great analogy.

Yeah, because they want to be helpful and when they double check and they go back and then do it again, which that recursive loop could happen. Which increase your cost and latency. That's what you're saying.

Yeah, yeah, exactly. And that's what I want to highlight. Like technically the problem itself is not fancy, like is a simple problem. Everyone knows that, but when you frame it in a concrete business problem and when you're put to actually solve a real-world problem where you can have so many decisions, right? Doing the right one is hard. Like even it's like choosing the simplest solution is sometimes hard to see through the fog, you know.

I want to ask you, like, why didn't you guys choose the simple solution? I feel like this is a simple solution. How about we just give everything to the, to the LLM and then let it decide?

Well, we actually, because we pivoted many, many times.

Okay.

We started with a more complex idea, like we did not had clarity on our business problem since day one. And I think that's the biggest learning, like to actually frame really well your business problem. But sometimes the issue is that you don't know yourself, your business problem, like this particular context, like we did not know in advance that in so many scenarios, our context window will be, our data will be small. But from what I've seen more and more, like with experience, is that actually these vertical AI agents are true. In many scenarios, you actually have small to medium data and not big data. And all these fancy RAG techniques often are framed for medium to big data. And I also built this Agentic AI Engineering course, which we recently released. Where for the capstone project, we actually did a deep research agent and like an agent that writes professional articles. I applied, for example, did this same pattern here after I realized it. And the thing is that like to write a professional article, you often need as references, I don't know, 5, 6 other articles. And your first thought is that, yeah, if I want this agent that writes this article to have access to all my knowledge, You need RAG, like it's obvious, but no, it was just a lot easier to put everything in there and that's it with some smart prompt engineering, maybe some context engineering, like how to put everything into the prompt, how to filter your data properly, not put everything inside your prompt. It's easier to just take everything and do some filtering than do this retrieval.. And I believe that many, many problems can, can be solved this way, or just do some simple SQL queries with some metadata filters and sorting and things like this. It's just easier, you know.

That's a really good takeaway. I mean, I get it now. So I mean, the team started with this assumption, right? There may be large amounts of data that you need to work with. For this use case, but you didn't know at the time.

Yeah, exactly. And I think that many teams or many people start with this assumption or don't even realize that they start with this assumption.

Right, right. So, so I guess the Silicon Valley, you know, talk to your customers still works, right? Work with customers and then you will know.

But the thing is that we did that, but especially in a startup where you pivot so many times, Your initial customer can be different from your current customer, you know?

Yeah, yeah.

I think— Everything is so noisy and that's why it's hard to take the right decision every time.

I think that's the true and the biggest challenge in like building something. Yeah. Right. That's why it makes it hard.

To take the direction and know what to build is the hardest, especially now when AI can like help you code and build stuff. This is, I think, the most important skill you can have.

Yeah. Yeah. Do you think RAG is dead?

No. No, but I think that it is like an algorithm that you should use when it makes sense to use. Just that.

When does it make sense?

Well, basically, based on what we talked so far, when you have like medium to big data, that's it. Or when you want to be, you're super constrained on your context window. Maybe you want to use a smaller model, a cheaper model for whatever reason, and then you need to be very aggressive on what you put in there. And then RAG is still a good solution. So basically the ratio between your data and your context window, I think that's like a good formula that can find, do I need RAG? Or I don't need React.

You also said you, at least from the blog post, you said you regretted using MCP as well. Well, everybody is so excited about using MCP last year, right?

You should always use it. I also think—

What happened?

I also think it's a good solution. Like I still use MCP, but again, everyone was using MCP everywhere. And I think that's the wrong— I think that that's actually the take of the article. That if one solution is hot, you shouldn't put it everywhere. Like if you have a hammer, you see nails everywhere.

I want to build some agent tech system or whatever AI application. And then I come up to you and ask you, hey Paul, here's the thing I'm building. What's your bet on the chance that I need, I actually do need MCP in my stack?

I think if it's a tool that's very dev-oriented or like for heavy users that, so basically I see MCP as plugins, let's say very intuitively. And you can either use these plugins in dev tools, like Cursor, Cloud Code, or people that use Cloud or similar tools in other setups, because now people started to use Cloud and tools like this in creative work, productivity work, or whatever. Basically MCP is a plugin, but we were actually building a product and we needed integrations with other providers like email and I cannot go into too much detail, but we need integration with many, many, many providers. And we thought that, hey, every provider provides an MCP server and why shouldn't we connect to them through these MCP servers? But the thing is that our MCP server was sitting on our server. And it wasn't hooked like directly to the client, like to the user. It were connected on our server. And ultimately we just ended up like writing custom MCP servers for each of our clients for all this integration. And we haven't used any of them because they were too rigid to our custom use case, or they just did not have, weren't updated enough, or they just did not have yet. An MCP server. So for example, now I still use MCP servers because I'm a heavy user of Cursor and Cloud Code. And when I want like to write myself a custom code to hook them to these orchestrators, I still do that to MCP servers. And now with the skills, Cloud Skills, that's a different path. So you have two ways to do that. But on our end, we had to build everything, the orchestrator, how it uses tools, how it integrates to other tools. So just bypassing all these extra protocols and writing everything on our end, it was easier. For example, if I use Cloud Code and I just want to hook to my Gmail to do some basic stuff like read my emails and things like that, I still think it's amazing. Like I don't want to implement some custom code when I want to hook to every integration with Cloud Code or Cursor. For this use case, as I said, like when it's added as a plugin to other existing tools that I don't have control over as a developer, then it's amazing. But when you build an application where you have full control over, then I don't know. I wouldn't say so. I would just skip it.

But so, so, so it's use case basically. It's use case dependent on how complex your problem, how customized you need it to be.

Yeah. Yeah. But again, that's what we thought. But because the thing is that when you build like your custom orchestrator, if you want like to either choose, if you want to build your MCP or not, then you have to integrate MCP protocol in your application, which adds those extra layers of abstraction, which make the code more complicated to understand and adds more extra dependencies and things like that, which you don't want, especially in this world of AI, you want to keep it as dependency-free and simple as possible so the AI can actually write good code for you and not get lost into so many abstraction layers. If you start using MCP just with the idea that maybe I will use it, maybe I will not, you will just add this extra layer that adds useless complexity. Then it's not like a great thing, gray, it's more like yes or no. Do I use MCP? Or not. So what I see, I think this will help more. MCP is more like a way to serve your code, I think. And it's like instead of serving it as a FastAPI server, RESTful API server in general, you serve it as an MCP server. And again, if you are building the server itself, of course you can connect to other servers. But if you have full control over the code, I suggest And I recommend not to use MCP.

What do you think of the, the, um, the very hot, like, vibe coding tools out there?

Personally, on these, I'm pretty, pretty bullish. Like, again, it's hard to say how far they will go, but I will give you an example on my experience. Like, I don't know how to code frontend necessarily, like how to do designs and all of this. And for example, even for me, like a engineer, they can just extend my skills because I know enough frontend and design skills to vibe code this app, if that makes sense. And like this, I'm really confident that I can like build end-to-end applications with these tools. Otherwise, it will take me so much time to do that manually or even like surgically using LLMs to build specific parts of the frontend. And I started to be more and more bullish on vibe coding. And I was thinking to myself like last week or so that many people complain about vibe coding that it creates like messy code or code that doesn't respect like clean code or good architectural designs and things like that. But the thing is that these designs were made for people to avoid human error. And maybe the AI will not need them anymore. Maybe that's how AI actually writes code and we should leave it. We should not fight it. We should leave it and do its own thing and just adapt and actually create some layers, other ways on how to evaluate and make sure that these systems work properly. Like, in my mind, we shouldn't necessarily force AI to think like us because that's pretty rigid. Like, why we should do that? We should just like find a more intuitive and natural way in ensuring that what the AI builds, what we really want to build then. But I'm not saying that like engineering is dead. I'm saying that it's just like the game has changed. You should be careful at different things. Like you should probably still decide how your system looks like, how like, I don't know, your data models look like, how your data flows, how everything scales, the input output, the business problem that you solve. Like you're still the one in charge that solves the problem, but you're not necessarily the one in charge on how the code looks behind the scenes. Ultimately, now we write Python that's compiled. Many, many times until it reaches bytecode. Do we read the bytecode to make sure it's clean bytecode? No, we just trust it.

And that's a good point.

We can see AI-generated code like just a compilation step.

I don't know.

I'm just saying.

No, no, no. I, yeah, this is very interesting. You were saying, you were saying that it's like, you know, we have to accept the younger generation speaking a different language and then we just work with it.

Yeah, yeah. That's also a great way to put it.

And it becomes lower level and you don't care that lower level anymore. And maybe it's another level that we have to reach and then we haven't developed it before, right?

Yeah, exactly.

Product level, I don't know.

Exactly. And we need like a way to ensure at the next level that everything works fine. And for example, one level is like AI evals. Which basically ensures from a data point of view that your product works fine. Like you don't even need to write like the classic unit and integration tests. You just like from use a data approach based on specific inputs and outputs and ensure that your system works as expected. And me personally, I think AI evals will be a huge, a huge domain in the future. Because if AI can code, then the only thing you can do is to evaluate it and to create a very good signal back to the AI on what to fix and how to fix. And also it's extremely important to know how to prioritize what to fix because we shouldn't expect that we have infinite AI. We know now that with, with I know Cloud Opus 3.6 is amazing, but you run it a few times and you run out of tokens. So it's also a limited resource. So you know, you need to know how to prioritize what to be fixed and how to be fixed and things like this. So we kind of play a finite game, which we should take as such.

Good point. The evals are the new muscles we need to build, which is a lot more, you know, stringent requirements compared with the old, the traditional ways of the unit testing, regression testing. We need to do a lot more, right? Because it's not so deterministic anymore.

Yeah, exactly. From many points of view, they are pretty similar, like with unit test, regression test, there may be big overlaps. But as you said, these LLMs are not deterministic anymore. You also work with a lot of unstructured data like text, images, video, and you cannot just do like an equal operator between two pieces of text because they are not identical, but they are the same, if that makes sense. Like you never expect, I mean, we know it's that you can reframe a sentence in many, many ways and it has the same meaning. So Yeah.

Tell me about your new course, right? So you touched, we touched upon a little bit about it. When is it releasing? Is it on Mavenly?

We actually just released it yesterday.

Congratulations!

Just in time.

How long is your course? Is it a one day?

At the moment we have 34 lessons and it's split on 3 modules. The first one, like, is on the foundations of AI agents. Where we build from scratch all kinds of workflow patterns, agentic patterns, multimodal patterns, and things like that. And the next two modules are the module two is where we build two Capstone projects, which then we connect together. Like there are two agents that work independently and also work together or with a human in the loop. And the third part is where we built AI evals. Monitoring, we deploy them to production and things like this. And we'll keep adding lessons as time goes.

So, so I want to ask a little bit more about your course. Can you share like what are you learning like in your working experience and your building experience for your clients that will actually go into this course?

Yeah, so it's basically that the goal of this course is not to get super theoretical, but to build on an intuition, like a strong intuition on how agents and LLM workflows work. Because in reality, when people say you're building agents, you're either building workflows, agents, or somewhere in between. So we build a strong intuition on what is what, what patterns go where, and how actually to combine them. And then we build these two capstone projects mostly from scratch. We don't use like those agents from LangGraph or things like this because we want to like to actually understand how things work behind the scenes. And I also am a strong believer that you shouldn't use agents from frameworks in your code, even in production code. So they are great for like quickly prototyping and seeing if something works. Yeah, they're amazing. But if you really want to build something like a custom project that's like production ready, you'll most probably need to build a lot of custom code, custom orchestration logic, which those frameworks don't provide. So you actually need this for like to actually build real-world applications. But at the same time, I also think that frameworks like LangGraph are amazing, like to give you an ecosystem of utilities and memory layers and connectors and like retries mechanisms and everything around that. So these frameworks still have a lot of utility in that space. And for example, that's why we use the LangGraph functional API, which lets you like build whatever you want in plain Python code, but they also come with this memory layer checkpoint. So you can very easily debug, resume your code and things like that. So we exposed it as an MCP server. Because we wanted to leverage existing UIs from Cursor or Cloud Code. So instead of building our own UI and own application, we took it like a productivity dev tool. So it's plugged to these tools. And I also liked how we designed this human-in-the-loop system. So for example, for the writing agent, where we took a similar approach to coding, where basically after we have the first article, we implement the editing loops where you can like select what text you want to edit and you send it to the agent and it responds like with a diff where you can very nicely accept or reject what you like or not exactly like coding and things like this. And also I'm really excited about the AI evals section where we implemented very specific custom business metrics. Because in reality, it's not good practice to use these generic metrics like hallucinations, helpfulness, and things like this because they are not helpful. They don't show you any business value. You have a score of hallucination of 8. What does this tell you? Not much. You can just assume what it tells you, but can you go exactly into the code and pinpoint to what you should fix? No. So So you should, again, be very careful on how you build this specifically for your data and business use case. And we also show how to monitor all of this, track it, plug it as offline evals, build some LM judges that are actually calibrated to the domain expert, and also use them as online evals and a lot of things, many things around this space.

So you actually have a kind of like a start from scratch course, not using frameworks, but help people to start building AI agent systems and to get monitoring.

Yeah, exactly. I have a saying that I keep using is I like to teach people how to fish and then they can do whatever they want. Like if they understand the decision process, because we kept talking about this. If they understand the decision process and understand what to be used where, then the tools are not that important. You can either write from scratch, pick a tool, pick an algorithm. That's actually easy now. With AI, it's easy to implement this to some extent, of course. But knowing how to pick what, where is the hardest part. And that's what the core of this course focusing. And you can be like a complete beginner when you start and we take you from beginner to advanced.

So non-developers can also attend?

No, you need like some Python and LLM knowledge before. It's not like a complete beginner. You need to be like a developer, engineer, data engineer, data scientist, or some knowledge before. Like we go straight, straight into it. You know, total time with the basics.

Okay. You know, if a student comes up to you and then, because there are, you know, many AI agents courses out there, right? If a student comes up to you and asks you like, what can I do after I take the class? What's the before and after that you can tell them?

Well, you will have 3 projects that you can show, like 2 that are built. With us where they're basically what I explained. I don't want to repeat, but, and also you need to build one project of your own. So basically you've built a full portfolio that you're like, you will put on GitHub and you can show to your future employers or your future, or if you're going the contracting route or online route, your future audience, who knows. So, and they're not like basic. We use, for example, notebooks just for teaching. These are full-fledged Python projects that are like shipped with UV, actually shipped to GCP with authentication user layers and everything. So basically you can just take this framework and go at your job and implement agents for your company.

Do you feel like in today's job market, this is like, you know, building your own portfolio of these AI projects is necessary for like looking for a job or? Looking for freelancers.

I think they're the default of what you need to do actually to consider applying somewhere, right? Like, if you don't have this—

What about university? Like, what about like graduating from a university with a master's or bachelor's in computer science?

Maybe if you graduate from like Stanford, MIT, and these top universities.

Yeah.

That counts. But if you like graduate from a normal university. I don't know. It's again, a default, like you need to check, okay, degree, projects, and then we talk.

Okay. Yeah. That's a good takeaway.

That's how I see it.

You know, engineers is like designers. You kind of have to have a portfolio, like a pamphlet, a book of portfolio to show.

It's just like, exactly. Like, right. Exactly. Otherwise, especially in today's market. If you don't have like a minimum of proof of work, then it's hard.

Yeah, yeah, it's hard. And when you show a lot of your like proof of work, like how you did it, then you get people reaching out to you.

Yeah, exactly. But you need to put in a lot of work for that.

How much work is that? How many years of work is that?

Well, I started like coding pretty heavily like 10 years ago and I like work 10 to 12 hours a day from Monday to Saturday, something around that. Maybe not every day, but something around that.

What about building in public? Like when, ever since you started sharing, when did you feel like you started having these inbound queries, inquiries?

It's really hard to tell because it's not like a hard line, it's like a gradient. But I think that even after a few months, they started to show. So, but as you go up and up and up, uh, better deals start to come up, you know? So it's a process.

Yeah. It's a process.

Yeah. But for, for example, for, for me, like one of the biggest breakthroughs were after I wrote my book, I had one of these, uh, like big breakthroughs along my career.

So writing a book is also a good idea potentially.

Yeah. Yeah. But it's hard and it's a gamble.

Right.

Okay. I did not, again, I did not have expectations that my book would do so well. Like I had zero expectations when I started writing it, like completely zero. I said, okay, if I sell 1,000 copies, I will be extremely happy.

Yeah. And you're a bestseller.

Yeah. We sold like over, like around 20,000 copies. Actually, me and Maxime are starting working and discussing about a second book. Which will be around agentic AI engineering. Who would have seen that coming?

You have to write it now. Yeah. Yeah. Tell, tell me about it. What's your plan? When is it coming out?

I cannot tell too much because we are still like cooking the idea and we are not yet sure on many decisions. So we are actively cooking on like the outline and everything.

Okay.

But basically it'll be around agentic AI engineering and it'll take a similar approach to the course that I just explained, like Again, taking someone who has like zero experience in the generative engineering space and like building up the whole landscape, but around a project similar to the first book, because I have seen that people really like this approach of like actually building one large project where we show how to connect all the dots on how to collect data and not just, okay, we pull this dataset from whatever. On how you actually collect data, on how you actually clean it, use it to fine-tune specific models, to build the memory of your agent, to ship your agent, to build orchestration, to do AEBLs and everything that you need to actually build agentic applications.

I'm curious, like, I know that last time we talked about you chose to stay, I think you, you're moving to Portugal, right? And versus you, you could have come to San Francisco and you chose Portugal. Why is that? Well, your startup is in SF. Why aren't you coming here?

Yeah, well, actually, I like Europe. I like the lifestyle from Europe. So that's one big, big, big choice. It's also very hard to move continents with everything. Also in America, you need a visa, which makes everything more complex. Yeah. And I like my remote style work setup. And if I'm not constrained to be there, to be like in the office and all of that, personally, I like more like to work by the sea, by the ocean, like in a more like in a more relaxed environment. I don't like big cities. Okay. And agitation and things like that is not for me. So it's probably like a personal lifestyle that I chose. But at the same time, Portugal is very connected to everything. Like, timezone-wise, it's closer to the US, it's closer to Europe. So I can very easily like run a remote business from there. Now in Romania, it's pretty hard because like it's at the Eastern most eastern part of Europe, mostly. So it's trickier. And also in Portugal, it's cheaper to live, lower taxes. So it's like people who are familiar to like digital nomad type of choices.

They're all moving to Portugal. I have a family friend who actually took the whole family from Silicon Valley to Portugal. Really? Yeah.

How does it feel?

Yeah, he's, they're very happy about it. Yeah. So I'm thinking maybe that's the way to go, but, but, but here's the thing, right? A lot of people are thinking about Silicon Valley. Do you feel you miss out on not being in Silicon Valley or does it really matter?

Yeah, I do feel that I miss out. And I think that when I made this choice, like I need to be very conscious about it. Like when I do have this feeling, I need to like understand and be honest with myself. It's okay. I choose this. It's a trade-off. It's a bet. You know, you cannot have it all. And the thing is that, again, for my type of like work and lifestyle, I thought a lot and I don't think that I need it. Like there are of course some pros of being there, like being more connected to the community, having a lot more easier access to all kinds of conferences and things like that. Otherwise, like for example, the cost of living is higher, the taxes are higher, everything is higher, which means I will need to reflect that in all my prices and everything, which will make my business less competitive at the same time. So I ended there, there are trade-offs. And again, me personally, I'm not that of a people person that much, like in the sense that I'm an introvert and I get very consumed by Meeting people. Yeah, yeah, when we meet people often, like I love discussing, but now I need 3 times of recovery or 3 days of recovery.

I think a lot of us grew up, you know, being told to think about long term, right? But technology and AI are moving so fast now. Do you feel, is there even a long term anymore?

Well, it depends a lot on how you frame long term. I also like to think long term. I always think long term, but It's hard, yeah, to know what long-term is. So maybe 5 years is long-term thinking now. And I like this way of thinking that it's okay to have a vision, a direction on where you want to reach and like a few key bigger points that you want to reach. But to reach to that point, you need to be extremely flexible. I think Jeff Bezos said this, like you need this trade-off between, okay, you have this set of values and you want to reach to a specific point, like that's the long-term plan, but to reach there, things change so often that you need to be super, super extremely flexible. Like I never imagined I would do content creation 2 years ago or 3 years ago or something like that. So I guess you just need to adapt.

How I grew up, my parents would tell me that, you know, your goal is to go to the best universities and then go work for Google or one of those big companies, I think it's really hard to imagine. Like, I don't even know what younger people today is going to think about when they graduate, what they're going to do, right? Yeah.

That's the hard part.

What should we do?

It's harder to think about it.

Do you have any advice?

Like, I love what is happening at the moment, and I think that AI can like make you like a superhuman in so many ways. Especially if you're more into like a more entrepreneurial, creative way where you want like to do a lot of stuff on your own. But I think that the most, the biggest advice I can give is just learn how to use AI first and own a domain. Like be extremely good in a specific domain rather than know how to code and things like this. I think that's know how to solve a particular domain, whatever that is, medicine, finance, e-commerce, education. For me, it's education right now with AI. And if you go down that route, it will be very easy to adapt. That's how I see it. It's hard to predict how things will look like, but if you have the domain, that's a thing that's extremely valuable. And most, you will still need like Humans will still need doctors, like whatever happens, but how doctors will look like and how hospitals will look like with that, don't know yet.

Yeah, we don't know. We'll see. Thank you, Paul. I think you are one of the rare, you know, engineers who build your, uh, you, you build your AI career from, from somewhere, as you said, the scene was zero, right? No AI scene over there in Romania. And you wrote your best-selling book. I really— it takes a lot of like energy to build and share, right? And especially if you say you're introverted, right? I, I gotta believe that must be scary when you first start posting.

I'm like, yeah, it was terrible, right?

It was terrible, right? Like, I have no idea.

I was super anxious.

You were? You made it.

Like, I still am when I have to do a video, things like this. Like, I need 50 minutes of preparation.

I know how that feels and I feel that as well. And thanks for sharing that. It's really important for everybody, like all the engineers to reflect on like what they're doing, what they can, what more they can do, where they should go and thinking of like overcoming these mental barriers of moving forward.

Yeah. But like to conclude, I'm not demonizing like anything, like even big tech or Okay, we're not saying anything's dead.

Big Tech is not dead.

Yeah, yeah, of course.

Blogging is not dead. MCP is not dead.

Nothing is dead. It's just you need to take decisions on what actually aligns with your true self.

Right.

If that's not like too, too vague or whatever, but some people might like one thing, some people might like other thing.

Right.

You shouldn't take like the path that your parents told you, like go to the best university, go to Big Tech. Go and work at Google and that's, that's the path.

This is the opportunity. Now is the opportunity to be yourself, maybe.

Yeah. Right.

Let's hope so. Let's hope so.