Teaching the AI to Code (and Accidentally Becoming Better Engineers)
Remember all those engineering best practices we were taught…
but quietly skipped?
Write clear user stories.
Name things well.
Break down problems.
Document decisions.
Structure your design.
We knew these were good habits.
But real deadlines, MVP crunches, and scrappy startups had other plans.
So a lot of that got lost.
Now, with AI in the mix, we’re doing it all again.
Not for ourselves but to help the AI understand what we’re asking.
It turns out: if you want a language model to generate anything useful inside a real codebase, you have to give it the full context.
- Use cases
- Architecture overviews
- Similar implementations
- Design intent
- Naming conventions
- Integration patterns
Basically: you have to engineer the problem, before the AI can engineer a solution.
A developer recently shared two workflows while using an AI assistant. (LinkedIn post)
One was a fun roleplay: an “Architect” persona proposing a design, challenged by a “Devil’s Advocate,” then refined in a loop.
The other?
A long, structured, context-first deep dive:
- Deconstruct the problem
- Feed in docs, patterns, and similar code
- Build shared understanding
- Then — only then — generate code, in phases
Guess which one worked?
Not the clever roleplay.
The boring one.
The one that looked like real software design.
And that’s the kicker:
The AI didn’t need clever prompts.
It needed the engineering discipline we used to have.
We’re doing them because the AI falls apart without them.
The AI isn’t leveling us up.
It’s just reminding us what the level always was.
We say we’re coding with AI.
But most days, it feels more like we’re coaching it.
And in doing that maybe we’re finally coaching ourselves again, too.
