Claude Code: HOTAS for Knowledge Workers
How AI Coding Tools Give Your Team Situational Awareness
Everyone is worried AI will take their job. That fear misses what is actually happening.
Yesterday I spent four hours on a Zoom call with my operations team. By the end, a non-developer had built a working software tool. A retiring engineer watched his decades of institutional knowledge get codified into a system anyone on the team can now use. And I watched three people realize they had just gained something fighter pilots discovered fifty years ago: the ability to look up.
Eyes Out of the Cockpit
In the 1950s, fighter pilots had a problem. Jets were getting faster. Threat environments were getting more complex. But pilots were spending most of their time looking down at instruments, toggles, and switches scattered across the cockpit. In a dogfight, the pilot who spots the enemy first usually wins. Time spent looking at gauges is time not spent looking for threats.
The solution was HOTAS: Hands-On Throttle And Stick. Engineers moved critical switches and buttons onto the throttle and flight stick itself. Pilots could control radar, weapons, and countermeasures without ever removing their hands from the controls. Without ever looking down.
In the 70’s, Gene Adams and McDonnell Douglas took this to the next level on the F-15 and F/A-18, changing the fundamentals of air superiority. A radically simple concept, it took other countries decades to replicate. Every function a pilot needs in combat sits at their fingertips. The result is not automation. The pilot still flies. The pilot still fights. But now the pilot can keep their eyes outside the cockpit. Situational awareness goes up. Response time goes down. The human becomes more capable, not less. Add the AI tools we built in the 70’s and 80’s, and it looks like Alien Tech if you're the enemy (Sorry UAP fans).
This is what just happened to knowledge workers.
Four Hours in the Cockpit
Our Monday call started the way these calls usually do. Holly, our operations lead, was frustrated. Formidium, our fund administrator, was dragging in a mass of data. Scott, our engineer who is trying to retire, was still doing manual database entries because we never built a user interface for valuation updates. Eva, who handles investor communications, had built a workaround tool in a separate codebase that required downloading and uploading CSV files. Everyone was overloaded. Nobody had time to fix the underlying problems.
I opened Claude Code, connected it to our portal repository, and typed a prompt: “Create a screen for entering valuation changes for securities.”
Seven minutes and forty-four seconds later, we had a working valuation entry screen. Not a mockup. Not a specification. Working code, connected to our database, with a searchable interface.
Scott, who has been programming for decades, said it: “This is fucking amazing.”
Then things got interesting.
The screen needed refinement. It was not showing prior valuation changes. Type a prompt: “Add a feature to show prior valuation changes for the selected security.” A few minutes later, done. The search was clunky. “Add an as-you-type search field for securities.” Done.
Eva’s separate tool needed to be integrated into the main application. We connected Claude to her GitHub repo, told it to examine her code, understand what it does, and rebuild it inside our main app. Ten and a half minutes later, her tool was integrated. No more downloading CSVs. No more manual uploads.
At one point, the system tried to connect to a database port that was already in use. Claude figured out the conflict, suggested an alternative port, and updated the configuration files. When it could not find MariaDB, we told it where the database lived, and it connected.
The whole call felt like we had suddenly gained the ability to look up from our instruments.
The Hayek Problem
Hayek wrote in 1945 that the central economic problem is not resource allocation in the abstract. The problem is that the knowledge needed to allocate resources is dispersed across millions of minds. No central authority can possess it all. The knowledge that matters most is local, tacit, and specific to time and place.
The shipper who knows which ships are half empty. The estate agent who knows about temporary opportunities. The arbitrageur who spots fleeting price differences. These people possess knowledge that cannot be communicated to any planning board fast enough to act on it.
Hayek’s point was about markets. But it applies equally to organizations.
Every organization has Scotts. People who have accumulated years of specific knowledge about how systems actually work. Which database tables hold which data. What the real process is when the documented process fails. Why that one workaround exists. This knowledge is valuable precisely because it is hard to transfer. It lives in one person’s head. When that person retires, it walks out the door.
Every organization also has knowledge that should flow but does not. Eva knows exactly what report she needs. She knows the logic. She knows the business rules. But she cannot express that knowledge in Java. So she builds workarounds in spreadsheets, and the actual system never improves.
The coordination problem inside firms is identical to the coordination problem in markets. Valuable knowledge is dispersed. The people who have it cannot act on it. The people who can act on it do not have it.
Shannon’s Channel
Claude Shannon formalized information theory in 1948. His core insight was that communication has a capacity limit. The channel can only carry so much signal through so much noise. Bandwidth matters.
The bandwidth between a knowledge worker and a software system has historically been terrible. Eva has to describe what she wants to a developer. The developer has to translate that description into code. Eva has to test it. Misunderstandings surface. Iterations happen. Days or weeks pass. By the time the tool exists, the original problem may have evolved.
What happened on our call was a bandwidth expansion. Eva could describe what she wanted in plain language. Claude translated it to code in minutes. She could test it immediately. When something was wrong, she could describe the fix and see it implemented before the next sentence.
The channel between domain knowledge and system capability got orders of magnitude wider.
This is not about replacing developers. It is about reducing noise in the translation between what someone knows and what systems can do.
The Creative Destruction No One Expected
Schumpeter’s creative destruction usually operates at the industry level. New business models displace old ones. Startups eat incumbents. That is still happening.
But something else is happening too. Creative destruction is moving inside organizations. Not destroying jobs. Destroying the friction between knowledge and action.
Every hour Eva used to spend manipulating spreadsheets is an hour she now has to actually solve investor problems. Every manual database entry Scott used to make is now a form anyone can fill out. The institutional knowledge that was locked in one person’s head is now encoded in systems the whole team can use and improve.
This is deflationary in the best sense. Not lower wages. Lower friction. The same team can now do more. Or the same work requires less pain.
From our call: “We are dying. We’re dying. You know this. Eva and Holly have got too much task overload. You’ve got task overload. I want to get through and beat through this process. This actually offers a little hope that we can make these things easier.”
It did.
What To Watch For
I am not going to make predictions. The future is too nonlinear. But I can tell you what to watch.
Watch for organizations where knowledge workers suddenly have system-building capability. The first-order effect is productivity. The second-order effect is that the people closest to problems become the people who can fix systems. Hayek’s knowledge problem inside firms starts to dissolve.
Watch for the gap between large and small organizations to change. A five-person fund can now build internal tools that would have required a development team. Economies of scale in back-office operations may shrink. Nimble operators gain relative advantage.
Watch for the half-life of institutional knowledge to change. Scott’s retirement used to mean lost knowledge. Now it means a transition period where we codify what he knows into systems. The knowledge survives the person.
Watch for new categories of workers. Not developers. Not non-technical. Something in between. People who understand their domain deeply and can now directly instrument that understanding into systems.
What To Do
If you want to understand this shift, there is no substitute for direct experience. Here is how to start.
First, install Claude Code. It runs in your terminal. Connect it to a repository you want to improve. Describe a problem you want solved. Watch what happens. You do not need to know how to code. You need to know what you want.
Second, pick a real problem. Not a toy. Something that actually costs you time. The motivation to iterate through the rough edges is higher when the problem matters.
Third, expect it to be rough. The call took four hours. We hit port conflicts, database connection issues, and permission problems. That is the nature of working in real codebases. The tool does not eliminate all friction. It dramatically reduces it.
Fourth, watch the second-order effects. On our call, the breakthrough was not just the tools we built. It was the realization that Eva can now build her own tools. That Scott’s knowledge can be encoded. That Holly’s process frustrations can become software features. The capability compounds.
If you want to skip the setup friction and see this in action on a problem you actually have, I will spend two to three hours working through it with you. Book time at [calendly link]. If a lot of people sign up, I may charge for this because it filters for people who are serious. But the real goal is to get you to the point where you do not need me. I am going through this teaching process to help our portfolio companies maximize productivity.
The pilots who first used HOTAS had to learn new muscle memory. The controls were in different places. The workflow was different. But once they adapted, they never wanted to go back to looking down.
Neither will you.
Claude Code is available at: https://claude.ai/code