일관된 AI 정책을 세워야 하는 이유

Have a Coherent AI Policy 2026-05-14 leadership AI My very first job out of college was at a law firm with hundreds of paralegals. They were running an in-house workflow system to manage foreclosure and bankruptcy cases. I lucked into a boom industry when the housing bubble burst. At the peak, we were doing over 100K of each a year. The work was broken down into finely sliced tasks. Paralegals worked out of a queue of tasks, mostly of the same flavor. It was an assembly line for court filings; Taylorism brought to legal work. Before I started, a new executive had been brought in. One of her jobs was to streamline process. Her plan was simple: she was going to stand behind employees with a stopwatch and time how long it took them to complete tasks. KPIs would be set up based on those measurements. This went as well as you would expect. People don’t perform tasks the same way they normally do when an executive is standing behind them with a stopwatch. She quickly learned how worthless this was. All that is a segue to the latest garbage KPI in software engineering, tokenmaxxing, and the AI policy I wrote for my team. WTF is Tokenmaxxing? Tokenmaxxing is the latest fad to come out of management who still, in the Year of our Lord 2026, do not understand that every metric will be gamed. That executive with the stopwatch didn’t understand 20+ years ago and there are clearly leaders today who have not received the memo. The idea is that the company will encourage the adoption of AI tools by creating a leaderboard of who is using the most tokens. Much like any other naive metric , engineers immediately game it . Just create a loop that wastes tokens and shoot to the top of the leaderboard. Or waste just enough to show that you’re “using” AI, but not enough to explain your usage. This is what passes for leadership apparently. Creating easily gamed metrics for your team that are quickly divorced from actually helping people. Because at the end of the day, that’s what we’re here for, right? You’re here to help people, right? That’s what I’m here for. I’m here to help our customers accomplish their goals. I’m not here to use a certain number of tokens. Tokenmaxxing is a vanity metric masquerading as leadership. Why an AI Policy? I manage a team that is very skeptical of AI, and for good reason. I don’t need to enumerate the ethical concerns here. There have been enough think pieces about that. I also don’t need to enumerate the productivity concerns. Depending on which way the wind blows and the position of Jupiter in the zodiac, your mileage will vary on how useful these tools are for you. You can find credible examples of anywhere from 0.1x -> 10x productivity depending on how you hold it. But what I am confident of is that the current generation of LLMs is causing the biggest upheaval in software engineering in my almost twenty year career. And as the manager of a team, it’s part of my job to have some position on that. So, after much discussion with the team, I quickly put together a guide describing our AI philosophy. Since putting this together, I’ve been surprised by how many developers I’ve spoken with who have no such document at work. The mandate is simply to AI as hard as possible and hope it all works. TL;DR No AI mandate You must understand what your AI generated code does You must be able to do your job if your AI tooling disappears Care about your teammates and our customers Let’s go over these in more detail. When To Use AI Tools There is no mandate to use AI tools. You will not be reviewed based on how much you are using these tools. That being said, these tools are the largest upheaval our industry has seen in decades. Even if you are not using them on a daily basis, you are well served to be aware of how they are evolving. This space is moving so fast that your experience from six months ago is likely no longer relevant. A side effect of this large turnover in skills is that any expertise you didn’t gain six months ago is probably irrelevant today. Senior+ engineers are encouraged to use these tools in whatever way works best for them. That could be as an integral part of your daily workflow or just an occasional tool for proof of concepts for non-production code. There is an inherent contradiction in AI boosters. If you don’t get on the AI train now, you’re going to be left behind. AI is moving so fast that everything you know today will be worthless in six months. It cannot be true that I have to be an AI maximalist at this very moment and also that everything I know today will be worthless in six months. Why can’t I just wait until six months from now and use the better models and techniques? I won’t have to unlearn techniques that only exist to work around the immaturity of current tooling then. (I’m looking at you, Ralph Loops.) We hire smart people and we trust them to do the job. I don’t care what OS they use. I don’t care what editor they use. I don’t care what LSP they use. And I don’t care what AI tooling they use. I don’t care if they’re dipping their toe in for a prototype or if they’re running a full-blown Gas Town. I care that they’re delivering for our customers. But as the policy says, the upheaval is real. You do have a professional duty to try these tools on occasion. The tooling I tried in June 2025 is much worse than the tooling I came back to in January 2026. I expect the tooling I’m using in June 2026 to be even better. It’s Still Your Code Any code generated by AI tools is your code. It does not matter how much of your PR that AI wrote for you, you are expected to understand what the code does. It is expected that the code fits into our existing patterns. Our AGENTS.md file should help with this, but does not guarantee anything. You are responsible for making sure the code you submit for review is up to snuff. Do not put undue burden on reviewers. We all submit questionable PRs at times. This could be because of time constraints around a incident level production bug or because we’re in new design space. It is still the responsibility of the PR submitter to call this out. Using AI tools is not an excuse to call out all of your PRs as questionable. Humans ultimately make our architecture decisions, not AI. When there is a choice between accepting code that makes it easier for machines vs. code that is easier for humans, we prefer humans. If AI tooling is constantly spitting out code that does not conform to our coding standards, the AI tooling is what needs to change, possibly by improving our AGENTS.md file. AI maximalists will read this section and scoff. They’re already vibe coding everything and have little to no idea what the generated code looks like. If we were a greenfield startup, I might take this approach as well. We are not a greenfield startup. We have a ten year old codebase full of contradicting styles brought in by different teams. Sometimes it’s full-blown code archaeology to figure out why something is the way it is. The AI maximalist bet is that models will improve at a rate that exceeds the tech debt they are accruing. This is similar to the bet that startups have made for years. It doesn’t matter how bad the initial code is. The focus is on finding product-market fit and worrying about sustainability later. We have product-market fit though. We care about being able to work on this codebase for the next decade. Our customers care that our current features keep working. If you are an AI maximalist, where is the bottleneck shifting to? Is it code review? Is it knowing what your customers even want? Is it the rate of change your customers can absorb? Being able to theoretically write 10x more code does not mean that you are providing 10x more value to your customers. If Claude goes down tomorrow, can you still do your job? Can you understand the code in front of you? If OpenAI goes bankrupt next week, will you gaze upon the horrors in your codebase and weep? I spent a decade as a consultant. I’ve parach