Cypher-X

Ben Greene's talk starts from an uncomfortable premise: coding agents have made software production cheap enough that product managers, designers, marketers, and salespeople are all shipping code, and companies are visibly retasking their best employees to train agents on their jobs before laying off the humans who held them. His question is the one that follows from that: how do software engineers bring value when anyone can program computers? His thesis is that this is not a new situation but a familiar one arriving at scale. Startup engineers have always had to prove they deserve their job while simultaneously working out what that job now is, and the mindsets that make people effective in startups transfer directly to working alongside agents.

Greene is Co-Founder and CTO of Tessi, a startup applying AI and automation to home restoration after disasters, and co-creator of FreeFormula.Exchange. He describes himself as a four-time founding CTO, including at Outcomes4Me, Windshield, and NextLot, and draws examples from Outcomes4Me and from an earlier company, InsightSquared. He delivered this 44-minute, 44-second talk at QCon San Francisco 2025; InfoQ published the recording, slides, and transcript on July 28, 2026. He offered an alternative title for it: what startups can teach us about surviving the coding agent apocalypse.

These notes report what Greene presented and answered in the Q&A. Where I add background that an intermediate engineer needs but the talk did not state, the text says so explicitly.

What You Will Learn

Why cheaper code increases rather than decreases demand for engineering, and what Jevons paradox has to do with coding agents.
What Gall's Law says about building complex systems, and why it applies to your product and business as well as your architecture.
Why comprehension of your own codebase is the constraint on your ability to change it, and the concrete cultural practices Greene used to protect it.
What the Einstellung effect is, and why Greene argues both expertise and coding agents trend toward derivative solutions.
How the "POC before MVP" de-risking sequence works, and why coding agents actively push against it.
Why customer empathy is presented as the durable differentiator, and what failure looks like when it is missing.
What Greene's answers in the Q&A add on delegation, teaching problem solving, pivoting without metrics, and the organizational risk of accumulating code nobody understands.

The Setup: Jevons Paradox and the Demand for Software

Greene's first move is to argue that automation of software engineering is not new and has never reduced the amount of engineering work. He traces a lineage: Kathleen Booth designing the first assembly language in 1947, taking programming from direct hardware manipulation to symbolic instruction, and Grace Hopper designing and building the A-0 compiler in 1952, automatically translating mathematical instructions into executable machine code. Both are steps everyone celebrates, and both made software cheaper to produce. His observation is that each such step drove demand for computing infrastructure upward on what he describes as a logarithmic curve.

The mechanism he names is Jevons paradox: efficiency makes a resource cheaper to use, which causes people to use so much more of it that total consumption rises instead of falls. Applied to coding agents, the consequence is that now that everyone believes they can build software, demand for more software more quickly becomes more immense, not less. This is why Greene treats the "agents will free up engineering capacity" framing as incomplete. The pressure to produce goes up alongside the ability to produce, and he is blunt that agents ratchet that pressure up to 11 while being the worst offending enablers imaginable: do more, add more, give me more tokens, Claude Code's perpetual "should I continue?"

Startup Lesson 1: Always Start Simple

The pressure Greene describes is the pressure to jump straight to the grand vision, to build fast and scale fast. He calls this a universal constant in startups that is getting worse, and argues software engineering is rife with failed attempts to build large systems wholesale. He points at Fred Brooks as having covered this well, and then offers his own one-line paraphrase for anyone in a "TL;DR phase of life": a system that works is invariably built from a smaller system that worked. That wording closely tracks the principle he names a moment later.

He then broadens the claim past code. A system, in his framing, is just a collection of connected pieces that form a whole. Your tech is a system, but so is your product, which is a system designed to get outcomes for users or customers, and so is your business, which is a system designed to produce more money than it costs to operate. All three need to start simple. The principle he names for this is Gall's Law, from John Gall, who Greene points out was a pediatrician rather than a computer scientist:

A complex system that works is invariably found to evolve from a simple system that worked. A complex system designed from scratch never works and cannot be patched to make it work. You have to start over with a working simple system.

