The Leanpub Podcast 🎙 Feat. Fiodar Sazanavets, Author of Production-Grade Python, LangChain & LangGraph

Len: Hi, I’m Len Epp, co-founder of Leanpub, and in this episode of the Leanpub Podcast, I’ll be interviewing Fiodar Sazanavets. Fiodar is a senior software engineer specializing in AI systems, distributed applications, and data-intensive software. A former Microsoft engineer and four-time Microsoft MVP, he has more than a decade of professional experience designing and building production systems across a wide range of industries. You can follow him on X at F Sazanavets, and on LinkedIn at Fiodar Sazanavets, with a dash and an I in Fiodar. Fiodar is the author of the Leanpub book, Production-Grade Python, LangChain, and LangGraph, a deployment-first handbook for developers who know Python syntax but have not shipped Python. In the book, Fiodar writes about how AI engineering is becoming one of the most valuable and in-demand areas of software development, and how Python, LangChain, and LangGraph are core skills for building the systems behind it. In the book, you’ll learn how to turn basic Python knowledge into production-grade backend and agentic AI applications that move toward an engineering niche centered on building and controlling AI, rather than competing with it. In this interview, we’re going to talk about Fiodar’s background and professional career, his book, and at the end, we’ll talk a little bit about his experience as a prolific educator and author. So thank you very much, Fiodar, for being on the Leanpub Podcast.

Fiodar: Hi, everyone. I’m happy to be here.

Len: I always like to start these interviews by asking people for their origin story. So I was wondering if you could talk a little bit about your background, where you grew up, and how you built yourself a career as a software engineer and now as an AI engineer.

Fiodar: Yeah, sure. So I actually grew up in Belarus, and I moved to the UK in 2001 because of some political situation. My parents were quite actively involved in the politics, on the wrong side of the politics.

Len: Got it.

Fiodar: This is how I ended up in the UK. I did a degree that was just vaguely related to computer science, but wasn’t actually computer science. So my bachelor’s degree was in biology, and my master’s degree was in environmental informatics, which was kind of a combination of environmental science and computer science. But from a computer science perspective, it had nothing to do with software engineering — a little bit of project management, a little bit of just conceptual knowledge of how relational databases work, and quite a lot of things specific to geographic information systems and how to use software to analyze satellite images.

I managed to get a job that was directly related to this after I graduated. So I became a flood risk analyst, which was in high demand at that time. It was back in 2012. The UK actually flooded quite heavily that particular year, but there was only one problem with that. I really loved my job. It required a master’s degree to get in, but the pay was lower than I could have gotten without any qualifications, just doing night shifts in a warehouse. It was bad. And I thought maybe that was because it’s a graduate scheme, but apparently not. I spoke to more senior colleagues who have been with the company for six or more years. I spoke to people from different similar companies. It appears to be that it’s just a dead-end career.

So I started to research what I could pivot into. This is how I started to teach myself how to code. My employer at the time kind of accommodated that because I could have just built some extensions to the existing flood risk analysis systems, and this is how I started. My first programming language was VBA in Excel, and then I moved on to VB.NET, which used to be popular back then. And this is how I moved into the .NET ecosystem, which I’m going to talk about shortly. The .NET ecosystem was something that I spent most of my software development career in.

Once I was confident enough in my programming skills, I started applying for pure programming jobs. And my first — well, it wasn’t actually pure programming, it was something similar to a forward deploy engineer, but the term did not exist back then. So the actual role was called Implementation Consultant, but it was all about software development — going to client sites to develop the software. And that was .NET related. It was using a language called C# for programming. And for those who don’t know, .NET is basically this tech stack made by Microsoft. These days, it pretty much only uses C# as a programming language, but back in the day, it used to be VB.NET, it used to be F#. But the common thing between them is that they compile into the same kind of executable. You write your code differently, but it’s not your code that you wrote that actually gets executed. It gets first compiled into an EXE.

Since then, I have been doing very software-focused jobs. I’ve been developing software primarily, still doing .NET and C# for most of my career. Back in 2018, I started teaching on Udemy, so I started creating my own courses. I always kind of was experimenting because my day job was not enough for me, so I was looking for other things to do outside of it. I started building my own Android apps. I experimented with that, then built my website from scratch without using WordPress. I just decided to build my own MVC framework and then build a website on top of that, to teach myself how to do full stack web development.

Eventually what happened is that some organizations that saw my courses started inviting me over to film various videos, to narrate portions of books. So, for example, there is this quite famous publisher called Packt, a publisher of technical books. I don’t know if they still do it, but they used to do this one thing where somebody writes a book and they hire some subject matter experts to narrate code samples from that book. This is what I’ve been doing for a while.

