A note on where software engineering value has actually moved
“Typing code is solved” is not a claim that software engineering is finished. It is a claim about where the bottleneck is no longer.
The marginal cost of producing syntactically correct code has collapsed. For large classes of tasks—boilerplate, glue code, refactors, tests, migrations, adapters—the limiting factor is no longer keystrokes. It is judgment.
This is not speculative. It is observable in day-to-day work.
What “solved” actually means
Typing code is solved in the same way that arithmetic is solved by calculators.
You still need to understand mathematics. But no serious practitioner optimizes for manual calculation speed.
Similarly, modern coding assistants can:
- Generate correct implementations from structured intent
- Translate between representations (specs → code → tests → docs)
- Iterate when given feedback
- Repair code faster than humans can type it
The output is imperfect. The leverage is real.
What remains unsolved is everything around the code.
Where the real work moved
As code generation became cheap, three things became expensive:
1. Context
What problem are we actually solving? For whom? Under which assumptions?
Poor context produces fast, wrong code.
2. Constraints
Latency budgets, cost ceilings, failure modes, compliance, invariants, backward compatibility.
Constraints are not suggestions. They are the shape of the system.
3. Control of execution
Agents can execute, but they do not decide:
- what should exist
- what should not exist
- when to stop
- what “good enough” means
That remains a human responsibility.
Agents changed the unit of work
The unit of work is no longer “write this function.”
It is:
- define intent
- bound the solution space
- choose primitives
- specify invariants
- design feedback loops
- supervise execution
Humans decide. Agents execute.
This is not automation replacing engineers. It is amplification exposing weak thinking.
Why this feels uncomfortable
Many engineers built their identity around:
- typing speed
- language mastery
- clever implementations
Those skills still matter—but they no longer dominate outcomes.
The uncomfortable truth is that:
- mediocre judgment + powerful agents = faster failure
- strong judgment + basic agents = durable systems
The skill ceiling moved upward.
A concrete example
Suppose you want a CLI feature: “show files updated since X.”
The code is trivial. The work is not.
The real questions are:
- What does “updated” mean? (mtime? ctime? git state?)
- How does this interact with sorting and filters?
- What is the expected behavior on edge cases?
- How should errors surface?
Once those are answered, generating the code is mechanical.
Typing was never the bottleneck.
What this means for engineers
If you are still optimizing for:
- lines of code
- speed of implementation
- syntax memorization
You are optimizing a solved problem.
If instead you optimize for:
- problem framing
- constraint articulation
- system evolution
- agent orchestration
You are working on the scarce part.
The new craft
The new craft of software engineering looks less like typing and more like:
- specification
- system modeling
- governance
- decision-making under uncertainty
Code is still there. It is just no longer the point.
Closing
Typing code is solved. Thinking clearly is not.
That is good news.
It raises the ceiling of what small teams—and even individuals—can build, while sharply penalizing sloppy thinking.
Software did not get easier. It got more honest.