The Pragmatic Engineer AMA: Gergely Orosz on AI, Hiring, Big Tech, and Running an Independent Newsletter
The Pragmatic Engineer
In this reversed episode of the Pragmatic Engineer podcast, Gergely Orosz answers questions from subscribers instead of asking them. The questions are read by Volodymyr Giginiak ("Giggs"), CTO and cofounder of the legal AI startup Wordsmith, where Orosz is an investor. The questions fall into several groups: observations about the industry, opinions on AI and hiring, questions about Orosz personally, advice for specific situations, and the Pragmatic Engineer as a business. Across these topics Orosz returns to a few positions. He is skeptical of "AI-native" as a label, he sees hiring becoming messier rather than simply harder, and he thinks professionals who genuinely care about the craft will remain in demand.
Leaving Uber: a book, a startup plan, and an honest look at motives
Orosz started at Uber as a senior engineer after about ten years as an individual contributor, and he soon became an engineering manager. About four years in, two things happened at once. COVID hit Uber's business hard. He had access to an internal revenue dashboard that showed ride revenue falling close to zero, and he shared it with his team because he valued transparency. He says he is not sure that was the smartest move, but he would probably do it again. Uber then made 20% layoffs, and about a quarter of his team was cut. The remaining team's mission no longer made sense: they had been building for drivers on the assumption that drivers would be scarce, but during COVID drivers flocked to the platform. He was given a new team, but for the first time in four years he felt demotivated.
Money made leaving possible. Before joining Uber he had received a stock grant worth about $500,000 and had promised himself that if it ever turned into real money, he would take a risk. After the IPO, a lower share price, and taxes, it came to roughly $400,000. That was enough to go two or three years without working. His plan had nothing to do with writing as a career. He would finish The Software Engineer's Guidebook, which he had started at Uber, within six months, and then found or join a startup. Part of the reason was fatigue with middle management. In his words, "They tell you congratulations, you became a manager. They should have said you became a middle manager." The job meant keeping his team, his management, and his manager peers happy. During the layoffs, being based in Europe also meant a lot of politics and explaining regulations. He had ideas and wanted to be in charge next time instead of "fighting the machine."
The book went the way first migrations go for junior engineers. Six months later he was still treading water on the main book, although he had written three other short books along the way. So he asked himself what he would actually be doing. His startup idea was to productionize Uber's internal RFC system. He points out that spinning internal platform tools out of Uber was a well-trodden path, citing Temporal and Chronosphere. His brother, who was on his second startup, told him to start a company only if he was ready to spend ten years on it. Orosz was not excited about spending ten years on an RFC system.
He then examined his motives. The first was money. In 2021, ex-Uber startups seemed to become unicorns within a year or two. He did not expect that for himself, but he imagined a ten-year path where he might end up with a 5–10% stake, perhaps $25 million after taxes. When he asked what he would do with that money, the answer was to share what he knew: write books and make YouTube videos. He realized he could do that right away. The second motive, which he calls the more legitimate one, was the feeling of a small team working against the world. He had enjoyed that at Uber and at Skyscanner, where he met Wordsmith cofounder Ross, and he had not enjoyed managing managers.
The trigger was Substack. Lenny Rachitsky had shared that his product management newsletter had 2,000 paid subscribers. Orosz reasoned that every team has roughly ten times as many software engineers as product managers. Engineers might be less likely to pay, but no paid newsletter for engineers existed. He gave himself six months and assumed it might not work. It did.
What an "AI-native SDLC" looks like, and why he doubts it transfers
Asked whether he has seen Big Tech teams adopt an AI-native software development lifecycle, Orosz first questions the framing of the SDLC itself. Many large non-tech companies run rigid Scrum or SAFe processes and call themselves agile. They are surprised to see that teams at Uber, Meta, or Google plan for a few days, build, deploy, get feedback, and iterate. To those companies this looks like waterfall. Orosz argues that the waterfall-versus-agile distinction no longer matters. Referring to a conversation with Kent Beck, he says real waterfall meant a year or two of planning and heavy documentation, and nobody does that anymore. Before AI, almost every modern company used RFCs or design docs because thinking things through before building produces better results.
The closest thing to an AI-native process at a large, successful company, in his view, is Anthropic. It likely employs hundreds of engineers rather than thousands. Orosz describes it as a research lab rather than a product company, and he says it works very fluidly. From his conversations with Boris Cherny about Claude Code, he reports that the team skips design docs, prototypes constantly, responds to bugs on social media, and fixes them immediately. Claude Code is now the leading coding harness, so the approach clearly works for them. Orosz still wonders whether it can be replicated and when it might break down. He also asks how much strategy sits behind it, pointing to pricing tiers that keep changing back and forth.
He has not seen any established company successfully retrofit an AI-native process. What he sees instead is companies such as Google, Ramp, and Uber building AI infrastructure, for example coding agents wired into all their internal services. He also raises a question he considers unresolved. When a business already works and customers expect certain things, how much should it change? At Uber, the car arriving depends on non-software processes: driver outreach campaigns and advance notice before big events. AI does not change the pace of those. Moving too fast can also mean forgetting the basics. He cites Spotify. Its CTO and team told him they adopt AI responsibly, yet as a user Orosz has been frustrated by outages. He could not publish an episode a few weeks earlier, and Spotify has no status page. He does not know whether AI is to blame, but he remarks that if they are using AI, they are not using it to improve reliability.
Hiring after AI: two worlds, more friction
Before answering how AI has changed what employers look for, Orosz asks Giginiak how Wordsmith hires. Giginiak says the company now looks mainly for the ability to reason about what AI produces, correct it, and do appropriate research. Candidates get a take-home assignment that the company expects them to complete with AI. A long discussion follows. The interviewers ask whether an algorithm or design decision was the candidate's own researched choice or simply AI's default. They also examine parts of the code to see whether the candidate can spot issues and propose fixes on the spot.
Orosz describes hiring before AI as two worlds. The first is Google's model of algorithmic coding interviews. Google adopted them after abandoning puzzle questions because they select for computer science fundamentals, the ability to perform under pressure and explain one's thinking, and scalability: you can train a thousand interviewers on a pool of 200 questions, and a few leaks do not move the bar. Orosz adds a less flattering benefit. Candidates must be willing to prepare, and that selects for people who will tolerate occasional corporate nonsense such as performance review cycles or projects that make no sense. The second world is startups hiring for practicality: trial weeks, take-homes built on real bugs, and hiring open-source contributors directly.
AI breaks both. It passes algorithmic interviews easily, so remote versions stop making sense, and it completes hard take-homes well enough that they lose their signal. Orosz bets that both worlds will survive in modified form. Early filters will be AI-assisted and effectively cheatable, and the deciding stages will move in person. Google will bring candidates in for whiteboard interviews where AI cannot help. Startups will ask candidates to explain their work, as Wordsmith does, and a few, such as Linear, will run paid work trials. His conclusion is that hiring will involve "more friction," more time, and more subjectivity, and that it will "feel more unfair because there will be no clear rules" of the kind people had grown used to.
Giginiak says Wordsmith used work trials in its early stages and found them hard to scale. Orosz clarifies that the hard part is candidates: many cannot take a week off. Linear can do it only because it is so well known, and even Linear loses people who would like to join but cannot spare the time.
Who is thriving, and the tiers of companies
Despite the layoffs, Orosz talks to engineers who are as much in demand as ever, or more. They work at startups or well-known tech companies, they are product-minded, and they "don't stop at borders." When AI arrived, they found a way onto AI projects at their companies, often AI infrastructure, and are now treated as experts. The hardest roles to fill, he says, are for engineers with a few years of experience who have actually built something with AI and can advise on architecture: RAG versus fine-tuning, off-the-shelf versus custom models, on-prem versus hosted, inference costs, and which inference providers to use, with Groq and Cerebras as examples. He compares this to hiring someone who knew the cloud five years ago. These engineers' main problem is that other companies are surprised by their compensation expectations.
The engineers who struggle have no exposure to building with AI at work beyond using Claude Code or Codex like everyone else, and they lack pedigree, meaning they do not work at a company seen as modern. Orosz frames this with a tier model. At the bottom are consulting firms such as Accenture or Capgemini, which he says are struggling. Next come product companies. Above them are venture-funded product companies, which compete with Big Tech for talent. At the top today are the AI labs, Anthropic and OpenAI, occupying the position Google held around 2004, Meta around 2010, and Uber briefly around 2015. Jumping tiers is hard. He knows many people at Google and Meta who want to get into the labs, and those places are now extremely selective.
Juniors, and junior roles in systems programming
A question about junior roles in low-level systems, embedded, hardware, and defense gets a hedged answer. Orosz says he knows this area less well and assumes it is less saturated. At the Pragmatic Summit in February, about eight people were discussing AI coding tools. Most said nearly all of their code was generated, using models such as Opus 4.5 or 4.6 or Codex 5.4. The one engineer working in C++ and assembly said AI wrote perhaps 30% of their code. Orosz sees this area as closer to electrical and hardware engineering. He observes strong demand there, with more startups and more money in hardware. He also believes that someone who can build high-performance, low-latency systems in C++ can easily learn higher layers of the stack, while the reverse is rarely true.
His general advice to juniors: pedigree helps, so pursue good schools and internships. Otherwise, build impressive projects or contribute to open source, which he thinks still stands out, especially now that AI-generated contributions are being rejected. Accept a stepping stone, because any job beats no job. Then try to be the best at whatever job you get, even a bad one, build a network, and wait for the next opportunity.
Meta's "wartime mode"
One questioner asks how Meta's leadership could fail to foresee the damage to morale from cutting 10% after a record year and then reassigning another 10% without consent. Orosz says directors and people above them at Meta do see it. The real question, in his view, is whether founder Mark Zuckerberg sees it, and if so, why he does not care. He notes that companies with career CEOs, such as Uber, Microsoft, and Google, have not done anything similar, presumably because they know it would cause outages and cost them their best people. At Meta, some strong long-tenured engineers who had been content have been reassigned to work they do not want, such as data labeling within an AI data organization. Orosz adds that some people there, often less experienced engineers, are making the most of it. But the message many take away is that leadership no longer cares about engineering as a whole.
He stresses that the rest is speculation. Meta has entered wartime mode before, when Google+ launched and the company believed its survival was at stake, and everyone understood why. Now, he says, it looks like wartime without a visible enemy: revenue is at a record, ads are doing well, and products are growing. Owning AI seems existential to Zuckerberg, as the metaverse once did, and people are starting to ask Meta to "pick a lane." Orosz offers one possible explanation: Meta still owns no platform and remains an application-layer company, and Zuckerberg may want to break out of that. He says the simplest route is to ask Zuckerberg directly.
How Big Tech and "little tech" are adopting AI
Orosz ranks Google as trying the hardest. Its approach of letting everyone build internal AI tools is chaotic but productive. Google is also the only Big Tech company with a competitive frontier model, and Gemini is, in his view, the one product actually taking market share from ChatGPT. As an anecdote, he mentions that his editor now uses Gemini instead of ChatGPT, partly because it is free. Meta, he says, is bogged down in training its own models, and morale is falling. Microsoft is, in his assessment, more focused on politics than on AI. He describes overlapping organizations, GitHub now sitting under CoreAI with its source-control mission seemingly neglected and reliability suffering, and Azure short on capacity. Apple is secretive, and everything he hears suggests its engineering culture is poor and held together with duct tape. He nonetheless hopes Apple will push local AI on its hardware, and he credits it with not forgetting its core business. Amazon, in his view, shows how hard it is to retrofit innovation: it built Kiro and its own models, but he calls them subpar and says engineers drag their feet and prefer Claude Code.
He thinks the smaller public companies are further ahead: Uber, Ramp, Intercom, and Block (with a caveat about its layoffs). They have no identity crisis. They do not feel they must own the model, the application layer, and the platform. They take the best available tools, whether Claude Code or Codex, integrate them deeply, and optimize for their own business.
Should anyone copy Anthropic?
Orosz accepts that Anthropic, along with possibly the Codex team, is the best example of AI-native development at scale. He argues that it is nearly impossible to copy, because Anthropic's product is Claude, the model, not Claude Code. Claude Code generates revenue, but the whole organization works like a beehive around training and shipping a new model every few months. To copy it, you would have to become an AI lab. He also notes that Anthropic seems to have little or no enterprise sales team, which makes it an anomaly.
What he has not yet seen is startups fundamentally changing how they work. He suspects the reason is that traction matters more than process. No amount of AI-nativeness helps without customers and a market. Before AI, a great idea could succeed with weak engineering: early Uber had contractors building an ugly app, but it solved a real need in the right city. Coinbase is his other example. However AI-native it tries to be, its results follow the crypto market, and it recently made layoffs after a downturn. He wonders aloud whether "AI-native" is overrated.
Giginiak argues that adopting AI just because Anthropic does is a poor strategy. It works better to start from a concrete problem, such as having AI take a first pass at incident debugging, and keep the practice only if it sticks. Orosz suggests thinking of AI as a natural tool you reach for: try it, keep it if it helps, discard it or revisit it later if it does not, and do not be precious about it.
Tech debt, standards, and managers who code
On whether sacrificing code quality for AI speed is worth it, Orosz admits engineers know which answer they want. He then tells a story from before AI. Before its 2016 rewrite, the Uber app polled the server every five seconds for an ever-growing blob of several hundred kilobytes. He calls it inaccurate, slow, wasteful, and "honestly stupid." It existed because a small backend team could not keep up with the larger mobile and web teams, so they created a catch-all blob that frontend teams could extend at will. It was terrible architecture, and it also unblocked Uber's growth for a long time. His point is that tech debt can speed you up. He proposes thinking in stages, using Kent Beck's explore/expand/extract framing. When exploring for an idea, ignore quality. When scaling after product-market fit, pay more attention, knowing that revenue will let you hire people to fix the hacks. With a mature product, such as Instagram, which he says Meta still managed to damage, be very careful. He adds that AI speeds up refactoring as well as building, which removes the excuse for never doing it. Giginiak calls speed versus quality a false dichotomy and suggests segmenting by time or by codebase, for example infrastructure versus product.
On whether the industry should deliberately create AI standards, Orosz says it is too early and that standards emerge by accident. MCP succeeded because it came from Anthropic when Anthropic was a small, non-threatening lab. If Anthropic proposed the same thing today, he says, others would resist out of fear of lock-in.
On whether engineering managers should code, as at Anthropic, or focus on people, as at Meta and Uber, he sees trade-offs rather than a right answer. He recalls Elon Musk mandating that managers at X code while having 20+ reports. Non-coding managers pay more attention to people and fix organizational problems, for example working with HR to change a policy or coordinating teams to stop duplicated work. Coding managers give better technical guidance but have less bandwidth for that systems-level work. The industry is swinging strongly toward technical managers, so Orosz expects engineers to get less support and people-focused managers to feel underappreciated for a while. He thinks the pendulum will swing back at some point but does not know when.
Measuring AI productivity, and a common misconception
Orosz considers the problem of AI adoption turning into theater (token leaderboards, mandatory usage) largely obsolete. That frustration dates from the autocomplete era, before models like Opus 4.5 and GPT-5.4 and before Claude Code spread. Shopify ran token leaderboards back then and has since deprecated them. Now that nearly everyone uses these tools, he thinks measuring usage is about as meaningful as counting lines of code.
On what would convince him of real productivity gains, he goes back to Uber. People there told him revenue did not matter, only growth. Headcount was a black box: fill your allocation quickly and you got more, and unused headcount was reallocated at year's end. That always felt wrong to him. He stayed on teams where he could say what two more engineers would add in revenue, or what losing half the team would cost. He passed on a platform team building an internal React Native alternative because he could not see the business case. By that standard, he argues, AI productivity cannot be separated from business productivity. There are only two measures: incremental revenue that would not otherwise exist, which excludes gains from a rising market, and cost savings. He admits he finds it "kind of depressing" that cost savings may be AI's biggest use case, though companies selling AI products, including the labs and startups such as AI incident-review tools, clearly make money from it. His private hunch is that AI will resemble cloud, which is now everywhere, even at banks that once swore they would never adopt it, but invisible to customers and mostly a flexible way to control costs. He contrasts this with mobile, which created entirely new markets.
The popular belief he thinks is wrong is that AI makes work easier. If AI is making your life much easier, he asks whether you are trying hard enough. His own experience is that work with AI is just as hard as before, if not harder.
Degrees, prestige, and self-taught engineers
Orosz believes computer science is becoming more of a prestige field, mostly because of the market rather than what degrees teach. From about 2015 to 2020, bootcamp graduates could land well-paid jobs because every university graduate was already snapped up. That era has ended. Most companies no longer hire from bootcamps, and apprenticeships exist only in small pockets. Graduates of top schools such as MIT, Caltech, Harvard, Waterloo, and Imperial are still recruited, but they receive fewer competing offers, and graduates of mid-tier schools face a harder market. He tells of a self-taught engineer with five years of experience in SRE and infrastructure work who could not find a job for a year after being laid off and is now considering changing fields or working independently. Large employers use degree requirements to filter applicants because they already receive too many resumes. He also points out a less obvious advantage: degrees matter a great deal for visas and immigration, and that can pay off decades later.
How Orosz works with AI himself
Most of Orosz's time goes to research and writing. He also builds software for his business, including a backend for group subscriptions, customer support tooling, and now a self-service company signup flow he had long put off. He describes it as simple CRUD on a database running on infrastructure like Render. Where he would once have bought a SaaS product, he now prefers to build. He uses Codex with GPT-5.5 and Claude Code, and he rotates through Cursor and Factory. AI makes building less intimidating and makes him more ambitious, but it has not tempted him back into software full-time, because he loves the human connection of his current work.
He uses no AI in his writing. He experimented with having it generate an article in his voice from notes, and he did not think it sounded like him; it felt artificial. More importantly, for him writing is thinking. Many of his most popular social media posts are ideas that surfaced while he was revisiting a topic for the third time. He compares himself to a Hacker News commenter's observation that the best photography YouTubers are working photographers who post occasionally. His main job is research: staying close to engineers he knows. That, he says, is how he noticed Meta's decline, when 10 to 15 long-time contacts there started "sounding the alarm bell." He uses deep research heavily, yet he does not feel he works less. He simply researches more than he ever would have.
He accepts that some skills will weaken. His ability to search the web manually may decline, but that was drudgery, and he still checks deep research's sources, especially when they lean heavily on Reddit. His hand-coding fluency will probably degrade, and he is fine with that. His general rule is that any skill you delegate to AI will decline, so decide whether you can accept that.
Advice for specific situations
For a QA engineer in banking who is thinking of quitting to study computer science full-time, Orosz's advice is to future-proof from inside the job. Propose a part-time AI experiment, even an internal tool. Leaders currently want more AI use, so this is usually a win-win, and the worst case is that you learn something like RAG. He praises Google for encouraging this. A full-time degree may lag the industry during a shift this big, and hands-on work is the best way to learn. Changing jobs is harder, and side projects work only if something genuinely motivates you.
For a student whose classmates are not very motivated, he suggests finding people elsewhere: other classes, online communities, or other teams at work. He recalls being one of only two coders at his high school, and the difference between a bank where colleagues were kind but not passionate about technology and Skype, where everyone was.
For a parent whose son wants to become a game developer, Orosz says nobody knows what five years will bring. He offers a construction analogy. Anyone can buy professional tools and materials and learn from YouTube, yet professional builders still have work because most people would rather hire them. He expects tech to work the same way, with DIY growing alongside a lasting professional path. The games released in ten years will come from startups or AAA studios hiring graduates and people who build games on the side. He points to his episode with Jonas Tyroller, whose game sold a million copies with a two-person team and who has built games on the side for many years. His advice: encourage the son to start building games now.
For engineers in the EU choosing between aiming higher and staying put, he notes that staying put can be sensible in a volatile market. But this market is not 2023's, when layoffs were everywhere and nobody was hiring. Many companies are hiring now, which may create chances to move up a tier to more autonomy and more AI exposure. Staying at a slow-moving company could leave you with zero years of the experience that will be in demand. He recommends staying opportunistic: talk to your network, do not ignore recruiters, and remember you can always turn down an offer.
On using AI to learn, his view is that AI only helped him when he already wanted to learn something. It gives you one fewer excuse, but it will not make learning easier without motivation, and books, videos, and building things still matter.
The Pragmatic Engineer as a business
Orosz avoids giving exact income figures because every time he did, he was flooded with requests for coaching and financial advice. He shares scale instead. In the first year he had about 2,700 paying subscribers, and today there are more than 10,000, plus podcast sponsors. For comparison, his best year at Uber in the Netherlands paid roughly €288,000 (about $320–330k at the time), of which about €120k was base salary, with a bonus of roughly €26–30k and the rest in equity. He started with modest expectations based on Lenny's roughly $300k. In the first week he had 100 paying subscribers, about $10,000 paid upfront. At six weeks he had 1,000, roughly $100,000 a year at the original $100 price. Within four or five months his annual run rate exceeded his best Uber total compensation. He then stopped watching the numbers for about two years and focused on writing one good article at a time. He credits his 15 or so years as a developer, and the connections he made, with making the business possible. He says he is not attached to it: if interest faded, he could live with that as long as he had helped people. He has also chosen to leave important pieces outside the paywall even though it costs revenue.
Because he took no VC funding, he says he has no obligation to expand. His plans are to make the Pragmatic Summit a regular event, ideally with one in the US and one in Europe, perhaps London; to grow his small team slowly; and to do more ambitious research, including into "boring" but important industries such as utilities.
Two articles that caused trouble
Asked whether anyone has tried to sue him, Orosz describes two articles. The first, about the Dutch neobank bunq, he never published. In his first year, he was upset by bunq's use of intelligence tests before technical interviews, tweeted about it, and received evidence-backed stories from unhappy employees. His draft read like a hit piece. At his editor's suggestion, he sent it to bunq, then slept on it. He asked what it would achieve: bunq would only get defensive, and the article contained nothing positive about a growing business that employs people. He also heard from someone who had found bunq tough but called it a crucial stepping stone. That person could not get a Dutch visa sponsor anywhere else, was hired by bunq, and now works at Facebook. Orosz deleted the draft and decided to focus on writing about what works. Journalists later asked him for the details, and he declined.
The second article was about Pollen, the events company. Orosz had briefly noted in a layoffs roundup that Pollen handled its layoffs poorly. At an all-hands, the CEO reportedly dismissed his newsletter as a small publication with an agenda, not the BBC or Panorama. Angered, Orosz wrote a full investigation into unpaid salaries, canceled health insurance, and what he describes as a deliberate double charge of customers disguised as an outage. When he sent it to Pollen, the company called various claims libelous, and he self-censored parts of the piece. The BBC later reported on the company and made a documentary, which Orosz says he helped with. The experience convinced him that investigative journalism is not for him.
Trends, the book, and favorite tools
Orosz spots trends when several people start saying the same thing. Over the Christmas break he used Claude Code heavily and was impressed. He then researched whether others felt the same, and that led to his early article arguing that coding by hand is over. Some readers called him an AI shill, but he says his own experience plus the evidence he gathered supported the piece.
He considers The Software Engineer's Guidebook surprisingly durable, because it contained little about coding and its non-technical parts, such as understanding the business and software architecture, have become more relevant. He will revisit it once real best practices for AI-era engineering emerge, which he expects to take a while.
His favorite technical books are John Ousterhout's A Philosophy of Software Design, which he values as the only book comparing architecture approaches across groups of students and for its ideas of deep and shallow modules, and Kent Beck's Tidy First?, for how crisp every idea is. Among products, he names Granola for meeting notes as an example of what an AI-enhanced product can be, and Perplexity's deep research, which he finds the fastest of its kind and wishes Google Search resembled. He notes he pays for both and has no affiliation, and he does not care for Perplexity's newer push into areas like its "computer" product.
What will stay the same
Asked what will not change in five years, Orosz bets there will be as much demand as today, and he hopes more, for true professionals who care about the craft. He describes them as people who know where the industry stands, have used most of the tools, understand their trade-offs, and "have no ego and just choose the right one for the right job," whether for writing code, testing, deploying, or verifying correctness. He compares them to an architect who looks at a building and sees load-bearing concerns and earthquake resistance where a pedestrian sees pretty windows. Such people can change systems confidently, sometimes with scaffolding and sometimes without. He hopes AI will not scare those people away, and he suggests it may instead drive out those who never cared about software and were only there to make a quick buck.
What made you switch from a full IC role like at Uber to focus on tech content?
My plan was leave Uber, finish writing The Software Engineer's Guidebook in 6 months and afterwards start a startup, join a startup. I was a little bit tired of being a middle manager. They tell you congratulations, you become a manager. They should have said you became a middle manager.
Have you seen how AI is impacting what employers look for in candidates?
Hiring will honestly just be more friction. It'll feel more unfair because there will be no clear rules we have about used to and it'll be messy.
What's one thing about software engineering that will be the same in 5 years?
There will be just as big a demand for professionals who care about the craft. You have no ego and you just choose the right one for the right job.
Have you ever gotten in trouble over an article? Has anyone tried to sue you?
Yes, once. Two articles actually.
Today's episode is a different one. It's an AMA where I answer questions that you submitted. Asking the questions is Giggs. That is Volodymyr Giginiak, CTO at Wordsmith. Wordsmith is a legal AI startup where I'm an investor and know the team well. And Giggs was just in town to help out with this AMA. We've grouped the questions as observations across the industry, opinions on AI, opinions on hiring, questions about myself, advice on specific situations, and The Pragmatic Engineer as a business. Thanks to Antithesis for being our presenting sponsor. With Antithesis, you can verify your system's correctness without human review or traditional integration tests and avoid bugs or outages. With this, let's jump in.
Hey Ger, welcome to this reversed podcast AMA.
It's really nice to be a guest on my own podcast. This is really cool, and thanks for coming here. For some background, we know each other from Wordsmith, which is one of the very few startups I still invest in, because I stopped investing, but about two years ago I invested with a friend, Ross, who I worked together with. It's really nice to have you here.
Yeah, and I very much appreciate you putting trust in us in investing, and let's get started. So first question: what made you switch from a full IC role like at Uber to focus on sharing, reporting tech content?
Yeah. So at Uber I started as an IC, and I was an IC for about 10 years before Uber. I started as a senior engineer. I became an engineering manager pretty quickly. It wasn't an IC role but I guess a manager role, but it doesn't change the story too much. I was hitting about four years at Uber and two things happened at the same time. One is Uber in 2020 had layoffs because COVID hit Uber's business really bad. I had access to our internal dashboard where we saw revenue for rides and it was just going down very close to zero, and I was actually sharing it with my team because I figured transparency is a good thing. I'm not sure that was the smartest thing but I'd probably still do it again. People were like, this is not looking good, and we were all collectively freaking out a little bit, and layoffs came very predictably.
It was a 20% layoff. About a quarter of my team was unfortunately gone, and for the remainder of my team, our mission no longer made sense in this new world where we were building something for drivers when we thought there would not be as many drivers or we had to compete for them, but because of COVID, drivers actually were flocking to the platform. And so I got a new team to work with, but it felt to me for the first time in 4 years, when things were going really well, I just felt demotivated. I knew that the business would be doing poorly, and I also asked myself what I wanted to do after Uber. Right before I joined Uber I got this offer, which was an amazing compensation package with a bunch of stock, and I told myself, well, stock, who knows if Uber will go public or not. But I said if Uber does go public and this turns into stock, I got about $500,000 worth of stock as a grant option. And I'm like, if I have like 500k in my bank account, well, I can take a risk, and for the next thing I can actually do a startup. So I remembered this, and Uber had gone public, and that 500k stock turned into 400k because the stock price was a bit lower and then you have to pay taxes on it. So it was less, but I still had a lump sum sitting in my savings account and I was like, huh, I don't have to work actually. I could not work for like two, three years easily. So I was like, well, maybe I should take a risk.
And my plan was leave Uber, finish writing The Software Engineer's Guidebook, which is something I started writing at Uber, just finish it in six months, and afterwards do what you've done, which is start a startup, join a startup, because I was a little bit tired of being a middle manager. They tell you you're a manager, you know, congratulations, you became a manager. They should have said you became a middle manager, because now your job is to keep your team happy, to keep management happy, and especially I was in a different region. I was in Europe, so this was easy, but when layoffs came it was a lot of politics, a lot of explaining regulations, and it wasn't what I wanted to do. Also keep your peers happy, in terms of your manager peers. It was pretty tiring, and I was like, I want to be in charge next time, because I have a lot of ideas, but I felt I was fighting the machine, if you will, in some sense.
So that was my plan. It involved nothing with writing except just finish this book. I have a legacy. I can give this book to people. I can be proud of it. But then what happened is similar to software engineering when you start a project in software engineering you've never ever done before. You're a junior engineer. You're doing your first migration. You think it'll take two days and then two months later you're still stuck there. And it was the same thing with writing this book. I'd never written a book. I knew it's a big project but I was like, yeah, six months should be enough. Six months later I'm treading water. I wrote three other short books, but my main book was not progressing.
And I asked myself, okay, I gave myself about six to eight months to get this book out and then just go and have a real job. In my mind a real job was either start a startup, be a founder, or go back to being an engineering manager or staff engineer or a CTO at a smaller place. And I was like, okay, well, I should be honest with myself. What am I doing right now and what will I be doing? And I was like, either I start and I raise funds to start a startup. And my idea of a startup was just, Uber had a lot of platform engineering teams, copy one of the things that they were doing. My idea was actually we had an internal RFC system, request for comments, where we actually had a system that put these Google Docs together and we graded them and all that, and it was a pretty cool system. I thought maybe I could productionize that. A lot of Uber startups actually came from people looking at internal platform stuff and taking it and either making it open source. Temporal is ex-Uber, Chronosphere, ex-Uber observability system, and many others. So actually it's not all that radical.
But then I was like, well, if I did that, I'd just have to fully focus on that, and on the side I was doing writing. I was writing a few books actually, I was blogging, I was doing YouTube videos out of fun, and I was like, well, I need to stop that if I do that, because if I raise money I owe that to my investors, I will hire people, and for about 5 to 10 years I'm going to be happy to be just focused 100% on that. I talked with my brother. He was on his second startup and he said, look, if you start a startup, do it because you are ready to spend 10 years of your life on it. You need to believe that right now, because if you don't, it's not going to work, because startups are just really hard. It's not a popular thing to say. And I wasn't sure I was ready to spend 10 years on an RFC system. I wasn't that excited about it.
And then I asked myself, okay, what is this drive? Why do I really want to do this startup or a startup? And I was trying to be honest. I had two answers. One was the money, in the sense that this was 2021. It seemed everywhere I looked, ex-Uber startups were valued at a billion. They were unicorns in a matter of a year or two. It seemed too easy, and I was reasonable. I was like, that will probably not happen to me. But what might happen is I might be able to build a unicorn in, let's say, 10 years' time. And by that time, if I'm a solo founder, I might have a five or 10% stake, because I'll count with a lot of high dilution, which is $50 million, and let's say we have an exit and I leave and then I pay taxes and I still have 25 million, which is exactly 24 more than I would need outside of buying a house, and then I have this FU money. What would I do? The answer was, well, I'd probably share what I know. I'd probably write a book. I'd probably do some YouTube videos. I was like, huh, interesting. I could do that right now.
And the other reason I wanted to do the startup was the small teams. I always loved working, both at Uber and at my previous companies, at Skyscanner, where I met Ross, co-founder of Wordsmith. We were a small team, us against the world. And I love that feeling, being either an engineer on that team or the manager of that team. I didn't enjoy being a manager of managers, but I no longer had connection. And that was the other reason. And actually that was, I guess, the more legit reason. But in the end, I didn't have this exciting idea, and actually I was like, if this startup was successful, I would just be writing probably. So I was like, let me try that. I saw Substack was taking off. Lenny Rachitsky shared that he had 2,000 paid subscribers for his product management newsletter. I thought if Lenny has 2,000 paid subscribers for product management, there's 10 times as many software engineers as product managers in every single team, and they're not as likely to buy. But there were no paid newsletters for software engineers. So I was like, let me try it out. I gave myself six months and I figured it might not work, and then it just worked. It took off.
Yeah, makes sense. Next question. Have you seen engineering teams at big tech that adopted AI-native SDLC, and how do they collaborate across engineering, product and design?
Yeah. So AI-native SDLC, software development life cycle. Even the whole SDLC is an interesting one before we get into AI, because what is SDLC? It used to be you plan, you code, you deploy, you monitor, and some people used to call this waterfall, and then there was agile where you just iterate a lot faster.
And interesting thing, outside of big tech or outside of these large tech companies, if you go to a large company that is not a big tech, not one of the Googles or Metas, they often have pretty rigid processes around Scrum specifically. They say we're very agile, we have Scrum, or they have the SAFe system, the Scaled Agile Framework, which has a bunch of meetings and a really rigid way to be agile. And of course there's a bunch of money and consulting and all that, but they think they're very agile, and then they're very surprised to see how most teams inside of the likes of Uber or Meta or even Google work, which is like, oh, we kind of have this problem. We actually plan, we sit together, we do a few days of planning, and then we code it and then we deploy it and then we get some feedback and we might iterate. And they're like, well, that's waterfall, we're so much more agile. And actually the whole thing about waterfall and agile is it doesn't matter anymore. Waterfall used to be a thing. I talked with Kent Beck: it literally used to be a year or two of planning and having this much documentation, and we don't do that anymore.
So the software development life cycle is an interesting one, and almost every modern company up to AI used to have RFCs or RFDs or design docs where people would write things down, because they realized that if you plan things ahead and then you build, you'll have better results, plan things in terms of thinking through.
Now, the whole AI-native SDLC: the closest I've seen to a company who is big and successful and making a lot of money and employing hundreds or thousands of engineers is Anthropic. They don't employ thousands of engineers. They employ probably hundreds of engineers right now. But they're a very interesting place. They're not a product company decisively. They're a research lab, and they just do everything super fluidly. You can see it in Claude Code, and I've talked with Boris Cherny about this. They don't do design docs. They just do prototypes all the time. They show it to themselves. But I wonder if it's really replicable, and I also wonder when it will break down, in the sense that Claude Code is a great product. It's now the leading coding harness. So they did an amazing job, just with prototypes and iteration and using AI and getting feedback and fixing it and responding on social media. They respond to bugs, they fix it immediately. But there's a question to me sometimes: how much do they plan, do they have a strategy? Like with pricing, they keep changing the tiers back and forth.
And Anthropic is the closest I can think of, but I did not see any company that managed to really retrofit anything. What I'm seeing almost every company do: they are building AI infra systems. So for example, they will build a coding agent that talks with all their internal services, that's plugged in. Google is doing this. Ramp is doing this. Uber is doing it. So I think what's happening is they're building a lot better tooling to make this easier. And I think that's where we'll see it.
And I still have one last question, which is: if you have a business that is working, it's making money, it has a rhythm, you have customers who are used to certain things, how much do you want to change everything inside versus just changing it slowly? For example, in the case of Uber, people expect that when you press the button the car arrives, that the drivers are there. There's processes behind this which are non-software. You need to do outreach campaigns for the drivers. You need to let them know weeks in advance when there will be a big event so that they can prepare for it. The pace of the business has not changed because of AI, even though AI speeds up development.
And finally, when you just go too fast, you might forget the basics, which I'm seeing a lot. Spotify is a good example, where I've talked with their CTO and their team and they say they do AI very responsibly, which is great to hear. But then again, as a customer and a user, I'm so frustrated because they seem to be down so much. I couldn't publish an episode two or 3 weeks ago because they were down, and they don't have a status page, and I don't know if it's AI or not, right? It might not be. But then the whole site just went down and I'm like, if you're using AI, you're sure not using it to make better reliability.
Have you seen how AI is impacting what employers look for in candidates?
Yeah. Well, it's impacting it because it feels to me that they just don't really know what to look for. I'm going to ask you for this one. I'm going to turn it, because you guys are hiring. How did it change how you're hiring for software engineering? And then I'll answer.
Yeah. So in our case, we definitely structure the interview quite differently. So the main thing that we're looking for now is the ability
to reason through what AI is doing and correct it and do the appropriate research. So actually it's interesting, like our interview process: we give away a homework, which is, you know, pretty classic, but we expect that this homework will be done with AI. But then we basically have a very long discussion around this homework and we are checking: okay, you picked this algorithm, was it AI picking it for you or did you actually do research and you figured out what is appropriate? Or here is a design decision that you made, how did you make this decision? Again, is it an automatic decision by AI, or you understand it deeply and you can course correct? And then we are peeking into different parts of the code and we are seeing how the candidate can react on the spot, whether they can spot an issue, whether they can come up quickly with a solution to the issue. So basically the ability to reason through and research, and not just apply all the solutions that AI generates automatically.
So this makes a lot of sense, and I've seen a lot of similar things with startups doing it. And when we think of how hiring is changing with AI: before AI there were two worlds in hiring. There was the Google interview process, which is the LeetCode interview process, and this is because Google decided early on that they want to hire for raw intelligence. They had puzzles initially, like, you know, how many golf balls fit in New York or something like that, but they realized that doesn't really scale that well, and they found coding interviews, algorithmic coding interviews, to work really well because it selected for a few things. It selected for people who have computer science basics, which Google needed, specifically going to universities where they teach computational complexity and some of those things. It also selected to, you know, apply under pressure, explain your thinking, and it's very scalable, meaning you can train, you know, a thousand interviewers and give them a pool of 200 questions, and it doesn't matter if a few questions leak, the bar will be the same. And it works great for Google. It really does.
Oh, and a bonus is that people, once they know that this is expected of them, you need to prepare. And if you're unwilling to prepare for this, you're not going to be a good fit at a place like Google, where sometimes you need to do stupid stuff. There's performance reviews, we need to do this thing. There's a new project coming up which makes no sense, but we need to do it. And you know, corporate needs people who put up with BS processes every now and then without too much complaint. So it kind of selects for that. So kind of wonderful. And this is why most of Big Tech has just adopted that. And Google knows that you're not going to do that work, you're not going to use those algorithms. But again, it works well enough for them because they hire people who are adaptable. You learn stuff and you pick up new things anyway.
And then startups, you just hire for practicality. So this is where trial weeks have been popular, where a lot of startups used to hire by just giving you real work. For example, a take-home: fix a real bug in a few hours or a few days, and they could actually see, like, oh, you're actually doing the work. And startups who are doing open source often would just hire the contributors to the repository.
What AI has changed is, first of all, the algorithmic interview: it just whizzes through it. So doing it remotely no longer makes sense. And with the take-home, where you used to give someone a difficult take-home, AI will complete it pretty well. So you don't really get that signal.
So my bet is that what will happen is these worlds will stay, except the in-person part is where the decision will be made. You'll have filtering, like a take-home task that you can do with AI, and you can cheat if you will. But when you talk with them at Google, they will still have you come into the office and you'll have to do those whiteboard interviews, and if you didn't prepare, AI is not going to save you because you don't have access to it. And startups will probably want you to explain what you did, and a small percentage of startups who can do it will just have the trial weeks, like what Linear does: come work with us for a week, you need to collaborate. You can use AI, of course you can, but it's not the main thing of it. So I think hiring will honestly just be more... As a candidate, there will be more friction. You'll need to invest more time. It'll feel more unfair because there will be no clear rules that we have gotten used to, and it'll be messy. It'll also be more subjective. Just a reality.
Yeah, working together, by the way, is an amazing way to hire. We did that at the earlier stages. It's just a little bit hard to scale, but it's interesting that Linear managed to scale it. That's
Well, and by scaling you mean that yes, you know, it's hard to do it. So most candidates will say yes because you need to take time off. The only reason Linear can do it is they are very, very well known in the industry, and even then a lot of people say, "I'm sorry, I cannot do it. I'd love to work there, but I just don't have the time." And so they lose a bunch of those folks.
What kind of engineers are thriving and excelling right now? We hear about layoffs and slowdowns, but surely some are doing better than others.
Yeah. So we do hear about layoffs, but I talk with engineers who are very much in demand, just as much or maybe more so than before. And what these people have is they either work at startups or well-known tech companies. They are interested in the business. They're so-called product-minded. You know, they don't stop at borders. And by this time, whenever AI came around, they just got into it. They somehow weaseled their way, either at their company, saying, "Okay, I'm going to work on this AI project, building something on top of AI," often AI infra, like, I will help build this part. And now they're actually considered experts in this. And most companies that are hiring and trying to fill positions, the ones that are hard to fill are: I'd like an engineer who has a few years of experience. They've actually built something with AI, they're not an absolute noob to this. They will help me decide what architecture we should use. Should we use RAG? Should we use fine-tuning? Should we use an off-the-shelf model? Should we use our own model? Should we run it on-prem? Should we do it off-prem? What about the inference costs? What about, should we use Groq? Should we use Cerebras? So, you know, 5 years ago this was: you hired an engineer who knew about cloud and could help you figure it out at a startup. Now you're hiring someone who knows about inference and some of these things, and so engineers who have been doing this are in very high demand. The only problem they have is sometimes, if they work at the likes of Google, Meta, or a well-funded startup, these other companies are surprised at how high of a compensation ask they have. But these people are very much in high demand.
The people who are having trouble are either those who at their current work just have no exposure to using any AI, so they don't have this experience with building AI infra. You know, they still build software and they use Claude Code and Codex, but everyone does that. They feel a bit stuck on how to go about this, and they don't have good pedigree, meaning they don't work at a company that is assumed to be a modern company. And those people are finding it hard to make the jump, and now they're thinking, should I just do some side projects?
And my answer would be, well, at the very least, if you want to make that jump between the tiers of companies. And in my mind there's, I have the trimodal model, of course, but I also have this model of the companies, where you have consulting companies, like an Accenture or Capgemini or one of these, where you're given client projects. They're really struggling right now. You have the product companies, where you work and you build products, and within the product companies you have the venture-funded product companies, where you actually have a bunch of money to build quickly, scale; compensation will be higher, you're now competing and hiring from the likes of Big Tech.
And then at the very top you have, right now, the AI labs: the Anthropics, the OpenAIs. Whatever Google used to be in 2004 and Meta in 2010, and Uber for a short time in 2015 or so, now that's Anthropic and OpenAI. And it's hard to jump between these tiers. So for example, a lot of people are like, oh, I'd love to work at Anthropic. Well, I mean, dream big, but the reality is that I know so many people working at Google and Meta and Facebook who want to get into those places, but these places are extremely selective now.
So entry-level web product engineering is saturated. But what does the hiring landscape for juniors in low-level systems, hardware-software integration, embedded, or the defense stack look like? Same surplus, or a genuine shortage of systems-level thinking?
I'm less familiar with lower-level systems programming. I would just assume that it's not as saturated. When I was at the Pragmatic Summit in February, I talked with an engineer who was working on low-level systems, mostly C++, some assembly, and we talked about who's using AI: Claude Code, Codex, Cursor, etc. And he was the only one in the group. There were about eight of us talking. Everyone's like, "Yeah, using it, almost 100% of my code is generated by," back then it was Opus 4.5 or 4.6, or I think it was Codex 5.4. And he was the one saying, like, we're using it, but maybe for 30% of my code, because it's just very low level. These areas have always been, to me, a different world than general Big Tech. Big Tech hires these people. They feel a little bit closer to electrical engineering, hardware engineering. Now, in that area in general, I observe there's just big demand. There's a lot more startups. There's a lot more money in hardware tech. So hopefully it will be good.
And I also believe that knowing the basics, like if you can code in C++ and assembly, I think that's really useful knowledge and you can build on top of that, because most people who know a high-level language, TypeScript, whatever, most of them will not know how to go down to C++. If you know C++ and you can build high-performance, low-latency systems, you can easily learn the rest of the stack. And if you're in this situation, I would just look for those specific offerings. In junior positions, either you have pedigree, which makes it easier, which means you're in a good school or you had an internship at a good place, or, if you're in school, try to get that pedigree, try to get into an internship program, or build some impressive projects, either on the side, or contribute to open source, which is still a pretty good way to stand out, especially with AI contributions being rejected. You will have to work hard if you want to get to a prestigious place, and accept a stepping stone as well. Right now I think getting a job as a junior is better than getting no job. And once you have a job, try to excel. Even if it's a shitty job, try to be the best there. You'll build up a good network, and at some point hopefully you'll have a stepping stone, a new opportunity to come in and go to the next level.
A few questions about Big Tech. So when a company like Meta lays off 10% after a record year and then reassigns another 10% without consent, how does leadership fail to anticipate the obvious hit to culture and morale when everyone inside and outside can see it?
Yeah, this is the question, right? The interesting thing: I talk with people inside Meta, like some directors and even above, and they see it. [laughter] So this is not a question of, does leadership not see it. This is a question of, does the founder, specifically Mark Zuckerberg, not see it, and why does he not see it, or if he sees it, why does he not care? And we're now going into the territory of assuming what a specific person thinks. In the case of Meta, Meta is the only one who's done this. No other company that has a career CEO, I'm looking at Uber, I'm looking at Microsoft, I'm looking at Google, has done this, because they probably know what would happen, and they don't want a part of their business to go down for no reason in terms of outages, losing some of their best people. Because what's happening right now with Meta is some of the best engineers, who up to a few months ago thought, you know, I like Meta, it always treated me well, we're investing in AI, we might or might not be winning, but it's doing good, the stock is doing good, I have a good work-life balance, I've been here for 10 years, now some of them have been reassigned to do this work that they don't want to do, like this data labeling. You can make it interesting, and I talk with people who are in this organization, this AI/ADO organization, Advanced AI, that's AAI, and ADO is a data organization, but they joined and they're making the most of it, and they're engineers with less experience. But these people realize, like, well, I mean, leadership, specifically the CEO, no longer cares about engineering as a whole.
So we can only speculate. Clearly it feels like Meta has had some existential times in the past. One of them was when Google+ launched, somewhere in the 2010s, and it's well documented. There's a book about it, I'm not sure if Chaos Monkeys covers it, but it has been really well documented, where Meta went full-on wartime mode. It was like, look, Google is coming after us, they want to kill us, and everyone worked really hard because everyone understood that the fate of the company was on the line. And my sense is that Mark Zuckerberg probably thinks that this is the case right now, for some reason that is not really articulated and others don't necessarily understand, and he probably has his reasons. I don't know why he's not telling people, because Meta is operating in wartime mode, except everyone's like, where's the enemy? Revenue is record high. They're doing amazingly well in the ads business. Their products are growing, and for some reason it seems existential to Mark Zuckerberg to own AI. But again, this is where, when you look at the patterns, the metaverse also looked existential to some extent, and now AI is looking existential. I think people are starting to ask the question, like, okay, can you just pick a lane? And in all fairness, it might be hard for Meta or Mark Zuckerberg, because Meta still does not own any platform anywhere. They are an application layer still, and I think he really wants to break out of that, and I think it's just being a bit reactive, potentially. This is all speculation, so I think the easiest thing would be to just ask him, if you can.
Among Big Tech companies, specifically Google, Amazon, Meta, Microsoft, and Apple, how do you feel they're doing on AI adoption in engineering? Who is accelerating, who isn't, and who is managing the transition well?
I think Google is trying the most. They have the approach where they give free rein to everyone to build AI tools. It's a bit chaotic, but people are building a lot of things internally, and they are the only one who actually has an AI model, with Gemini, and they have a Gemini organization. And there's always talk about how they're doing compared to OpenAI and Anthropic, but they're the only ones who have any sort of competition. In fact, Gemini is the only product which is actually eating into ChatGPT's market share. My editor the other day was telling me, I don't use ChatGPT for my queries, I use Gemini because I really like Gemini, and I think he also said that it's free. So, okay, I guess there you go. So in this way, they're actually, I think, way ahead of
the others. Meta seems to be bogged down by building and training their own AI, and morale is just going down because people don't really see the point. Microsoft is in this weird place where it's still very political, as far as I understand. There's the organizations, there's the Copilot org, there's the CoreAI organization. GitHub is under CoreAI now, so is AI their mandate or is source control? They seem to be forgetting about that, and their reliability does not sell. Azure is fighting with everyone for capacity; they don't have enough. Microsoft is more focused on politics than AI, in my assessment.
Apple, I talk with people at Apple, but Apple is very secretive. And Amazon is secretive, 'cause their engineering culture is pretty good, so I'm surprised they're so secretive, but Apple is secretive because their engineering culture is absolute trash from all I gather; it's duct tape everywhere. I'm not sure much is happening at Apple, but because Apple is not doing too much, I personally hope that they will actually see local AI, locally running on your hardware, because they have a very strong hardware thing. So one thing I think Apple is doing good is they haven't forgotten about their core business, which is making devices and software that's decent. It's not great, but it's decent enough that people don't leave. And maybe that will actually be a winning strategy.
Amazon, they're also an interesting one. So Amazon is the example to me of how difficult it is to retrofit innovation, compared to Google. They're trying so hard to have AI everywhere internally. They built Kiro, their internal tool, and they have their own models, but they're all subpar. People are dragging their feet; they'd rather use Claude Code. And Amazon is full of smart people. So to me, Amazon is a good example of just how, Amazon, Microsoft, how difficult it is to bring AI to a large organization.
Companies that I think are doing a lot better than all of these companies are, I guess, the little tech, not the big tech, but the publicly traded companies who are smaller. Uber, Ramp, even Intercom, Block, save for the layoffs, but they're the ones building AI in front because they don't have an identity crisis. All of these, Amazon, Microsoft, Meta, Google, they're like, "Look, we need to own the whole stack. We need to build the AI model. We need to build the application layer. And then we need to become a platform." And Uber and Ramp are like, "No, we know our place. We want to use these the very best possible way. We will take Claude Code, Codex. We don't care. We don't want to build one of those. We will integrate it as much as we can inside of us. We will not have a foundational model. We will buy or use the best one." And so they're just focusing on optimizing it for their business. So I think they're the ones who are kind of the most ahead in terms of larger companies right now.
Anthropic, and specifically Claude Code, are shipping at an extraordinary rate, using agents for implementation, tests, reviews, incident response and many other things. Is this how AI-native development will look, or is it a very extreme environment and others would be wrong to copy it directly?
I think it's just very hard to copy Anthropic. So we cannot deny that Anthropic is the best example of AI-native development at scale, together with potentially the Codex team. And when I say Anthropic, I actually mostly mean Claude Code, and also their model, but it's all intertwined, because in an AI lab their product is, don't forget, Anthropic's product is Claude. It's not Claude Code. Claude Code is a revenue generator because Claude is so good. Their product is the model; they get a new version every few months and they do a bunch of work with training, pre-training, post-training, and then the tooling around it and everything, it's like a beehive all around this one thing. So the only way you could copy it is you become an AI lab and the product is just a byproduct, which right now is doing great, even though Anthropic, for example, doesn't even have an enterprise sales team that a lot of other ventures would have. Maybe they have, but it must be pretty small right now. I always feel that they're a bit of an anomaly.
Where I'm interested, and I'm not seeing all that much yet, is startups, how startups are completely changing how they work. And I suspect the reason I'm not seeing it is when I talk with AI-native startups who are like, okay, we're founders, we will use AI for everything, and you start a company, you realize the first hurdle is how do you get traction. And at Wordsmith, you guys luckily have gotten traction, you kind of passed that point, but for a lot of founders it doesn't matter how AI native you are if you don't have customers, if you don't have a market segment, if you don't have any of this. And I wonder if that's going to be more important: get traction, doesn't matter how. And once you have traction, it's a little bit like even pre-AI, you could assemble an amazing engineering team and build a first version of a product, or you could just have a really bad engineer but have a really good idea and launch that product and it takes off. Uber was a good example where, when it took off, Travis Kalanick just hired some contractors, made an ugly app, but it did something that people wanted, and it was at the right place in San Francisco. So I wonder if AI native is overrated, and once you have a business model, of course you can optimize it, but will AI native make all the difference? I'm not sure. And another good example is Coinbase. They're really trying to be AI native, do all those things, but in the end they're a crypto company. If the crypto market goes up, they will do great. And now they did layoffs because the crypto market just went down. So you can be as AI native as you want, and maybe you'll be able to do the same with fewer people, but I'm not as sold on this.
Yeah. To me it feels like artificially trying to become AI native is a bad strategy, right? Just saying Anthropic is doing that, so we'll copy it and try to implement it. What I think works really well is when you're seeing the problem and you understand that, oh, actually this problem can be solved really well with AI. For example, incident response, right? So why don't we try AI to do a first pass understanding what's happening? It seems like an obvious idea, and if we have problems with incidents and debugging time is taking a while, we can try, and if it sticks, then good. But some other process might not work in the company. So it depends: if there is a problem and it feels like it can be solved with AI, then it's a good idea to adopt the practice.
I wonder if instead of AI native, just think about companies where AI is a natural tool that you reach for. For anything, you try it out and it might or might not work, but you're not precious about it. You use it if it makes sense, and you throw it away if it doesn't, or you'll revisit it later.
Yeah, it's just another tool that can help you. Next one: can you share something about today's presenting sponsor? Is this really a question that people are asking?
No, this was actually not submitted by anyone, but I still want to talk about it.
Now, I admit this was the one question I sneaked in, because I really wanted to share something visually interesting about our presenting sponsor, Antithesis. It's how different their UI is. Let me show you with three examples. We already know that Antithesis verifies your system's correctness by running your whole system in a hostile simulation and finding bugs. Here's the UI for causality analysis. You can open a report for a bug and see the probability of the bug occurring throughout the timeline of the simulation. In this case, we can see that at virtual time 25, something happened that makes this bug close to 100% likely to occur. So we can jump into this point in the virtual timeline of the simulation to read the logs. This kind of bug probability visualization is one that I've just not seen before. There's also this neat log explorer. You can filter on error messages and then visualize how common or uncommon the error is over time. For example, here we're looking for linearization failures, the purple line, and you can understand how rare or common a specific failure was. Again, I've yet to see this kind of error visualization, and I really like the innovation on the UI here. And finally, the multiverse debugger. You can go back in time and replay a debug timeline. And you can inject bash commands at any time without affecting the playback of the bug. How cool is that? For example, here we're listing files in the current directory, but as you can imagine, you can debug the whole environment much more easily. I really like how the team at Antithesis are pushing what's possible with both debugging and verifying software. Head to antithesis.com/pragmatic to learn more.
Is ignoring code quality for speed with AI worth it long term? Some engineers still review the plan, architecture and code. Others rely on SDD plus harness and disregard the code. Pluses are short term, but is AI good enough to make up for worse code?
This is a big question, isn't it? And I wonder if there's any answer. I feel as engineers we know what answer we want. We want the answer to be yes, quality is important. Yes, care and craftsmanship are important. And this hasn't changed. Even before AI, we wanted this to be true.
But when I got inside of Uber, I learned about some horrible hacks that Uber did that looked really painful. For example, the old Uber app before 2016, before we had the rewrite, you would open the Uber app and you would see the ETA of the cars, you'd see the products, and you could pull the slider and then it would show how many minutes the next category would be. For example, Uber Black is 2 minutes, Uber Van is 6 minutes, and you pull it and you saw some other information on the screen. And what happened is that app was polling the server every 5 seconds to get all the information. It was a package, and so every 5 seconds you would get an increasingly large data package, but by that time it was a few hundred kilobytes, I believe, that was coming back. And this is just a terrible strategy. It's inaccurate. It's slow. It's really wasteful on resources. It's also just stupid, honestly. And this was in 2016; by that time we should have just pushed this information. But the reason this happened is the back-end team was small, and the front-end, the mobile and the web teams, were larger, and they were getting frustrated that whenever they wanted a change on the back end to get some information back, it would take days, weeks, months. And so they asked the back-end team, hey, can we do something about it? And they're like, well, there's this really hacky solution where we just send this big blob together, and you can go in the back and add whatever you want into this blob. And they're like, perfect. And it actually unblocked Uber for a long time to grow independently, but it was a terrible architecture. And so this is an example where this is clearly tech debt, but tech debt can speed you up.
And I wonder if with AI this is also true: should we not look at tech debt in the stages of a product or a company? Early stage, you're looking for an idea; just go with tech debt. We don't know if it'll work; you'll probably toss it out. There are companies at this stage where we just try out prototypes, and it doesn't matter if it's beautiful or not. Once you've found product-market fit, Kent Beck has the three X's: explore, expand, extract. And there are other ways to say this, but in the expand phase, you found product-market fit. You want to scale up. You want to quickly reach a bunch more users. And you're kind of okay with hacks at this point to grow faster. And the last phase is when you're mature; you want to make things good. And what I've seen at the likes of Uber, again pre-AI, is when you find product-market fit, you have a bunch of customers, you have a bunch of demand, you will now have enough revenue and money that you can hire people who can help you fix these hacks.
So I wonder if it's the same with AI. Maybe we're overthinking it: if you're in the early stages, you're just doing a prototype, just go all in. Don't worry about the code quality, which might hurt you. If you're at a stage where you're now scaling up, pay more attention. And if you're at a stage where it's a mature product, it's actually making money, we don't want to mess it up. I'm looking at Instagram's product, for example, which is a mature one, but Meta still messed it up. That is probably where you want to be very careful, pay attention, understand it. Oh, and the final thing is, AI doesn't only let us build faster. It allows us to refactor faster. So we have no excuse not to do that every now and then.
Yeah, I completely agree. I think it's basically a false dichotomy that it can be only speed or quality. It's more about segmenting in time or in the codebase, right? So infrastructure, maybe more attention to quality; product, maybe more attention to speed.
There have been repeated shifts in AI tooling and best practices. AI makes it easier to find exploits and create them. An AI jungle. What would it take for the industry to seriously create standards rather than hoping they emerge?
Yeah, first, AI is so new, it keeps changing. I think any standards would make no sense, and I think standards just naturally emerge. I haven't seen any patterns to it. MCP: Anthropic, when they were still a small lab, not a leading lab, very small, created this thing called MCP, and everyone thought it kind of makes sense, and it comes from a non-threatening place. It's a small lab which we don't really know. They're kind of cool, but they're not, Google was bigger, OpenAI was bigger, and then all these large companies adopted it, 'cause there was a lot of politics in it. So I think it's accidental. If Anthropic today tried to do an MCP, people would be like, no, we don't want to be locked in. So I think they'll just emerge. I'm sorry, I don't see anything planned happening here.
Companies like Anthropic have engineering managers coding a lot, and at Meta, and I presume at Uber as well, the philosophy was actually the other way around, that EMs should mostly focus on people. What's the right approach for engineering managers in the AI era?
I mean, this is a philosophical question, and people have strong opinions about that. For example, we know from when Elon Musk took over Twitter and then renamed it to X, he fired a bunch of people and he mandated that engineering managers should code while having 20-plus reports, which sounded pretty insane, to do both. I'm not sure there's a right or wrong model. I've seen all sorts of models work out there; there are pros to both. When an engineering manager does not code, they will care far more about people. They will pay more attention to what is frustrating people at the personal level, at the organization level, and they will try to fix those systems and they'll try to take really good care of people. Engineering managers who code, they will be more in the details. They will be able to give more technical guidance. They will have better technical discussions, and they will care a lot less about this first category of things. And they also probably will not have bandwidth to make systems-level changes or go to meetings to, for example, work with HR to actually change some policy that makes no sense and upsets a few people, or work with a bunch of other teams to have this
new system instead of everyone just duplicating the work. So right now the industry is definitely going very strong in a direction that managers should be technical. Let's forget about this people management stuff. So I think people need to unfortunately expect less guidance and support from managers. Managers who love doing this part and are very good at the people part will feel probably underappreciated for a while.
And I think there's a pendulum. I think it'll swing back and I think we've been at the side where we have been very focused on people and has been very rewarded as a manager and it was great to be an engineer at companies like this. It's now going back where it will be less so and I wonder if it'll come back again.
At some large companies that you reported on, not using AI aggressively is a career risk. How should leaders prevent adoption from becoming a theater? Token leaderboards, mandatory usage, code volume targets rather than real outcomes.
So I wonder if this is almost over because there was a part where I talked with CTOs and engineering leaders at all sorts of companies and they were really frustrated saying, "Oh, my engineers are not using AI." But this was before Opus 4.5. This was mostly before Opus 4.5 and GPT 5.4 and before Claude Code was used by many people. This was at the age of autocomplete with, you know, GPT-4o or even worse models, and like, our engineers aren't using it, or when Cursor was just the tab, you know, they have the golden tab key.
I think this is almost like a non-issue. Everyone in most places I know uses it, and also that's when token leaderboards made a lot of sense. Shopify had token leaderboards in that era. No one knows about them, but they did it back then and now they kind of deprecated it. So I think it's kind of a moot point, especially with these strong models. I assume everyone will use it and I think it's almost meaningless to look at it, a bit like lines of code made no real sense to look at for most engineers.
What evidence would persuade you that an organization achieved an actual AI productivity gain rather than just more code, more PRs or more humans to review?
It's a good one. Right before I entered, just taking a step back, when I worked at Uber it was the first company where I joined where people told me, don't worry about the revenue, we just care about growth. As long as we grow we're good. We just raise more money and then we hire more people and then we grow faster and we raise more money and we hire more people.
And I remember my manager was telling me about headcount when I became manager. I was like, how does headcount allocation work? Do you need to make a business plan or something? It's like, oh no no no, it's kind of a black box here. It's this weird thing where you get a headcount allocation and if you fill it quickly you get some more. And I was like, how does that work? And turns out that because in Amsterdam at the time we could hire quickly, the headcounts were reset at the end of the year and if you didn't use it they reallocated within the org. It was a really weird time and it felt off to me.
I'm like, surely if I hire a person and they cost X, they should generate at least as much value, right? But they're like, no, not right now, we don't live in an age like that, this is different. I always felt it wrong. And so there were opportunities where I could have worked on a team or led a team which was a purely platform team with no direct business value, and I was unsure. It was a cool technology. There was a team who was building something similar to React Native just internally because React Native did not fit our needs, and I was like, I'm not sure I see the business use case.
So I always stayed on teams where I was very comfortable that we are actually making money. I knew how we were making money. And I always had this in my mind that if someone asked what would you do if you hired two more people, I would have an answer: here's how much more revenue we would generate. And if someone asked what would happen if I took away two of your people or half your team or your whole team, I'd be like, no problem. Here is the business impact. Here's how much revenue we would make.
And so when it comes to AI productivity, can we really distinguish it from business productivity? I mean, there's only two ways that a business revenue-wise can make a difference. And this is just a very capitalist way of thinking about things, of course. But one is either you make incremental revenue, meaning money that you would have not made before. If you would have made that money before, it doesn't matter. Like if you're a crypto exchange and, oh, we're making more money because there's more crypto volume. Well, that's not AI, is it? It's the market. But if we launch this new product and it's now making money that we didn't make and AI is helping with that, that's I guess value for AI. Or cost savings.
And I wonder if AI's biggest use case is just cost savings, which is kind of depressing to me. But the AI-native companies that are making money, I do see the ones which are selling an AI product. You know, the AI labs are obvious ones. There are startups, let's say AI incident review, who are making money because of that product. So I think that's a use case. But otherwise it's pretty iffy, pretty finicky.
And I still have this private thought of, will AI be a bit more like cloud, in the sense that cloud is everywhere now, including in banks that said we will never go on cloud and now they're in AWS. But as a customer no one cares if you have cloud or not. It used to be a cost saver, a more flexible way to control cost, and I think AI maybe is a more flexible way to control your own cost or how people do work. It's a weird thing, but to me it feels closer to cloud than a technology like mobile, which created a whole new market of everything.
What is a popular current belief about AI and engineering that you think is incorrect?
I think it's incorrect to think that it just makes things easier. If you're using AI and your life is getting a lot easier, are you trying hard enough or are you just delegating stuff? Because to me, I use some of it for my business and it actually makes me think just as hard, if not harder. Work is harder. So I think believing that AI makes work easier, our jobs easier, is just wrong.
How important are degree and university prestige in hiring today? Is computer science becoming a prestige field like law or architecture, leading to fewer self-taught professionals?
Unfortunately, I believe it is. And this is less to do with the degree and what they're teaching, but more about the market. There was a time around 2015 to 2020 where you could get hired at a company for a well-paying job by doing a boot camp, which is like three months to 6 months, sometimes 12 months, versus a four-year or five-year degree in computer science. And the reason was there was just a huge shortage. All of the people graduating from university were snapped up.
That has ended. The majority of companies do not hire from boot camps. Very few, in pockets, maybe in the UK or elsewhere, do apprenticeships, but they're very small. And the top universities are still getting those graduates hunted down, at the likes of MIT, Caltech, Harvard, many others, Waterloo in Canada, Imperial College in the UK and so on. But they're not getting as many competing offers as before, and even at the mid-level of schools, it's just harder.
So when it was hard to hire someone with a computer science degree, people went for self-taught and those things. But now they do it less. I even had someone tell me who is self-taught, worked in the industry for 5 years, lost their job about a year and a half ago, that for a year she couldn't find a position even though she was doing SRE work and infrastructure work. And I think in the end she said that she's either considering changing fields or just doing her own thing. And that's the other thing, I think it's easier than ever to do your own thing, but companies I think will be more picky.
And the value of the degree, it's a bit underrated. If you're living in your current country and you don't plan to leave, it might matter a bit less. But first of all, large employers often have this requirement just for filtering. Saying we need a degree just filters out a bunch of non-qualified people. Saying we need a computer science degree just filters out the art majors, and they don't have to look through as many resumes because they already have too many even with this one thing.
But a degree is very important for visas. If you're, for example, in a country and you'd like to move to another country, typically more towards the west, without a degree it will be very difficult with the immigration system. So that's something that's worth keeping in mind. That thing can pay dividends even decades later when you're not thinking too much about it.
So a few questions about yourself now. Do you still spend time programming yourself or testing large language models? And if so, what percentage of the time?
I spend most of my time researching and writing, but increasingly now for my business, The Pragmatic Engineer, I have a backend that manages group subscriptions, some customer support functionality that I'm building. I'm building it myself. And now I might have some folks help me on my team as well. But when I could get a SaaS now, I'm like, I don't want to get a SaaS, I just want to build it myself.
So it's simpler stuff, honestly. It's like a CRUD database that runs on infrastructure like Render. I use the tools. I use Codex. I really like Codex and GPT-5.5. I also use Claude Code as well. I play with Cursor. I sometimes try Factory. So I try to rotate these tools and it just makes it so much easier for me to get back into it, but I don't spend most of my time on it.
And in your own workflow as a creator, writing, podcasting, researching, have you seen productivity gains from AI?
So this is the interesting thing where I think I should have. So I don't use any AI for my own writing. I did a few of these experiments more for curiosity, saying, "Hey, here's some notes. Generate an article in the voice and tone of The Pragmatic Engineer." First of all, it isn't doing a good job on it. I don't think it sounds like me. Second of all, it just has those, I don't know, it just feels artificial, like the links.
And then most importantly, I really enjoy, like I love writing. It's not the thing of writing, it's the thinking. When I write I keep thinking, and a lot of times on social media when I post something and it gets a bunch of likes or views, it's often that I'm just writing and I have this idea when I'm revisiting, you know, this topic for the third time, and I'm like, that's an interesting idea. So I just post that idea out there and I just go back to writing, and then later I see people respond to it, because I guess what people see is just an original idea.
Most of my social media is a byproduct of writing and researching. Most people don't know this. There are so many people who are optimizing social media for likes or all of this, but for myself and a bunch of people that I know and respect, it's kind of like their side thing.
One good example: I read someone on Hacker News wrote about this, that their favorite YouTube creators in photography, this person was a hobby photographist, their favorite photography creators are not professional YouTube creators about photography. They're photographers who have a business and they actually do shoots, and then they have a YouTube channel where they share every now and then. It's infrequent.
And I also think of myself as, my main thing is I research what's happening in the tech industry. I talk with engineers. I try to keep an ear on the ground as much as I can, and I do this by just being in touch with a bunch of software engineering folks I know, some friends, and when I see interesting things I dig into it. You know, that's for example how I noticed that something was really off at Meta. I've only ever sensed things being slightly off at Meta for a long time, but now I have 10 or 15 people who I've known there for years, and now most of them were sounding the alarm bell. I'm like, that's new. I haven't heard that before. And you know, turns out I was right about just how bad things have gotten there.
But in my workflow, I use it for research when I'm like, here's a topic, all right, I'm going to research Ramp's engineering culture. All right, deep research on all the platforms, give me all the stuff. And I would have thought that this would have freed up time, and I guess it frees up some of that time, but I would have never spent that much time researching. So I don't feel that I'm working less, interestingly enough.
And what capability do you worry AI might weaken in you personally? For example, coding fluency or technical recall or writing from a blank page.
I don't think the writing will suffer because I just don't use it there. I don't even have spell checks on. I just don't like it, and I turn Grammarly off as well because I hate when it wants to reorganize it. I think whenever you over-rely on something it could make you less efficient. For example, one thing I now over-rely on is just deep research. I want to find all the things on the web. So my ability to find things on the web might be worse, but I'm not too worried about that because first of all, it was just drudgery. Second of all, I don't really trust the internet that much. Like in deep research, I still check where it gets references from. When it's too much Reddit, I'm like, [laughter] I'm not sure this is going to be 100% checked out.
But with coding, I now just prompt and write the code, and my ability to write code by hand will probably be degrading, but I don't personally mind that part all that much. So I think it goes back to, look, whenever you're using AI for a bunch of stuff, just know that that skill will go down, and are you okay with that? And I'm kind of okay with it.
Has AI ever tempted you to go back to building software?
It's now so much easier to build software. It probably would have tempted me, but right now I just love what I do and I actually love the human connection of actually talking to people and getting a window into what other people are doing. But it is making me build more software and be more ambitious. So there's this project that I've been putting off for a while, which is a self-service signup flow for companies for The Pragmatic Engineer, so the whole company domain, and I'm actually just building it because it's so much easier to get started with. It's less intimidating.
Vladimir is a QA engineer in banking, early thirties, and he's worried about staying relevant. So he's tempted to quit for a full CS education, but it's quite scary to give up a good paycheck. He feels stretched. How should he think about future-proofing his options?
What I see in terms of future-proofing is the single best way to future-proof it is to work at a company which is doing stuff that is very relevant. You know, this is building products, building modern products, building products that incorporate some level of AI where it's okay to experiment. Banking, where it's a rigid place, might be the opposite. But my first advice would be, inside a company, can you start a project where you are just doing some experiments with AI? This
is why Google is such a great place right now. I know it might not be too popular to say, but they encourage doing this, like, oh, you're on your team, you're building a product, cool, and you have a suggestion to build this new experiment with AI, yeah, go ahead and do it.
And I have a feeling that a lot of companies will be receptive to this, because right now every leader thinks we should use AI more, and if someone comes and says, I have an idea and I'll do it part-time, it's a win-win. Worst case is, you know, you learned about RAG or you learned how to implement this thing. It can be an internal tool, and that's why there's an explosion even at larger companies like Uber with internal AI tools. Just start doing that. I think that's the best way to stay relevant.
Because if you take a computer science degree or do it full-time, it could be behind the industry right now. Also, you can do a degree part-time, but because it's such a big technology shift, the best way is to be hands-on. So my advice would be try to do that as part of your job, that's the easiest. Everything else is harder. Leaving for a new place, interviewing for a new place, all harder.
Of course, you can try to do side projects, but I find that unless it's something that truly motivates you, like unless you have this thing that you really want to build, like this health app that you really want and it doesn't exist, then do it. But other than that, it could be easier to do it at work. My two cents.
How can you surround yourself with highly motivated top-notch programmers when your classmates aren't at that level and it feels like too much to catch up to?
I mean, if your classmates are not that motivated and you are, try to find a different group of friends. Well, it depends on where. If it's high school, then you're stuck with them. Even when I was at high school, there were only two of us who were coding, and luckily there was another person. Maybe you can find someone from a different class, maybe in an online community.
I've heard Alis real on my podcast: when she was in high school she joined online communities and she actually started to contribute to some software there. So that's one way.
If this would be at work, try to either change teams internally if you can, or outside of your project, take projects where you can work with other people. Seek out and try to follow those people or get towards them, because a lot of people will be motivated.
And also, this is the thing where when you're in that situation you can change companies. It makes a difference. When I worked in banking, one of my first jobs, my colleagues were super nice, they were such nice people, but they were not in love with technology. None of them were. And then when I moved to Skype, everyone was, and it was just such a big difference.
So Akos is saying that his son is heading for an IT-focused high school, dreaming of becoming a game developer. What does the path and the job market look like in 5 years from now? And what should he do to prepare himself?
Everyone's asking this question, right? If only we knew. I personally try to draw parallels from other industries, because we don't know what's going to happen exactly with AI. You know, with this tool, we know that coding is so much easier. It will probably make some of the other parts of the jobs easier.
But I like to think of a parallel, for example construction, where if you wanted to build a house today, or at least renovate your house significantly, you could walk into the DIY store or you can go online and you can order a bunch of equipment, including professional equipment. You can get the same equipment as professionals. On YouTube you have professionals making videos of how to build a wall, renovate a wall, tear down a wall. You could do all of that. You have the information and you have the tools and you have the materials. You can buy the top-notch materials. It just takes a bit of work.
So why do people in construction have a job? Well, I guess most people don't want to do all that and they'd rather hire a professional. So I think what will happen in the tech industry is exactly this. And of course fewer people are calling out an electrician to change a light bulb, or even some of the more advanced work; a lot of people are using YouTube, and DIY shops are probably getting way more business. But I think there will be professionals. So if you want to be a professional in a field, there will be a path to that, and to get into that it will go through universities' education.
I'm fairly certain that the game that will be released in 10 years, which Akos's son will hopefully be working on, will be built by a studio that's either a startup or a AAA studio, and if it's a AAA studio they will hire graduates from some of the top universities, from people who have been building games on the side.
And for Akos's son specifically, I have an episode with Jonas Tyroller, who builds games, and one of his games got a million sales with two of them building it. I would suggest watching that episode. But also Jonas shared a video of all the games he built over like 10 or 15 or 20 years, and he has been building games on the side. So if his son wants to become a game developer, just encourage him to start building games on the side right now.
In this hard market, what do you recommend for engineers in the EU? Keep aiming for tier one companies or stick with a tier two job?
Yeah. So this is the trimodal structure. I have tier one, I put it as the local companies, like the local supermarkets, the ones that are really competing for local talent. Tier two is regional, and tier three is global. That's the big tech.
And in this job market, well, first of all, when the job market is really volatile and uncertain, staying put can be a good strategy. At the same point, I would not stop looking for opportunities, because on one end, the job market feels a bit different than in 2023. 2023 was a brutal market. It was layoffs everywhere and no one was hiring. Right now there are some layoffs, but so many companies are hiring.
So now could be a great opportunity to jump a tier up, to a startup, to building products, to having more autonomy, to using more of these AI tools. And if you stick at a company that is just really moving slowly, you might not have that opportunity. I talked about the engineers who are really in demand. They have a few years of hands-on experience with these tools. They will be in demand in a few years' time as well. And if you will still have zero years of that, well, you're kind of sitting in one place.
So I would be opportunistic in looking out, maybe looking at job openings, talking with your network, not fully ignoring recruiters, seeing what's out there. Look, if you get a job offer, you can always say no. If you have no job offers, you're going to stay at your current place probably anyway.
How can engineers and students use AI to learn and explore new technologies and concepts better?
I think you can use deep research a lot better. You can ask it to explain stuff. But the way I see it, AI only ever helped me learn about stuff when I wanted to learn about something. So start with what you want to learn. It's a tool. It'll help you, but I also wouldn't fully throw away things like books, other resources, maybe videos, tutorials, and also just building your own thing. That's what I mean, the biggest miscon...
It's not going to make it easier to learn, especially when you're not motivated. So decide what you want to learn, and yeah, it can help you, but just learn it. In that case you have one fewer excuse when you want to do it, and if you don't want to do it, just don't do it.
So not IRS is asking a question, so I guess it's very safe to share all the information. How much do you earn from this, and why start this instead of the tech job?
The last time I shared specific numbers was, I think, in the first year of the publication, where I shared that I had like 2,700 paying customers, and it's gone a lot beyond that. It's now more than 10,000 paying customers of the newsletter. I also now have some sponsors on the podcast.
And the reason I don't like to talk about the specific money, you know, there are people who say here's exactly how much I make, is every time I do that, I get so many questions coming in from people like, "Oh, I also want to make this much. Can you advise me? Can you have a call with me? Can you coach me? Can you mentor me? I want to quit my job. I want to do this thing." And first of all, I'm very grateful, it's an amazing business, but it's just not what I'm good at. I don't want to give financial advice to people. And I didn't even think this was possible.
But to actually not be that vague: when I left Uber, my compensation was going down a little bit because of the four-year vesting. But in my best year at Uber in the Netherlands, I think it was something like €288,000. Back then it was like $320,000 or $330,000 or something like that. And 120 of that was base salary. I think it was a 26 or 27k bonus, or maybe 30k bonus. It was a big cash bonus, and the rest was in equity.
And when I started this, I didn't think it would go too far. I thought I'd give it a shot. Most of why I didn't think it would go so far was just being realistic. Lenny shared his numbers of 2,000 paid subscribers, and you do the math, it's $300,000 roughly, give or take. And he was going up. And I thought, well, maybe I could get there? Maybe yes, maybe no. But we'll see when we get there.
But in the first week of starting the publication, I had 100 paying customers, which was $10,000. So that's paid up front, which is very nice. In 6 weeks, I got to 1,000 paying subscribers. It was still $100 before I raised, and I started to raise the prices back then, but it was around $100,000. And then I kept going up, and I started to be on a higher annual run rate in about, I think, four or five months than my old Uber best total compensation. And it was still going up, and I was like, "Okay, what's going on?"
So I just kind of stopped looking at or thinking too much about the money or these things. I started to focus on just writing that one really good article. I did this for a year and a half, two years actually. And then I looked up and I was like, well, I actually really love doing this. I didn't know that you could make more than working at big tech by doing this thing, your own business.
And this is also something that you can realize: with your own business, you have the potential to make more. And also, you know, one of the reasons you probably left Meta as well, where you were probably very highly paid, is you have the opportunity with a startup, with your own business. I'm very lucky that this has happened.
But also, one thing: I love my days. I find it very exciting every day, what I'm doing, and that is what keeps me doing this. And honestly, I just love being in charge. Right now I'm sitting here because I'd like to sit here and I'm having a great time with you, but if I didn't want to, I didn't have to do this. And I do well when I create my own structure.
But it really helped me. I don't think I could have done any of this without going through those 15-ish years as a developer. I always tried to do the best work that I could. I had a lot of structure. I made a lot of connections who actually helped so much with this business. A lot of times my guests are people that I know, or I reach out to them for advice.
So luckily, I feel almost like, wow, was this possible? I didn't think this was possible, but now I'm just kind of rolling with it and I'm like, yeah, it's great. I love it. I enjoy it. I'm also not too attached to it, in the sense that, look, if the business wouldn't do that well, or people for some reason stop being interested, well, I can live with it, as long as I help some people, I give value to some people.
And also, this is an interesting thing: I could make more revenue by juicing it more. I could put more things behind the paywall. I've gotten feedback from people saying, "Why did you put so much of this outside of the paywall?" And whenever I think something is important and more people should get access to it, I try to not put it behind the paywall, even if it hurts the business, because again, it's kind of nice to be able to do that.
What's next, Gergely? Any expansion plans for The Pragmatic Engineer?
Yes. So the interesting thing is, if this was a VC-funded company and I took VC funding, I would have to expand. But I don't. The only plan I have is I would like to make The Pragmatic Summit more regular. There was one in February in San Francisco. There will be one in the beginning of the year, also in San Francisco, and I'd like to get to a point where I can have one in Europe as well. And I'd like to be able to do this on a more regular basis.
So ideally my dream, but this is more down to logistics and energy and some of those things, is to have one Pragmatic Summit in the US and one in Europe, in London or somewhere else. Getting to that point I will be very happy.
And also, I'm growing my team very slowly. We now have a small team. So I'm just figuring out ways that I can have folks involved and help with even more ambitious research. I'd love to go even deeper. I have so many ideas of companies to research, industries to research, sometimes some boring industries. At some point, I'd love to go into a utilities company and go through how they build software. It sounds pretty boring, but it's pretty darn important.
Have you ever gotten in trouble over an article? Has anyone tried to sue you?
Yes, once. Two articles actually. One I never published, because I decided not to publish. This was at the beginning of the publication. For some reason, I really got upset at the neobank bunq in the Netherlands, because I read about their hiring practices. They do an intelligence test, a Rorschach test, before doing a technical interview. And I thought that's kind of messed up.
And I tweeted about this, and a bunch of people who were unhappy at the company wrote to me like, "Oh, here's some juicy stories about how terrible this company is, and here's all the things that they do," and they had evidence and all that. And some of it was like, "Whoa, wow. This is crazy."
And so I started to write an article about that. This was in the first year of The Pragmatic Engineer. I started in August and this was in December. And I had an article ready that was pretty damning. It probably read like a hit piece. I didn't have any agenda, but it was just negative, negative, negative, and can you imagine this and that. I was about to publish it. I even sent it over to the company, to bunq, because my editor was like, you should probably send this over to them.
But then I slept on it and I was thinking, what am I going to achieve with this? At the company, inside bunq, I'm not helping anyone, because they'll be defensive, and it's actually a business, it employs people and it's growing and it's employing more and more people. And then I also got a message from someone who said that they had a bad experience there, but it was also very helpful, because this person came from, I think, Egypt, and no
company would hire him in a visa in the Netherlands, but Bunq did, and they were pushing him really hard and some things felt unfair, but it was a stepping stone, and that person now works at Facebook and said it could have never happened without Bunq, and they took a chance on me. And I was thinking, well, I'm not going to help the company. The article has zero positives. It just says don't do this, don't do that. And also, despite this, they actually have a business. And I was like, I'm probably missing something here.
And I decided to not publish it, because that's when I decided I want to publish things where I actually share things that work, and I wasn't sharing any of the things that made Bunq work. And actually they're now an even more successful company. And I think this is the thing: every company has its ups and downs. So that was a thing that I did not publish, and I didn't get in trouble for that. A bunch of journalists reached out to me later to get all the juicy details because they wanted to read it, but I just deleted the whole thing.
The thing that I almost got in trouble for, and I was really stressed about, is the deep dive on Pollen. Pollen, the events company, who really pissed me off, because I was just covering layoffs across the industry. I mentioned Pollen was one of the many who did layoffs, and I knew people there who left Twitter and Deliveroo and some good companies to work at Pollen because it was a good company, good salary, flexible perks. And I just briefly mentioned them in my article saying they did layoffs, it was poorly handled.
On an all-hands, someone brought up, saying, the Pragmatic Engineer, I was the only one who mentioned it, the Pragmatic Engineer mentioned that we did layoffs and it was poorly handled. What do you think of it as a CEO? And the CEO said, ah, this is not like the BBC or Panorama, it's some small publication, they have an agenda against us, don't worry about it, it's incorrect anyway. And they shared this back with me and I was like, what?
And so the company did not pay employees, they lied to them, they canceled health insurance. It was lots of lies and unpaid salaries, and I just decided, this thing was me, like the guy said, I'm not a Panorama. So I did a proper investigative article where I collected a lot of stuff on how it went wrong, including a double charging of a payment that was a deliberate double charge, disguised as an outage. There's now reporting out about it from the BBC. I might or might not have helped with some of that reporting for the BBC.
I couldn't put it in my article, because when I sent it over to Pollen, they said that this is libelous, this is libelous, this is libelous, meaning they could sue me. And I had to think about, do I really want to do that? So I actually self-censored, and I put so much effort into the article, so much stress, and I realized that investigative journalism is just not for me. And it's a good read. The BBC later made a documentary. I also helped them with that, but I realized this world is not for me.
Other than the book and newsletter, what's something surprising you have found through your writing?
I usually just find ideas as they go, because they fester. I also have a long list of things that I collect. I'm not sure if I have any specific things. Trends sometimes pop out a bit more as I'm seeing multiple people talk about them at the same time. And sometimes it just reinforces the things that I'm kind of thinking could happen.
In January, when I started using Claude Code over the Christmas break a lot more, I was really impressed with it, and I was like, "Wow, this is really..." but is it just me? And I started to read around and I did some research, and I saw a lot of people saying the same thing, and that actually encouraged me to write the article saying I think coding by hand is over. And this was very early on, and I actually got some flak for it from some people: how can you say this? You're an AI shill. But I felt this is where it's going based on my experience, and then I got a bunch of evidence and I talked with a few more people. So it either reinforces some opinions I have, or it also gives me new ideas.
Do you plan a new edition of the guidebook updated for the AI era, and what would you change to better reflect the LLM era?
Right now this book stayed surprisingly durable for AI, because it didn't contain too much about coding to start with. But the non-technical parts, things like understand the business, think about software architecture, those are more relevant. But at the lower levels, at some point it'll probably be updated. I think I want to wait until we figure out what are practices that actually work, when we'll have so-called best practices for certain companies. I think it'll take a while, but I'll probably revisit it at that point.
What's your favorite technical book?
So I'll give you two. One is A Philosophy of Software Design. I just love this book. It's still to this day the only book that actually compares architecture approaches between groups of students and what we can learn from that. I wonder with AI if we could now replicate this, have agents build different software, but it still wouldn't be the same. But it's just a really nicely written book. I really like the idea of modules, shallow modules, deep modules, and so on.
And then I also enjoyed Kent Beck's Tidy First book. It's a really thin book, but I just like how crisp every single idea is. Even though that book might be a bit less relevant when you're writing a bit less code, I just like the thinking that's behind it.
Besides Craft, what are some of your favorite software tech products?
I really like Granola for meetings. It not only takes notes, it fills out your notes, and it's just such a delightful example of what an AI-added product could be. I'm happy to pay for that because I get more value, and it's easier note-taking, fewer issues with it, not having to think about that. I wish actually that I could see more products that are like that.
And I also still really enjoy Perplexity's search functionality, especially the deep research. Every product has rolled out deep research, but Perplexity is still the one that seems to be the fastest. I wish it was what Google would do for search. And again, it's something that I pay for and I have no affiliation with it, and this is specifically search. I don't like their new push for Computer or any of that stuff. But again, from the beginning, I feel there are some things where AI can really add just a new experience, where I'm like, oh, I didn't know this could exist.
Forget what changes. What's one thing about software engineering that you bet will be the same in 5 years?
I think there will be a big demand, I hope a bigger demand, for professionals who care about the craft and who are true professionals, in the sense that you know where the industry is at. You know what the tools are. You've used them, you use most of them. You know what their trade-offs are. You have no ego, and you just choose the right one for the right job. And right now, today, this will involve: okay, what kind of tool do I use to write code with? How do I test it? How do I deploy it? How do I verify the correctness of the system?
And as a professional, you care about the things that the average person would not. If I'm a building architect, I'm not one, but I would imagine that when I look at a building, I see all the things that as a pedestrian I don't really care about. I'm like, "Oh, it's beautiful glass windows." And the architect is probably thinking, "How does it hold up? What kind of characteristics? What about earthquakes? What about this? What about that?"
And I think that having us software professionals who can look at software that way, work with it and change it, be unafraid of changing it with high confidence because we have the tool set, the tools. Again, with buildings, sometimes you put up scaffolding to make some changes, sometimes you don't need to, you just do a quick job. I think that will be a lot more in demand, and I hope that we'll have more people who care about this, and AI is not going to scare them away. Or maybe AI just scares away the people who never really cared about the software. They just always cared about making a quick buck, and it was never about the industry.
Yeah. So these are all the questions. Thanks, Gergely, for the very interesting conversations. Really appreciate it.
Thank you. It's a bit weird to sit here, because usually that's my line that you just said, but Giggs, this was awesome. Thanks so much.
Thank you.
And thanks to everyone, of course, who submitted questions. Well, this was a different format. And finally, it was nice to not be the one asking the questions for once. Leave a comment to let me know how you liked this one. Thanks, and see you in the next one, where we're going to return to the usual setup.
Article published