The Secret Life of Claude Code: Why Small Tasks Are the Key to Working with AI

How to break down complex work so Claude Code helps you build it right, piece by piece

#ClaudeCode #CodingWithAI #SoftwareEngineering #SmallTasks

Margaret is a senior software engineer. Timothy is her junior colleague. They work in a grand Victorian library in London — the kind of place where code quality is the unspoken objective, and craftsmanship is the only thing that matters.

Episode 10

The rain had been falling since midmorning, and by evening it had settled into the kind of steady, unhurried rhythm. It made the library feel like the only solid place in the city. Timothy arrived shaking water from his coat, his notebook already open in his hand, a page flagged with a folded corner.

Margaret was at her usual table, a fresh pot of tea steaming beside her. She glanced at the flagged page as he sat down.

"You came with something specific," she said.

"I came with a disaster," he said pleasantly. "A contained one. But instructive."

She waited.

"I had a task yesterday. Reasonably sized — or so I thought. Add a caching layer to an existing service. I'd planned it, briefed it properly, asked Claude Code to help me think through the risks first." He set the notebook on the table. "All the things we've talked about."

"And?"

"And I gave it to Claude Code as one task. The whole thing. Caching strategy, implementation, integration with the existing service, error handling, cache invalidation." He paused. "Two hours later I had something that was technically impressive and practically unusable. The cache invalidation logic conflicted with the error handling. The integration made assumptions about the existing service that weren't true. And by the time I found the problems, everything was tangled together. I couldn't fix one thing without pulling on three others."

Margaret poured tea into his cup without being asked.

"You handed it a continent," she said, "and asked it to map it all at once."

Why Small Tasks Work Better

Timothy wrapped his hands around the cup. "I thought the briefing would be enough. I'd given it all the context."

"Context tells Claude Code what you need," Margaret said. "It does not change what happens when a task is too large. A well-briefed large task produces a well-reasoned large mistake." She set down the pot. "The size of the task determines how quickly you can detect an error, and how much it costs you when you do."

"Small tasks fail small," Timothy said.

"Yes. And they fail early, when the cost of correction is still low." She turned her cup slowly in its saucer. "Think of it this way. When you hand Claude Code a small, precise task, you receive a small, precise output. You can read it in its entirety. You can test it in isolation. You can confirm it is correct before it touches anything else." She paused. "When you hand it a large task, you receive a large output — and the errors inside it are distributed across the whole. Finding them requires understanding everything at once."

Timothy thought of yesterday. The cache invalidation logic had looked reasonable in isolation. The error handling had looked reasonable in isolation. It was only when they met in the middle of the integrated whole that the conflict became visible — and by then, unpicking it had taken longer than writing it.

"The size of the task is also the size of the blast radius," he said.

"That is exactly the right way to think about it," Margaret said.

Finding Natural Divisions in Your Work

"How small is small enough?" Timothy asked. "There must be a point where you're dividing things so finely that you lose the coherence of the whole."

"There is," Margaret agreed. "The discipline is not smallness for its own sake. It is finding the natural seams in the work and cutting there — not forcing artificial divisions, but recognizing where one thing genuinely ends and another begins."

She pulled a sheet of paper toward her and wrote a single word: caching.

"Your task yesterday. Where were the seams?"

Timothy thought about it. "The strategy — deciding what to cache and for how long — is separate from the implementation. The implementation is separate from the integration. The integration is separate from the error handling. And cache invalidation is its own problem entirely."

"Five tasks," Margaret said. "Not one."

"Five tasks that could each be reviewed, tested, and confirmed before the next one began." He looked at the word on the paper. "And if the strategy was wrong, I'd have found out before I'd written a line of implementation."

"Yes. And the strategy prompt looks very different from the implementation prompt. One asks Claude Code to reason and recommend. The other asks it to build something specific and bounded." She set down her pen. "Different sizes of task require different kinds of prompt. When you conflate them, you get a response that is trying to do both — and usually doing neither as well as it could."

Making Confirmation a Habit

"There's something else I've been thinking about," Timothy said. "Even when I break tasks down, I sometimes find myself rushing through the confirmation step. I get the output, it looks right, I move on."

"And later you discover it was not quite right," Margaret said.

"Later, when it's load-bearing," he said. "When other things have been built on top of it."

