Standards Over Speed: Grade Is Not Quality
If you have read any of my other posts, you probably already know that I am particular about words. I will write a whole post about how can’t and shouldn’t are not the same word. Words have meanings. Some of them are not interchangeable, even when people use them as if they are, and the conflation does real damage to the conversations the words are supposed to support.
A lot of this comes from the Marines. The military, by necessity, builds vocabulary around very small distinctions. Attack, destroy, disrupt, neutralize are not synonyms. They describe different effects, with different criteria for success, executed against different kinds of targets. A commander who tells a unit to neutralize a target is not telling them to destroy it, and a unit that destroys a target when they were told to neutralize it has not accomplished the mission. They have done something else.
I will give one example from my own career, because it matters to me and I think it illustrates the point. I never attacked Marine Corps networks during my time on the red team. Attack is an offensive word. It implies hostile intent toward the target. I was not hostile to the networks I was working on. I was defensive. I was Marine. The networks were Marine networks. My job was to find their weaknesses so they could be made stronger. The right words for what I was doing were assess, aggress, and test. Each of those carries a different shading than attack, and the shadings matter. Using attack would have misrepresented both my intent and my relationship to the target. I cared about the precision because the precision was part of the work.
This post is about another pair of words that get used interchangeably in a way I find frustrating. The pair is grade and quality. I am a Project Management Professional. The PMP coursework makes a clean distinction between the two, and the distinction has stayed with me ever since I picked up the certification. People use the two words as synonyms in everyday conversation, which is fine in everyday conversation. In a professional context, the conflation costs real money and produces real disappointment. The two words mean different things, and the difference matters more in the age of AI-assisted building than it has in any previous era of software development.
I am going to spend this post explaining the difference. By the end of it, I want you to know the difference too.
The Definitions
In the project management framework, grade and quality refer to two different properties of a deliverable.
Grade is the standard the product is built against. The specification. The tier of capability the product is being targeted at. A high-grade product has been designed to do more, last longer, handle more demanding conditions, or operate at a higher level of capability than a low-grade product. Grade is a choice you make at the start of the project, when you decide what the product is supposed to be.
Quality is how closely the finished product matches the standard it was built against. A high-quality product meets its specification. A low-quality product does not. Quality is a measure of execution against the chosen grade.
These are independent. A product can be high-grade and low-quality. It can be low-grade and high-quality. It can be either combination of the two, in any direction.
The Phone Example
The cleanest illustration I have found for this distinction is two phones.
The first phone is designed with a 24-hour battery specification. The team building it intends for it to last a full day on a single charge under typical use. When the phone ships, the battery lasts 18 hours. It does not meet its specification. The phone is high-grade, because the target was ambitious, but it is low-quality, because the execution fell short of the target. The buyer who picked this phone for its battery life is going to be disappointed every day.
The second phone is designed with a 12-hour battery specification. The team building it intends for it to last half a day, and that is what they tell customers to expect. When the phone ships, the battery lasts 12 hours. It meets its specification exactly. This phone is low-grade, because the target was modest, but it is high-quality, because the execution matched the target. The buyer who picked this phone got exactly what they were promised.
Which phone is better? It depends on what the buyer needed. If the buyer needed all-day battery, the first phone is closer to that goal, even though it fell short. If the buyer needed reliable, predictable battery life and was willing to charge at lunch, the second phone is the better product.
The point of the example is not that one phone is universally better than the other. The point is that grade and quality are different axes, and you need both words to describe a product accurately. Saying “this phone is bad quality” when you actually mean “this phone is a lower grade than I wanted” is a common conflation, and it produces conversations that go nowhere because the two sides are arguing about different properties.
Why This Matters in the AI Era
The reason this distinction has become more important in the last few years, rather than less, is that AI tools have changed who can build software.
A few years ago, building software required programming knowledge. Not necessarily expert knowledge, but enough to write code, understand what the code did, and debug what went wrong. That barrier filtered out a lot of people who had product ideas but lacked the technical skill to execute them. Now the barrier is much lower. A marketer with a clear vision for a tool can describe what they want to an AI assistant and get working software in an afternoon. A subject matter expert who has been complaining for years that no one builds the tool they need can finally build it themselves.
That shift is, on balance, a good thing. More people building means more problems getting solved. The democratization of software construction is something I am genuinely in favor of, and I am not going to write a post that argues against it.
What I will write is a post that argues people are conflating grade and quality in this new landscape, and the conflation is causing real damage.
The marketer who builds a program with AI assistance can produce something that is, in a meaningful sense, high quality. The program does what they asked it to do. It matches the specification they had in their head. From the marketer’s perspective, it is working software, and the AI delivered exactly what was requested.
But the grade of the program is set by the marketer, and the marketer does not know what a high-grade version of the program looks like. They do not know what security considerations the program should have. They do not know what edge cases the program should handle. They do not know what the failure modes are, what the operational requirements are, or what the maintainability profile looks like a year down the line. The marketer set the grade based on what they understood the program needed to do, which is the only grade they were equipped to set.
When a developer with real experience builds the same program, the grade is different. The developer knows what a robust version of the program looks like because they have seen what happens when programs are not robust. They know what attacks to defend against because they have seen those attacks succeed. They know what conditions the program will eventually have to handle because they have watched programs break under those conditions. The grade they set is higher, because the standard they hold the work against is shaped by experience the marketer does not have.
Both the marketer and the developer can produce high-quality work. The difference is the ceiling each of them can reach, and the ceiling is set by the grade.
Domain Vocabulary Is the Grade-Setter
Pete and I have been talking about this kind of thing a lot, and one of his posts says something I want to extend into the frame of this one.
In [The Framework Learns], Pete introduced a concept he calls Vocabulary-First Onboarding. The observation that produced it is one of the most useful things I have read on AI-assisted work this year. His version of the insight is this. The speed at which a person can work productively with an AI in a given domain is bounded by the vocabulary they have in that domain. Not the conceptual depth. The vocabulary. The names of things.
Pete’s example is the difference between his security work and his CSS work. In security, he has decades of vocabulary. He knows what OWASP A02 means without thinking about it. He can describe what he wants to a model in the language the model was trained on, and the model meets him with the precision he needs. In CSS, he had to learn vocabulary in real time, and the work slowed to a crawl while he figured out what to call the things he was trying to do. Same person. Same AI. Different speed. The variable was the vocabulary.
I want to extend Pete’s observation into the grade-versus-quality frame, because I think the two ideas reinforce each other.
The grade of an AI-assisted output is set by the vocabulary the person brings to the conversation. When the marketer prompts an AI to build a program, the vocabulary they bring is marketing vocabulary. Conversion. Engagement. User journey. The AI builds an output that maps to that vocabulary. Anything outside of that vocabulary, like input validation, rate limiting, session management, or error handling, has to be supplied by the AI’s defaults, because the marketer does not have the words to ask for it. The grade is set by the words the marketer knows.
When a developer prompts the same AI to build the same program, the vocabulary they bring is developer vocabulary. They ask about authentication flows, parameter sanitization, idempotency, retry behavior, observability. The AI builds an output that maps to that vocabulary. The grade is set by the words the developer knows.
The AI is responsive to vocabulary because vocabulary is, as Pete writes, the API between human expertise and AI capability. The expertise lives in the words. The words tell the AI which standards to apply, which patterns to invoke, which considerations to surface. If the words are not in the prompt, the considerations do not get surfaced, because the AI has no other signal that they should be. The vocabulary the user brings is the grade the AI builds against.
This is why the conflation of grade and quality is so dangerous in AI-assisted work. The non-expert producing a program with AI is operating against a low-grade specification, set implicitly by the limited vocabulary they brought to the prompt. The AI builds high-quality output against that low-grade specification. The non-expert evaluates the output against the same limited vocabulary, and the evaluation confirms the work is done. The grade was too low the whole time, but nothing in the loop ever flagged it, because the grade-setting function lives in vocabulary the non-expert does not have.
The Two Failure Modes
There are two failure modes I see most often when grade and quality get conflated in AI-assisted work.
The first failure mode is the marketer’s program shipped without anyone catching the missing grade. The marketer is happy because they got what they asked for. The organization is happy because the program is in production and is producing value. Six months later, an issue surfaces. A data leak. A logic flaw. A security vulnerability that lets someone do something the marketer did not anticipate because the marketer did not know to anticipate it. The program is high-quality against the marketer’s specification and low-grade against the specification any experienced developer would have written. The discovery of that gap is usually the moment when the costs of the conflation finally land.
The second failure mode is more subtle and more common. Organizations look at the speed and apparent productivity of AI-assisted development and conclude that they need fewer experienced developers. The math seems obvious. If a marketer can produce a working program in an afternoon, why should the company keep paying senior developers to spend a week on it? The answer, of course, is that the marketer is producing a low-grade program quickly, and the senior developer is producing a high-grade program over a longer time horizon, and the two outputs are not interchangeable. But that distinction is invisible at the surface level. The marketer’s program looks like working software. The senior developer’s program looks like working software. Only the failure modes reveal the difference, and the failure modes show up later, when the choice to reduce the experienced workforce has already been made.
I want to be careful here. I am not arguing that AI-assisted development is a problem. I am arguing that AI-assisted development without domain expertise is a problem, and the two are easily confused. The same AI tools that let a marketer ship a low-grade program in an afternoon let a senior developer ship a high-grade program in a fraction of the time it would have taken pre-AI. The tool is the same. The result is different. The variable is the expertise of the person using the tool.
What Good Looks Like
The right model for AI in software construction, in my view, is empowerment of experts rather than replacement of them.
A senior developer using AI to build a program produces better work than they could have produced unassisted. The AI handles the boilerplate, the routine, the parts of the work that do not require deep judgment. The developer focuses on the parts that do. The grade is set by the developer’s expertise. The quality is improved by the AI’s speed and the iteration cycles the speed enables. The combination produces high-grade, high-quality work, faster than either the developer or the AI could produce alone.
A non-expert using AI to build a program produces work that looks the same on the surface but is fundamentally different underneath. The AI handles the boilerplate, the routine, and also, by default, sets the grade based on patterns from its training data rather than on the requirements of the specific problem. The non-expert evaluates the output against their own understanding, which is necessarily limited by their lack of domain knowledge. The work ships. The work appears to be done. The failure modes that an expert would have anticipated are not addressed, because the expert is not in the loop.
The right organizational response to this difference is to keep experts in the loop, not to remove them. AI-assisted development should make experts more productive, not redundant. The expertise is the part that sets the grade. The AI is the part that improves the quality of execution against the grade. Take away the expert and you take away the grade-setting function, and you are left with high-quality execution against a specification that is too low for the problem you actually need to solve.
Faster, Not Replaced
If you know what you are doing, AI will make you faster. The same intuitions you developed over years of working in your domain still apply. The AI accelerates the execution, but the judgment about what to build, how to build it, and what to be careful about is still yours. You ship more work in less time, and the work meets the standard you have learned to hold things against.
If you do not know what you are doing, AI will produce something that looks like it could work. You will not be able to tell the difference between a program that is genuinely robust and a program that has the appearance of robustness but will fall over the first time it encounters a condition you did not anticipate. The output will pass your evaluation because your evaluation is operating against the same limited understanding that produced the prompt in the first place.
If you do not know what you are doing and you throw AI at it anyway, you are going to break things at speed. The acceleration applies in both directions. AI makes good engineers faster. It also makes inexperienced builders fail faster, more confidently, and at greater scale than they would have without the tools. The output is shipped before the problems are caught, because the speed of construction outpaces the speed of evaluation when the evaluator does not know what to look for.
The goal is not to gatekeep the work to credentialed experts. The goal is to recognize that grade-setting is itself a skill, that the skill is built through experience in the domain, and that AI tools do not provide that experience for free. They amplify whatever the user brings to them. If the user brings expertise, the amplification is positive. If the user brings only the desire to build something, the amplification is whatever happens when the AI’s defaults are accepted as the specification.
The Working Principle
The principle I want to leave you with is the one I keep coming back to in my own work.
When you are building something, ask yourself which axis you are optimizing. Are you trying to ship the highest-quality version of a low-grade specification, because that is what you can articulate? Or are you trying to ship a high-grade specification that meets the actual requirements of the problem you are solving?
If the answer is the first, find someone with the domain expertise to set the grade higher. Bring them into the loop early. Let their experience shape what the program needs to be, not just what you happen to want it to be. Then use the AI to build the high-grade version efficiently.
If the answer is the second, you are probably already in good shape. You know what you are building, you know what good looks like, and the AI is going to make you faster at producing it.
Grade is the standard you are building against. Quality is how well you hit the standard. The first is set by what you know. The second is improved by how you work. AI changes the second axis dramatically. It does not change the first.
Know what you are building. Then use the tools to build it well.