How I write code with Cursor
I do not treat an AI assistant as a magic author. I treat it as a fast, fallible collaborator that only earns trust when the surrounding process is strict.
The default path for non-trivial work looks like this: I decide what is worth building and what “done” means; the assistant proposes and edits code under guardrails; then automated checks and human review decide what lands. That split matters. Strategy stays human. Optimization can be accelerated.
Discipline instead of vibes
Asking a model to “write good code” is unverifiable. Asking it to satisfy a long list of explicit constraints is verifiable. In practice those constraints live in three layers:
- Rules — short must / must-not guardrails that fire continuously (structure, safety, logging, scope).
- Skills — bounded runbooks for recurring jobs (deploy checks, test slices, container commands) with stop conditions when inputs are missing.
- Specialist agents — narrow helpers for debugging, unit runs, or skeptical verification, each with a clear success condition.
For labour-market framing, Cursor 3 plugins, AGENTS.md, spend (Opus vs Auto), Ansible/e2e/flows, and criteria-based testing — without treating the tool as a product pitch — see Cursor 3 in practice.
On top of that sit the ordinary engineering gates: lint, types where they exist, unit tests for pure logic, integration only when wiring is the point, and a smoke check against a running endpoint before calling a change done.
What I refuse
- Drive-by paste — accept a suggestion, skip reading it, commit. That is how “AI coding” earned a bad name.
- AI as a shortcut past thinking — if I have not named the problem, a fluent answer only hides the gap.
- AI as the practitioner — models have no stake. My name is on the commit; I carry the outage.
- Confidence theatre — fluent wrongness is common. The process exists because of that, not despite it.
Learning is still required
AI amplifies expertise and also amplifies its absence. If I cannot evaluate the kind of code the assistant produces, speed is a liability. Hand-writing still matters for learning and for building judgment. What I do not skip is the gate before a change is considered finished: review, tests, and a real runtime check when the surface is public.
Where this shows up on complex development work
The same split applies across Magento / Mage-OS, PLC and process control, complex ERPs, and native apps — anywhere a fluent wrong answer is expensive. The point is not framework trivia (cron wiring, CLI flags, asset renaming). It is orchestration, analysis, and tests: keep strategy, problem framing, and stop conditions human; let assisted execution fill in under constraints; then unit checks for pure logic, integration when wiring is the point, and a real runtime smoke when the surface is public decide what stays. The assistant can draft the patch; the apparatus decides whether it is allowed to stay.
As of October 2026, what felt true a year ago no longer holds. Then the easy story was AI as roughly a 5× boost — write better code faster, same craft, more throughput. That pitch still sells. What it underplays is already visible in the labour market: substitution and deskilling are underway, even when public talk stays quiet. For the political economy of that race — and why ethics without practice is piety, and practice without ethics is capture — see Reading Obsolete: ethics and craft in an AI labour race.
Used this way, Cursor is not a replacement for craft. It is a process-level defect-prevention tool — useful in proportion to the quality of the questions I keep asking after the answers start sounding good enough.
Written with the help of an AI assistant.