Margaret nodded slowly. "This is the second half of the discipline. Breaking the task down creates the opportunity for confirmation. But the opportunity must be taken." She looked at him steadily. "Confirmation is not glancing at the output and finding it plausible. It is asking yourself — and sometimes asking Claude Code — whether this output is precisely correct, not approximately correct."

"Approximately correct is dangerous," Timothy said.

"Approximately correct is the most dangerous kind of wrong," Margaret said, "because it passes every casual inspection. It fails only under load, or at the edge, or in combination with something else — which is to say, it fails at the worst possible moment." She paused. "The small task gives you something testable. The confirmation habit ensures you actually test it."

Timothy wrote this down. He thought of the number of times he had read an output, nodded, and moved on — not because he had verified it but because it had looked like the thing he expected to see. Expectation was not verification. He had known this in principle for years. He was only now feeling its full weight.

Claude Code Knows When It's Guessing

"One thing I've noticed," Timothy said, "is that when I give Claude Code a large task, the output sometimes has a kind of confidence that isn't quite earned. It produces something complete and coherent, and it reads like certainty."

"And when you give it a small task?"

He thought about it. "It's more precise. And sometimes it flags uncertainty more clearly — tells me it's made an assumption, or that there are two ways to approach something."

"Yes," Margaret said. "This is not accidental. A large task requires Claude Code to make many decisions — some it can make well, some it cannot. But the output arrives as a whole, and the confident parts and the uncertain parts look the same. The seams between what it knows and what it has guessed are hidden inside the larger structure." She refilled her cup. "A small task narrows the space. There are fewer decisions to make, and the ones that require assumptions are easier to surface — both for Claude Code and for you."

Timothy sat with this for a moment. The large task had felt efficient going in. One prompt, one output, one review. In practice it had been the least efficient thing he had done all week. The small tasks would have taken more prompts. They would have taken less time.

"The overhead of breaking it down is always less than the overhead of untangling it," he said.

"Always," Margaret said. "Without exception, in my experience."

Keeping the Larger Goal in View

"I want to go back to what you said about losing coherence," Timothy said. "If I'm working in small pieces, how do I make sure the whole still holds together?"

"This is the right question," Margaret said. "And it is where the plan — the one we discussed last time — does its most important work. The plan holds the shape of the whole. The small tasks are how you build it, piece by piece, each one confirmed before the next begins." She paused. "The plan is the map. The small tasks are the steps. You do not need to see the whole path at once — you need to know where you are going and take each step with care."

"And Claude Code holds the context of the plan if I provide it at each step."

"Yes. A brief reminder of the larger goal at the start of each small task keeps the pieces oriented. You are not starting fresh each time — you are continuing a known journey." She looked at him. "The discipline is maintaining that thread. Not letting the small tasks become disconnected fragments, but keeping each one in its place within the whole."

Timothy thought of the way a good craftsman worked — not trying to finish everything at once, but completing each part fully before moving to the next, trusting that precise parts would assemble into a precise whole. The quality of the whole was the sum of the care taken at each seam.

"Small tasks, big discipline," he said.

Margaret looked at him with quiet approval. "The title of the lesson," she said. "Yes."

Timothy gathered his things as the rain continued its steady conversation with the windows. The library felt warm against it, the lamps steady, the shelves standing their patient watch.

"I'm going back to the caching task tonight," he said. "Starting over."

"Five tasks," Margaret said.

"Five tasks. Strategy first. Then implementation. Then integration. Then error handling. Then invalidation." He tucked his notebook under his arm. "Each one confirmed before the next begins."

"And if the strategy produces a surprise?"

"Then I'll be glad I found out before I built anything on top of it." He buttoned his coat. "Cheaper that way."

"Considerably," Margaret said, already turning back to her reading.

He walked to the tall doors and pushed through them into the rain, which received him without complaint.

Behind him the library settled back into its quiet, the only sound the occasional turn of a page and the steady percussion of rain against old glass.

Next episode: Margaret and Timothy explore the junior developer's advantage — why less experience with established patterns can be a genuine asset when working with Claude Code, and what veterans can learn from the beginner's approach.

Aaron Rose is a software engineer and technology writer at tech-reader.blog.

Catch up on the latest explainer videos, podcasts, and industry discussions below.

Search This Blog

Tech-Reader.blog