Most developers ask AI for code and wonder why they get a tangled mess back. Here’s the fix: ask for the architecture first, the code second.
TL;DR: One prompt structure separates planning from building, and it’s the difference between clean, logical code and something you have to completely rewrite.
The Real Problem Isn’t the AI
When you drop an open-ended request like “write me a Python script that does X,” the AI fills in every blank. It makes assumptions about structure, data flow, class organization, and logic. Sometimes those assumptions are fine. Often, they create code that technically works but is impossible to extend or maintain.
Spaghetti code isn’t a failure of the model. It’s a failure of the prompt. You gave it no constraints, so it invented its own.
Think about what that actually looks like in practice. You ask for a data processing script. The AI comes back with one 200-line function, all logic shoved into a single block, variables named things like data2 and temp_result. It runs. It does what you asked. And the moment you need to add one more data source or change the output format, you’re staring at it for 45 minutes trying to figure out where to even start.
The AI wasn’t being lazy. It was being literal. You asked for code that works. You got code that works. The problem is that “works” and “maintainable” are two completely different requirements, and you only specified one of them.
The Abstract-to-Concrete Workflow
The fix is one extra step between the idea and the code. Instead of asking for a finished script, ask for the blueprint:
“I need a Python tool to [Function].
1. List the necessary classes and methods.
2. Define the data flow.
3. Once I approve, write the boilerplate code.”
You review the architecture before a single line of real code gets written. You catch structural problems at the design stage, not after you’re two hours into debugging. Then you approve and let the AI build on a foundation you’ve already validated.
Here’s what that looks like in a real exchange. You ask for the architecture of a web scraper that collects pricing data from three sites. The AI comes back with a ScraperBase class, three site-specific subclasses, a DataNormalizer that handles formatting, and a StorageHandler that writes to CSV or a database. You look at it and immediately notice the normalizer should actually sit inside each scraper, not after the fact. You say so. The AI adjusts. Now you build. The whole feedback loop takes five minutes, and it just saved you from discovering that structural mistake three hours into coding.
That’s the power of the extra step. Changing an architecture sketch costs nothing. Refactoring 300 lines of code costs an afternoon.
This is exactly how senior engineers work. Sketch the structure first. Code second. The prompt is just making you apply that discipline even when you’re tempted to skip straight to building.
🛠 Use Cases
- Building scrapers that pull from multiple sources, each source can be its own class, so adding a fourth source later is a 10-minute job, not a rewrite
- Automation tools with several processing steps or conditions, mapping the flow first makes it obvious where your logic branches and where errors should be caught
- Data pipelines where the flow between components matters as much as the logic inside them, you want to see the handoffs before you see the implementation
- Any script you’ll need to maintain, extend, or hand off to someone else, future you (or a teammate) will actually understand what they’re looking at
- Integrations between two systems where both sides have their own quirks, separating the connector logic from the transformation logic keeps both clean
Prompt of the Day
Copy this and adapt it to whatever you’re building:
“I need a Python tool to [describe the function here].
1. List the necessary classes and methods.
2. Define the data flow between them.
3. Once I approve the structure, write the boilerplate code.”
Works for any language, swap Python for JavaScript, Go, or whatever you’re using. The structure is the point, not the syntax. You can also push it further by adding a step 4: “Flag any edge cases or potential failure points in the design.” Now you’re getting a code review before the code even exists.
If you’re working on something larger, the same principle applies across files and modules. Ask for the folder structure and the responsibility of each file before you ask for any of the files. The habit scales.
One Habit, Cleaner Code
Next time you’re about to ask AI to write a script, pause for one second. Ask for the architecture first. You’ll spend less time untangling and more time shipping something you’re actually proud of.
Most people skip this step because they want the code immediately. That impatience is exactly why they end up spending twice as long debugging something they could have avoided at the design stage. The two-step prompt isn’t slower. It’s faster, once you count the time you’re not spending on rewrites.
The ‘Abstract-to-Concrete’ Coding Workflow.
by u/Significant-Strike40 in PromptEngineering