Then I started writing articles for others. There used to be — well, this guy is still quite popular, but he’s called John Sonmez. He used to have a channel on YouTube called Simple Programmer and a website simpleprogrammer.com. He used to allow subject matter experts to write long-form articles on his website. So I started doing that.

Then eventually, in the first half of 2021, both John Sonmez and Packt approached me with an offer to write books. I ended up doing two books at the same time.

Len: That’s amazing.

Fiodar: So for John Sonmez at Simple Programmer, I’ve done a book called Battle-Hardened Developer, which is not about any specific technologies. It’s about mindset, how habits work. It’s kind of a motivational book because at that time he was moving more into motivational content rather than programming. But it’s all presented in the context of programming — like how it helped in my career, what do I do, what did I discover, sharing my insights, sharing some science that I knew.

For Packt, it was a technical book about a particular technology. So I got to the stage where both books were kind of done and they were just waiting — they had turned into the release pipeline to get released, which was a few months away. So I basically suddenly had quite a lot of free time. And then this idea hit me. What if I self-publish books, especially now since I’m comfortable with the process? It’s actually not as complicated as I thought. I kind of know the standards now. I worked with two different teams of editors already, kind of picked up common themes. And then I decided to explore this opportunity.

And then I found an article. I can’t remember the name of the guy, but he used to be one of, maybe still is, one of the best-selling authors on Leanpub. He wrote a book about Ansible.

Len: Jeff Geerling?

Fiodar: Yeah, him. He wrote a lot of articles about books. He basically described in his article how he earned quite a lot of money. His book was like 25% published. This Leanpub platform allows you to do early access because it’s like a book-as-a-service model. I got really excited about it.

Just to do a quick experiment, the quickest way possible, I took material from one of my existing Udemy courses. I basically translated that into a book, which became SignalR on .NET 6, The Complete Guide. It took me like two months because I already had the material. I just needed to turn it into book form. I actually managed to release that book before the other two books were fully released at 100%. Then it became more popular than I thought it would be. This is how I started doing all of this. Then I wrote another book, which was The Easiest Way to Learn Design Patterns. And yeah, here we are.

I’m going to mention Leanpub as well because one excellent feature of Leanpub is that, well, first of all, you don’t have to do your own formatting. You still can do that because you write your content in Markdown. Now there’s a what-you-see-is-what-you-get editor, which is awesome.

Len: Oh, good.

Fiodar: You basically just write your content as if you’re writing a Notion page. Very easy. Then that gets compiled into a book. The platform does all the formatting for you. You configure it, but there are some standard formats to choose from. And then for a very small monthly fee, you also unlock the option to download a print-ready PDF, which you can then import into the platforms that do print-on-demand services. Like in my case, it was Amazon Kindle Direct Publishing, which allowed me to publish a paperback copy of the book as well.

Len: Yeah, thank you very much for sharing that. And I’m glad to see that you noticed the WYSIWYG editor — the visual editor, as we call it — and the print-ready PDF. I mean, we didn’t realize how — like, that’s been around for a long time, but yeah, if you want to get your book into print, you need to provide Amazon KDP or IngramSpark or whoever it is with a print-ready PDF file. And we have a feature that lets that just drop right out of your book manuscript. So you don’t need to think — you might make some fun choices about how big you want the book to be when it’s in print, but you don’t have to worry about formatting it or anything like that. It just kind of works. And we give you what you need to get your book in print. So when you’re done done, you can just click that button and go off to where you need to get your book in print.

So thank you very much for sharing that really great story. Before we go on to talk directly about the book, there are a couple of threads for me to pull on there. One obvious one is, what was life like growing up in Belarus? I’m old enough that I grew up with the idea that these countries behind the Iron Curtain were these mysterious places where everything was very different. So what was life like for you growing up?

Fiodar: A lot of things were different. So my childhood was kind of okay because I think my parents did a really good job of shielding me and my brother from all the horrible things that were going on. And by horrible things, I mean the Soviet Union collapsed, but we had several generations of people who were taught how to live under a very oppressive version of socialism. So from an objective perspective, suddenly the country had so many new opportunities, but then you had a population that wasn’t prepared to take advantage of these opportunities. There was a small minority of people who kind of figured it out, who started opening businesses, but there were also quite a lot of people who basically decided to get rich on the backs of those people. And we had a massive organized crime problem. The protection racket was the biggest one. So basically anybody who opened a business, some large man would come over and basically force that person to pay protection money. There were quite a lot of things going on.

