Slow down to speed up: AI and software engineering

Notes from Gergely Orosz's talk Slow down to speed up: AI and software engineering.

The main idea: AI makes code generation dramatically cheaper, but it does not make understanding, verification, ownership, or maintenance cheap. The bottleneck moves from typing code to deciding what should exist, checking whether it works, and keeping the system understandable.

TL;DR

• AI increases individual coding throughput, but team productivity can still fall if review, verification, and architecture do not scale with it.
• The dangerous metric is not “lines of code produced”; it is “trusted, maintainable value shipped.”
• Coding agents behave like very fast junior engineers: useful, tireless, and dangerous without guardrails.
• Senior engineers often benefit more than juniors because they can detect nonsense, constrain scope, and verify results.
• The practical advice is not “use less AI”; it is “cap agent usage to what you can review or verify.”

The core shift

Before AI, code was expensive mostly because humans had to write it. With coding agents, code becomes cheap. That sounds purely good, but it creates a new failure mode: organizations can accumulate code faster than they accumulate trust.

The hard parts become:

• understanding the product and domain;
• choosing the right problem;
• constraining the solution;
• reviewing and testing the output;
• preserving architecture and maintainability;
• deleting or simplifying code instead of only adding more.

This is why “slow down to speed up” is not anti-AI. It is pro-throughput, but throughput measured at the system level rather than the prompt level.

Token maxing

One pattern in the talk is “token maxing”: people and companies burn huge amounts of model output because generating code feels productive.

The problem is that output is not the same as progress. If the review queue, CI, product validation, and human understanding cannot absorb the generated code, then more agent work just creates backlog and cognitive debt.

A useful rule: do not generate more code than you can verify.

Why seniors get more leverage

AI can help juniors, but the talk argues that senior engineers often get disproportionate leverage because they have taste and context.

They know:

• what the codebase is supposed to do;
• which constraints matter;
• where the architecture is fragile;
• what a plausible but wrong answer looks like;
• when to stop an agent before it overbuilds.

A junior can ask an agent to build a mobile app. A senior can ask for the smallest safe change, review the result, and know what to throw away.

Agents are new junior engineers

One of the strongest frames: coding agents are like junior engineers that can be started in parallel.

That means the old boring practices become useful again:

• clear interfaces;
• domain boundaries;
• design patterns;
• explicit guardrails;
• boring enterprise constraints;
• tests and verification steps.

The talk explicitly suggests dusting off books about design patterns and using these patterns again. Not because patterns are fashionable, but because agents need rails.

Product thinking matters more

Do not outsource thinking to AI. The talk pushes engineers to become more product-minded and more domain-aware.

If you work in agriculture, talk to farmers. If you work in automotive, talk to mechanical engineers. The moat is not just “knows syntax”; it is “understands the domain well enough to tell the model what matters.”

This is also where the Product-Minded Engineer idea comes in: understand the business, talk to product managers, and know why the system exists.

AI engineering as a career direction

The talk points to AI engineering as a growing part of software engineering: building RAG, evals, internal tools, LLM systems, and workflows around models.

The recommended book here is AI Engineering by Chip Huyen.

The reason this matters: it gives engineers hands-on intuition about what LLM systems can and cannot do. That intuition compounds.

Reading list from the talk

Directly mentioned or strongly implied:

• AI Engineering — Chip Huyen.
• The Product-Minded Engineer — Drew Hoskins. Gergely Orosz separately says he has a blog post with the same title.
• Domain-Driven Design — not named as a specific book title in the transcript, but DDD is explicitly discussed as newly relevant for agent guardrails.
• Design Patterns — again, the talk does not give a specific title, but explicitly says it may be time to dust off design-pattern books.

Useful companions by theme:

• Domain-Driven Design — Eric Evans.
• Implementing Domain-Driven Design — Vaughn Vernon.
• Design Patterns — Gamma, Helm, Johnson, Vlissides.
• Software Engineering at Google — for engineering culture, review, maintainability, and scale. This one fits the theme, but I would not label it as a direct recommendation from the talk.

Practical takeaways

For individual engineers:

• Use AI, but keep your own judgment active.
• Build small internal tools and workflows to learn by doing.
• Learn AI engineering: RAG, evals, model behavior, internal agent systems.
• Become more product-minded and domain-specific.
• Use AI for understanding, tests, cleanup, and tech debt, not only feature generation.

For teams and engineering leaders:

• Measure outcomes, not code volume.
• Watch review bandwidth as a bottleneck.
• Build shared guardrails and patterns for agent work.
• Budget AI usage around verification capacity.
• Encourage public/shared agent workflows so the team learns together.

The uncomfortable conclusion

AI does not remove engineering discipline. It raises the penalty for not having it.

If the organization already has good tests, clear boundaries, strong reviewers, product context, and ownership, AI can accelerate it. If the organization is already sloppy, AI gives it a bigger shovel.