Decomposing problems for AI
Break vague, large problems into concrete sub-tasks that AI can handle reliably — the foundational skill for using AI on real projects.
- Explain why AI performs better on narrow, well-scoped tasks than on broad ones
- Apply a decomposition strategy to break a large problem into concrete sub-tasks
- Identify natural seams in a problem where decomposition makes sense
- Recognise when a task is too vague to hand to AI as-is
"Build me a web app that tracks expenses." Said to a developer, that sentence starts a three-hour planning conversation. Said to an AI, it produces a wall of boilerplate code that may or may not resemble what you actually need, with no guarantee that the pieces fit your real constraints.
The problem isn't the AI. The problem is the request. A broad, vague task gives the model enormous latitude to fill in details you care about. What it fills them in with is essentially a guess — the most common pattern it has seen for this class of problem.
The solution is decomposition: taking a big problem and breaking it into sub-tasks small enough that you can specify them precisely.
Why AI works better on narrow tasks
A model generates a response by predicting the most plausible continuation of your prompt. For a narrow, specific task, "most plausible" converges reliably toward what you actually want. For a broad task, "most plausible" produces the generic centre of a very large distribution — the kind of code that technically answers the question but misses all your specific requirements.
Consider the difference:
Broad: "Build me an expense tracker."
Narrow: "Write a Python function that takes a list of dictionaries with
date(ISO 8601 string),amount(float), andcategory(string) keys, and returns a summary dictionary mapping each category to the total amount spent in that category."
The second prompt has exactly one reasonable interpretation. The model can produce a correct, verifiable solution. The first prompt has thousands — and the one the model picks almost certainly differs from the one you have in your head.
Decomposition in practice
Decomposition is not a formal methodology — it's a thinking habit. You look at a problem and ask: what are the distinct responsibilities here? Where are the natural seams?
For a problem like "build a tool that parses a CSV of sales data and produces a monthly summary report," the seams are visible:
- Parsing — read the CSV file and turn it into a structured data format
- Data cleaning — handle missing values, malformed rows, inconsistent date formats
- Aggregation — group rows by month and compute the summaries (total sales, average, max)
- Formatting — turn the aggregated data into the report format (table, text file, specific columns)
Each of these is a well-scoped sub-task. Each can be specified precisely and handed to AI with a clear input shape and expected output. And critically, each can be tested independently: you can verify that parsing works correctly before you build the aggregation layer on top of it.
The natural seams in a problem usually follow data transformations. Where does one shape of data turn into another? That boundary is almost always a good place to split a task. The function signature at each boundary — what goes in, what comes out — becomes the specification you hand to the AI.
The one-thing-at-a-time principle
AI maintains focus better on narrow tasks. When you give it a broad task, it has to make dozens of implicit decisions simultaneously: data format, error handling strategy, library choice, naming conventions, abstraction level, performance assumptions. It resolves these by pattern-matching to the most common choices, not to your choices.
When you give it one narrow task, those decisions are either specified by you or genuinely don't matter. The model's attention goes entirely into solving the problem rather than resolving ambiguities.
A useful prompt hygiene rule: if a prompt contains more than one verb ("parse and summarise and format"), consider splitting it into separate prompts. Each verb is a potential task. Each task is a potential sub-problem with its own specification and test.
Decomposition is not micromanagement
Decomposition doesn't mean writing the specification so completely that you've already solved the problem. It means writing it specifically enough that the model's output is verifiable and correctable.
There is a level of specificity that's too much — where you've essentially written pseudocode and you're asking the model to transcribe it. That's valid as a use case (it's fast to go from pseudocode to working code), but it's not the same as decomposition. Decomposition is about finding the right sub-problem boundaries so that each piece is tractable, not about pre-solving every piece.
Don't decompose more than necessary. Some tasks are genuinely one thing. "Write a function that formats a currency amount as a string with two decimal places and a dollar sign" is already well-scoped — decomposing it further adds overhead without benefit. Decompose until the task is tractable, then stop.
Ordering sub-tasks matters
The order you tackle sub-tasks in matters for two reasons. First, later sub-tasks often depend on the output format of earlier ones — you need to know what the parsed data looks like before you can write the aggregation function. Second, earlier sub-tasks give you working code to reference when writing later ones.
A good approach: start with the data model. Define what your core data structure looks like — the shape of the thing that flows through the system — before asking for any processing code. That definition becomes the shared specification you use in every subsequent prompt:
"All functions in this system operate on a list of
Transactionobjects with these fields: ..."
Where to go next
Decomposition gives you well-scoped tasks to hand to AI. The next lesson covers what to do when the output from one of those tasks isn't working: debugging with AI — how to give the model the right information to help you diagnose and fix a problem.
Knowledge check
- 1.Why does AI produce better results on narrow, well-scoped tasks than on broad ones?
- 2.A developer wants to build a tool that reads a JSON file of user records, filters out inactive users, and emails each active user a personalised welcome message. Which of the following are good sub-task decompositions? Select all that apply.
- 3.When decomposing a problem for AI, you should always break it into as many small sub-tasks as possible to maximise AI accuracy.
Lab: Prompt engineering challenge
Start with a deliberately vague prompt and iterate through every technique from this module — ending with a final version you can compare to your first attempt.
Debugging with AI
Give AI the right information to become an effective debugging partner — and avoid the trap of accepting fixes that treat the symptom rather than the cause.