Greene's practical instruction follows directly. If your business, product, or tech does not produce the results you want when it is small and simple, making it bigger and more complicated will not fix it. Go back, fix it, then add complexity.

Supplementary note, not from the talk: it is worth being explicit about why this gets harder with agents. Effort used to be the thing that forced teams into small increments by default. Once generating a large system costs minutes, starting simple stops being a constraint the tooling imposes and becomes a decision you have to make and defend deliberately.

Startup Lesson 2: Comprehension Is Key

Greene's second lesson is the one he returns to most often, and it rests on an assumption about change. Perfection is not attainable, and change will be directed by what actually happens when you release to the world. The startup formulation he cites is that if you are not embarrassed by your product, you shipped too late, because much of the polish you add gets thrown away once you discover your underlying assumptions were wrong. At InsightSquared they called this shaving the yak: it is ugly and it smells, and giving it a beard trim will not make a difference.

If change is inevitable, then the ability to change correctly is what you need to protect, and that ability depends on understanding what you already built. Greene calls comprehension the linchpin of change. His diagnosis of the familiar situation where a simple-sounding request turns out to take weeks instead of hours is that there is some intricately wired bomb in the code that nobody understands and everybody is afraid to change. The two available responses are to heroically replace the entire component or to cowardly work around it, and in his experience you usually do the latter.

Coding agents make this failure mode available from the first commit rather than after years of accumulated drift. Greene's description is that they make it incredibly easy to create entire codebases you do not understand from the very first step, which he compares to hiring a team that copies code off the internet at the speed of sound and always tells you exactly what you want to hear. He is explicit that he finds this terrifying. He is equally explicit that the answer is not to eliminate technical debt: technical debt is necessary, because it is not reasonable to build for your ten-year vision when you do not know whether the idea is viable at all. The requirement is that you know what trade-offs you are making, which is only possible if you understand what you shipped.

How to Protect Comprehension in Practice

An audience member pushed on this directly, noting that the obvious answer, documentation, does not work because teams do not write it consistently and nobody reads it when they do. Greene's answer is the most actionable material in the talk, and he frames it as an inductive proof. At zero code, he completely understands the system. To understand it when there is a lot of code, he needs to understand each increment as it is added. The mechanism for that is the code review process, applied to every change, whether it is code or infrastructure.

He concedes this sounds too obvious to be worth stage time, and then explains why it fails anyway: engineers are insecure about how smart they are, and it can be very hard for a software engineer to say "I don't understand this code." He says he has watched that happen many times and has done it himself. The countermeasure he built at Outcomes4Me was a stated engineering value that if the reader does not understand the code easily and the cognitive load is not low, the code needs to change. Variables, organization, whatever it takes, until it is easier to understand. His formulation is after correctness, think always of the reader, and his justification is that if a reviewer does not understand the change now, they will not understand it in a month when they need to modify it, and probably neither will the author.

The part worth copying is how he made the value stick. He modeled it by pretending to be really dumb and not understanding anyone's code, until eventually he did not have to pretend. That worked culturally until COVID sent the company remote, at which point he could no longer model the behavior in public and the culture regressed. His fix was to create a separate engineering Slack channel purely for asking questions, and to require everyone to ask their questions there in public, so that people could see it was acceptable to not know things in public. Note the underlying mechanic: the practice depends on public visibility of senior people not knowing things, so any change that removes that visibility, such as going remote, silently breaks it.

Startup Lesson 3: Do Something New

In startups, Greene argues, you need to be roughly ten times better than the alternatives to get noticed, and that requires doing new things. The obstacle he identifies is that competence itself narrows your options. He names the Einstellung effect, coined by psychologist Abraham Luchins and his mathematician wife Edith Hirsch Luchins, who showed that prior experience narrows perception and causes experts to default to familiar patterns even when those patterns are suboptimal.

His connection to agents is sharp: if humans get more derivative over time, agents are always completely derivative. He states this as a given rather than arguing for it. The examples he offers of work that would move the discipline forward are deliberately unglamorous research-adjacent problems. When are we adopting proof-carrying code? Who is going to get deterministic concurrency models into production? How will we bring formal validation to software engineering? His conclusion is that coding agents are not going to innovate and drive software engineering, or society, forward, and that this is left to engineers.

