Process
You didn't write every line of code. So what's your actual value-add?
It's the fair, skeptical question — and the honest answer is that directing AI coding tools didn't remove the hard part of the job, it relocated it. The hard part was never typing the code; it was scoping the requirement, deciding the architecture, holding the security bar, and knowing when a feature is lying to the user. That's the part I still do myself, on every change.
Operating model
The loop, every feature
1
PRD thinking
- Ambiguous ask → defensible scope
2
FEATURE_MAP scoping
- Pin feature to exact files, endpoints, tables
3
AI-directed implementation
- Within the pinned scope only
4
Test-gated commit
- Suite must be green before merge
5
Audit remediation loop
- Zero-trust security pass
Step 5 feeds back into step 1 for the next feature — the audit findings become next sprint's PRD input, not a one-time cleanup pass.
The anti-spiral discipline
Why 'AI-directed' needs a scoping contract, not just a prompt
The specific failure mode of directing AI coding tools across a growing codebase isn't bad code — it's scope creep an AI tool won't flag on its own: a change requested for one feature quietly edits a shared file and breaks a feature nobody was even looking at. The FEATURE_MAP discipline exists to make that failure structurally harder — every feature is pinned to its exact files, endpoints, and tables before a change starts, and touching a shared file (models, schemas, config, main entrypoint) is treated as a contract change that needs explicit, wider review rather than getting bundled into an unrelated fix.
Where this shows up in the product, not just the code
The BodhitAI feature audit
The same discipline applied to product honesty, not just code correctness: auditing BodhitAI's own feature surface and feature-flagging off a fake "AI mirror," a rules engine posing as AI, and an insecure payment flow — cutting an 8-feature surface to 3 that genuinely worked, rather than shipping a feature that would mislead a user about what it actually does.
What this makes me good at
Judgment, applied at the layer that doesn't get automated away
- →
Turning an ambiguous requirement into a scoped, defensible system — the PRD-thinking step that has to happen before any tool, AI or otherwise, can be pointed at a problem correctly.
- →
Holding a non-negotiable security and test bar even while moving fast solo — because there's no second engineer to catch what a fast-moving change missed.
- →
Catching when a feature is dishonest before a user does — treating "does this actually work the way it claims to" as a product-management responsibility, not an afterthought.