AI changed my daily routine less like a magic productivity button and more like a new layer in my workflow. I do not use it to avoid thinking. I use it to make thinking cheaper: faster summaries, sharper drafts, quicker first passes, and better pressure-testing of decisions before they become code or communication.

The most useful shift was treating AI as a working partner with a narrow job, not as an oracle. I get the best results when I give it context, constraints, and a clear definition of done.

Morning: turn scattered context into a plan

My day usually starts with scattered inputs: pull requests, release notes, Slack threads, tickets, build failures, and half-finished notes from the previous day.

AI helps me turn that into an initial plan:

• summarize long threads into decisions, blockers, and owners
• extract action items from release or QA conversations
• compare a branch diff against the stated goal
• identify which files or systems I should inspect first
• rewrite a messy note into a concrete checklist

The important part is that I still decide priority. AI can tell me what is present in the context; it cannot know which tradeoff matters most for the team that day.

Coding: start with orientation, not generation

When I use AI for coding, I rarely start with "write this feature." I start with orientation:

Here is the goal. Read the surrounding code first. Tell me which patterns already exist, which files are likely involved, and what risks you see.

That first pass is valuable because it slows down the tendency to invent a new abstraction. A good AI-assisted coding session usually looks like this:

1. Ask it to inspect the local pattern.
2. Ask for a small implementation plan.
3. Make the edit.
4. Run the relevant checks.
5. Ask it to review the diff as if it were a pull request.

I still read the code. I still own the final shape. AI is useful because it keeps more context in view while I am working.

Debugging: ask for hypotheses, not certainty

Debugging is where AI can be both helpful and dangerous.

It is helpful when I ask for a ranked hypothesis list:

• what could explain this error?
• which logs or files should I inspect next?
• what changed recently that could affect this behavior?
• what would falsify each hypothesis?

It is dangerous when I accept the first plausible answer. AI is very good at producing a confident explanation before the evidence is complete. For bugs, I use it as a hypothesis generator, then force the answer back through logs, tests, reproduction steps, and source code.

Code review: make the boring pass cheap

AI is excellent at the first review pass:

• spot inconsistent naming
• catch missing edge cases
• compare code against an existing convention
• find duplicated logic
• identify missing tests
• summarize a large diff before I read it manually

That does not replace human review. It makes human review more focused. Instead of spending all my energy reconstructing the diff, I can spend more time on the part that matters: whether the change is correct, maintainable, and aligned with the product or platform direction.

Writing: draft faster, edit harder

I use AI heavily for writing, especially for internal docs, PR descriptions, release notes, and blog drafts.

The workflow is almost always:

1. I write the rough point in my own words.
2. AI reshapes it into a clearer structure.
3. I edit it back toward my voice.
4. AI checks spelling, syntax, and weak reasoning.

The last step matters. AI can make text smoother while also making it emptier. I try to keep concrete details: what failed, what changed, what I learned, and what I would do again.

Decision-making: use it as a sparring partner

The highest-value use is not code generation. It is decision support.

When I am choosing between two approaches, I ask AI to argue both sides:

• What are the hidden costs of this migration?
• What would make this abstraction premature?
• What would a senior reviewer push back on?
• Which failure mode am I underestimating?
• What is the smallest version of this change that still solves the problem?

This works because AI has no stake in my preferred solution. It can challenge the shape of an idea before I attach too much ego to it.

My rules for using AI well

These rules keep AI useful instead of noisy:

• Give it context. Good answers come from local code, real logs, concrete examples, and explicit constraints.
• Keep tasks bounded. "Review this diff for regressions" works better than "improve this codebase."
• Ask for evidence. If it makes a claim, I want file paths, line references, commands, or a reproducible reason.
• Do not outsource judgment. AI can suggest; I decide.
• Run the checks. Generated code is not real until tests, typecheck, build, or manual verification support it.
• Protect sensitive data. Do not paste secrets, customer data, private tokens, or anything that does not belong in the tool.
• Edit the voice back. Especially for writing, the first AI draft is structure, not final copy.

What changed in my day

The biggest change is not that I type less code. It is that I spend less time on blank-page work and more time on judgment.

AI helps me get from scattered context to a first useful artifact: a plan, a diff summary, a review checklist, a doc outline, a migration risk list. From there, the real engineering work is still mine.

That is the balance I try to keep: use AI to move faster through the mechanical parts, but stay accountable for the reasoning, the tradeoffs, and the final result.