Why Your Best Engineer Can't Write a Construct

Your best engineer can review a pull request in four minutes and catch a race condition that three other reviewers missed. Ask her to write a construct that teaches an AI to review code the way she does, and she will stare at a blank document for an hour and produce something generic and useless.

This is not a failing of the engineer. It is a fundamental property of expertise.

The Curse of Competence

Psychologists call it the “curse of knowledge” — the cognitive bias where experts can no longer imagine what it is like to not know something. But with constructs, the problem is deeper than that. It is not that experts forget what beginners don't know. It is that experts cannot access their own decision-making process.

When your best engineer looks at a diff, she does not consciously think: “First I check the function signatures. Then I trace the data flow. Then I look for boundary conditions.” She looks at the diff and sees the race condition. The pattern recognition is immediate, pre-verbal, and opaque to introspection.

Ask her how she found it and she will say something like: “It just looked wrong.” She is not being evasive. She genuinely does not have conscious access to the steps her brain took. The expertise has been compiled down to intuition. And intuition is exactly what you cannot put in a construct.

Tacit Knowledge

The philosopher Michael Polanyi called this “tacit knowledge” — the things we know but cannot tell. His famous example: you can recognize a face in a crowd of thousands, but you cannot describe how you do it. The knowledge is real. The articulation is impossible.

Software engineering is saturated with tacit knowledge. The instinct for when a function is doing too much. The feeling that a database schema will cause problems at scale. The sense that a test is testing the wrong thing. These are not rules. They are patterns that took thousands of hours of practice to internalize.

A construct requires explicit knowledge. Step one, step two, step three. If this, then that. Check for X before Y. A construct is a recipe. Tacit knowledge is taste. The gap between the two is the gap between knowing how to cook and knowing how to write a cookbook.

The Articulation Problem

This is why the best construct writers are often not the best practitioners. They are the best observers of practitioners.

The skill of writing a construct is not the skill of doing the work. It is the skill of watching someone do the work and decomposing what you see into a sequence of decisions that a machine can follow. It requires:

Patience to observe. Sit with the expert while they work. Do not ask “how do you do this?” — they cannot answer that question accurately. Instead, watch. Note when they pause. Note when they scroll back up. Note when they switch tabs. The pauses are where the decisions happen.

Skill to interrogate. When they pause, ask: “What made you stop there?” Not “what are you thinking?” — that invites rationalization. Ask about the specific stimulus that triggered the pause. “Was it the variable name? The nesting depth? The lack of error handling?” Give them multiple choice. Experts are better at recognizing their reasoning than generating it from scratch.

Discipline to structure. Take the raw observations and organize them into a decision tree. Not a flat list of rules, but a hierarchy: first check this, then check that, and if both are fine, check the other thing. The ordering matters. Experts check the most likely problems first. That implicit prioritization is part of the expertise and must be captured.

The Interview Method

The best constructs are born from interviews, not from writing sessions. The construct author interviews the expert the way a journalist interviews a source — with genuine curiosity, specific questions, and a willingness to push past the first answer.

The first answer is almost always a platitude. “I look for bugs.” Good. What kind? “Well, anything that could break.” What breaks most often? “Null pointer exceptions.” Where? “At the boundary between our code and the external API.” Why there? “Because the API returns different shapes depending on the error type and nobody reads the docs.”

That last sentence is a construct rule. Not “check for null pointers” — every linter does that. But “when code integrates with an external API, verify that every error response shape is handled, because API error formats are inconsistent and underdocumented.” That is the kind of specific, experience-derived rule that makes a construct valuable.

Why This Matters for the Ecosystem

If the best practitioners cannot write constructs and the best construct writers are not necessarily the best practitioners, then construct creation is a collaborative act. It takes two kinds of expertise: domain knowledge and articulation skill.

This has implications for how the construct economy develops. The highest-value constructs will not come from solo authors. They will come from pairs: a domain expert and a construct writer working together. The surgeon and the technical writer. The veteran teacher and the prompt architect. The trader and the decision framework designer.

The construct is the artifact of that collaboration — a document that neither person could have written alone. The expert provides the judgment. The writer provides the structure. The construct captures something that lived only in one person's head and makes it available to every agent in the world.

That is a new kind of authorship. And it is one of the reasons the construct economy may be larger than anyone expects.

Related: The Last Mile of Expertise explores the broader problem of tacit knowledge transfer. The Soul Stack covers how the constructs these pairs produce compose together.