Skip to main content

I and AI

Feb 17, 2026 · 3 min read

How I use AI as an engineering partner: plan first, implement with fast iteration, run structured reviews, and keep quality high while focusing my own time on architecture and system-level decisions.

I use AI every day, but I do not use it as autopilot. I use it as a fast engineering partner that helps me move from idea to production-quality code without losing discipline. The goal is not to generate more code. The goal is to make better technical decisions faster and keep quality high while doing it.

My workflow is simple and repeatable: define the scope clearly, implement the smallest correct change, validate it, review it, and ship it. AI helps in every step, but ownership stays with me. If lint, tests, or build fail, we fix root causes before moving on. No duct tape, no “good enough for now” hacks.

In practice, we plan first and iterate the plan until scope and direction are exactly right. Only after that do we implement. Depending on complexity, I either review continuously while changes are being made or in one focused pass at the end. Once implementation is done, I run a structured review pass with Codex, then prepare the PR and review everything myself before merge.

This gives me speed without giving up control. AI removes a lot of execution overhead, but technical judgment and final responsibility stay with me. A big practical win is that AI can take more of the grunt implementation work, which frees me to spend more time on architecture, tradeoffs, and system-level decisions.

Where this helps most is momentum. I can implement faster, refactor with more confidence, and tighten naming and structure while context is still fresh. It also helps with less glamorous but important work: removing dead code, keeping docs in sync, and making PRs precise instead of vague.

Another big shift is breadth. AI helps me execute outside my core day-to-day stack faster, but still within areas I can reason about. I can work more efficiently because I understand the fundamentals and can validate the result. A new programming language or library is no longer a blocker; it is a learning curve I can handle quickly with tight feedback loops and proper review.

To make this repeatable across projects, I built starter kits for both Codex and Claude. They include baseline rules, common workflows, and sensible defaults, so I can start quickly without rebuilding process every time. That setup reduces day-one friction and keeps quality consistent across different codebases.

The non-negotiables are the same as before AI: readable code, meaningful tests, clear contracts, and stable behavior. If those are missing, nothing else matters. For me, AI is force multiplication for fundamentals, not a replacement for them.

If you want a concrete example of this in practice, read Launching Resume v2.

Share