Know-What vs Know-How: The AI Task Taxonomy That Saves You From Disasters
Tasks that require describing WHAT you want behave differently from tasks that require describing HOW you want it done. Getting the category wrong is how you end up with 100k lines of confused code in a day.
A useful way to categorize what you are asking a model to do is to distinguish between tasks that require knowing facts versus tasks that require knowing a process or skill. This is a moving target and will continue to drift as models get better, but here's the important distinction.
"Say-what" tasks are tasks that only require you to clearly describe what you want as an output, and give any necessary data for that to happen. Examples: factual recall, text summarization, language translation, retrieval from provided material. Creative media generation within the limits of the description.
"Say-how" tasks are tasks that require you to clearly describe how you want something to be done, and what pattern(s) you would like that task to follow. Examples: writing code, drafting legal arguments, designing organizational systems, debugging.
These categories are debatable — but "saying what to a say-how task" repeatedly is a recipe for disaster later on. One example: Say you have an existing API. You'd like to add a new set of endpoints to this API, using a coding AI system. Ideally, there are some shared methods that the new endpoint could use, a pattern that you've used for the existing endpoints, and maybe a change in the way something is defined that you will mirror in the calling code. If you simply tell a modern AI code system (Codex, Claude Code, etc), there is a solid chance that the system will find all of these needs, intuit them, and act as you wish it would.
Or, there's also a reasonable chance that one of these will happen (all from the recent trenches, working with best-in-class systems as of mid-2026):
1. The system creates what should be the shared resource again in a completely new place, making a near-duplicate but with slightly different syntax, creating the worst possible confusion for future coworkers.
2. The system adds the new facilities, but in an entirely unexpected place, "piggybacking" on the first eligible subsystem it found, making it very hard to disentangle later.
3. The system "changes" the specific needed syntax, but keeps the entirety of the old version as a "safety fallback", effectively locking future workers into supporting the old/deprecated system and the new system, with no obvious delineation between the two and no easy way to remove the old one.
4. The system "jumps the gun" and not only changes the thing you asked for, but also all of the calling code in whatever way seems most likely to make the code "still run", effectively adding random alterations to part of your code, potentially without you noticing.
The REAL danger: all the changes above seem to work when they happen. If you aren't very careful (either in the initial asking, or the code review, or ideally both), you will think everything is fine, check that code in and put it into production. It will probably even operate as written. Then later on, you'll be fighting a tsunami of bugs, confusion, and tech debt, as you try to figure out where everything is and why the team somehow committed 100k lines of code in a day.
On that note, prepare for huge services and known mega-platforms having more and more "unexplained downtime" over the next calendar year, as every team who doesn't figure out the above battles these same issues.