Supplementary note, not from the talk: proof-carrying code is a technique where compiled code ships with a machine-checkable proof that it satisfies a stated safety policy, so the consumer can verify it without trusting the producer. Deterministic concurrency models are designs in which a concurrent program produces the same result for the same input regardless of scheduling, removing an entire class of race conditions. Formal validation refers to mathematically proving properties of a program rather than sampling behavior with tests. Greene lists these as open frontiers rather than explaining them.

Startup Lesson 4: Attack the Hard Bits First

The fourth lesson is about de-risking. A startup is already placing a huge bet, so the goal is to eliminate as many other sources of risk as possible. When you are building something new, you have no idea how long it will take or how effective it will be, so Greene's rule at the engineering, product, and business levels is POC before MVP: prove the approach can work before committing to it.

Concretely, when he starts a project he lists all the functional requirements he thinks could possibly come up in the most important ways, and tries to get each of them working at some very basic level. The payoff is not the prototype itself but the change in variance. The more unpredictable pieces he clears, the more predictable the remainder becomes, and the closer he can get to the roadmap and timeline his business counterparts want. Note what he explicitly does not claim: a successful POC tells you an approach will work, not that it is the best approach.

His worked example is a proof-of-concept Android app he built the month before the talk, delivering a completely offline LLM experience with an on-device model and a connected on-device vector database for retrieval-augmented generation (RAG). He believed it was possible but wanted to be sure, and wanted to know whether he could assemble it quickly. He is not an Android developer, and he used Claude Code to build it.

The instructive part is the fight with the agent. Claude was, in his words, absolutely adamant that they build a web-based Llama-backed MVP instead, and kept raising arguments about having a quick demo and conserving tokens. Greene's objection is that a web-based demo proved nothing he did not already know; the whole point was the on-device path. He eventually had to instruct the agent explicitly to stop suggesting alternative solutions merely because they were easier. His generalization is that coding agents want to avoid the hard bits, engineers still need to do the hard work themselves, and that hard work remains the most valuable work.

Supplementary note, not from the talk: RAG is a pattern where, instead of relying only on what a model memorized during training, the system retrieves relevant documents at query time and includes them in the prompt. A vector database stores numeric embeddings of those documents so that semantically similar content can be found by nearest-neighbor search. Running both the model and the vector store on the device is what makes Greene's target fully offline, and it is also what makes it hard: the model must be small enough to run within phone memory and power budgets.

flowchart TD
    A[New project or feature] --> B[List all functional requirements
that could plausibly matter]
    B --> C{Identify the riskiest
and least understood}
    C --> D[Build a bare proof of concept
for each hard requirement]
    D --> E{Does the approach work?}
    E -- No --> F[Change approach
before committing]
    F --> C
    E -- Yes --> G[Remaining work is now
predictable enough to plan]
    G --> H[Build the simplest system
that produces the outcome]
    H --> I[Review every increment
for comprehension]
    I --> J[Ship, observe real users,
expect assumptions to be wrong]
    J --> A

The diagram above is my synthesis of the sequence Greene describes across lessons one, two, and four. He did not present it as a single flow.

Startup Lesson 5: Care About Impact

Greene's fifth lesson is that great startup engineers do not see their job as starting and ending with the code. They reach past the software problem into the customer problem and the business problem, and use their understanding of what technology can do to find solutions other people are not considering. His argument for why engineers specifically are well placed to do this is that they are generally the strongest systems thinkers and critical thinkers on the team, and the most versed in what technology can actually do.

The reason this matters commercially is a point about adoption rather than about craft. Solving the first problem you see is never enough in a startup, because the surface problem is not compelling enough to overcome the barriers in the way of adopting change. To break through, you have to keep digging into people's pain, their goals, and their hopes. His illustration is an exchange with a founder turned investor who asked when he thought customers would use the app. Greene answered "with their coffee," and the investor replied: is that their breakfast coffee, or their after-lunch coffee? The point the investor drew out was that at his own previous company, knowing his customers that intimately was the key to creating an experience that fit into their lives at the right moment, and that caring enough to get to know them produced the insight that led to a successful exit.

