Think Like an Engineer - Break Down Problems, Not Prompts

What I've used at work for 20+ years, I also use with AI: break down problems into atomic parts and go step by step. It's like telling a story - when someone writes "He drives a car" on the first page of a book, the reader can't understand who it is, what it is, and might even close the book. But if the first page provides a good hook and context - even if not too much - it immediately reads better.

It's similar with AI. It doesn't matter that it doesn't have all the context from the beginning, but it needs the basic foundation and that initial hook to guide it in the right direction.

Atomization: Why Smaller Tasks = Better Results

It's ironic. Giving AI a large task often takes more time than breaking it into small steps. Why?

When I break a big problem into smaller parts:

• For each task, I can quickly provide the right context (e.g., the right code file)
• The task description is shorter and clearer
• AI has an extremely high chance of correct results on first iteration
• Results sometimes come in seconds

Compared to a large task:

• AI breaks it down into iterations itself
• Searches for right context from my large context
• More iterations and reviews I have to do
• At the end of the day, it costs me more time

Real Example: Car Seat vs. Vacation

Car seat selection - atomic part:

• Clear goal (seat for 120cm child)
• Clear criteria (safety)
• Clear output (top 3 list)

Trip planning - needs breakdown:

1. Car seat selection for older child
2. Check if it can be passed to younger one (who grows faster)
3. Packing list
4. Route and stops
5. Accommodation

Each part I handle separately with its own context. Result? Everything solved in 30 minutes instead of 2 hours of chaos.

Parallelism Is a Trap

Someone on LinkedIn wrote about parallel AI agents:

• "One analyzes code"
• "Second writes tests"
• "Third writes documentation"
• "Everything in parallel!"

This is bad in practice. Why?

Task A uses input data that Task B modifies. Task A's result will be based on data that's no longer true.

My rule: I work in parallel only on things that aren't connected. For example:

• Bug fix in module A + writing tests for module B ✓
• Refactoring function + writing documentation for the same function ✗

When I Know a Task Is Too Big

When I give a task, I already have an idea of how it will be solved. I automatically know if it's a complex solution. I look at it from the perspective of:

1. Features:

• Is it CRUD? (Create, Read, Update, Delete)
• Dashboard with multiple widgets?
• Linking multiple record types?

2. Data:

• How many entities does the task involve?
• Is data interconnected?

3. Context:

• How many files do I need to keep in memory?
• Is information about the problem massive?

If the answer to more than 2 questions is "many/yes," I divide it.

Clear Goals, Flexible Path

You need clearly defined goals from the start. BUT! You need to expect that on the way to goals, those goals might:

• Expand (discover more opportunities)
• Deepen (find the problem is deeper)
• Shrink (find it won't work as planned)
• Change (the bug is completely elsewhere)

Example from practice: Solving bug "user can't save form." On the way I discover:

1. Problem isn't in saving but in validation
2. Validation fails only for certain emails
3. Found 2 more similar bugs
4. All 3 have common cause

Goal changed from "fix saving" to "fix email validation." That's fine.

Vibe Coding: 2 Minutes or Something's Wrong

For me, vibe coding isn't giving a prompt and going for coffee. It's:

• Give specific prompt
• Have a result in seconds, max 1-2 minutes
• If it takes longer, it's an error

Usually when it takes long, the result is also bad. Then I know I must:

1. Make task smaller
2. Improve context
3. Start over

Practical Workflow for Complex Tasks

1. First analysis (read-only)

   • "Analyze this task and break it into steps"
   • AI gives me a list

2. Then atomic tasks

   • "Do only step #1"
   • I add context for that step

3. Record progress

   • I write analysis to markdown file
   • Use it as seed for new sessions

4. Every 8-12 interactions

   • Ask for SUMMARY + 3 TODO
   • Start new session with this seed

This avoids context contamination and keeps sessions focused.

Conclusion: AI Isn't Magic, It's a Tool

The key skill in working with AI (and not just AI) is the ability to break down complex problems into meaningful steps with clear context. This isn't just a technique. It's a mindset.

In the next article, we'll look at how AI changes work - it doesn't replace it, but pushes us to a higher league.

---

Oliver Kriska has been programming for 25+ years, working with AI daily. His principle: same approach to juniors and AI - clear tasks, small steps, iterations.