In Belarus, it probably wasn’t as bad as Russia, especially in western Belarus, where I grew up, but I still kind of experienced a little bit of that — not experienced directly, but kind of had some stories. Things happened to my friends’ parents, those kinds of things. It was fairly poor, so basically the economy collapsed. At that point in the 90s, Belarus had roughly the same level of hyperinflation as Zimbabwe. I literally remember when a note would be issued with one Belarusian ruble. I think it took a year or something to basically make it worthless. People were carrying notes that had like 10,000 written on them. And eventually, once every couple of years, they would keep the same design of the note, the cash, and would basically just cut the number of zeros down. So what used to be 10,000 now becomes one, and anything below that amount becomes invalid.

Len: Wow, yeah, thanks for sharing that. It’s interesting. We’ve had a couple of authors — one was in Crimea, I grew up in Crimea, and another one grew up in Moscow — and I’ve heard some stories about how things changed. Dmitry Vostokov was one — I remember he ended up in Ireland, but in 1994 he was working remotely for an American company because they realized Russia was full of all these highly educated people who know how to use computers and do math. And so there were all kinds of opportunities that grew up around that as well.

And so you moved to the UK. I mean, I moved to the UK too — I was probably older than you were, and it was from different circumstances — but how did you find moving to the UK?

Fiodar: So in some ways, my life kind of temporarily became more difficult because I had to adjust to a new culture and a new school that I used to go to. Basically, because we weren’t rich, we escaped Belarus because we had to escape it, not because we had a lot of money to just move to a different country because we preferred it. And we ended up in the UK. We had some options of other countries to go to. We ended up living in an area of the UK that wasn’t so nice — Bradford in West Yorkshire. So there were basically those two things. First of all, I had to adjust to a completely new culture. And the second thing is that the area that I lived in wasn’t the best.

But yeah, it took me about a year, year and a half. I finished school — I only did the final year, year 11 of standard high school. Then I went to college and everything changed. I already kind of adjusted to people with different cultures, a lot nicer than the school that I used to go to. But one thing that I brought with me from Belarus is that if you grow up in an environment like Belarus, where a culture is kind of competitive but at the same time there aren’t that many opportunities, you kind of become very sensitive to seeing opportunities. This is what really surprised me about the UK — how can a country with so many opportunities, like literally I just saw them everywhere, have so many people — because I used to live in a working class area, a council estate — how can those people not see the same opportunities I’m seeing? I think I had this advantage from growing up in an environment where opportunities were genuinely much more scarce. That combined with a very competitive culture.

Len: Thank you very much for sharing that. I had, in a different way but a kind of similar experience, when I moved to London from where I am now, Saskatoon, Saskatchewan, in the middle of Canada. There was more opportunity for me in a corner of London than there was in all of Canada. And when I say opportunity, I don’t just mean job opportunity or education opportunity. There were famous lecturers from all around the world giving lectures all the time in the many universities and various other kinds of institute lecture halls and things like that — an old tradition that goes back to, I think, the early 19th century in London in particular. And it was always kind of striking to me that, wow, look at what you have here. And particularly — not to pick at a scab or open a wound — but why do you all act so miserable all the time?

Fiodar: I think it’s similar. Back in Belarus, for example, I was a really bad student. And the reason for that is because I just did not see any opportunities in a normal way. For example, if you finish school with good grades, you become an engineer or somebody with a qualification, and your salary will maybe be just slightly higher than that of somebody who didn’t finish school, some manual labourer. And in fact, quite a lot of manual labourers would just work overtime, find some people, do it kind of off the books as well, and they would probably end up earning more. Then I came to the UK, and I saw this very obvious path. There’s this nice area with nice houses, people driving nice cars over there. And it’s actually well defined — it’s very obvious that if you study well, if you go to university, if you then get into some good career, you will be one of them. And it really surprised me that so many people didn’t see that, even though we had people in our school that used to come in and explain that to the students. For some reason, they still didn’t believe it.

Len: Yeah, you just prompted a memory in me. There was a time when I was an investment banker in London and I joined a group that got to teach kids from what in the United States they would call inner city schools. We would have kids from like a half a mile away come to the top of our skyscraper in the City of London, and it was just like — they didn’t, how could they know what they were looking at or what was going on around them, you know? And that’s always been true, particularly of London as well — the proximity of wealth and poverty, and knowledge and lack of knowledge and stuff like that. It is a striking part of life there.