Greene names the mindsets he wants: speed to need, patience, waiting, and above all empathy, in the sense of stepping into the customer's shoes and feeling what they feel. He lists these without defining them. His summary line is the central claim of the whole talk: AI agents cannot care, but we can.

Larry, and What "Software Engineer" Even Means

To make the threat concrete, Greene tells a story about his friend Larry, who studied lighting design in college and now deploys large-scale digital displays, including the massive display at Salesforce Tower and many of the displays in Times Square. Larry has no experience creating software at all, and Greene's prompt for the story is a text message Larry sent him, which he uses to raise the question of whether he should feel threatened. Greene runs through the defensive reactions out loud, that Larry is not a real engineer and is not full-stack, and then rejects them: none of us can really call ourselves full-stack anymore, and when he is vibe coding an Android app that he barely understands at the component level and does not understand at all at the code level, he feels like a cross between a deity and a dumbass.

Having nearly double-majored in English, he looked up the definition of software engineering and fixed on two words in it: practical application. That, to him, is just creating solutions to real problems, and it is the identity he thinks holds up. Engineers are problem solvers, and what needs to change is how we go about it.

His self-criticism of the profession is that software engineers have long built buffers to keep others at bay. Sliding pizza under the door is celebrated Silicon Valley lore, reflecting real stories from Microsoft, Netscape, and id Software. His reading is that engineers like the freedom from prying eyes and the time to cope with a recurring dread that they are not as smart as they hope and are going to fail. He argues imposter syndrome is baked in deeply enough that it shapes how we work and the tools we build.

Bonus Lesson: Get Out of Your Box

Greene closes the prepared material by paraphrasing a post he liked on the skills becoming critical, listing creativity and taste as AI augmentation, learning agility, systems thinking, and high agency. He adds empathy as a fifth. His instruction is to go out into the world, explore it, care about it, and find problems that inspire you to build practical solutions. His optimistic case is that there are a great many problems, we are not running out any time soon, software can help with many of them, and therefore engineers have jobs to do. His closing framing is a responsibility claim rather than a reassurance: engineering changes the world, we are responsible for the change we create, so make it a good one.

What the Q&A Added

The Q&A is where several of the ideas got operational detail, so it is worth treating as part of the content rather than as an appendix.

Teaching empathy. Asked how empathy can be taught, Greene said you teach it by practicing it, and by modeling it for your children, employees, and colleagues until it is baked into a company culture. He defined empathy as sympathetic understanding: going out and genuinely trying to understand what someone else's life and problems are like rather than othering them, on the grounds that people are emotional at their core and put layers of logic on top. An audience member offered a heuristic they had learned from a manager, that we judge ourselves by our intentions and others by their actions, so assuming others' intentions differ from how their actions land makes us less judgmental. Greene connected this to the fundamental attribution error: when you make a mistake it is because you are a bad person, when I make a mistake it is because my environment failed me.

What missing empathy looks like with agents. Asked for a concrete case of agents derailing projects through lack of empathy, Greene compared it to working with a team outside your company that is not tied into the mission. They do exactly what you ask, which is not their fault, but it is often the wrong thing, because what you actually needed was a system that lets you test whether the thing is right at all. Under pressure to go fast, teams take the fastest path to where they think they want to go, arrive, and realize they ran waterfall while holding daily standups and two-week sprints. Nobody thought about the system they were trying to build at a basic level; they produced a pile of code that does one thing after another. He says he has hit the identical problem with Claude Code and Cursor as with disengaged external teams.

The optimistic reframe, and the gatekeeping problem. An audience member named Aaron argued that every organization has a backlog a mile deep, that much of the work engineers used to do was boring, such as writing yet another GET REST endpoint returning JSON in a new shape, and that handing that to agents lets engineers work on the interesting algorithmic problems they previously got two weeks a year on. He described a virtuous cycle for the unfamiliar work too: he does not know how to build an Android app, but he can now get the basics easily and then use the AI to learn the parts he does not know. He acknowledged that the anxiety is understandable because this is arriving during a period of layoffs. Greene agreed and said he had leveraged that fear in structuring the talk, but does not think the opportunities are going away. His addition was that engineers have to stop gatekeeping around writing software and accept that many colleagues will now create code, that it is the same work, and that engineers simply know it better and can help. He noted he has never once wished he could go back to programming a big computer mechanically.

