AI Struggles: A Developer’s Story  🔗 **Source:** [AI Struggles: A Developer’s Story](https://www.youtube.com/watch?v=qDL1aGqF4HU) > [!note]+ Document Notes > --- > tags: [ai-coding-tools, developer-productivity, php-community, jetbrains, php-annotated, brent-roose, tempest-framework, developer-careers, ai-hype, brownfield-vs-greenfield, code-review-burden, skill-formation, puzzle-solving-motivation, personal-essay] > author: Brent Roose (PHP Annotated) > source: youtube.com > reference: https://www.youtube.com/watch?v=qDL1aGqF4HU > date created: 2026-09-02 08:40 > --- > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > [!warning] Read these before trusting the note > > **Speaker identity is inferred, not stated.** The transcript never names the speaker. The biography it gives — 17 years programming, ~5 years at a company that made open source profitable alongside client work, a PHP blog, hired by JetBrains "to teach about PHP and PhpStorm," now building "a new framework for PHP" that is "more than 3 years old" — matches Brent Roose (PHP Annotated host, JetBrains developer advocate, Tempest framework, formerly Spatie, stitcher.io). Treat the attribution as high-confidence inference. > > **Vendor channel.** PHP Annotated is a JetBrains channel and the speaker is a JetBrains employee. The talk does not pitch JetBrains AI products (Junie, AI Assistant) by name; its one IDE reference is "I also use an IDE instead of a text editor. There is a reason for that." The conflict is structural, not overt. > > **ASR artifacts (auto-captions):** "Symphfony" = Symfony; "CRUT/credit controller" = CRUD controller; "Entropic" = Anthropic; "PHP Storm" = PhpStorm; "3mon" = 3-month; "Jet Brains" = JetBrains. > > **Cited studies are described, not linked.** The speaker refers to "an extensive study at Stanford" (100,000 developers, 600 companies, 80% private codebases, commits back up to 3 years) and "another study published by [Anthropic] a couple of months ago" on skill formation, saying links are "in the description." The captured HTML has zero links; the YouTube description wasn't captured. The Stanford description matches the Denisov-Blanch team's developer-productivity research; the Anthropic description matches its coding-skills study. Neither is verified here — numbers below are the speaker's recollection of them. Talk format (slides referenced: "this would be the output," "that orange bar") — visuals not in the transcript. > > No sponsors. 18,372 transcript characters, 18:49, uploaded 2026-09-02. > # 🏷️ Title: AI Struggles: A Developer's Story > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ### 🔗 References > - Source: https://www.youtube.com/watch?v=qDL1aGqF4HU (PHP Annotated, JetBrains) > - Referenced but not linked in capture: a Stanford developer-productivity study (100k developers / 600 companies) and "a very accessible talk by one of the researchers"; an Anthropic study on AI assistance and coding-skill formation; unnamed "pretty heavy reading" on AI economics and sustainability. All said to be in the video description. > ## 📝 Summary > **What this is.** An 18-minute personal talk by a JetBrains PHP advocate about feeling "old" for the first time in 17 years of programming — not because of age but because AI produced "a different generation… not necessarily a generation by age but by mindset." The first two-thirds is autobiography: a World of Warcraft maze generator that hooked him on "puzzle solving," a deflating agency internship ("you can probably forget most of these details they teach at school"), a Symfony summer job that restored the joy, an over-abstracted CRUD controller that "someone probably should have stopped," a WordPress agency job he quit after two days, and years of finding a balance between puzzle-solving and employer value through open source, blogging, teaching, and framework work. The last third maps that arc onto AI: initial panic, then deliberate conversations with "the vibe coders as well as the skeptics," then four findings. > **The four findings.** > 1. *Productivity is nuanced.* A Stanford study of 100,000 developers at 600 companies (80% private codebases, commits back up to 3 years, researchers with "no AI product or skepticism to sell") showed output rising after AI adoption, but "a big chunk of that gain consisted of AI generated code that had to be reworked." Net gain exists; so does a price. An Anthropic study found "a statistically significant decrease in mastery because of AI assistance." > 2. *Gains depend on project stage and task complexity.* Greenfield vs. brownfield, simple vs. complex. On his framework — greenfield in age but low-level and complex — "AI only rarely helps" while still adding rework overhead; AI-written external PRs need so much cleanup that "it's often just easier to start from scratch than for me to be an LLM code reviewer." > 3. *The hype is financially motivated.* "Many AI drivers are also selling a product." An anecdote: a developer denied an earned promotion because "she's not using enough AI, which upper management had set as a hard requirement for career growth." > 4. *Sustainability is unresolved.* Hardware shortages, electricity costs, and "those handful of companies… investing in each other." > **Bottom line.** The talk's argument is that the AI shock is the same shape as the junior-developer shock — the gap between what you love about code and what the job needs — and is survivable the same way: understand the tool, use it where it measurably helps, and don't be ashamed of "guarding our passion." It ends: "the question isn't about whether AI will change programming. It's about what we choose to do with that change." > ## 📖 Main Content > **The autobiographical setup and why it's load-bearing.** The talk spends twelve minutes on career history before mentioning AI. That's a structural choice: the AI section only works if you accept the earlier claim that "loving code and working with code… aren't always the same thing… It's a process of growing up." Every AI finding is then framed as a repeat of that lesson. The maze generator (SQL-exporting game-object placement for a private WoW server, "which I know it was illegal") establishes that the speaker's motivation was puzzles, not code. The internship establishes that professional code can have "barely any puzzle solving left." The CRUD controller establishes the opposite failure — puzzle-chasing that "wasn't necessarily in the best interest of that startup." The two-day WordPress agency stint is offered as a data point about self-knowledge, with the aside "we can laugh about WordPress" — a throwaway that lands differently for a WordPress audience. > **The Stanford study as the talk's evidence.** The speaker describes the methodology in unusual detail for a talk: sample size, company count, private-codebase share, commit history depth, and the researchers' claimed independence. The result is presented as a chart with an "orange part" — rework of AI-generated code — subtracted from apparent output. His reading is careful: "still there was a measurable increase in productive output as well," so the study is not anti-AI. His inference — that the productivity question "might be a much more personal question" because the rework cost "may be perceived very differently from person to person" — is his, not the study's, and he marks it as such. > **The Anthropic skill-formation study.** One sentence, with the speaker's own emphasis: "this is Anthropic by the way, the creator of Claude." The rhetorical point is that a 17 years of programming and for the first time I feel old. Not because I've been doing this for 17 years, but because something has changed. I'm not a true veteran. I still feel young when people are talking about dialup internet, for example. I I've never had that. But I also realize there's now a generation after me. I'm not that young anymore and that never really bothered me until two years ago. But to truly understand, I need to take you back to the beginning. One of my first real programming projects was a maze generator, but not a normal maze generator. I was playing on a private World of Warcraft server back in the day, which I know it it was illegal. I'm sorry for that. But for Christmas, we were organizing this event with a whole server, a gnome race. I had figured out how game objects in the world were stored as coordinates in a database table. And so I had built a program where I sketched the maze layout. Um, I pressed a button and then it would export SQL queries that I could run on that database. H, and this in turn uh would result in game objects being placed into the world. Now, unfortunately, this is the only screenshot I was able to find and and the maze itself was part of a bigger obstacle course. So, you can't see it here. You had to be there. But it was really fun. And it was one of these kinds of projects that made me full of passion for code. And actually, what I fell in love with was not necessarily code itself. It was more the puzzles that code allowed me to solve. I had fallen in love with puzzle solving. And so I went to learn programming in high school and then in college. And I have to admit my need for puzzle solving was largely satisfied. We we learned about patterns, principles, algorithms and data structure. And you know code was always the star of the show. But then came my internship and with it came my first real project as well as my first real code review. And I was looking forward to it because I finally got to learn from the real professionals. And so during that first week, I had been working on this feature, a Google Analytics dashboard for their customuilt CMS. And now my mentor would review my code for the very first time. And I remember this vividly. He comes in and he asks one question. Do you always use one return statement per function? That was such a random question to me. Uh it had little to do with the overall scope. I thought uh this was just the way I was taught in school and I never knew any better. But apparently that one return statement per function is a convention that stems from way before my time likely even from before the time when people were using dialup internet. Uh most programmers today don't really care about it anymore. But to me that was new. And so uh yes I I told him we learned it this way. to which he replies, "Now, you know, you can probably forget most of these details they teach at school about programming. We don't actually do this in real life." And that was my first code review done. And and I felt a bit confused afterwards because this was not how I expected that first review to go. And things didn't go any better during the rest of my internship either. There wasn't anything necessarily wrong with it and I got good grades afterwards. But with every week I just I felt my passion for code drain more and more. You see the things I was doing with code in a professional setting they were just so different from what I had grown passionate about uh for the last couple of years. There was barely any puzzle solving left. It was uh to be honest uh pretty boring. And after 3 months when my internship came to an end um I was ready to abandon programming altogether to give up. One thought kept repeating over and over again. They don't teach this in school. I felt very unprepared. If that 3mon experience was any resemblance of what programming in in the real world meant then, you know, I rather not program at all. Now, in hindsight, uh I should make something clear that there wasn't anything wrong with this internship at all. Um, it was a normal PHP web agency, you know, building websites and and web applications for small to medium-sized companies. The only thing that was really wrong were my expectations. But I didn't know that yet. And so I decided to pivot to another study, design. I did first graduate my programming studies though because you know that that internship was the very last step of the process. Uh, but my parents said that if I wanted to do a secondary study, I I would have to pay for that myself. So, I had to find a summer job. Now, I could do two things. I could fill shelves at a grocery store, um, or I could write code. And even if realworld code apparently wasn't my thing, um, I still preferred it over filling shelves. So, I did find a a very well-paying summer job as a Symphfony developer. Um, it was with a startup and it turned out to be a very pivotal moment for me because suddenly I was doing something entirely different from what I had been doing before. I was still writing code and it was still a real project but at the same time it was such a different experience compared to my internship. I truly found joy again and I discovered that programming even in real life projects could be fun as well. Somehow that there was room for puzzle solving and sure there were some boring parts but overall it was really exciting. I did make one uh mistake though. I kind of went overboard abstracting a problem because I'm a puzzle solver, right? I had to build a REST API with I think it was 50 to 100 endpoints, something like that. And I thought, let me write an abstraction for that. That will be fun. And and that's what led to the CRUT controller. Um, one abstract controller that could handle every possible endpoint for every possible entity in the database. Um, I spent weeks on what I thought was a beautiful work of art. Uh but in reality, someone probably should have stopped me because chasing my need for puzzle solving uh wasn't necessarily in the best interest of that startup. Uh it would have taken less time to just build those 100 controllers by hand or maybe to use some kind of generator. My abstraction it became so complex and the business requirements grew over time that even I couldn't really understand it anymore. And the sad part is I I don't really know what happened to it. I know that eventually the startup failed, but I don't think that was because of my credit controller. In any case, I had a lot of fun, but summer came to an end and I had to start my new study. Um, except I didn't really want to study anymore. I had so much fun during the summer as a programmer that I thought like, okay, maybe let's give the real world one more chance. You know, at some point, you realize that that loving code and and working with code that they aren't always the same thing. And that's okay, but it takes time to get used to. It's it's a process of growing up. For example, my first real job after my internship and my summer job was with a WordPress agency and I quit after 2 days. And you know, we can laugh about WordPress, but this was a crucial part of me discovering what I needed from a programming job to to be productive, to be happy. I knew that I needed some level of puzzle solving or else I would just get bored over time. I needed some CRUD controller in my life, some challenges to keep me engaged, but I also had a responsibility to create enough value for the company I was working at. I couldn't keep spending months on CRUD controllers just for the sake of solving a puzzle. And finding that balance took me years. One solution for me was open source. I was able to spend around 5 years at a company that had managed to turn open source into something that was actually profitable when combined with client work. I also started a blog where I wrote about PHP and programming. I found ways to combine the puzzle solving with teaching so that other people could benefit as well. Eventually, I was hired by Jet Brains to teach about PHP and PHP Storm to be involved and to invest in the PHP community. And then my latest puzzle solving itch is being scratched by building a new framework for PHP. It's a real thing and there's an active and very talented open source community involved. And honestly, I'm super proud of it. The thing is, I had to find ways to balance the interests of whichever company was paying my salary with what I needed to keep my passion for code afloat so that I could be an effective programmer. You know, I've been doing this for 17 years, and it took some time, but I feel like I finally found a good balance. Although, in all honesty, maybe I should say 16 years. Um because the past year, well maybe two years actually it has been pretty wild and I experienced a lot of chaos again and you've probably noticed it as well. I'm talking about AI for the first time in 17 years of programming. I truly feel old as if a new generation of programmers is here that I don't seem to understand now. I spent years trying to find that balance so that I could get joy out of code itself to have that puzzle solving aspect while still providing enough value to my employer. But then seemingly out of nowhere comes a different generation and not necessarily a generation by age but by mindset. Another type of programmer that doesn't seem to need joy from code itself. On the surface, they don't seem to care for code at all. They just want to get to an end result as fast as possible with as little tokens as possible and it gives them joy apparently. And my first reaction was panic, especially with all the click- baity headlines out there about how AI is going to replace so many developers, lots of FOMO, our whole industry would change and whatnot. And this is a feeling I still see so many developers struggle with. But then after that initial panic, I figured I might as well properly look into the subject. I like to think of myself as a rather rational thinker. I'm okay with questioning myself and I thought back of the years at the start of my programming career. I had to learn how to deal with that friction, puzzle solving versus providing value. Maybe it was time to do that once again. And so I decided to challenge my own ideas and struggles with AI. I sat down and I talked to people, people from from either side, the vibe coders as well as the skeptics. I talked to them and I learned many great things and I found some peace and I want to share some of these findings with you. First, I learned that the answer to to how much more or less productive AI makes you, it isn't as straightforward as you might think. Even if you're using AI extensively and feel more productive, that doesn't really mean you are measurably more productive. Or does it? It turns out there was an extensive study at Stanford about this question and they analyzed the work of a 100,000 developers from across 600 companies. Um 80% of code came from private code bases, real world code. They they analyzed millions of commits going back up to 3 years and they claimed to be rather impartial. They they had no AI product or skepticism to sell. They were independent researchers and the results were pretty interesting. This would be the output of the companies they analyzed and they saw a clear pattern amongst all test subjects. Output is measured by whatever is being done in the codebase. And the core of their study was to be able to measure this output as accurately as possible. And now this is where their test subjects started to use AI. And you would think that this is proof, right, that AI makes you more productive. There's a lot more output from developers, much more activity in their codebase. But there's a side note because not all output is created equally. Where the introduction of AI indeed made developers feel like they were doing more. A big chunk of of that gain consisted of AI generated code that had to be reworked. And still there was a measurable increase in productive output as well. But that orange part really stood out. And then suddenly the question of whether AI makes you more productive or not becomes a lot more nuance because yes there is some productivity to be gained but also a price to be paid. You know it might be a much more personal question of whether AI makes you more productive or not because that price to pay may be perceived very differently from person to person. And by the way there are so many more details to this study. Um there's a very accessible talk uh by one of the researchers if you want to learn more. Um there's a link in the description. Interestingly, there was another study published by Entropic a couple of months ago where they looked into how AI impacts the formation of coding skills and their conclusion and this is Entropic by the way uh the creator of Claude. Their conclusion was that they found a statistically significant decrease in mastery because of AI assistance. Isn't that interesting? Again, the the link will be in the description. Now, another interesting uh takeaway from that same Stanford study was how productivity gains differed uh based on a kind of project. My biggest gripe with AI demos is that uh they always look so fancy in in hello world apps. Uh but what about real life? You know, I spend my fair share of time in in legacy code bases and I can tell you there's a very big difference between green field and brownfield projects. And this is exactly what these researchers also looked into. They found that the potential gains from AI heavily depended on the stage a project was in as well as the complexity of the task. I mentioned that that one of my project is this new PHP framework, right? Which could be considered green field although it's already more than 3 years old. Um, but at the same time, most tasks are pretty complex. It's a framework. There's more lower level code, and I find that AI only rarely helps. However, it still introduces that additional overhead, that that orange bar you had to deal with. On top of that, I notice how external contributors make use of AI to send pull requests. And almost always there is so much cleanup work to be done which means it's often just easier to start from scratch than for me to be an LLM code reviewer. At the same time there are areas where AI gives you a measurable productivity boost and ignoring that would be foolish because I also use an IDE instead of a text editor. There is a reason for that. I'll circle back to these thoughts but there's another insight I want to highlight as well. Um the hype the bubble. You know, I have people asking me whether I think it's still worth becoming a programmer these days. I've had someone reach out to me saying she isn't getting a promotion, which she was entitled to. Um, she's doing a perfect job. The only thing missing is that she's not using enough AI, which upper management had set as a hard requirement for career growth. Now, collectively, we've created such a hype around AI that to me seems very disconnected from reality. There are a couple of things to note about that. The first thing is that you should realize that many AI drivers are also selling a product. They benefit financially from the hype. Just keep that in mind. Also, it's part of the Silicon Valley way, right? Throw enough money at enough projects and 99% will fail, but the 1% that sticks might be a golden ticket. I think it's good to be aware of this. It makes you think a bit more rationally about all of this. And for me, it helps tone down the hype. Okay. So, I I mentioned three points already, three realizations I made. Um, and I'll come back to these in a minute. But there is one more thing to highlight and that's the question of sustainability because here's the reality. AI is running into limitations. There are hardware shortages both for training and running models. Electricity costs are through the roof. And if both of these aren't enough, there are some serious economic concerns as well with those handful of companies, you know, investing in each other. All that to say is that it might not scale the way we like it to long term. Now, I don't want to go into the depths of of stock markets and VC funding. I'm not eloquent enough on the topic, but I can point you towards some interesting resources to read if you want to. I have to warn you, it's it's pretty heavy reading, so you need to spend a couple of hours on it. I think it's worth digging into, so I'll share those in the description as well. The point I want to make today is that the rise of AI panicked me initially. Um, I was reminded of of my very first years as a programmer. Uh, the struggles I had to deal with, the balance I had to find between my desire for puzzle solving and a company's needs. I felt threatened by AI because I fear that that part of coding I enjoyed the most that it would be gone entirely. But it turned out to be the biggest growing opportunity I had in years because I thought back of how I dealt with those earlier struggles and I knew I eventually made it out a better person, a better programmer. And so I decided to not feel intimidated by AI, but to understand it to even leverage it to some extent where it serves me instead of the other way around. I spent time and effort trying to understand the bubble and hype effect. And I wanted to get a more nuanced view on the matter. I learned that it's not as simple a story as people make it out to be. Whether you're a pro or con, there are side notes to be made. And that knowledge, that understanding, it gave me a lot of peace. I'm certain that AI will have some sort of lasting impact on our industry. But I'm also certain that it's not here to replace us. There are just too many side notes. As professional developers, we'll have to learn and understand this new tool. But we also shouldn't feel ashamed of guarding our passion because both sides bring value to the table. So if you feel intimidated by AI, um I hope you might find some peace in knowing that it's not extreme as you may fear. And if you're completely sold on AI, I hope you've got some things to think about to further sharpen your vision. Because the question isn't about whether AI will change programming. It's about what we choose to do with that change. I'll see you in the next one. Bye-bye., AI Struggles: A Developer’s Story, Brent Roose (PHP Annotated), 01m1h1fph4xvfga6kd5ekmkmzg.