The problem solving process has always been an important part of software development, but AI has made it even more important. Developers can now move from an idea to generated code incredibly quickly. That speed can be useful, but it also makes it tempting to skip the thinking that should happen before implementation.
Instead of defining the problem and working through the solution, we can jump directly into asking AI to build something. This week’s challenge is about reversing that process. Before you ask AI to generate the answer, write down what you are trying to accomplish and how you believe the solution should work. In other words, show your work before asking AI to do the work.
Start Your Problem Solving Process with the Problem
One of the central ideas from this week’s conversation is deceptively simple: know what you are solving before deciding how to solve it. Rob Broadhead explains that developers should “define your problem before you actually put AI on it.” That distinction matters because beginning with AI can mean beginning with a solution rather than the actual problem.
It is easy to decide, “I’m going to use AI to fix this,” and then work backward from the tool. A stronger approach begins with understanding what is wrong, what needs to change, and what a successful outcome should look like. Only after those questions have been answered should you decide whether AI belongs in the solution and what role it should play.
Michael Meloche connects this approach to test-driven development. When you understand what the end product should be, you have something against which you can evaluate the implementation. The same principle applies to AI. You need to understand the expected result well enough to recognize when AI is moving toward the wrong one.
AI becomes more useful when you give it a destination and a path instead of asking it to discover both for you.
Your Problem Solving Process Creates AI Guardrails
Requirements, flow diagrams, user stories, pseudocode, inputs, and outputs may sound like traditional software development exercises. However, these practices become especially useful when AI enters the workflow because they force developers to turn assumptions into explicit instructions.
Rob points out that many of the practices developers learned before writing code have become valuable guardrails for AI. Defining the product, documenting requirements, identifying inputs and outputs, and thinking through the design give you a framework for evaluating whatever AI produces.
Guardrails do not necessarily slow development down. They can make development faster because they provide direction. Without that direction, you may generate something quickly, discover that it does not fit the problem, change course, generate something else, and repeat the process. You are moving quickly, but you are zigzagging toward the destination.
When the destination and boundaries are already defined, AI has a clearer path to follow. You also have a better way to recognize when it leaves that path.
AI can generate a large amount of work very quickly. If you have not defined the destination first, that speed can create more work instead of more progress.
Show Your Work Before AI Shows You an Answer
Many developers remember being told to “show your work” when solving math problems in school. Rob admits that he disliked this requirement. If he already knew the answer, writing every intermediate step seemed unnecessary.
Working with AI gives that old exercise new relevance. AI can give you an answer quickly, but that creates another question: is it the right answer? As Michael asks during the discussion, “AI can give you a solution, but is it the right solution?”
You cannot confidently answer that question if you have not thought through the problem yourself. That does not mean manually writing the entire application before asking AI for help. It means understanding enough of the path from problem to outcome that you can evaluate the proposed solution.
Rob uses tying a shoe as an example. Most of us can tie our shoes without consciously thinking through every movement, but explaining every step clearly enough for another person to reproduce the process is surprisingly difficult. We carry knowledge in our heads that we use automatically without having to verbalize it.
Software development contains the same kind of hidden knowledge. Experienced developers recognize patterns, make assumptions, account for dependencies, and eliminate options without necessarily documenting every decision. Working with AI increasingly requires making some of that knowledge explicit.
Writing down your approach can expose gaps before implementation begins. You may realize that an input is missing, an assumption is unreliable, two steps depend on each other, or the expected outcome has never been clearly defined. Discovering those problems before generating the implementation is part of the value of showing your work.
A Better Problem Solving Process Builds Systems Thinkers
This Weekly Challenge is about more than writing better AI prompts. It connects directly to building a career beyond the code.
Rob argues that developers increasingly need to become systems thinkers rather than focusing exclusively on writing code. Michael expands on that point by discussing how developers now encounter different layers of a complete solution. The boundaries between development, databases, DevOps, testing, and other parts of software delivery are increasingly difficult to treat as completely separate concerns.
The important question is therefore becoming less about whether you can write a particular method or remember the syntax for a specific language. The bigger question is whether you understand what needs to be built and how the pieces work together.
A systems thinker needs to be able to:
- Understand the problem being solved.
- Define the expected outcome.
- Break a larger solution into smaller components.
- Recognize dependencies between those components.
- Identify assumptions and missing information.
- Explain how information moves through the system.
- Evaluate whether an implementation matches the original requirements.
AI can help generate individual pieces of a system, but someone still needs to understand how those pieces should fit together. That is where critical thinking and systems thinking become increasingly important.
Building a career beyond the code means developing value in the thinking surrounding the implementation, not only in producing the implementation itself.
Take the Problem Solving Process Challenge
This week, choose one real problem from something you are currently building. It does not have to be an entire application. If you are working on a large project, choose a feature, module, workflow, or individual problem that is small enough to think through in one sitting.
Then open a Markdown document, text file, notebook, or physical notepad. Do not start by asking AI to solve the problem. Start by documenting your understanding of it.
Write down:
- The problem: What exactly are you trying to solve?
- The desired result: What should exist or happen when the work is complete?
- The inputs: What information does the solution require?
- The process: What needs to happen, and in what order?
- The outputs: What should the completed process produce?
- The assumptions: What are you currently assuming to be true?
- The unknowns: What still needs to be investigated or decided?
Do not worry about creating a polished technical specification. The purpose of the exercise is to make your thinking visible. You want enough detail that you can follow the process from the original problem to the expected result.
Spend at least fifteen minutes documenting your solution before asking AI to generate anything. Then give AI the problem, expected outcome, and process you created and use that framework as the starting point for implementation.
Use AI to Test Your Thinking
Once you have documented the solution, bring AI into the process. At this point, AI is no longer starting with an empty page. You have given it a framework to work within.
Pay attention to what happens next. AI may identify a missing step, point out an edge case, suggest that two steps should happen in a different order, or produce something that conflicts with one of your requirements. Those differences give you something concrete to evaluate.
Instead of asking yourself whether the AI response simply looks good, you can compare it against the problem and process you already defined. Does the proposed solution produce the output you expected? Does it respect the assumptions you documented? Did it introduce functionality that was never required? Did it miss an important step?
Rob notes that the process of writing things down will often expose forgotten details before AI ever becomes involved. You may find yourself realizing, “I forgot this,” or “I forgot that.” AI can then uncover additional gaps.
That is not a failure of the exercise. Finding those gaps is one of its most useful outcomes.
Build the Skill in Small Steps
You do not need to spend every evening and weekend developing this skill. One of Rob’s recurring recommendations is to make progress in small increments. Fifteen minutes a day, repeated consistently, can become several hours of meaningful work over the course of a week.
The same approach works for systems thinking. You do not need to understand every technology, architecture, framework, and AI tool at once. Pick one problem and work through it. Then do the same thing with another problem.
Over time, patterns begin to emerge. You start recognizing common dependencies and assumptions. You ask better questions earlier. You become more deliberate about why you choose a framework, stack, architecture, or tool. Eventually, the process of breaking down a problem becomes part of how you naturally approach development.
That is progress toward a career beyond the code. You are not simply becoming faster at generating software. You are becoming better at understanding what software needs to do before implementation begins.
Conclusion: Think First, Then Build
AI makes producing software faster. That makes thinking before producing software more valuable, not less.
This week, choose one real development problem and resist the temptation to immediately hand it to AI. Define the problem, describe the outcome, identify the inputs and outputs, break the solution into steps, and question your assumptions. Show your work before asking AI to do the work.
Then bring AI into the process and see what changes.
A strong problem solving process gives AI better guardrails, but the larger benefit belongs to you. You are practicing the ability to understand problems, communicate solutions, and think about complete systems rather than individual pieces of code.
Those are skills you can carry from project to project, regardless of which programming language, framework, or AI tool comes next.
Stay Connected: Join the Developreneur Community
👉 Subscribe to Building Better Developers for more conversations on momentum, leadership, and growth. Whether you’re a seasoned developer or just starting, there’s always room to learn and grow together. Contact us at [email protected] with your questions, feedback, or suggestions for future episodes. Together, let’s continue exploring the exciting world of software development.