AM
← Writing

1 Aug 2026 · 1 min read · filed between rabbit holes

Using Cursor and Codex without lowering the bar

DXCursorEngineering

I list Cursor and Codex on my resume on purpose. Not as a personality trait — as part of how I currently ship fullstack work at Tatras Data: multi-agent flows, Design Mode, rapid UI iteration, and codebase modernization.

Used badly, these tools produce a lot of plausible code and a product you don't understand. Used well, they compress the boring middle of a change so you can spend time on architecture and taste.

What I actually automate

  • First-pass UI in Design Mode when the layout is known and the design tokens already exist.
  • Mechanical migrations: Nest-style module wiring, types, tests that follow a pattern already in the repo.
  • Explaining a legacy path before I touch it — then I still read the path.

What I don't automate: index choice, auth boundaries, data retention, or the last 10% of copy. Those are where products get sued, get slow, or feel cheap.

Multi-agent is a workflow, not a vibe

Splitting "propose a plan / implement / review" across agents only helps if you still own the merge. I treat agent output like a junior PR: assume it's locally correct and globally naive. Then I run the app.

The 70% query win and the CPU drop were not generated insights. They came from EXPLAIN, production metrics, and changing the schema to match the query. Agents can draft the migration. They cannot feel the spike.

The bar is still yours

AI-accelerated execution is real. The resume line is honest. The standard I hold is the same as before: does this hold in production, can the next person read it, and did we measure the thing we claimed to improve?

That's the only way these tools stay an advantage instead of a liability.