AI is leverage, not authority.

// 02what i believe

• -AI is a powerful tool, not a decision-maker. It proposes, a human with context approves.
• -Trust but verify, every time. Generated code gets the same review as any production change, often more scrutiny, because a model rarely signals uncertainty reliably.
• -Security doesn't get outsourced to a model. Secrets, auth boundaries, and data handling get reviewed by someone who understands what breaks if it's wrong.
• -Automate the repeatable, not the judgment calls. Boilerplate, migrations, test scaffolding, first-pass docs: automate all of it. Architecture trade-offs and "should we even build this" stay human.
• -Knowing how to work with AI well is now a core engineering skill, not a side interest. It's the same tier as knowing your data structures.

// 03how i see the future

Right now, engineers who can't use AI tools are already behind, and the gap is widening by the week, not the year. My honest read: by 2030, "software engineer" as the industry has defined that role for the last two decades won't exist in the same form. What survives is the engineer who leverages AI fully. That means treating it as a force behind their own judgment and taste, not a replacement for either.

I can build a working proof of concept in an afternoon that used to take a sprint. That part isn't the concerning one. What's concerning is how little distance is left between "fast POC" and "good enough to replace the person who built it." Not much, and shrinking.

What holds that gap open going forward is speed of shipping and having an idea worth shipping in the first place. Implementation keeps getting cheaper. What remains scarce is understanding the problem, choosing the right constraints, verifying the result, and taking responsibility for what reaches production.

// 04what i help teams change

I help engineering teams turn occasional AI usage into repeatable, production-ready workflows. The goal is not to add another AI tool. It is to remove friction, shorten feedback loops, and create systems that engineers can understand and trust.

• -Developer experience: rebuilding the parts of a workflow that waste senior engineers' time (slow feedback loops, manual review queues, brittle CI) so attention goes to the 10% that actually needs a human.
• -Workflow automation: turning repeatable engineering work (releases, migrations, incident triage, first-pass code review) into pipelines an agent runs and a human trusts.
• -Agentic operating systems: designing the shared tools, permissions, memory, knowledge, and guardrails that let a team safely delegate work to multiple agents instead of processing every task through a human-controlled queue.
• -Full leverage: not occasional use of a chat assistant. Wiring AI into the actual development loop (code, tests, docs, deploys) so the whole system moves faster, not just the typing.

// 05how i work with ai tools

• -Skills: packaging repeatable expertise (a deploy checklist, a code review rubric, a domain's edge cases) into instructions an agent loads on demand, instead of re-explaining the same context every session.
• -Subagents: running a task in its own isolated context window so it doesn't pollute the main conversation, and so a narrowly scoped agent can focus on exactly one job instead of juggling everything at once.
• -Agentic workflows: chaining multiple agents through defined stages (research, implement, review) with checkpoints a human actually reads, not a black box that runs end to end unsupervised.
• -Tool configuration: setting what each agent can touch on purpose. Permissions, MCP servers, and file access get scoped per task, not granted wholesale because it's convenient.