So the next thing I wanted to ask you about — you went to university but you didn’t study computer science, and you eventually taught yourself programming. That kind of thing is a bit of a theme on the Leanpub Podcast because so many of our authors are technical people. So I guess the question I would have for you is, if you were talking to someone who’s just finished high school and they were thinking of having a career as a software engineer, would you recommend that they go to university and get a full degree?

Fiodar: It’s a difficult question because it’s definitely a career where your skills and knowledge matter, but a degree certificate, not so much. The only place where I was ever asked for my degree certificate was my first job that I got from university. It actually required a master’s degree. After that, not a single place asked me for my degree certificate. I’ve got it mentioned on my resume right at the bottom somewhere. I don’t even know if anybody looks that far. At one point, I didn’t even mention education on my resume and I was still getting invited to interviews.

So yeah, you definitely need some kind of skills. The degree part — well, you can also take a bootcamp. And a bootcamp is basically not necessarily equivalent to a degree, but it distills only those skills that are absolutely needed. I’m talking about good bootcamps, because not all of them are good, by the way. It basically just distills all the skills that are actually relevant to a software development job. It does not teach you some low-level computing concepts. It does not teach you the history of computing or anything like that. And this is why it takes like six months, nine months, maybe a year, not three or four years like a normal degree does. There’s a really good bootcamp called Skill Foundry, which is run by my friend Eric Weiss. If anybody wants to go through a bootcamp because they don’t want to take the full degree, that’s one of the places I can recommend. It can be done remotely as well, it can be done online, but they have live chat and they have mentors.

But a degree still kind of makes it easier. And one thing that a degree gives you is that you will be able to apply for really top jobs after graduation. And also, if you are ambitious and hardworking, you might be able to get a job while you’re doing a degree as well — maybe part-time, but still, which will probably give you more experience than the degree itself.

The mistake that I made when I was choosing a subject to study — computing was something that I always liked. Back when I was a teenager in Belarus, I couldn’t afford a proper computer, but I had this Sinclair ZX Spectrum. A Soviet knockoff of it, not the real thing, but basically equivalent. For those who don’t know, it’s a machine from the 80s. It’s basically a keyboard that you connect to your TV and a tape recorder, and it had a memory of like 47 or 48 kilobytes. You had to load programs off a tape, and each program needed to fit in the memory. So it was just a small game. You can watch the videos of those games on YouTube and, by modern standards, they’re just ugly. But what I used to do is program my own simple games — some simple fighting games where there are like two stick figures just going at each other. So I was kind of enjoying it.

I bought my first proper computer when I moved to the UK — well, my parents bought it for me. I started doing various mods of the games that I had. I was into this kind of stuff. There was only one problem. Almost everybody in my circle was also into this kind of stuff. And I wasn’t aware of cognitive biases back then. What was happening is that everybody wanted to do computer science. And I kind of thought — I didn’t realize I was in an echo chamber at the time — if everybody wants to do computer science, then everybody graduates and there won’t be any jobs left because everybody’s competing for a limited number of jobs. Which was kind of logical based on the information I had at the time. So I needed to do something that is science-related, but not that, and it’s probably going to be interesting, and then I’ll figure out in the process what job I want to do. And this is how I chose biology.

Len: One thing — just as a kind of segue now into the next part of the interview where we talk about your book. So one thing I’ve been noticing about discussions of AI — and again, this might be my echo chamber; Leanpub is a place where people have written books about hard things and they’ve taken time out of the rest of their life to do it, so basically I’m saying we have a lot of very smart authors, and people who are particularly on the edge of what’s happening in software development — I noticed that your career went from software engineer to AI engineer. And one thing I’ve been noticing is that the importance of being very smart and knowing a lot has gone up in the world of software development and engineering. And that’s one thing that I think is kind of changing a little bit the attitudes towards getting a university degree. What I’m kind of hearing is that if you can take a few years in your youth to just think and be around and learn — whatever it is that you’re studying — the kind of foundation that lays for learning in the rest of your life can be pretty powerful. And here’s another way of putting it: if what you’re doing isn’t hard, AI is going to be doing it relatively soon. So this is just the world that I see emerging for software developers and software engineers.

Fiodar: I see it as well. You actually raised a good point. So maybe what I said about bootcamps is not as valid as it was like maybe two years ago. You still can go to a good bootcamp and still pick up the skills, but actually in that situation a degree would probably be more helpful, because you do spend more years studying and actually getting those fundamentals down, which will make it easier in the world of AI.

