TL;DR: The thing that finally broke me wasn’t a complex distributed systems problem — it was writing my fourteenth handleSubmit function of the month. Same shape, same validation logic, same error state wiring, same loading spinner toggle.
📖 Reading time: ~28 min
What’s in this article
- The Problem: You’re Spending More Time on Boilerplate Than on Actual Engineering
- What ‘Vibe Coding’ Actually Means in Practice (Not the Twitter Definition)
- The Tools I’m Actually Using and How They Differ
- Setting Up Cursor for a Real Web Project — Commands and Config
- Project Conventions
- Code Style
- What to Avoid
- The 3 Workflow Patterns That Actually Work in Modern Web Dev
The Problem: You’re Spending More Time on Boilerplate Than on Actual Engineering
The thing that finally broke me wasn’t a complex distributed systems problem — it was writing my fourteenth handleSubmit function of the month. Same shape, same validation logic, same error state wiring, same loading spinner toggle. I could type it in my sleep, which is exactly the problem. That’s not engineering. That’s data entry with a fancier keyboard.
Most senior devs I talk to aren’t blocked on architecture. They’re bleeding hours on the stuff that’s technically correct to write by hand but genuinely doesn’t require thought. Specifically:
- Form validation schemas — you know Zod or Yup’s API cold, but you’re still typing out
.string().min(1).email() chains for every new model
- API wiring — the fetch wrapper, the loading/error/success state, the TypeScript interface that mirrors your backend response
- CSS that “almost works” — you know what you want visually, but you’re bikeshedding
align-items vs justify-content for 20 minutes
- Tests for deterministic code — writing a test for a pure utility function you already know is correct feels like filing paperwork
What changed around 2023 wasn’t the AI getting smarter at autocomplete — it was the shift to conversational context. GitHub Copilot in 2022 would complete a line. Claude or GPT-4 in 2024 lets you say “here’s my Prisma schema and my Express router pattern, generate me a full CRUD module that matches” — and it generates something you’d actually commit with minor edits. That’s a different category of tool. The context window going from 4K to 100K+ tokens is what made this real. You can paste your entire existing codebase pattern and get output that fits.
The honest framing here is that vibe coding isn’t some mystical new paradigm. It’s stop typing the same scaffolding for the fortieth time and start spending your brain cycles on the 20% of the codebase that actually requires judgment — the data model decisions, the caching strategy, the component API design that your team will live with for three years. I’ve watched junior devs who lean into this workflow ship features faster than seniors who refuse it, not because the AI is writing better code, but because the junior isn’t precious about who typed the boilerplate.
The cost of ignoring this shift is real and measurable on your own calendar. Pull up last week’s commits and honestly count how many lines you typed versus how many lines you decided. If that ratio isn’t heavily skewed toward decisions, you have a workflow problem. For teams evaluating their whole toolchain alongside this, see our guide on Essential SaaS Tools for Small Business in 2026 — the toolchain conversation and the AI workflow conversation are increasingly the same conversation.
What ‘Vibe Coding’ Actually Means in Practice (Not the Twitter Definition)
Karpathy’s original framing was almost offhand — describe what you want, skip the implementation details, let the model figure out the mechanics. That sounds great on a slide deck. The friction shows up around day two when you’re mid-feature and the AI confidently scaffolds a component using next/router instead of next/navigation, because it hasn’t internalized that your app targets Next.js 14 with the App Router. It’s not stupid, it just doesn’t know what it doesn’t know about your specific project.
The spectrum is real and worth being honest about. On one end you have fully vibing — paste a rough description, accept whatever ships, move on. This works surprisingly well for throwaway scripts, one-off data transforms, or boilerplate you’ve written 40 times before. On the other end is co-piloting: you design the data flow, you write the types, you make the architectural calls — and you use the AI to fill the implementation gaps you find tedious. Most experienced developers I know land firmly in co-pilot territory. They’re not too proud to use AI, but they’ve been burned enough times to know that handing over the wheel entirely produces code that looks correct until you read it carefully.
The failure modes of pure vibe coding are specific and predictable. Hallucinated package versions are probably the most annoying — asking for an implementation and getting back code that imports from a version of a library that had a completely different API surface, or worse, a package that doesn’t exist at all. The deeper problem is that the AI has zero awareness of your existing conventions. If your codebase uses Zod for runtime validation in a specific way, or you’ve standardized on React Query v5’s new useMutation signature, the AI will happily write valid-looking code that is stylistically alien to everything around it. Security blind spots are the scariest part: I’ve seen AI-generated API routes that skip auth checks because the prompt didn’t explicitly mention them, and the code passes a casual review.
Here’s what actually works: ground the prompt in your own codebase. The difference between a useless AI response and a useful one is often just specificity about what already exists.
// Prompt that actually produces usable output:
"Add optimistic UI updates to the removeFromWishlist mutation
in WishlistButton.tsx. Use the same pattern as useCartUpdate.ts —
the QueryClient.setQueryData approach with a rollback in onError.
The wishlist query key format is ['wishlist', userId]."
That prompt works because it eliminates ambiguity. You’re not asking the AI to invent a pattern — you’re asking it to replicate one it can read. The output slots into your codebase without a refactor pass. Contrast that with “add optimistic updates to my wishlist” which will produce generic React Query docs-style code that ignores your actual query key structure, your error handling conventions, and whatever abstraction layer you’ve built on top of useMutation. The mental model shift is: you’re not delegating thinking, you’re delegating typing.
The Tools I’m Actually Using and How They Differ
The thing that actually convinced me to ditch VS Code after four years wasn’t some blog post — it was watching Cursor’s Tab completion finish a function I hadn’t typed yet in a way that matched the exact pattern already in my codebase. Copilot suggests completions based on what you’re typing. Cursor’s Tab predicts your next edit — including jumping across lines, renaming a variable you haven’t touched yet, and continuing a refactor mid-stream. Those are genuinely different behaviors, not marketing copy. After a month you stop noticing it and start feeling annoyed when you open any other editor.
The feature I use more than anything else is the Composer panel — Cmd+Shift+I — which lets you describe a change and have it execute across multiple files simultaneously. I asked it to “add rate limiting middleware to every Express route file and update the corresponding test files to mock the limiter” and it opened diffs across six files at once. It gets it wrong maybe 30% of the time on complex tasks, but that’s still dramatically faster than doing it by hand. What makes Cursor actually trustworthy for team projects is the .cursorrules file you drop in the repo root:
# .cursorrules
- Always use named exports, never default exports
- Database queries go in /lib/db/*.ts, never in route handlers
- Use zod for all input validation — import from '@/lib/validators'
- Error responses must use the AppError class from '@/lib/errors'
- Never use `any` type — use `unknown` and narrow it
These rules get injected into every prompt automatically. New devs on the team get guardrails without a code review lecture. That’s the real unlock for team adoption.
GitHub Copilot is still the default everywhere because most teams won’t ask developers to install a new editor, and honestly, for one specific workflow it’s still better: inline suggestions while you’re actively typing in a file you’ve had open for a while. Copilot builds decent short-term context from your open tabs and its suggestions feel less disruptive than Cursor’s sometimes-aggressive Tab rewrites. Where it falls apart completely is cross-file understanding. Paste a function call in one file and ask Copilot to implement the function it’s calling — it’ll invent an API that has nothing to do with your actual types. Cursor handles this because it indexes your whole project. Copilot is working from a glorified sliding window.
Windsurf shipped their “Cascade” agentic flow and I ran it for three weeks on a real project. The difference from Cursor’s Composer is that Windsurf’s agent will autonomously run terminal commands, read the output, adjust, and loop — without you clicking “run” each time. I had it scaffold a Next.js API route, run the test suite, read the failure output, fix the test, and re-run — all from one prompt. That feels qualitatively different from Cursor. The honest downside: Windsurf’s indexing is slower on large repos and I hit moments where it lost track of context mid-task and started inventing file paths. Still, it’s free at the base tier in a way Cursor’s $20/month isn’t, which matters for solo projects.
I stopped using Claude for code generation and started using it for architecture conversations, which is where it’s genuinely dangerous-good. My actual workflow: paste the full Postgres schema, paste the relevant API surface, then ask something like “if read traffic on this table spikes 10x, where does this design break and what’s the cheapest fix that doesn’t require schema migrations?” The answer is usually three paragraphs that save me from a 2am incident. Claude 3.5 Sonnet via the API handles 200K token context, so I can feed it an entire module and ask about edge cases. I pipe it through a small script so I’m not copying files manually:
cat schema.sql src/lib/db/*.ts |
npx claude-cli --model claude-3-5-sonnet-20241022
--prompt "Find any N+1 query patterns and explain the fix"
ChatGPT-4o fills a specific and humble niche in my workflow: rubber-duck debugging under time pressure. You paste a stack trace at 11pm, you get a plausible hypothesis in 10 seconds. It’s not always right — maybe 60% hit rate on novel errors — but the wrong answers usually still point you toward the right search terms. I don’t use it for architecture or multi-file changes anymore. It confidently hallucinates module APIs in ways Claude and Cursor don’t, probably because its training cutoff means it’s working from older package versions. Treat it as a fast first guess, not a ground truth.
Setting Up Cursor for a Real Web Project — Commands and Config
The First Thing You Should Change After Installing Cursor
Default model is gpt-4o. For everyday autocomplete that’s fine. But the moment you ask it to refactor a 300-line server action, extract a custom hook from tangled component state, or rewrite your API layer to use a new pattern — switch to claude-3-5-sonnet. I made this change after watching GPT-4o confidently introduce three subtle type errors during a refactor that Claude caught and fixed in the same prompt. Go to Cursor > Settings > Models, enable Claude 3.5 Sonnet, and set it as default for Composer. Keep a faster model for autocomplete if you want to save tokens.
The .cursorrules File Is Your Linting Layer for AI
Without a .cursorrules file, Cursor has no idea your team uses kebab-case for component files, or that you never use default exports, or that all server-only code lives in /lib/server/. Every suggestion it makes pulls from generic TypeScript patterns it was trained on. Here’s an actual rules file I use for Next.js 14 + TypeScript + Tailwind projects:
# .cursorrules
You are an expert in Next.js 14 App Router, TypeScript, and Tailwind CSS.
## Project Conventions
- Component files use PascalCase: `UserProfileCard.tsx`
- Utility files use kebab-case: `format-date.ts`
- All components are named exports, never default exports
- Server Components are the default; add "use client" only when required
- Tailwind only — no inline styles, no CSS modules
- All API calls go through `/lib/server/` — never fetch directly in components
- Types live in `/types/` as named exports, never inline in components
- zod schemas live next to the route handler that uses them
## Code Style
- Prefer `const` arrow functions for components: `const UserCard = () => {}`
- Use `type` not `interface` unless you need declaration merging
- Error handling: always use Result pattern or typed error returns
- No `any`. If you're tempted, use `unknown` and narrow it.
## What to Avoid
- Don't suggest React.FC — use explicit return types
- Don't use `useEffect` for data fetching — use Server Components or SWR
- Don't wrap everything in try/catch — let errors bubble to error.tsx
The impact is immediate. Cursor stops suggesting export default, stops wrapping fetch calls in components, and starts matching your actual codebase patterns instead of StackOverflow circa 2022.
Composer vs Chat — You’re Probably Using the Wrong One
Cmd+I opens Composer. Cmd+L opens Chat. These are not interchangeable. Composer is a multi-file editor — it diffs changes across files, creates new files, and applies edits directly to your codebase. Chat is a conversation panel that explains, answers questions, and generates snippets you copy manually. The thing that trips everyone up: Chat can look like it’s making changes when it’s just showing you code blocks. I’ve watched developers copy-paste from Chat for twenty minutes when they could have used Composer to apply the same refactor in two. Rule of thumb — if you’re about to copy something from Chat into a file, stop and open Composer instead.
Composer also handles multi-file context better. You can reference @UserCard.tsx and @types/user.ts in the same Composer prompt and it’ll update both consistently. Chat will hallucinate the relationship between them because it’s stateless per message.
@codebase Indexing — What It Actually Does and Where It Breaks
When you first open a project and run @codebase in a prompt, Cursor indexes your repo using embeddings. On a ~50k line repo expect 3-5 minutes the first time. It watches for file changes after that and updates incrementally, which is fast. The gotcha that burned me: it respects your .gitignore. That sounds right until you realize your .env.local, your local seed data files, and any *.local.* patterns you’ve excluded from git are also invisible to the index. Cursor won’t know your environment variable names, won’t know what database URL structure you’re using, nothing.
The workaround is to manually reference those files in your prompt with @.env.local when relevant — Cursor can read files you explicitly mention even if they’re not indexed. For env vars specifically, I keep a .env.example committed with real key names (not values), and Cursor picks that up fine through normal indexing.
When Indexing Stalls and How to Force It
You’ll know indexing is stuck when the status bar shows “Indexing…” for more than ten minutes on a mid-size repo, or when @codebase returns results that clearly predate your last refactor. The terminal output from Cursor’s background process looks like this:
# Check Cursor's indexing log on macOS
tail -f ~/Library/Logs/Cursor/main.log | grep -i index
# You'll see something like:
[IndexService] Indexing stalled at chunk 847/2341
[IndexService] Retrying chunk 847...
[IndexService] Retrying chunk 847...
Force a full reindex by opening the Command Palette (Cmd+Shift+P) and running “Cursor: Resync Index”. If that doesn’t unstick it, the nuclear option:
# macOS — wipe the index cache and restart
rm -rf ~/Library/Application Support/Cursor/User/workspaceStorage/*/index
# Then restart Cursor — it will rebuild from scratch
The stalling usually happens on repos with large generated files — package-lock.json, auto-generated GraphQL types, or .next/ build artifacts. Add those to a .cursorignore file in your project root (same syntax as .gitignore), and indexing becomes reliable. The .cursorignore file is separate from .gitignore — Cursor respects both, but only .cursorignore is specifically for controlling what the AI sees.
The 3 Workflow Patterns That Actually Work in Modern Web Dev
The difference between vibe coding that ships and vibe coding that creates a mess isn’t the AI model you’re using — it’s whether you have a repeatable system for how you engage with it. I’ve watched developers waste hours tweaking prompts when the real fix was changing the shape of the workflow entirely. Here are three patterns that consistently produce usable output.
Pattern 1 — Spec-Then-Generate
Before you ask the AI to write anything, write the contract yourself. A detailed JSDoc block with explicit input types, expected outputs, and edge cases forces you to think through the problem first — and it gives the AI actual constraints to work against instead of vibing into a guess. The review step matters too: you’re reviewing the diff, not the prompt. If the generated code diverges from the spec you wrote, that’s a signal the spec was ambiguous, not that you need a better prompt.
/**
* Parses a JWT and returns the payload if valid.
*
* @param token - Raw JWT string from Authorization header
* @param secret - HMAC-SHA256 secret used during signing
* @returns Decoded payload object on success
* @throws {TokenExpiredError} if `exp` claim is in the past
* @throws {InvalidTokenError} if signature verification fails or token is malformed
* @example
* parseToken('eyJ...', process.env.JWT_SECRET) // => { userId: '123', role: 'admin' }
* parseToken('expired_token', secret) // throws TokenExpiredError
*/
Paste that block into Cursor or Copilot Chat, say “implement this,” and the output is dramatically more predictable than “write a JWT parser.” The spec also survives the AI output — if the implementation gets refactored later, the contract comment is still there documenting what the function is supposed to do.
Pattern 2 — Test-First Vibing
This is the only workflow pattern where I’d call vibe coding genuinely rigorous. Write the test file with explicit behavior descriptions before any implementation exists, then ask the AI to write the function that makes the tests pass. The test file becomes your spec, your prompt, and your validation layer simultaneously. The AI has a concrete pass/fail oracle instead of your subjective approval.
// auth.test.ts — write this BEFORE asking for the implementation
describe('validateAuthToken', () => {
it('should return 401 when token is expired', async () => {
const expiredToken = sign({ userId: '1' }, SECRET, { expiresIn: '-1s' })
const result = await validateAuthToken(expiredToken)
expect(result.status).toBe(401)
expect(result.error).toBe('TOKEN_EXPIRED')
})
it('should return 403 when token has wrong signature', async () => {
const tamperedToken = sign({ userId: '1' }, 'wrong-secret')
const result = await validateAuthToken(tamperedToken)
expect(result.status).toBe(403)
})
it('should return the decoded payload on valid token', async () => {
const token = sign({ userId: '42', role: 'admin' }, SECRET, { expiresIn: '1h' })
const result = await validateAuthToken(token)
expect(result.payload?.userId).toBe('42')
})
})
Now you can literally paste this into Copilot Chat and say “implement validateAuthToken to make these pass.” The output is constrained by real assertions. When the AI hallucinates a return shape, the test catches it immediately. You’re not reading AI output hoping it looks right — you’re running npx vitest and watching green/red.
Pattern 3 — Refactor With Context
Generic refactor prompts are almost useless. “Make this better,” “clean this up,” “improve error handling” — these produce cosmetic changes that ignore your actual codebase conventions. The refactor pattern that works is: existing code + the pattern you want to match + one concrete example of the target pattern. You’re not asking the AI to invent a style, you’re asking it to recognize and apply an existing one.
// Prompt structure that actually works:
// 1. Here is the function I want to refactor [paste fetchUserData.ts]
// 2. Here is the pattern I want it to match [paste authFetch.ts]
// 3. "Refactor fetchUserData to use the same error handling pattern as authFetch,
// including the structured error object shape and the retry logic on 503s"
The concrete example in authFetch.ts does the heavy lifting. The AI can see the exact error object shape, the retry delay you’re using, whether you’re throwing or returning error states. “Refactor this fetch wrapper to use the same error handling as authFetch.ts” will outperform “add better error handling” every single time — and the gap widens the more opinionated your codebase already is. If you’ve built consistent patterns across 20 files, the AI can learn your conventions from one example and propagate them. That’s the actual use point.
Where Vibe Coding Breaks Down — The Rough Edges I’ve Hit
The hallucinated API problem is more subtle than people think. It’s not that Copilot invents completely fictional libraries — it’s that it invents plausible methods on real APIs. I had a colleague who got a suggestion for router.prefetch() in the Next.js App Router. That method exists in the Pages Router. The App Router dropped it. The code compiled, passed linting, and made it to code review before anyone caught it. That’s the dangerous class: not obviously broken, just quietly wrong. The fix I’ve started using is treating any method I didn’t already know existed as unverified until I find it in the official docs.
Auth bugs from AI generation deserve their own category. I reviewed a PR where the AI-generated middleware checked permissions before verifying the JWT signature. It worked — authenticated users got the right access — but the ordering meant a malformed token with a valid user ID embedded could, depending on the decode step, slip past the signature check and hit the permission layer. The kind of bug you miss when you’re reading fast and the logic looks right structurally. The fix isn’t to stop using AI for auth code; it’s to have a checklist: verify signature → decode claims → check expiry → then check permissions. If the generated code doesn’t follow that order, reject it regardless of whether it “works”.
// This is the wrong order — AI generated this and it "works" in happy path
const middleware = async (req) => {
const decoded = jwt.decode(req.headers.authorization); // decode WITHOUT verify
if (!hasPermission(decoded.role, req.path)) return 403;
jwt.verify(req.headers.authorization, SECRET); // verify happens too late
};
// Correct order
const middleware = async (req) => {
const decoded = jwt.verify(req.headers.authorization, SECRET); // throws if invalid
if (!hasPermission(decoded.role, req.path)) return 403;
};
Cursor starts losing coherence on files past roughly 800 lines in my experience — the suggestions stop fitting the established patterns in the file, and it starts generating code that conflicts with things defined 600 lines up. The irony is that the correct fix (split your files) is good practice anyway, but the limitation forces you into it rather than you choosing it for good reasons. I’ve seen codebases where someone kept a 1500-line component together because “it’s all one feature” and the AI-assisted edits near the bottom were functionally unaware of the state management at the top. The context window is a hard ceiling, not a soft suggestion.
The generated test problem is one I feel strongly about. Vibe coding tends to produce tests that verify what the code does, not what the feature should do. I had a utility function that sorted items by date — the AI wrote a test that asserted the output matched a hardcoded sorted array. I refactored the sort (same behavior, different implementation) and the test broke. I fixed the test to match the new implementation. Then a bug crept in where null dates caused items to float to the top. Both versions of the test would have passed. A behavior-driven test — “items with null dates should appear last” — would have caught it. The tell is when every test reads like expect(fn(input)).toEqual(knownOutput) with no assertion about why that output is correct.
The “yes-and” problem is the one that worries me most architecturally. Ask an AI to implement infinite scroll on a page that already has server-side pagination, and it will give you working infinite scroll code. It will not say “these two patterns are going to conflict when the user hits the back button.” Ask it to add a feature that requires duplicating state across three components, and it will cheerfully duplicate the state. It has no skin in the game for what the codebase looks like in six months. I’ve started treating AI suggestions the way I treat a very fast junior dev: impressive output velocity, needs explicit architectural guardrails, won’t volunteer that the approach itself is the problem.
Vibe Coding vs Traditional Workflow: When to Use Which
The thing that took me longest to internalize: this isn’t a question of “is AI-assisted coding good or bad?” It’s a question of blast radius. How bad is the worst-case output from this particular prompt, and can I catch it in review? That mental model changed how I use these tools entirely.
Where Vibe Coding Actually Earns Its Place
I reach for AI-assisted generation without hesitation in four situations. First, scaffolding new routes — give it your Express or Hono router structure and ask for a new resource endpoint. The output is boring, predictable, and easy to scan. Second, repetitive adapters — if you’re mapping a third-party API response shape to your internal types and you’ve already written two of them, the third one is pure pattern-matching that an LLM handles better than I do at 4pm. Third, translating a Figma description into Tailwind components. Something like “a card with a gray-100 background, 16px padding, a bold heading, and a muted subtext line” produces usable JSX in seconds. The output is visual — you either see it render correctly or you don’t, which makes review fast. Fourth, first-pass test coverage. Skeleton test files with describe blocks and happy-path assertions get you 60% of the way there. You still write the edge cases yourself, but the scaffolding grunt work is gone.
# Fast scaffold: new route + basic tests in one shot
# Works well because the expected structure is narrow and reviewable
prompt: "Generate an Express router for GET /users/:id and POST /users.
Use async/await, return 404 with {error: 'not found'} if missing,
validate req.body with zod. Add jest tests for both routes using supertest."
Hard No’s — and Why Each One Specifically
Authentication flows without a security review are the obvious one, but I want to be specific about why. LLMs will generate JWT handling that looks correct and has subtle issues — signing with HS256 when your threat model needs RS256, forgetting to validate aud and iss claims, storing tokens in localStorage without flagging the XSS risk. It looks complete. That’s the danger. Database migration scripts on production schemas are a harder no — the model doesn’t know your actual row counts, your index usage patterns, or whether that column you’re dropping is still referenced by a stored procedure from 2019. I’ve seen generated migrations that would lock a table with 50M rows for 8 minutes. Anything touching payment processing: Stripe’s API is well-documented enough that the generated code often works — right up until it doesn’t handle a webhook idempotency edge case and you double-charge someone. Performance-critical hot paths are the last one. An LLM will give you readable, correct, O(n²) code when you needed O(n log n). It won’t profile it first.
The Team Size Variable Changes Everything
Solo project on a deadline? My acceptable quality threshold is significantly lower. I’m the only reviewer, I know the full context, and I’m moving fast. If I ship a slightly awkward abstraction that I can refactor in a week, that’s fine. The moment three other engineers are maintaining that code, the calculus flips. They don’t have the context of your original prompt. They’re going to read that generated adapter at 9am and try to extend it, and if the AI wrote something that’s technically functional but idiomatically weird — unusual variable names, inconsistent error handling patterns, a control flow that’s hard to follow — you’ve just created a maintenance tax that compounds. I apply much stricter review to anything that hits a shared codebase. Generated code for a shared repo should be indistinguishable from handwritten code after editing, not “good enough to ship.”
The Two-Minute Review Heuristic
My personal filter before committing any AI-generated output: can I fully review it in under two minutes, and do I understand every line? Both conditions have to be true. If I’m reading a 40-line function and I hit a section where I think “this looks right, I’ll trust it” — that’s the problem surfacing. I don’t actually understand it. I’m pattern-matching on the syntax looking correct. The two-minute limit isn’t arbitrary either; it forces the scope to stay small. If a single generated output takes longer than that to verify, it’s too large a chunk and I should have prompted for smaller pieces. The inverse — output I understand completely but can’t review fast because it’s complex — means I should have written it myself, because I clearly have the mental model for it already.
- Safe to ship: You can explain every branch to a colleague without re-reading it
- Needs editing: You understand it but the style doesn’t match the codebase conventions
- Rewrite it: You’re trusting the output without being able to defend each line
Honest Take on How This Changes the Senior/Junior Dynamic
The thing that catches junior devs off guard isn’t that AI writes bad code — it’s that AI writes plausible bad code. It compiles, the tests pass if you didn’t write them carefully, and it ships. Then at 2am something breaks in a way that requires understanding what a database transaction actually does, why a race condition exists between two async calls, or what “event loop starvation” means in practice. The AI can’t be paged. You are. And if you’ve been copy-pasting generated code for six months without building the mental model underneath it, that 2am incident is going to be brutal.
I’ve watched this pattern play out specifically with error handling. AI-generated code tends to swallow exceptions or re-throw them in ways that make tracing a production issue genuinely hard. A junior who understood try/catch semantics would catch it in review. A junior who vibe-coded their way through onboarding will spend three hours staring at a Datadog trace wondering why the stack is empty. The fundamentals aren’t less important now — they’re the thing that separates someone who uses AI productively from someone who uses AI as a liability generator.
Senior devs who’ve adapted well aren’t writing more code — they’re doing better work on the stuff that was always getting squeezed out. System design conversations that used to get rushed because of sprint pressure. Code reviews where they actually explain why an architectural choice is wrong, not just flag it and move on. The judgment calls: “Yes the AI’s solution works but it introduces a pattern that will be a nightmare when we need to scale this across tenants.” That kind of review is worth more now because the raw code-writing bottleneck is gone, and someone has to hold the architectural coherence together.
Onboarding has gotten genuinely faster for feature scaffolding and genuinely worse for understanding. A new hire can have a CRUD endpoint running in 40 minutes using AI assistance. But they won’t understand why your team chose optimistic locking over pessimistic locking in that service, why there’s a custom middleware wrapping every authenticated route, or why the data model has that weird denormalized column that exists for a historical performance reason. That context lives in senior devs’ heads and in Slack threads from 18 months ago. Mentorship on the why of a codebase hasn’t been automated. If anything it matters more now because the new hire will confidently regenerate something that breaks your implicit contracts without realizing it.
The skill I’ve watched become a genuine differentiator is specification writing. The developers who get the best output from AI are the ones who write prompts that read like RFC documents — they specify the inputs, the edge cases, the failure modes, the performance constraints, and the interface contract before asking for an implementation. That’s not a new skill. That’s exactly what you need to write a good tech spec, a good ticket, or a good docstring. If you were sloppy about specifying requirements before, AI just amplifies that sloppiness into generated code you now have to own. The developers who were already rigorous about articulating what they wanted before building it? They got a massive productivity multiplier. Everyone else is generating technical debt at scale.
# The difference between a bad prompt and a useful one:
# Bad:
"Write a function to handle user authentication"
# Useful:
"""
Write a Python function `authenticate_user(email: str, password: str) -> AuthResult`
- Uses bcrypt for password comparison (never plaintext equality)
- Returns AuthResult(success=False, error="invalid_credentials") for BOTH
bad email AND bad password — no user enumeration
- Raises ValueError if email format is invalid (not just empty)
- Locks account after 5 failed attempts within 15 minutes (use Redis for this,
key: f"auth_failures:{email}", TTL 900s)
- Must complete in under 200ms p95; the bcrypt work factor is already set to 12
"""
The output quality difference between those two prompts isn’t marginal — it’s the difference between code you have to throw away and code you have to review. Writing the second prompt requires you to already know what good authentication looks like. That knowledge still has to come from somewhere, and right now it’s coming from the seniors who built enough systems to know what goes wrong.
Disclaimer: This article is for informational purposes only. The views and opinions expressed are those of the author(s) and do not necessarily reflect the official policy or position of Sonic Rocket or its affiliates. Always consult with a certified professional before making any financial or technical decisions based on this content.
Originally published on techdigestor.com. Follow for more developer-focused tooling reviews and productivity guides.
