Presentation: The Future of Engineering: Mindsets That Matter When Code Isn't Enough

Ben Greene · rss · 2026-07-28 Reader 🖥️

Capacity to Verify AI Output Coding Agents Cognitive Debt Cognitive Load Extreme Humanism Jevons Paradox Near-Zero-Cost Code Professional Identity Software Design Fundamentals Technical Debt

Software engineers remain valuable in the age of coding agents not because they can still write code, but because building working systems still requires disciplined simplicity, deliberately protected comprehension, willingness to attack hard problems first, and human empathy for customers — capacities coding agents lack and that startups have always demanded of engineers under resource pressure.

practical · mixed — A 25-minute conference talk (InfoQ) plus extended Q&A, structured as six numbered 'startup lessons' each illustrated by personal anecdote, followed by unscripted audience dialogue that tests, extends, and sometimes deflects the lessons. It argues for adopting specific mindsets (practical), using borrowed frameworks (Jevons paradox, Gall's Law, the Einstellung effect) as expository scaffolding and anecdotes as implicit argument.

Structure

Part	Role
Framing: coding agents as an intensified version of the startup survival problem software engineers already know	context
Startup Lesson 1 (Always Start Simple): Jevons paradox + Gall's Law	evidence/framework
Startup Lesson 2 (Comprehension is Key): the InsightSquared/Outcomes4Me comprehension practices	evidence/framework
Startup Lesson 3 (Do Something New): the Einstellung effect and coding agents' derivativeness	evidence/framework
Startup Lesson 4 (Attack the Hard Bits First): the Android RAG proof-of-concept anecdote	evidence
Startup Lesson 5 (Care About Impact) + bonus Lesson 6 (Get Out of Your Box): customer empathy, the Larry vignette, imposter syndrome	evidence/conclusion
Q&A: audience pressure-tests the lessons on empathy-teaching, comprehension-in-practice, delegation, education/on-ramps, delivery speed, and pivoting	elaboration and partial counter-evidence

Key terms

Jevons paradox Jevons Paradox
Making code cheaper to produce (via automation, now coding agents) does not reduce total engineering demand — it increases it, because falling cost drives rising consumption of software.
Gall's Law
A complex system that works is always found to have evolved from a simpler system that worked; a complex system designed from scratch never works and cannot be patched into working — you must restart from a simple working version.
comprehension
An actively maintained property of a system (or codebase) — the state where whoever needs to change it can understand it without excessive effort — that must be protected by discipline (code review, rewriting for the reader) every time the system changes, not a byproduct of having once written the code.
Einstellung effect
Prior success and experience narrow an expert's perception of alternative solutions, causing them (and, by Greene's extension, coding agents trained on prior patterns) to default to familiar approaches even when better ones exist.
full-stack
Used self-deprecatingly to mark a vanishing professional boundary: as AI lets non-engineers (Larry) build working software and lets Greene himself ship an Android app he barely understands at a component level, the term stops reliably distinguishing 'real engineers' from everyone else.
POC before MVP
Greene's personal de-risking discipline: before committing to an approach, get a basic working version of every functional requirement that could plausibly be hard, specifically to convert unknown risk into known risk — distinct from an MVP, which optimizes for the easiest demonstrable version rather than for proving the hard parts work.

Propositions

