When people talk about AI for programming, almost everyone pictures "write me this function". Where it helps me most isn't generating code, but thinking and organizing before touching anything. Here's how I actually use it at work.
1. Structure the problem before coding
Before writing a line, I explain the problem and ask it to help me break it down: what the pieces are, what order makes sense, which edge cases I'm missing. Not so it decides for me, but so I have a first map that I then critique and adjust. I start with a plan, not a blank page.
2. Split the work into real tasks
From a big, fuzzy feature to a concrete, ordered task list. AI is great at turning "we need the notifications module" into actionable steps. That saves me the heaviest part of planning sprints and backlog.
3. Architecture sparring
For design decisions I use it as someone to argue with: I propose two approaches and ask for trade-offs. I don't trust the answer blindly (it's often incomplete), but it forces me to justify my decision, which is exactly what I want.
4. Documentation and review
First drafts of docs, READMEs, meaningful commit messages, and a first review pass that catches slips before I ask a teammate for review.
What I DON'T do
- I don't trust it blindly. I verify anything that touches code or data; AI is wrong with apparent confidence.
- I don't delegate judgment. The decision and the responsibility are mine; AI speeds me up, it doesn't decide.
- I don't ship code I don't understand. If I can't explain it, it doesn't go in.
What it's actually good for
Reaching the code with a clear plan and not losing the thread on long projects. And I apply the same thing to client work: first structure what you actually need together, then build it. If you have an idea you want to land, write to me.