The only thing that I’d probably object to is that I have actually seen all sorts of developers — those with degrees and those without degrees — and most of the time it does not really determine how good somebody is. Quite often you see self-educated developers who actually end up being much better. And the reason for that is because sometimes what you see in somebody who graduated from university is that they just think, maybe subconsciously even, since I’ve done so much studying, I’m kind of done, and they just start learning incrementally after that. And those who are self-taught have this constant imposter syndrome, and they just think they have to prove themselves. They keep learning, they keep spending hours upon hours — maybe up to 20 hours a week on top of their day job — to learn, and they end up learning things rapidly. Maybe if you compare someone who was self-taught to someone who had a degree in three to five years’ time, a self-taught developer might actually overtake such a person.

Len: Yeah, that’s a very interesting observation. And of course it reminded me — the flip side of what I was saying was, if you’ve got a good AI service, it can answer any question you ask. It never gets tired, it never gets bored of you, it never gets mad at you. It probably will never call you dumb unless you ask it to. You can make as many mistakes as you want with it without being embarrassed. You can ask it questions at two in the morning if you want to, you don’t have to wait for office hours or something like that.

Fiodar: Exactly.

Len: And it’s got access to all the world’s knowledge and all that kind of stuff. So it’s a complicated time that we’re living in when it comes to the choices that we need to make, because the opportunities before us are just so incredible.

Moving on to the next part of the interview where we talk about your book, Production-Grade Python, LangChain, and LangGraph — what was the origin story of this book?

Fiodar: Oh yeah, it’s quite interesting. As I mentioned before, most of my career — for well over a decade — I have been primarily specializing in .NET and C#. Because it’s Microsoft’s stack, it’s a framework and language developed by Microsoft, and quite a lot of enterprises use it. Even though early in my career I experimented with pretty much every programming language, including Python as well, I kind of stuck with C# and .NET because there were so many opportunities and I just did not feel like I had a need to move anywhere else. They were fairly well paid — for example, compared to PHP opportunities on average. Maybe not as well paid as C++ opportunities at an investment bank or hedge fund, but still, on average quite well paid. And C# was consistently in the top 10 of the most popular languages. I think at one point it got into the top three as well.

What happened is that AI happened. Basically, everybody started adopting generative AI and Microsoft started adapting to it and they started adding quite a lot of really good tools to the .NET ecosystem. However, the Python ecosystem already had mature tools available for AI engineering because AI engineering existed before generative AI became a thing — only it used to be a very niche subject. And now, if you look at job opportunities or contract opportunities, opportunities that don’t involve some kind of AI engineering — and I’m not talking about agentic production of code, I’m talking about building applications with AI features in them — they almost don’t exist anymore. So the field of AI engineering is expanding rapidly; well, it has expanded rapidly.

But what I’ve also noticed, because the .NET ecosystem did not have tools as mature as Python, I wanted to open up more opportunities for myself and to have this opportunity to help more clients. And also — I’ll have to step back a little bit — what I do these days is independent consulting. So I run a company called Orion AI Engineering, and it’s a mixture of day rate contracts for large enterprises and fixed scope projects for smaller companies. And when a small company asks me to implement some system, what I used to do is use .NET, even though they don’t care about the tech stack — they are non-technical but they want to bring somebody in. That was not necessarily the right thing to do, because it’s basically me dictating what tech stack they should use based on my own limitations. But with knowing Python, I can just pick the most appropriate framework for them, because since Python is the most mature ecosystem for AI engineering and machine learning, it only makes sense that if they’re not limited by any tech stack, they should choose Python.

So I can now apply what’s best for my clients and not just what I am capable of. Because of that, I started learning Python heavily — but what I mean by that is not learning if statements and while loops. I knew those already. Those are the things you can just pick up if you go to any online tutorial, or ask ChatGPT. What I started learning is production-grade Python and the two most popular frameworks in Python for AI engineering, which are LangChain and LangGraph. LangChain is for building agents and LangGraph is for orchestrating agents. It’s a bit more complex than that, but that’s what they are in a nutshell.

By production-grade, what I mean is how applications are developed, how a repository is structured, how tests are executed, how do you integrate Python into a release pipeline, when the Python application is running what are the caveats and what do you have to watch out for — those kinds of things.

I started taking a lot of notes in my own documents, in ChatGPT chats, everywhere. I ended up with a lot of different notes. And then I kind of realized, wait a minute — because this field is growing while every other niche of software development is shrinking — there are probably going to be a lot more people looking to go through exactly the same process as I went through. And I decided to take all these notes and just compile them into a book. It’s basically a book that I wish I had when I started.