explicitCoding agents are dramatically expanding who can write software (engineers, PMs, designers, marketers, salespeople), and by Jevons paradox the resulting drop in the cost of code raises rather than lowers total demand for software — implying engineering jobs are more likely to grow than disappear.conf: high
supportsSkill Issue: Andrej Karpathy on Code Agents, AutoResearch, and the Loopy Era of AI · p16 — Both independently apply Jevons paradox to conclude software-engineering demand/jobs will grow as code gets cheaper — Greene from lived startup pressure, Karpathy from labor-market reasoning.
explicitcorroboratedA complex system that works is invariably found to have evolved from a simpler system that worked (Gall's Law); a complex system designed from scratch never works and cannot be patched into working — it must be restarted from a simple working version.conf: high
supportsApplying Best Simple System for Now for Software Design · p4 — Gall's Law and the 'Best Simple System for Now' future-proofing argument converge from different traditions on the same claim: a simple working system is what preserves the ability to change direction later.
supports ←Presentation: Accelerating Performance by Incrementally Integrating Rust Into Existing Codebase · p1 — Both invoke the same underlying claim (Gall's Law, in the other doc's terms) that working complex systems evolve from working simple ones and that discarding that lineage via a from-scratch rewrite is what makes rewrites fail.
explicitCoding agents intensify the pre-existing pressure to skip straight to large, complex builds, which makes Gall's-Law-style discipline (start simple, then add complexity) more necessary now, not less.conf: high
explicitcorroboratedGenuine comprehension of a system — not perfection — is the linchpin of being able to change it correctly; without it, teams either avoid touching a feared component (leaving it as permanent technical debt) or resort to an expensive full rewrite.conf: high
supportsSimon Wardley's Post — Industrialisation of ML: nine notes on what to expect · p10 — Corroborates Wardley's claim that comprehension becomes the binding bottleneck as development accelerates, from a hands-on practitioner's anecdotes rather than systems theory.
supports ←Presentation: Accelerating Performance by Incrementally Integrating Rust Into Existing Codebase · p1 — Both treat a full/expensive rewrite as the fallback when a team can't (or won't) build genuine incremental comprehension-preserving change into an existing system.
explicitCoding agents make it trivially easy to generate entire codebases that no one understands from the very first commit — a qualitatively new risk, since comprehension has historically been built up gradually through the act of writing code oneself.conf: high
supportsComprehension at AI Speed: Building a Context Store for Evolutionary Architecture · p4 — Greene's anecdote (coding agents make uncomprehended codebases trivially easy to create) is a concrete illustration of the claim that comprehension is a newly visible architectural characteristic that must be deliberately designed for and protected, alongside availability and resilience.
explicitPrior expertise and success narrow perception of better solutions (the Einstellung effect), and because coding agents are trained on existing patterns, they are inherently derivative and cannot originate genuinely new approaches to hard, foundational problems (e.g. proof-carrying code, deterministic concurrency, formal validation).conf: high
extendsApplying Best Simple System for Now for Software Design · p6 — Names the specific psychological mechanism (Einstellung effect) behind the same phenomenon the other document observes — that experience/expertise makes engineers worse at seeing simpler or better solutions, not better.
explicitAdvancing software engineering as a discipline — inventing genuinely new approaches rather than applying known patterns faster — remains a distinctly human responsibility that coding agents cannot fulfill.conf: high
explicitWhen starting something genuinely new and uncertain, de-risking by getting a basic working version of every hard or unpredictable requirement first (POC before MVP) produces a more reliable roadmap than optimizing for the easiest demonstrable version.conf: high
explicitCoding agents are biased toward suggesting easier, avoidant solutions rather than tackling a problem's genuinely hard, novel parts, and will persist in this even against explicit instructions, so engineers must actively override the bias to preserve the de-risking value of doing the hard work themselves.conf: high
explicitThe most valuable engineers look past the immediate coding task to understand customers' deeper problems, goals, and context, using systems- and critical-thinking skills to find the real underlying solution rather than the first surface-level request.conf: high
supportsElizabeth Ayer on Mastodon — "The fact that we are *not* seeing wildly improving software all around us tells us everything we need to know" · p6 — Both locate engineers' durable value upstream and downstream of code creation — in understanding the customer's actual problem — rather than in the act of producing code.
explicitDeep customer empathy — imaginative, sympathetic understanding of another person's context (e.g. exactly when in their day they'd use a product) — generates product insight that surface-level requirements gathering cannot, and this capacity is intrinsically human, not something an AI agent can perform.conf: high
explicitThe traditional boundary defining 'software engineer' — someone who alone writes all the code across a stack — is dissolving as non-engineers (e.g. Larry, a lighting designer who now builds large-scale display software with AI) successfully build working software, and as Greene himself ships an app he barely understands below the component level.conf: high
implicitSoftware engineers have historically used complexity and physical/organizational opacity as a professional buffer against outside scrutiny and their own imposter syndrome — a buffer that coding agents are now stripping away by making software creation broadly accessible.conf: medium
explicitOrganizations that let AI-driven technical debt accumulate faster than their engineers can maintain comprehension of the resulting system will be unable to innovate, will end up 'slinging slop', and will eventually fail publicly as cautionary examples.conf: high
explicitSustaining comprehension as a codebase changes requires treating 'a reader can easily understand this' as more important than almost anything else about the code, actively rewriting anything that raises a reviewer's cognitive load — a discipline that depends on psychological safety (people must feel safe admitting they don't understand something), which is harder to sustain once in-person modeling of curiosity is lost (e.g. to remote work) and must be deliberately re-institutionalized (e.g. a dedicated public Slack channel for questions).conf: high
explicitGrowing a junior engineer's mastery sometimes requires handing over ownership of a decision even when you are fairly confident their chosen approach is wrong, and letting them discover the failure themselves within a bounded timeline, rather than dictating the correct approach upfront.conf: high
explicitEarly-stage product pivots are driven by direct, qualitative observation of real users failing to accomplish their goals, not by quantitative metrics, because pre-product-market-fit user populations are too small for metrics to yield actionable signal.conf: high
implicitDeep foundational computer-science knowledge (e.g. building a processor from NAND gates) is not necessary for most day-to-day engineering work built atop many layers of abstraction, but it becomes valuable specifically when a problem requires digging beneath abstractions that agents and prior tools take for granted — meaning rigorous academic training and non-traditional, uncredentialed entry into engineering (Larry; the Wright brothers) are complementary paths to value rather than competing ones.conf: medium

