# The Pragmatic Engineer — annotated P-series, audited v3 **Window:** 2024-10-11–2026-10-11. **123 records:** P001–P123. P123 is appended; earlier IDs are unchanged. **Access:** 52 public main articles; 71 restricted records remain provisional. A public page or outline is not independent validation of every underlying claim. Six fields follow the SE@PoliMi schema: https://www.sepolimi.com/p/se-ai-annotated-bibliography . Practitioner interviews, original reader surveys and book excerpts retain distinct evidence origins. Main findings means reported material, not necessarily experimental results. All book placements are proposals. --- ## P001 — Why techies leave Big Tech **Citation.** Gergely Orosz (2024-10-15). *Why techies leave Big Tech*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/leaving-big-tech **Type of work.** Industry/practitioner publication — practitioner interview synthesis. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Jobs & roles; Skills & learning. **In short.** Collects engineers’ and leaders’ accounts of leaving large companies for reasons including learning, autonomy, career progression, layoffs and compensation. **Summary.** Collects engineers’ and leaders’ accounts of leaving large companies for reasons including learning, autonomy, career progression, layoffs and compensation. **Main findings — reported material.** Reveals multiple motivations and trade-offs behind departures; the cases cannot estimate attrition prevalence or an AI-driven employment effect. **Classification and proposed placement.** General software engineering; sections 12.5. Departure accounts illuminate career fit and learning opportunities; they do not isolate AI-driven displacement. **Second-audit outcome.** Classification and annotation retained after review. Career-transition interviews support organizational context, not a measured effect of AI on retention. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P002 — Did Automattic commit open source theft? **Citation.** Gergely Orosz (2024-10-18). *Did Automattic commit open source theft?*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/did-automattic-commit-open-source-theft/ **Type of work.** Industry/practitioner publication — reported governance commentary. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure; Code quality & security. **In short.** Discusses the WordPress plugin-directory dispute, distinguishing permission to fork source from control over a distribution channel and its existing users. **Summary.** Discusses the WordPress plugin-directory dispute, distinguishing permission to fork source from control over a distribution channel and its existing users. **Main findings — reported material.** Useful as an ecosystem-governance and dependency-trust case. The headline is an argumentative question, not a legal finding of theft. **Classification and proposed placement.** General software engineering; sections 11.3, 6.5. The dispute concerns authority over software distribution and dependencies; retain contested legal characterizations as allegations. **Second-audit outcome.** Classification and annotation retained after review. WordPress/Automattic dispute is attributed governance reporting; not an independently adjudicated legal conclusion. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Updated 19 October 2024. Disputed motivations and legal characterizations are attributed, not adjudicated. This non-Pulse-titled blog article is an excerpt of a Pulse issue originally published 2024-10-17. It passes the literal title-prefix rule; it is excluded by the optional stricter Pulse-origin filter. The parent issue is provenance only, not another P article. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Pulse-origin provenance.** Earlier issue 2024-10-17: https://newsletter.pragmaticengineer.com/p/the-pulse-111. Included by literal title-prefix rule; excluded by the stricter view. --- ## P003 — State of the software engineering job market in 2024 **Citation.** Gergely Orosz (2024-10-22). *State of the software engineering job market in 2024*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/state-of-eng-market-2024 **Type of work.** Industry/practitioner publication — industry observational data analysis. Evidence origin: SECONDARY_OR_PROVIDER_DATA_ANALYSIS. **Streams.** Jobs & roles; Economics. **In short.** Combines employment-change and job-listing data to describe variation in engineering demand, seniority, geography and company hiring. **Summary.** Combines employment-change and job-listing data to describe variation in engineering demand, seniority, geography and company hiring. **Main findings — reported material.** The visible analysis stresses a changed market, but job listings and inferred employment changes measure different populations and do not isolate an AI effect. **Classification and proposed placement.** Labor-market and recruiting context; sections 12.5. Hiring and employment indicators contextualize AI-era labor claims without identifying an AI treatment effect. **Second-audit outcome.** Classification and annotation retained after review. Employment and vacancy providers cover different populations; do not equate job listings, total employment and AI displacement. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Live Data Technologies and TrueUp use proprietary coverage; TrueUp explicitly concentrates on Big Tech and selected startups. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P004 — Hiring software engineers and engineering leaders from Big Tech (Part 1) **Citation.** Gergely Orosz (2024-10-29). *Hiring software engineers and engineering leaders from Big Tech (Part 1)*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/hiring-from-big-tech **Type of work.** Industry/practitioner publication — practitioner interview synthesis. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Jobs & roles; Skills & learning. **In short.** Uses startup hiring accounts to examine when large-company experience transfers well and when established processes or specialized tools become liabilities. **Summary.** Uses startup hiring accounts to examine when large-company experience transfers well and when established processes or specialized tools become liabilities. **Main findings — reported material.** The accessible cases encourage assessing relevant ownership and adaptability rather than treating employer prestige as sufficient evidence of fit. **Classification and proposed placement.** Labor-market and recruiting context; sections 10.6, 12.5. Transfer of experience across organizations is an onboarding and recruitment question, not proof of employer-based ability. **Second-audit outcome.** Existing classification or proposed placement revised. Principal subject is hiring/recruiting; harmonize with other hiring records rather than a general-engineering catch-all. Retain engineering-practice relevance as a non-exclusive secondary facet. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Anonymous, selected startup accounts; not representative estimates of Big Tech employees’ competence. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Secondary subject facets.** General software engineering. **Shared source cohorts.** DATA:P:BIGTECH_HIRING_2024. --- ## P005 — How to become a more effective engineer **Citation.** Gergely Orosz; Cindy Sridharan (2024-11-05). *How to become a more effective engineer*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/how-to-become-a-more-effective-engineer **Type of work.** Industry/practitioner publication — updated guest essay. Evidence origin: ADAPTED_OR_EXCERPTED_WORK. **Streams.** Engineering structure; Skills & learning. **In short.** Cindy Sridharan discusses organizational constraints, implicit hierarchies, communication and incremental improvements from an individual-contributor perspective. **Summary.** Cindy Sridharan discusses organizational constraints, implicit hierarchies, communication and incremental improvements from an individual-contributor perspective. **Main findings — reported material.** The essay connects effective engineering with context and achievable changes, rather than assuming technical merit alone determines adoption. **Classification and proposed placement.** General software engineering; sections 11.2. Organizational communication, responsibility and feasible change are general engineering context; not agent memory, code-comprehension evidence or a mentoring intervention. **Second-audit outcome.** Classification and annotation retained after review. Explicitly revised 2024 guest edition of a 2022 essay is eligible; retain original-author credit and prior-version provenance. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Edited and updated 2024 edition of a 2022 essay; retained as the in-window edition, not a newly collected empirical study. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Cindy Sridharan. --- ## P006 — How to debug large, distributed systems: Antithesis **Citation.** Gergely Orosz; Elin Nilsson (2024-11-12). *How to debug large, distributed systems: Antithesis*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/antithesis **Type of work.** Industry/practitioner publication — reported company case and technical explainer. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Verification & review; Code quality & security. **In short.** Explains deterministic simulation, replay and fault exploration through Antithesis, alongside debugging history and engineering trade-offs. **Summary.** Explains deterministic simulation, replay and fault exploration through Antithesis, alongside debugging history and engineering trade-offs. **Main findings — reported material.** Provides a concrete external-testing example relevant to verification beyond generated tests; vendor capabilities are not independently benchmarked here. **Classification and proposed placement.** General software engineering; sections 7.5, 7.4. Deterministic simulation supplies an external verification example; transferring it to agent-produced changes requires its own evaluation. **Second-audit outcome.** Mapping retained; access/evidence annotation qualified. A later notice makes the article public in May 2026 and mentions subsequent podcast sponsorship. Treat those notices separately from the original November 2024 reporting; an original historical capture was not available. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Originally paid in November 2024; made public with a May 2026 update disclosing Antithesis as a podcast sponsor. Original article date retained. A later notice makes the article public in May 2026 and mentions subsequent podcast sponsorship. Treat those notices separately from the original November 2024 reporting; an original historical capture was not available. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Elin Nilsson. --- ## P007 — Hiring software engineers and engineering leaders from Big Tech (Part 2) **Citation.** Gergely Orosz (2024-11-19). *Hiring software engineers and engineering leaders from Big Tech (Part 2)*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/hiring-from-big-tech-part-2 **Type of work.** Industry/practitioner publication — practitioner interview synthesis. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Jobs & roles; Economics. **In short.** Discusses recruitment timing, compensation, flexibility and the portability of large-company experience to startups. **Summary.** Discusses recruitment timing, compensation, flexibility and the portability of large-company experience to startups. **Main findings — reported material.** The public outline identifies context-sensitive recruitment considerations rather than a universal ranking of companies or candidates. **Classification and proposed placement.** Labor-market and recruiting context; sections 12.5. The second hiring installment addresses fit and transition constraints, rather than repeating Part 1 verbatim. **Second-audit outcome.** Existing classification or proposed placement revised. Principal subject is hiring/recruiting; harmonize with other hiring records rather than a general-engineering catch-all. Retain engineering-practice relevance as a non-exclusive secondary facet. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Related interview series with Part 1; reported company stereotypes should not be generalized. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Secondary subject facets.** General software engineering. **Shared source cohorts.** DATA:P:BIGTECH_HIRING_2024. --- ## P008 — IDEs with GenAI features that Software Engineers love **Citation.** Gergely Orosz (2024-11-26). *IDEs with GenAI features that Software Engineers love*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/ide-that-software-engineers-love **Type of work.** Industry/practitioner publication — self selected social media survey. Evidence origin: ORIGINAL_VOLUNTARY_OBSERVATIONAL_SURVEY. **Streams.** Productivity; What agents can do. **In short.** Reports a voluntary social-media poll about AI-enabled editors and discusses tool preferences. **Summary.** Reports a voluntary social-media poll about AI-enabled editors and discusses tool preferences. The canonical newsletter reports 155 responses; its public blog excerpt does not provide the whole newsletter. **Main findings — reported material.** The poll describes early-adopter preferences, not industry market share or measured productivity. A conflicting 145-response sentence in the blog is retained as a source-edition discrepancy. **Classification and proposed placement.** AI-assisted software development; sections 2.4. Editor preference and adoption belong to workflow evidence, not causal productivity estimates or benchmarked capability. **Second-audit outcome.** Classification and annotation retained after review. Canonical 155 responses and public-excerpt limitation remain; the inconsistent 145 in the blog is not an independently validated total. **Access and limitations.** Public preview and blog excerpt; complete newsletter not reviewed. Voluntary replies across Bluesky, X and Threads; early-adopter self-selection. Canonical newsletter body and chart report 155 responses (77+62+16); one blog sentence says 145. Use 155 only as the canonical author-reported count, not an independently verified sample. The public blog supplies the IDE portion, not the complete newsletter, which also contains industry-news material. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **W/O relations.** W009 (EDITORIAL_COMPARISON_NOT_CITATION): Tool preference and suggestion acceptance differ from measured productivity; both need construct-validity caveats. **Shared source cohorts.** DATA:P:IDE_SOCIAL_2024. **Alternate editions, not extra records.** https://blog.pragmaticengineer.com/ide-that-software-engineers-love/ --- ## P009 — The Pragmatic Engineer in 2024 **Citation.** Gergely Orosz (2024-11-29). *The Pragmatic Engineer in 2024*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/the-pragmatic-engineer-in-2024/ **Type of work.** Industry/practitioner publication — editorial index. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** No forced thematic assignment. **In short.** Indexes the publication’s prior year of articles, organized around company practices and engineering topics. **Summary.** Indexes the publication’s prior year of articles, organized around company practices and engineering topics. **Main findings — reported material.** A discovery aid and editorial retrospective, not an additional independent source for the linked articles’ findings. **Classification and proposed placement.** Catalogue-only material; sections none. An annual index aids source discovery but is not another engineering study or another copy of every linked article. **Second-audit outcome.** Classification and annotation retained after review. Publication retrospective remains catalogue-only, not engineering effectiveness evidence. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Updated 5 December 2024. Not the same work as the separate December year-end Wrapped announcement. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P010 — The Pragmatic Engineer: Cyber Monday Deals **Citation.** Gergely Orosz (2024-12-02). *The Pragmatic Engineer: Cyber Monday Deals*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/the-pragmatic-engineer-cyber-monday-deals/ **Type of work.** Industry/practitioner publication — promotional announcement. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** No forced thematic assignment. **In short.** Advertises temporary discounts on the author’s books and newsletter. **Summary.** Advertises temporary discounts on the author’s books and newsletter. **Main findings — reported material.** Historical promotional record only; no engineering findings. Prices and availability must not be presented as current. **Classification and proposed placement.** Catalogue-only material; sections none. A time-limited sales announcement is retained for corpus completeness without invented engineering findings. **Second-audit outcome.** Classification and annotation retained after review. Sales promotion remains in the blog inventory without artificial research or thematic links. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P011 — How GenAI is reshaping tech hiring **Citation.** Gergely Orosz; Elin Nilsson (2024-12-03). *How GenAI is reshaping tech hiring*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/how-genai-changes-tech-hiring **Type of work.** Industry/practitioner publication — qualitative practitioner survey. Evidence origin: ORIGINAL_VOLUNTARY_OBSERVATIONAL_SURVEY. **Streams.** Jobs & roles; Verification & review. **In short.** Synthesizes contributions from 49 hiring managers and engineers about screening, unauthorized assistance, changing interview formats and integrating LLMs into assessment. **Summary.** Synthesizes contributions from 49 hiring managers and engineers about screening, unauthorized assistance, changing interview formats and integrating LLMs into assessment. **Main findings — reported material.** The visible reports suggest hiring signals and verification costs are changing; projections about future interview formats remain expectations, not measured outcomes. **Classification and proposed placement.** Labor-market and recruiting context; sections 12.5. AI-mediated recruiting and candidate assessment are labor-market context; 49 volunteered accounts do not measure developer productivity, retained learning or market prevalence. **Second-audit outcome.** Classification and annotation retained after review. Employer/interview reports concern recruiting and AI use in applications; no representative prevalence estimate. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. 49 self-selected contributions collected through messages and forms; not a representative hiring-market sample. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Elin Nilsson. **Secondary subject facets.** Ai hiring and assessment. **W/O relations.** O035 (EDITORIAL_COMPARISON_NOT_CITATION): Changing hiring signals should not be confused with a justification for removing apprenticeship. **Shared source cohorts.** DATA:P:GENAI_HIRING_2024. --- ## P012 — Why my new audiobook “The Software Engineer's Guidebook” is everywhere except on Audible **Citation.** Gergely Orosz (2024-12-10). *Why my new audiobook “The Software Engineer's Guidebook” is everywhere except on Audible*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/why-my-audibook-is-not-on-audible/ **Type of work.** Industry/practitioner publication — first person publishing case. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** No forced thematic assignment. **In short.** Describes the author’s audiobook distribution experience and commercial concerns about platform terms and publication delays. **Summary.** Describes the author’s audiobook distribution experience and commercial concerns about platform terms and publication delays. **Main findings — reported material.** A publishing-platform case rather than software-engineering evidence. A later update says Audible released the audiobook, so the headline is no longer a current availability statement. **Classification and proposed placement.** Catalogue-only material; sections none. This audiobook distribution case concerns publishing; it is not evidence about software development or current availability. **Second-audit outcome.** Classification and annotation retained after review. Audible availability update is dated separately; historical title is not a current distribution claim. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Updated 13 February 2025; preserve original date and changed availability. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P013 — How Shopify Built Its Live Globe for Black Friday **Citation.** Gergely Orosz (2024-12-17). *How Shopify Built Its Live Globe for Black Friday*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/shopify-black-friday **Type of work.** Industry/practitioner publication — reported company case. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure. **In short.** Interviews Shopify engineers about a time-bounded interactive visualization project, covering prototypes, architecture, performance, operations and qualitative product goals. **Summary.** Interviews Shopify engineers about a time-bounded interactive visualization project, covering prototypes, architecture, performance, operations and qualitative product goals. **Main findings — reported material.** Illustrates delivery trade-offs and user experience beyond code output. AI-generated concept art is one input, not evidence that AI built or validated the system. **Classification and proposed placement.** General software engineering; sections 4.1, 5.5. A real product-visualization case links intention, architecture and delivery; AI concept art is only a limited component. **Second-audit outcome.** Classification and annotation retained after review. Shopify visualization is a product-engineering case, not an experiment on AI-assisted productivity. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P014 — How AI-assisted coding will change software engineering: hard truths **Citation.** Gergely Orosz; Addy Osmani (2025-01-05). *How AI-assisted coding will change software engineering: hard truths*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/how-ai-will-change-software-engineering **Type of work.** Industry/practitioner publication — adapted guest essay with editorial commentary. Evidence origin: ADAPTED_OR_EXCERPTED_WORK. **Streams.** Verification & review; Productivity. **In short.** Republishes an edited version of Addy Osmani’s 70% problem essay and adds Orosz’s commentary about engineering responsibilities, expertise and software craft. **Summary.** Republishes an edited version of Addy Osmani’s 70% problem essay and adds Orosz’s commentary about engineering responsibilities, expertise and software craft. **Main findings — reported material.** Separates rapid prototyping from production completion and stresses comprehension and verification. The percentage is rhetorical, not a validated effect size. **Classification and proposed placement.** AI-assisted software development; sections 8.9, 2.5. An edited Osmani essay plus Orosz commentary reinforces production-completion responsibilities but is dependent on O049. **Second-audit outcome.** Classification and annotation retained after review. Explicit edited Osmani republication; retain dependency on O049 and distinguish Orosz commentary from original authorship. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Dependent on the existing Osmani essay: must not count as independent corroboration. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Addy Osmani. **W/O relations.** O049 (ADAPTS_WITH_EDITORIAL_COMMENTARY): The page explicitly introduces an edited republication of Osmani's 70% problem with Orosz commentary; not independent evidence. O042 (EDITORIAL_COMPARISON_NOT_CITATION): The human last-mile completion theme overlaps, without establishing a measured 70/30 division. --- ## P015 — Bug management that works (Part 2) **Citation.** Gergely Orosz; Elin Nilsson (2025-01-07). *Bug management that works (Part 2)*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/bug-management-that-works-part-2 **Type of work.** Industry/practitioner publication — multi practitioner interview synthesis. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Code quality & security; Engineering structure. **In short.** Synthesizes practitioner approaches to allocating bug-fixing capacity, assigning ownership, preventing defects and sustaining a quality-focused culture. **Summary.** Synthesizes practitioner approaches to allocating bug-fixing capacity, assigning ownership, preventing defects and sustaining a quality-focused culture. **Main findings — reported material.** The visible examples favor explicit ownership and capacity decisions while showing that dedicated bug-fixing periods have mixed reported results. **Classification and proposed placement.** General software engineering; sections 5.6, 11.2. Bug ownership and maintenance capacity are lifecycle-quality concerns, not an evaluation of an AI tool. **Second-audit outcome.** Classification and annotation retained after review. Bug-management team practices support quality and workflow mapping; continuation does not imply a second independent dataset. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Shares an interview pool with an earlier installment; not a controlled comparison of defect-management policies. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Elin Nilsson. --- ## P016 — Where to find to The Pragmatic Engineer Podcast **Citation.** Gergely Orosz (2025-01-08). *Where to find to The Pragmatic Engineer Podcast*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/the-pragmatic-engineer-podcast/ **Type of work.** Industry/practitioner publication — navigation announcement. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** No forced thematic assignment. **In short.** Lists distribution channels and the stated focus of the publication’s podcast. **Summary.** Lists distribution channels and the stated focus of the publication’s podcast. **Main findings — reported material.** Navigation and promotional context only; not an interview transcript or an engineering evidence source. **Classification and proposed placement.** Catalogue-only material; sections none. A podcast directory is a navigation record, not the content of its linked interviews. **Second-audit outcome.** Classification and annotation retained after review. Blog podcast-directory article is in scope as a blog publication; podcast episodes themselves remain outside newsletter Deepdives. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Updated 12 January 2025. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P017 — Cross-platform mobile development **Citation.** Gergely Orosz; Elin Nilsson; Fatos Morina (2025-01-14). *Cross-platform mobile development*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/cross-platform-mobile-development **Type of work.** Industry/practitioner publication — technical landscape synthesis. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Engineering structure; Code quality & security. **In short.** Compares native, React Native, Flutter and web-based approaches, using ecosystem data and cases to explain platform-selection trade-offs. **Summary.** Compares native, React Native, Flutter and web-based approaches, using ecosystem data and cases to explain platform-selection trade-offs. **Main findings — reported material.** The public analysis separates developer preference, application counts and revenue measures; framework popularity is not evidence of causal productivity gains. **Classification and proposed placement.** General software engineering; sections 5.5. Platform selection changes architectural constraints; popularity and revenue data do not identify a framework's causal value. **Second-audit outcome.** Classification and annotation retained after review. Cross-platform tradeoffs support architecture and engineering structure; tool popularity is not a controlled quality comparison. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Elin Nilsson; Fatos Morina. --- ## P018 — Are LLMs making StackOverflow irrelevant? **Citation.** Gergely Orosz (2025-01-21). *Are LLMs making StackOverflow irrelevant?*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/are-llms-making-stackoverflow-irrelevant/ **Type of work.** Industry/practitioner publication — secondary data commentary. Evidence origin: SECONDARY_OR_PROVIDER_DATA_ANALYSIS. **Streams.** System knowledge & memory; Skills & learning. **In short.** Discusses declining Stack Overflow question volumes alongside the rise of LLM assistance and earlier moderation-related changes. **Summary.** Discusses declining Stack Overflow question volumes alongside the rise of LLM assistance and earlier moderation-related changes. **Main findings — reported material.** Offers a hypothesis about shifting developer knowledge-seeking. Question volume is a limited proxy, and the timing alone does not prove replacement or equivalent answer quality. **Classification and proposed placement.** AI-assisted software development; sections 9.4, 10.5. The article concerns where developers obtain and preserve knowledge, not measured equivalence between generated and community answers. **Second-audit outcome.** Classification and annotation retained after review. Question activity and site relevance are different constructs; AI causation and shutdown predictions remain author interpretations. **Access and limitations.** Public main article available; classification-bearing passages reviewed. This non-Pulse-titled blog article is an excerpt of a Pulse issue originally published 2025-01-09. It passes the literal title-prefix rule; it is excluded by the optional stricter Pulse-origin filter. The parent issue is provenance only, not another P article. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Pulse-origin provenance.** Earlier issue 2025-01-09: https://newsletter.pragmaticengineer.com/p/the-pulse-119. Included by literal title-prefix rule; excluded by the stricter view. --- ## P019 — Microsoft’s developer tools roots **Citation.** Gergely Orosz (2025-01-21). *Microsoft’s developer tools roots*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/microsofts-developer-tools-roots **Type of work.** Industry/practitioner publication — historical industry commentary. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Economics; Engineering structure. **In short.** Traces Microsoft’s developer-tool history to frame its contemporary position in editors, repositories and AI assistance. **Summary.** Traces Microsoft’s developer-tool history to frame its contemporary position in editors, repositories and AI assistance. **Main findings — reported material.** The historical narrative offers context for platform incentives and dependency, rather than a formal competition or AI-return-on-investment study. **Classification and proposed placement.** General software engineering; sections 12.8, 11.3. Developer-platform history contextualizes dependency and distribution incentives; it is not a measured AI ROI model. **Second-audit outcome.** Classification and annotation retained after review. Developer-tool history and distribution strategy support economic/organizational context, not antitrust adjudication. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P020 — Taking on Google search: Perplexity and Kagi **Citation.** Gergely Orosz (2025-01-28). *Taking on Google search: Perplexity and Kagi*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/perplexity-and-kagi **Type of work.** Industry/practitioner publication — comparative company cases. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure; Verification & review. **In short.** Compares engineering cultures, search infrastructure, product choices and evaluation practices at two companies challenging established search products. **Summary.** Compares engineering cultures, search infrastructure, product choices and evaluation practices at two companies challenging established search products. **Main findings — reported material.** Provides contrasting accounts of building search and AI products. Company testimony and product growth do not establish coding-assistant effectiveness. **Classification and proposed placement.** Engineering AI systems; sections 5.5, 7.2. Search-product engineering and evaluation are adjacent to, but different from, using AI to develop software. **Second-audit outcome.** Classification and annotation retained after review. Search-product architecture is engineering AI systems; promotions and vendor descriptions are not benchmark validation. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Article accompanied subscriber offers; Orosz discloses no compensation or commercial affiliation. Descriptions are historical, not current product recommendations. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P021 — Cross-platform mobile development with Expo **Citation.** Gergely Orosz; Elin Nilsson (2025-02-04). *Cross-platform mobile development with Expo*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/expo **Type of work.** Industry/practitioner publication — reported company case. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure; Productivity. **In short.** Interviews Expo’s team about developer tooling, React Native integration, build services and production deployment workflows. **Summary.** Interviews Expo’s team about developer tooling, React Native integration, build services and production deployment workflows. **Main findings — reported material.** The public cases illustrate how tooling and incremental adoption affect development experience; they are not AI-tool evaluations. **Classification and proposed placement.** General software engineering; sections 5.5, 2.7. Expo illustrates developer-platform integration and delivery friction without establishing AI-related effects. **Second-audit outcome.** Classification and annotation retained after review. Expo team case supports mobile architecture; contemporary adoption claims are historical reports, not current recommendations. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Elin Nilsson. --- ## P022 — The Pragmatic Engineer 100K Giveaway **Citation.** Gergely Orosz (2025-02-05). *The Pragmatic Engineer 100K Giveaway*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/the-pragmatic-engineer-100k-giveaway/ **Type of work.** Industry/practitioner publication — promotional announcement. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** No forced thematic assignment. **In short.** Announces a subscriber milestone and a time-limited giveaway of books and newsletter subscriptions. **Summary.** Announces a subscriber milestone and a time-limited giveaway of books and newsletter subscriptions. **Main findings — reported material.** Promotional catalogue record only; it supplies no engineering findings or effectiveness evidence. **Classification and proposed placement.** Catalogue-only material; sections none. A giveaway announcement belongs in the source inventory, not in the engineering evidence synthesis. **Second-audit outcome.** Classification and annotation retained after review. Channel milestone and giveaway remain catalogue-only. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P023 — Where did TikTok’s software engineers go? **Citation.** Gergely Orosz (2025-02-06). *Where did TikTok’s software engineers go?*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/where-did-tiktoks-software-engineers-go/ **Type of work.** Industry/practitioner publication — secondary labor market analysis. Evidence origin: SECONDARY_OR_PROVIDER_DATA_ANALYSIS. **Streams.** Jobs & roles. **In short.** Reports destinations of departing TikTok engineers using Live Data Technologies’ professional-mobility data. **Summary.** Reports destinations of departing TikTok engineers using Live Data Technologies’ professional-mobility data. **Main findings — reported material.** Observed moves favor large established employers in the presented data. Proposed motives such as uncertainty or liquid compensation are interpretations, not directly measured reasons. **Classification and proposed placement.** Labor-market and recruiting context; sections 12.5. Observed employer transitions concern mobility; they do not reveal each worker's motives or an AI displacement mechanism. **Second-audit outcome.** Classification and annotation retained after review. Employee-movement provider data does not establish motives for switching employers. **Access and limitations.** Public main article available; classification-bearing passages reviewed. This non-Pulse-titled blog article is an excerpt of a Pulse issue originally published 2025-02-06. It passes the literal title-prefix rule; it is excluded by the optional stricter Pulse-origin filter. The parent issue is provenance only, not another P article. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Pulse-origin provenance.** Earlier issue 2025-02-06: https://newsletter.pragmaticengineer.com/p/the-pulse-123. Included by literal title-prefix rule; excluded by the stricter view. --- ## P024 — Is Big Tech becoming more cutthroat? **Citation.** Gergely Orosz (2025-02-11). *Is Big Tech becoming more cutthroat?*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/is-big-tech-becoming-more-cutthroat **Type of work.** Industry/practitioner publication — industry organizational commentary. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Jobs & roles; Engineering structure. **In short.** Discusses performance-management changes, layoffs and employer expectations at large technology companies, contrasting contemporary practices with earlier periods. **Summary.** Discusses performance-management changes, layoffs and employer expectations at large technology companies, contrasting contemporary practices with earlier periods. **Main findings — reported material.** Provides organizational and labor-market context; the public account does not isolate AI as the cause of changing employment practices. **Classification and proposed placement.** General software engineering; sections 11.2, 12.5. Workplace incentives and management practices shape engineering conditions; the commentary is not a causal intervention study. **Second-audit outcome.** Classification and annotation retained after review. Performance-management reporting concerns organizational incentives; evidence does not identify an isolated AI effect. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Mixture of reported company actions, other journalism and author interpretation. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P025 — State of the startup and scaleup hiring markets in 2025 – as seen by recruiters **Citation.** Gergely Orosz (2025-02-18). *State of the startup and scaleup hiring markets in 2025 – as seen by recruiters*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/startup-market-in-2025 **Type of work.** Industry/practitioner publication — recruiter interview synthesis. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Jobs & roles; Economics. **In short.** Contrasts broad job-listing declines with two specialist recruiters’ accounts of demand for startup engineers and engineering leaders. **Summary.** Contrasts broad job-listing declines with two specialist recruiters’ accounts of demand for startup engineers and engineering leaders. **Main findings — reported material.** Different recruitment segments can move in opposite directions; boutique recruiter experience cannot overturn broad indicators without aligning populations and denominators. **Classification and proposed placement.** Labor-market and recruiting context; sections 12.5. Recruiter perspectives are qualitative signals about market segments, not population estimates. **Second-audit outcome.** Classification and annotation retained after review. Two recruiting businesses report segment-specific hiring; do not generalize their client mix to the entire labor market. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Purposefully selected specialist agencies; their business volumes are not population hiring rates. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P026 — Software engineering job openings hit five-year low? **Citation.** Gergely Orosz (2025-02-20). *Software engineering job openings hit five-year low?*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/software-engineer-jobs-five-year-low/ **Type of work.** Industry/practitioner publication — secondary labor market analysis. Evidence origin: SECONDARY_OR_PROVIDER_DATA_ANALYSIS. **Streams.** Jobs & roles; Economics. **In short.** Examines Indeed/FRED vacancy indices across countries and discusses competing explanations for the decline, including the post-pandemic correction and AI expectations. **Summary.** Examines Indeed/FRED vacancy indices across countries and discusses competing explanations for the decline, including the post-pandemic correction and AI expectations. **Main findings — reported material.** Job-posting counts are not employment counts. Cross-country similarities weaken a single-policy explanation and do not identify AI as the cause. **Classification and proposed placement.** Labor-market and recruiting context; sections 12.5, 12.6. Vacancy trends frame competing labor-market explanations; they cannot alone establish employment loss caused by AI. **Second-audit outcome.** Classification and annotation retained after review. Indeed/FRED vacancy indices are not employment totals; article itself acknowledges incomplete coverage and causal ambiguity. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Updated 5 May 2025. Legal/tax timing assertions require separate verification before reuse. This non-Pulse-titled blog article is an excerpt of a Pulse issue originally published 2025-02-13. It passes the literal title-prefix rule; it is excluded by the optional stricter Pulse-origin filter. The parent issue is provenance only, not another P article. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **W/O relations.** W139 (EDITORIAL_COMPARISON_NOT_CITATION): Both require distinguishing job-posting indicators from employment and causal AI displacement. **Pulse-origin provenance.** Earlier issue 2025-02-13: https://newsletter.pragmaticengineer.com/p/the-pulse-124. Included by literal title-prefix rule; excluded by the stricter view. --- ## P027 — Robotics for software engineers: Part 1 **Citation.** Gergely Orosz; Sandor Felber (2025-02-25). *Robotics for software engineers: Part 1*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/robotics **Type of work.** Industry/practitioner publication — guest technical tutorial. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Skills & learning; Engineering structure. **In short.** Sandor Felber introduces robotics through project planning, controls, simulation, deployment, testing and day-to-day engineering work. **Summary.** Sandor Felber introduces robotics through project planning, controls, simulation, deployment, testing and day-to-day engineering work. **Main findings — reported material.** The public outline highlights the gap between simulations and physical deployment and distinguishes academic work from industrial delivery. **Classification and proposed placement.** Adjacent engineering: robotics; sections 10.5, 5.5. Robotics introduces hardware and physical-system constraints; transfer to coding-agent engineering is an analogy only. **Second-audit outcome.** Classification and annotation retained after review. Robotics domain is adjacent engineering; retain Sandor Felber credit and avoid coding-agent efficacy claims. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Adjacent engineering domain; not direct evidence about AI coding tools. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Sandor Felber. --- ## P028 — Trimodal Nature of Tech Compensation in the US, UK and India **Citation.** Gergely Orosz (2025-03-04). *Trimodal Nature of Tech Compensation in the US, UK and India*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/trimodal **Type of work.** Industry/practitioner publication — observational compensation data analysis. Evidence origin: SECONDARY_OR_PROVIDER_DATA_ANALYSIS. **Streams.** Economics; Jobs & roles. **In short.** Analyzes Levels.fyi compensation submissions by geography, experience and employer tier, distinguishing salary from total compensation and equity value. **Summary.** Analyzes Levels.fyi compensation submissions by geography, experience and employer tier, distinguishing salary from total compensation and equity value. **Main findings — reported material.** Illustrates labor-market heterogeneity. Employer tiers are an analytical grouping and should not be confused with statistically validated three-mode distributions or an AI effect. **Classification and proposed placement.** Labor-market and recruiting context; sections 12.8, 12.5. Compensation tiers describe segment structure; the article does not statistically establish three distributional modes. **Second-audit outcome.** Classification and annotation retained after review. Compensation tiers are a practitioner labor-market framework, not a universal causal salary model. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Self-reported and verified platform data, not a representative labor-force sample; no mixture-model replication performed. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P029 — AI fakers exposed in tech dev recruitment: postmortem **Citation.** Gergely Orosz (2025-03-11). *AI fakers exposed in tech dev recruitment: postmortem*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/ai-fakers **Type of work.** Industry/practitioner publication — reported security case. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Jobs & roles; Verification & review. **In short.** Reports a security startup’s account of suspected impersonation during remote hiring and the changes it made to candidate verification. **Summary.** Reports a security startup’s account of suspected impersonation during remote hiring and the changes it made to candidate verification. **Main findings — reported material.** The visible incidents motivate stronger identity and competency checks; attribution to a coordinated foreign operation remains a hypothesis rather than a demonstrated conclusion. **Classification and proposed placement.** Labor-market and recruiting context; sections 12.5. A reported hiring-fraud incident concerns candidate identity and assessment integrity, not production coding-agent performance. Attacker attribution remains uncertain. **Second-audit outcome.** Classification and annotation retained after review. Recruitment-fraud case is employer-reported; no population fraud rate or independently tested detection protocol. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Single-company account; suspicion, observed behavior and alleged attacker attribution must remain distinct. Recording or identity-check proposals require separate privacy and legal assessment. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Secondary subject facets.** Ai hiring and assessment. --- ## P030 — Survey: What’s in your tech stack? **Citation.** Gergely Orosz; Elin Nilsson (2025-03-18). *Survey: What’s in your tech stack?*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/what-is-in-your-tech-stack **Type of work.** Industry/practitioner publication — survey recruitment. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** No forced thematic assignment. **In short.** Invites readers to report their languages, frameworks, platforms and tools and outlines plans for publishing results. **Summary.** Invites readers to report their languages, frameworks, platforms and tools and outlines plans for publishing results. **Main findings — reported material.** This is a recruitment and methods record, not a results article; it establishes a connection to the subsequent tooling-survey series. **Classification and proposed placement.** Methods and provenance; sections none. A survey invitation establishes recruitment provenance, not findings; it links to the later three-part results series. **Second-audit outcome.** Classification and annotation retained after review. Survey invitation is recruitment/provenance, not results; plans to publish in May are not actual result dates. **Access and limitations.** Public main article available; classification-bearing passages reviewed. No survey findings are reported in this invitation. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Elin Nilsson. **Shared source cohorts.** DATA:P:TECHSTACK_2025. **Alternate editions, not extra records.** https://blog.pragmaticengineer.com/survey-whats-in-your-tech-stack/ --- ## P031 — What is Growth Engineering? **Citation.** Gergely Orosz; Alexey Komissarouk (2025-03-20). *What is Growth Engineering?*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/what-is-growth-engineering **Type of work.** Industry/practitioner publication — guest practitioner guidance. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Engineering structure; Productivity. **In short.** Alexey Komissarouk describes experimentation-driven engineering that prioritizes learning about business outcomes, supported by product analytics, feature flags and organizational ownership. **Summary.** Alexey Komissarouk describes experimentation-driven engineering that prioritizes learning about business outcomes, supported by product analytics, feature flags and organizational ownership. **Main findings — reported material.** Offers a useful contrast between shipping to learn and building for longevity. Reported business experiments are not evaluations of AI-assisted development. **Classification and proposed placement.** General software engineering; sections 4.1, 2.1. Growth engineering connects product hypotheses to measured outcomes rather than treating feature output as value. **Second-audit outcome.** Classification and annotation retained after review. Growth engineering concerns experiments and product outcomes; guest guidance is not an AI development trial. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Revenue and experimental effects are contributor-reported and not independently replicated here. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Alexey Komissarouk. --- ## P032 — AI Engineering in the real world **Citation.** Gergely Orosz (2025-03-25). *AI Engineering in the real world*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/ai-engineering-in-the-real-world **Type of work.** Industry/practitioner publication — reported multi company cases. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure; Verification & review. **In short.** Seven company accounts describe engineers building LLM products, including evaluation, nondeterminism, privacy, latency, bespoke tooling and usage-driven costs. **Summary.** Seven company accounts describe engineers building LLM products, including evaluation, nondeterminism, privacy, latency, bespoke tooling and usage-driven costs. **Main findings — reported material.** The accessible cases distinguish easy prototypes from production obligations; they concern building AI products and cannot directly quantify coding-assistant productivity. **Classification and proposed placement.** Engineering AI systems; sections 5.5, 7.2. The cases concern building AI-enabled products; their operational lessons are not evidence of coding-agent productivity. **Second-audit outcome.** Classification and annotation retained after review. Seven AI-product cases address evaluation, privacy and latency; principal domain remains engineering AI systems. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Orosz discloses investments in incident.io and Wordsmith, both included in the article. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P033 — The Reality of Tech Interviews in 2025 **Citation.** Gergely Orosz; Evan King; Stefan Mai (2025-04-01). *The Reality of Tech Interviews in 2025*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/the-reality-of-tech-interviews **Type of work.** Industry/practitioner publication — guest industry analysis. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Jobs & roles; Skills & learning. **In short.** Interview-preparation founders discuss selective hiring recovery, changing interview difficulty, domain specialization and differences between startup and large-company hiring. **Summary.** Interview-preparation founders discuss selective hiring recovery, changing interview difficulty, domain specialization and differences between startup and large-company hiring. **Main findings — reported material.** The visible account highlights variation by experience and specialty. Platform activity is only a proxy for demand and cannot establish population-wide hiring rates. **Classification and proposed placement.** Labor-market and recruiting context; sections 12.5. Interview preparation and assessment methods concern competence signals; commercial interests and selection limit generalization. **Second-audit outcome.** Existing classification or proposed placement revised. Principal subject is hiring/recruiting; harmonize with other hiring records rather than a general-engineering catch-all. Retain engineering-practice relevance as a non-exclusive secondary facet. Interview-format and hiring-market observations do not evaluate delayed retention or engineering-fluency measures. Locate interview-selection methods in recruitment without implying validation of retained-skill measurement. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Contributors cofound Hello Interview; claims about a one-standard-deviation increase in hiring standards are not supported by a validated common scale in the preview. Interview-platform traffic and an asserted higher hiring bar have distinct, incompletely specified denominators; neither is a population employment statistic. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Evan King; Stefan Mai. **Secondary subject facets.** General software engineering. --- ## P034 — MCP Protocol: a new AI dev tools building block **Citation.** Gergely Orosz (2025-04-08). *MCP Protocol: a new AI dev tools building block*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/mcp **Type of work.** Industry/practitioner publication — technical explainer and creator interview. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure; What agents can do. **In short.** Explains MCP using a database-tool example and an interview with a protocol co-creator. **Summary.** Explains MCP using a database-tool example and an interview with a protocol co-creator. Connects client-server architecture and IDE extensibility to credential-access risks. **Main findings — reported material.** The public demonstration illustrates improved access to context and tools while warning that capability expansion does not provide a security boundary. **Classification and proposed placement.** AI-assisted software development; sections 3.2, 6.7. The database/tool example explains how coding assistants acquire context and capabilities through MCP. Security and authorization remain separate design duties; this is not an empirical security evaluation. **Second-audit outcome.** Classification and annotation retained after review. Developer-tool integration focus supports AI-assisted development; the protocol does not itself confer authorization or safety. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Protocol and implementation descriptions are dated April 2025, not a security assessment of every later MCP implementation. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Secondary subject facets.** Engineering AI systems. **W/O relations.** O040 (EDITORIAL_COMPARISON_NOT_CITATION): Two practitioner explanations of MCP; agreement does not independently validate the security of deployed servers. O014 (EDITORIAL_COMPARISON_NOT_CITATION): Identity and authorization belong to the agent platform, not to language-model competence alone. --- ## P035 — Tech hiring: is this an inflection point? **Citation.** Gergely Orosz (2025-04-15). *Tech hiring: is this an inflection point?*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/tech-hiring-inflection-point **Type of work.** Industry/practitioner publication — reported multi company cases. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Jobs & roles; Verification & review. **In short.** Discusses employer experiences with automated applications and AI-assisted interview deception, alongside possible changes to remote hiring, trial periods and work samples. **Summary.** Discusses employer experiences with automated applications and AI-assisted interview deception, alongside possible changes to remote hiring, trial periods and work samples. **Main findings — reported material.** The visible cases suggest that hiring signals require reassessment; they do not demonstrate that remote interviews universally fail or in-person hiring is inevitable. **Classification and proposed placement.** Labor-market and recruiting context; sections 12.5. Employer experiences with AI-assisted applications and interviews inform hiring policy; the blog is only a partial alternate edition and no software-delivery effect is estimated. **Second-audit outcome.** Classification and annotation retained after review. Employer account of application volume and AI-assisted interviews is contextual, not causal labor-market estimation. **Access and limitations.** Public preview and blog excerpt; complete newsletter not reviewed. Orosz discloses an investment in Maestro, one of the companies discussed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Secondary subject facets.** Ai hiring and assessment. **Alternate editions, not extra records.** https://blog.pragmaticengineer.com/tech-hiring-is-this-an-inflection-point/ --- ## P036 — More than one million readers **Citation.** Gergely Orosz (2025-04-22). *More than one million readers*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/one-million **Type of work.** Industry/practitioner publication — publication retrospective and reader survey. Evidence origin: ORIGINAL_VOLUNTARY_OBSERVATIONAL_SURVEY. **Streams.** No forced thematic assignment. **In short.** A publication retrospective includes a 2024 reader survey describing respondents’ roles, employers, location and education, alongside the newsletter’s growth. **Summary.** A publication retrospective includes a 2024 reader survey describing respondents’ roles, employers, location and education, alongside the newsletter’s growth. **Main findings — reported material.** The self-selected readership profile helps assess transferability of later reader surveys; subscriber growth itself is not software-engineering evidence. **Classification and proposed placement.** Methods and provenance; sections none. A readership survey helps characterize the publication's audience and selection, not the entire engineering workforce. **Second-audit outcome.** Classification and annotation retained after review. Subscriber milestone gives publication provenance, not evidence of engineering outcomes or representative survey sampling. **Access and limitations.** Public main article available; classification-bearing passages reviewed. 2,395 voluntary responses reported for a 2024 reader survey; not a census or random sample of software engineers. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Shared source cohorts.** DATA:P:READER_PROFILE_2024. --- ## P037 — Humanoid robots for software engineers (Robotics for software engineers, Part 2) **Citation.** Gergely Orosz; Sandor Felber (2025-04-29). *Humanoid robots for software engineers (Robotics for software engineers, Part 2)*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/humanoid-robots **Type of work.** Industry/practitioner publication — guest technical tutorial. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Skills & learning; Engineering structure. **In short.** Sandor Felber explains humanoid-robot hardware constraints, state estimation, real-time control and optimization, with an outline of learning-based methods. **Summary.** Sandor Felber explains humanoid-robot hardware constraints, state estimation, real-time control and optimization, with an outline of learning-based methods. **Main findings — reported material.** Provides domain background for software engineers entering robotics; its AI concerns concern robotic control, not autonomous software development. **Classification and proposed placement.** Adjacent engineering: robotics; sections 10.5, 5.5. Humanoid-robot development provides adjacent systems context, not evidence that software-agent autonomy transfers to physical systems. **Second-audit outcome.** Classification and annotation retained after review. Humanoid hardware/control challenges belong to adjacent robotics, not direct coding-agent research. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Sandor Felber. --- ## P038 — What’s Changed in 50 Years of Computing: Part 4 **Citation.** Gergely Orosz (2025-05-06). *What’s Changed in 50 Years of Computing: Part 4*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/mythical-man-month-part-4 **Type of work.** Industry/practitioner publication — historical conceptual commentary. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Engineering structure; Productivity. **In short.** Revisits Brooks’s account of tooling, debugging, project schedules and documentation against contemporary engineering practice. **Summary.** Revisits Brooks’s account of tooling, debugging, project schedules and documentation against contemporary engineering practice. Distinguishes improvements in tools from persistent coordination and specification problems. **Main findings — reported material.** The accessible outline supports continuity in engineering responsibilities despite technological change; historical comparisons do not establish an AI-specific effect. **Classification and proposed placement.** General software engineering; sections 1.3, 2.1. Historical comparison frames durable engineering judgment; it is not a controlled estimate of modern AI effects. **Second-audit outcome.** Classification and annotation retained after review. Modern rereading of Brooks is distinct 2025 commentary; original book is older and not a new experiment. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P039 — Building, launching, and scaling ChatGPT Images **Citation.** Gergely Orosz (2025-05-13). *Building, launching, and scaling ChatGPT Images*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/chatgpt-images **Type of work.** Industry/practitioner publication — reported company case. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure. **In short.** Interviews OpenAI engineering leaders about an image-generation launch, asynchronous execution, isolation, load testing and bottlenecks beyond GPU capacity. **Summary.** Interviews OpenAI engineering leaders about an image-generation launch, asynchronous execution, isolation, load testing and bottlenecks beyond GPU capacity. **Main findings — reported material.** The visible account emphasizes operational preparation and adaptation under unexpected demand. Growth numbers describe the product launch, not coding-assistant effectiveness. **Classification and proposed placement.** Engineering AI systems; sections 5.5, 7.2. Launching an image-generation service concerns AI-product infrastructure, evaluation and deployment rather than AI-for-coding performance. **Second-audit outcome.** Classification and annotation retained after review. Team interview describes AI-product rollout and architecture; launch/scaling claims remain attributed. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Company-reported launch experience; primarily engineering an AI product. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P040 — Stack overflow is almost dead **Citation.** Gergely Orosz (2025-05-15). *Stack overflow is almost dead*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/stack-overflow-is-almost-dead/ **Type of work.** Industry/practitioner publication — secondary data commentary. Evidence origin: SECONDARY_OR_PROVIDER_DATA_ANALYSIS. **Streams.** System knowledge & memory; Skills & learning. **In short.** Updates an earlier analysis of falling Stack Overflow question counts, considering moderation history, alternative communities and LLM-based assistance. **Summary.** Updates an earlier analysis of falling Stack Overflow question counts, considering moderation history, alternative communities and LLM-based assistance. **Main findings — reported material.** The observations concern new questions, not all site usage or knowledge value. The headline and shutdown forecast go beyond what the descriptive series demonstrates. **Classification and proposed placement.** AI-assisted software development; sections 9.4, 10.5. The follow-up concerns knowledge-community activity; fewer questions do not prove disappearance of all usage or knowledge value. **Second-audit outcome.** Classification and annotation retained after review. Question-count decline is not equivalent to company closure or independently identified AI causation. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Updated 19 May 2025. The causal contribution of LLMs is not identified by the time series. This non-Pulse-titled blog article is an excerpt of a Pulse issue originally published 2025-05-15. It passes the literal title-prefix rule; it is excluded by the optional stricter Pulse-origin filter. The parent issue is provenance only, not another P article. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **P-series reporting relations.** P018 (UPDATES_PRIOR_REPORTING): Later Stack Overflow traffic discussion revisits the earlier metric narrative; not an independent observation programme. **Pulse-origin provenance.** Earlier issue 2025-05-15: https://newsletter.pragmaticengineer.com/p/the-pulse-134. Included by literal title-prefix rule; excluded by the stricter view. --- ## P041 — The AI Engineering Stack **Citation.** Gergely Orosz; Chip Huyen (2025-05-20). *The AI Engineering Stack*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/the-ai-engineering-stack **Type of work.** Industry/practitioner publication — guest book excerpt. Evidence origin: ADAPTED_OR_EXCERPTED_WORK. **Streams.** Engineering structure; Verification & review. **In short.** Chip Huyen’s book excerpt distinguishes application, model and infrastructure layers and compares AI engineering with machine-learning and full-stack engineering. **Summary.** Chip Huyen’s book excerpt distinguishes application, model and infrastructure layers and compares AI engineering with machine-learning and full-stack engineering. Evaluation and interfaces are central application concerns. **Main findings — reported material.** Provides an architectural vocabulary for building AI products; it should not be treated as evidence that using AI improves software-development productivity. **Classification and proposed placement.** Engineering AI systems; sections 5.5, 7.2. An introduced technical book excerpt explains the AI-product stack; distinguish application engineering from coding assistance. **Second-audit outcome.** Classification and annotation retained after review. Chip Huyen book material addresses AI-application architecture; distinguish source-book authorship from editorial introduction. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Excerpt credited to Chip Huyen; primarily software engineering for AI, not AI-assisted software engineering. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Chip Huyen. --- ## P042 — Microsoft is dogfooding AI dev tools’ future **Citation.** Gergely Orosz (2025-05-27). *Microsoft is dogfooding AI dev tools’ future*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/microsoft-ai-dev-tools **Type of work.** Industry/practitioner publication — conference field report. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure; Productivity. **In short.** Reports observations at Microsoft BUILD, including supervised coding agents, public failures on the .NET codebase and platform incentives behind optimistic AI messaging. **Summary.** Reports observations at Microsoft BUILD, including supervised coding agents, public failures on the .NET codebase and platform incentives behind optimistic AI messaging. **Main findings — reported material.** The public outline contrasts bounded demonstrations with brownfield difficulties and keeps developers responsible for agent output. **Classification and proposed placement.** AI-assisted software development; sections 11.1, 2.4. Internal use and conference examples illustrate adoption mechanisms, not independently measured organization-wide gains. **Second-audit outcome.** Classification and annotation retained after review. Conference observations and demonstrations are not measured deployment productivity. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Author reports self-funded travel; situated interviews and demonstrations are not a representative evaluation. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P043 — Vibe Coding as a software engineer **Citation.** Gergely Orosz; Elin Nilsson (2025-06-03). *Vibe Coding as a software engineer*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/vibe-coding-as-a-software-engineer **Type of work.** Industry/practitioner publication — practitioner conceptual analysis. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Verification & review; Skills & learning. **In short.** Examines competing definitions of vibe coding, contrasts prototypes with production systems, and discusses cases where developers resume direct control to finish an application. **Summary.** Examines competing definitions of vibe coding, contrasts prototypes with production systems, and discusses cases where developers resume direct control to finish an application. **Main findings — reported material.** The accessible text makes review, security, performance and engineering judgment the boundary between a useful prototype and accountable delivery. **Classification and proposed placement.** AI-assisted software development; sections 8.9, 10.2. Exploratory generation and accountable engineering differ in verification and retained understanding. **Second-audit outcome.** Classification and annotation retained after review. Vibe coding versus inspected AI-assisted coding is an operational distinction; no validated universal outcome comparison. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Definitions differ among quoted practitioners; no measured production benefit is established. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Elin Nilsson. **W/O relations.** O028 (EDITORIAL_COMPARISON_NOT_CITATION): Both distinguish exploratory generation from accountable AI-assisted engineering. W113 (EDITORIAL_COMPARISON_NOT_CITATION): The controlled comprehension question is narrower than broad practitioner advice about vibe coding. --- ## P044 — Real-world engineering challenges: building Cursor **Citation.** Gergely Orosz (2025-06-10). *Real-world engineering challenges: building Cursor*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/cursor **Type of work.** Industry/practitioner publication — reported company case. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure; System knowledge & memory. **In short.** Reports engineering choices behind Cursor, including code-context synchronization, execution isolation, orchestration infrastructure and latency-sensitive development workflows. **Summary.** Reports engineering choices behind Cursor, including code-context synchronization, execution isolation, orchestration infrastructure and latency-sensitive development workflows. **Main findings — reported material.** The visible outline illustrates the substantial infrastructure behind coding assistance; it does not demonstrate that adoption or vendor growth equals developer productivity. **Classification and proposed placement.** Engineering AI systems; sections 5.5, 9.4. A tool-builder architecture case: repository synchronization, context and execution infrastructure. It has a secondary AI-assisted-development connection but is not a developer-productivity trial. **Second-audit outcome.** Classification and annotation retained after review. Cursor infrastructure is principally engineering an AI product; prior IDE survey reuse must not count as new respondents. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Company interview; detailed implementation claims beyond the preview remain unverified. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Secondary subject facets.** AI-assisted software development. **W/O relations.** O031 (EDITORIAL_COMPARISON_NOT_CITATION): Repository context is an operational design concern; the company case is not a controlled context-engineering evaluation. --- ## P045 — Builder.ai did not “fake AI with 700 engineers” **Citation.** Gergely Orosz (2025-06-12). *Builder.ai did not “fake AI with 700 engineers”*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/builder-ai-did-not-fake-ai/ **Type of work.** Industry/practitioner publication — reported investigation. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure. **In short.** Investigates claims that Builder.ai was merely a human-operated substitute for AI. **Summary.** Investigates claims that Builder.ai was merely a human-operated substitute for AI. Former-employee accounts describe a code-generation product alongside human fulfilment; a hypothetical human-operated design is an explanatory contrast, not a verified internal architecture. **Main findings — reported material.** The account challenges a simplified corporate narrative. It does not independently verify the product’s reliability, staffing, financial history or productivity. **Classification and proposed placement.** AI-sector and organizational context; sections 11.2. Industry fact-checking distinguishes reported AI code generation from human fulfilment. Neither a hypothetical architecture nor employee accounts validate a capability benchmark. **Second-audit outcome.** Classification and annotation retained after review. Corrective reporting challenges a specific fake-AI narrative; it does not independently settle every allegation about the company. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Claims about internal operations are attributed to former staff; corporate-failure explanations remain interpretations. This non-Pulse-titled blog article is an excerpt of a Pulse issue originally published 2025-06-12. It passes the literal title-prefix rule; it is excluded by the optional stricter Pulse-origin filter. The parent issue is provenance only, not another P article. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Secondary subject facets.** AI-assisted software development. **Pulse-origin provenance.** Earlier issue 2025-06-12: https://newsletter.pragmaticengineer.com/p/the-pulse-137. Included by literal title-prefix rule; excluded by the stricter view. --- ## P046 — Being an “Intrapreneur” as a software engineer **Citation.** Gergely Orosz; Chaitali Narla (2025-06-17). *Being an “Intrapreneur” as a software engineer*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/being-an-intrapreneur-as-a-software **Type of work.** Industry/practitioner publication — guest practitioner guidance. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Engineering structure; Skills & learning. **In short.** Chaitali Narla discusses identifying valuable problems, taking ownership, building relationships and finding sponsorship for change within an organization. **Summary.** Chaitali Narla discusses identifying valuable problems, taking ownership, building relationships and finding sponsorship for change within an organization. **Main findings — reported material.** The visible guidance connects engineering impact with initiative and organizational support. It is general career guidance, not evidence of AI effectiveness. **Classification and proposed placement.** General software engineering; sections 11.2, 4.1. Internal entrepreneurship concerns ownership and organizational adoption rather than AI capability. **Second-audit outcome.** Classification and annotation retained after review. Intrapreneurship is career/product practice, not an AI automation experiment. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Chaitali Narla. --- ## P047 — Learnings from two years of using AI tools for software engineering **Citation.** Gergely Orosz; Birgitta Böckeler (2025-06-24). *Learnings from two years of using AI tools for software engineering*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/two-years-of-using-ai **Type of work.** Industry/practitioner publication — guest practitioner synthesis. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Skills & learning; Productivity. **In short.** Birgitta Böckeler reflects on changes from autocomplete to agentic assistance over two years, including cognitive bias, reviewer fatigue, quality supervision and team effectiveness. **Summary.** Birgitta Böckeler reflects on changes from autocomplete to agentic assistance over two years, including cognitive bias, reviewer fatigue, quality supervision and team effectiveness. **Main findings — reported material.** The public outline emphasizes adapting engineering practices alongside tools; two years of experience does not establish a longitudinal controlled study. **Classification and proposed placement.** AI-assisted software development; sections 10.5, 2.7. Longitudinal practitioner experience informs adaptation and comprehension, but does not substitute for controlled measurement. **Second-audit outcome.** Classification and annotation retained after review. Böckeler's accumulated practitioner experience is not a two-year longitudinal controlled study. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Birgitta Böckeler. **W/O relations.** O003 (EDITORIAL_COMPARISON_NOT_CITATION): Practice and retained understanding matter, but practitioner experience does not measure skill decay. W118 (EDITORIAL_COMPARISON_NOT_CITATION): Skill-formation research offers a separate empirical lens; the interview is not a replication. --- ## P048 — Software engineering with LLMs in 2025: reality check **Citation.** Gergely Orosz (2025-07-01). *Software engineering with LLMs in 2025: reality check*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/software-engineering-with-llms-in-2025 **Type of work.** Industry/practitioner publication — interview based synthesis. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Productivity; Engineering structure. **In short.** Contrasts executive expectations with developers’ experiences of LLM-assisted work, drawing on interviews and a conference presentation. **Summary.** Contrasts executive expectations with developers’ experiences of LLM-assisted work, drawing on interviews and a conference presentation. Examines adoption, review obligations and the gap between demonstrations and dependable delivery. **Main findings — reported material.** The accessible report presents uneven benefits and continuing engineering oversight, rather than a universal productivity multiplier. **Classification and proposed placement.** AI-assisted software development; sections 2.5, 1.9. The synthesis separates demonstrated tool potential from organization-level delivery outcomes. **Second-audit outcome.** Classification and annotation retained after review. Written keynote is Deepdives and distinct from the embedded video; cross-post alias remains consolidated. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Interview selection and conference synthesis are not a controlled estimate of productivity. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **W/O relations.** W010 (EDITORIAL_COMPARISON_NOT_CITATION): Generated activity and shipped outcomes are different dependent variables. **Alternate editions, not extra records.** https://blog.pragmaticengineer.com/software-engineering-with-llms-in-2025/ --- ## P049 — Skills useful to learn for robotics engineering (Robotics for software engineers, Part 3) **Citation.** Gergely Orosz; Sandor Felber (2025-07-08). *Skills useful to learn for robotics engineering (Robotics for software engineers, Part 3)*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/skills-useful-to-learn-for-robotics **Type of work.** Industry/practitioner publication — guest practitioner guidance. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Skills & learning; Engineering structure. **In short.** Sandor Felber outlines software, AI and robotics skills for work involving real-time control and physical constraints. **Summary.** Sandor Felber outlines software, AI and robotics skills for work involving real-time control and physical constraints. **Main findings — reported material.** The guidance illustrates multidisciplinary learning and performance requirements. Physical robotics autonomy is not the same construct as coding-agent autonomy. **Classification and proposed placement.** Adjacent engineering: robotics; sections 10.5, 5.5. Robotics skill development provides adjacent engineering education, not a tested coding-agent training intervention. **Second-audit outcome.** Classification and annotation retained after review. Third robotics skills installment retains source dependency and adjacent-domain classification. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Guest discloses his robotics startup and hiring interests. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Sandor Felber. --- ## P050 — The Pragmatic Engineer 2025 Survey: What’s in your tech stack? Part 1 **Citation.** Gergely Orosz; Elin Nilsson (2025-07-15). *The Pragmatic Engineer 2025 Survey: What’s in your tech stack? Part 1*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/the-pragmatic-engineer-2025-survey **Type of work.** Industry/practitioner publication — reader survey analysis. Evidence origin: ORIGINAL_VOLUNTARY_OBSERVATIONAL_SURVEY. **Streams.** Engineering structure; Productivity. **In short.** The survey reports tool usage and sentiment across languages, coding assistants, IDEs, delivery infrastructure and cloud platforms. **Summary.** The survey reports tool usage and sentiment across languages, coding assistants, IDEs, delivery infrastructure and cloud platforms. **Main findings — reported material.** This is a self-selected readership sample with 2,997 retained responses, not a random industry census. Cross-year differences can reflect changing respondents. **Classification and proposed placement.** General software engineering; sections 11.1, 2.4. A broad, self-selected technology-stack survey with an AI-tooling subsection. Retain AI as a secondary facet; the same respondents underlie Parts 2 and 3. **Second-audit outcome.** Mapping retained; access/evidence annotation qualified. The reported gross 3,000-plus submissions and cleaned 2,997 retained responses refer to stages of the same reader survey, not separate datasets. No microdata recount was performed. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Same dataset as Parts 2 and 3; do not interpret mentions as causal productivity effects. The reported gross 3,000-plus submissions and cleaned 2,997 retained responses refer to stages of the same reader survey, not separate datasets. No microdata recount was performed. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Elin Nilsson. **Secondary subject facets.** AI-assisted software development. **W/O relations.** W022 (EDITORIAL_COMPARISON_NOT_CITATION): Adoption surveys require sampling and denominator cautions; do not treat separate samples as a common time series. **Shared source cohorts.** DATA:P:TECHSTACK_2025. --- ## P051 — Why reliability is hard at scale: learnings from infrastructure outages **Citation.** Gergely Orosz (2025-07-22). *Why reliability is hard at scale: learnings from infrastructure outages*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/why-reliability-is-hard-at-scale **Type of work.** Industry/practitioner publication — postmortem synthesis. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Code quality & security; Engineering structure. **In short.** An editorial comparison of infrastructure outages considers update controls, global configuration, database behavior and incident transparency. **Summary.** An editorial comparison of infrastructure outages considers update controls, global configuration, database behavior and incident transparency. **Main findings — reported material.** Failure containment and learning from prior incidents matter as systems scale. Some causal details are Orosz’s reconstruction rather than provider-confirmed facts. **Classification and proposed placement.** General software engineering; sections 5.6, 11.6. Infrastructure incidents illustrate reliability and escalation; applying them to agents is a marked engineering analogy. **Second-audit outcome.** Classification and annotation retained after review. Incident synthesis is reliability context; repeated failure mechanisms are not an estimated industry failure rate. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P052 — Cursor makes developers less effective? **Citation.** Gergely Orosz (2025-07-24). *Cursor makes developers less effective?*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/cursor-makes-developers-less-effective/ **Type of work.** Industry/practitioner publication — secondary research commentary. Evidence origin: SECONDARY_RESEARCH_REPORTING. **Streams.** Productivity. **In short.** Discusses METR’s experienced-maintainer experiment and possible workflow explanations. **Summary.** Discusses METR’s experienced-maintainer experiment and possible workflow explanations. A targeted primary-source check confirms 16 developers and 246 issues randomized by issue to AI allowed or disallowed, not separate developer treatment groups. **Main findings — reported material.** The primary study reports slower completion in this specific early-2025 setting. P052’s broader all-tools inference and proposed familiarity explanation remain interpretations; neither is independent causal validation. **Classification and proposed placement.** AI-assisted software development; sections 2.2, 2.3. This is secondary commentary on W023, not a replication; the all-tools extrapolation and causal learning-curve explanation are unsupported. **Second-audit outcome.** Classification and annotation retained after review. Secondary article still says 136 issues and developer-group assignment; preserve correction from primary METR methods. **Access and limitations.** Public main article available; classification-bearing passages reviewed. P052 says 136 issues and implies assignment by developer. METR’s primary methodology reports 246 issues and issue-level randomization, with developers working in both conditions. Do not reproduce the secondary account’s conflicting design description. A primary abstract/methodology check was performed, not a full-paper audit or statistical replication. This is a retitled Pulse excerpt; preserve its existing series provenance. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **W/O relations.** W023 (SECONDARY_ACCOUNT_OF_EXISTING_RESEARCH): P052 reports the METR study already W023. Primary-method check corrects the issue count and issue-level randomization; no new experiment or replication is introduced. **Pulse-origin provenance.** Earlier issue 2025-07-17: https://newsletter.pragmaticengineer.com/p/the-pulse-140. Included by literal title-prefix rule; excluded by the stricter view. --- ## P053 — Building great SDKs **Citation.** Gergely Orosz; Quentin Pradet (2025-07-29). *Building great SDKs*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/building-great-sdks **Type of work.** Industry/practitioner publication — guest practitioner guidance. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Code quality & security; Engineering structure. **In short.** Quentin Pradet examines API-first design, SDK generation, documentation and ongoing maintenance for human and model consumers. **Summary.** Quentin Pradet examines API-first design, SDK generation, documentation and ongoing maintenance for human and model consumers. **Main findings — reported material.** Clear contracts and robust libraries reduce integration friction; translating an SDK with an LLM does not remove language-specific correctness and maintenance work. **Classification and proposed placement.** General software engineering; sections 5.5, 4.3. SDK contracts and reusable interfaces support maintainable systems without directly measuring AI-generated code quality. **Second-audit outcome.** Classification and annotation retained after review. SDK-maintainer guidance supports API quality and compatibility, not AI-tool productivity claims. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. A section explicitly discusses LLM-assisted SDK generation; it is secondary to the broader SDK design guidance. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Quentin Pradet. **Secondary subject facets.** AI-assisted software development. --- ## P054 — What are Forward Deployed Engineers, and why are they so in demand? **Citation.** Gergely Orosz (2025-08-12). *What are Forward Deployed Engineers, and why are they so in demand?*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers **Type of work.** Industry/practitioner publication — role analysis with interviews. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Jobs & roles; Engineering structure. **In short.** Interviews and job descriptions explain customer-embedded engineering, product feedback and AI integration responsibilities. **Summary.** Interviews and job descriptions explain customer-embedded engineering, product feedback and AI integration responsibilities. **Main findings — reported material.** The role combines implementation and domain discovery, with substantial variation between employers; demand examples are not a universal career forecast. **Classification and proposed placement.** AI-sector and organizational context; sections 12.5, 11.2. FDE role design links technical integration to customer work; demand claims do not establish universal career advantages. **Second-audit outcome.** Classification and annotation retained after review. FDE role includes customer integration beyond AI; AI-ecosystem framing is valid but not exclusive. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P055 — New trend: extreme hours at AI startups **Citation.** Gergely Orosz (2025-08-14). *New trend: extreme hours at AI startups*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/new-trend-extreme-hours-at-ai-startups/ **Type of work.** Industry/practitioner publication — reported work culture analysis. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Jobs & roles; Engineering structure. **In short.** Collects public hiring language and leadership accounts of demanding work schedules at AI companies, questioning the incentives used to justify them. **Summary.** Collects public hiring language and leadership accounts of demanding work schedules at AI companies, questioning the incentives used to justify them. **Main findings — reported material.** Illustrates organizational pressure and sustainability risks; selected examples do not quantify prevalence or prove a causal productivity effect. **Classification and proposed placement.** AI-sector and organizational context; sections 11.2, 12.7. Reported working hours and incentives are organizational conditions, not productivity measurements or labor-law conclusions. **Second-audit outcome.** Classification and annotation retained after review. Long-hours accounts and burnout arguments are selected reporting, not a measured hours-to-output function. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Non-Pulse-titled excerpt. Updated 23 October 2025; legal assertions are not adopted as guidance. This non-Pulse-titled blog article is an excerpt of a Pulse issue originally published 2025-08-14. It passes the literal title-prefix rule; it is excluded by the optional stricter Pulse-origin filter. The parent issue is provenance only, not another P article. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Pulse-origin provenance.** Earlier issue 2025-08-14: https://newsletter.pragmaticengineer.com/p/the-pulse-142. Included by literal title-prefix rule; excluded by the stricter view. --- ## P056 — The Pragmatic Engineer 2025 Survey: What’s in your tech stack? Part 2 **Citation.** Gergely Orosz; Elin Nilsson (2025-08-19). *The Pragmatic Engineer 2025 Survey: What’s in your tech stack? Part 2*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/the-pragmatic-engineer-2025-survey-part-2 **Type of work.** Industry/practitioner publication — reader survey analysis. Evidence origin: ORIGINAL_VOLUNTARY_OBSERVATIONAL_SURVEY. **Streams.** Engineering structure; Productivity. **In short.** The second installment of the reader survey covers collaboration, project management, databases and backend infrastructure. **Summary.** The second installment of the reader survey covers collaboration, project management, databases and backend infrastructure. **Main findings — reported material.** Reported use and sentiment differ across tool categories and company sizes; these observations are not controlled tool comparisons. **Classification and proposed placement.** General software engineering; sections 11.1, 2.4. The second tools-survey installment describes the same respondent cohort's infrastructure choices. **Second-audit outcome.** Mapping retained; access/evidence annotation qualified. The reported gross 3,000-plus submissions and cleaned 2,997 retained responses refer to stages of the same reader survey, not separate datasets. No microdata recount was performed. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Same April–May 2025 respondent cohort as Parts 1 and 3. The reported gross 3,000-plus submissions and cleaned 2,997 retained responses refer to stages of the same reader survey, not separate datasets. No microdata recount was performed. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Elin Nilsson. **Shared source cohorts.** DATA:P:TECHSTACK_2025. --- ## P057 — Creative ways to fund open source projects **Citation.** Gergely Orosz (2025-08-21). *Creative ways to fund open source projects*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/creative-ways-to-fund-open-source-projects/ **Type of work.** Industry/practitioner publication — reported maintenance economics. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Economics; Engineering structure. **In short.** Examines maintenance-fee and other funding mechanisms for open-source work, including the burden of supporting users and reviewing contributions. **Summary.** Examines maintenance-fee and other funding mechanisms for open-source work, including the burden of supporting users and reviewing contributions. **Main findings — reported material.** Separates software availability from the recurring cost of stewardship. The examples do not establish that a particular fee model generalizes to every project. **Classification and proposed placement.** General software engineering; sections 12.8, 11.7. Open-source funding affects maintenance capacity; the cases do not independently quantify AI's effects on sustainability. **Second-audit outcome.** Classification and annotation retained after review. OSS sustainability examples are financing practices, not randomized economic comparisons. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Updated 22 August 2025. No legal-compliance conclusion is independently evaluated. This non-Pulse-titled blog article is an excerpt of a Pulse issue originally published 2025-08-21. It passes the literal title-prefix rule; it is excluded by the optional stricter Pulse-origin filter. The parent issue is provenance only, not another P article. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Pulse-origin provenance.** Earlier issue 2025-08-21: https://newsletter.pragmaticengineer.com/p/the-pulse-143. Included by literal title-prefix rule; excluded by the stricter view. --- ## P058 — How experienced engineers get unstuck in coding interviews **Citation.** Gergely Orosz; Mike Mroczka (2025-08-26). *How experienced engineers get unstuck in coding interviews*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/how-to-get-unstuck-during-coding-interviews **Type of work.** Industry/practitioner publication — guest practitioner guidance. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Skills & learning; Jobs & roles. **In short.** Mike Mroczka presents structured problem-solving and practice advice against a changing interview landscape affected by AI assistance. **Summary.** Mike Mroczka presents structured problem-solving and practice advice against a changing interview landscape affected by AI assistance. **Main findings — reported material.** Preparation can improve interview performance, but interview success and real-world engineering competence are distinct constructs. **Classification and proposed placement.** General software engineering; sections 10.8, 12.5. Interview problem-solving guidance addresses competence demonstration rather than retained learning or AI-tool efficacy. **Second-audit outcome.** Classification and annotation retained after review. Interview problem-solving guidance remains general skills; avoid treating coaching advice as validated hiring outcomes. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Mike Mroczka. --- ## P059 — State of the software engineering job market in 2025, part 1, what the data says **Citation.** Gergely Orosz (2025-09-02). *State of the software engineering job market in 2025, part 1, what the data says*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/state-of-the-tech-market-in-2025 **Type of work.** Industry/practitioner publication — labor market data report. Evidence origin: SECONDARY_OR_PROVIDER_DATA_ANALYSIS. **Streams.** Jobs & roles; Economics. **In short.** Recruitment and employment datasets are assembled to examine engineering hiring, AI roles, tenure, location and management layers. **Summary.** Recruitment and employment datasets are assembled to examine engineering hiring, AI roles, tenure, location and management layers. **Main findings — reported material.** Coverage differs between job postings, observed employment changes and company headcounts. Their trends do not isolate AI effects on employment. **Classification and proposed placement.** Labor-market and recruiting context; sections 12.5, 12.6. The data-led labor report requires separating vacancy, workforce and seniority measures before causal interpretation. **Second-audit outcome.** Classification and annotation retained after review. Provider-specific vacancy and employment data have distinct denominators and selection mechanisms. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P060 — Inside Google's Engineering Culture: Part 1 **Citation.** Gergely Orosz; Elin Nilsson (2025-09-09). *Inside Google's Engineering Culture: Part 1*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/google **Type of work.** Industry/practitioner publication — reported company case. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure; System knowledge & memory. **In short.** Research and interviews with current and former Google engineers describe roles, hiring, career structures and shared engineering practices. **Summary.** Research and interviews with current and former Google engineers describe roles, hiring, career structures and shared engineering practices. **Main findings — reported material.** The visible overview emphasizes common infrastructure alongside team variation. Detailed company claims behind the paywall remain unverified in this review. **Classification and proposed placement.** General software engineering; sections 11.2, 9.4. Google interview accounts contextualize engineering coordination and ownership, not a representative industry baseline. **Second-audit outcome.** Classification and annotation retained after review. Company culture overview explicitly cannot represent all teams; retain sampling and within-company variation caveats. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Outline-level preview; shared research with Part 2. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Elin Nilsson. **Shared source cohorts.** DATA:P:GOOGLE_INTERVIEWS_2025. --- ## P061 — How tech companies measure the impact of AI on software development **Citation.** Gergely Orosz; Laura Tacho (2025-09-16). *How tech companies measure the impact of AI on software development*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/how-tech-companies-measure-the-impact-of-ai **Type of work.** Industry/practitioner publication — multi company measurement report. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Productivity; Economics. **In short.** Laura Tacho presents company measurement practices combining adoption, delivery, quality and developer experience, with baseline and segmentation guidance. **Summary.** Laura Tacho presents company measurement practices combining adoption, delivery, quality and developer experience, with baseline and segmentation guidance. **Main findings — reported material.** Metrics should constrain one another: output alone cannot establish net value. The framework and cases are practitioner evidence, not a new randomized evaluation. **Classification and proposed placement.** AI-assisted software development; sections 2.8, 12.4. Multi-company measurement practices combine delivery, quality and developer experience; commercial affiliations remain explicit. **Second-audit outcome.** Classification and annotation retained after review. Measurement guidance is not a causal effect estimate; preserve DX relationships and underlying-source dependencies. **Access and limitations.** Public main article available; classification-bearing passages reviewed. At publication Orosz disclosed investment in DX and Tacho was DX CTO; article states it was not sponsored. The source discloses Laura Tacho’s DX role and Orosz’s investment in DX. Company measurement practices are not a new randomized causal estimate. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Laura Tacho. **W/O relations.** W023 (REPORTS_EXISTING_RESEARCH): The public article explicitly cites the METR study as a contrasting productivity result; not an independent replication. W010 (EDITORIAL_COMPARISON_NOT_CITATION): A measurement portfolio should separate changes generated, changes shipped and downstream value. W145 (EDITORIAL_COMPARISON_NOT_CITATION): Measurement inputs can inform ROI modeling; neither framework supplies a calibrated production pilot for this book. --- ## P062 — How Claude Code is built **Citation.** Gergely Orosz (2025-09-23). *How Claude Code is built*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/how-claude-code-is-built **Type of work.** Industry/practitioner publication — reported company case. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** What agents can do; Engineering structure. **In short.** Interviews with founding engineers explain tool access, stack choices, rapid prototyping, subagents and internal verification practices. **Summary.** Interviews with founding engineers explain tool access, stack choices, rapid prototyping, subagents and internal verification practices. **Main findings — reported material.** The case links capability to the surrounding harness and team workflow. Company estimates of generated code and release speed are not controlled productivity results. **Classification and proposed placement.** AI-assisted software development; sections 3.6, 11.2. The creator case explains harness and feedback design, without independently validating vendor effectiveness claims. **Second-audit outcome.** Classification and annotation retained after review. Mixed product/tool-building and internal AI-first workflow account; add AI-product engineering as a secondary facet. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Secondary subject facets.** Engineering AI systems. **W/O relations.** O013 (EDITORIAL_COMPARISON_NOT_CITATION): A harness-builder case and long-running-agent guidance address continuity and validation from different evidence perspectives. --- ## P063 — Inside Google’s Engineering Culture: the Tech Stack (Part 2) **Citation.** Gergely Orosz; Elin Nilsson (2025-09-30). *Inside Google’s Engineering Culture: the Tech Stack (Part 2)*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/google-part-2 **Type of work.** Industry/practitioner publication — reported company case. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure; System knowledge & memory. **In short.** Interviews and source research describe Google’s internal infrastructure, monorepo, development tools and AI integration. **Summary.** Interviews and source research describe Google’s internal infrastructure, monorepo, development tools and AI integration. **Main findings — reported material.** A coherent internal platform can support scale while imposing complexity on new projects. Company-specific practices require contextual transfer. **Classification and proposed placement.** General software engineering; sections 5.5, 9.4. The second Google installment extends shared interview reporting into tooling and architecture. **Second-audit outcome.** Classification and annotation retained after review. Google's internal stack is a company-specific case; no automatic transfer to smaller teams. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Shares interviews and research with Google culture Part 1; not an independent replication. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Elin Nilsson. **Secondary subject facets.** AI-assisted software development. **Shared source cohorts.** DATA:P:GOOGLE_INTERVIEWS_2025. --- ## P064 — State of the software engineering jobs market, 2025, part 2 what hiring managers see **Citation.** Gergely Orosz (2025-10-07). *State of the software engineering jobs market, 2025, part 2 what hiring managers see*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/state-of-the-tech-market-in-2025-hiring-managers **Type of work.** Industry/practitioner publication — labor market interviews. Evidence origin: SECONDARY_OR_PROVIDER_DATA_ANALYSIS. **Streams.** Jobs & roles. **In short.** Interviews with hiring managers and recruiters examine application volumes, referrals, product-engineering demand and fraudulent applicants. **Summary.** Interviews with hiring managers and recruiters examine application volumes, referrals, product-engineering demand and fraudulent applicants. **Main findings — reported material.** The reporting challenges a single-cause AI explanation for difficult hiring. Employer testimony is not representative population evidence. **Classification and proposed placement.** Labor-market and recruiting context; sections 12.5. Labor-market interviews describe recruitment signals and uneven opportunities; AI is one contextual factor, not an isolated causal effect or a measured software-development intervention. **Second-audit outcome.** Classification and annotation retained after review. Hiring managers' accounts are contextual and selected; article does not isolate AI as the market's cause. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Secondary subject facets.** Ai hiring and assessment. --- ## P065 — The Pragmatic Engineer 2025 Survey: What’s in your tech stack? Part 3 **Citation.** Gergely Orosz; Elin Nilsson (2025-10-14). *The Pragmatic Engineer 2025 Survey: What’s in your tech stack? Part 3*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/the-pragmatic-engineer-2025-survey-part-3 **Type of work.** Industry/practitioner publication — reader survey analysis. Evidence origin: ORIGINAL_VOLUNTARY_OBSERVATIONAL_SURVEY. **Streams.** Engineering structure. **In short.** The final part of the 2025 reader survey covers observability, incident management, frontend tools and experimentation platforms. **Summary.** The final part of the 2025 reader survey covers observability, incident management, frontend tools and experimentation platforms. **Main findings — reported material.** Tool mentions describe the responding readership; popularity is not evidence of technical superiority or measured productivity. **Classification and proposed placement.** General software engineering; sections 11.1. The third tools-survey installment extends the same dataset to observability and frontend systems. **Second-audit outcome.** Mapping retained; access/evidence annotation qualified. The reported gross 3,000-plus submissions and cleaned 2,997 retained responses refer to stages of the same reader survey, not separate datasets. No microdata recount was performed. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Same April–May 2025 survey cohort as Parts 1 and 2; do not count as independent studies. The reported gross 3,000-plus submissions and cleaned 2,997 retained responses refer to stages of the same reader survey, not separate datasets. No microdata recount was performed. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Elin Nilsson. **Shared source cohorts.** DATA:P:TECHSTACK_2025. --- ## P066 — What is good software architecture? **Citation.** Gergely Orosz; Matthew Hawthorne (2025-10-21). *What is good software architecture?*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/what-is-good-software-architecture **Type of work.** Industry/practitioner publication — guest practitioner guidance. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Engineering structure; Code quality & security. **In short.** Matthew Hawthorne discusses architectural tradeoffs, operational learning and shared responsibility using Netflix examples. **Summary.** Matthew Hawthorne discusses architectural tradeoffs, operational learning and shared responsibility using Netflix examples. **Main findings — reported material.** Architecture should improve the problems a team faces rather than merely reorganize code; formal architect titles are not a prerequisite. **Classification and proposed placement.** General software engineering; sections 5.5, 5.9. Architectural principles clarify long-term changeability; they are not an empirical comparison of agent designs. **Second-audit outcome.** Classification and annotation retained after review. Hawthorne's architectural guidance is experience-based, not a validated universal architecture ranking. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Matthew Hawthorne. **W/O relations.** W059 (EDITORIAL_COMPARISON_NOT_CITATION): Architectural principles clarify how to interpret generated architecture smells; normative guidance is not an empirical replication. --- ## P067 — What caused the large AWS outage? **Citation.** Gergely Orosz (2025-10-23). *What caused the large AWS outage?*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/aws-outage-us-east-1/ **Type of work.** Industry/practitioner publication — incident analysis. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Code quality & security; Engineering structure. **In short.** Explains a DynamoDB DNS race and the cascading effects of shared service dependencies using the provider’s incident account. **Summary.** Explains a DynamoDB DNS race and the cascading effects of shared service dependencies using the provider’s incident account. **Main findings — reported material.** Useful for illustrating stale concurrent actions, dependency amplification and recovery design. It does not demonstrate an AI-caused incident. **Classification and proposed placement.** General software engineering; sections 5.6, 11.6. The outage concerns a conventional infrastructure failure; no AI origin or AI-specific causal mechanism is inferred. **Second-audit outcome.** Classification and annotation retained after review. Secondary interpretation of AWS postmortem; incident-specific chronology is not a general failure probability. **Access and limitations.** Public main article available; classification-bearing passages reviewed. This non-Pulse-titled blog article is an excerpt of a Pulse issue originally published 2025-10-23. It passes the literal title-prefix rule; it is excluded by the optional stricter Pulse-origin filter. The parent issue is provenance only, not another P article. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Pulse-origin provenance.** Earlier issue 2025-10-23: https://newsletter.pragmaticengineer.com/p/the-pulse-aws-takes-down-a-good-part. Included by literal title-prefix rule; excluded by the stricter view. --- ## P068 — San Francisco is back as the world’s leading tech hub **Citation.** Gergely Orosz (2025-10-28). *San Francisco is back as the world’s leading tech hub*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/san-francisco-is-back **Type of work.** Industry/practitioner publication — field visit report. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Jobs & roles; Economics. **In short.** Visits to AI companies and local events inform an account of development practices, hiring and geographic concentration. **Summary.** Visits to AI companies and local events inform an account of development practices, hiring and geographic concentration. **Main findings — reported material.** The piece offers situated observations about a technology cluster, not a systematic ranking of cities or a causal test of colocation. **Classification and proposed placement.** AI-sector and organizational context; sections 12.8, 12.5. Field observations concern geographic concentration of AI-related activity, not a quantified global ranking. **Second-audit outcome.** Classification and annotation retained after review. Site visits support AI-ecosystem context; geographic dominance and growth remain attributed interpretations. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Secondary subject facets.** AI-assisted software development. --- ## P069 — Comparing interviews at 8 large tech companies **Citation.** Gergely Orosz (2025-10-30). *Comparing interviews at 8 large tech companies*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/comparing-interviews-at-8-large-tech-companies/ **Type of work.** Industry/practitioner publication — single participant interview report. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Skills & learning; Jobs & roles. **In short.** Compares a principal-level candidate’s interviews, emphasizing systems design, behavioral assessment and company-specific processes. **Summary.** Compares a principal-level candidate’s interviews, emphasizing systems design, behavioral assessment and company-specific processes. **Main findings — reported material.** Demonstrates variation in assessment and leveling from one candidate’s experience, not comparative company hiring success rates. **Classification and proposed placement.** General software engineering; sections 10.8, 12.5. One candidate's multi-company comparison illustrates assessment variation and cannot estimate industry prevalence. **Second-audit outcome.** Classification and annotation retained after review. One candidate's multi-company comparison supports interview-context illustration, not company-level representative estimates. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Excerpt of Pulse #149, retained because its standalone title is not The Pulse. This non-Pulse-titled blog article is an excerpt of a Pulse issue originally published 2025-10-09. It passes the literal title-prefix rule; it is excluded by the optional stricter Pulse-origin filter. The parent issue is provenance only, not another P article. The interview counts concern one pseudonymous candidate across multiple companies, not dozens of independent candidates. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Pulse-origin provenance.** Earlier issue 2025-10-09: https://newsletter.pragmaticengineer.com/p/the-pulse-149-new-trend-programming. Included by literal title-prefix rule; excluded by the stricter view. --- ## P070 — New trend: programming by kicking off parallel AI agents **Citation.** Gergely Orosz (2025-10-30). *New trend: programming by kicking off parallel AI agents*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/new-trend-programming-by-kicking-off-parallel-ai-agents/ **Type of work.** Industry/practitioner publication — reported practice commentary. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** What agents can do; Engineering structure. **In short.** Discusses concurrent coding-agent workflows through practitioner accounts, contrasting parallel task execution with the serial attention needed to review and land changes. **Summary.** Discusses concurrent coding-agent workflows through practitioner accounts, contrasting parallel task execution with the serial attention needed to review and land changes. **Main findings — reported material.** Suggests task partitioning and coordination skills may matter more as agents multiply. Benefits and cognitive costs are hypotheses rather than measured comparative outcomes. **Classification and proposed placement.** AI-assisted software development; sections 3.7, 11.5. Parallel agent dispatch creates coordination and verification demands; number of agents is not proof of productivity. **Second-audit outcome.** Classification and annotation retained after review. Article explicitly leaves parallel-agent productivity unresolved; retain review-capacity and selection caveats. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Excerpt of Pulse #149; shares that issue, not the content of the separate interview-comparison article. This non-Pulse-titled blog article is an excerpt of a Pulse issue originally published 2025-10-09. It passes the literal title-prefix rule; it is excluded by the optional stricter Pulse-origin filter. The parent issue is provenance only, not another P article. The public account explicitly reuses the Sid Bidasaria conversation reported in P062. It is a different article, not independent interview evidence. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **W/O relations.** O025 (EDITORIAL_COMPARISON_NOT_CITATION): Parallel-agent operation creates coordination work; forecasts and examples do not establish net speedup. O010 (EDITORIAL_COMPARISON_NOT_CITATION): Agent count and delegated authority are separate dimensions; no tested maturity ordering is inferred. **P-series reporting relations.** P062 (REUSES_INTERVIEW_MATERIAL): Both use the Sid Bidasaria conversation; the later article asks a different parallel-agent workflow question. **Pulse-origin provenance.** Earlier issue 2025-10-09: https://newsletter.pragmaticengineer.com/p/the-pulse-149-new-trend-programming. Included by literal title-prefix rule; excluded by the stricter view. --- ## P071 — Tech jobs market 2025, part 3: job seekers’ stories **Citation.** Gergely Orosz (2025-11-04). *Tech jobs market 2025, part 3: job seekers’ stories*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/tech-jobs-market-2025-part-3 **Type of work.** Industry/practitioner publication — labor market reporting. Evidence origin: SECONDARY_OR_PROVIDER_DATA_ANALYSIS. **Streams.** Jobs & roles. **In short.** Job-seeker interviews and recruitment-platform observations describe uneven demand by experience, specialization and location. **Summary.** Job-seeker interviews and recruitment-platform observations describe uneven demand by experience, specialization and location. **Main findings — reported material.** Applicant experience and platform activity reveal different parts of the market. They do not by themselves identify AI-caused displacement. **Classification and proposed placement.** Labor-market and recruiting context; sections 12.5. Labor-market interviews describe recruitment signals and uneven opportunities; AI is one contextual factor, not an isolated causal effect or a measured software-development intervention. **Second-audit outcome.** Classification and annotation retained after review. Job-seeker accounts and platform statistics are distinct sources; not an isolated AI displacement estimate. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Secondary subject facets.** Ai hiring and assessment. --- ## P072 — Four years on writing a tech book: pitching to a publisher **Citation.** Gergely Orosz (2025-11-11). *Four years on writing a tech book: pitching to a publisher*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/four-years-on-writing-a-tech-book-pitching-to-a-publisher/ **Type of work.** Industry/practitioner publication — first person publishing case. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** No forced thematic assignment. **In short.** Recounts technical-book pitching, publisher collaboration, commercial terms and the eventual choice to self-publish. **Summary.** Recounts technical-book pitching, publisher collaboration, commercial terms and the eventual choice to self-publish. **Main findings — reported material.** Offers an individual publishing case and editorial lessons, not evidence about AI-assisted software engineering. **Classification and proposed placement.** Catalogue-only material; sections none. The author explains book pitching; keep the publishing record separate from software-engineering evidence. **Second-audit outcome.** Classification and annotation retained after review. Publishing retrospective remains catalogue-only; historical experiences do not change article publication eligibility. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P073 — Career paths for software engineers at large tech companies **Citation.** Gergely Orosz; Ethan Evans (2025-11-18). *Career paths for software engineers at large tech companies*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/career-paths-for-software-engineers **Type of work.** Industry/practitioner publication — guest practitioner guidance. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Jobs & roles; Skills & learning. **In short.** Ethan Evans discusses progression through technical and management tracks, independent execution and organizational scope. **Summary.** Ethan Evans discusses progression through technical and management tracks, independent execution and organizational scope. **Main findings — reported material.** Career expectations depend on role and company context. Retrospective promotion advice is not a validated competence rubric or an AI-specific labor forecast. **Classification and proposed placement.** General software engineering; sections 11.2, 10.7. Career-path advice concerns scope and responsibility, without demonstrating measured productivity or learning effects. **Second-audit outcome.** Classification and annotation retained after review. Promotion advice based on one former executive's experience is not validated career-outcome evidence. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Ethan Evans. --- ## P074 — A startup in Mongolia translated my book **Citation.** Gergely Orosz (2025-11-21). *A startup in Mongolia translated my book*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/traveling-to-mongolia/ **Type of work.** Industry/practitioner publication — first person company visit. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** No forced thematic assignment. **In short.** Describes Nasha Tech’s staged translation and technical review of the author’s book, alongside observations of its development tools and local product work. **Summary.** Describes Nasha Tech’s staged translation and technical review of the author’s book, alongside observations of its development tools and local product work. **Main findings — reported material.** Shows one organization investing in shared engineering knowledge and language access. No measured learning or productivity effect is established. **Classification and proposed placement.** Catalogue-only material; sections none. A translation announcement concerns access to a book; it provides no evaluated learning outcome. **Second-audit outcome.** Classification and annotation retained after review. Book translation/travel account remains catalogue-only. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Author has a direct interest in the book; updated 24 November 2025. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P075 — A pragmatic guide to LLM evals for devs **Citation.** Gergely Orosz; Hamel Husain (2025-12-02). *A pragmatic guide to LLM evals for devs*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/evals **Type of work.** Industry/practitioner publication — guest practitioner method. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Verification & review; Engineering structure. **In short.** Hamel Husain describes error analysis, deterministic checks, judge evaluation and production feedback for LLM applications. **Summary.** Hamel Husain describes error analysis, deterministic checks, judge evaluation and production feedback for LLM applications. **Main findings — reported material.** Judge outputs need comparison with human expertise and held-out data; an apparent successful demonstration is not a robust evaluation. **Classification and proposed placement.** Engineering AI systems; sections 7.2, 7.7. LLM application evaluation offers transferable checker-design ideas, but software acceptance requires software-specific oracles. **Second-audit outcome.** Classification and annotation retained after review. LLM evals guidance primarily concerns AI applications; not a coding-agent acceptance experiment. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Hamel Husain. **W/O relations.** W084 (EDITORIAL_METHOD_COMPARISON): Judge calibration connects to self-preference bias, but the W study's dialogue setting differs from software acceptance. W102 (EDITORIAL_METHOD_COMPARISON): Independent/cross-model checking still needs an external reference; topical comparison only, not a claimed citation. --- ## P076 — Downdetector and the real cost of no upstream dependencies **Citation.** Gergely Orosz (2025-12-05). *Downdetector and the real cost of no upstream dependencies*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/downdetector-and-the-real-cost-of-no-upstream-dependencies/ **Type of work.** Industry/practitioner publication — reported architecture case. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Economics; Engineering structure. **In short.** Uses an interview with Downdetector engineering leadership to examine why a multi-cloud monitoring service still depended on Cloudflare. **Summary.** Uses an interview with Downdetector engineering leadership to examine why a multi-cloud monitoring service still depended on Cloudflare. **Main findings — reported material.** Reliability depends on the complete dependency chain; removing a dependency can carry substantial cost and operational burden. This is a contextual trade-off, not proof that redundancy is unnecessary. **Classification and proposed placement.** General software engineering; sections 12.1, 5.5. An availability architecture trades dependency risk against operational cost; it is not an AI-specific ROI study. **Second-audit outcome.** Classification and annotation retained after review. Pulse-derived excerpt explicitly preserved; multi-cloud architecture can retain a common upstream dependency. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Non-Pulse-titled public excerpt of Pulse #154. This non-Pulse-titled blog article is an excerpt of a Pulse issue originally published 2025-11-20. It passes the literal title-prefix rule; it is excluded by the optional stricter Pulse-origin filter. The parent issue is provenance only, not another P article. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Pulse-origin provenance.** Earlier issue 2025-11-20: https://newsletter.pragmaticengineer.com/p/the-pulse-154. Included by literal title-prefix rule; excluded by the stricter view. --- ## P077 — Building MCP servers in the real world **Citation.** Gergely Orosz; Elin Nilsson (2025-12-09). *Building MCP servers in the real world*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/mcp-deepdive **Type of work.** Industry/practitioner publication — multi practitioner survey and interviews. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure; Code quality & security. **In short.** Developer accounts and maintainer interviews examine internal MCP adoption, debugging, legacy systems and tool-interface design. **Summary.** Developer accounts and maintainer interviews examine internal MCP adoption, debugging, legacy systems and tool-interface design. **Main findings — reported material.** Internal use can differ from public visibility; expanded tool access also requires security boundaries. The collected accounts are not a representative adoption census. **Classification and proposed placement.** AI-assisted software development; sections 6.7, 3.2. Accounts from MCP implementers and maintainers explain interface design, integration and trust boundaries. Security is important but not the sole subject; detailed paid content remains unreviewed. **Second-audit outcome.** Classification and annotation retained after review. 46 developer contributors and expert interviews are reported practice; protocol adoption is not proof of secure deployment. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Elin Nilsson. **Secondary subject facets.** Engineering AI systems. **W/O relations.** O040 (EDITORIAL_COMPARISON_NOT_CITATION): Real server integrations complement a protocol explanation while requiring separate trust and authorization checks. --- ## P078 — Frictionless: why great developer experience can help teams win in the ‘AI age’ **Citation.** Gergely Orosz (introduction/interview); Nicole Forsgren; Abi Noda (excerpts) (2025-12-10). *Frictionless: why great developer experience can help teams win in the ‘AI age’*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/frictionless-why-great-developer **Type of work.** Industry/practitioner publication — introduced guest book excerpt. Evidence origin: ADAPTED_OR_EXCERPTED_WORK. **Streams.** Productivity; Engineering structure. **In short.** An interview and excerpts from Nicole Forsgren and Abi Noda connect developer friction, organizational change and meaningful measurement. **Summary.** An interview and excerpts from Nicole Forsgren and Abi Noda connect developer friction, organizational change and meaningful measurement. **Main findings — reported material.** Faster generation need not remove delivery bottlenecks. The introduced book explicitly distinguishes practitioner guidance from the research foundations of Accelerate. **Classification and proposed placement.** AI-assisted software development; sections 2.7, 11.1. Developer-friction guidance connects individual workflow to organizational delivery; a book excerpt is not a fresh experiment. **Second-audit outcome.** Classification and annotation retained after review. Forsgren/Noda book excerpts require original-author roles; Orosz's introduction is a separate contribution. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz (introduction/interview); Nicole Forsgren; Abi Noda (excerpts). **W/O relations.** W024 (EDITORIAL_COMPARISON_NOT_CITATION): Organizational capability and developer friction contextualize adoption; the excerpt is not another DORA experiment. --- ## P079 — How AWS deals with a major outage **Citation.** Gergely Orosz (2025-12-16). *How AWS deals with a major outage*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/how-aws-deals-with-a-major-outage **Type of work.** Industry/practitioner publication — incident response interview. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Code quality & security; Engineering structure. **In short.** An incident responder explains AWS’s October outage, mitigation coordination, lock contention and planned verification improvements. **Summary.** An incident responder explains AWS’s October outage, mitigation coordination, lock contention and planned verification improvements. **Main findings — reported material.** The account grounds reliability in system behavior and response practices rather than unsupported staffing explanations. It is an insider post-incident account, not an AI productivity study. **Classification and proposed placement.** General software engineering; sections 11.6, 5.6. Incident-response reporting illustrates operational coordination and learning, without testing AI-generated recovery strategies. **Second-audit outcome.** Classification and annotation retained after review. Named incident responder's account adds perspective to P067, not an independent incident sample. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **P-series reporting relations.** P067 (REVISITS_SAME_REPORTED_INCIDENT): Inside response account and earlier cause discussion concern the same October 2025 AWS outage; not two incidents. --- ## P080 — When AI writes almost all code, what happens to software engineering? **Citation.** Gergely Orosz (2026-01-06). *When AI writes almost all code, what happens to software engineering?*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/when-ai-writes-almost-all-code-what **Type of work.** Industry/practitioner publication — practitioner forecast. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Engineering structure; Skills & learning. **In short.** Orosz combines bounded personal experiments and practitioner accounts to discuss the shift from typing code toward product judgment, verification and coordination. **Summary.** Orosz combines bounded personal experiments and practitioner accounts to discuss the shift from typing code toward product judgment, verification and coordination. **Main findings — reported material.** The essay forecasts role changes while acknowledging quality and workload risks; low-risk tested examples do not prove equivalent results in all production settings. **Classification and proposed placement.** AI-assisted software development; sections 1.3, 10.2. Changed code-production practices redistribute work and identity while retaining the need for understanding. **Second-audit outcome.** Classification and annotation retained after review. First-person production example includes review and tests; it does not measure universal autonomous-code reliability. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Originally paid; made public September 24. Use original January publication date. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **W/O relations.** O005 (EDITORIAL_COMPARISON_NOT_CITATION): Human judgment can move toward scope and acceptance even when less code is written manually. **Alternate editions, not extra records.** https://blog.pragmaticengineer.com/the-grief-when-ai-writes-most-of-the-code/ --- ## P081 — Design Systems for Software Engineers **Citation.** Gergely Orosz; Michael Abernethy (2026-01-13). *Design Systems for Software Engineers*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/design-systems-for-software-engineers **Type of work.** Industry/practitioner publication — guest practitioner case. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure; System knowledge & memory. **In short.** A Rubrik practitioner account explains shared UI components, ownership and when a design-system investment makes sense, including AI-assisted implementation. **Summary.** A Rubrik practitioner account explains shared UI components, ownership and when a design-system investment makes sense, including AI-assisted implementation. **Main findings — reported material.** Consistent components and design rules require maintained shared knowledge; generating UI code alone does not create a coherent design system. **Classification and proposed placement.** General software engineering; sections 5.5, 9.5. Design-system architecture, component reuse and ownership are general software-engineering concerns. A secondary AI-assisted-development section offers context, not an AI-specific controlled comparison. **Second-audit outcome.** Classification and annotation retained after review. Design-system guidance is principally general engineering with an AI facet; do not force AI-only classification. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Michael Abernethy. **Secondary subject facets.** AI-assisted software development. **W/O relations.** O018 (EDITORIAL_COMPARISON_NOT_CITATION): Reusable design constraints can help specifications, without making generated specifications authorized intentions. --- ## P082 — The Product-Minded Engineer: The importance of good errors and warnings **Citation.** Gergely Orosz (interview/introduction); Drew Hoskins (excerpt) (2026-01-20). *The Product-Minded Engineer: The importance of good errors and warnings*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/the-product-minded-engineer **Type of work.** Industry/practitioner publication — introduced guest book excerpt. Evidence origin: ADAPTED_OR_EXCERPTED_WORK. **Streams.** Engineering structure; Code quality & security. **In short.** An interview and Drew Hoskins book excerpt examine diagnostics as a user interface, including feedback consumed by autonomous agents. **Summary.** An interview and Drew Hoskins book excerpt examine diagnostics as a user interface, including feedback consumed by autonomous agents. **Main findings — reported material.** Useful errors and scenario-based thinking connect implementation to user intent and actionable feedback; the advice is not an experimental comparison. **Classification and proposed placement.** General software engineering; sections 4.3, 5.1. Good error behavior links product intention to observable contracts and failure handling. **Second-audit outcome.** Classification and annotation retained after review. Drew Hoskins book excerpt concerns product judgment; preserve original content authorship and editorial introduction. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz (interview/introduction); Drew Hoskins (excerpt). --- ## P083 — Inside a five-year-old startup’s rapid AI makeover **Citation.** Gergely Orosz (2026-01-27). *Inside a five-year-old startup’s rapid AI makeover*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/ai-first-makeover-craft **Type of work.** Industry/practitioner publication — reported company case. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure; Productivity. **In short.** Craft’s move toward a shared visual agent interface is reported through workflows spanning engineering and nontechnical teams. **Summary.** Craft’s move toward a shared visual agent interface is reported through workflows spanning engineering and nontechnical teams. **Main findings — reported material.** The case illustrates workflow redesign and changing ownership. Delivery improvements and counterfactual timelines are company testimony, not controlled measurements. **Classification and proposed placement.** AI-assisted software development; sections 11.1, 2.4. A disclosed family-linked startup case illustrates adoption and workload redistribution, not a neutral representative sample. **Second-audit outcome.** Mapping retained; access/evidence annotation qualified. A June 27, 2026 access/acquisition update is separate from the January 2026 edition date; later promotional context must not be retroactively dated to the original article. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Author discloses a family relationship with Craft’s founder and no financial interest. Paywall removed in June; original publication remains January 27. Craft’s founder is identified as Orosz’s brother. This disclosed relationship and later update material must remain visible when using the company case. A June 27, 2026 access/acquisition update is separate from the January 2026 edition date; later promotional context must not be retroactively dated to the original article. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **W/O relations.** W007 (EDITORIAL_COMPARISON_NOT_CITATION): Context-specific adoption accounts cannot be pooled as universal enterprise effects. --- ## P084 — I replaced a $120/year micro-SaaS in 20 minutes with LLM-generated code **Citation.** Gergely Orosz (2026-01-29). *I replaced a $120/year micro-SaaS in 20 minutes with LLM-generated code*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/i-replaced-a-120-year-micro-saas-in-20-minutes-with-llm-generated-code/ **Type of work.** Industry/practitioner publication — first person case report. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Economics; Productivity. **In short.** Reports rebuilding a small testimonials feature with Codex, including planning, modular data, testing and deployment. **Summary.** Reports rebuilding a small testimonials feature with Codex, including planning, modular data, testing and deployment. The replacement covered a narrower personal use case than the original service. **Main findings — reported material.** Demonstrates a bounded build-versus-buy example, not the general replacement of SaaS. Maintenance, verification and changing compliance obligations remain outside the headline time comparison. **Classification and proposed placement.** AI-assisted software development; sections 12.1, 12.4. The personal build-versus-buy experiment has a narrow scope; the headline omits long-term maintenance and service equivalence. **Second-audit outcome.** Classification and annotation retained after review. One personal replacement demonstrates a build-versus-buy example; headline implementation minutes do not include lifecycle costs. **Access and limitations.** Public main article available; classification-bearing passages reviewed. The reported replacement covers the personal functionality the author used, not the complete SaaS product; lifecycle maintenance and opportunity costs were not measured. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **W/O relations.** O045 (EDITORIAL_COMPARISON_NOT_CITATION): A small personal build-versus-buy example illustrates, but does not establish, Osmani's personal-software market hypothesis. W145 (EDITORIAL_COMPARISON_NOT_CITATION): The headline implementation time omits lifecycle costs required by an ROI assessment. --- ## P085 — Deepdive: How 10 tech companies choose the next generation of dev tools **Citation.** Gergely Orosz (2026-02-03). *Deepdive: How 10 tech companies choose the next generation of dev tools*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/measuring-ai-dev-tools **Type of work.** Industry/practitioner publication — multi company case study. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Productivity; Verification & review. **In short.** Interviews compare tool-selection practices across company sizes, including locally scored AI review trials and procurement constraints. **Summary.** Interviews compare tool-selection practices across company sizes, including locally scored AI review trials and procurement constraints. **Main findings — reported material.** Tools differ by codebase and evaluation criteria. Reported comment scoring is more informative than raw usage, but the cases do not establish a universal vendor ranking. **Classification and proposed placement.** AI-assisted software development; sections 2.8, 3.9. Choosing coding tools requires fit-for-purpose evaluation; this is procurement/evaluation rather than primarily code review. **Second-audit outcome.** Classification and annotation retained after review. Selected company interviews, including anonymous contributors, describe procurement choices; not a randomized vendor comparison. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Company-local scoring exercises and tool selection are distinct from randomized productivity comparisons; evaluation samples and scoring scales are context-specific. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **W/O relations.** W008 (EDITORIAL_METHOD_COMPARISON): A controlled coding-task design is a methodological comparator for vendor evaluation, not evidence that these company selections were randomized. --- ## P086 — Steve Yegge on AI Agents and the Future of Software Engineering **Citation.** Gergely Orosz (2026-02-10). *Steve Yegge on AI Agents and the Future of Software Engineering*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/steve-yegge-on-ai-agents-and-the **Type of work.** Industry/practitioner publication — practitioner interview. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** What agents can do; Jobs & roles. **In short.** A written interview explores Yegge’s autonomy ladder, multi-agent work, fatigue and predictions about engineering employment. **Summary.** A written interview explores Yegge’s autonomy ladder, multi-agent work, fatigue and predictions about engineering employment. **Main findings — reported material.** These are provocative practitioner forecasts, not validated maturity levels or labor-market estimates. Higher autonomy is not established as inherently better. **Classification and proposed placement.** AI-assisted software development; sections 3.7, 11.2. Yegge's levels and forecasts describe a practitioner's model of agent work, not a validated maturity scale. **Second-audit outcome.** Classification and annotation retained after review. Yegge's stages are an interviewee framework, distinct from Osmani's agency/orchestration axes and not validated maturity levels. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Yegge’s eight stages are a provocative practitioner ladder, not a validated maturity scale and not Osmani’s independent agency/orchestration axes. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **W/O relations.** O010 (EDITORIAL_COMPARISON_NOT_CITATION): Yegge's stages and Osmani's axes are different practitioner frameworks; do not equate level labels or validation. --- ## P087 — How Codex is built **Citation.** Gergely Orosz (2026-02-17). *How Codex is built*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/how-codex-is-built **Type of work.** Industry/practitioner publication — reported company case. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** What agents can do; Engineering structure. **In short.** Interviews with Codex builders describe the agent loop, language choices, evaluation, internal use and tiered code review. **Summary.** Interviews with Codex builders describe the agent loop, language choices, evaluation, internal use and tiered code review. **Main findings — reported material.** The case connects capability with harness design and verification; team estimates of generated code and counterfactual delivery time should not be treated as measured causal effects. **Classification and proposed placement.** AI-assisted software development; sections 3.6, 7.8. The Codex case explains tool and verification design; vendor reports are not independent evaluations. **Second-audit outcome.** Classification and annotation retained after review. Codex interviews mix agent-product architecture and internal development workflow; retain both subject facets and separate them from measured effects. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Secondary subject facets.** Engineering AI systems. **W/O relations.** W095 (EDITORIAL_COMPARISON_NOT_CITATION): Harness capabilities need lifecycle verification and cost accounting beyond successful generation. --- ## P088 — The Future of Software Engineering with AI: Six Predictions **Citation.** Gergely Orosz (2026-02-24). *The Future of Software Engineering with AI: Six Predictions*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/the-future-of-software-engineering-with-ai **Type of work.** Industry/practitioner publication — conference synthesis. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Engineering structure; Jobs & roles. **In short.** Conference and workshop reporting considers organizational health, engineering careers, refactoring and Agile practices under AI adoption. **Summary.** Conference and workshop reporting considers organizational health, engineering careers, refactoring and Agile practices under AI adoption. **Main findings — reported material.** The synthesis argues that existing organizational conditions influence outcomes. Forecasts and quoted vendor data are not independent experiments. **Classification and proposed placement.** AI-assisted software development; sections 11.2, 12.8. Conference forecasts concern potential changes in engineering roles; they should remain forecasts. **Second-audit outcome.** Classification and annotation retained after review. Reporting draws on the Pragmatic Summit and a separate roughly 50-person workshop; selected participants are not an industry-wide consensus sample. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P089 — AI Tooling for Software Engineers in 2026 **Citation.** Gergely Orosz; Elin Nilsson (2026-03-03). *AI Tooling for Software Engineers in 2026*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/ai-tooling-2026 **Type of work.** Industry/practitioner publication — reader survey analysis. Evidence origin: ORIGINAL_VOLUNTARY_OBSERVATIONAL_SURVEY. **Streams.** Productivity; Engineering structure. **In short.** A survey of newsletter readers examines coding-tool adoption, model preferences, seniority and organizational differences. **Summary.** A survey of newsletter readers examines coding-tool adoption, model preferences, seniority and organizational differences. **Main findings — reported material.** The volunteer survey reports associations among tool use, role, company size and sentiment. Procurement explanations are author hypotheses, not identified causes; neither population market share nor causal productivity follows from these responses. **Classification and proposed placement.** AI-assisted software development; sections 2.4, 11.1. The reader survey measures reported usage and sentiment, not causal productivity or population-wide adoption. **Second-audit outcome.** Existing classification or proposed placement revised. All eight advertised survey sections and demographics are visible; paid material is an additional report. Adoption and organizational patterns inform observational adoption and team work, not a measured comprehension-debt claim. Avoid treating the author's procurement explanation as an established causal result. The author reports 906 responses for the shared 2026 cohort. This is not an independently counted sample; comparisons with other survey waves are not a matched longitudinal panel. The same page calls the paid supplement 65 pages near the beginning and 35 pages near the end. It also pairs 55% regular agent usage with 507 people; 507/906 is about 56%, so the response denominator or rounding needs clarification. Neither discrepancy is silently corrected. **Access and limitations.** Public main article available; separate paid supplementary material not reviewed. Survey ran January 27–February 17, 2026; same cohort as the two impact follow-ups. The author reports 906 responses for the shared 2026 cohort. This is not an independently counted sample; comparisons with other survey waves are not a matched longitudinal panel. The same page calls the paid supplement 65 pages near the beginning and 35 pages near the end. It also pairs 55% regular agent usage with 507 people; 507/906 is about 56%, so the response denominator or rounding needs clarification. Neither discrepancy is silently corrected. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Elin Nilsson. **W/O relations.** W020 (EDITORIAL_COMPARISON_NOT_CITATION): Both kinds of self-report need selection and recall cautions; datasets and populations remain distinct. **Shared source cohorts.** DATA:P:AI_SURVEY_2026. --- ## P090 — How Uber uses AI for development: inside look **Citation.** Gergely Orosz (2026-03-10). *How Uber uses AI for development: inside look*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/how-uber-uses-ai-for-development **Type of work.** Industry/practitioner publication — reported company case. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** System knowledge & memory; Engineering structure. **In short.** An industry case describes Uber’s AI development platform, shared context, internal agents and review-related tooling. **Summary.** An industry case describes Uber’s AI development platform, shared context, internal agents and review-related tooling. **Main findings — reported material.** The report describes internal tools, organizational context and patterns of agent adoption at Uber. These accounts suggest engineering dependencies worth testing elsewhere, but do not isolate the causal effect of platform integration on delivery outcomes. **Classification and proposed placement.** AI-assisted software development; sections 9.5, 11.2. Uber's internal integration and company context are operational conditions that limit transfer of reported results. **Second-audit outcome.** Mapping retained; access/evidence annotation qualified. Replace a causal-sounding platform claim with an attributed company observation. An author correction in the March 12, 2026 Pulse distinguishes the IDE-generated-code share from an earlier erroneous percentage. Original date, updated text and company-level denominators remain separate. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Original publication March 10; updated March 11. Reported adoption percentages use different denominators. Author discloses former employment at Uber. The source’s correction distinguishes 84% agentic-tool adoption from 65–72% IDE code-generation figures and CLI-specific measures; those denominators must not be interchanged. An author correction in the March 12, 2026 Pulse distinguishes the IDE-generated-code share from an earlier erroneous percentage. Original date, updated text and company-level denominators remain separate. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **W/O relations.** O002 (EDITORIAL_COMPARISON_NOT_CITATION): Internal company context and delegation boundaries are important in established codebases; case reports are not causal evidence. --- ## P091 — Are AI agents actually slowing us down? **Citation.** Gergely Orosz (2026-03-17). *Are AI agents actually slowing us down?*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/are-ai-agents-actually-slowing-us **Type of work.** Industry/practitioner publication — reported practitioner analysis. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Productivity; Code quality & security. **In short.** Orosz contrasts increased generation and pull-request activity with quality problems, cleanup, outages and organizational mandates. **Summary.** Orosz contrasts increased generation and pull-request activity with quality problems, cleanup, outages and organizational mandates. **Main findings — reported material.** Activity can rise without corresponding product value. Claims drawn from underlying studies require separate source verification before causal use. **Classification and proposed placement.** AI-assisted software development; sections 2.6, 8.1. The synthesis highlights downstream cleanup and review load rather than equating more generated changes with more value. **Second-audit outcome.** Classification and annotation retained after review. Reuses the Uber account and contrasts PR activity with quality; observational comparisons do not identify agent-caused changes. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Observed product bugs and the author’s inference that AI caused them are different claims. Visible anecdotes do not identify a causal quality effect. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **W/O relations.** W004 (EDITORIAL_COMPARISON_NOT_CITATION): Velocity and accumulated complexity can diverge; the synthesis does not resolve confounding in the underlying observational research. W010 (EDITORIAL_COMPARISON_NOT_CITATION): Higher pull-request activity is not automatically more shipped value. --- ## P092 — “How to be a 10x engineer” – interview with a standout dev **Citation.** Gergely Orosz (2026-03-24). *“How to be a 10x engineer” – interview with a standout dev*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/how-to-be-a-10x-engineer-interview **Type of work.** Industry/practitioner publication — practitioner interview. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Skills & learning; Engineering structure. **In short.** Interviews with an experienced engineer and a former manager explore ownership, task decomposition, communication and collaboration. **Summary.** Interviews with an experienced engineer and a former manager explore ownership, task decomposition, communication and collaboration. **Main findings — reported material.** The account illustrates effectiveness beyond code activity; the “10x” label is rhetorical rather than a measured multiplier. **Classification and proposed placement.** General software engineering; sections 10.8, 11.2. A standout engineer's experience motivates judgment and context; '10x' is not a measured effect size. **Second-audit outcome.** Classification and annotation retained after review. An anonymous engineer profile and former-manager account do not operationally measure a tenfold productivity effect. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. The 10x label is descriptive rhetoric around one selected developer, not a measured productivity multiplier. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P093 — Is the FDE role becoming less desirable? **Citation.** Gergely Orosz (2026-03-27). *Is the FDE role becoming less desirable?*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/is-the-fde-role-becoming-less-desirable/ **Type of work.** Industry/practitioner publication — reported role analysis. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Jobs & roles; Engineering structure. **In short.** Revisits forward-deployed engineering through two disappointed practitioners and external hiring coverage, contrasting role marketing with sales and customer-delivery duties. **Summary.** Revisits forward-deployed engineering through two disappointed practitioners and external hiring coverage, contrasting role marketing with sales and customer-delivery duties. **Main findings — reported material.** The examples qualify an earlier positive account: identical job titles can hide substantially different engineering responsibilities. They do not establish market-wide dissatisfaction rates. **Classification and proposed placement.** AI-sector and organizational context; sections 12.5, 11.2. A small set of dissatisfied accounts qualifies FDE enthusiasm; it does not estimate role-wide job satisfaction. **Second-audit outcome.** Classification and annotation retained after review. Retitled Pulse-derived discussion concerns the trade-offs and desirability of the FDE role; not a representative hiring-rate estimate. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Non-Pulse-titled blog excerpt; not a duplicate of the longer August 2025 Deepdive. This non-Pulse-titled blog article is an excerpt of a Pulse issue originally published 2026-03-19. It passes the literal title-prefix rule; it is excluded by the optional stricter Pulse-origin filter. The parent issue is provenance only, not another P article. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **P-series reporting relations.** P054 (QUALIFIES_PRIOR_REPORTING): Later FDE desirability reporting qualifies the earlier role-demand account; observations differ in time and scope. **Pulse-origin provenance.** Earlier issue 2026-03-19: https://newsletter.pragmaticengineer.com/p/the-pulse-is-the-fde-role-becoming. Included by literal title-prefix rule; excluded by the stricter view. --- ## P094 — What is inference engineering? Deepdive **Citation.** Gergely Orosz (introduction); Philip Kiely (guest excerpt) (2026-03-31). *What is inference engineering? Deepdive*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/what-is-inference-engineering **Type of work.** Industry/practitioner publication — introduced guest book excerpt. Evidence origin: ADAPTED_OR_EXCERPTED_WORK. **Streams.** Engineering structure; Economics. **In short.** An introduced excerpt by Philip Kiely explains serving models through batching, caching, quantization, parallel execution and autoscaling. **Summary.** An introduced excerpt by Philip Kiely explains serving models through batching, caching, quantization, parallel execution and autoscaling. **Main findings — reported material.** Inference engineering involves explicit latency, throughput and cost tradeoffs. This is engineering AI infrastructure, not evidence that coding assistants improve developer productivity. **Classification and proposed placement.** Engineering AI systems; sections 5.5, 12.1. Inference serving is engineering of AI infrastructure, distinct from using AI to generate application code. **Second-audit outcome.** Classification and annotation retained after review. Philip Kiely's book excerpt is inference-engineering guidance; preserve original author and distinguish vendor context from benchmark evidence. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz (introduction); Philip Kiely (guest excerpt). --- ## P095 — The impact of AI on software engineers in 2026: key trends. Part 1 **Citation.** Gergely Orosz; Elin Nilsson (2026-04-14). *The impact of AI on software engineers in 2026: key trends. Part 1*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/the-impact-of-ai-on-software-engineers-2026 **Type of work.** Industry/practitioner publication — reader survey analysis. Evidence origin: ORIGINAL_VOLUNTARY_OBSERVATIONAL_SURVEY. **Streams.** Economics; Jobs & roles. **In short.** A follow-up analysis of the 2026 reader survey examines tool costs, usage limits, developer identity and uneven changes to engineering work. **Summary.** A follow-up analysis of the 2026 reader survey examines tool costs, usage limits, developer identity and uneven changes to engineering work. **Main findings — reported material.** Reported attitudes and usage patterns vary substantially; editorial developer categories are not validated measures of ability. **Classification and proposed placement.** AI-assisted software development; sections 12.1, 11.1. Cost and identity findings extend the shared 2026 survey; editorial respondent categories are not validated competence measures. **Second-audit outcome.** Existing classification or proposed placement revised. Cost constraints and respondent-role patterns inform economics and organization, not measured comprehension debt. The author reports 906 responses for the shared 2026 cohort. This is not an independently counted sample; comparisons with other survey waves are not a matched longitudinal panel. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Uses the same respondent cohort as AI Tooling 2026 and key trends Part 2; not independent replication. Builders, shippers and coasters are interpretive response groupings, not a validated psychological or competency typology. The author reports 906 responses for the shared 2026 cohort. This is not an independently counted sample; comparisons with other survey waves are not a matched longitudinal panel. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Elin Nilsson. **W/O relations.** O045 (EDITORIAL_COMPARISON_NOT_CITATION): Cost and identity survey responses can contextualize personal-software hypotheses without establishing market-wide welfare effects. **Shared source cohorts.** DATA:P:AI_SURVEY_2026. --- ## P096 — Learnings from conducting ~1,000 interviews at Amazon **Citation.** Gergely Orosz; Steve Huynh (2026-04-21). *Learnings from conducting ~1,000 interviews at Amazon*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/learnings-from-conducting-1000-interviews **Type of work.** Industry/practitioner publication — guest practitioner essay and book excerpt. Evidence origin: ADAPTED_OR_EXCERPTED_WORK. **Streams.** Jobs & roles; Skills & learning. **In short.** Steve Huynh shares experience from technical and behavioral interviews, followed by an excerpt from his book. **Summary.** Steve Huynh shares experience from technical and behavioral interviews, followed by an excerpt from his book. The account emphasizes communication, demonstrated past work, role expectations and level calibration. **Main findings — reported material.** Interview readiness includes explaining decisions and collaboration, not just solving coding tasks. Recollections and advice do not establish the predictive validity of an interview rubric. **Classification and proposed placement.** General software engineering; sections 10.8, 12.5. Experienced interviewer guidance concerns assessment quality, not a controlled test of interview validity. **Second-audit outcome.** Classification and annotation retained after review. Steve Huynh's interview experience supports practical coaching, not a controlled study with one thousand independent research participants. **Access and limitations.** Public main article available; classification-bearing passages reviewed. The guest’s approximately one thousand interviews describe experience and authority, not a published validation dataset for the proposed interview approach. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Steve Huynh. --- ## P097 — How will AI change operating systems? Part 1: Ubuntu and Linux **Citation.** Gergely Orosz (2026-04-28). *How will AI change operating systems? Part 1: Ubuntu and Linux*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/ubuntu-and-ai **Type of work.** Industry/practitioner publication — company interview and platform report. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure; Code quality & security. **In short.** An interview with Canonical explains accelerator support, local-model packaging, developer tooling and exploratory agent-friendly OS features. **Summary.** An interview with Canonical explains accelerator support, local-model packaging, developer tooling and exploratory agent-friendly OS features. The preview distinguishes present hardware enablement from longer-term workflow plans. **Main findings — reported material.** Running models and agents reliably requires infrastructure support, not just prompts. Planned capabilities should not be treated as shipping features or measured safety guarantees. **Classification and proposed placement.** Engineering AI systems; sections 6.7, 5.5. Operating-system AI plans concern platform integration and trust; planned features are not completed security evaluations. **Second-audit outcome.** Classification and annotation retained after review. Canonical executive interview addresses operating-system permissions and agent execution, not an AI-assisted coding productivity experiment. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Secondary subject facets.** AI-assisted software development. --- ## P098 — Designing Data-Intensive Applications: The Cloud & Doing the Right Thing **Citation.** Gergely Orosz (introduction); Martin Kleppmann; Chris Riccomini (excerpts) (2026-05-05). *Designing Data-Intensive Applications: The Cloud & Doing the Right Thing*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/designing-data-intensive-applications-book-excerpt **Type of work.** Industry/practitioner publication — introduced guest book excerpt. Evidence origin: ADAPTED_OR_EXCERPTED_WORK. **Streams.** Economics; Engineering structure. **In short.** Orosz introduces authorized excerpts by Martin Kleppmann and Chris Riccomini on cloud versus self-hosting and engineers’ ethical responsibilities. **Summary.** Orosz introduces authorized excerpts by Martin Kleppmann and Chris Riccomini on cloud versus self-hosting and engineers’ ethical responsibilities. The visible discussion relates operational control, expertise, workload variability and cost. **Main findings — reported material.** Build/buy and hosting choices depend on workload and organizational capabilities. Excerpt authorship must be credited; this is not an Orosz experiment or an evaluation of coding agents. **Classification and proposed placement.** General software engineering; sections 12.1, 11.6. The guest excerpts connect cloud choices and professional ethics to organizational constraints; credit the book's authors. **Second-audit outcome.** Classification and annotation retained after review. The 2026 second-edition excerpt credits Martin Kleppmann and Chris Riccomini; edition date, original book history and Orosz introduction remain distinct. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Displayed byline: Gergely Orosz. Excerpt authors: Martin Kleppmann and Chris Riccomini. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz (introduction); Martin Kleppmann; Chris Riccomini (excerpts). --- ## P099 — TechPays has been acquired by Levels.fyi **Citation.** Gergely Orosz (2026-05-12). *TechPays has been acquired by Levels.fyi*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/techpays-has-been-acquired-levels-fyi/ **Type of work.** Industry/practitioner publication — business announcement. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** No forced thematic assignment. **In short.** Announces transfer of the author’s compensation-transparency project to Levels.fyi and discusses sustaining its data and maintenance. **Summary.** Announces transfer of the author’s compensation-transparency project to Levels.fyi and discusses sustaining its data and maintenance. **Main findings — reported material.** Provides provenance and a disclosed business relationship relevant to salary-data commentary, not a new compensation study. **Classification and proposed placement.** Catalogue-only material; sections none. The acquisition announcement records a later financial relationship relevant to source provenance, not new compensation research. **Second-audit outcome.** Classification and annotation retained after review. First-person TechPays acquisition announcement is catalogue context; it does not supply a new compensation dataset. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Updated 13 May 2026. The later acquisition must not be assumed to have existed when earlier salary articles were published. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P100 — Revisiting “No Silver Bullets” in the age of AI **Citation.** Gergely Orosz (2026-05-12). *Revisiting “No Silver Bullets” in the age of AI*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/revisiting-no-silver-bullets-in-the **Type of work.** Industry/practitioner publication — historical and conceptual essay. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Engineering structure; Productivity. **In short.** Orosz revisits Brooks’s distinction between fundamental software difficulty and tool-level improvement. **Summary.** Orosz revisits Brooks’s distinction between fundamental software difficulty and tool-level improvement. The preview weighs AI against earlier developments such as reliability engineering, open source and collaboration tools. **Main findings — reported material.** Large increases in generated code are not automatically comparable gains in productivity, reliability or simplicity. The historical comparison is an argument, not a controlled test. **Classification and proposed placement.** AI-assisted software development; sections 1.3, 2.5. Brooks's conceptual distinction helps separate code-production acceleration from fundamental design and coordination difficulty. **Second-audit outcome.** Classification and annotation retained after review. Reinterprets Brooks' argument in the AI context; analogy is not proof of a universal productivity ceiling or gain. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **W/O relations.** O049 (EDITORIAL_COMPARISON_NOT_CITATION): Both distinguish rapid implementation from persistent design and completion difficulty; neither establishes a universal percentage. --- ## P101 — AI’s impact on software engineers in 2026: key trends, Part 2 **Citation.** Gergely Orosz; Elin Nilsson (2026-05-19). *AI’s impact on software engineers in 2026: key trends, Part 2*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/ai-impact-on-software-engineers-part-2 **Type of work.** Industry/practitioner publication — reader survey analysis. Evidence origin: ORIGINAL_VOLUNTARY_OBSERVATIONAL_SURVEY. **Streams.** Skills & learning; Code quality & security. **In short.** The final analysis of the publication’s 2026 reader survey examines team adoption, codebase quality, less-experienced engineers and differing experiences of focus and cognitive load. **Summary.** The final analysis of the publication’s 2026 reader survey examines team adoption, codebase quality, less-experienced engineers and differing experiences of focus and cognitive load. It argues that existing engineering practices shape perceived benefits. **Main findings — reported material.** Self-reported benefits coexist with maintenance and learning concerns. This is another analysis of the same survey cohort, not an independent replication of its earlier installments. **Classification and proposed placement.** AI-assisted software development; sections 10.2, 5.6. The same 2026 survey links reported adoption with learning and maintenance concerns, not measured retained skill. **Second-audit outcome.** Mapping retained; access/evidence annotation qualified. The author reports 906 responses for the shared 2026 cohort. This is not an independently counted sample; comparisons with other survey waves are not a matched longitudinal panel. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Self-selected respondents and subjective reports; shared 2026 survey dataset with AI Tooling 2026 and key trends Part 1. The author reports 906 responses for the shared 2026 cohort. This is not an independently counted sample; comparisons with other survey waves are not a matched longitudinal panel. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Elin Nilsson. **W/O relations.** W117 (EDITORIAL_COMPARISON_NOT_CITATION): Reported cognitive load and maintenance concerns are not direct measurements of retained skill or causal cognitive offloading. W154 (EDITORIAL_COMPARISON_NOT_CITATION): Comprehension debt is distinct from technical debt; respondent sentiment is not a calibrated comprehension measure. **Shared source cohorts.** DATA:P:AI_SURVEY_2026. --- ## P102 — State of the software engineering job market in 2026 **Citation.** Gergely Orosz; Jessica Salmon (2026-05-26). *State of the software engineering job market in 2026*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/state-of-the-job-market-2026 **Type of work.** Industry/practitioner publication — industry data analysis. Evidence origin: SECONDARY_OR_PROVIDER_DATA_ANALYSIS. **Streams.** Jobs & roles; Economics. **In short.** The report uses job listings and workforce profiles to examine software and AI engineering demand across countries and employers. **Summary.** The report uses job listings and workforce profiles to examine software and AI engineering demand across countries and employers. The preview explicitly asks whether AI roles are replacing traditional software roles. **Main findings — reported material.** The article states that the available data cannot answer replacement causally. Geography, employer coverage and the difference between posted vacancies and employment matter. **Classification and proposed placement.** Labor-market and recruiting context; sections 12.5, 12.6. The market report combines heterogeneous indicators and requires separating correlation, coverage and causation. **Second-audit outcome.** Classification and annotation retained after review. Job postings and employment datasets use different coverage and denominators; do not infer AI displacement from their juxtaposition. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Jessica Salmon. **W/O relations.** W142 (EDITORIAL_COMPARISON_NOT_CITATION): Labor-market weakening has competing explanations; the industry report is not independent identification of an AI effect. --- ## P103 — Ideas: slow down to speed up when working with AI agents **Citation.** Gergely Orosz (2026-06-02). *Ideas: slow down to speed up when working with AI agents*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/ideas-slow-down-to-speed-up-when **Type of work.** Industry/practitioner publication — practitioner essay. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Productivity. **In short.** The accessible introduction announces draft keynote ideas about rising code production and possible consequences for quality, reliability and technical debt. **Summary.** The accessible introduction announces draft keynote ideas about rising code production and possible consequences for quality, reliability and technical debt. The substantive argument is behind the subscriber boundary. **Main findings — reported material.** No substantive findings were accessible. Classification is provisional from the title, subtitle and short introduction, not a reconstruction of the paid text. **Classification and proposed placement.** AI-assisted software development; sections none. Only a short introduction is accessible; retain a provisional stream without inferring detailed methods, findings or section mappings. **Second-audit outcome.** Classification and annotation retained after review. Minimal public scheduling/conference introduction does not expose the substantive argument; retain metadata-only status and unresolved overlap with P107. **Access and limitations.** Minimal introduction only; substantive conclusions unconfirmed. Do not conflate this early ideas post with the later June 23 keynote summary; related but separate publications. Only a short introduction is publicly visible. P107 explicitly develops this theme later; the overlap cannot be fully assessed without authorized access to P103. No detailed findings are inferred from its title. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P104 — State of the software engineering job market in 2026, part 2 **Citation.** Gergely Orosz; Jessica Salmon (2026-06-09). *State of the software engineering job market in 2026, part 2*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/the-job-market-in-2026-part-2 **Type of work.** Industry/practitioner publication — industry data analysis. Evidence origin: SECONDARY_OR_PROVIDER_DATA_ANALYSIS. **Streams.** Jobs & roles; Economics. **In short.** The second labor-market report combines hiring-platform, workforce and interview-preparation data on specializations, seniority, compensation and management layers. **Summary.** The second labor-market report combines hiring-platform, workforce and interview-preparation data on specializations, seniority, compensation and management layers. Its preview distinguishes strong AI demand from weaker entry-level and other specialist demand. **Main findings — reported material.** Vacancies, coaching demand and employment profiles measure different constructs. They do not establish that AI directly caused every change in hiring or compensation. **Classification and proposed placement.** Labor-market and recruiting context; sections 12.5, 12.8. Specialty and seniority indicators describe uneven demand, not a single estimated effect of AI on labor. **Second-audit outcome.** Classification and annotation retained after review. Provider and interview observations concern jobs and company differences; no isolated causal AI employment effect is established. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Jessica Salmon. --- ## P105 — Why is Meta destroying its engineering organization? **Citation.** Gergely Orosz (2026-06-16). *Why is Meta destroying its engineering organization?*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/why-is-meta-destroying-its-engineering **Type of work.** Industry/practitioner publication — investigative industry commentary. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** Engineering structure; Code quality & security. **In short.** Orosz contrasts Meta’s earlier engineering culture with reported AI-related restructuring, pressure on developers and weakening operational safeguards. **Summary.** Orosz contrasts Meta’s earlier engineering culture with reported AI-related restructuring, pressure on developers and weakening operational safeguards. The piece combines historical comparison and contemporary employee accounts. **Main findings — reported material.** The analysis raises a governance failure hypothesis: adoption pressure can undermine ownership and assurance. Its allegations and causal interpretation should remain attributed to the reporting. **Classification and proposed placement.** AI-assisted software development; sections 11.6, 5.6. The report raises an organizational-risk hypothesis; employee allegations and editorial causal interpretations remain attributed. **Second-audit outcome.** Classification and annotation retained after review. Reported Meta organizational problems and motives require attribution to accounts and editorial interpretation, not treatment as independently adjudicated facts. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Claims about management intent and organizational consequences are attributed reporting; the article is not a controlled evaluation of AI or a verified causal explanation. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **W/O relations.** O005 (EDITORIAL_COMPARISON_NOT_CITATION): Governance and judgment must remain accountable; reported organizational failures are allegations and interpretations, not an experiment. --- ## P106 — Reliability fail: No automated zone failover for Coinbase’s global trading service **Citation.** Gergely Orosz (2026-06-23). *Reliability fail: No automated zone failover for Coinbase’s global trading service*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/coinbase-fail/ **Type of work.** Industry/practitioner publication — incident analysis. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Code quality & security; Engineering structure. **In short.** Analyses a May 2026 trading outage through the disclosed matching-engine architecture, zone dependence and manual recovery requirements. **Summary.** Analyses a May 2026 trading outage through the disclosed matching-engine architecture, zone dependence and manual recovery requirements. **Main findings — reported material.** The engineering lesson concerns tested recovery paths and explicit availability trade-offs; the estimated interrupted trading volume is not measured realized financial loss. **Classification and proposed placement.** General software engineering; sections 5.6, 11.6. An outage and failover case illustrates engineering assurance; interrupted volume is not realized loss and AI causation is not inferred. **Second-audit outcome.** Classification and annotation retained after review. Incident analysis concerns infrastructure concentration and trading interruption; business valuation or theoretical exposure is not realized financial loss. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Public non-Pulse-titled excerpt of a Pulse issue; retained under the requested title-prefix rule. This non-Pulse-titled blog article is an excerpt of a Pulse issue originally published 2026-06-11. It passes the literal title-prefix rule; it is excluded by the optional stricter Pulse-origin filter. The parent issue is provenance only, not another P article. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Pulse-origin provenance.** Earlier issue 2026-06-11: https://newsletter.pragmaticengineer.com/p/did-anthropics-new-model-just-boost. Included by literal title-prefix rule; excluded by the stricter view. --- ## P107 — Slow down to speed up: so much has changed in 6 months’ time **Citation.** Gergely Orosz (2026-06-23). *Slow down to speed up: so much has changed in 6 months’ time*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/slow-down-to-speed-up **Type of work.** Industry/practitioner publication — reported industry synthesis. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Productivity; Code quality & security. **In short.** A keynote-based synthesis contrasts rapid growth in agent-produced changes with review, reliability and team-productivity constraints. **Summary.** A keynote-based synthesis contrasts rapid growth in agent-produced changes with review, reliability and team-productivity constraints. The public material includes company accounts and platform activity metrics. **Main findings — reported material.** Individual output and organizational delivery are different outcomes. Alleged incident causes and broad industry trends require verification beyond the reported accounts. **Classification and proposed placement.** AI-assisted software development; sections 2.5, 8.1. Keynote observations reinforce the distinction between generation, review capacity and stable delivery without identifying a causal effect. **Second-audit outcome.** Classification and annotation retained after review. Public keynote explicitly develops the earlier P103 draft and reader feedback; full overlap remains unresolved because P103 is restricted. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. The article explicitly develops P103 and reuses the Meta discussion in P105. Distinct articles do not supply independent confirmations of the reused claims. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **W/O relations.** W021 (EDITORIAL_COMPARISON_NOT_CITATION): Review and reliability bottlenecks qualify activity metrics; underlying telemetry definitions and commercial provenance still matter. **P-series reporting relations.** P103 (DEVELOPS_PRIOR_ARTICLE): The expanded keynote explicitly develops the earlier short ideas article. Full overlap assessment is blocked by P103 access. P105 (REUSES_REPORTED_CASE): The Meta organizational discussion is reused in the expanded keynote, not independently confirmed. --- ## P108 — Pollen tried to remove my article about CEO Callum Negus-Fancey and CTO Bradley Wright, and Google is assisting with it **Citation.** Gergely Orosz (2026-06-28). *Pollen tried to remove my article about CEO Callum Negus-Fancey and CTO Bradley Wright, and Google is assisting with it*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/pollen-tried-to-remove-my-article-about-callum-negus-fancey-and-google-is-assisting-to-it/ **Type of work.** Industry/practitioner publication — first person editorial account. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** No forced thematic assignment. **In short.** Describes the author’s investigation of a copyright complaint that deindexed an earlier company investigation. **Summary.** Describes the author’s investigation of a copyright complaint that deindexed an earlier company investigation. He disputes the complaint and discusses source availability. **Main findings — reported material.** Illustrates evidence-custody and publication fragility. Despite the headline, the author explicitly does not know who filed the complaint; the suggested responsible parties remain speculation. **Classification and proposed placement.** Methods and provenance; sections none. The editorial account illustrates fragility of source access; it does not establish the identity of the complainant. **Second-audit outcome.** Classification and annotation retained after review. Copyright-dispute reporting does not establish a complainant identity merely through an accusatory article title. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Updated 8 July 2026. Do not turn the headline’s allegation into a verified finding. The headline attributes the deletion request to the CEO, but the body states the requester’s identity is unknown. Do not promote the headline attribution to an established fact. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P109 — Tech jobs market in 2026, part 3: hiring managers & job seekers **Citation.** Gergely Orosz (2026-07-07). *Tech jobs market in 2026, part 3: hiring managers & job seekers*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/tech-jobs-market-in-2026-part-3-hiring **Type of work.** Industry/practitioner publication — qualitative industry interviews. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Jobs & roles. **In short.** Accounts from hiring managers and job seekers describe noisy applications, distrust of AI-enhanced credentials and sharply different demand across specialties and regions. **Summary.** Accounts from hiring managers and job seekers describe noisy applications, distrust of AI-enhanced credentials and sharply different demand across specialties and regions. This complements, rather than duplicates, the series’ vacancy-data analyses. **Main findings — reported material.** Reported hiring friction can coexist with hard-to-fill positions. Interview accounts cannot estimate the industry-wide employment effect of AI or eliminate selection bias. **Classification and proposed placement.** Labor-market and recruiting context; sections 12.5. Labor-market interviews describe recruitment signals and uneven opportunities; AI is one contextual factor, not an isolated causal effect or a measured software-development intervention. **Second-audit outcome.** Classification and annotation retained after review. More than fifty contributed accounts remain a selected reporting pool, not a probability sample of employed engineers. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Secondary subject facets.** Ai hiring and assessment. --- ## P110 — What is “loop engineering?” **Citation.** Gergely Orosz (2026-07-14). *What is “loop engineering?”*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/what-is-loop-engineering **Type of work.** Industry/practitioner publication — reported practitioner analysis. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** What agents can do; Engineering structure. **In short.** Orosz traces Ralph-style loops, scheduled triggers and goal-oriented harness features. **Summary.** Orosz traces Ralph-style loops, scheduled triggers and goal-oriented harness features. Developer accounts include useful maintenance automation alongside drift, token spending and disappointment with unnecessary orchestration. **Main findings — reported material.** The article questions whether custom loops remain useful as harnesses absorb them. Context design, bounded scope and measurable benefit are more defensible than assuming that more looping improves results. **Classification and proposed placement.** AI-assisted software development; sections 3.6, 12.3. The critique challenges unnecessary custom orchestration, not the need for bounded execution, context and independent assurance. **Second-audit outcome.** Classification and annotation retained after review. Accessible loop-engineering discussion refers to Osmani's website edition and weighs costs/complexity; it neither validates all loops nor refutes bounded-loop engineering. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. P110 directly links https://addyosmani.com/blog/loop-engineering/ (7 June 2026). O012 catalogues the substantially matching Substack edition (8 June 2026). Treat the edge as discussion of the same underlying work via an alternate edition, not an exact-URL citation. The paid remainder and comparative loop outcomes remain unreviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **W/O relations.** O012 (CRITICAL_DISCUSSION_OF_EXISTING_PRACTITIONER_WORK): Direct discussion of Osmani’s loop essay through the website edition; O012 is its substantially matching Substack edition. Not an exact-URL citation, independent validation or wholesale refutation. W095 (EDITORIAL_COMPARISON_NOT_CITATION): Lifecycle reliability and token/review cost are appropriate tests of whether extra orchestration earns its keep. W191 (EDITORIAL_COMPARISON_NOT_CITATION): Observed failure modes are relevant to testing loop usefulness; the interview-based article is not a failure-rate study. **Shared source cohorts.** DATA:P:LOOP_REPLIES_2026. --- ## P111 — Pushing software engineering limits with “napkin math” **Citation.** Gergely Orosz (2026-07-21). *Pushing software engineering limits with “napkin math”*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/pushing-software-engineering-limits **Type of work.** Industry/practitioner publication — practitioner interview. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Economics; Engineering structure. **In short.** An interview with Simon Eskildsen connects back-of-the-envelope resource estimates, long-term systems experience and the design of turbopuffer. **Summary.** An interview with Simon Eskildsen connects back-of-the-envelope resource estimates, long-term systems experience and the design of turbopuffer. Performance assumptions are checked against hardware limits and observed behavior. **Main findings — reported material.** A gap between expected and measured performance can expose a bad benchmark or a bad model. Reported startup cost savings remain a case study, not an AI-productivity experiment. **Classification and proposed placement.** General software engineering; sections 12.4, 5.5. Resource estimates checked against observation illustrate model calibration; startup savings are not coding-agent ROI evidence. **Second-audit outcome.** Classification and annotation retained after review. Written edited discussion is labeled Deepdives despite an accompanying recording; the same section/form rule supports inclusion of P123. **Access and limitations.** Public main article available; classification-bearing passages reviewed. The publication discloses that turbopuffer sponsors its podcast and states that this deepdive is editorially independent. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P112 — How building software is changing at Anthropic **Citation.** Gergely Orosz (2026-07-28). *How building software is changing at Anthropic*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/inside-anthropic **Type of work.** Industry/practitioner publication — company case study. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure; Productivity. **In short.** Interviews at Anthropic contrast accelerated migration and implementation with long-running infrastructure projects. **Summary.** Interviews at Anthropic contrast accelerated migration and implementation with long-running infrastructure projects. The visible outline preserves planning, testing, small teams and engineering understanding despite changes in how code is produced. **Main findings — reported material.** Faster implementation does not eliminate coordination or verification. Migration time and token figures are company reports with hypothetical pre-AI comparisons, not matched experimental results. **Classification and proposed placement.** AI-assisted software development; sections 11.1, 2.5. The company case retains planning and verification despite accelerated implementation; hypothetical pre-AI comparisons remain unvalidated. **Second-audit outcome.** Classification and annotation retained after review. Anthropic team interviews are context-specific company reporting; selection and internal resources limit transferability. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Reported migration duration is compared with an estimated engineering counterfactual, not a controlled time-saving experiment. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **W/O relations.** O009 (EDITORIAL_COMPARISON_NOT_CITATION): The company case preserves planning and ownership of outcomes despite increased generation; a practitioner comparison only. --- ## P113 — Software engineering at a proprietary trading company: Optiver **Citation.** Gergely Orosz; Ivan Klaric; Jesse Spevack (2026-08-11). *Software engineering at a proprietary trading company: Optiver*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/optiver **Type of work.** Industry/practitioner publication — company case study. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure; Code quality & security. **In short.** A company deepdive introduces trading-specific engineering incentives, tightly integrated hardware/software, platform ownership, risk management and AI adoption. **Summary.** A company deepdive introduces trading-specific engineering incentives, tightly integrated hardware/software, platform ownership, risk management and AI adoption. The public introduction contrasts low-latency execution with increasingly important predictive models. **Main findings — reported material.** Speed is constrained by the consequences of failure. Trading-specific architecture and incentives are useful boundary conditions, not a template for every development team. **Classification and proposed placement.** General software engineering; sections 5.5, 11.6. Trading-system constraints provide an important boundary case for engineering controls; do not generalize domain-specific incentives. **Second-audit outcome.** Classification and annotation retained after review. High-stakes trading-engineering practices contextualize quality and systems work; they are not causal AI-tool evidence. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Ivan Klaric; Jesse Spevack. **Secondary subject facets.** AI-assisted software development, Engineering AI systems. --- ## P114 — Headed for the Exit: the Great Engineering Leader Career Break **Citation.** Gergely Orosz (2026-08-18). *Headed for the Exit: the Great Engineering Leader Career Break*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/the-great-engineering-leader-career-break **Type of work.** Industry/practitioner publication — qualitative industry interviews. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Jobs & roles; Engineering structure. **In short.** Interviews with engineering leaders examine career breaks, founder expectations, cost pressure, changing team sizes and renewed interest in hands-on work. **Summary.** Interviews with engineering leaders examine career breaks, founder expectations, cost pressure, changing team sizes and renewed interest in hands-on work. The preview highlights tension between rapid prototyping and operational ownership. **Main findings — reported material.** The interviews identify plausible mechanisms and experiences, not the prevalence of leadership departures or a causal effect of AI on employment. **Classification and proposed placement.** AI-sector and organizational context; sections 12.5, 11.8. Leadership-break interviews concern ownership, incentives and transitions, without measuring the prevalence of AI-caused exits. **Second-audit outcome.** Classification and annotation retained after review. Roughly twenty leadership interviews explain individual breaks; they do not estimate industry attrition or knowledge loss. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Selected career-break interviews and the six-of-ten subgroup do not estimate a population departure rate. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P115 — Why Ramp built its own in-house coding agent, Inspect **Citation.** Gergely Orosz; Jessica Salmon; Ivan Klaric (2026-08-25). *Why Ramp built its own in-house coding agent, Inspect*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/why-ramp-built-inspect **Type of work.** Industry/practitioner publication — company case study. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** System knowledge & memory; What agents can do. **In short.** Interviews with Ramp describe a background coding agent running in remote sandboxes with internal integrations and backend/frontend verification. **Summary.** Interviews with Ramp describe a background coding agent running in remote sandboxes with internal integrations and backend/frontend verification. The preview explains why local-tool and context limitations motivated an internal platform. **Main findings — reported material.** Remote environments and company context can matter as much as model selection. Adoption and self-verification claims are reported by the company, not controlled evidence of correctness. **Classification and proposed placement.** AI-assisted software development; sections 9.5, 3.2. The Inspect case emphasizes company context, remote sandboxes and verification; reported self-checks are not independent accuracy evidence. **Second-audit outcome.** Classification and annotation retained after review. Ramp case retains Jessica Salmon and Ivan Klaric contributor credit; internal context and infrastructure are not generic evidence of agent success. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Agent-origin merged-PR share is not a quality-adjusted productivity measure. Self-run tests and screenshots do not by themselves establish an independent acceptance oracle. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Jessica Salmon; Ivan Klaric. **Secondary subject facets.** Engineering AI systems. **W/O relations.** O004 (EDITORIAL_COMPARISON_NOT_CITATION): Persistent company instructions and context need maintenance and validity checks, not only accumulation. W159 (EDITORIAL_COMPARISON_NOT_CITATION): Contextual consistency is a testable operational concern; the company case does not replicate memory research. --- ## P116 — Why you're not getting a response to your podcast pitch from me (or others) **Citation.** Gergely Orosz (2026-08-27). *Why you're not getting a response to your podcast pitch from me (or others)*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/why-youre-not-getting-a-response-to-your-podcast-pitch-from-me-or-others/ **Type of work.** Industry/practitioner publication — editorial process commentary. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** No forced thematic assignment. **In short.** Explains how the author selects podcast guests and handles high volumes of promotional pitches, including his own AI-assisted email workflow. **Summary.** Explains how the author selects podcast guests and handles high volumes of promotional pitches, including his own AI-assisted email workflow. **Main findings — reported material.** Provides publication-process context rather than evidence about development productivity or engineering effectiveness. **Classification and proposed placement.** Catalogue-only material; sections none. Podcast selection and email handling are editorial process, not measured software-development performance. **Second-audit outcome.** Classification and annotation retained after review. Podcast-pitch blog post is publishing context, not a coding-agent effectiveness study. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P117 — How software engineering is changing: an essay challenge **Citation.** Gergely Orosz (2026-09-01). *How software engineering is changing: an essay challenge*. The Pragmatic Engineer. https://blog.pragmaticengineer.com/how-software-engineering-is-changing-an-essay-challenge/ **Type of work.** Industry/practitioner publication — editorial recruitment. Evidence origin: EDITORIAL_OR_PRACTITIONER_ARGUMENT. **Streams.** No forced thematic assignment. **In short.** Invites first-hand accounts of changing engineering practice, including AI adoption, with explicit editorial selection and human-authorship expectations. **Summary.** Invites first-hand accounts of changing engineering practice, including AI adoption, with explicit editorial selection and human-authorship expectations. **Main findings — reported material.** A recruitment and editorial-method document, not results from the submitted accounts. Selection and incentives can shape the later evidence base. **Classification and proposed placement.** Methods and provenance; sections none. An essay challenge is recruitment and source-selection context; no submission findings or AI-authorship detector validity are inferred. **Second-audit outcome.** Classification and annotation retained after review. Essay competition is a recruitment/methods artifact; incentives and future submissions do not count as completed findings. **Access and limitations.** Public main article available; classification-bearing passages reviewed. Updated 5 October 2026. No validation of proposed AI-writing detection is established. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. --- ## P118 — What is happening with code reviews? **Citation.** Gergely Orosz (2026-09-08). *What is happening with code reviews?*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/what-is-happening-with-code-reviews **Type of work.** Industry/practitioner publication — reported practitioner analysis. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Verification & review; Engineering structure. **In short.** The article surveys responses to growing AI-generated review workloads: reviewing AI feedback, routing by blast radius, inspecting plans and tests, reducing patch size, and retaining manual review. **Summary.** The article surveys responses to growing AI-generated review workloads: reviewing AI feedback, routing by blast radius, inspecting plans and tests, reducing patch size, and retaining manual review. **Main findings — reported material.** The visible discussion rejects a universal review process. Noise filtering, scope decisions and release responsibility remain important even when review automation increases. **Classification and proposed placement.** AI-assisted software development; sections 8.1, 8.8. Reported review approaches depend on risk, noise and team context; the article does not validate one universal review policy. **Second-audit outcome.** Classification and annotation retained after review. Review practices and workload changes are reported in a restricted article; visible outline does not validate a universal low-risk approval policy. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **W/O relations.** O001 (EDITORIAL_COMPARISON_NOT_CITATION): Risk-calibrated review and retained accountability overlap, but the sources are practitioner analyses rather than trials. O019 (EDITORIAL_COMPARISON_NOT_CITATION): Contemporary review practices complement earlier reviewer guidance; no single process is validated for every team. W093 (EDITORIAL_COMPARISON_NOT_CITATION): Low-risk automation is a narrower evaluated setting than broad claims about the end of code review. W096 (EDITORIAL_COMPARISON_NOT_CITATION): Reviewer noise and developer response constrain the usefulness of automated comments. --- ## P119 — Inside OpenAI’s agentic software factory **Citation.** Gergely Orosz (2026-09-15). *Inside OpenAI’s agentic software factory*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/openai-software-factory **Type of work.** Industry/practitioner publication — company case study. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure; What agents can do. **In short.** A company-visit report describes Codex adoption, internal integrations and feedback loops extending into performance work and infrastructure. **Summary.** A company-visit report describes Codex adoption, internal integrations and feedback loops extending into performance work and infrastructure. Its public preview emphasizes harness capabilities and changes in engineering responsibilities. **Main findings — reported material.** An unusually integrated environment and effectively unrestricted internal token access limit generalization. Claimed adoption and productivity implications require separate outcome measurement. **Classification and proposed placement.** AI-assisted software development; sections 11.2, 3.6. A deeply integrated internal software factory is a boundary case, not a representative operating environment. **Second-audit outcome.** Classification and annotation retained after review. Seven named interviewees and generous internal tool access characterize a company case, not an independently controlled software-factory benchmark. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Internal integrations, selected interviewees and unusually permissive token budgets limit transfer to other organizations. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Secondary subject facets.** Engineering AI systems. **W/O relations.** O008 (EDITORIAL_COMPARISON_NOT_CITATION): An internal software-factory example is not proof that its autonomy model transfers to organizations with different constraints. --- ## P120 — How will AI change operating systems? Part 2: Windows **Citation.** Gergely Orosz; Ivan Klaric (2026-09-22). *How will AI change operating systems? Part 2: Windows*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/windows-and-ai **Type of work.** Industry/practitioner publication — company interviews and platform report. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure; Code quality & security. **In short.** Interviews with Microsoft staff outline agent identity, local MCP discovery, isolation, local-model support and developer experience on Windows. **Summary.** Interviews with Microsoft staff outline agent identity, local MCP discovery, isolation, local-model support and developer experience on Windows. The public portion also compares several differently sampled operating-system surveys. **Main findings — reported material.** Agent identity and isolation are distinct from model capability. Survey populations and multiple-choice designs differ; stated platform plans are not independent security evaluations. **Classification and proposed placement.** Engineering AI systems; sections 5.5, 6.7. Windows platform architecture enables AI applications and agents through identity, isolation and discovery. Distinguish roadmap features from deployed capabilities, and architecture from validated security outcomes. **Second-audit outcome.** Classification and annotation retained after review. Windows runtime discussion separates agent-product engineering and roadmap ideas from demonstrated AI-assisted development effects; preserve contributor attribution. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz; Ivan Klaric. **W/O relations.** O014 (EDITORIAL_COMPARISON_NOT_CITATION): Identity, isolation and runtime policy are architectural responsibilities beyond model capability. --- ## P121 — Why has Shopify dropped React Native? **Citation.** Gergely Orosz (2026-09-29). *Why has Shopify dropped React Native?*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/shopify-native-mobile **Type of work.** Industry/practitioner publication — company case study. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure; Productivity. **In short.** The public preview examines Shopify’s return to native mobile development after previously adopting React Native. **Summary.** The public preview examines Shopify’s return to native mobile development after previously adopting React Native. It connects AI-assisted implementation with changing performance and code-sharing trade-offs. **Main findings — reported material.** Reported migration speed is company-specific; the preview also recognizes that AI can assist native and cross-platform stacks. It does not prove that native development is universally superior. **Classification and proposed placement.** AI-assisted software development; sections 5.5, 2.4. AI can change platform migration costs, but a single-company account does not establish universal superiority of native development. **Second-audit outcome.** Classification and annotation retained after review. Shopify's reported migration and AI tooling are a company-specific case, not proof that cross-platform frameworks are generally obsolete. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. A selected team’s reported migration does not establish that React Native or cross-platform development is generally obsolete. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **Secondary subject facets.** General software engineering. **W/O relations.** O007 (EDITORIAL_COMPARISON_NOT_CITATION): Faster migration still requires architectural fit and code quality; the reported company result is context-bound. --- ## P122 — The state of the tech industry in 2026 **Citation.** Gergely Orosz (2026-10-06). *The state of the tech industry in 2026*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/the-state-of-the-tech-industry-in **Type of work.** Industry/practitioner publication — reported industry synthesis. Evidence origin: SELECTED_INTERVIEWS_OR_REPORTED_PRACTICE. **Streams.** Engineering structure; Productivity. **In short.** Orosz synthesizes company visits, interviews and platform data in a keynote about agent-heavy development. **Summary.** Orosz synthesizes company visits, interviews and platform data in a keynote about agent-heavy development. He contrasts changing interfaces and review workloads with the continuing importance of teams, planning and verification. **Main findings — reported material.** Reported frontier practices are a directional snapshot, not representative adoption estimates. Increased code volume does not establish increased delivered value. **Classification and proposed placement.** AI-assisted software development; sections 1.9, 11.1. A keynote synthesis summarizes frontier practices and preserves engineering fundamentals; overlapping reporting is not fresh experimental evidence. **Second-audit outcome.** Classification and annotation retained after review. The main keynote is public with paid extras; its October 2025/2026 reference remains inconsistent and its PR-volume estimate is not independently verified. **Access and limitations.** Public main article available; separate paid supplementary material not reviewed. The article contains an apparent October 2025/2026 date inconsistency in its PR-volume discussion; do not import those numerical estimates without primary-source checking. The October 2025 phrase still conflicts with the October 2026 publication and August 2026 PR discussion. Keep the author’s numerical extrapolation unresolved rather than silently changing its date. The article explicitly synthesizes earlier P-series reporting. Public availability does not imply an independent check of every paragraph or chart. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz. **W/O relations.** W010 (EDITORIAL_COMPARISON_NOT_CITATION): Keynote claims about generated work must remain separate from delivered value and measured organizational outcomes. **P-series reporting relations.** P080 (SYNTHESIZES_PRIOR_REPORTING): The keynote explicitly refers to the earlier AI-written-code essay. P115 (SYNTHESIZES_PRIOR_REPORTING): The keynote explicitly reuses the Ramp Inspect report. P119 (SYNTHESIZES_PRIOR_REPORTING): The keynote explicitly reuses the OpenAI software-factory report. P112 (SYNTHESIZES_PRIOR_REPORTING): The keynote explicitly cites the Anthropic account for project staffing. P091 (SYNTHESIZES_PRIOR_REPORTING): The keynote explicitly refers to the earlier quality/productivity discussion. --- ## P123 — Cycles of disruption in the tech industry: with software pioneers Kent Beck & Martin Fowler **Citation.** Gergely Orosz (2026-04-07). *Cycles of disruption in the tech industry: with software pioneers Kent Beck & Martin Fowler*. The Pragmatic Engineer. https://newsletter.pragmaticengineer.com/p/cycles-of-disruption-in-the-tech **Type of work.** Industry/practitioner publication — edited panel discussion. Evidence origin: EDITED_EXPERT_PANEL_AND_PRACTITIONER_INTERPRETATION. **Streams.** Engineering structure; Skills & learning. **In short.** Orosz edits a Beck–Fowler panel discussion about AI and earlier technological shifts. **Summary.** Orosz edits a Beck–Fowler panel discussion about AI and earlier technological shifts. The public outline connects adoption, team practice, workload, outcome metrics, testing and craft. **Main findings — reported material.** The visible discussion argues for curiosity tempered by skepticism. The outline proposes attention to outcomes, work boundaries and engineering practice; these are participant recommendations, not measured productivity or retention effects. **Classification and proposed placement.** AI-assisted software development; sections 2.5, 11.5. Directly addresses using AI in software work, with historical and organizational analogies; maps to shipped value and agile team practices as editorial proposals. **Second-audit outcome.** Previously omitted qualifying article added. Wrongly excluded as Podcast; live page is a written Deepdive dated 2026-04-07. **Access and limitations.** Public preview/outline only; subscriber remainder not reviewed. Only the public introduction, outline and opening discussion were inspected; the paid remainder was not accessed. Beck and Fowler are participants, not article byline coauthors. The Summit also informs P088, so these articles are not independent event evidence. Subscriber-only article remainder not reviewed. No microdata replication, controlled product test, or independent-rater agreement study was performed. **Attribution.** Gergely Orosz (credited author and moderator); Kent Beck and Martin Fowler (panel participants). **Secondary subject facets.** General software engineering. **P-series reporting relations.** P088 (SHARES_REPORTED_EVENT_CONTEXT): Both draw partly on the February 2026 Pragmatic Summit, with Beck/Fowler perspectives; distinct written articles, not independent event samples. ---