Gergely Orosz's Recent LinkedIn Posts

What. A. Day. The first-ever Pragmatic Summit was next-level. Thank you to the 500 exceptional attendees, 20 awesome roundtable hosts, the 17 out-of-this-world speakers, and the incredible Statsig organizing team: Four years of The Pragmatic Engineer built up to this special day: Special shoutout to Morgan Scalzo + Ian Ito for driving, Jessie Ong + Christie C. for ridiculously good design + videos, Margaret-Ann Seger, Talia Morris, Sami Springman, Skye Scofield and the many other folks at Statsig for the incredible work to make this the single best one-day event of the year. It takes a village!! A brief recap - more to come later!

Outside of the bubble of people who are forward-looking around the capabilities of new technology (eg LLMs) I see a LOT of crab mentality. Where the few people using tech to work better/more innovative/faster are being told by their peers to stop it/it won't work etc. AI is a technology that changes most existing assumptions. This means that those with "no priors" (no previous assumptions) are at a massive advantage of doing work more efficient / more of it / innovate more, than those that keep working exactly how they used to be. But change can feel threatening to anyone and everyone who has been doing great in the "old" world. So the most obvious response is to try to "pull back" anyone on the team using these new tools - to the point of threatening the status quo. This is why a lot of the "crab mentality" is hapening. Just be aware: especially if it is you that is being pulled down. Don't let yourself: show them and the world instead what you can do; how this thing works, and learn how to use LLM tools to do more efficient/innovative/meaningful work. And if you find yourself playing the role of the crab: a much better strategy is to swim up with the folks changing their workflow. Else you will be akin to the old man yelling to everyone in 2008 how the cloud cannot possibly work, even if it did it would be dangerous to use, everyone keep using your on-prem hardware and go to the sysadmin if you want to deploy.

9 interesting observations from my conversation with Mitchell Hashimoto (creator of Ghostty, founder of HashiCorp): 1. Vargant was created because dev environment setup was an unbillable time sink at a consultancy. At the Ruby on Rails shop where Mitchell worked, jumping onto another client’s project could waste half a day. This inspired building Vargant. 2. Terraform won, despite being 7th to market. Terraform won through relentless conference presence, community building, and a better developer experience — not timing. 3. HashiCorp had no real business for four years and their first commercial product was a full-on failure. The initial product, Atlas, required customers to adopt the entire HashiCorp stack. It was a hard sell. HashiCorp pivoted to selling individual services like Vault, and this approach proved to be a winner. 4. VMware almost bought HashiCorp for ~$100M, and Terraform would have not happened if it did. VMWare took took the offer to their board, where they rejected to buy with a single vote. Mitchell said that Terraform probably never would’ve existed if the VMWare purchase went through. 5. Mitchell’s new rule for building software: always have an agent running in the background doing something. He kicks off tasks before leaving the house — research, edge-case analysis, library comparisons — so work progresses while he drives or is away. 6. Open source is moving from “default trust” to “default deny” — and Mitchell thinks that’s how it should be. This is because AI makes it trivial to create plausible-looking but incorrect and low-quality contributions. As he put it: “open source has always been a system of trust. Before, we’ve had default trust. Now it’s just default deny.” 7. Git and GitHub may not survive the agentic era in their current form. Agents cause so much churn that merge queues become untenable, branches proliferate, and repos balloon. Mitchell compares the needed shift to Gmail’s revolution for email: “We’re at the Gmail moment for version control... never delete, archive everything.” 8. The best engineers Mitchell ever hired had boring, invisible backgrounds. No GitHub contributions, no public profiles, companies you’ve never heard of. “Every moment you spend on social media is taking away from something else... the best engineers are the ones that context-switch the least.” 9. Mitchell’s advice for AI-skeptical engineers: start by reproducing your research, not your code. As he puts it: “There’s a lot of people like, ‘I don’t want it to write code for me.’ But just delegate some of the research part.” He uses agents for library comparisons, edge-case analysis, and deep research — not just code generation. “You don’t need to pick up on the ‘it must replace you as a person’ kind of propaganda.” Watch the full episode here: https://lnkd.in/ecdgWKbY Other platforms and transcript: https://lnkd.in/drgXiipV

