Building Practical Software with AI-Assisted Tools
Reflections on integrating AI tools into real product workflows — what's working, what's hype, and where the leverage actually lives.
The question I keep hearing from engineers is some version of: “Should I be using AI tools in my workflow?”
The answer — in my experience — is yes, but probably not for the reason you think. The leverage isn’t in having AI write your code. It’s in reducing the friction of starting.
The Starting Problem
Most software work doesn’t stall in the middle of a problem. It stalls at the beginning. The blank file. The first test to write. The configuration you’ve done before but can’t quite remember.
AI tools are exceptional at reducing that friction. They’re like having a knowledgeable pair who’s read every Stack Overflow answer and can type faster than you.
What I Actually Use It For
In my current workflow, AI-assisted tools do useful work at specific seams:
- Scaffolding and boilerplate: Setting up a new project, generating repetitive config, wiring up initial structure. Not the decisions, just the keystrokes.
- Unsticking moments: When I know roughly what I need but can’t remember the exact API, syntax, or flag, a well-prompted AI gets me there in seconds.
- First drafts of tests: Writing tests is often the hardest step. Getting a reasonable first draft helps me iterate to something correct rather than starting from zero.
- Documentation: Writing a clear
READMEor API docs is tedious. AI handles the tedium; I handle the accuracy.
What I Don’t Use It For
Architecture decisions. Anything that requires deep understanding of the specific constraints of my codebase. Code review. Anything where the cost of being confidently wrong is high.
AI tools are very good at being confident. They’re not always right. The discipline is knowing when to trust and when to verify.
The Craft Question
Here’s the concern I take seriously: does leaning on AI tools erode craft over time?
My honest answer is: it depends on how you use it. If you treat every AI output as ground truth and stop reasoning through your code, yes — you’ll lose sharpness. If you use it as a starting point that you then own fully, I think the net effect is neutral to positive.
The judgment is still yours. The taste is still yours. The accountability is still yours.
Where I Think This Goes
The tools are good now. They’ll be better in two years. The engineers who’ll thrive are the ones who can use them as amplifiers without outsourcing their judgment.
That’s not a new skill — it’s the same thing we say about every productivity tool. Know when to reach for it, and know when to put it down.
This is an early working draft. I’ll continue updating this as my thinking evolves.