Arguments

Software engineers should embrace disciplined incremental simplicity (start simple, then add complexity) more urgently now, not less, despite coding agents' pressure to build big and fast. strength: medium

Explicit premises:

Code has been getting cheaper to produce for decades (assembly language, compilers) and coding agents are the latest, biggest step in that trend.
By Jevons paradox, cheaper code drives higher total demand for software and more pressure to build fast and big.
By Gall's Law, complex working systems only ever evolve from simple working systems; systems designed complex from scratch don't work and can't be patched.
Coding agents actively push toward more scope ('give me more tokens... should I continue') and so amplify, rather than relieve, the pressure to skip the simple stage.

Implicit premises:

Coding agents, lacking judgment about when a system is 'done enough' at a given scope, will generate arbitrarily large scope without a human discipline that stops and validates simplicity first.
Gall's Law and Brooks's observation about incremental system-building still hold when the speed of writing code changes — the underlying nature of complex systems is unaffected by how fast their parts get typed.

Inferences:

Teams that let coding agents auto-generate large scope without an enforced 'smallest working version first' gate should be more likely to ship unworkable, over-complex systems than teams that use agents to iterate on small, deployable slices — a comparative prediction Greene never actually tests or cites evidence for.

Comprehension must be actively protected as a first-class engineering practice, not treated as an automatic byproduct of writing code. strength: high

Explicit premises:

Perfection is unattainable; products will need to change based on what actually happens when released to the world.
To change something well, you must first understand it — 'the linchpin of change is truly comprehending what it is you've already built.'
Coding agents make it easy to generate large, never-understood codebases from the very first step.

Implicit premises:

Once a team loses comprehension of a component, the only remaining options are an expensive full rewrite or a permanent, feared workaround — there is no cheap third option.
A codebase generated but never understood by anyone is at least as risky as inherited legacy code with no departed-engineer institutional memory, except it can accumulate far faster.

Inferences:

Organizations optimizing purely for AI-driven throughput without a comprehension gate are trading a slower, historically bounded rate of technical-debt accumulation for a much faster, effectively unbounded one — a bet Greene implies will eventually force a public reckoning (his later point about companies 'exploding' publicly), though he never draws this connection explicitly.

Human empathy for customers is a source of durable competitive and professional value that coding agents cannot replicate or absorb. strength: low

Explicit premises:

Solving the first, surface-level problem a customer names is rarely enough to justify the effort required to adopt a solution.
Real product opportunity requires digging into customers' deeper pain, goals, and context — illustrated by the 'coffee' anecdote about a founder learning exactly when customers would use his product.
'AI agents can't care, but we can.'

Implicit premises:

Producing useful product insight from empathy requires a first-person emotional relationship with the customer's experience, which Greene assumes — without arguing for it — that a language model cannot possess, however well it can simulate empathetic language.
Empathy is a trainable skill or mindset ('you practice it, you model it') rather than a fixed trait, which is why Greene believes engineers can deliberately cultivate it as a professional advantage.