The first recording from The Pragmatic Summit is available to watch for anyone: How AI is Reshaping the Craft of Building Software. With Thibault Sottiaux (Head of Engineering, Codex, OpenAI) and Vijaye Raji(CTO of Applications, OpenAI) A very good one. Watch it here: https://lnkd.in/ejQmNenh

This was amazing. Nhat looked at me on the street and said: "hang on, you should be in Amsterdam, no?" Peak SF - and also love Hayes Valley!

This is "Code Inbox" at Uber: new tool all devs have to reduce the noise from code reviews, including for AI-generated code. It's one of ~a dozen recently built systems related to AI agents. At The Pragmatic Summit, principal engineer Ty Smith, and director of engineering Anshuman Chadha pulled back the curtain on what new systems Uber built to roll out AI tools for all devs (and more non-devs). New, internal systems include MCP Gateway, Uber Agent Builder, AIFX CLI, Minion, uReview, Sheperd, and more. Read more about these tools, why they built them at Uber, and how they work: in today's The Pragmatic Engineer deepdive: https://lnkd.in/gqjfjrgX Or watch the talk from Ty and Anshu: https://lnkd.in/gRMFEXi4

The chatter about generating code with AI tools feels stuck at the "basic" level of... well, codegen, plus (perhaps) reviews and testing. I hear close to little talk about the things that come right after generating code: deploying, canarying, o11y, SLOs, error budgets etc My point is that it feels we're still very early in how we use these tools: we use it for the most common and widespread place of codegen (where they are admittedly a fit in their capabilities.) But we don't seem to talk all that much on how it impacts shipping + operating production software. I suspect that this is because you need to walk before you can run: there's enough issues still today with code generation (smaller and larger things) that few have had the energy to look further than this stage. But there's so many more things that need to happen to ship quality and robust software, beyond the first step of writing the code!

Steve Yegge believes coding by hand will gradually disappear, grudgingly acknowledges that software engineers no longer need to understand Assembly (and is unhappy about this), and says most devs should NOT use his agent orchestrator, Gas Town. I always enjoy Steve's energy and him thinking two steps ahead: this conversation was no different. Watch or listen: • YouTube: https://lnkd.in/e4bDbPKp   • Spotify: https://lnkd.in/e7_j-4sd • Apple: https://lnkd.in/ec6w7je9 Brought to you by: • Statsig – ⁠ The unified platform for flags, analytics, experiments, and more. https://lnkd.in/eQkXqjMZ • Sonar – The makers of SonarQube, the industry standard for automated code review. https://lnkd.in/ekMzUJxY • WorkOS – Everything you need to make your app enterprise ready. https://workos.com/ Three interesting thoughts from Steve that we talked about in this conversation: 1. Reading ability is becoming a blocker for wider AI adoption. Some struggle with walls of text that current AI tools produce, and Steve predicts that in the very near future, most people will program by talking to a visual avatar, not reading terminal output because he observes that five paragraphs is already a lot to read for many devs. 2. What software engineers need to know keeps changing. In the 1990s, any decent software engineer knew Assembly, and today almost no decent developer knows it because Assembly has long been superseded by technical progress. What engineers “need” to know these days is different from the ‘90s and that process continues with AI, changing the parts of the craft that are essential for devs. We grumble about this but that won’t change anything by itself. 3. There’s a “Dracula Effect” where AI-augmented work drains engineers faster than traditional work. This is because AI automates the easy tasks, meaning that engineers are stuck doing high-intensity thinking all day. Steve says you may only get three daily productive hours at max speed, but during that time, you could produce 100x more output than before.

One of the best software engineers I worked with was on the job market: and their job search was completely different than almost all job searches: This engineer did not fire off a single job application or reply to any LinkedIn InMail or other message. Yet he secured three offers, thanks to former colleagues he worked with jumping to refer him with the warmest referrals possible. I posted about this person five months ago, and Oliver Frolovs asked if it would be possible to interview this engineer (thank you!) I asked, and he said yes, but with one condition: to keep his identity anonymous (he is not seeking employment, nor does he want fame or attention.) The interview is out in today's The Pragmatic Engineer. Here it is: https://lnkd.in/eqgZja72 Oh, and this is his actual, public GitHub profile. Don't judge a book by its cover!