Turning ticket-takers into builders. Asked how a technical leader shifts a culture of self-identified programmers toward problem solvers, Greene's first answer was to join a startup, where nobody has time to define exactly what you should do and there is no choice but to broaden. His leadership-specific answer targets a pattern he sees in engineers moving into leadership: a reticence to delegate until they know exactly how something can be done, because they feel that handing off a problem they have not solved sets the other person up to fail. His counter is that you are not growing the other person that way, and that you have to accept a certain rate of failed efforts. His example is a junior engineer at InsightSquared, Anthony, who took on a major story with a plan Greene was fairly sure was wrong. Greene told him "I don't know if this will work, here's what I think, but you should decide and do it your way and then we'll see," inside a two-week sprint. Anthony came back after two days having discovered it would not work and switched approaches himself. Greene's read is that he never took away the engineer's motivation or search for mastery and still got a working solution.

Whether new engineers lose the low-level on-ramp. An audience member named Paul noted that simpler and lower-level problems, like learning assembly, were what taught him how computers actually think, and asked what skipping that does to the pipeline of new engineers. Greene's answer was ambivalent. He recalled a sophomore class, "Ten Great Theoretical Ideas of Computer Science," where the class built a 2-bit processor on paper out of NAND gates using taped-together sheets; he no longer remembers how it worked, but knows it is possible and finds that valuable. He balanced this against the fact that we all build on many levels of compilation and other people's work that we are barely aware of. His position is that a strong academic background pays off specifically when you need to dig below the surface to solve a problem you cannot solve at the surface, and otherwise the abstraction is fine. He also argued the outsider perspective has real value, because people who do not know how programming works sometimes think of genuinely interesting ways for it to work, and cited the Wright brothers as among the least qualified people on earth to start building airplanes. This is the Einstellung effect from lesson three viewed from the other side.

Delivering faster without degrading the solution. Asked how leaders balance pressure to rebuild prior products faster against getting the requirements right, Greene said he is ready to move on from traditional software as a service and from building the same things repeatedly. His concrete levers are defining behavior better, looking for patterns, and finding platforms and reasonable tools, with open source as the main route to going faster without sacrificing the end result. His argument for open source is experiential: in no situation has he used an open-source library and concluded that its authors had spent less time thinking about that problem than he had. His second lever is engaging non-engineer colleagues in the creation process. Engineers are good at seeing corner cases and non-builders typically are not, but once a colleague has built something in Lovable or Replit and shows it to you, you can ask the corner-case questions: what if the person cannot do that, what about the roughly 10% of men who are red-green colorblind.

Pivoting without usable metrics. Asked what metrics drove pivots, Greene made a sequencing argument. You usually pivot because you have not found product-market fit; if you have not found product-market fit you have not reached scale; and without scale your metrics do not do much quantifiable good. You can see that a funnel is not working at all, but that gives no insight into what to change, because you do not have enough traffic to split test, and early on both variants are usually bad anyway. The substitute he found most valuable is taking the idea to a real person with the real problem and watching how spectacularly they fail at the goal you gave them. His example is Outcomes4Me, a product for cancer patients to understand their diagnosis, see what clinical guidelines say about treatment paths and options, find clinical trials, manage symptoms, and track medications. The first version of the treatment path was completely wrong: systematically coherent from the team's standpoint, but not consumable in the way patients framed the information in their own minds or interrogated it. He says he cannot imagine getting that feedback from numbers. Later, when the problem was that marketing was not working, better numbers did help.