Len: Yeah. And as I mentioned when we recorded the launch video for this book, that’s often where the best books come from. Someone goes through a journey on their own and then they’re like, now I can be a guide to those who want to go on that journey themselves after me. And that ends up producing some of the very best books.

One thing I’m going to — so you answered my first question, which is why is Python one of the most important languages in modern AI engineering. My next question was, I’m going to quote you at yourself, which isn’t always fair, but here’s the quote: “Routine implementation work is becoming increasingly automatable while the ability to design, integrate, evaluate, secure, deploy, and operate AI systems remains difficult and valuable. Engineers who understand both traditional production software engineering and modern AI systems are therefore well positioned for the direction in which the industry is moving.” So that led me to ask this sort of provocative slash cheesy question. Why is understanding — you said engineers who understand both traditional production software engineering and modern AI systems — why is understanding these things going to matter at all going forward? Aren’t people just going to be able to go, hey Claude, fix this or do this?

Fiodar: Well, one thing about AI — even the top models — is that they don’t necessarily hallucinate as much as they used to, because hallucinations were a real problem when they would just straight up make up the answer. It doesn’t happen as much, not only because models got better, but because in tools like Claude it’s not just the model — there’s this whole agentic harness with system prompts and guardrails that prevents models from doing that. But still, models have been trained on the data that is most abundant, which is the average. It’s not good, it’s average. By default, it will produce something that is average. That’s the first problem with it.

So unless you start asking Claude to produce something that is actually production grade, it will not do it automatically by default. It will give you some examples based on — most likely it will give you examples based on what it has seen. And most of the examples it has seen would be from GitHub repositories publicly available, most of which are hobby projects, or some blog posts, which are also toy examples to teach some concept to somebody, not necessarily a production-grade system. That’s one of the issues.

Another issue is that those models are often wrong in a subtle way. So what you’re seeing looks very plausible. But at the same time, there’s a very subtle issue. If you don’t know what you’re doing, maybe this one subtlety is not going to hurt you, but they will accumulate eventually. If you only judge an application based on whether it works or not, then you can’t tell whether it will continue working if it’s deployed in front of a million users, or at least 100 users. If it’s just you, scalability requirements might be very different.

One of the biggest things in software engineering in general is non-functional requirements. A lot of non-technical people — executives and managers, for example — complain that during this one big hackathon you managed to develop a proof of concept. Why did it then take you half a year to develop the actual production feature if it’s only a slightly different style or an extra button added? And the answer is not because developers are lazy, but because there is such a thing as non-functionals. A POC is just for demo. One person runs it as one user, that’s it. Non-functionals are things that are very important but nobody sees. So unless you’ve studied it, you wouldn’t even know they exist. Performance requirements, scalability requirements, any kind of bottlenecks. How do you handle partial failures when you integrate with third-party APIs and systems, like payment gateways, for example? What if, for that millisecond when your request is being made and you’re trying to process a transaction, the Stripe gateway is down? How do you handle that? Somebody who does not understand those concepts will not be able to build a reliable system like that. Such a system may work until the first incident. And that first incident might be catastrophic.

Len: Yeah, thank you very much for sharing that. I think that particularly invoking incidents at the end there — trying to prevent them from happening, but knowing how to handle them when they do and understanding what you’re looking at, that becomes so important. And I think it’s very interesting that you say near the beginning of the book, “This book starts where many Python introductions stop” — how source code becomes a running production service. What’s it like when it’s actually out there in the world, kind of running on something other than your own computer? How many people are trying to use it at the same time? What does that mean? Managing costs, things like that — a very different thing.

And are you finding — just a general question about that — that one kind of can’t just operate in an ivory tower away from implementation anymore? Or are there still lots of roles like that for software?

Fiodar: So software developers, myself included, they still produce code. They don’t necessarily produce it by typing it all manually, but they still produce it, they still own it. Nobody should ever accept the excuse, “what is this bug? Oh, Claude did it.” No, you did it with Claude, but you did it. AI, even though it seems intelligent, is not intelligent, it’s not accountable for anything. It’s just a tool still. It’s a very good tool, but it’s still just a tool.

So yeah, one of the biggest benefits that AI introduced is that it eliminated having to type all the boilerplate code, because most of an application is boilerplate and glue code, not functional logical code. So yes, basically most of your application code can now be produced without you typing any code yourself, just with prompts and context documents, those kinds of things.