If you'd like to get a hype-free take on what's happening with AI in the tech industry, The Pragmatic Summit keynote by Laura Tacho is a must-watch. Recorded two weeks ago, made public for everyone today. It got SO much love at the event, and people kept looking for Laura to talk to her about it: https://lnkd.in/eAfUyDfV

Exactly one year ago (10 mar 2025), Dario Amodei: "In 12 months, we may be in a world where AI is writing essentially all of the code." The full quote, as he said it at The Council of Foreign Relations "I think we will be there in 3-6 months, where AI is writing 90% of the code. And then, in 12 months, we may be in a world where AI is writing essentially all of the code." This turned out to be... surprisingly accurate, in some circles! Today, inside inside early-stage startups and AI labs, AI-generated code is 90%+ of the code written, and inside a few AI labs it's closer to 100% (on the Claude Code team, though not across all of Anthropic.) Here's first-hand details on how Codex writes ~90% of the code of Codex (from The Pragmatic Engineer deepdive on the team: https://lnkd.in/eq5npFVq - inside OpenAI this is closer to 70%) and how Claude Code writes 100% of Boris Cherny's code, and about 80% at Anthropic: https://lnkd.in/eA-pag5g In January, many experienced engineers concluded (as did I) that AI tools are good enough to write most of the code, looking ahead: https://lnkd.in/ebsWNCZm The one thing I do not know: how could have Dario predicted the step change with the Nov/Dec models (Opus 4.5 / GPT 5.2 and 5.3) that made this possible? Still, it's rare for me to see a prediction that looks impossible at the time it was made, and then turns out somewhat true - even if in smaller pockets - by the time it's predicted to hit. One important addition: software engineers are still happily employed today, even at places where AI churns out most of the code. Turns out writing code is just one part of the job, perhaps not even the most challenging one (especially not looking ahead)! And AI-generated code is causing more problems in many places: research previously shared by Laura Tacho highlighted how defect rate is up across the industry. And reliability of major AI vendors (that generate the most code with AI) is also disappointingly low. So there's plenty more work to do - and software engineers feel more in-demand to me than before!

Iconic moment at The Pragmatic Summit this week: GitHub's last CEO Thomas Dohmke (now founder of Entire), grilling Atlassian CTO Rajeev Rajan for not being agile enough, Rajeev grilling him right back for being too startup’y, and the room exploding with laughter It was such a lively, unscripted and spontaneous exchange: and a very good illustration of how authentic, spontaneous and real The Pragmatic Summit was. Video coming soon - first for conference attendees and The Pragmatic Engineer full subscribers, then to everyone! Thanks to Thomas and Rajeev for being awesome and being down to have some fun!

One last addition: Steve Huynh will also be on stage at The Pragmatic Summit. What a gang! Here are 8 of the 27 standout speakers for this one-day event. It's a pretty special one: almost all speakers have been guests on The Pragmatic Engineer podcast, or (guest) authors in the newsletter - but never at the same event, before. Until now! Thanks to everyone who took a chance on the event + booked before the agenda was final. The event is sold out - and has been for about two weeks - but we'll record talks, and they will go out to paid newsletter subscribers first, and everyone else later on. For those of you with tickets: see you on Wednesday, in SF! https://lnkd.in/eYTCCX5N

How was one of the most loved programming languages - Kotlin - created, and what is next after it? This is a rare and special conversation with Kotlin creator Andrey Breslav, with so many fascinating details on how Kotlin became the global success as it is today. Watch or listen: • YouTube: https://lnkd.in/eB_8ud4V • Spotify: https://lnkd.in/eauJyuUh • Apple: https://lnkd.in/eEhacfpE Brought to you by: • Statsig — ⁠ The unified platform for flags, analytics, experiments, and more. https://lnkd.in/eQkXqjMZ • Sonar – The makers of SonarQube, the industry standard for automated code review. Join me online at the Sonar Summit on March 3rd: https://lnkd.in/eD3nmzGF • WorkOS – Everything you need to make your app enterprise ready. https://workos.com/ Three things you probably did not know about Kotlin: 1. Kotlin’s first version was not a compiler: it was an IDE plugin. In a smart move, Andrey decided to build an IDE plugin that utilized IntelliJ’s parsing infrastructure first. This let Andrey demo the language interactively before anything could compile.! As he recalled: “I could show off the language as if it existed because it had some tooling, but I couldn’t compile anything.” 2. The initial Kotlin team was almost entirely made up of new grads Andrey hired some of his former university students to work on Kotlin. Many became core contributors who built foundational parts of the language. I found this story inspiring: it’s a reminder that you don’t need lots of experience to build durable things, as long as you are a fast learner. 3. Omitting the ternary operator from Kotlin is one of Andrey’s biggest design regret. Andrey removed this operator it because "if" was already an expression, freeing up "?" and ":" for nullable types and type annotations made sense. But "if", as an expression, turned out to be verbose. Andrey noted: “by the time I agreed [that removing the operator was a mistake], it was too late because you can’t retrofit the ternary operator in the current syntax.”

What does it mean for software engineering when we no longer write the code? A good person to answer is Boris Cherny: he wrore the first-ever TypeScript book published by O'Reilly, was one of the most productive engineers (by number of diffs and code reviews) at Facebook/Meta, and created Claude Code at Anthropic. Since November, he no longer writes code by hand. Watch or listen: • YouTube: https://lnkd.in/dYrVa2Xg • Spotify: https://lnkd.in/esJTybd5 • Apple: https://lnkd.in/dNuautNY Brought to you by: • Statsig — ⁠ The unified platform for flags, analytics, experiments, and more. https://lnkd.in/eQkXqjMZ • Sonar – The makers of SonarQube, the industry standard for automated code review. Proactively find and fix issues in real-time with the SonarQube MCP Server: https://lnkd.in/djtgaSBe • WorkOS – Everything you need to make your app enterprise ready. https://workos.com/ Three interesting things from this conversation: 1. Boris automated himself out of code review well before AI. Boris was one of the most prolific code reviewers at Meta company. And he worked hard to minimize time spent on code review. His system::every time he left the same kind of review comment, he logged it in a spreadsheet. Once a pattern hit 3-4 occurrences, he’d write a lint rule to automate it away! 2. PRDs are dead on the Claude Code team: prototypes replaced them. Instead of writing Product Requirement Documents (specs), they build dozens of working prototypes before shipping a feature. Boris: “There’s just no way we could have shipped this if we started with static mocks and Figma or if we started with a PRD.” 3. This is the year of the generalist (and maybe the year of those with ADHD) Boris’s work has shifted from deep-focus single-threaded coding to managing multiple parallel agents and context-switching rapidly. As Boris put it: “It’s not so much about deep work, it’s about how good I am at context switching and jumping across multiple different contexts very quickly.”

Seven of my biggest takeaways after recording a rare podcast episode with the creator of Kotlin, Andrey Breslav 1. Kotlin was born because Java stagnated for six years. By 2010, the last major Java release was Java 5 (2004). Java 6 (released in 2006) made zero language changes, Java 7 (released in 2011) made minor ones, and lambdas didn’t arrive until 2014. Meanwhile C# had lambdas, properties, and more — creating a clear market opening. 2. Kotlin’s first version was not a compiler: it was an IDE plugin (!!) In a smart move, Andrey decided to build an IDE plugin that utilized IntelliJ’s parsing infrastructure first. This let Andrey demo the language interactively before anything could compile 3. The initial Kotlin team was almost entirely made up of new grads. Andrey hired some of his former university students to work on Kotlin. Many became core contributors who built foundational parts of the language. I found this story inspiring: it’s a reminder that you don’t need lots of experience to build durable things, as long as you are a fast learner. 4. Omitting the ternary operator is one of Andrey’s biggest design regret. In Kotlin, Andrey removed this operator because "if" was already an expression, freeing up "?" and ":" for nullable types and type annotations made sense. But if, as an expression, turned out to be verbose. 5. Kotlin adding Android support was accidental. An Android developer literally asked the team "does Kotlin work on Android?," the Kotlin team checked, and theirtoolchain crashed. The Android tools were stricter than the JVM because Android developers "actually read the spec" (ha!) Ironically, this strictness made Android a great testing environment for validating Kotlin's bytecode correctness, and it was the reason the Kotlin team fixed up Kotlin to also compile on the stricter Android JVM. 6. 2026 will be the year of the IDE comeback vs terminal-based tools. While Andrey praised Claude Code as “a complete breakthrough of what you can do in a terminal,” but argued that we can work better, as devs, inside specialized environments. He expects new development environments built from the ground up for agent-first workflows. 7. What's next after Kotlin? A new type of programming language! Andrey is currently building a new programming language, but one based on English. It's called CodeSpeak: and it is neither a formal language, nor just prompting. It’s designed for engineers, not casual users, and aims to shrink typical application code by roughly 10x. What remains is “the essence of software engineering” — only the things the human uniquely knows about what needs to happen, because “everything else, the machine knows as well.” Watch the full podcast episode - which is probably the most in-depth history of Kotlin - and what's next - , as told by Andrey: https://lnkd.in/gzuZbcME On the photo: me and Andrey after the podcast recording, in Amsterdam

Big day: The Pragmatic Summit! First-ever in-person The Pragmatic Engineer event. 17 standout speakers. 500 incredible attendees. Starts in an hour!

How do software engineers use AI tools, and which ones are getting a lot more popular? We'll tell you if you tell us: If you are a dev / eng manager and would like to get a detailed report on how dev teams actually use AI tools, what is trending down/up: share what you do in our The Pragmatic Engineer survey (with Elin Nilsson) and we'll share back a detailed report: It's ~10 minutes to fill: https://lnkd.in/eYkV6h3h Thanks in advance if you're helping!

How did a tiny team of 30 engineers build WhatsApp, more than a decade ago, and what can dev teams learn from that feat today? Jean Lee was engineer #19 at the company, and shares fascinating details of how they built the world-famous messaging app. Watch or listen: • YouTube: https://lnkd.in/e7BPq_Z8 • Spotify: https://lnkd.in/edYURQsN • Apple: https://lnkd.in/e28cPGET Brought to you by: • Statsig – ⁠ The unified platform for flags, analytics, experiments, and more. https://lnkd.in/eQkXqjMZ • Sonar – The makers of SonarQube, the industry standard for automated code review. https://lnkd.in/ekMzUJxY • WorkOS – Everything you need to make your app enterprise ready https://www.WorkOS.com Three interesting observations from this episode: 1. WhatsApp had no code reviews after in-place. WhatsApp cofounder, Brian Acton, reviewed the very first pull request of each new hire, and after that, there were no more code reviews. Jean recounts how Brian reviewed her debut PR in extreme detail. This first (and only!) review set the bar high, and she wrote code to that standard from then on. 2. WhatsApp had close to zero formal processes. WhatsApp had no Scrum, no Agile, no TDD (test driven development), and no formal code reviews beyond the first commit. In contrast, Skype had 1,000 engineers and mandatory Scrum training, but WhatsApp still outcompeted it and won. Jean’s response to hearing of all the formal processes Skype used in order to execute faster: “I’m surprised to hear they thought they were shipping faster because of it.” Perhaps process is often a substitute for trust, not quality?” 3. Saying “no” to features was a competitive advantage. WhatsApp’s CEO, Jan Koum, rejected 99% of feature requests from the team. While competitors shipped dozens of shiny, new features, WhatsApp ruthlessly prioritized reliability and simplicity. Jan repeatedly told the team what the mission was. “I want a grandma living in the countryside to be able to use our app”, he said.

Mitchell is one of the best engineers of our time: worth understanding how he warmed up to AI tools and the very pragmatic ways he uses them (and avoids overuse)

Upcoming guests on The Pragmatic Engineer Podcast: • Thuan Pham - Uber's first (and longest-serving CTO), now CTO at Faire • Martin Kleppmann - author of Designing Data Intensive Applications • David Heinemeier Hansson (DHH) - creator of Ruby on Rails, cofounder of 37Signals, built Basecamp and Hey • Alice Ryhl - Rust language advisor, core maintainer of Tokio (Rust's async library) and software engineer at Google • Anders Hejlsberg - creator of TypeScript, C#, TurboPascal • Kelsey Hightower - legendary for his Kubernetes+community work, formerly distinguished engineer at Google, minimalist Recent guests who came on the podcast: • Jean Lee - engineer #19 at WhatsApp, founder of Exaltitude • Steve Yegge - creator of Gas Town, author of Vibe Coding, formerly at Amazon, Google • Boris Cherny - creator of Claude Code, formerly one of the most productive engineers at Meta • Mitchell Hashimoto - creator of Ghostty, founder of HashiCorp • Andrey Breslav - creator of Kotlin, now building the new programming language CodeSpeak • Grady Booch - heavily influenced object-oriented programming, creator of UML, industry legend   • 🦄 Peter Steinberger - creator of OpenClaw, previously founder of PSPDFKit • Mai-Lan Tomsen Bukovec - heads up AWS S3   • Bryan Cantrill - cofounder at Oxide Computer Company, industry veteran for anything servers and hardware and software and Rust I sometimes have to pinch myself, that this is real, looking through the past and upcoming guest list. Thank you to everyone listening, and to all the past and future guests for coming on the show! 🙌 Search for "The Pragmatic Engineer" on your favorite podcast player, and add it to not miss episodes. Or subscribe here: • YouTube: https://lnkd.in/eU9FDp3N • Spotify: https://lnkd.in/esJTybd5 • Apple: https://lnkd.in/e-PZVTAY • Email: https://lnkd.in/grXSBkVw

