Editor | Yifeng
This should be the most solid and objective AI programming talk I’ve ever heard.
It doesn't talk about “miracles,” nor does it peddle “anxiety.” Instead, it raises a very practical question:
“Today, can we do a reality check:
Are those overly optimistic AI programming predictions reliable? Or is reality not that magical at all?”
Microsoft CEO said: ‘30% of code is written by AI’;
Authoropic’s CEO claimed a few months ago, ‘Within a year, all code will be generated by AI’;
But why does this feel different from how engineers actually work?
Why did someone from a startup use Devin, not only failing to improve efficiency but also introducing bugs that cost them $700 in accident expenses?
This talk comes from Gergely Orosz — formerly an engineering manager at Uber, who later transitioned to a full-time tech author.
His book “The Tech Resume Inside Out” was once called the “programmer’s resume bible,” and now, through The Pragmatic Engineer, the world's most popular engineering newsletter, he continues to influence hundreds of thousands of tech professionals.
To answer the above questions, he spent two months interviewing AI DevTools startups, in-house engineers at large tech companies, AI biology startups, and a group of independent developers who “love code itself.” He ultimately compiled a multidimensional picture of the real state of AI programming.
Let me give you a preliminary conclusion first:
- AI DevTools Startups: Heavy usage (unsurprising);
- Large Tech Companies: Huge investment, usage continuously increasing;
- AI Startups: Inconsistent usage, some effective, some indifferent;
- Independent Developers: More excited and willing to use than before.
The most surprising was a true “veteran programmer” — Kent Beck (yes, the author of “Extreme Programming”), who represents the fourth category:
“I’m happier writing code now than at any time in the past 52 years.” —Kent Beck, now in his 52nd year of coding.
AI finally allowed him to pursue projects he always wanted to do but found “too complex, too expensive,” such as writing a parallel computing server in Smalltalk. He said:
“The landscape of ‘what’s cheap, what’s expensive’ in the tech stack is being rewritten; many things we gave up on in the past are now ridiculously cheap.”
The editor has organized this insightful talk into an easy-to-read and informative article. Here’s what you’ll read next:
- AI DevTools Startups: 90% of code AI-generated, thousands of MCP requests running simultaneously!
- Google and Amazon: How to integrate LLMs into development tools?
- AI Startups: How do developers use Claude Code, Cursor, Windsurf, etc.?
- Independent Developers: Who is “completely transforming,” and who is “observing rationally”?
- Finally, his 4 reflective questions, each hitting real engineering scenarios.
Claude Code, Windsurf 90% AI Code, Cursor Only Half of Former
First up are AI DevTools startups.
I recently spoke with the Anthropic team last week and asked them what trends they’ve observed internally. While these companies might have a bit of a “self-serving filter,” their answers were quite insightful.
They said that when they first internally opened Claude Code for engineers to use, almost everyone immediately started using it daily, and their enthusiasm continues to this day. This “organic adoption” surprised even them.
Keep in mind, this was just an internal version at the time. Claude Code was only released publicly a month ago; it’s not an IDE but a command-line interface (CLI) that runs in the terminal.
They also told me that currently, 90% of the Claude Code product itself was written using Claude Code. This number sounds exaggerated, almost like an advertisement. But I specifically confirmed with the engineers—they aren't like the marketing department, so this statement is quite credible.
They also mentioned an interesting statistic: On its official launch day, Claude Code’s usage surged by 40%; in less than three weeks, the increase reached 160%. Whatever the reason, this indicates that the tool indeed has appeal.
Additionally, Anthropic launched a project called MCP (Model Context Protocol). Their goal is to use a protocol to connect IDEs or Agents to developers’ existing context environments, such as databases, GitHub, Google Drive, Puppet, etc.
I tried it myself: I connected it to one of my API data sources and directly asked it: “How many people claimed a certain coupon code?” It automatically generated an SQL query, and the result was quite reliable. This “natural language to data” experience was truly eye-opening.
According to them, MCP was open-sourced last November. By early this year, several medium-sized companies began adopting it. Then, in March and April, even “big players” like OpenAI, Google, and Microsoft joined in supporting MCP.
Now, thousands of MCP requests run daily, and its importance will be mentioned later in the talk.
Besides Claude, I also spoke with two other AI IDE teams:
- Windsurf: They said that currently, 95% of their team’s code is generated by Windsurf’s Agent or autocomplete;
- Cursor: Their estimate is that 40% to 50% of their code uses AI. While not as high as the previous two, they frankly admitted: some areas are indeed useful, while others are still not quite there.
I appreciate Cursor’s honesty. After all, these companies make AI programming tools, and everyone wants to maximize “AI usage” to 100%—that’s a selling point. But Cursor didn't hide anything, which is commendable.
Google: “Cautious and Long-Term,” All AI Tools are In-House Developed
I anonymously spoke with several Google engineers, about five of them. First, it's important to know that almost all of Google’s engineering systems are self-developed.
- They don’t use Kubernetes; they use their internally developed Borg;
- They don’t use GitHub; they use their own code repository system;
- They don’t use public Code Review tools; they use their internal tool Critique;
- Their IDE is the self-developed system Cider (full name: Integrated Development Environment and Repository).
Cider was initially a web tool, but it has now evolved into a customized branch based on VS Code, highly integrated with Google’s internal infrastructure, offering a very smooth development experience, with a high degree of interoperability.
Engineers told me that AI tools are now almost everywhere.
Internally at Google, they have integrated large language models into their IDE “Cider.” Cider is a custom branch based on VS Code, and there’s also a web version called Cider V, which integrates autocomplete and a conversation-based IDE. They said the user experience is pretty good, perhaps not as good as Cursor, but overall performance is quite solid. In their code review tool Critique, AI can also provide review feedback, which is rated as “very reasonable and usable.”
For instance, code search, a very powerful internal Google tool, now also integrates LLM support. You can ask it questions, and it will help you locate relevant code sections. Just a year ago, these features were hardly used internally at Google. But everything changed within six months.
A current Google engineer told me that Google’s approach to implementing AI tools internally is very “cautious and long-term.” They want these tools to be genuinely trusted and continuously used by engineers.
Additionally, there are many other tools exclusively for internal Google use, such as:
- Notebook LM: You can upload documents and converse with it;
- Prompt Playground: Somewhat similar to OpenAI’s Playground, but Google actually developed it before OpenAI released theirs;
- Moma: An LLM-based knowledge retrieval system widely used among Google engineers.
I heard from a Googler (who preferred to remain anonymous) that every org (organization) is now developing its own GenAI tools. The reason is simple: leadership wants to see this innovation, and it's easier to secure internal resources and budget support this way. Tools like Notebook LM were developed because “a team secured budget and just started building it.”
However, what impressed me most was what a former SRE told me—he still keeps in touch with many Google SREs—that Google’s infrastructure team is currently preparing for a “10x code volume” increase. They are upgrading deployment pipelines, code review tools, feature flagging mechanisms, and so on.
This made me very curious: Has Google already seen certain trends that we haven't yet realized?
Amazon: More Aggressive with AI than Google, but Quite Low-Key
When it comes to AI tools, most people don’t immediately think of Amazon.
Although outsiders aren’t deeply aware of Amazon’s AI capabilities, my conversations with internal engineers revealed that almost all developers use a tool called Amazon Q Developer Pro. It’s incredibly useful for AWS-related tasks.
What surprised me was that Amazon insiders were puzzled as to why the outside world knew almost nothing about this tool. They stated, “As long as you’re working with AWS, this tool’s context understanding is exceptionally good.”
About six months ago, I heard them say this tool “wasn’t great”; but now, many are saying: “It’s really good to use now.”
They also told me that they now use AI tools for writing Amazon PR FAQs (those six-page documents simulating press releases). During mid-year performance review season, many writing tasks are also accelerated with AI.
Amazon has a partnership with Anthropic; they have an internal version of Claude.
Regarding Amazon, what I found most interesting was the internal progress of MCP (Model Context Protocol).
Anthropic first proposed MCP, and now Amazon seems to be fully integrating it.
A little background: Amazon is an “API-driven” company. As early as 2002, Jeff Bezos issued his famous mandate:
“All teams must expose functionality and data through service interfaces (APIs), and no internal communication is allowed; violators will be fired.”
This is also the underlying reason for AWS’s birth. All their services can be publicly accessed via APIs, so now they only need to “attach” an MCP server to the API, and AI Agents can directly connect and call them, which is incredibly easy.
I learned from an Amazon employee that most internal Amazon tools and websites currently support MCP, which I believe is the first time this has been publicly mentioned.
Automation is ubiquitous within Amazon. I’ve heard that many people are using AI tools to automate ticketing systems, emails, internal processes, etc., and some engineers have even automated most of their workflows.
Although no one outside is discussing these developments, they are indeed happening. Amazon, as an “API First” company, might now quietly become a leader in “MCP First” by 2025.
Startup Polarization: Some Love It Madly, Some Say “Worse Than Hand-Coding”
I also spoke with some small startups. They didn't start out as AI tool companies, but have gradually integrated AI into their daily processes — some have even shifted towards an “AI-first” approach.
1. Proponent: Incident IO: The Entire Team Uses It, Fostering a Strong “Knowledge Co-creation” Atmosphere
Incident IO, originally a company that built an on-call alerting platform. It was an on-call platform, but AI is clearly very suitable for alerting, troubleshooting, and solution inference. So they gradually became an AI-first company.
I interviewed co-founder Lawrence Jones (who was also a speaker at this conference), and he told me:
The entire team is extensively using AI to boost efficiency, and they share usage tips and best practices in Slack, fostering a “knowledge co-creation” atmosphere.
Some specific examples are quite illustrative:
- Someone tried using another MCP server to handle a complex support ticket, and the AI’s initial draft was surprisingly reliable;
- He shared this experience in the group, and others tried it out, discussing prompt design and generation logic;
- Someone also discovered a “new prompt trick”: asking AI to provide 3-5 different code solutions, then following up with “why write it this way, and what if we took a different approach.”
Lawrence stated that the most crucial turning point was three weeks after Claude Code went live.
He checked the data (it was a Sunday at the time) and found that the entire team was already using it daily. There was no brand sponsorship; they simply found Claude incredibly useful.
2. Disabler: An AI Biology Startup: Latest Models Can't Meet Demand, Is the Niche Too Small?
This company has been around for about three years, with a team size between 50 and 100 people. Its entire system architecture is very modern: based on Kubernetes for automated numerical pipelines, Python, Hugging Face, and other technologies.
Their engineer told me: “We’ve tried many LLMs, but none have truly been usable. Because manually writing correct code is actually much faster than modifying AI-generated code — even with the latest models, like Claude 3.7, or even Claude 4, it’s still the same.”
They feel their domain might be too niche for LLMs to be effective.
This engineer also admitted that they didn’t want to be publicly named because they didn’t want to be labeled “AI skeptics”—but it was the truth.
They are a fast-paced startup that tried various AI tools (including code review assistants), but ultimately found these tools unsuitable for developing their new, complex software. It’s not that they didn’t try, but they tried, found it didn't work, and quickly pivoted.
“Never Been More Excited!” — How Do Independent Developers and Veteran Programmers Evaluate AI Coding?
After discussing startups, I also interviewed several independent software engineers who were already very accomplished before the AI era and have a deep love for “writing code.”
1. Flask Author Armin: I Now Prefer to Be an AI Agent Engineer
Armin Ronacher, the author of the Python web framework Flask, has been a “pure coder” for over a decade. He recently left Sentry and is preparing to start his own venture.
He recently published an article titled: “AI Changes Everything.” He made a very disruptive statement:
“If you told me six months ago that I’d prefer to be an ‘AI agent engineer’ instead of coding myself, I definitely wouldn’t have believed you.”
His shift was due to three reasons:
- Claude Code is truly smooth to use;
- After intensively using LLMs, he finally “broke through a psychological barrier” and began accepting the AI collaboration model;
- Most critically: agents can execute automatically and observe feedback, a mechanism that can greatly reduce the impact of ‘hallucination errors’.
2. iOS Tool Author Peter: I Found My “Passion for Coding” Again
Peter Steinberger is the author of PSPDFKit, the founder of the most popular PDF SDK for iOS. After selling his company, he has been exploring new technologies. He recently published an article titled:
“The Spark Returns”
He said he felt a turning point had arrived: languages and frameworks no longer mattered, and AI tools allowed him to easily switch from Objective-C to TypeScript, writing anything he wanted. The decoupling capability at the tool layer was so strong that productivity skyrocketed.
He also shared a joke he posted on social media: “Many tech people are so excited playing with AI tools that they can’t sleep.”
Interestingly, we were exchanging messages at 5 AM; I woke up early for something else, and he hadn’t slept at all because he was coding.
3. ThoughtWorks’ Brigita: LLM is a “Horizontal Force” in the Tech Stack
Brigita, a Distinguished Engineer at ThoughtWorks, summarized the significance of LLMs this way: LLMs are among the very few tools that can be used at any abstraction layer.
You can treat it as an assembly-level low-code tool, or use it to manipulate high-level languages, or even program with natural language. This isn't simply ‘adding a layer of AI,’ but something that horizontally permeates the entire tech stack.
It is this “cross-layer abstraction capability” that makes LLMs truly exciting. The person saying this is a seasoned engineer who had already achieved success before AI emerged.
4. Django Co-founder Simon: The Real Breakthrough Has Just Begun
Simon Willison is a co-founder of the Django framework, who sustains himself by writing blogs and open-source contributions, and was called “the must-read LLM blogger” by Andrej Karpathy.
He said:
“Code agents really can run, loop repeatedly, debug compilers, and get things done. In the past 6 months, the iteration of large models has clearly crossed a threshold; now they are truly ‘useful’.”
5. Kent Beck: 52 Years as a Coder, Happiest Now!
Finally, the heavyweight guest: Kent Beck, father of Extreme Programming (XP), author of JUnit, a living legend in software engineering.
He said:
“I’m happier programming now than at any time in the past 52 years.”
He is currently working on a parallel virtual server project using Smalltalk — a dream of his for many years.
He said the advent of LLMs finally allowed him to focus on what he truly wanted to do, without being constrained by tool frameworks.
In his view, LLM is another technological wave that fundamentally changes the cost structure, following microprocessors, the internet, and smartphones:
“Things we didn’t do in the past because they were expensive or impractical have suddenly become ridiculously cheap and easy.”
Further Thoughts: Four Questions Worth Pondering
These trends are very interesting, but I don't believe we can yet say that “AI has completely transformed software development.” It's far from a “done deal, the future is here” kind of story.
So I have four questions of my own:
❓Question One: Why are founders and CEOs far more excited than engineers?
While some engineers are indeed thrilled, like Armin and Peter, they themselves might be entrepreneurial types. But Zack Lloyd, founder of Warp, asked a very pertinent question:
“Has anyone noticed that the most senior engineers tend not to use AI much, while the most enthusiastic ones are founders and product managers?”
This is a founder of an AI tool terminal reflecting.
Looking at public statements by CEOs, almost all are vigorously promoting AI’s potential. This is worth our consideration.
❓Question Two: How mainstream is the use of AI tools among developers?
I asked for a show of hands at the event: “How many of you use AI tools to write code at least once a week?”
Approximately 60–70% of the audience raised their hands.
This aligns with DX’s survey data. They recently surveyed 38,000 developers, and the results were:
- In a typical organization, about half of people use AI tools weekly;
- The top companies can reach six out of ten.
But please note, most examples I discussed in my talk are actually higher than this median (except for that AI biology startup).
There might also be a sample bias—those willing to share their experiences are inherently more inclined to use AI.
❓Question Three: How much time have we actually saved?
For example, Pete told me he felt his productivity increased by 10–20 times.
However, DX’s survey shows that AI tools typically save developers about 3–5 hours a week, averaging about 4 hours.
4 hours is not bad, but claiming “10x efficiency improvement” seems a bit exaggerated. The question is: Are we truly using the time saved to create more value?
I don’t know.
❓Question Four: Why is AI particularly effective for individual developers but less so for teams?
This phenomenon is very common. Laura Tacho of DX also told me that AI tools perform well at the “individual level” but have not yet demonstrated value at the “organizational level.”
The enthusiasm of CEOs and founders is understandable, as their companies are betting on AI and face financial pressure.
It also makes sense for large tech companies to actively invest in and explore AI tools.
But what concerns me most are the veteran developers who have been around for a while; they are genuinely seeing results, feeling the change, and willing to invest more.
I think we might be at a moment of “step-change transformation” in how software is developed.
I contacted software engineering thought leader Martin Fowler and asked for his insights on an article I reviewed. His response was:
“The impact that LLMs will have on software development is comparable to the shift from assembly language to high-level languages.
Later updates to various high-level languages, while improving productivity, didn’t bring about that ‘qualitative leap.’
But LLMs are different: they are the first tools in computer history to introduce ‘non-determinism,’ which is very critical.”
Conclusion
My conclusion is: Change is happening, and we need to experiment more boldly.
We should experiment more like startups, to figure out:
- What works?
- What doesn't work?
- What has genuinely become cheaper?
- What is truly worth investing in?
This talk concludes here, its content solid and perspectives diverse, leaving much to ponder.
Do you resonate with these observations from the talk?
For you, does AI code writing empower or cause trouble? Feel free to share your real feelings in the comments section.