My AI journey did not start with a perfect agent. It started with a practical question: can these tools help me think, ship, and review software with fewer blind spots?
The answer became yes only after I stopped treating AI like an autocomplete box and started treating it like a junior collaborator that needs context, constraints, examples, and verification.
01 / StartFrom curiosity to workflow
At first I used AI for small tasks: naming variables, summarizing docs, and drafting component structure. That helped, but the real value appeared when I asked it to inspect tradeoffs before code was written.
- Describe the goal and constraints before asking for code.
- Give it the real folder structure and project rules.
- Ask for risks and missing assumptions.
- Run lint, build, and manual checks instead of trusting the first answer.
02 / PracticeWhere AI helps me daily
The strongest use cases are planning feature boundaries, reading unfamiliar code, generating first-pass implementations, writing migration checklists, and turning messy notes into documentation that another engineer can follow.
The rule. AI can accelerate engineering work, but it cannot own correctness. The developer still owns architecture, tests, product behavior, and the final review.
03 / PromptingThe prompts that actually work
Good prompts are boring and specific. I include the route, the files, the acceptance criteria, the constraints, and the commands that prove the work is done.
Goal: update the blog detail page.
Constraints: keep locale routing, use next/image, preserve SEO metadata.
Verification: run yarn lint and yarn build.
Review: list any remaining Lighthouse risks.04 / NextWhat I want to learn next
I want to build stronger AI-assisted workflows around code review, regression testing, product research, and documentation. The goal is not to replace engineering judgment. The goal is to spend more of that judgment on the hard parts.
