Who Is Paul Iusztin?
Paul Iusztin built an AI career from a country where there was no AI scene — and never moved to fix that. Romania to remote freelancing to a 40,000-subscriber newsletter to the bestselling LLM Engineer's Handbook (~20,000 copies sold) to founding-engineer at a San Francisco startup, all from his desk somewhere along the Atlantic coast. He's now in Portugal. The startup is in SF. He's not moving.
He's the rare engineer-teacher whose most influential work is the public work. The book outsold his expectations by 20x. The newsletter, Decoding AI, hit 40,000 engineers learning how to actually ship AI that works. The new course, Agentic AI Engineering, just launched. A second book — on agentic engineering — is in development. The startup, building vertical AI agents for financial advisors, is the lab where he learns the things he then teaches.
His thesis is contrarian and gaining traction: most teams don't need RAG. Most teams don't need MCP. Most teams don't need agentic loops. He published it in a piece titled "We Killed RAG, MCP, and Agentic Loops" — and he's been arguing it since. Not because the fancy tools don't work, but because most engineers reach for them before asking whether the problem actually needed them.
The Archetype: The Sage
The Sage
The Explorer
The Return
Paul is The Sage. The drive isn't building or shipping or even making money — it's understanding, then translating that understanding so other people can use it. His career arc reads like a single long act of analysis-and-explanation: book → newsletter → course → second book. Each loop's output becomes the next loop's input.
The line that gave it away in the conversation: "I have a saying that I keep using is I like to teach people how to fish." That's not a tagline. It's how he's actually structured his work. The course he just launched explicitly avoids frameworks like LangGraph "because we want to actually understand how things work behind the scenes." Most courses teach you the tool. Paul teaches you the decision process behind whether to use the tool — if and when and why.
His secondary archetype is The Explorer — Romania to freelance contracting to content creation to startup founding-engineer to Portugal, with multiple pivots inside each phase and a strong distaste for predetermined paths.
"I just love to learn. I just started outputting everything that I learned online. And that was like basically building in public is magic."
The Hero Match
Lao Tzu
The match is uncanny on Paul's central thesis. Lao Tzu's Tao Te Ching argues that the highest mastery is the willingness to remove rather than add — that complexity is a failure of seeing clearly, and that simplicity is the hardest discipline because it requires you to abandon what you've already built. Paul's "We Killed RAG, MCP, and Agentic Loops" thesis is essentially this applied to AI engineering. When he said "Usually the answer was more in simplicity than following all these fancy algorithms. But it's hard to find this simplicity. It's the hardest" — that's almost translated Tao.
The deeper match is what Lao Tzu did. The legend is that he was a librarian who wrote one book and then disappeared westward. He didn't build an empire or take a position. He left writings. Paul's career has the same texture. He explicitly chose the writing path over the institutional path: refused the leetcode-and-FAANG track, lives in Portugal not SF, freelances rather than employs. His leverage is the writing. The teaching outlasts any startup work.
The third resonance is wu wei — non-forcing, the wisdom to know when not to act. Paul's MCP critique — "if you have a hammer, you see nails everywhere" — is exactly this. Most engineers his age are still defending the hammer. He's the rare one telling the audience to put it down.
Yoda — Star Wars: The Empire Strikes Back era
Empire-era Yoda — the Dagobah hermit, not the prequel-trilogy general — is what Paul is doing right now. Living in a remote, beautiful, mostly-empty place. Refusing to engage with the central institutions. Teaching one student at a time through stripped-back wisdom that contradicts what the student thinks they need. "Do or do not, there is no try" maps perfectly to Paul's "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." Same teaching move: the wisdom is in the binary, not the optionality.
The introvert dimension matters. Yoda chose a swamp over a senate. Paul chose the Atlantic coast over Sand Hill Road. Both are aware they're missing the action — and both have decided the action wasn't actually where the work was.
"If you have a hammer, you see nails everywhere."
The Story Behind Decoding AI
A few years ago, Paul was sitting in Romania trying to figure out how to get a job in AI. The local market was thin and not particularly interesting. The remote market was a meat-grinder of leetcode interviews and 30-minute Zoom screens where he was supposed to compress everything he knew into the right kind of answer. He hated it. His take, in his own words: "this lead code job interview path is kind of hijacked because there's a lot of competition. It's just a numbers game."
So he stopped. Not in a flashy way — he just started writing online. "I just said, okay, I like to learn. I'm really passionate about software and AI. And I just started posting randomly without zero strategy, zero." He wasn't trying to build a personal brand. He was trying to make it easier to find contract work. The brand happened anyway.
The book happened the same way. He wrote it without expectations: "I had zero expectations when I started writing it. If I sold 1000 copies, I would be extremely happy." It became a bestseller. He still sounds slightly surprised when he talks about it. "We sold like over 20,000 copies."
The company, the course, the second book — all of it follows the same pattern. The output is the input. The teaching forces the learning. The learning produces the next teaching.
Now he's at the financial-advisor startup, watching teams reach for fancy AI patterns when the simple ones would work. He's been writing it down. Some of it became the article that broke through earlier this year: "We Killed RAG, MCP, and Agentic Loops." Most of it will become the next book.
The Founder's Journey ↔ The Company's Journey
Romania (no AI scene) → freelance contracting → LinkedIn building-in-public → bestselling book → newsletter at 40K → founding AI engineer → Portugal-by-the-ocean → course launch → second book.
Multiple startup pivots → vertical AI agents for finance → over-engineered first attempt with RAG, MCP, and agentic loops → realized small data + simple solutions outperformed → wrote the post-mortem → became the public thesis the audience now associates with the brand.
Both journeys are the same archetype made visible. The Sage who learned by trying the fancy thing first, then strips it back to the principle. Decoding AI the brand and Decoding AI the product company are both organized around the same core move: the teaching doesn't come from theory. It comes from breaking the thing first.
How Paul Leads
Paul owns his calls cleanly. When he narrates career and content choices, the language is direct and personal: "I decided," "I started," "I realized I need to go more into the freelancing route." He doesn't claim things drifted into place when they didn't. He has a clear settled position on the corporate path — "personally I don't like corporate. I don't like that fact. So it's just a personal fit" — and he's not avoiding the question, he's already answered it for himself.
When he narrates startup decisions, he switches to "we" and gets more humble: "we did not have clarity on our business problem since day one... I think that's the biggest learning." He distributes credit on hard pivots and doesn't pretend he knew. That's a healthier ratio than most founders run — claiming personal wins while owning team failures, instead of the other way around.
What this means in practice: Paul will tell you what he thinks clearly. He'll also defer cleanly when someone else has domain knowledge he doesn't. He doesn't grandstand and he doesn't equivocate. That combination — strong opinions, weakly held, clearly communicated — is rare.
Founder Superpowers
Stripping the fancy from the right answer
Paul has a rare diagnostic instinct for when a sophisticated solution is actually wrong for the problem. The skill isn't anti-fancy — it's post-fancy. He's tried the complex thing first and learned what it cost. On RAG: "if we load all the data that an advisor has into the context window, it will just sum up to 64,000 tokens at maximum... it's just easier just to load everything." Most engineers his age never get past defending the hammer.
Building learning loops in public
Paul converts every act of learning into an output, every output into a teaching, every teaching into a product. The chain is unbroken: book → newsletter → course → second book, with the startup work feeding everything. He doesn't do anything once. This is the rarest pattern in technical content — most experts go inert the moment they stop being students. Paul never stops being a student because the act of teaching forces him to keep learning.
Translating engineering reality into teaching frameworks
The Canva diagrams aren't decoration — they're the work product. "I'm a visual learner. For me, it's very hard to put my thoughts into words. But visually, it's a lot easier." The reframes that landed in conversation — "AI-generated code is just another compilation step. We don't read bytecode, why read this?" and "vertical AI agents are like the new web apps" — are all the same move: take a complex engineering reality and find the analogy that makes it instantly graspable. That translation is the rarest skill in technical content.
What It's Like to Work with Paul
He's measured. Not slow — measured. He thinks before answering and self-corrects mid-sentence when he wants more precision. "I don't think it's really five years, but let's say three years each, maybe more." If you bring him a problem, you'll get the framework first, then the specific guidance. He doesn't reach for stories until he's set up the principle.
He's also an introvert with a serious recovery cycle. "I love discussing but now I need three times of recovery, three days of recovery." This isn't a quirk — it's a working constraint. He needs deep solo time to do the actual work (a single Canva diagram takes 30-45 minutes; the article that became "We Killed RAG, MCP, and Agentic Loops" came out of months of pattern-noticing). What this means for collaborators: he's not flaky — he just won't be in the meeting for the sake of the meeting. When he shows up, he's ready.
And he's honest about anxiety in a way most engineers in his position aren't. "I still am [super anxious] when I have to do a video, things like this. I need 50 minutes of preparation." He doesn't perform stoicism. The work gets done; the discomfort is acknowledged. That's a healthier work-with model than most of what's on offer.
"I have a saying that I keep using is I like to teach people how to fish. Then they can do whatever they want."
Why This Matters (For You)
If You're an Engineer Building AI Agents
Paul's central argument is that most agentic systems fail because they were over-built before the team understood the problem. RAG was added before anyone checked if the data fit in context. MCP was added because every provider offers a server. Agentic loops were added because reflection sounded like the right pattern. The discipline isn't picking the fancy patterns — it's removing them after you've established that the simple version works first. If you're three months into a stack of frameworks and your latency is bad and your costs are climbing, the answer Paul would give is: take it apart. What does this break if you load everything into a 64K context window and skip the retrieval step entirely? That question, asked seriously, is most of the work.
If You're a Builder Choosing Your Career Path
The leetcode-FAANG path is one route. It's not the only one, and Paul's career is the proof. Build a portfolio in public. Write what you're learning, even when you're learning it badly. The 10-12 hours a day, six days a week he describes — "I started coding pretty heavily like 10 years ago and I work 10 to 12 hours a day from Monday to Saturday" — is not a sustainable lifestyle and he doesn't pretend it is. But the compounding is real. Years of building in public turned into a book, and the book turned into the largest career break he's had. The path is slow, lonely, and usually invisible until it's not. If you're early and frustrated by the standard interview pipeline, ask whether you'd rather optimize for the next year or the next ten.
If You're Early in Your Career
Paul's most practical advice landed in the closing minutes: "be extremely good in a specific domain rather than know how to code." Coding is becoming abundant. Domain expertise — really understanding finance, or medicine, or e-commerce, or education — is becoming rare. He chose AI engineering as his domain a decade ago, and he's spent that decade actually doing the work, not just sampling it. If you're 22 and trying to decide between three plausible specializations, the call is to pick one and go deep. Pick wrong and pivot in two years; that's still better than spending a decade hopping. The compounding lives in the depth.
If You're Considering Joining Decoding AI
Paul's company is the lab where the public teaching gets generated, not the other way around. If you're a senior engineer who likes shipping production code and seeing it become the next book chapter, that's a fit. If you're someone who needs an in-office culture, frequent stand-ups, or a leader who's always available — probably not. He's remote-first by conviction, introverted by temperament, and runs on long deep-work blocks rather than continuous collaboration. He'll tell you what he thinks clearly and defer cleanly when you have domain knowledge he doesn't. Working with him is closer to working alongside a craftsman than working under a manager.
Go Deeper
The full conversation with Paul Iusztin is on its way. Check out other episodes in the meantime.