Over the past year, I’ve spent hundreds of hours building software with AI.
Along the way, I noticed something interesting.
Most discussions about AI-assisted coding begin with prompts.
People debate whether they should tell the model:
“You’re a senior software engineer…”
or
“You’re an expert Python developer…”
or
“Think step by step…”
Those techniques certainly have their place.
But I eventually realized I was solving the wrong problem.
The biggest improvement in my workflow didn’t come from writing better prompts.
It came from defining better projects.
⸻
The Problem
One thing I’ve consistently observed is that many AI coding conversations begin with a large context dump.
Developers paste documentation.
Requirements.
Existing code.
Ideas.
Meeting notes.
The AI receives plenty of information…
…but very little guidance about how that information should be used.
The model has to infer:
- what the objective actually is,
- what absolutely cannot change,
- what success looks like,
- where the architectural boundaries are,
- and what kind of output is expected.
That’s a lot of unnecessary interpretation.
⸻
My Workflow Changed
Instead of starting with a coding prompt, I now start with a simple engineering brief.
Before asking any model to write code, I define the project first.
The brief acts as a shared specification between me and the AI.
It separates:
- project goals,
- architectural context,
- constraints,
- validation,
- implementation expectations.
Only after those questions are answered do I move into implementation.
At that point the coding model isn’t trying to discover the project.
It’s implementing a project that’s already been defined.
⸻
How I Use the Engineering Brief
The template itself isn’t the workflow.
The workflow is.
Here’s how I typically use it:
Step 1 – Download the template
Start with a blank Engineering Brief.
Don’t write code yet.
⸻
Step 2 – Build the project with a planning model
Upload the template into your preferred planning model.
This might be ChatGPT, Claude, Gemini, Grok, Copilot, or another LLM.
Work through the brief together.
Refine the objective.
Clarify the architecture.
Identify constraints.
Define what success actually looks like.
The goal is to produce a complete engineering specification—not code.
⸻
Step 3 – Export the completed brief
Once the planning session is finished, save the completed Engineering Brief.
At this point the project should already be well-defined.
⸻
Step 4 – Hand the brief to your implementation model
Now move to your coding environment.
Instead of beginning with:
“Build me an application…”
you’re beginning with an engineering specification that already describes the project.
The implementation model can now focus on solving the engineering problem rather than trying to discover it.
⸻
Why I Separate Planning from Implementation
I’ve found this separation surprisingly valuable.
Planning models are excellent at asking questions.
Coding models are excellent at implementation.
Those aren’t always the same skill.
By letting one model help define the project before another model begins coding, I’ve found the resulting implementations tend to be more consistent and require fewer architectural corrections later.
Why This Has Worked Better
The benefit isn’t that one particular model becomes smarter.
It’s that every collaborator—human or AI—starts from the same foundation.
I’ve used essentially the same workflow across ChatGPT, Claude, Gemini, GitHub Copilot, Grok, and other systems.
The conversations change.
The models change.
The project structure stays remarkably consistent.
That consistency has reduced misunderstandings, unnecessary rewrites, and architectural drift in my own projects.
⸻
Context Isn’t the Same as Structure
This was probably the biggest lesson for me.
Context answers:
What should the model know?
Structure answers:
What should the model do with what it knows?
Both matter.
But they’re solving different problems.
The more clearly I separate those two ideas, the better my results tend to be.
⸻
This Isn’t Really About AI
Ironically, I don’t think this workflow is specific to AI at all.
A new engineer joining a project benefits from the same clarity.
A contractor benefits.
A future version of myself benefits.
Good engineering has always started with good specifications.
AI simply makes the value of those specifications much more obvious.
⸻
Final Thought
I still use prompts.
I still refine conversations.
But I no longer expect the prompt to carry the entire project.
The project should already exist before implementation begins.
Architects don’t start with prompts.
They start with specifications.
Top comments (0)