# engineering-culture A software-engineering concept concerning the practices, collaboration, and standards that shape how engineering teams develop and review software. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Presentation: Teaching Engineers, Trusting AI: How Education Enabled Autonomous Code Review DevFeed: [Presentation: Teaching Engineers, Trusting AI: How Education Enabled Autonomous Code Review]() Original publisher: [Read original article]() Author: Sarah Deitke Published: 2026-09-16T11:00:00Z Content type: article Language: en Sources: [InfoQ]() Topics: [Artificial Intelligence](), [Code review](), [Pull Request](), [Tooling](), [engineering-culture](), [observability]() Tags: [adoption](), [agile](), [ai](), [ai-ml-data-engineering](), [architecture-design](), [artificial-intelligence](), [automated](), [automation](), [autonomous](), [case-study](), [code-review](), [code-reviews](), [culture](), [culture-methods](), [developer](), [developer-experience](), [development](), [duolingo-ai-literacy-code-review](), [infoq](), [metrics](), [ml-data-engineering](), [observability](), [pairing](), [presentation](), [qcon-london-2026](), [qcon-software-development-conference](), [transcripts]() ### AI overview Sarah Deitke presents Duolingo's approach to cultural AI adoption through internal AI literacy workshops, observability dashboards, and safe AI guardrails. The presentation includes a case study on redesigning code review with an automated PR risk-assessment bot and reports faster delivery without increased defect rates. ### Source excerpt Sarah Deitke discusses how Duolingo drives cultural AI adoption beyond tooling access. She explains their internal AI literacy workshops and observability dashboards, then shares a case study on redesigning code review using an automated PR risk-assessment bot. Deitke demonstrates how pairing targeted developer education with safe AI guardrails speeds up delivery without increasing defect rates. By Sarah Deitke ## Tips for giving your first code reviews DevFeed: [Tips for giving your first code reviews]() Original publisher: [Read original article]() Author: Khan Academy Published: 2017-09-18T22:00:00Z Content type: tutorial Language: en Sources: [Khan Academy]() Topics: [Code review](), [engineering-culture]() Tags: [advice](), [code-review](), [code-reviews](), [engineering](), [internship](), [mobile](), [news](), [onboarding](), [tips]() ### AI overview Hannah Blumberg shares practical advice for people conducting code reviews for the first time. She explains how asking questions and working through reviews with a teammate can help new reviewers contribute, learn, and communicate feedback effectively. ### Source excerpt By Hannah Blumberg At Khan Academy, (nearly) every piece of code that goes into our codebase has been ... Read more ## Receiving feedback as an intern at Khan Academy DevFeed: [Receiving feedback as an intern at Khan Academy]() Original publisher: [Read original article]() Author: Khan Academy Published: 2015-10-26T22:00:00Z Content type: opinion Language: en Sources: [Khan Academy]() Topics: [Code review](), [engineering-culture](), [Development]() Tags: [code-review](), [culture](), [engineering](), [experience](), [infrastructure](), [intern](), [news]() ### AI overview David Wang reflects on receiving code review feedback as an intern at Khan Academy. He describes the distinction between code critiques and character critiques, and explains Khan Academy's view of feedback as an ongoing, positive investment in colleagues' development. ### Source excerpt By David Wang When my first piece of code was reviewed at Khan Academy, my mentor Dylan prefaced ... Read more ## Why Coding Agents Still Need Human Code Reviews DevFeed: [Why Coding Agents Still Need Human Code Reviews]() Original publisher: [Read original article]() Author: Anton Zaides Published: 2026-09-15T06:01:00Z Content type: opinion Language: en Sources: [Manager.dev]() Topics: [AI-assisted coding](), [Code review](), [engineering-culture](), [Claude](), [Software Engineering]() Tags: [claude](), [code-review](), [code-reviews](), [coding-agents](), [software-engineering]() ### AI overview The article argues that coding-agent workflows still require human code reviews. It describes how making reviews optional caused them to drop sharply, allowing passable implementations to become templates that spread bugs, performance problems, race conditions, and confusion among agents. ### Source excerpt When my most experienced engineer got tired of our shitty code ## Maybe We Shouldn't Be Reviewing All This Code DevFeed: [Maybe We Shouldn't Be Reviewing All This Code]() Original publisher: [Read original article]() Author: Rachel Laycock (rlaycock@thoughtworks.com) Published: 2026-09-02T13:32:00Z Content type: opinion Language: en Sources: [Martin Fowler]() Topics: [Code review](), [pull-requests](), [Artificial Intelligence](), [Software Engineering](), [engineering-culture](), [Meta]() Tags: [ai](), [development](), [meta](), [pull-request](), [pull-requests](), [rachels-ramblings](), [review](), [software](), [software-development]() ### AI overview This opinion argues that AI-generated code is increasing the volume of code beyond what humans can realistically review, but that the deeper problem is relying on code review to provide knowledge sharing, mentoring, collective ownership, and architectural understanding. It advocates moving valuable feedback and collaboration earlier in the development process instead of treating pull requests as its center. ### Source excerpt TL;DR Or, perhaps the problem isn't that AI has broken code review, maybe it's that we've been using code review to solve the wrong problems I was on a panel recently with Brian Houck from DX at Code Remix, hosted by Moderne. It was one of the more interesting panels I've done, largely because we disagreed. As my colleague Martin Fowler says, panels are much more interesting when people disagree and both sides have a good argument. Brian and I definitely did. Brian has since written a thoughtful piece called What are code reviews even for? He is clearly passionate about his position, and I am passionate enough about mine that I'm writing this response. To be clear, I think we mostly want the same things. I just don't think code review is the best way to get them. Brian is lovely, by the way, and encouraged me to write this. But I'd be lying if I said I didn't want you to think I'm right by the end :) So what were we disagreeing about? AI is producing more code than humans can realistically review. Brian cites some pretty striking numbers: at Meta, significant lines of code per human-landed diff reportedly increased 106% in a year, while DX's own data shows median pull request size increasing 64%. His concern, which I share, is that simply automating code review away risks losing all the other things we use it for. Code review isn't just about finding bugs. It's how teams share knowledge, teach junior engineers, build collective ownership and spread architectural understanding. My question is: why are we waiting until code review to do all of those things? I've never particularly liked pull requests as the centre of the software development process. Not because engineers shouldn't look at each other's code, but because I've always struggled with the idea that we should build something, finish it, package it up, throw it over to somebody else and then have the important conversation about whether we built the right thing in the right way. And don't even get me started ## Meta's engineering culture and team-reduction plans amid competition from AI-native startups DevFeed: [Meta's engineering culture and team-reduction plans amid competition from AI-native startups]() Original publisher: [Read original article]() Author: Gergely Orosz Published: 2026-08-27T17:59:17Z Content type: article Language: en Sources: [The Pragmatic Engineer]() Topics: [Meta](), [Artificial Intelligence](), [engineering-culture](), [GitHub]() Tags: [ai](), [culture](), [engineering](), [engineering-culture](), [github](), [meta](), [startups]() ### AI overview The article examines why Meta changed its engineering culture and considered reducing teams amid concerns about AI-native startups doing more with less. It also discusses Ramp's AI infrastructure and increased GitHub load. ### Source excerpt We find out why Meta destroyed its standout engineering culture: it feared AI-native startups doing more with less. Also: thoughts on Ramp's AI infra, GitHub's load doubles in four months, and more ## Why performant code matters (but gets widely ignored), with Casey Muratori DevFeed: [Why performant code matters (but gets widely ignored), with Casey Muratori]() Original publisher: [Read original article]() Author: Gergely Orosz Published: 2026-08-26T15:59:59Z Content type: opinion Language: en Sources: [The Pragmatic Engineer]() Topics: [Code](), [Software](), [engineering-culture]() Tags: [code](), [developer](), [engineering-culture](), [performance](), [software]() ### AI overview This podcast episode features Casey Muratori discussing why software performance matters, why it is often overlooked, and how developers can write faster code. ### Source excerpt Casey Muratori explains why software performance matters, how developers can write faster code, and why he challenges conventional engineering practices. ## Senior Engineer ≠ Years of Experience DevFeed: [Senior Engineer ≠ Years of Experience]() Original publisher: [Read original article]() Author: Valentina Jemuović Published: 2026-08-24T06:01:00Z Content type: opinion Language: en Sources: [Optivem Journal]() Topics: [Software Engineering](), [Development](), [engineering-culture]() Tags: [effective](), [engineering](), [experience](), [learning](), [mistakes](), [software]() ### AI overview This opinion argues that years of software engineering experience do not reliably measure engineering ability. Repeated habits, including poor design, avoiding tests, and overengineering, can become more entrenched over time, while continuous learning, experimentation, feedback, and willingness to change are presented as stronger indicators of effectiveness. ### Source excerpt "I've been doing this for 15 years, so I already know." ## From Chrome DevTools to AI Engineering, with Addy Osmani DevFeed: [From Chrome DevTools to AI Engineering, with Addy Osmani]() Original publisher: [Read original article]() Author: Gergely Orosz Published: 2026-08-19T16:53:57Z Content type: article Language: en Sources: [The Pragmatic Engineer]() Topics: [AI Engineering](), [AI Agent](), [Developer experience](), [Google](), [developer tooling](), [engineering-culture](), [Loop Engineering](), [Chrome]() Tags: [agents](), [ai-agents](), [ai-engineering](), [developer](), [developer-experience](), [devtools](), [engineering](), [google](), [software-engineering](), [workflows]() ### AI overview Addy Osmani discusses his 14 years at Google, including work on Chrome, DevTools, Core Web Vitals, and AI developer experience. The conversation covers AI agents, loop engineering, cognitive surrender, engineering culture, and the broader skills engineers need. ### Source excerpt Addy Osmani shares lessons from 14 years at Google and how AI agents are reshaping software engineering, developer workflows, and the skills engineers need to succeed. ## How To Lead Engineers Who Don't Report To You DevFeed: [How To Lead Engineers Who Don't Report To You]() Original publisher: [Read original article]() Author: Ryan Murphy Published: 2026-08-09T17:17:21Z Content type: tutorial Language: en Sources: [The Software Engineering Times]() Topics: [Software Engineering](), [engineering-culture](), [Development]() Tags: [engineering](), [how-to](), [management](), [software-engineering]() ### AI overview The article explains why leading engineers without formal reporting authority is especially difficult for tech leads and individual contributors. It argues that they must lead through influence rather than authority and introduces five bases of power--reward, coercion, legitimate, referent, and expert--as a framework for understanding why people follow a request. ### Source excerpt This is about leading engineers, but the first sentence will piss a lot of people off. ## Middle management roles are also a trap. DevFeed: [Middle management roles are also a trap.]() Original publisher: [Read original article]() Published: 2026-08-08T14:00:00Z Content type: opinion Language: en Sources: [Will Larson - Irrational Exuberance]() Topics: [Tech Lead](), [engineering-culture](), [Software Engineering]() Tags: [engineering-management](), [organizational-culture](), [software-engineering](), [tech-lead]() ### AI overview The article argues that middle-management roles can be a poor path to becoming an executive. Although these roles develop skills such as stakeholder balancing, process design, and resource allocation, the author says line-management roles provide better opportunities to develop domain expertise, execution, and organizational culture. ### Source excerpt Six years ago, I wrote Tech Lead Management roles are a trap. My argument then was that TLM roles present themselves as easier than moving into a full management role, but the tension between doing the software engineering and engineering management aspects of the role made being a TLM a much harder first management role than a pure engineering management role. I still agree with that post, and I have some additional bad news to share: middle management roles are mostly a trap as well, if you goal is to become an executive. The core aspects of middle management roles are: Balancing between top-down executive, lateral stakeholder, and bottom-up team pressure, e.g. keeping morale up as an organization deprioritizes last year's big initiative Defining and operating an organization's process, e.g. creating career ladders and interview loops Competing for a share of fixed organizational resources (e.g. budget) and allocating acquired resources These are all extremely important skills to be an effective executive, and they make up the bulk of The Engineering Executive's Primer, but they are insufficient to make you a great executive. If you don't have them, you will be a deeply flawed executive, but even if you're an expert at them, you can still be a terrible executive. That's because the most important skills of an effective executive are the same exact skills that make an excellent line manager: developing domain expertise, driving execution (including setting pace), and translating both of those into an organizational culture that extends beyond you (in any of innumerable different ways). All of them are more easily practiced and mastered as a line manager than as a middle manager. Most middle management roles make practicing those skills difficult, and sometimes negatively select against developing them. As a middle manager, if you drive execution too closely, you might get told off as a micromanager. As a middle manager, if you go too deep on domain expertise, you m ## Agentic Code Quality DevFeed: [Agentic Code Quality]() Original publisher: [Read original article]() Author: Addy Osmani Published: 2026-08-08T00:00:00Z Content type: article Language: en Sources: [Addy Osmani]() Topics: [Code quality](), [Testing](), [mutation-testing](), [engineering-culture]() Tags: [code-quality](), [mutation-testing](), [testing](), [tests](), [time]() ### AI overview The article argues that code quality for agent-generated software depends on quality gates and deterministic constraints enforced through the surrounding harness, environment, and operating system. It discusses unit, property, acceptance, and mutation testing, along with code-quality metrics and checks on the scope and safety of proposed changes. ### Source excerpt Quality now depends on the constraints you set around your agents. ## Hedge 315: Engineering Psychology DevFeed: [Hedge 315: Engineering Psychology]() Original publisher: [Read original article]() Author: Russ Published: 2026-08-07T13:54:37Z Content type: article Language: en Sources: [rule 11 reader]() Topics: [engineering-culture](), [Software Engineering](), [Network](), [Software](), [Artificial Intelligence]() Tags: [ai](), [audio](), [engineering](), [hedge](), [network](), [software-engineering]() ### AI overview A discussion of the psychology of software engineering and its application to network engineering, focusing on human infrastructure, engineer productivity, and individual flourishing. It also mentions the impact of AI on work. ### Source excerpt We often talk about "human infrastructure" in network engineering--but what does this mean, and how do we help engineers "produce" while helping them to flourish as individuals? Catherine Hicks joins Tom and Russ to discuss the psychology of software engineering, and how the lessons learned apply to network engineering. https://media.blubrry.com/hedge/media.blubrry.com/hedge/content.blubrry.com/hedge/hedge-315.mp3 download You can find Catherine's new book on the psychology of software engineering here. If you would like to follow Catherine's writing in this area, including the impact of AI on work, you can find her blog here. You can connect with Catherine on LinkedIn. ## Cloud provider postmortems: volume vs depth DevFeed: [Cloud provider postmortems: volume vs depth]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-08-05T00:00:00Z Content type: opinion Language: en Sources: [Sridhar Rajarao]() Topics: [Cloud](), [incident](), [SRE](), [site-reliability-engineering](), [engineering-culture]() Tags: [2017](), [2025](), [2026](), [aws](), [azure](), [cloud](), [dynamodb](), [engineering-culture](), [gcp](), [incident](), [incident-management](), [postmortems](), [s3](), [sre](), [transparency](), [writeup]() ### AI overview The article compares public postmortem practices among Google Cloud, Azure, and AWS. It argues that Google Cloud emphasizes high volume and speed, Azure emphasizes detailed transparency and customer accountability, and AWS publishes fewer writeups with greater depth and industry influence. ### Source excerpt GCP publishes 100+ postmortems a year. AWS publishes almost none. Azure has become the transparency leader. What each posture reveals about engineering culture, and what SREs should steal from all three. ## Why engineering managers lose hands-on coding time DevFeed: [Why engineering managers lose hands-on coding time]() Original publisher: [Read original article]() Author: Anton Zaides Published: 2026-08-04T06:01:00Z Content type: article Language: en Sources: [Manager.dev]() Topics: [engineering-culture](), [Software Engineering](), [Development](), [AI-assisted coding]() Tags: [ai](), [coding-agents](), [engineering](), [engineering-manager](), [manager]() ### AI overview The article examines how engineering managers gradually lose hands-on coding time as meetings, coordination, and project responsibilities increase. It argues that this shift can become a habit and discusses the case for managers remaining connected to the codebase. ### Source excerpt Never prompted until today ## How building software is changing at Anthropic DevFeed: [How building software is changing at Anthropic]() Original publisher: [Read original article]() Author: Gergely Orosz Published: 2026-07-28T15:49:30Z Content type: article Language: en Sources: [The Pragmatic Engineer]() Topics: [anthropic](), [Artificial Intelligence](), [Code review](), [Testing](), [engineering-culture]() Tags: [ai](), [anthropic](), [code-review](), [teams](), [testing]() ### AI overview This article examines changes in how Anthropic builds software, including increased use of AI for code review and testing and the continued use of two-pizza teams. ### Source excerpt A deepdive on what's changed in how the leading AI lab makes software. Ever more code review and testing is done by AI, two-pizza teams very much alive, and more. Details from inside of Anthropic ## Hiring, parallelization, and code review practices for engineering teams DevFeed: [Hiring, parallelization, and code review practices for engineering teams]() Original publisher: [Read original article]() Author: Anton Zaides Published: 2026-07-28T06:01:00Z Content type: opinion Language: en Sources: [Manager.dev]() Topics: [Software Engineering](), [engineering-culture](), [sdlc](), [pull-requests](), [Job]() Tags: [code-review](), [engineering](), [hiring](), [sdlc](), [software-engineering]() ### AI overview This guest article discusses three practices the author says engineering teams should focus on: continuously improving hiring, learning to parallelize work effectively, and adapting code review workflows. It presents these ideas as based on the CTO's experience and observations of productive teams. ### Source excerpt Hiring, parallelization, and why they stopped reviewing most PRs ## How to be useful as a software architect DevFeed: [How to be useful as a software architect]() Original publisher: [Read original article]() Author: hi@swizec.com (Swizec Teller) Published: 2026-07-25T00:00:00Z Content type: opinion Language: en Sources: [Swizec Teller]() Topics: [engineering-culture](), [Code review](), [Automation](), [Software]() Tags: [architecture](), [automation](), [code-review](), [culture](), [software](), [system-design]() ### AI overview The article argues that useful software architects improve the future of a codebase by building systems that let teams move quickly and safely. It emphasizes culture, feedback loops, automation, code review, system design review, testing, and shepherding work into production without becoming a bottleneck. ### Source excerpt Software architects have a weird role: Think about the code _tomorrow_. Today's code is what it is, how do we make it good tomorrow? Without slowing down, losing business, or falling off a cliff. ## Platform engineering tools you NEED to know in 2026 DevFeed: [Platform engineering tools you NEED to know in 2026]() Original publisher: [Read original article]() Author: Mallory Haigh Published: 2026-07-23T05:40:01Z Content type: article Language: en Sources: [Platform Engineering Blog]() Topics: [Platform Engineering](), [Backstage](), [engineering-culture](), [Kubernetes](), [API](), [Orchestration]() Tags: [api](), [architecture](), [culture](), [developers](), [engineering](), [guide](), [how-to](), [k8s](), [kubernetes](), [platform](), [platform-engineering](), [tools]() ### AI overview A strategic guide to platform engineering tools in 2026, emphasizing adoption, developer workflows, culture, product thinking, and architectural principles over tool installation or vendor marketing. It introduces a three-tier platform architecture and discusses backend orchestration through a unifying API, with examples including Backstage and Kubernetes. ### Source excerpt Platform engineering tools you need for 2026, framed by adoption-first thinking, three-tier architecture, and the must-know stack from K8s to AI. ## Engineer Cloud Cost Awareness: Why It Fails & Fixes DevFeed: [Engineer Cloud Cost Awareness: Why It Fails & Fixes]() Original publisher: [Read original article]() Author: Kelsey Rosen Published: 2026-07-23T00:00:00Z Content type: tutorial Language: en Sources: [Harness Blog]() Topics: [Cloud](), [finops](), [engineering-culture](), [systems](), [Development](), [Optimization](), [Automation]() Tags: [automation](), [best-practices](), [cloud](), [culture](), [development](), [engineering](), [finops](), [infrastructure](), [optimization](), [workflows]() ### AI overview This guide explains why engineers often overlook cloud costs: cost data lacks visibility, incentives are misaligned, and feedback is disconnected from development workflows. It recommends embedding cost awareness through automation, real-time feedback, and FinOps practices. ### Source excerpt Discover why engineer cloud cost awareness fails and proven strategies to build accountability. Learn how Harness Cloud & AI Cost Management helps. | Blog ## How Do You Know That? DevFeed: [How Do You Know That?]() Original publisher: [Read original article]() Author: Kent Beck Published: 2026-07-22T14:10:06Z Content type: opinion Language: en Sources: [Software Design: Tidy First?]() Topics: [AI Agent](), [engineering-culture](), [coding]() Tags: [agent](), [ai-agent](), [coding](), [engineering]() ### AI overview A podcast conversation with Beth Andres-Beck about software engineering accountability, why teams may fail to write tests, how people learn to solve difficult problems, and what it means for an AI agent to lack its own drive. ### Source excerpt Stream the latest episode ## AI-Assisted Programming and Shared Understanding in Software Projects DevFeed: [AI-Assisted Programming and Shared Understanding in Software Projects]() Original publisher: [Read original article]() Author: Armin Ronacher Published: 2026-07-13T00:00:00Z Content type: opinion Language: en Sources: [Armin Ronacher]() Topics: [Artificial Intelligence](), [engineering-culture](), [Documentation](), [Code review]() Tags: [ai](), [ai-assisted-programming](), [code-review](), [documentation](), [thoughts]() ### AI overview An opinion piece arguing that AI-assisted programming can make individual developers faster, but large software projects still depend on teams coordinating a shared understanding of the system. ### Source excerpt I feel that some vibecoded software changes somewhat randomly and unexpectedly. That made me think about Bruegel's "The Tower of Babel" which shows an already quite chaotic depiction of the Tower of Babel. The story is one of pride and ambition and ultimately why people no longer speak the same language. But it is also a story about the unity that makes technological progress work. The text begins with a technology upgrade: And they said one to another, Go to, let us make brick, and burn them thoroughly. And they had brick for stone, and slime had they for morter. They use it for a civilizational project: let us build us a city and a tower, whose top may reach unto heaven But when God assesses the situation the bricks are not what concern him: the people is one, and they have all one language, [...] and now nothing will be restrained from them.1 They get their power through coordination which they have because they share a language. They can use this to coordination to combine their powers and build something no one of them could build alone. God does not take away the bricks or their knowledge of how to make them but their ability to understand one another. With AI-assisted programming we should get better tools which lets us build more ambitious software. That is certainly true at the level of the individual and without doubt a developer with an agent can change a codebase dramatically quicker. But large software projects have never been limited only by how quickly an individual can produce code but they are limited by how well people can coordinate their understanding of the system they are changing. The shared language of a software project is the common understanding shared among its developers. This language is rarely written down in one place but it lives in documentation and code. It can also just be something that comes up in code review or watercooler conversations or when one engineer has to explain a change to someone else. It can be about the architecture ## A critique of arguments for doing more AI DevFeed: [A critique of arguments for doing more AI]() Original publisher: [Read original article]() Author: Sergio Visinoni Published: 2026-07-08T09:16:36Z Content type: opinion Language: en Sources: [Sudo Make Me a CTO]() Topics: [Artificial Intelligence](), [Code review](), [engineering-culture]() Tags: [ai](), [charity-majors](), [code-review](), [discussion]() ### AI overview The article responds to two articles by Charity Majors, examining arguments about AI, resistance to AI enthusiasm, ethical considerations, and the role of code review. It argues that the articles' conclusions remain unconvincing to the author. ### Source excerpt A reaction to two recent popular articles by Charity Majors. Is AI a big deal? Is resistance to AI fundamentalism? Does the solution to the current problems emerge from doing more of it? ## Theory of constraints, AI, and code review DevFeed: [Theory of constraints, AI, and code review]() Original publisher: [Read original article]() Author: hi@swizec.com (Swizec Teller) Published: 2026-07-06T00:00:00Z Content type: opinion Language: en Sources: [Swizec Teller]() Topics: [Artificial Intelligence](), [Code review](), [engineering-culture](), [Pull Request](), [Code]() Tags: [ai](), [code](), [code-review](), [productivity](), [pull-requests](), [review]() ### AI overview The article argues that producing code faster with AI does not necessarily increase company-wide delivery because overall throughput is constrained by slower parts of the development system, especially code review and release processes. ### Source excerpt Feedback from an expert is how you learn taste. Your code doesn't matter until it's shipped. [Next page]()