Stack Overflow Survey Reactions | Software Engineering & Career Insights  🔗 **Source:** [Stack Overflow Survey Reactions | Software Engineering & Career Insights](https://www.youtube.com/watch?v=GogxA6pFiT8) > [!note]+ Document Notes > tags: [stack-overflow-survey, ai-developer-tools, developer-job-satisfaction, vibe-coding, software-community] > author: Overcommitted > source: Overcommitted (YouTube) > reference: https://www.youtube.com/watch?v=GogxA6pFiT8 > date created: 2026-10-14 08:48 > > > [!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. > > # 🏷️ Title: Stack Overflow Survey Reactions | Software Engineering & Career Insights > <!-- 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) - [🔄 Refactor appendix](#-refactor-appendix--stack-overflow-survey-reactions--software-engineering--career-insights) ## 📝 Summary - **What happened.** The Overcommitted podcast published a 49:15 episode on 2026-10-13 in which three hosts (the transcript names Bethany as host, plus Britney and Erica; the description lists more hosts) react to the 2026 Stack Overflow developer survey, section by section: work, AI, knowledge and development practices, technology, and community. The hosts say they met "working on a team at GitHub" (00:00:01). The captions don't label who speaks each line, so this analysis attributes views to "a host" unless a name is spoken. - **The claim.** The hosts read the survey as showing that AI use jumped (they cite 31% last year to 87% this year, 00:19:39), that self-employment rose from 4% to 10% (00:03:36), that most respondents are complacent or unhappy at work (22% happy, 33% not happy, 00:14:28), and that Stack Overflow's remaining value is community (00:43:56). Their own through-lines are: AI-written communication reads as offensive, source attribution is the trust mechanism, code was never the hard part, and humans in the loop still matter. - **Why it matters.** The hosts are working engineers describing how survey numbers match daily practice: team-versus-solo tradeoffs, vibe-coded apps, token cost pressure, spec bloat, and the "SaaS apocalypse" that the survey says isn't happening (00:34:28). That is practitioner color a table of percentages doesn't carry. - **Key stakeholders.** Stack Overflow (survey author), the Overcommitted hosts and their Discord community, developers using AI harnesses, managers deciding team size, and AI vendors whose defaults the hosts distrust (00:25:37, 00:33:01). - **Risks and tradeoffs.** Every survey number in this episode is spoken from the hosts' reading of the survey page, not shown or linked in the transcript. The description links https://survey.stackoverflow.co/2026, but this analysis made no network calls, so none of the figures is verified here. Numbers the hosts raise that clearly aren't from the survey (the "9%" React figure at 00:38:09, the "five hour limits" at 00:25:37) are flagged unsourced below. - **Bottom line.** The episode is opinion anchored to a survey. Its strongest content is the practitioner reasoning (why internal tooling still gets bought, why source attribution matters, why a language-popularity list mixes unlike things). Its weakest is the causal storytelling around unexplained numbers, which the hosts mostly label as speculation themselves. ## 📖 Main content **Format and framing.** Bethany opens by saying the survey "revolved around AI" and proposes walking each survey section for takes and stats that stood out (00:00:43). The structure of the episode follows the survey's own tabs: Work, AI, Knowledge (development practices), Technology, Community. **Work.** The hosts open on the survey's work-section headline and notice two things: self-employment moved from 4% to 10% "in this year alone" per one host (00:03:36), and roughly 45% of respondents land in a "complacent" bucket (the transcript says "almost half", 00:14:28), with 22% happy and 33% not happy. One host checked earlier years and found happiness "pretty much around the same" (00:01:26), so the shift is smaller than the survey page's framing suggests. They offer causes for self-employment (long-held ambitions plus AI tooling, layoffs, escape from corporate politics) and agree the survey can't say which, because respondents weren't asked why (00:02:53). **Solo versus team.** A host argues work is now faster alone, not easier, because one person can take a big chunk of work end to end, and merge conflicts disappear (00:04:19 to 00:06:29). Another host counters that scale and lifetime matter: internal tools are fine solo, but anything with a pager rotation or a multi-month scope needs shared context (00:07:12). The Mythical Man-Month is invoked from memory as evidence that adding people doesn't speed work proportionally (00:06:29). **Vibe coding and quality.** One host built a gift-list app twice, three months apart: the first attempt looked clearly AI-made, the second took 2 days and looked professional (00:08:41). That prompts a quality question: if more people build alone, does overall software quality drop, and do users need a signal like the SSL lock for "built with AI" or "uses a third-party payment handler" (00:10:11)? The same host calls 4% to 10% "extrapolating way too far" as evidence for a landscape shift. Others respond that bad software has always existed (apps forced on cruise passengers, gyms) and that AI may improve defaults, especially security prompts (00:11:38, 00:12:20). The group converges on a practical habit: be more careful about unfamiliar brands asking for payment details (00:13:02). **AI section.** The cited adoption jump is 31% to 87%, with 13% not using AI at all (00:19:39). Hosts note the survey separates AI for technical generation from AI for communication, and that respondents are uneasy about the latter. Two hosts describe the cost of reading AI-written messages: "this is not written for a human" (00:20:25), "an ick for delivering something" AI-written as their own (00:21:54), and the social norm forming around sending unverified AI output, which one host calls being "a meat proxy" (00:23:21). Source attribution surfaces as the survey's top trust item, and the hosts add their own practice of asking the model to show its work (00:24:06). **Harness defaults and tokens.** The hosts link a video from "Ed" who makes what the captions render as "Poly Token" (the description gives Polytoken). Their summary of it: harnesses use dark patterns such as five-hour limits to keep people at the keyboard, and defaults become the behavior of the average user (00:25:37). The hosts also discuss "token maxing" and a reversal from "use all the AI" to "hit the brakes" as subsidies shrink (00:27:46, 00:28:32). A host's speculation that vendors profit from bloated specs is explicitly labeled "my tinfoil hat brain" (00:33:01); another host asks whether bloat comes from the model or the harness and nobody has data. **Knowledge section.** The top context sources, as the hosts report them, are project goals and requirements (85%) and code repositories or technical documentation (73%) (00:29:18). Hosts connect this to AI-generated specs and issues: if a spec is unvetted, you can't tell whether it answers a customer problem. "Less is more" and spec-driven development (a Bluesky CTO's view, per a host) get airtime (00:31:36 to 00:32:19). **SaaS apocalypse.** The survey respondents don't expect SaaS to vanish. The hosts agree with what they describe as the survey authors' conclusion: buyers still purchase internal tooling because building means owning maintenance and tech debt (00:34:28). A host adds that code was never the hard part, with Redis and Linux as examples of things people don't self-build (00:35:56). A host suspects the fear originated with business people, not engineers (00:36:39). **Technology.** JavaScript tops the list, then SQL, with Python high; Ruby, Go and Rust are absent (00:37:22, 00:38:09). The hosts criticize the list design: browser languages, a query language, and shells aren't comparable categories, and "what is Python used for" is the interesting slice (00:40:18). A host observes language-specific conferences (React Summit, GopherCon) are now dominated by AI talks, so the technology choice matters less (00:41:01). The "9% of the internet is React" figure (00:38:09) is a half-remembered saying, not a survey number. **Community.** The hosts note Stack Overflow's survey leaned into its own community role and was candid about its decline, and that people still say they "Google" things, though a search now returns an AI overview (00:43:13). Two hosts say Stack Overflow never felt welcoming to ask on, citing fear of "duplicate question" responses (00:44:39). A host cites 70% of people asking an agent a question and argues human conversation still wins for networking, different viewpoints, and sustainable learning even when an agent can answer faster (00:46:05 to 00:47:34). The episode closes with a plug for the Overcommitted Discord. **Contested or unverified.** Whether the 87% figure and the "four hours a day" claim describe the same population is unclear from speech alone (00:18:56). The complacency number is described as headline-only on the survey page with no explanation (00:15:58). The 4% to 10% self-employment change is the hosts' reading of the survey, and one host warns against extrapolating from it. ## 🗒️ Notes #### ⏱️ [00:00:01](https://www.youtube.com/watch?v=GogxA6pFiT8&t=1) Intro and episode format - Bethany hosts with Britney and Erica; the hosts say they met on a team at GitHub and started the podcast to share what they learned. - Topic: reactions to the Stack Overflow developer survey. Stated focus: AI and its effect on job satisfaction and language choice. - Plan: walk the survey sections in order and discuss stand-out stats. #### ⏱️ [00:01:26](https://www.youtube.com/watch?v=GogxA6pFiT8&t=86) Work: complacency and the self-employment jump - A host asks whether the survey's "it ain't what it used to be" work opener is new or boilerplate, and checked earlier years: happiness and complacency look flat, bouncing up and down. - Candidate reasons for more self-employment: long-held ambitions unlocked by AI, layoffs, or escaping corporate environments. The hosts concede the survey likely can't show causes. > [!quote] [00:03:36] > the number of people that are working for themselves increased from 4% to 10% - A host proposes cross-referencing self-employed respondents against AI usage to test the AI-enabled-independence theory (00:04:19). #### ⏱️ [00:05:03](https://www.youtube.com/watch?v=GogxA6pFiT8&t=303) Solo work versus teams - One host's theory: AI makes it faster to take a big chunk of work alone, with fewer merge conflicts; another says working alone was always easier because all context lives in one head. - The Mythical Man-Month comes up as the known limit on adding people (00:06:29). - Counterpoint at 00:07:12: internal, single-owner tooling suits solo work; anything with a pager, multiple maintainers, or a multi-month scope needs delegation and shared context. - The hosts agree on the appeal of flow state when nobody has to review (00:07:59). #### ⏱️ [00:08:41](https://www.youtube.com/watch?v=GogxA6pFiT8&t=521) Vibe coding and software quality - A host rebuilt a gift-list app after 3 months: the second attempt took 2 days and looked far more professional than the first. - Question raised at 00:09:25: if people truly vibe-code their dreams alone, does general software quality fall, and how would a user know? - The same host calls reading 4% to 10% as a landscape shift "extrapolating way too far" (00:10:11) and floats a quality-signal idea like SSL lock icons or an AI-generated tag. - Rebuttal at 00:11:38: > [!quote] [00:11:38] > I feel like there's always been bad software. - A host adds that if AI-assisted software isn't improving continuously, the builder is "probably not doing it right," citing AI prompts for security additions (00:12:20). #### ⏱️ [00:13:02](https://www.youtube.com/watch?v=GogxA6pFiT8&t=782) Trust in unfamiliar vendors - Hosts now ask whether an unfamiliar brand is a company or one person before handing over payment credentials, and whether to build the thing themselves instead. - A side thread at 00:13:46 names a toy-related AI product concern. The captions garble the names ("Muse", "liaboo"; likely a product and Labubu), so the specifics are unreliable. - Agreement that polished, clean sites now trigger "what's the catch" and "how are you making your money." #### ⏱️ [00:14:28](https://www.youtube.com/watch?v=GogxA6pFiT8&t=868) Job satisfaction: complacent, unhappy, happy - The stat: almost half complacent, with the happy bucket smallest. > [!quote] [00:14:28] > 22% were happy and 33% were not happy - One host frames it NPS-style (8 of 10 and up counts as good) and wants a comparison against other industries (00:15:14). - The hosts note the survey page headlines complacency but the Work tab doesn't explain it (00:15:58). - Work-to-live cohorts are valid, and loving your work is called a privilege (00:16:42). Hosts acknowledge their own bias: they run a podcast about their work (00:17:27). - Unhappiness may come from politics and strategy churn, not the craft, and that could also feed self-employment (00:17:27). #### ⏱️ [00:18:10](https://www.youtube.com/watch?v=GogxA6pFiT8&t=1090) AI section: adoption and AI-written communication - Bethany summarizes the AI section: a majority use AI over four hours a day, sentiment is favorable overall, and respondents are uneasy about human communication and creative output (00:18:56). > [!quote] [00:19:39] > the jump from 31% last year using AI to 87% this year - 13% still don't use AI at all; a host wonders whether that's access or choice. - A host had this exact conversation at work: long AI-written replies cost the reader "brain energy" and aren't written for a human (00:20:25 to 00:21:09). - A host uses AI for software development and search but dislikes delivering AI-written text as their own voice; they ask AI to prompt them instead of drafting for them, and complain it keeps drafting anyway (00:21:54, 00:22:38). - Social norms are forming: forwarding unverified model output is "a meat proxy" move (00:23:21). #### ⏱️ [00:24:06](https://www.youtube.com/watch?v=GogxA6pFiT8&t=1446) Source attribution and harness dark patterns - Source attribution is described as a high-importance survey theme; hosts ask models to show their reasoning and numbers. > [!quote] [00:24:53] > I don't trust it unless I know how you got there. - A host links a video by "Ed" (captions: "Poly Token"; description: Polytoken) about harness patterns that read as marketing tactics, citing five-hour limits that pull users back at the reset (00:25:37). - Defaults become the average user's behavior, which a host ties to the spread of Claude-sounding writing (00:26:21). - A host now sends messages with typos on purpose to signal human authorship (00:27:03). #### ⏱️ [00:27:46](https://www.youtube.com/watch?v=GogxA6pFiT8&t=1666) Token maxing and the knowledge section - Behavior change from the survey: respondents monitor or ration tokens. The hosts say "token maxing" is the buzzword and describe companies flipping from rewarding heavy AI use to hitting the brakes as subsidies end (00:28:32). - Knowledge section: top context sources, by the hosts' reading, are project goals and requirements and code repositories or technical documentation. > [!quote] [00:29:18] > project goals and requirements which was 85% - Related worry: AI-generated issues and docs read as authoritative, so reviewers ask whether a human vetted the spec and what customer problem it answers (00:30:05). - A host calls requirements "your success criteria" and says to make them airtight before starting (00:30:52). #### ⏱️ [00:31:36](https://www.youtube.com/watch?v=GogxA6pFiT8&t=1896) Spec-driven development and spec bloat - A host reports a Bluesky CTO's view that specs are the durable artifact and code is ephemeral (00:32:19). - The same host finds AI-generated specs always add extras that must be trimmed, then jokes about a conspiracy. > [!quote] [00:33:01] > this is like my tinfoil hat brain too - The hosts debate whether bloat is a model-level tuning artifact or a harness incentive; nobody cites evidence, and one host says they now distrust AI companies (00:33:44). #### ⏱️ [00:34:28](https://www.youtube.com/watch?v=GogxA6pFiT8&t=2068) The SaaS apocalypse that isn't happening - Per the hosts, respondents don't expect SaaS to disappear; the survey authors' reading is that owning internal tooling brings tech debt that often isn't worth it (00:35:12). - A host's point: code was never the hard part, supporting and scaling it is, with Redis and Linux as examples (00:35:56). - The hosts suspect the "build everything yourself" fear came from non-maintainers, with engineers replying "that's not how it works" (00:36:39). #### ⏱️ [00:37:22](https://www.youtube.com/watch?v=GogxA6pFiT8&t=2242) Opportunity cost and the technology list - A host feels choosier now about what to build because the industry moves faster and opportunity cost rose (00:37:22). - List order: JavaScript, SQL, then Python high; Ruby, Go, and Rust are absent, to the hosts' surprise (00:38:09). - Java, C, and C++ appear; the hosts read that as legacy systems that never got rewritten (00:39:35). - A half-remembered "9% of the internet is React" saying is offered to explain why industry-hyped tech differs from what runs day to day (00:38:52). It isn't a survey figure. #### ⏱️ [00:41:01](https://www.youtube.com/watch?v=GogxA6pFiT8&t=2461) Languages stop being identities - The hosts critique the list: browser languages, SQL, and shells aren't comparable; a front end, back end, query, and scripting split would be more useful (00:40:18). > [!quote] [00:41:01] > the technology you're using doesn't really matter as much anymore - Language-specific conferences (React Summit, GopherCon) are turning into AI conversations; a host recalls GopherCon talks on why Go is best even with AI (00:41:43). - Joke close: choose a language by mascot cuteness (00:42:27). #### ⏱️ [00:43:13](https://www.youtube.com/watch?v=GogxA6pFiT8&t=2593) Community and Stack Overflow's role - The hosts credit the survey for being realistic about Stack Overflow's state, while noting most respondents still say they search online, which now includes AI overviews (00:43:13). - A host: community is the thing Stack Overflow has now (00:43:56). - Two hosts say Stack Overflow never felt welcoming for asking: fear of "duplicate question" replies (00:44:39). - A host wonders whether sibling Stack Exchange communities still flourish or have been "eaten by the AI monster" (00:45:22). #### ⏱️ [00:46:05](https://www.youtube.com/watch?v=GogxA6pFiT8&t=2765) Humans in the loop - A host cites the share of people asking an agent a question as unsurprising, since an agent gives a cheap second opinion. > [!quote] [00:46:05] > 70% of people say that they ask an agent a question - Counter: a bot can't answer everything, and working through a problem with another person builds relationships and a viewpoint an agent lacks (00:46:50, 00:47:34). - A host admits the tradeoff: immediate answers are tempting, human routes are more sustainable. #### ⏱️ [00:48:20](https://www.youtube.com/watch?v=GogxA6pFiT8&t=2900) Close - Plug for the Overcommitted Discord (linked in the bio per the hosts), a call to follow or subscribe, and a mention of Bluesky. - Sign-off at 00:49:02 ("till next week"). ## 📚 References The transcript itself contains no links; the following come from the video description or are primary sources for named entities. - [Stack Overflow Developer Survey 2026](https://survey.stackoverflow.co/2026): the survey the episode reacts to. Not opened for this analysis, so every percentage the hosts cite remains unverified here. - ["Ed from Polytoken" video](https://youtu.be/YrmR6EZ5Y1U): the video the hosts say they'll link in the show notes, about dark patterns in AI harnesses. The captions render the product as "Poly Token"; the description spells it Polytoken. - [Overcommitted](https://overcommitted.dev): the podcast's site, from the description. The hosts also point to their Discord and Bluesky without giving URLs. - *The Mythical Man-Month*, Fred Brooks: invoked at 00:06:29 as the reason adding people doesn't speed delivery proportionally. Named by title only. - GopherCon and React Summit: conferences the hosts attended (00:41:01). No links given. - Redis and Linux: the hosts' examples of software people don't self-build (00:35:56). The captions spell Redis "Reddus." ## 🗣️ Paraphrase The hosts treat the survey as a mirror for their own working lives. On work, they see flat happiness numbers wrapped in a dramatic headline, and a jump in self-employment they can't explain. They offer guesses (AI makes solo work faster, layoffs push people out, politics push people away) and keep reminding each other that the survey never asked why. On AI, they accept the adoption jump but split use into two kinds. Using AI to write code, search, or think through an idea is fine. Using it to write the message you send another person feels like taking away your voice and passing your reader the work of decoding it. The thread that ties the sections together is trust. Source attribution matters because an unverified spec or an unattributed answer can't be checked. Harness defaults matter because most people never change them. Unfamiliar polished sites make the hosts wary because AI lowered the cost of looking professional. The SaaS discussion lands on the same idea from another angle: code is cheap, but owning it isn't, so buyers still pay vendors to carry maintenance. The technology and community sections turn reflective. A language-popularity list mixes things that aren't comparable, and language identity fades as AI talk takes over language-specific conferences. Stack Overflow's strongest remaining asset, they argue, is community, even though two of the hosts never felt welcome asking questions there. They end on the claim that human conversation still earns its slower pace through networking and different viewpoints. ## 📰 Newsletter **What three engineers noticed in the Stack Overflow survey.** The Overcommitted podcast spent 49 minutes reacting to the 2026 Stack Overflow developer survey, and the useful part isn't the percentages. It's the reasoning around them. The hosts cite AI use jumping from 31% to 87%, then spend more time on what that does to communication: long AI-written messages cost the reader effort, and several hosts now call out "this is what Claude told me" as a courtesy to flag. Their working rule is short: use AI to research and write code, and put your own words in anything another human reads. Two ideas travel well into WordPress work. First, source attribution: the hosts say they don't trust AI output unless they know how it got there, which maps directly onto AI-generated tickets, patches, and docs in contributor queues. A short "how I got here" note on every AI-assisted contribution is a cheap fix. Second, the survey says SaaS isn't dying because owning internal tools means owning the tech debt. That's a good argument for the managed-hosting and plugin ecosystem conversation: code was never the hard part, supporting it is. One caution before you repeat any figure from the episode: the percentages are the hosts' spoken reading of the survey, not checked against it here. Start from the source. Links: [the survey](https://survey.stackoverflow.co/2026), [Overcommitted](https://overcommitted.dev), [the Polytoken video the hosts recommend](https://youtu.be/YrmR6EZ5Y1U). ## ✅ Action items #### DevRel - Developer advocacy: turn the "AI for code, human for communication" rule (00:21:54) into a short talk or post with a worked before/after of an AI-written message and a human-edited one. - Education: run an office-hours session on source attribution for AI-assisted answers, using the 00:24:53 trust rule as the prompt. - Developer experience: add a "how I got this" template line to any quickstart or issue form that AI tools commonly fill in, so reviewers can see provenance. - Developer marketing: don't cite 31%, 87%, 4%, or 10% from this episode in any material until each is checked against https://survey.stackoverflow.co/2026. - Community management: write down an unspoken-rules norm for AI-written messages in community channels, since the hosts say norms are forming (00:22:38) and "meat proxy" posting gets called out (00:23:21). - Internal/external/cross-project: track whether the survey's community findings (human conversation still valued, 00:46:05) show up in your own support-channel data before using them as justification. #### OSPO - Policy and governance: decide what disclosure an AI-assisted contribution needs. The hosts' stance is that unverified AI output shouldn't be handed over silently. - License compliance: no direct action from this source. - Security management: the hosts note AI prompts for security additions (00:12:20), but also distrust unfamiliar sites for payment. Treat "AI-built, unreviewed" internal tools as an inventory risk class. - Software inventory: the SaaS discussion (00:34:28) argues internal tooling carries tech debt. Record owner and maintenance cost for any AI-built internal tool, not just licensing. - Developer support: publish guidance that AI-generated specs need a human editor, since a host reports AI always adds extras (00:32:19). - Community engagement: no direct action from this source; nearest relevance is the hosts' point that community is the lasting asset (00:43:56). - Strategic alignment: set an internal metric for AI-assisted tokens per merged change so the "token maxing" shift (00:27:46) is measured rather than anecdotal. #### Community - Maintainers: ask contributors to state how an AI-assisted spec or issue was verified, echoing the survey theme the hosts discuss at 00:30:05. - Contributors: onboarding docs should say that requirements are the success criteria (00:30:52) and must be reviewed by a person before work starts. - Sponsors: no direct action from this source. - Ecosystem: the hosts' discomfort with Stack Overflow's unwelcoming reputation (00:44:39) is a reminder to audit your own forums for "duplicate question" tone. #### WordPress - Core: no direct action from this source; nearest relevance is the "AI spec bloat" concern (00:32:19) for core tickets. - Core Performance: no direct action from this source. - Core AI: add source attribution and human-verification expectations to any responsible-AI guidance, citing the 00:24:53 trust rule as the user need. - **Core Program Team:** note the "AI-written communication is offensive" norm (00:24:06) when drafting team-communication guidance. - Mobile: no direct action from this source. - Playground: a demo that shows an AI-built plugin alongside its review checklist would illustrate the "never been so easy to create the wrong thing" point (00:30:52). - Community: draft a community norm on AI-assisted posts, informed by the hosts' "meat proxy" description (00:23:21). - Training: a lesson on writing your own spec before prompting, tied to the requirements point at 00:30:52. - Marketing: no direct action from this source; avoid quoting unsourced percentages from it. - Support: when support replies use AI drafts, add a verification step. The hosts report that unverified forwarding is called out (00:23:21). - Design: no direct action from this source. - Documentation: add provenance notes for AI-assisted docs, per the hosts' worry about unvetted AI documentation (00:30:05). - Photos: no direct action from this source. - TV: no direct action from this source. - Polyglots: no direct action from this source; nearest relevance is that AI-translated text raises the same "not written for a human" concern (00:20:25). - Accessibility: long AI-generated walls of text (00:31:36) hurt readers who use screen readers or have processing differences. Add a plain-language review step to accessibility guidance. - Meta: no direct action from this source. - CLI: no direct action from this source. - Hosting: the hosts' discussion of unknown sites asking for payment (00:13:02) is a trust-signal opportunity for hosting checklists. - Tide: no direct action from this source. - Openverse: no direct action from this source. - Themes: review queues could ask for a statement of AI assistance, since polished AI-built output is now cheap (00:09:25). - Plugins: same as Themes, plus a maintenance-ownership line, since the hosts argue code was never the hard part (00:35:56). #### The WPOCC - Programs: no direct action from this source; The WP Open Community Collective could survey its own members on the same work-happiness question. - Projects: no direct action from this source. - Funding experiments: no direct action from this source; nearest relevance is the hosts' point that maintenance, not code, is the cost (00:35:56). ### FAIR - Technical independence: no direct action from this source; nearest relevance is the hosts' concern that harness defaults shape behavior (00:26:21). - Policies and covenants: require provenance for AI-assisted metadata or code, matching the attribution theme at 00:24:06. - Productized governance artifacts: add an "AI provenance stated" row to scorecards. ## 🧪 Hypotheses 1. Respondents who report self-employment also report heavier daily AI use than salaried respondents, supporting the AI-enabled-independence theory the hosts float at 00:04:19. 2. The reported complacency share is stable year over year within a few percentage points, as one host's check of prior years suggests (00:01:26), so the survey headline overstates change. 3. Reviewers rate unlabeled AI-written messages as less considerate than human-written ones of equal accuracy, matching the hosts' "offensive" reaction (00:24:06). 4. Requiring a stated source or reasoning on AI-assisted specs reduces rework compared with unattributed specs, because reviewers can check the basis (00:30:05). 5. AI-generated specs contain more unrequested scope than human-written specs for the same prompt, as one host reports (00:32:19), and the difference is larger in one harness than in another. 6. Organizations that build internal tools with AI report higher maintenance cost per tool after 12 months than organizations that buy equivalent SaaS, supporting the survey authors' reading at 00:35:12. ## 📊 Methodology - **H1.** Obtain the survey's public data release, if the 2026 survey publishes one, and cross-tabulate employment type against daily AI hours. Report effect size and confidence intervals. If no microdata is public, the test cannot run and that gap is the finding. - **H2.** Pull complacency, happy, and unhappy shares from the 2023 to 2026 surveys, compute year-over-year change with margins, and test whether 2026 falls outside the prior range. - **H3.** Run a blinded study with matched pairs of messages (AI-drafted, human-drafted), each rated for clarity, effort to read, and perceived consideration by 100 raters. Counterbalance order and disclose nothing about authorship in one arm and full disclosure in the other. - **H4.** Compare two squads over 8 weeks on the same ticket types, one requiring provenance notes, one not. Measure rework count and time to merge, counting reopened tickets as rework. - **H5.** Give 30 identical prompts to two harnesses and a human baseline, then count requested versus added requirements per spec with two independent coders. - **H6.** Interview or survey 40 teams on internal tool spend, tracking engineer-hours per tool at 3, 6, and 12 months. Control for tool size and uptime requirement. - **Controls throughout.** Pre-register thresholds, fix prompts, record model and harness versions, and keep raters blind to condition where possible. ## ❓ Questions - Where on the survey page do 31% and 87% come from, and are they the same population as the "over four hours a day" claim (00:18:56)? - What explains the 4% to 10% self-employment change: new freelancers, laid-off workers, or a change in how the question is asked? - Does "complacent" mean what the hosts assume, and does the survey explain it in any tab (00:15:58)? - If the survey separates AI for technical generation from AI for communication, what are the respondent shares for each (00:20:25)? - Do the hosts' dark-pattern claims about harness limits (00:25:37) hold up, and who has measured whether limits change usage behavior? - Is spec bloat a model property or a harness property, as the hosts ask at 00:33:44, and has anyone tested it? - What fraction of "Python" respondents use it for scripts versus full-stack applications (00:38:09)? - Does the 70% "ask an agent" figure (00:46:05) count people who also ask humans, or is it exclusive? ## 🔮 Future research - **Explaining the self-employment shift.** The survey can't say why, per the hosts (00:02:53). A follow-up question set on motivation would settle the AI versus layoffs versus politics debate. - **AI communication norms.** The hosts describe norms forming in real time (00:22:38). Observational work on how workplaces handle disclosure of AI-written messages would add evidence beyond four anecdotes. - **Attribution as a design default.** The hosts want source attribution as a default, not a customization (00:24:53). A study of attribution defaults and error-catching would test that. - **Language-list design.** The hosts' critique (00:40:18) suggests a front end, back end, query, and scripting split. Comparing the two survey designs on the same respondents would show whether it changes rankings. - **Community after AI.** Whether sibling Q&A communities are declining as Stack Overflow's did (00:45:22) is an open measurement problem. ## 💡 Implications - **Practice.** Treat AI as a research and code tool and keep your own words in human-facing messages. Put a "how I got here" line on anything AI-assisted that a reviewer must act on. - **Policy.** Teams need a stated expectation for AI disclosure in tickets, specs, and docs. The hosts report informal call-outs are already happening (00:23:21). - **Security.** Unfamiliar polished sites are harder to judge when AI lowers the cost of looking professional (00:13:02). Security reviews of internal AI-built tools should check payment and credential handling first. - **Education.** Teach specs and requirements as the skill that matters, since the hosts argue it's never been easier to create the wrong thing (00:30:52). - **Funding.** The SaaS discussion (00:34:28) is an argument that maintenance, not code production, is the budget line. Funders of open source tooling can cite it. - **Survey literacy.** A listener should treat every figure here as secondhand until checked against the linked survey. ## 🧠 Learning styles assessment - **Reading level estimate.** Flesch-Kincaid Grade Level, estimated from the transcript's conversational register, is about grade 7, with Flesch Reading Ease near 75. This is an estimate, not a computed score. Spoken disfluency lowers the effective readability of the raw captions. #### 👀 Visual learners - Present: the hosts reference survey charts and the survey website on screen or in their notes. The transcript can't confirm what's shown. - Improve: show the survey chart for each cited statistic while the hosts discuss it, with the number and the question text on screen. #### 🔊 Aural learners - Present: a conversational format with three voices, and laughter and joking that signal tone. - Improve: the captions don't label speakers, so a listener can't tell who holds which view. Say names when switching. #### 🗣️ Verbal learners - Present: concrete analogies (SSL lock for AI quality, "meat proxy," net promoter score for happiness). - Improve: define "vibe coding," "harness," and "token maxing" in one sentence each at first use. #### 🧩 Kinesthetic learners - Present: hosts describe their own experiments, like rebuilding an app in 2 days and rewriting how they prompt AI. - Improve: give a repeatable exercise, such as rewriting an AI message in your own words and comparing time to read. #### 🧠 Logical learners - Present: several hosts separate speculation from evidence ("tinfoil hat brain" at 00:33:01, "extrapolating way too far" at 00:10:11). - Improve: state each cited percentage with its question wording and population so logical learners can check the claim. #### 🧑‍🤝‍🧑 Social learners - Present: discussion among three people, and a Discord invitation at 00:48:20. - Improve: pose one discussion question per section for the Discord. #### 🧘‍♀️ Solitary learners - Present: self-contained segments, each tied to a survey section, easy to replay. - Improve: add reflection prompts such as "which of your messages last week should have been in your own words?" #### 🌿 Naturalistic learners - Present: no explicit natural-world content. - Improve: no material fit in the transcript; the nearest hook is the sustainability theme in the token-cost discussion (00:28:32), which could name the energy cost. ## 📊 Accessibility assessment Judged against the video as published: 49:15 audio podcast on YouTube, no chapter list, auto-generated captions, and a description with three links. #### Screen reader semantics - Present: YouTube supplies the page landmarks and player controls; the description lists three links. - Improve: no chapters. WCAG 2.2 AA 2.4.5 (Multiple Ways) and 2.4.6 (Headings and Labels) point to adding chapter timestamps so screen reader users can jump by survey section. #### Keyboard navigation - Present: the player is keyboard operable by default. - Improve: nothing in the content adds barriers. 2.1.1 passes via the platform. #### Contrast and readability - Present: unverifiable from a transcript. The episode is mostly talking heads or audio with a static image. - Improve: any on-screen survey chart needs 1.4.3 contrast (4.5:1 for text) and 1.4.11 non-text contrast for chart marks. #### Text resizing and reflow - Present: the player scales and captions resize independently. - Improve: burned-in text, if any, fails 1.4.4 and 1.4.10. Prefer captions or description text over baked-in text. #### Media and captions - Present: auto-captions exist, which is how this analysis was produced. - Improve: captions misspell proper nouns ("Poly Token" for Polytoken, "Reddus" for Redis, "cloud writing" for Claude writing, "Muse" and "liaboo" unclear) and have no speaker labels. Prerecorded captions must be accurate under 1.2.2; speaker identification helps under 1.2.2 as well. If the video shows survey charts, 1.2.5 (audio description, prerecorded) applies to numbers conveyed only visually. #### Forms and interactions - Present: none in the episode. The Discord link is described as in the bio. - Improve: put the Discord and Bluesky links in the description as selectable text. The hosts say "we'll link it in the bio" but the description lists only three links. 2.4.4 (Link Purpose) applies to those links. #### Standards reference - Primary gaps against WCAG 2.2 AA: **1.2.2** (captions inaccurate on proper nouns, no speaker labels), **2.4.5 / 2.4.6** (no chapters), **1.2.5** (visual-only survey numbers, if shown), **1.4.3** and **1.4.11** (chart contrast, unverified). Caption correction is the highest-impact fix. ## 🌍 DEIB assessment #### Cultural breadth - Present: the hosts discuss a global survey audience and refer to different regions only implicitly. Examples are US-centric (a cruise, a gym, GitHub, Bluesky). - Improve: ask what the survey says by region, and whether the AI adoption numbers differ outside North America. #### Inclusive language - Present: no exclusionary terms found in the transcript. Language is conversational and mostly plain. - Improve: "meat proxy" is a casual idiom that could confuse non-native listeners. Define it on first use. #### Neurodiversity support - Present: the episode follows the survey's section order, which gives a predictable structure. - Improve: no chapters, and the hosts jump between topics (a toy mascot tangent at 00:13:46). Chapter markers would help listeners who need to navigate by topic. #### Representation - Present: three hosts with different roles and tool stacks (the transcript mentions Go, Ruby, and AI harness work), and a guest-less format. - Improve: no outside voice from respondents, and no host mentions a perspective from beyond their own tool stacks. A guest from a self-employed or non-Western developer community would add breadth. #### Psychological safety - Present: hosts frame their opinions as personal ("I just have such an ick"), invite disagreement, and acknowledge their own bias (00:17:27). They validate the work-to-live view as legitimate (00:16:42). - Improve: the Stack Overflow unwelcoming discussion (00:44:39) names a real fear of posting; follow it with an invitation for listeners to share their experience in the Discord. ## ✅ Logical validity #### Strong reasoning - **Self-limiting inference, 00:10:11.** A host says reading 4% to 10% as a landscape shift is "extrapolating way too far." That correctly separates a survey increase from a claim about overall software quality. To strengthen it: state the sample size. - **Distinguishing speed from ease, 00:05:46 to 00:06:29.** One host revises "easier" to "faster" when working solo and cites the Mythical Man-Month. The revision removes an ambiguity and the supporting reference is relevant. - **Scope condition, 00:07:12.** A host qualifies the solo-work claim by criticality and lifetime: fine for internal tools, not for pager-owned or multi-month work. This is a clean conditional claim. - **Causal humility, 00:02:53.** The hosts note the survey can't answer why people turned self-employed because respondents weren't asked. They list candidate causes without picking one. - **Mechanistic argument, 00:35:56.** If code were the hard part, everyone would self-host Redis. The counterfactual is concrete and checkable against everyday behavior. - **Self-labeled speculation, 00:33:01.** The vendor-profits-from-bloat idea is tagged "my tinfoil hat brain," so listeners can discount it. #### Fallacies - **Hasty generalization from personal experience, 00:17:27.** The hosts note their own happiness may not match the average, which partly self-corrects, but the earlier "teams are harder than solo" views at 00:05:03 rest on a few anecdotes. Fix: state the sample and condition. - **Unsupported attribution of motive, 00:33:01.** "maybe they want to charge people for more tokens" ascribes intent to AI vendors without evidence. The host flags it as a hunch, which limits the harm. Fix: test bloat rates across harnesses and models before assigning motive. - **Appeal to anecdote, 00:08:41.** A single gift-list app rebuilt in 2 days stands in for how far "the industry's come." Fix: cite a broader measure of AI coding quality. - **Unsourced figure, 00:38:52.** "only like 9% of the internet or something like that is React sites" has no source and is hedged by the speaker. Fix: cite a web-technology usage survey or drop the number. - **Survey number repeated without caveat, 00:14:28.** The hosts say "78% of respondents were in the neutral to negative side." That follows arithmetically from 22% happy, but "net promoter score" framing at 00:15:14 imports thresholds (8 of 10 and up) the survey doesn't use. Fix: label the comparison as an analogy. - **Equivocation on "AI use," 00:18:56 versus 00:19:39.** One reading says a majority use AI over four hours a day, another says 87% use it at all. Without the survey's wording, the two figures can't be reconciled. Fix: quote the survey's exact question. #### Tone of voice - Warm, conversational, and self-deprecating. The hosts use first person, contractions, and laughter. Strong feelings appear in plain terms ("such an ick," "offensive," "I'm clearly growing super distrustful"). The tone turns lighter when the topic turns to Stack Overflow's reputation and mascot jokes (00:13:46, 00:42:27), and earnest at the close (00:47:34). The hosts reliably tag speculation as speculation. ## 🛡️ DARVO analysis Not applicable to this source. DARVO (Deny, Attack, Reverse Victim and Offender) describes a response to an accusation. This episode is a discussion of survey results with no accuser and no accused. For completeness across the three prongs: **Deny**: nothing is denied; the hosts admit their own bias at 00:17:27. **Attack**: AI companies and harness defaults are criticized (00:25:37, 00:33:01), but as a product-design critique, not a personal attack on a critic. **Reverse victim/offender**: no such move appears. ## 🎯 Conclusion The episode is most useful as practitioner reasoning, not as a statistics source. Its best arguments are structural: code was never the hard part (00:35:56), source attribution is how you trust output (00:24:53), requirements are the success criteria (00:30:52), and a language-popularity list that mixes browser languages, SQL, and shells can't tell you much (00:40:18). Its weakest content is causal storytelling around unexplained numbers, which the hosts mostly label as speculation. Every percentage cited here is a spoken reading of the survey, and none was checked against https://survey.stackoverflow.co/2026 for this analysis. The one figure the hosts clearly don't take from the survey, the React "9%", has no source at all. **Next steps for readers:** open the survey and check the five numbers you intend to reuse (4% to 10% self-employed, 22% happy and 33% not happy, 31% to 87% AI use, 85% and 73% for knowledge sources, 70% asking an agent) against the exact question wording. Then adopt the two habits the hosts model: keep your own words in anything a person must read, and attach a "how I got here" note to AI-assisted work. ## 🔄 Refactor Appendix — Stack Overflow Survey Reactions | Software Engineering & Career Insights > Density: 2–5 Literature atoms (H3 pad), 0–3 Permanent candidates (H4 pad). > Emitted: 5 Literature, 2 Permanent. Resonance filter applied — the survey percentages were > dropped as atoms because none is verified against the survey in this run. > > Konik claim-header rules: present tense, declarative, ≤10 words, searchable, unique. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Split Pad #### [H1] Code was never the hard part > [!quote] [00:35:56] > if the code was the easy part, like everybody would just build their own Reddus and like manage it by themselves **Context & use**: - 00:35:56, in the SaaS-apocalypse discussion, after the survey authors' reading that internal tooling carries tech debt. - A concrete counterfactual: if building were the cost, people would self-host Redis. It supports the claim that maintenance and scaling are the budget line. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H2] Trust in AI output requires seeing the reasoning > [!quote] [00:24:53] > I don't trust it unless I know how you got there. **Context & use**: - 00:24:53, introducing source attribution as a theme the hosts tie to the survey's trust findings. - It's a user-need statement that translates directly into a design default: show sources and reasoning without being asked. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H3] Cheap generation makes the wrong thing easy > [!quote] [00:30:52] > it's never been so easy to create the wrong thing. **Context & use**: - 00:30:52, in the knowledge-section discussion of requirements as success criteria. - Pairs with the point that unvetted AI specs read as authoritative. It argues for spending effort on the spec, not the build. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H4] Bad software predates AI > [!quote] [00:11:38] > I feel like there's always been bad software. **Context & use**: - 00:11:38, in reply to a worry that vibe coding lowers overall software quality. - A useful baseline: judge AI's effect against the existing quality distribution, not an idealized one. The host adds that AI might even raise the floor. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> #### [H5] Sending AI-written text as your own erodes voice > [!quote] [00:21:54] > such an ick for delivering something that was just clearly AI written and not my own words **Context & use**: - 00:21:54, from a host who uses AI for code and search but not for messages to other humans. - Links to the cost shifted to the reader (00:20:25) and the "meat proxy" norm (00:23:21). Keep the 00:20:25 passage with it, since it explains the reader-side cost. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> ### 🧠 Atomic Split Pad #### [P1] Maintenance, not code, is the cost of software **Claim** (one sentence, Courtney's voice): When code gets cheap, the cost of software shifts to owning it, so build-versus-buy decisions turn on maintenance, support, and scaling capacity. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds for software that runs in production, has multiple users, or sits on a pager rotation. Weaker for one-off scripts and personal tools where nobody inherits the debt (00:07:12). Fails if maintenance itself becomes cheap enough to automate. **Links**: - [[AI cost architecture]] — because extends to ownership cost, not only inference cost - [[Internal tooling build versus buy]] — because applies-in internal platform decisions - [[Spec-driven development]] — because contrasts on whether the durable artifact is code or spec <!-- atomicity: 1 idea ✓ --> #### [P2] Provenance on AI output is a trust default **Claim** (one sentence, Courtney's voice): AI-assisted work that another person must act on should carry its sources and reasoning by default, because readers can't verify what they can't trace. **Evidence pointer**: [[#H2]] · [[#H3]] **Scope & conditions**: Applies to specs, issues, docs, and messages that a reviewer must trust. Doesn't apply to throwaway drafts the author fully rewrites. The hosts say customization is possible but defaults dominate behavior (00:26:21). **Links**: - [[Source attribution for AI-assisted contributions]] — because extends to contributor policy - [[Reading vendor benchmarks]] — because evidence-for treating unsourced numbers as claims - [[Support ticket triage]] — because applies-in AI-drafted replies that need verification <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Check every survey figure the hosts cite (4% to 10%, 22%/33%, 31% to 87%, 85%/73%, 70%) against https://survey.stackoverflow.co/2026 before reuse — https://www.youtube.com/watch?v=GogxA6pFiT8 #fleeting #inbox - [F2] Find the source behind the "9% of the internet is React" saying at 00:38:52 or drop it from any notes #fleeting #inbox - [F3] Open question: do the 87% any-use and "over four hours a day" claims at 00:18:56 describe the same population? #fleeting #inbox - [F4] Watch the Polytoken video from the description (https://youtu.be/YrmR6EZ5Y1U) and test the dark-pattern claim about five-hour limits at 00:25:37 #fleeting #inbox - [F5] Article seed: "Code was never the hard part" with the Redis and Linux counterfactual at 00:35:56 #fleeting #inbox #articleseed - [F6] Send the language-list critique (00:40:18) to Stack Overflow as survey-design feedback if a feedback channel exists #fleeting #inbox #share ### → Things 3 (max 2 actions) - [ ] Verify the five survey figures cited in this episode against the 2026 survey page and note which hold — research, 20 min #things - [ ] Draft a "how I got here" provenance line for AI-assisted tickets and docs in the DevRel workflow — policy draft #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Stack Overflow Survey Reactions Software Engineering & Career Insights.md|Stack Overflow Survey Reactions | Software Engineering & Career Insights by Overcommitted]] ## Highlights - [00:11:38] install by some service I'm using like my gym we went on a cruise where we had to download an app that was terrible like like all these things that are just horrible horrible apps bad user experience not accessible like probably security practices and stuff like that and I'm like okay why in 2026 do we still have bad apps like it's so easy to make these good But it it's just like not not happening. So, I don't know. I feel like there's always been bad software. And honestly, I I feel like like if there's AI involved in that, then maybe that would help it be better software in a way. [00:12:20] >> Yeah. I think if you're building with AI right now and it's your like your software isn't getting better and continuously like improving, uh, you're probably not doing it right because that's they're better than like the average engineer now. There's a lot of things that like I'll be working with it and it'll catch and be like, "Oh, do you want to add this and this and this too for security?" I'm like, "Oh, yeah. Yeah, I do. Thank you." Uh, that's good looking out there. Uh, like it's getting really good, especially at the security side, I feel like. So, but I do I do think about it a little bit more now when I come to these websites for like brands that I'm not familiar with where I'm like, is this company is this a company or is this like a single person who just put this together to try and solve this problem? Like, do I really ([View Highlight](https://read.readwise.io/read/01m4x7gevxshfdcvy3h39kfcs7)) - Note: [H4] Bad software predates AI - Tags: atom/literature/h3 - [00:21:54] cool for that. Um, but like the amount of just like even if it sounds natural and stuff, I just have such an ick for delivering something that was just clearly AI written and not my own words as though it were my own words. Like I I don't know. I feel that feels like an extension of like taking away my voice in a way. And I'm like so I do try to like paraphrase wherever possible and like like U one tool I've been using is um rather than like if I'm like struggling with ideas or something, I'll say I'll have AI like prompt me to like think through things and like force me to think through like my ideas and like [00:22:38] go through different concepts. But yeah, it's for actual like text generation. And I hate how much it pushes that text generation all the time. Like I'll be like, "Oh, like let's sync through this." and it's like, "Oh, yeah, here's a here's a generated like response." And I'm like, "No, I don't want you to respond. Do not do that. Stop [laughter] it." Um, so yeah, it's that's rough. Yeah. Yeah. I I do feel like we are like as a society starting to form more like unwritten rules about like what is acceptable and what is not. And I feel like the the AI written communication is just not it's not it. It's not It's not getting sounding like I am I'm like you Bethany like I really really love using ([View Highlight](https://read.readwise.io/read/01m4x7gj7w9rbpkfkp3t1g0mk2)) - Note: [H5] Sending AI-written text as your own erodes voice - Tags: atom/literature/h3 - [00:24:53] of the default like then than then like similar to how you were saying like I don't actually really want you to like tell me what to say. like I I want you to kind of like bring that back a little bit like and obviously I know you know you can customize these things and like we all do but um yeah just like note for anyone working on these like it's I um yeah I always I always definitely fall into that category of I don't trust it unless I know how you got there. Yeah, I watched this video earlier. I'll link it in the show notes um that I feel like is very related to this where uh it's um from Ed who makes Poly Token which is an AI code writing harness um [00:25:37] where he was talking about like a lot of these patterns that we're seeing in like major harnesses that a lot of other people are using that are like clearly like marketing PS or tactics or whatever. Um, and like they're using a lot of dark patterns to try and keep people at their computer all the time and like continuously using stuff like the five hour limits or whatever where it's like, "All right, you want to make sure you're around when that 5 hour limit runs out so you can go keep using more usage." Um, anyway, I thought it was really interesting cuz I think it's one of those things that like I don't typically feel like I think about how those are designed until it's like years later and you actually see the impacts and the effects on people over time. But I feel like this is another uh place where like yes, you can customize these ([View Highlight](https://read.readwise.io/read/01m4x7g9gb01pr5z7xrqm5ap2k)) - Note: [H2] Trust in AI output requires seeing the reasoning - Tags: atom/literature/h2 - [00:30:52] requirements are the most important thing to follow like um that's that's your success criteria. Um and so yeah, just making sure that that is airtight anytime you have something that you're working on before you start working on it. Um, >> and also kind of like less is more there too sometimes like >> Yeah, >> it's never been so easy to create the wrong thing. It feels like like now because before like when there was miscommunication with the project goals like >> you could you could build something that was like not meeting the project like I think that's a common thing like not just now but before but like you'd probably be more familiar with what you [00:31:36] were building and have like more be more tied to that rather than like oh yeah I know what you want and then just sling it out. Um yeah so I think that's such a such a great point and of course like less is more. I think we've learned that with all this AI like with AI uh uh text being like walls of text and it's like I'm not reading that. And it's so easy for something to just slip in there that >> like is not actually true or is not actually what you want. Yeah. Yeah. our um CTO at Blue Sky keeps talking about how like he thinks that like spec driven development is really like the future of writing uh development. Like the most important ([View Highlight](https://read.readwise.io/read/01m4x7gbyt7vm451dfhvcb24q3)) - Note: [H3] Cheap generation makes the wrong thing easy - Tags: atom/literature/h3 - [00:35:12] their internal tooling because even if you can build something, you have to maintain it. So the tech debt that you assume when you build internal tooling can be not worth it depending on um what it is. So >> yeah, and this is such a great transition to the technology bucket because like that was such a fear of AI like, oh, if you could just if code's cheap, you can just build it yourself. But like as we're learning, code was never the never the part that was hard. Like it's it's supporting it, it's maintaining it, it's like scaling it, and all the knowledge that comes with [00:35:56] that. Like if the code was the easy part, like everybody would just build their own Reddus and like manage it by themselves, but clearly no one does that. Um for a good reason like [laughter] [gasps] >> it's it's wild. >> Yeah. Or like everyone would have their own Linux like operating system that they maintain, but that's not how I work. Like there people like it like have like known versions of that and like rely on that. So yeah. Yeah, it's I I do think like the SAS apocalypse was always a little funny to me. Like I I can see some like maybe in cases where the m maintenance was the easy part then maybe like sure that it would take over ([View Highlight](https://read.readwise.io/read/01m4x7g77zj9br46a1apc6wq25)) - Note: [H1] Code was never the hard part - Tags: atom/literature/h1