Institutionalizing Judgment - The Method
Before Tom was sold on AI, he thoroughly experimented. He wanted to know how good AI actually was at building a real analytical application, inside a real data platform, wired to real data. So he decided to do something he knew well: he made the AI rebuild an app he'd already built himself, years earlier, in a system he knew cold. Not because the output wasn't already available, but because he needed to know how the AI generated result stacked up against something he already knew worked. He needed to know if the hype was true, and it helps to know the right answer when testing.
The output was good. Clean structure, sensible logic, a UI that would sail through a casual review. And yet, Tom could still drive a truck through the holes in it. Where did this number actually come from? Why resolve this metric one way instead of another? Why decide the UI should look like this, and against what standard? None of that shows up in a walkthrough, but all of it was real. He and the AI worked through it piece by piece, checking every claim in the app against what he actually knew was true underneath… until the AI told the truth.
Then came the insight that mattered more than the app itself: Tom could only find the holes because he'd built the data himself. Nobody else on his team could have run the same depth of review. Not because they weren't good, but because the truth the app needed to be checked against didn't live in any system. It lived in Tom's head.
The Hidden Trap of AI-Assisted Software Development
The obvious first fix was a watchdog: build something that grades every app after the fact, checks it against the house rules; right source, right way to resolve this label, matches the standard. It worked. It also caught everything downstream after the app was already built, which meant building it, grading it, then rebuilding it. That's not only putting more barriers between insight and execution, but it is putting the fence at the bottom of the cliff; at the wrong place to stop anyone that falls.
Encoding Rules at the Source
The better fix flips the question: why grade the output at all, when you can hand the system the rule before anything gets built? Encode the house rules at the start. Skip the QC loop entirely, because the mistake it exists to catch never gets the chance to happen.
The Orchestra Metaphor: Balancing Guardrails with Developer Freedom
That's closer to how a composer runs an orchestra.
They don't play every instrument, and a good score doesn't tell a violinist how to move their bow. It sets what has to be true: this pitch, this rhythm, this moment, and leaves the creativity entirely to the player. That's how a composer turns forty independent musicians into a musical masterwork.
Here's the thing, and it runs against the usual instinct, governance that restricts developers is bad design. If the only way to keep people aligned is to slow them down or take away their judgment, you built the wrong system. Governance that institutionalizes judgment, that hands every developer the knowledge that used to live in one person's head, doesn't restrict anyone. It frees them to move at full speed inside a shape that already holds together; the same rule, decided once, instead of re-litigated by every developer on every app. A real score, and the resulting structure, is what separates an orchestra from a jam session.
Scaling Expertise Without Slowing Down Innovation
One thing worth saying straight: this was never a story about AI being unreliable. The output was good : good enough that a team without Tom's specific history would have shipped it and never known the difference. That's the real risk. Not bad AI. Verification that only works if the right person happens to be in the room. Institutionalizing judgment is what makes that verification possible for everyone else, every time, whether or not the one person who'd know is around to catch it.
Navigate the Full Score Data Solutions Creativity Through Constraint Series:
Part 3: Institutionalizing Judgment (Current)
👉 Stay tuned for Part 4