What if what is happening with AI will expand the software industry further, not contract it? This is what Grady Booch predicts will happen. If you are anxious about the state of the industry, you want to watch/listen to Grady's longer-term perspective and stories. Watch/listen to the full episode here: • YouTube: https://lnkd.in/eAesvu74  • Spotify: https://lnkd.in/ewyizHbH  • Apple: https://lnkd.in/eqprJ2sH Brought to you by: • Statsig — ⁠ The unified platform for flags, analytics, experiments, and more. https://lnkd.in/eQkXqjMZ • Sonar – The makers of SonarQube, the industry standard for automated code review. Join me online at the Sonar Summit on March 3rd, where I talk about practical tactics for the AI era. https://lnkd.in/eD3nmzGF • WorkOS  – Everything you need to make your app enterprise-ready. https:// workos.com One interesting observation from Grady: Deep foundations become more important as the field accelerates. Grady noted that the field is moving at an incomprehensible pace for people without deep foundations and a strong model of understanding. He specifically recommends reading Minsky’s Society of Mind (book: https://lnkd.in/e7-QkNCE) for architectural guidance.

Here's what GitHub's last CEO has been up to: building an agent-first dev platform. I'm an investor. They just shipped Checkpoints. It's open source, easy to use. It adds agent context (eg trajectories, prompts, token usage etc) to PRs. Get it at entire.io

