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 > <!-- deep-read:sections start --> ## 🧭 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 vendor found a cost of its own product. He doesn't give the effect size or design. **Brownfield, complexity, and the reviewer's burden.** The most concrete section. Two claims from experience: on a complex, lower-level codebase AI "only rarely helps" but still imposes rework overhead; and AI-assisted external contributions shift labor onto the maintainer. The phrase "LLM code reviewer" names a role many open-source maintainers now hold involuntarily. He immediately balances it: ignoring measurable gains "would be foolish because I also use an IDE instead of a text editor" — the analogy is that AI is tooling, and tooling adoption is normal. **Hype and incentives.** Two mechanisms: sellers benefit from hype, and Silicon Valley's portfolio logic ("99% will fail, but the 1% that sticks might be a golden ticket") means loud bets are rational for investors regardless of the tool's merit. The promotion anecdote is the emotional center of this section — AI usage as a management KPI decoupled from output. **Sustainability.** He disclaims expertise ("I'm not eloquent enough on the topic") and points to unnamed reading. The three named constraints are hardware, electricity, and circular investment. This is the thinnest section and he says so. **The resolution.** Not a synthesis but a stance: understand it, use it "where it serves me instead of the other way around," accept that "both sides bring value to the table." Addressed to two audiences in turn — the intimidated ("it's not as extreme as you may fear") and the sold ("some things to think about to further sharpen your vision"). ## 🗒️ Notes - **The strongest line for Courtney's practice** is "it's often just easier to start from scratch than for me to be an LLM code reviewer." Her CLAUDE.md already treats review as the binding constraint ("Verify delegated work… Delegated claims are advisory"; "A finding is a claim until something runs"). This talk is a maintainer saying the same thing from the receiving end of AI-assisted PRs. Relevant to Outpost, post-kinds, and every repo she maintains that accepts external contributions. - **The Stanford study's "orange bar" is the rework cost her credit-routing model already prices.** Her policy routes mechanical work to cheaper executors and reserves the expensive model for review. The study, as described, says the rework fraction is where apparent gains leak. Same mechanism, independent source. - **"Not enough AI usage" as a promotion blocker** is a governance failure worth a line in anything she writes about AI policy for teams: measuring tool usage instead of output inverts the incentive the Stanford result warns about. - **The WordPress aside.** "We can laugh about WordPress" — spoken by a PHP-framework author to a PHP audience, as an accepted premise. Not the talk's point, but a data point on how the broader PHP community frames WordPress work in 2026. Worth knowing when she speaks at PHP events (Longhorn PHP is in this same batch). - **What the talk doesn't do.** No demo, no tool comparison, no methodology for "where AI serves me." The four findings are all reasons for caution; the balancing statements ("ignoring that would be foolish") have no specifics behind them. For a talk that criticizes hello-world demos, it offers no counter-example of AI working well on his own brownfield code. - **Vendor position.** A JetBrains employee on a JetBrains channel not mentioning JetBrains AI products is either editorial independence or product-agnostic marketing (an IDE vendor benefits from "use tooling, but stay a developer"). The talk's content is consistent with both readings. - **Numbers are the speaker's recollection of two studies.** 100,000 / 600 / 80% / 3 years for Stanford; "statistically significant decrease in mastery" for Anthropic. Neither is linked in the capture. Verify before citing. ## 📚 References - Roose, B. (inferred). *AI Struggles: A Developer's Story*, PHP Annotated (JetBrains), YouTube, 2026-09-02, 18:49. - Stanford developer-productivity study as described: 100,000 developers, 600 companies, 80% private codebases, commits back up to 3 years; output gain partly offset by rework of AI-generated code; gains vary by project stage and task complexity. Not linked in capture; likely the Denisov-Blanch research program. Unverified. - Anthropic study on AI assistance and coding-skill formation as described: "statistically significant decrease in mastery." Not linked in capture. Unverified. - Cross-reference: Courtney's CLAUDE.md credit-routing section (review as the binding constraint; delegated claims advisory). - Cross-reference: the Fable 5.1 prompting docs deep-read (same batch) — vendor guidance on keeping AI changes scoped, the supply side of the "LLM code reviewer" problem. ## 🗣️ Paraphrase I've programmed for 17 years and for the first time I feel old — not because of age but because a new kind of programmer showed up who doesn't need to enjoy code, just results. That scared me. Then I remembered I'd felt this before: as a junior, I loved puzzles and hated that real jobs had few of them, and I had to grow up and find the balance. So I did the same with AI — talked to both camps and read the research. What I found: AI does raise output, but a big slice of that is rework of what it wrote, so the net is real but personal. It helps a lot less on complex, older code than on demos. Much of the hype comes from people selling something, and some managers now measure AI usage instead of results. And it may not scale — hardware, power, and money are all constrained. My conclusion: it will change the industry, it won't replace us, learn the tool, use it where it serves you, and don't apologize for still loving the work. ## 📰 Newsletter **A PHP advocate's AI reckoning, in numbers he borrowed.** JetBrains's PHP Annotated host spends twelve minutes on his own career — a maze generator for a World of Warcraft server, a code review that opened with "do you always use one return statement per function?", a two-day WordPress agency job — to set up one claim: the AI shock is the junior-developer shock again, the gap between loving code and doing the job. His evidence is a Stanford study of 100,000 developers at 600 companies (as he describes it — no links survive in the transcript) that found output up after AI adoption but with a large rework slice, plus an Anthropic study finding "a statistically significant decrease in mastery" from AI assistance. From his own framework work: AI "only rarely helps" on complex, low-level code, and 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." He names the incentive problem — a developer denied a promotion for insufficient AI use — and the sustainability problem, then lands on a stance rather than a method: understand it, use it where it measurably helps, and guard your motivation without shame. Honest about its own gaps; no demo of AI working well on his code, and every number is secondhand. ## ✅ Action Items **DevRel** - The talk structure — twelve minutes of personal history to earn a four-point argument — is a model for advocacy talks on contested topics: build trust before the claims. Steal the shape, not the length. `#action/h3` - "LLM code reviewer" is a phrase maintainers will recognize; use it when writing about contribution guidelines for AI-assisted PRs. `#action/h2` **OSPO** - The maintainer-burden claim (AI-assisted PRs cheaper to redo than review) is a direct input to contribution policy: require contributors to disclose AI assistance and to run the project's review checklist themselves before opening a PR. `#action/h2` - The promotion anecdote is a policy anti-pattern: never make tool usage a career KPI. `#action/h3` **Community** - The talk's "two audiences" close — one message for the intimidated, one for the sold — is a template for community discussions about AI that keep both camps in the room. `#action/h3` **WordPress teams** (Core, Core Performance, Core AI, Core Program Team, Mobile, Playground, Community, Training, Marketing, Support, Design, Documentation, Photos, TV, Polyglots, Accessibility, Meta, CLI, Hosting, Tide, Openverse, Themes, Plugins) - **Core / Core AI:** the brownfield finding applies to WordPress Core more than to almost any codebase in PHP — 20+ years old, backward-compatibility-bound. Any Core AI-tooling claim should be evaluated on Core, not on a demo. `#action/h2` - **Core Program Team / Plugins:** the "LLM code reviewer" burden is arriving in Trac and the plugin review queue. A contribution-guideline line on AI-assisted patches is due. `#action/h2` - **Training / Marketing:** the "we can laugh about WordPress" aside is how a PHP-framework author addresses a PHP audience in 2026. Worth knowing when positioning WordPress to PHP developers. `#action/h3` - All other teams: not applicable to this source. **The WPOCC** - Not applicable to this source. **FAIR** - Not applicable to this source. **Personal (Courtney)** - **Find and read the two studies** before citing any number from this talk. Search the video description for the Stanford talk and the Anthropic skill-formation paper; log both as deep-read candidates. `#action/h1` - **Compare the "orange bar" to your credit-routing rationale.** If the study's rework fraction is available, it's an external number for the review-is-the-bottleneck claim your routing policy rests on. `#action/h2` - **Add an AI-assisted-contribution line to your plugin repos' CONTRIBUTING** (Outpost, post-kinds, Social Webmention Importer): disclose AI use, run the review checklist before opening the PR. This talk is the citation for why. `#action/h2` - **Longhorn PHP prep:** note the PHP-community framing of WordPress before speaking or attending. `#action/h3` ## 🧪 Hypotheses - **H-A:** The rework fraction in the Stanford data is larger on older, larger codebases than on new ones, which would make WordPress Core among the worst cases for net AI productivity gain. *Testable if the study's per-project breakdown is public.* - **H-B:** Repos that add an AI-disclosure line to CONTRIBUTING see fewer closed-without-merge AI-assisted PRs within six months, because contributors self-filter. *Testable on Courtney's own repos.* - **H-C:** The talk's four findings will age asymmetrically: the sustainability section fastest (it's a market snapshot), the brownfield section slowest (it's about codebase structure). *Check in a year.* - **H-D:** A JetBrains-channel talk that never names a JetBrains AI product performs better with skeptical PHP developers than one that does. *Untestable from here; note as a DevRel pattern.* ### 📊 Methodology Personal narrative plus two secondhand studies plus two anecdotes. The narrative is the evidence for the frame (AI shock = junior shock), and it's unfalsifiable by design — it's one person's arc. The studies are described with methodological detail (sample, sources, independence) but no links survive the capture and no effect sizes are given beyond "a big chunk" and "statistically significant." The promotion anecdote is n=1 and secondhand. The brownfield claim is first-person experience on one framework. The right treatment: accept the frame as a rhetorical device, verify the two studies before citing, and treat the maintainer-burden claim as a credible practitioner report consistent with other maintainers' accounts. ### ❓ Questions - What is the rework fraction in the Stanford data, and does it vary by codebase age and size the way the speaker implies? - What was the Anthropic study's design — who were the learners, what was "mastery," how large was the effect? - Where does AI measurably help on the speaker's own framework? He says such areas exist and gives none. - Is the "different generation by mindset" real or a framing? Developers who "just want to get to an end result" existed before AI; what changed is the tooling, not the type. - How many of the AI-assisted external PRs he redoes would have been redone anyway as junior contributions? - Does JetBrains have editorial guidance for PHP Annotated on discussing AI, given Junie and AI Assistant? ### 🔮 Future Research - Locate and deep-read both cited studies; compare the Stanford rework result to Courtney's credit-routing assumptions. - Survey WordPress plugin maintainers on AI-assisted PR burden; compare to the speaker's "easier to start from scratch" claim. - Track whether PHP-community talks in 2026–27 shift from "AI struggles" to "AI methods" — the speaker promises to "circle back" to where AI helps and doesn't. - Pair with the Fable 5.1 prompting docs: the vendor's "keep changes to what the task asks for" instruction is the supply-side fix for the maintainer-burden problem this talk describes from the demand side. ### 💡 Implications **For maintainers.** Review, not generation, is the cost center. If AI-assisted PRs are cheaper to rewrite than review, contribution policy has to move review labor back to the contributor — disclosure, checklists, smaller PRs. **For managers.** Tool usage as a KPI measures the wrong thing. The Stanford result, as described, says apparent output overstates real output by the rework fraction; a manager rewarding AI usage is rewarding the overstatement. **For developers who love the work.** The talk's permission structure matters: "we also shouldn't feel ashamed of guarding our passion." That's a mental-health message wrapped in a productivity talk, and it's the reason the twelve minutes of autobiography are there. **For WordPress.** A 20-year-old, compatibility-bound codebase is the brownfield case the speaker says AI helps least. Core AI claims should be benchmarked on Core. ## 🧠 Learning Styles Assessment **Auditory / narrative** — the primary mode. A single speaker telling a chronological story, no co-host, conversational register with self-corrections ("maybe I should say 16 years"). **Visual** — slides referenced but not captured: a screenshot of the WoW obstacle course, output charts with "that orange bar." The transcript alone loses the chart, which is the talk's main piece of evidence. **Read/write** — weakly served; the promised links live in the description, not the talk. **Kinesthetic** — not served; no exercises, no demo. **Reflective** — strongly served; the whole talk is a model of reflection and it closes by asking both camps to reflect. **Global** — the four findings are announced and recapped ("I mentioned three points already… one more thing"), which helps global learners; sequential learners get the chronology. **Overall:** a reflective narrative talk. Best consumed as audio with the slides; the transcript loses the evidence chart. ## 📊 Accessibility Assessment Assessment of the captured auto-transcript, not of the YouTube page or slides. #### Alternative text and non-text content Two visuals are referenced ("this is the only screenshot," "this would be the output… that orange part") and neither is described in enough detail for a non-sighted listener to reconstruct the chart. The speaker says what the orange bar means but not its size. #### Keyboard navigation Not applicable; YouTube player controls. #### Contrast and readability Not assessable from transcript. #### Text resizing and reflow Not applicable. #### Media and captions Auto-generated captions only (ASR errors: Symphfony, CRUT, Entropic, PHP Storm, 3mon). No human-corrected captions in the capture. Speech is clear, single speaker, moderate pace — favorable for ASR, which makes the remaining errors mostly proper nouns. #### Forms and interactions None. #### Standards reference WCAG 2.2 AA mapping: 1.2.2 Captions (Prerecorded) — auto-captions present but uncorrected; 1.2.3 / 1.2.5 Audio Description — chart content not described in audio sufficiently; 1.1.1 Non-text Content — slide screenshot not described. Nothing can be marked pass/fail from the transcript alone. ## 🌍 DEIB Assessment #### Cultural breadth Western European developer's career (Belgian PHP scene inferred from biography; not stated). References — dialup, private WoW servers, PHP agencies — assume a 2000s-2010s European/North American developer background. #### Inclusive language Neutral. The one gendered reference is the promotion anecdote ("she isn't getting a promotion"), used respectfully. "Vibe coders" and "skeptics" are named as sides without contempt for either. #### Neurodiversity support The talk's central theme — needing puzzle-solving to stay engaged, boredom as a career risk — will resonate with developers who need intrinsic challenge to sustain attention. The speaker frames it as a legitimate need, not a flaw. Long unbroken narrative with no section markers is harder for listeners who need structure. #### Representation A single senior white-collar European male voice (inferred) speaking for "developers." The anecdote about the woman denied promotion is the only other person given a story, and she isn't named or quoted directly. #### Psychological safety High. The speaker models admitting fear ("my first reaction was panic"), admitting past mistakes (the CRUD controller, the illegal server, quitting after two days), and grants permission to "guard our passion" without shame. Both camps are addressed without ridicule. ## ✅ Logical Validity **Central analogy — AI shock ≈ junior-developer shock.** Valid as a frame, not as an argument. Both are experiences of the gap between intrinsic motivation and job demands; the resolution in the first (find a role with enough puzzles) doesn't automatically transfer to the second (the tool changes what "the job" is). The speaker doesn't claim it transfers; he claims the *process* transfers — understand, adapt, keep what matters. That weaker claim holds. **Productivity claim.** "Yes there is some productivity to be gained but also a price to be paid" — supported by the described study, if the description is accurate. The move to "a much more personal question" is his inference and is marked as such. **Brownfield claim.** First-person experience generalized with a hedge ("I find that AI only rarely helps"). Consistent with the study's stage/complexity finding as he describes it. Not overclaimed. **Hype claim.** Two mechanisms (seller incentive, portfolio logic) are real and don't depend on any particular AI product being bad. The promotion anecdote illustrates the consequence; n=1. **Sustainability claim.** Asserted with disclaimed expertise. Weakest section; the speaker says so. **Fallacies.** None structural. Mild appeal to authority in "this is Anthropic by the way, the creator of Claude" — a vendor admitting a cost is more credible, but it's still one study with no design given. The balancing statements ("ignoring that would be foolish") are unsupported assertions on the pro-AI side, which means the talk is more evidenced against than for — a mild asymmetry the speaker doesn't acknowledge. **Verdict.** Honest, hedged, evidenced where it can be, and clear about where it can't. The frame is rhetorical; the findings are secondhand; the maintainer-burden claim is the one piece of primary evidence and it's credible. ## 🛡️ DARVO Analysis Not applicable to this source. No accusation, no victim/offender reversal. The nearest structural feature is the opposite: the speaker takes ownership of his own panic, his own past mistakes, and his own initial dismissal of the "different generation," and criticizes systems (hype incentives, usage-as-KPI) rather than people. The promotion anecdote names "upper management" as the actor without reversing blame onto the developer. ## 🎯 Conclusion A personal talk that earns a modest argument: the AI disruption feels like the first years of a programming career, when you learn that loving code and doing the job are different things, and it's survivable the same way. The evidence is two studies described from memory — a Stanford analysis of 100,000 developers showing real but rework-discounted gains, and an Anthropic finding of decreased mastery — plus one credible first-person claim: on complex brownfield code, AI-assisted external PRs are often cheaper to rewrite than to review. That last claim is the one Courtney's practice already encodes (review is the bottleneck; delegated claims are advisory) and the one that should drive a concrete change — an AI-disclosure line in her repos' contribution guidelines. Verify both studies before citing any number. Note the WordPress aside for Longhorn PHP. And take the talk's permission at face value: guarding the part of the work you love isn't a productivity failure. ## 🔄 Refactor Appendix — AI Struggles: A Developer's Story ### 📚 Literature Atoms (H3) #### [H1] On complex brownfield code, AI-assisted PRs are often cheaper to rewrite than to review > [!quote] ID:rw_01m1h1fph4xvfga6kd5ekmkmzg > "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." A maintainer naming the labor shift: generation moved to the contributor's tool, review stayed with the maintainer. The primary evidence in the talk. Tags: `#atom/literature/h1` #### [H2] Apparent AI productivity gains include a rework fraction that makes the net gain personal > [!quote] ID:rw_01m1h1fph4xvfga6kd5ekmkmzg > "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." The speaker's inference from the Stanford "orange bar." The study (as described) supplies the fraction; he supplies the "personal" reading. Tags: `#atom/literature/h2` #### [H3] The new divide is by mindset, not age: programmers who don't need joy from code itself > [!quote] ID:rw_01m1h1fph4xvfga6kd5ekmkmzg > "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" The talk's thesis statement of the shock. "As little tokens as possible" dates it precisely. Tags: `#atom/literature/h3` #### [H4] Hype has a seller and a portfolio logic behind it > [!quote] ID:rw_01m1h1fph4xvfga6kd5ekmkmzg > "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." Two incentive mechanisms that hold regardless of whether any given tool works. Tags: `#atom/literature/h4` #### [H5] Measuring AI usage instead of output inverts the incentive > [!quote] ID:rw_01m1h1fph4xvfga6kd5ekmkmzg > "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." n=1, secondhand, and the clearest illustration of the KPI failure in the talk. Tags: `#atom/literature/h5` ### 🧠 Permanent Candidates (H4) #### [P1] AI shifts contribution labor from generation to review, and review stays with the maintainer When contributors generate with a tool, the cost of a PR moves from writing it to reviewing it, and the reviewer didn't get the tool's speedup. Past a threshold of cleanup, the rational maintainer response is to rewrite rather than review — which means the contribution produced negative value. Policy fixes push review labor back to the contributor: disclose AI use, run the checklist, keep PRs small. *Candidate; converges with Courtney's own "review is the binding constraint" routing rule from an independent source, and applies directly to her plugin repos.* Links: [[Review Is the Binding Constraint When Generation Is Cheap]] · [[Credit Routing Policy]] · [[Contribution Guidelines for AI-Assisted PRs]] · [[Open Source Maintenance MOC]] Tags: `#atom/zettel/z1` #### [P2] Rewarding tool usage rewards the overstatement of output If measured output includes a rework fraction, a KPI on tool adoption rewards exactly the portion of output that isn't real. Output-based measures (merged, surviving code) don't have this problem; usage-based ones do. *Candidate; the mechanism is general to any tool with a rework cost, and the talk supplies a concrete case.* Links: [[Goodhart Effects in Engineering Metrics]] · [[AI Policy for Engineering Teams]] Tags: `#atom/zettel/z2` ### ✏️ Fleeting Queue - Find the Stanford talk (100k devs / 600 companies) and the Anthropic skill-formation study; the video description has the links the capture lost. `#atom/fleeting/f1` - "We can laugh about WordPress" — PHP-community framing, spoken as shared premise. Note for Longhorn PHP. `#atom/fleeting/f1` - The speaker promises to "circle back" to where AI does help; the talk never does. Watch for a follow-up. `#atom/fleeting/f1` - Speaker identity is inferred from biography (JetBrains, framework >3 years old, ~5 years at an open-source-profitable company). Confirm from the video page. `#atom/fleeting/f1` ### → Things 3 (max 2 actions) 1. **Add an AI-assisted-contribution line to CONTRIBUTING** in Outpost, post-kinds, and Social Webmention Importer — disclose AI use, run the review checklist before opening the PR. `#action/h2` 2. **Pull the two cited studies from the video description** and log them as deep-read candidates. `#action/h1` <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/AI Struggles A Developer’s Story.md|AI Struggles: A Developer’s Story by Brent Roose (PHP Annotated)]] ## Highlights - 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 ([View Highlight](https://read.readwise.io/read/01m1h22ykdw5kgttwnyq6ngy96)) - Note: The thesis of the shock: a "generation by mindset" that doesn't need joy from code and optimizes for "as little tokens as possible." The talk's pivot from career autobiography to AI; the rest maps the junior-developer lesson (loving code ≠ doing the job) onto it. #atom/literature/h3 - Tags: atom/literature/h3 - 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 ([View Highlight](https://read.readwise.io/read/01m1h22eves8jzt0sahh6s1kcb)) - Note: The "orange bar": the Stanford study (100k developers, 600 companies, as he describes it — not linked in capture) shows output rising after AI adoption, but a large slice is rework of AI-generated code. Net gain is real; the price is real; whether it's worth it is personal. Same mechanism Courtney's credit-routing model prices. #atom/literature/h2 - Tags: atom/literature/h2 - 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 ([View Highlight](https://read.readwise.io/read/01m1h21xr2dmfex2v3p8zjak2g)) - Note: Maintainer's view of AI-assisted external PRs: cheaper to rewrite than to review. Generation moved to the contributor's tool; review stayed with the maintainer. The talk's one piece of primary evidence, and the claim Courtney's "review is the binding constraint" routing rule already encodes. #atom/literature/h1 - Tags: atom/literature/h1 - 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 ([View Highlight](https://read.readwise.io/read/01m1h23j33m7pd1hsb2dgqcctk)) - Note: Two incentive mechanisms behind the hype — sellers profit from it, and portfolio logic (99% fail, 1% golden ticket) makes loud bets rational regardless of the tool's merit. Preceded by the anecdote of a developer denied promotion for "not using enough AI." Spoken by a JetBrains employee who names no JetBrains AI product. #atom/literature/h4 - Tags: atom/literature/h4