For a standard application — and most of the applications in the world are fairly standard, they solve a particular business problem, but from a technical implementation perspective they are kind of the same: there is a database, there are some very standard types of business rules, there’s just different data that they operate on, specific styling is different, but the concepts behind them are the same — those applications you can easily build without typing any code at all.

And then there are more specialized applications with some complex business logic. For example, when I was at Microsoft, I was building a system for the Met Office that transfers large datasets with climate and weather data, which kind of brought me back to my origins in environmental sciences. That kind of system, you probably won’t be able to just prompt into existence. You will be able to prompt a bit of it, but not everything. Some algorithms — it’s probably going tobe easier just to type them up yourself and explain it to AI, rather than make it make mistakes. And regardless of how you do it, whether it’s 100% written by AI or not, you still need to verify the outputs. You absolutely must verify the output.

There are certain techniques that you can implement to make it so that you don’t necessarily have to verify every single line of code yourself. This is what everybody’s complaining about — those pull requests are now getting so large that who can verify them? But those require engineering knowledge as well. So for example, tests — you need to also make sure that AI does not change tests just to make them pass, those kinds of things. So for the tests, you definitely have to verify: wait a minute, did AI change any files that have tests in them? You have to have deterministic quality gates like linters, like SonarQube for example, that just statically analyzes your code for any code smells, for any standard syntax violations. You have to have those rule sets — I can’t remember the proper name for those, but basically the configuration files that tell linters what to look out for. It’s basically the configuration files that enforce syntax standards on your code: we are using this kind of annotations, we are using this kind of naming, those kinds of things. So yes, basically if you have those deterministic guardrails in place, then you can get away with not reviewing every single line of code — like 100% code coverage on those linters. But you still have to verify some of the code. You definitely still absolutely must verify the general structure of the PR. So what files did it exactly change? Did it have to change this file? Oh wait a minute, what did it do in this file?

Len: The last question I’d like to ask you about the book is, let’s come up with a kind of practical working example. So for example, if someone learns how to use LangChain and LangGraph from your book in Python, can you give me an example of something you’ve built, or that would kind of bring it home to people — the kind of power that they’ll have, what they’ll be able to do, what they’ll be able to offer clients, for example?

Fiodar: Yeah, sure. So an agentic system — one of the agentic systems that I’ve built. It wasn’t actually in LangChain and LangGraph, that particular one, but the concepts are the same. I used Microsoft Agent Framework, but Microsoft Agent Framework is basically a .NET version of LangChain and LangGraph combined. It’s just a more interesting example, which is why I use this one.

A company with a large industrial data platform, software as a service, needed an agentic system to simplify user interactions. So when a user asks a question, it needs to have this orchestrator agent that tries to figure out which agent to send that question to. Because agentic systems should be designed in such a way where each agent has a narrow set of responsibilities, because language models are not very good at managing a context that contains too much — and by too much, I don’t mean in terms of quantity of text, but in terms of concepts. So it’s basically like context switching. If you are asking a question that contains five different sub-questions, then it’s probably not going to manage well. But if you’ve got five agents and you then get the LLM to split that original question into five separate agent-specific questions, then it works much better.

So in that kind of workflow, LangGraph would be the system that decides where to send each question to — the agent orchestration system. Imagine a graph where the orchestrator sits here, and then there are sub-agents at different points. And LangChain is the thing that allows you to build the code that interacts directly with the LLM and manages its memory. LangGraph — another thing that it does is that sometimes something in your session might break halfway through, some network failure or something like that. It does checkpointing. So it allows you to basically resume from where it left off, so the user does not suddenly see an interruption of the session.

Going back to the system that I’ve built — the orchestrator agent, a user may be asking to retrieve documents for some, I don’t know, wind turbine, for example. Or they may be asking to retrieve some time series data showing average wind speed across a particular period of time at a particular wind farm. So documents would be the responsibility of one agent, and those wind speeds would be the responsibility of another agent. And then in an agentic system like that, there would probably be another agent, before the user receives the final output, that consolidates all the answers from all these different agents and also does some kind of last-minute hallucination prevention guard.

Len: Great. Yeah, that’s a great example and it makes a lot of sense. So thanks. With that, the book covered — everyone should go get it. You’ll learn these superpowers that Fiodar was just describing, and be able to do these things in a structured way that’s understood.

So moving on to the last part of the interview, where we talk about your experience as a writer. You’ve already talked a little bit about your story, how you got into it, getting approached by publishers and things like that. So my main question for you, I guess, would be — what’s your approach to writing now? How did you write this book, for example? Do you block off time in your calendar?

Fiodar: Yes.

Len: Do you do a lot of structuring in advance? Do you think a lot about the outline before you start writing?

Fiodar: Yes. So the first thing that I do is produce the outline for the book. My first iteration of the outline is probably going to be just a book’s sections and high-level chapters. For this particular book, I ended up with a lot of short chapters, because I’ve noticed that when we talk about technical books, it’s usually preferred — and I prefer it myself — when you have either chapters with a lot of short sections in them, or just shorter chapters. This way, concepts are kind of easier to consume. So I think it’s like 60 chapters, but every one of them is like three pages long. The book itself is just under 300 pages. So it’s still kind of average size.

Len: Yeah, no, that’s great. And do you have a place that you go where you write? Like, is it different from where you work or anything like that?

Fiodar: It’s the same room that I’m sitting in. That’s my home office, where I do any kind of work. I don’t treat books any differently from my software development work. Basically, I even see writing a technical book — especially I kind of got onto this concept of book as a service — more like building a book rather than writing it. Because it’s not a novel. I’m basically building a useful product for somebody else to use. I don’t really see it as different from writing software.

Len: That’s really great. I don’t know if I’ve exactly heard anyone put it quite so well before. But a lot of the time I think one thing I encounter a lot with people is — oh, a book — they can do amazing things in their life, but a book, they’re like, oh, this is some grand significant thing, who am I to do that? And we all do that with things in our lives. And it’s like, actually you can just sit down and, like you do all kinds of other work in your life, you can do work on a book. And I love that idea of building it.

And the last question I have about that is reviewing and interacting with other people. Do you have people that you show drafts of your chapters to and things like that? Other people that you get feedback from while you’re writing?

Fiodar: Yeah, while I’m writing a book I usually get in touch with people, maybe even before I write the book. So for example, one of the things that I do way before I write the book is prepare some kind of companion repo for it. For example, this book has quite a big companion repo that provides a realistic production-grade example of what a Python repo with LangChain and LangGraph will look like. In that particular case it’s an agentic system that monitors support tickets for an IT company.

So yeah, I talk to subject matter experts. These days I actually do less of that. I still talk to some people, but AI can help you with quite a lot of things. It can instantly spot any spelling mistakes, those kinds of things. You can get AI to verify your repo, whether it makes sense. Then you can also use tools like Visual Studio Code, linters — do they highlight any problems as well? Those deterministic tools that I talked about. But yeah, it definitely makes sense to speak to some kind of subject matter expert to get your book reviewed. But with those tools in place the process is much easier, and you probably don’t need to bring over several subject matter experts now.

Len: The last question I always like to ask on the podcast, if the guest is a Leanpub author, is: if there was one magical feature we could build for you, or if there’s one thing that whenever you’re using Leanpub you’re just shaking your fist going, damn you Leanpub, why is this so broken or so bad — is there anything that you can think of that you would ask us to do?

Fiodar: On-demand printing, same thing as KDP does.

Len: I bet some other people say the same thing, didn’t they?

Fiodar: Yeah.

Len: We’ve had many other people ask us for that. Why can’t I just click a button to download my print-ready PDF, but then I’ve got to go off and learn KDP or learn IngramSpark and stuff like that? Why can’t I just do it from within Leanpub? And there’s a lot of answers to that, one of which is bits and atoms are two different businesses. Essentially, the world of physical things has its own complexities and costs and risks and stuff like that, and it’s just a very different business model from doing digital things. And so I think that’s one of the reasons why we stick to the digital side. And we may one day have someone knock on the door and say, hey, we’ve built a startup or we’ve got a company where you can just click a button and integrate with us — and instead of a print-ready PDF, it could be, link my print-ready PDF to this third-party service that’s integrated with Leanpub. That may happen someday, but I don’t think we’re ever going to build our own print book empire. Sorry, not empire, but we do get that a lot and it’s very obvious. And for anyone listening, the value of a print book is just kind of incalculable. The feeling that you get from holding it, from looking at it, from having it on your bookshelf, from giving it to people, being at a conference — it’s a very different kind of thing. You can send the book to people that you admire who are in your professional area, and they get it. They might get a bunch of them, but they might see it and they might enjoy it. There’s great value to physical books, and that’s one of the reasons that authors ask us about it so much.

Well, Fiodar, thank you so much for taking the time to talk to me and to talk to all of us on this podcast. And thanks very much for the really great book, which I highly recommend to anyone who’s interested in understanding that difference between kind of, you know, programming a mockup or a demo or proof of concept and actually running something in real life. It’s really amazing.

Fiodar: My pleasure.