How has the day-to-day workflow of Mitchell Hashimoto changed, thanks to AI tools? Mitchell is one of the most influential infrastructure engineers of our time (who created the likes of Terraform and Ghostty), and is one of the most pragmatic builders I’ve met. Watch or listen: • YouTube: https://lnkd.in/ecdgWKbY • Spotify: https://lnkd.in/es7kX8vS • Apple: https://lnkd.in/eF8vmUig Brought to you by: • Statsig — ⁠ The unified platform for flags, analytics, experiments, and more. https://lnkd.in/eQkXqjMZ • Sonar – The makers of SonarQube, the industry standard for automated code review. Join me online at the Sonar Summit on March 3rd: https://lnkd.in/eD3nmzGF • WorkOS – Everything you need to make your app enterprise ready. https://workos.com/ ---- Three interesting learnings from this episode: 1. HashiCorp had no real business for four years and their first commercial product was a full-on failure. The initial product, Atlas, required customers to adopt the entire HashiCorp stack, which created an unsolvable internal budget problem: no one org within a company would want to purchase the whole stack! HashiCorp pivoted to selling individual services like Vault, and this approach turned out to be a billion-dollar business. 2. Mitchell's new rule for building software: always have an agent running in the background doing something. "If I'm coding, I want an agent planning. If they're coding, I want to be reviewing." He kicks off tasks before leaving the house — research, edge-case analysis, library comparisons — so work progresses while he drives or is away. 3. Git and GitHub may not survive the agentic era in their current form. Agents cause so much churn that merge queues become untenable, branches proliferate, and repos balloon. Mitchell compares the needed shift to Gmail's revolution for email: "We're at the Gmail moment for version control... never delete, archive everything."

Last call to join me and the ELC community on 3 March, in Amsterdam: