AI Literacy: Knowing When to Prompt and When to Architect

I have a colleague who uses Claude for everything. Type a question, paste some code, get an answer. He is genuinely faster at certain tasks than anyone I know. He is also completely blocked when a problem exceeds what a single prompt can hold, because he has never needed to think beyond that boundary.

I have another colleague who refuses to use AI for anything architectural. He will use it to generate a regex or explain an error message, but the moment a problem involves system design, he sets it aside. His reasoning: "I don't trust it to understand the full context." He is right that AI doesn't hold context the way a human architect does. He is wrong that this means AI is useless for architecture-sized problems.

The distinction I actually care about — and the one that has made the most difference in how I work — is not "simple vs. complex" or "trusted vs. untrusted." It is prompt-sized versus architecture-sized.

What Makes a Problem Prompt-Sized

A prompt-sized problem has these properties: it is self-contained, it does not require understanding the broader system to solve correctly, and the correct solution can be verified by inspection or a simple test.

A screen capture module — a button that captures the application window, crops the taskbar, and saves a PNG — is prompt-sized. The requirements fit in two sentences. The solution uses standard libraries (pyautogui, Pillow) with no interaction with the rest of the system. You can test it by running it and looking at the output file. A zero-shot prompt produces a complete, correct implementation in minutes.

A regular expression for parsing a specific date format is prompt-sized. A function to convert degrees Celsius to Fahrenheit is prompt-sized. A SQL query for a straightforward aggregation is prompt-sized. These are not trivial problems — they can have edge cases and require accuracy — but their solution space is bounded enough that an LLM with no additional context can reliably navigate it.

What Makes a Problem Architecture-Sized

An architecture-sized problem has dependencies that span multiple modules, a state space that exists across multiple files or processes, and correctness criteria that require understanding why the system was designed the way it was.

The 1,600-line async nozzle validation pipeline I described in a previous post is architecture-sized. It cannot be specified in a prompt. The prompt would need to communicate: the async database query pattern, the SQLite schema, the Eel WebSocket callback chain, the specific concurrency constraints of the edge hardware, the business rules for severity classification, and the UI integration points. That context is not transferable via text in a single shot — it requires the AI to read and understand the codebase, reason about dependencies, and generate a plan before writing a line of code.

An LLM that tries to generate the nozzle pipeline from a brief prompt will produce code that looks correct and is subtly wrong — functions that reference variables that don't exist in the actual codebase, database queries that assume a schema slightly different from the real one, async patterns that ignore the specific threading model already in place. The errors won't be obvious. They'll hide until runtime.

The Over-Engineering Trap

Here is the failure mode I see most often: treating prompt-sized problems as architecture-sized.

An engineer needs a function to convert a list of component dictionaries to a CSV string. This is prompt-sized. Instead of prompting for it, they spend 45 minutes designing a ComponentSerializer class with an abstract base, a CSV strategy, a JSON strategy, and a factory method. The resulting code is objectively "better" by some software engineering metrics. It is also completely unnecessary. The one-liner csv.writer approach works, is readable, and requires zero maintenance.

Over-engineering prompt-sized problems is expensive in time and creates architectural complexity that future engineers have to navigate. The best AI-augmented engineers I've worked with have a ruthless filter: if this can be expressed as a clear prompt and verified in 10 minutes, it does not need a design document.

The Under-Engineering Trap

The opposite failure: treating architecture-sized problems as prompt-sized.

This produces the subtle, hard-to-detect errors I described above. The classic symptom is a codebase that grows by adding new files rather than evolving existing ones — because each prompt generates a self-contained solution that doesn't actually integrate with what's already there. After 20 such iterations, you have 20 modules that all slightly overlap, none of which have been designed with the others in mind.

The assembly hub had a period that looked like this. Individual features were added by prompting, each working in isolation, none aware of the shared state model. The result was the 1,200-line monolithic function that needed the full state management refactor described earlier. Every individual prompt had been correct. The architecture they collectively produced was wrong.

The Practical Test

When I encounter a new task, I apply a two-question filter:

1. Can I express the complete requirements in under 200 words, with no reference to files I would need to attach?

If yes: prompt-sized. Write the prompt. If no: architecture-sized. Start by reading the relevant code, mapping dependencies, writing an implementation plan, then use AI as an execution tool for specific subtasks within that plan.

2. Would a correct solution require understanding a decision made outside this immediate function?

If yes: architecture-sized. The solution needs context the prompt can't carry.

These two questions have not led me astray. The screen capture module passes both. The nozzle validation pipeline fails both. The filter holds.

Why This Is an AI Literacy Skill

The engineers who get the most leverage from AI tools in 2026 are not necessarily the ones who write the best prompts. They're the ones who have accurate mental models of where AI is reliable and where it isn't. Accurate problem classification — prompt-sized or architecture-sized — is the meta-skill that determines whether every other AI workflow is trustworthy or fragile.

Get the classification right and AI multiplies your output. Get it wrong and AI produces confident-sounding code that erodes your codebase one invisible mistake at a time.