Teaching problem solving itself. Asked what has to change in how students are taught, given that problem solving has always been the stated goal of computer science education, Greene declined to claim it needs reinventing. His model is the same as for engineering, or dribbling a basketball: someone sets you a challenge of appropriate difficulty for your current level, you practice until you can do it well and easily, and then you take the next level. What you are working toward is a state of flow, the task where the difficulty is high, your ability is also high, and it feels great. He added two caveats from experience: not everyone is going to be great at everything, which he says having children taught him and which he considers fine, and that he is not trained to teach, though he feels he has improved at it both as a parent and as a manager, roles he finds oddly similar.

The comprehension cliff at organizational scale. The final question came from someone who found that they no longer struggle with the code itself, but that when they produce a large volume of output and return two or three months later they no longer recognize it, and who reports their organization saying it would like to see 90% of engineers using agentic AI for their coding. Greene called this his lemming slide and said it is the part that scares him most. His pessimistic reading is that some companies understand the hole they are digging and believe they will ultimately be better off with AI that understands the code and no people. He does not think that will work, because those companies will not be able to innovate anything and will just be slinging slop. He admitted he does not know how to solve it. What he thinks has to happen is that the principle that engineering must proceed at a pace where the engineering team can continue to understand how things work has to pervade the whole organization, investors included, since investors need to understand what happens when you drastically increase the rate of accumulating technical debt, which is what this fundamentally is. The evidence he points to is public rather than internal: the widely circulated "I just vibe coded this app, how it's going" memes that end with the author taking it down under attack, and a run of problems that have become public. His reading of those is that people are realizing this is not ready for deploying production apps. His expectation is that some companies will go too far down this path and fall apart publicly, and that the industry will need to make examples of them, because people will keep trying it unless reminded how bad an idea it is, since those who do not know history are doomed to repeat it.

Trade-offs And Limitations

This is experience, not evidence. Everything here is Greene's reported experience across several startups plus one personal Android prototype. He presents no measurements, benchmarks, or studies, and does not claim to. Treat the lessons as well-argued heuristics rather than as validated findings.
Startup lessons do not transfer uniformly. The advice assumes an environment where you can talk to customers, choose your approach, and tolerate failed experiments. Engineers in regulated domains, large enterprises, or platform teams several layers from any customer will find "go meet your customer" and "join a startup" harder to act on than Greene's framing suggests.
Comprehension has a cost that Greene does not price. Requiring that every increment be understood by a reviewer directly limits how much agent throughput you can absorb. He advocates the discipline without addressing what it does to delivery commitments made on the assumption that agents make teams faster.
The public-questions practice depends on power dynamics. It worked because a CTO modeled not understanding things. In a team where admitting confusion is penalized in performance review, mandating public questions could backfire.
POC before MVP costs time and can mislead. Greene is careful that a successful POC shows an approach will work, not that it is the best one. It also spends effort on code you intend to throw away, which is hard to justify when the requirements themselves are the uncertain part rather than the technology.
Technical debt is endorsed but not bounded. He says technical debt is necessary and that you must know the trade-offs you are making, but offers no mechanism for tracking or repaying it beyond keeping the code comprehensible.
"Agents cannot innovate" is an assertion. Greene's claim that agents are always completely derivative is a reasonable inference from how models are trained, but he presents it as settled rather than as a position that is actively contested.
The risk analysis is about comprehension, not security or cost. Greene does not discuss the security implications of shipping agent-generated code you do not understand, the licensing exposure of code copied from training data, or the cost of running agents at scale. The comprehension argument implies these risks but the talk does not address them.

Practical Takeaways

