A senior engineer's honest take on Cursor, Claude Code, and where AI tooling actually pulls weight in production work versus where it gets in the way.
It was a Tuesday morning at the creator-economy platform I worked at. I was three weeks into the branded mobile apps build, working with two other engineers, and the Rails plus Python plus Fastlane plus GitHub Actions pipeline was starting to feel real. Cursor was open on my left monitor. Claude Code was running in a terminal split on the right. I’d just asked it to generate the first cut of a Fastlane lane that ships a creator’s app to the App Store, and the diff looked roughly right. I read it line by line anyway. Two bugs. Fixed them. Shipped the lane behind a feature flag.
That’s the loop. Not magic. Not “AI wrote my app”. Just one more tool in the rotation, sitting next to my tests and my linter.
I’ve been writing software for over a decade and I’ve seen plenty of waves of “this changes everything”. Most of them didn’t. This one is different in a quiet way. AI tooling doesn’t replace the engineer. It compresses the boring parts of the day so the engineer spends more time on the parts that actually matter.
In a typical month I bounce across a lot of repos at the creator platform, and I CTO a few side products in parallel. One is a health and wearables thing. One is an AI music-learning app. One is a community-plus-talent product. Different stacks. Different conventions. No way to keep all that context in my head.
Cursor and Claude Code keep it in theirs.
The way I configure Cursor for this is boring on purpose. Strict TypeScript settings, project-specific rules in .cursorrules, and a model preference that doesn’t auto-apply edits across files.
{
"cursor.cpp.disabledLanguages": [],
"cursor.general.enableLogging": false,
"cursor.cmdk.useThemedDiffBackground": true,
"cursor.composer.autoApplyChanges": false,
"cursor.chat.alwaysShowFullDiff": true,
"editor.formatOnSave": true,
"typescript.tsdk": "node_modules/typescript/lib",
"typescript.preferences.importModuleSpecifier": "non-relative",
"eslint.run": "onType",
"eslint.validate": ["typescript", "typescriptreact"]
}autoApplyChanges: false is the only line that matters. I want to read the diff before it touches a file. That habit caught a Cursor-suggested change last month that would have dropped the locale segment from a cache key. I read it twice. Reverted.
For Claude Code I lean on a tiny CLAUDE.md at the root of each repo and a few project-specific slash commands. The repo-level one tells the agent what stack we use, where the tests live, which lint commands to run, and what’s off-limits. The commands let me automate the verbose stuff.
claude /run-all-tests
claude /security-review
claude /review-backend/run-all-tests is just pnpm test:ci:all in disguise, plus a guard that fails if coverage drops. /security-review reads the diff against main and looks for the usual suspects: leaked secrets, missing input validation, unsafe SQL string interpolation, IDOR-shaped endpoints. /review-backend is the one I lean on hardest. It reads the diff like a staff engineer would and writes the review in Turkish, which keeps me honest because Turkish forces me to slow down and re-read.
Our branded-mobile-app pipeline at the creator platform is the cleanest example I’ve got. We’d been asked to take a manual process owned by a whole mobile-CX team and turn it into a release that ships in five minutes. Apple submission, Google submission, native billing, build signing, the works. Three engineers. Three months.
We used Cursor and Claude Code throughout. Most of the Fastlane glue was AI-generated, then reviewed and re-shaped. The GitHub Actions matrix that fans out across creator apps was mostly hand-written, because the orchestration logic was load-bearing and I wanted to feel every line. Something like this lives in our workflow file:
name: bma-native-release
on:
workflow_dispatch:
inputs:
branded_app_id:
required: true
platform:
required: true
type: choice
options: [ios, android, both]
jobs:
build:
runs-on: macos-14
strategy:
fail-fast: false
matrix:
platform: ${{ fromJSON(inputs.platform == 'both' && '["ios","android"]' || format('["{0}"]', inputs.platform)) }}
steps:
- uses: actions/checkout@v4
- uses: ruby/setup-ruby@v1
with:
bundler-cache: true
- name: Resolve branded config
run: bundle exec rake bma:resolve[${{ inputs.branded_app_id }}]
- name: Build and submit
env:
APPLE_API_KEY_ID: ${{ secrets.APPLE_API_KEY_ID }}
GOOGLE_PLAY_JSON_KEY: ${{ secrets.GOOGLE_PLAY_JSON_KEY }}
run: bundle exec fastlane ${{ matrix.platform }} submitOutcome: release time fell off a cliff. Operational cost dropped meaningfully. Sales picked up once native billing went in. The pipeline replaced a process that used to take a whole team to run. Three engineers built it. AI tooling was part of why.
The piece I keep telling other engineers about is the boring half. We didn’t ship faster because the AI wrote heroic code. We shipped faster because nobody had to context-switch out of Cursor to read 30 pages of Fastlane docs. The cycle from “I think we need a lane that does X” to “here’s a working draft” went from an afternoon to fifteen minutes. That compounds across three months and three engineers.
There are places AI tooling reliably does not help. Production incident diagnosis is the clearest one. When something is visibly broken on a live system, I’ve tried asking Claude Code for the root cause. It produces a great-sounding list of plausible causes ranked by nothing. It doesn’t know which table is hot, which job escaped a maintenance window, or which call in our runbook comes first. That kind of call still needs me.
This is the part that doesn’t fit in a thought leadership tweet. AI compresses code generation, scaffolding, doc reading, and the tedious half of refactors. It does not compress judgment about production. Senior engineering work is still mostly judgment. The tools just give you more reps per day.
The other place I lean on AI tooling hardest is the side products I CTO in parallel with the day job. A wearables thing. An AI music product. A community platform. A logistics-sector hiring product before them. Small teams. No room for a dedicated platform team. AI tooling is how we pretend we have one.
On the wearables side product, the React Native app, the Nest.js backend, the Next.js dashboard, the AWS infra, all of it gets shipped by a tiny team with Cursor and Claude Code in the loop on every PR. CodeRabbit runs the AI review on every pull request and catches the small things before a human reviewer wastes time on them. Devin handles a few autonomous chores. None of these tools replace an engineer. They give a small team the shape of a bigger one for the rote work.
CLAUDE.md per repo is worth more than a clever prompt.Thanks for reading. If you’ve got thoughts, send them my way.