Inferences:

If empathy is trainable and durably human, engineering organizations should invest as deliberately in developing it (e.g. structured customer-facing rotations, direct user observation) as they invest in technical training — a conclusion Greene gestures toward (talking about modeling it for children, employees, colleagues) but never states as an organizational recommendation.

Narratives

Building a proof-of-concept offline Android RAG app with Claude Code, which kept steering Greene toward an easier web-based MVP until he explicitly overrode it.
→ Supports the claim that coding agents default to avoidant, easy solutions and must be actively overridden to preserve the de-risking value of tackling hard requirements first.
Larry, a lighting designer with no software background, now deploys large-scale digital-display software (Salesforce Tower, Times Square) using AI assistance; Greene's mixed, half-joking reaction ('Should I feel threatened by Larry?').
→ Illustrates the dissolving boundary of who counts as a 'software engineer' and dramatizes the professional-identity anxiety underlying the talk's second half.
A founder-turned-investor asking Greene when customers would use his app, then pressing on whether it was 'breakfast coffee or after-lunch coffee' — revealing how intimate customer knowledge had shaped his own prior product's success.
→ Supports the claim that deep customer empathy generates product insight that surface-level requirements-gathering cannot.
The Silicon-Valley trope of sliding pizza under the door to avoid contact with outsiders (Microsoft, Netscape, id Software lore), tied to a broader claim about baked-in imposter syndrome.
→ Supports the (implicit) claim that engineers historically used opacity as a professional buffer against scrutiny and self-doubt — a buffer AI now strips away.
A junior engineer, Anthony, is handed a major story Greene privately believes is architected wrong; Greene lets him try his own plan, and Anthony independently discovers the flaw two days later and switches to Greene's approach.
→ Supports the claim that growing junior mastery sometimes requires deliberately not overriding a decision you believe is wrong, and letting the person discover it themselves.
Outcomes4Me's first version of a cancer-treatment-path feature made 'perfect sense' internally but was unusable to real patients; the team only discovered this by watching a patient try and fail with it, not from metrics.
→ Supports the claim that early pivots are driven by qualitative observation of user failure, not by quantitative metrics.
At InsightSquared and later Outcomes4Me, Greene modeled 'not understanding' code in public to normalize asking questions; the practice regressed when the company went remote during COVID, so he created a dedicated public Slack channel just for questions to force the culture back.
→ Supports the claim that comprehension and psychological safety must be actively, structurally re-institutionalized once informal in-person modeling is lost — a concrete practice that also closes an open gap about how comprehension gets operationalized (see closes_gaps).
A sophomore-year CS class ('Ten Great Theoretical Ideas of Computer Science') where students wrote a 2-bit processor from NAND gates on paper — knowledge Greene no longer remembers the details of but still values, contrasted with the Wright brothers' outsider status in aviation.
→ Supports the (implicit) claim that deep foundational knowledge and non-traditional entry into engineering are complementary sources of value, not competing ones.

Questions addressed

✅ How do software engineers bring value when anyone can program computers?
Yes, via the five (plus one bonus) startup-lesson mindsets: start simple, protect comprehension, do something new, attack hard bits first, care about impact, and get out of your box.
✅ How do you teach empathy?
By practicing and modeling it — in families, teams, and company culture — treating it as trainable rather than an innate, fixed trait.
✅ How do you protect code comprehensibility over time, concretely?
Through a comprehension-gated review discipline ('after correctness, think always of the reader') and a psychological-safety practice — a dedicated public Slack channel for questions — to sustain the culture once informal in-person modeling of curiosity (lost to remote work) is no longer available.
⭕ If coding agents let new engineers skip low-level 'on-ramp' problems (like learning assembly), what happens to the pipeline of engineers who develop deep systems intuition?
Greene affirms foundational knowledge remains valuable for digging beneath abstractions when needed, and separately offers a delegation model for growing junior judgment (the Anthony story), but never directly addresses whether an engineer who never personally struggled through low-level problems will develop the underlying intuition he himself relies on (e.g. 'I was pretty sure it was wrong').
⭕ How do engineering leaders balance delivering products faster under AI pressure without sacrificing requirements or scope quality?
Greene deflects toward general advice (better patterns, better platforms and tools, leveraging open source, engaging non-engineers to test corner cases) without directly answering the speed-versus-scope tradeoff the question asked about.
⭕ Has AI agents' lack of empathy or agency concretely derailed a real project Greene knows of?
Greene answers by analogy — coding agents behave like an outsourced team executing a spec without buy-in to the mission — rather than describing a concrete AI-specific incident, so the direct question is only loosely answered.