Make "start simple" an explicit decision. Apply Gall's Law deliberately: if the small, simple version does not produce the result you want, fix that before adding complexity to your tech, your product, or your business model.
Gate every increment on comprehension, and make the reader the standard. Apply code review to infrastructure as well as code, and treat "after correctness, think always of the reader" as a stated value: if a reviewer cannot follow the change with low cognitive load, rewrite the naming and organization until they can. Merging something no reviewer understands is the failure mode, regardless of who or what wrote it.
Make not knowing things publicly visible. Model asking basic questions yourself, and if the team goes remote or otherwise loses ambient visibility, replace it deliberately, as Greene did with a dedicated public questions channel.
De-risk before you commit. List the functional requirements that could plausibly matter, build the crudest possible proof of concept for the hardest ones, and only then produce a roadmap.
Push back when the agent steers you toward the easy path. Greene had to explicitly instruct Claude Code to stop proposing simpler alternatives. If your goal is to prove a hard capability, an agent optimizing for a quick demo is working against your objective.
Ask what the customer's day actually looks like. "With their coffee" is not an answer; breakfast coffee versus after-lunch coffee is. Push your product understanding to that resolution before designing around it.
Delegate problems you have not solved. Give the direction and your opinion, let the other person choose, and accept a failure rate as the cost of growing people, as Greene did with the junior engineer at InsightSquared. Size the challenge just above current ability so the person is working toward flow rather than toward failure.
Do not wait for metrics to justify an early pivot. Before scale, watch one real user fail at the task in front of you; that produces information a broken funnel chart cannot.
Bring non-engineers into building, then ask the corner-case questions. Once colleagues have built something themselves in a tool like Lovable or Replit, they are far more receptive to questions about failure modes and accessibility.
Reach for existing platforms and open source before rebuilding. Greene's heuristic is that library authors have almost always spent more time on the problem than you are about to.
Raise comprehension as an organizational and investor-level concern. Framed as the rate of technical debt accumulation, it becomes a business risk argument rather than an engineering preference.

Key Terms

Jevons paradox — When efficiency makes a resource cheaper to use, total consumption can rise rather than fall because demand grows faster than the efficiency gain. Greene applies it to software: cheaper code increases demand for software.
Gall's Law — John Gall's principle that a working complex system invariably evolved from a working simple system, and that a complex system designed from scratch never works and cannot be patched into working.
Shaving the yak — How Greene's team at InsightSquared described polishing something whose underlying assumptions are wrong: it is ugly and it smells, and a beard trim will not help.
Einstellung effect — Named by Abraham Luchins and Edith Hirsch Luchins, the finding that prior experience narrows perception so that experts default to familiar patterns even when better solutions exist.
POC before MVP — Greene's de-risking sequence: build a rough proof of concept that the hard parts of an approach can work before committing to build a minimum viable product on that approach.
RAG (Retrieval-Augmented Generation) — Retrieving relevant documents at query time and supplying them to a language model as context, rather than relying only on what the model learned in training. Greene's prototype ran both the model and the retrieval index on the device, with no network.
Fundamental attribution error — The bias of explaining others' mistakes by their character and our own by our circumstances. Greene raises it as an obstacle to empathy.
Speed to need — One of the customer-facing mindsets Greene names alongside patience and waiting. He lists it without defining it.
Proof-carrying code — Shipping compiled code together with a machine-checkable proof that it satisfies a safety policy. Greene lists it as an example of the frontier work agents will not do for us.
Practical application — The phrase Greene extracted from the dictionary definition of software engineering and adopted as the durable core of the job: creating solutions to real problems.

Closing Assessment

The strongest part of this talk is not the list of startup lessons, which are individually familiar, but the causal chain Greene draws between them. Cheap code increases demand rather than relieving pressure; increased pressure encourages building complex systems wholesale; systems built wholesale by agents are not understood by the people who own them; and code you do not understand is code you cannot correctly change, which is fatal given that your assumptions will be wrong and change is guaranteed. Each link is arguable, but together they explain why comprehension rather than throughput is the thing he wants engineers to defend.

The empathy argument is the more contestable half. Greene's case that agents cannot care, and that caring is what surfaces the customer insight that makes a product worth adopting, is asserted rather than demonstrated, and his own examples of it, the coffee question and the Outcomes4Me treatment path, are recollections rather than evidence. What makes it worth taking seriously anyway is that it is consistent with the rest: both the comprehension failure and the empathy failure come from the same place, an engineering culture that has historically preferred to slide pizza under the door rather than admit what it does not know or ask whose problem it is actually solving.

Reference: Ben Greene, The Future of Engineering: Mindsets That Matter When Code Isn't Enough, QCon San Francisco 2025, published by InfoQ on July 28, 2026.