From 1998 to 2002, I was stationed in Japan with the World Famous Golden Dragons, running the night shift for the avionics shop that kept our F/A-18 Hornets flying. Near the end of my tour, a new sailor from New York who we called “B” joined my shift. He was smart and attentive, with a strong work ethic, and he was paired with me on a good number of maintenance actions. He asked a lot of questions along the way and quickly became a very useful technician.
One night I was at my desk processing paperwork when B confidently told a coworker who outranked him by three paygrades and 10 years, “Fish’s second rule of troubleshooting says, ‘If you swap out a part and the gripe changes, you probably put in a bad part.’” I remember thinking two things in quick succession: “When did I write rules of troubleshooting?!” and “Is that even good advice??” It was a remarkable moment. Even when I had no intention of doing so, I was shaping institutional norms with every action I took and every word I uttered. In retrospect, a lot of what I contributed was neither sustainable nor healthy.
A couple of decades later, I decided to run an inventory of our norms at WitFoo as a foundational part of modernising our process with AI tooling. (I’ve written before about what building a cybersecurity platform with AI has been teaching us.) It started with a fairly straightforward prompt to Claude:
Analyze all of our code and create an inventory of all norms we share across developers. These norms will include formatting, security, performance, style and consistency. The norms will align or deviate from industry standards. Without judgement, create that inventory. In doing that deep dive, establish personal norms that are used by each developer that deviate from shared norms. Highlight all conflicts we share with each other and industry best practices and norms. Format the report in a way that the team can review and ratify norms.
With that report in hand, we went line by line and had some heated conversations. We had to pick which norm (from our own contributors or from best practice) we wanted to implement, and then explain the decision. There were dozens of major conflicts to resolve. It was contentious and painful. We even parted ways with a long-tenured team member over it. When we finished the review, we had version 1.0 of “The WitFoo Way” (WFW) of coding. In the year since, that set of documents has grown to dozens of focused files and more than 1,700 concrete norms.
We used that document to build a wide array of tests and processes. Every time we have a process failure, we take it all the way back to The WitFoo Way, look to expand the norms so they cover the edge case, then re-evaluate our tooling against the change.
Recently we had Claude inspect every commit we made over the last year, find the deviations from WFW, and build a training dataset to identify and correct them. We have since fine-tuned models on that dataset to improve our new coding and review sessions. (That is the same legacy-code muscle I described in Teaching Claude the Old Tricks.)
About three months ago, I decided to run some experiments to widen the scope of WFW beyond the codebase. I started by handing Claude every post from this blog over the last 15 years and asking it to build a “Writing Style Guide for Charles/Fish.” It came back with a six-page summary of how I write, and some of it was a bit deflating to read. I took the opportunity to improve a few of the norms in that document, so it reflects how I wish I wrote rather than how I actually write. I still write every post here from beginning to end, but I do run my drafts against that style guide. Claude always makes thoughtful changes that I usually accept (and learn from). It handles the second draft; I still own the first and the final.
Kathy Keanini and her team at Picara Consulting did fantastic work with the WitFoo team to establish our corporate voice and tone. They produced detailed guidance on what we say and don’t say, on what we value and what we discount. I took their work and used it to build the corporate voice (Voice Two, in contrast to my personal Voice One). From there I kept going: sales, fundraising, legal, HR, pricing, distribution, roadmap, accounting, and every other nook of the business I could think of. For each one, I fed in documents and artefacts from across the company and asked Claude to extract the norms and flag the conflicts, the same way we built WFW. The findings landed in markdown files, organised into folders.
The next step was deconflicting those areas of the business. I used this prompt:
Analyze all markdown files in the subdirectories. Identify conflicts between them for me to resolve. Research best practices and provide me with recommendations for improvement. Create a comprehensive index of all information in a file called
fish-in-a-box.mdthat can be shared with others in their research.
Like the WFW process, getting “Fish in a Box” took several rounds of discussion to codify the norms. Once it was done, I had Fish-in-a-box 1.0. In the months since, as we have rolled out new strategies, updated policies and products, and learned lessons, that encyclopedia of norms has been updated and versioned dozens of times.
My entire executive team uses the project. They can request updates to canon (norms we need to add or change) that I review and approve. It lets them build strategies and test ideas across the whole company without needing as many cycles from me. Or, as I like to put it: Fish-in-a-box answers a lot of questions that only I could answer in the past, and it does it without my often horrible attitude. It has paid off for the broader team, not just by helping us move faster but by building rapport across teams, because everyone now works from the same common ground truth. It tells people when they are on the right track, and offers gentle correction when their judgement needs a nudge.
It is not perfect. Several work products built with Fish-in-a-box have come off the rails on their way to me. Those misfires have led to better tooling and better documentation. They have also led to good conversations and debates that often trigger changes to canon and to the norms themselves.
I should also be clear about something: my humans are the ones coming up with the ideas, then testing and honing them with AI. The tooling has removed barriers and friction from their work. It has not lobotomised them or flattened their contributions. If anything, it has freed them up for the part that is irreducibly human. (I’ve made that case at more length in Why I’m Not Losing Sleep Over AI Stealing My Job or My Soul, and before that in The Wizard, The Warrior and The Poet.)
It has also become a great equaliser for catching unintended risk. It is easy to write a blog post like this one with the best of intentions and not notice that I am breaking faith, breaking a contract, or handing ammunition to a competitor. Having a final pass from a “norms checker” has already saved us from more problems than I can count. (This post got that pass too.)
Our work documenting, ratifying, and operationalising norms started inside software development, but it has become a core competency across the team. It has brought us closer together (a thread that runs back through Learning Foo), taken the emotional landmines out of a lot of decisions, and let us do better work at a faster pace.
Wrap Up
In my recent OODA Loop entry, People > Machines (The OODA Loop Strikes Back), I argued that AI can accelerate destruction or it can build resilience. I wanted this piece to be a concrete, anecdotal account of the second path: using AI to slow down, learn more about ourselves, and find the places we needed to improve. (I dug into the destruction half of that in Supersonic Broken Processes.) Standing on this side of a genuinely painful process, the reward has outlasted the turbulence. It turns out a dispassionate AI can offer gentle, honest assessments that, in well-meaning hands, become a path to sustainable operations that can later be accelerated safely.
Which brings me back to B and that night in the avionics shop. I had been writing rules of troubleshooting for years without ever sitting down to write them. The difference now is that we wrote them down, argued about them, and agreed on them on purpose. The norms were always there. We just put the Fish in a box.
