Think Like an Architect: Breaking Big Tasks Down

You paste a feature description into Claude Code: 'Add user authentication with email login, Google sign-in, password reset, and remember me.' It produces a sprawling implementation across eight files, makes architectural decisions you didn't agree to, and introduces three subtle bugs you won't notice until you deploy. The problem is the task size.

Every part of a task comes with decisions: where things go, what they're called, what happens when something goes wrong, how information is organized, and how the pieces talk to each other. In a big task, Claude Code makes all of them at once, without checking with you, from its best guess at what you'd want.

Some of those guesses will be wrong. Changing how login works after it's connected to eight parts of your project can mean reworking all eight. Before those connections exist, it's one change.

Big tasks are also harder to verify. When Claude Code returns 800 lines of code, how do you check it? You can read it, but you can't easily tell whether the error handling is right, whether people stay logged in after an hour, or whether Google sign-in copes with every unusual case. You ship it and find out once people are using it.