Skip to content
Meta-Rational Software Development with Engineering Skills for AI

Knowing what not to build: the 10x engineer as context

Aspects: purposiveness · breadth of considerations · effective action (meta-systematic)

Signals you are in this situation

Section titled “Signals you are in this situation”
  • The ticket arrives as a feature list with priorities already assigned.
  • Effort goes into parts nobody will notice.
  • The phrase while we are at it keeps appearing in planning.
  • Nobody can name the cheap version.
  • Technical interest, not value, sets the order of work.

The situation

Section titled “The situation”

Ben Kuhn describes a classmate who really could write code ten times faster than anyone around him. He pulled the same all-nighters as everyone else, because he spent the time building impressive development tools in his favourite language instead of solving the assignment. Kuhn also describes a fast, motivated colleague whose output fell by a factor of ten for two months after being put on an ill-defined project with a long feedback loop and no connection to the rest of the company’s work. Same people, same skills, different context. The variation in usefulness was real, but it lived in the pairing of engineer and situation, not in the engineer.

Salvatore Sanfilippo reaches the same place from the other side. Of the nine qualities he lists as making the difference in productivity, only the first is raw ability to get sub-tasks done. The others include recognising which parts of a design are not easy wins, sacrificing a non-fundamental goal to make the fundamental one simple, resisting perfectionism, and choosing at every step the features with the most effect for the least effort. He gives the example of a message broker whose whole design improved once he gave up strict ordering of messages. Justin Etheredge, from twenty years of small-team work, puts it more bluntly: the best code is no code, software is a means to an end, and most of the forces in a project push toward building too much.

The meta-rational perspective

Section titled “The meta-rational perspective”

Kuhn’s post contains a list of what producing useful software actually requires: identify the right problem, build enough context to attempt it, choose the best approach, convince the people who matter, build it, get it into production, learn what was wrong, improve it, explain it, and maintain it as needs change. Building is one step in ten. Chapman’s reading of the list is that the other nine are meta-rational tasks, and that a highly effective engineer either does all of them or works in a context where aligned collaborators do some of them. Effectiveness is a property of an engineer-and-context pair.

That reframes the old argument. Nobody writes the same code ten times faster. Some people write different code, because they have figured out what is worth writing, and they have the standing in their organisation to act on that judgment. The capability is not technical. It depends on caring about the organisation’s purposes rather than about what would be technically interesting, and it depends on a position from which deciding what to build is permitted. Sanfilippo notes that when a task arrives rigidly specified, with tools and implementation mandated, the leverage disappears: the engineer can still make local design choices but cannot remove a part of the specification that was never worth the effort.

So the question this page is about is not how to code faster. It is how to arrange the work so that what is not worth building gets identified before it is built, and so that the person who can see this is allowed to say so. Kuhn’s engineers who were consistently effective shared two habits: they were conscious of the context factors, and they steered toward situations where those factors helped. Etheredge’s warning about the 0.1x programmer is the same point inverted. The biggest losses are not slow typing but time spent on things that turn out not to matter, and nobody noticed at the time.

Failure path

Section titled “Failure path”
1 Problem handed down a ticket, already framed as features 2 Accept the framing every feature is assumed to matter 3 Weigh the parts skipped: no ranking of what counts 4 Cut what isn't worth it skipped 5 Build all of it fast, well-tested, impressive tooling 6 Ship the whole system 7 Measure the effect most of it changed nothing for anyone “we need more capacity”: another ticket, same framing
How the situation goes wrong when handled purely rationallyHow to read

The work arrives already framed as a list of features, and the framing is accepted because questioning it is not the engineer’s job. Nobody ranks the parts against a purpose or cuts the ones that are not worth it. The whole thing is built, fast and well. When it ships, most of it changes nothing for anyone, and the lesson drawn is that the team needs more capacity, which produces another ticket in the same shape.

Corrected path

Section titled “Corrected path”
1 Problem handed down a ticket, already framed as features 2 Question the framing grilling: Interviews you round by round until nothing about a plan is left silently assumed.grilling ask-matt: A router that asks which skill or flow fits your situation.ask-matt 3 Weigh the parts name the destination; rank against it wayfinder: Charts work too big for one session as a map of decision tickets with a named destination.wayfinder 4 Cut what isn't worth it no-gos in the spec; wontfix on the rest to-spec: Synthesises the conversation into a spec and publishes it to the tracker.to-spec triage: Moves issues through triage states and writes agent-ready briefs.triage 5 Build the small thing cheap answer first prototype: Builds throwaway code that answers one design question.prototype implement: Implements a spec or tickets test-first at agreed seams.implement 6 Ship the smaller system 7 Measure the effect code-review: Reviews a diff for standards and spec conformance in parallel sub-agents.code-review what mattered in use re-weights the next cut cheap answer says no: re-rank, don't finish
The same path with skills inserted at the break pointsHow to read

The shape is the same: work still arrives, code still ships. What changes is that the framing is questioned before it is accepted, the parts are weighed against a named destination, and the ones that fail that test are cut in writing rather than quietly deferred. A cheap prototype answers the remaining doubts before anything is finished. Two loops carry the judgment forward: a prototype that says no sends the work back to be re-ranked, and what turned out to matter in use re-weights the next round of cuts.

Skills for this situation

Section titled “Skills for this situation”
Skill When to invoke it here What it changes Example
grilling (via /grill-me) When a ticket arrives with its features already decided. Interrogates the framing until it is clear which parts serve the purpose and which are there because someone once imagined them. The decision tree makes the non-essential branches visible. /grill-me this ticket: which of these five features actually move the metric we care about?
ask-matt Before picking a procedure at all. Asks which flow fits the situation, including the option that none does and the right move is a conversation rather than a build. Choosing the method is itself the meta-rational step. /ask-matt we have a feature list and doubts about half of it; where do we start?
wayfinder For work too large to hold in one head. Its first act is naming a destination, and the destination governs scope. Anything that does not lead there is easier to drop once the map exists. /wayfinder the destination is one reconciliation view operations trusts, not a reporting suite
to-spec After the grilling settles what stays. The spec records what is out of bounds as well as what is in. Written no-gos survive the next planning meeting; verbal ones do not. /to-spec and list the three features we decided not to build as explicit no-gos
triage For the requests that keep arriving. Moves them through a small state machine, and one of the states is wontfix. Declining in the tracker, with a reason, is cheaper than building and cheaper than ignoring. /triage the open requests; mark anything outside the destination as wontfix with a note
prototype When a feature might be worth it and might not. Throwaway code answers the question in hours. A prototype that says no is the cheapest possible way to not build something. /prototype whether best-effort ordering is enough for the queue consumer
implement For what survived the cuts. Unchanged as a discipline. The difference is that it is now applied to a smaller system, which Etheredge argues you will iterate into a better one than you could have designed up front. /implement issue #22
code-review At the end, with one added question. Beyond standards and spec: what in this change turned out to matter, and what did not? The answer feeds the next round of ranking. /code-review against main, then: which of these changes would we skip if we did it again?

Sources

Section titled “Sources”