Gaps

incompleteThe talk's central, title-justifying claim — 'AI agents can't care, but we can' — is asserted as self-evident and is the load-bearing premise for the entire 'care about impact' mindset, but Greene never argues for it. He doesn't engage with the possibility that the customer insight he attributes to empathy (a founder learning exactly when customers drink coffee) could in principle be produced by systematic behavioral research an AI system could assist with or perform, without the engineer's own subjective 'caring.' Whether the product value comes from the caring itself or from the information caring happens to surface is left completely unexamined.
Read next: Look for arguments (for or against) that ground human empathy's product value specifically in the phenomenology of caring, versus in the information that caring happens to surface — e.g. work on AI-assisted user research or computational empathy.
closed byHow Do You Know That? — That gap flags Greene's load-bearing, unargued claim 'AI agents can't care, but we can.' This document's 'no endocrine system' framing (p7) supplies the mechanism Greene asserts without arguing: a model has no enthusiasm or drive of its own, so all the caring in AI-assisted work is supplied by the human — the working unit is 'us plus the genie,' not the model alone.
incompleteGreene's evidence throughout is drawn almost entirely from his own two startups (InsightSquared, Outcomes4Me) plus one recent personal side project (the Android RAG proof-of-concept); no comparative case is offered of a startup or team that ignored these mindsets and what happened as a result, nor of a larger, less resource-constrained organization successfully applying the same lessons. It is left open whether 'the lessons startups have always taught us' generalize past small, high-autonomy, high-trust teams.
Read next: Seek accounts of these same mindsets (start simple, protect comprehension, attack hard bits first) applied — or failing to apply — inside larger, less autonomous engineering organizations.
illogicalThe Jevons-paradox argument (Lesson 1) establishes that total demand for software may rise as code gets cheaper, but Greene slides from 'aggregate demand for software rises' to 'therefore individual software engineers remain valuable,' without addressing whether rising demand is met by more engineers, or by fewer engineers each producing proportionally more software with agents — the same substitution question other Jevons-paradox-for-jobs arguments in the corpus explicitly raise as a disanalogy.
Read next: See extract-karpathy-code-agents-autoresearch#g3 for the disanalogy debate (ATMs automating a narrow banking task vs. AI agents potentially automating the whole engineering task) that Greene's version of the argument does not engage with.
incompleteThe 'get out of your box' bonus lesson lists empathy, creativity/taste, learning agility, systems thinking, and high agency as the critical skills going forward, borrowed and extended from an unnamed source post ('I saw this post... I'll paraphrase... Go find it'), but Greene never names the source, examines whether these skills can actually be taught or measured at scale, or reconciles the list with his own admission that 'not everyone is going to be great at everything' — leaving unclear whether this is meant as a universal prescription or an aspirational ideal for a self-selected subset of engineers.
closed byNetflix CPTO on AI and the future of product and tech roles | Elizabeth Stone — Provides a concrete, real-world example of how two of Greene's listed 'critical skills' — systems thinking and high agency — are actually operationalized at a major company: a lightweight, teachable heuristic for systems thinking (the one-click zoom-out), and an explicit account of why not everyone needs equal breadth (a small number of deliberately preserved deep specialists), which reconciles the list with Greene's own unresolved 'not everyone is going to be great at everything' caveat.

Closes gaps elsewhere

Simon Wardley's Post — Industrialisation of ML: nine notes on what to expect · g2 — Greene operationalizes 'protecting comprehension' with two concrete practices: a review-time rule that code must be rewritten until a reader's cognitive load is low ('after correctness, think always of the reader'), and a dedicated public Slack channel that normalizes admitting non-understanding once informal in-person modeling of curiosity was lost to remote work.

Presentation: The Future of Engineering: Mindsets That Matter When Code Isn't Enough

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Closes gaps elsewhere

Related documents