Engineering culture // the tea
Cursor Brainrot: You’re Not a “Prompt Engineer,” You’re Just Copy-Pasting Until It Works
If your debugging strategy is repeatedly telling the model “bro, same error,” the autocomplete is not the only thing completing a pattern.
00 // The tea
The PR is 4,800 lines. You read twelve of them.
Somewhere right now, a developer has asked an AI assistant to “build the entire authentication system.” The model has responded with seven files, a middleware layer, two database migrations, and a package nobody has heard of. Our hero glances at the green syntax highlighting, experiences a brief spiritual connection with productivity, and opens a pull request titled “auth improvements.”
Respectfully, that is not prompt engineering. That is slot-machine debugging with better autocomplete. The problem is not Cursor, Claude, Copilot, or whichever glowing text box currently lives beside your editor. These tools can be excellent. The problem is treating generated plausibility as verified software—and treating your inability to explain the output as somebody else’s code-review task.
AI assistance compresses typing time. It does not compress the need for architecture, threat modeling, domain knowledge, or ownership. When those skills disappear, the saved keystrokes return later with interest, usually during an incident call at an hour when everyone’s aura is already negative.
The habit is addictive because it produces visible motion. Every prompt creates more code, every retry changes the error, and every green checkmark feels like progress. Understanding is quieter. It looks like reading a library’s documentation, drawing a state transition, deleting an unnecessary dependency, or spending twenty minutes proving the bug is one incorrect assumption. AI brainrot is not “using AI too much.” It is confusing output volume with reduced uncertainty.
01 // Signs your codebase is highkey cooked
The receipts are in the Git history
temp_final_v2_fixed has entered production
Your “small helper” is 300 lines, mutates six outer variables, catches every error, and returns either an object, a string, or vibes.
You installed a hallucinated package
The model invented fast-math-pro-plus to calculate an average. You ran npm install before checking the registry, maintainer, source, downloads, or whether division still exists.
Your prompt history is a hostage negotiation
“Please bro, same error. Fix it properly this time. I’ll tip you $20.” The model does not accept tips. It does accept the same incomplete context for a sixth attempt.
The code review is an archaeological dig
Nobody knows why three abstractions exist, every comment paraphrases the next line, and the author answers questions with “that’s what the AI suggested.”
The fake-package moment is not only comedy. Blindly installing a generated dependency creates a supply-chain decision. Package installation can execute lifecycle scripts with your developer account’s permissions. Before adding anything, verify that the package exists, inspect its ownership and repository, check its release history, understand the license, and ask the deeply unfashionable question: can the standard library already do this?
02 // The AI aura scorecard
Are you the engineer, or merely the model’s emotional-support keyboard?
| Developer action | Aura | Verdict |
|---|---|---|
| Writing the core architecture yourself and using AI for unit tests | +1,000 | Pilot behavior |
| Reading AI output and refactoring it to match the team’s style | +500 | Ownership detected |
| Asking the model to explain tradeoffs before generating code | +350 | Curiosity buff |
| Copy-pasting the same error message back five times | −200 | Context still missing |
| Approving a 2,000-line diff because the tests are green | −600 | Coverage is not comprehension |
| Begging “please” and “thank you” so the LLM does not sabotage you | −800 | Stand up, bruh |
Manners are fine. Fear-based politeness is not a testing strategy. The scorecard’s actual metric is ownership: did you choose the boundaries, verify the behavior, and accept responsibility for the result? A legitimate engineer can use enormous amounts of AI. An AI puppet is defined by the moment judgment leaves the loop.
There is a simple comprehension test. Close the chat panel and explain the change from memory to another developer. Name the data flow, the side effects, the error path, and the reason each new dependency exists. If the explanation collapses into “it basically handles everything,” reopen the diff—not the prompt. Fluency while looking at generated code can feel like knowledge; recall exposes whether the model’s reasoning ever became yours.
03 // Prompt engineering is not software engineering
A beautifully phrased request cannot rescue a missing mental model
Good prompts help. Clear constraints, relevant files, expected behavior, and explicit non-goals reduce ambiguity. But a prompt is not architecture. If you cannot describe where state lives, which component owns a transaction, what failure modes are acceptable, or which trust boundary the request crosses, the model is choosing those things implicitly. It will often choose something locally plausible and globally chaotic.
Copying an error into chat can be useful once. Repeating it without adding observations is ceremonial. Bring new evidence: the smallest reproducer, runtime versions, the exact input, logs around the failure, what changed, and which hypothesis you already falsified. That is debugging. “Try again but be more senior” is fan fiction.
04 // Pilot versus copilot
Delegate motion; retain direction
A copilot can draft, compare, enumerate, and critique. The pilot chooses the destination, understands the aircraft, and remains accountable when the weather changes. In code, that means you define the system’s invariants before asking for implementation. Tell the assistant which files it may touch, which interfaces must remain stable, how errors should surface, and what tests prove the change. Ask for a plan and tradeoffs before a patch.
Excellent copilot work
Boilerplate interfaces, test cases, repetitive adapters, documentation drafts, migration checklists, regex candidates, and explaining unfamiliar code.
Keep your hands here
State ownership, database schemas, authorization, security filters, concurrency, money movement, public APIs, destructive migrations, and incident behavior.
“AI wrote it” is not a waiver. Never accept code you could not explain to a senior engineer during standup: what it does, why this design was chosen, which alternatives were rejected, how it fails, and how you know it works. If the answer is “the model seemed confident,” congratulations—you have discovered confidence theater.
05 // The anti-brainrot workflow
Scope. Ask. Verify. Own.
Scope
Write the requirement, invariants, trust boundaries, and acceptance tests in your own words. Make the change small enough to review.
Ask
Provide relevant context and request options or a plan first. Tell the model what it must not change. Prefer a focused diff over a repo-wide renaissance.
Verify
Read every line. Check APIs and dependencies against primary documentation. Run tests, lint, types, security scans, and a manual unhappy path.
Own
Refactor names and structure into the team’s language. Remove speculative abstractions. Write the PR description yourself and defend the tradeoffs.
Add one final rule: when the assistant fails twice, stop prompting and investigate. Read the stack trace from the bottom, isolate the failing layer, inspect actual values, and consult the documentation. Return to the model with evidence, not desperation. The goal is not to prove you can work without AI. The goal is to ensure AI amplifies a mind that is still actively engineering.
Before opening the pull request, run a tiny ownership gate. Can you summarize the change in three sentences without mentioning the AI? Did you verify every new package and public API? Can you point to a test for the failure path, not only the happy path? Did the diff become smaller after your review? Would you be comfortable carrying the pager for this code tonight? Five honest yeses are worth more than a paragraph describing how “production-ready” the model said it was.
Teams should make this normal rather than shameful. Reviewers can ask for smaller diffs, architectural notes, and evidence without conducting a trial about which tool was used. Junior developers need space to say “I do not understand this generated section yet.” Seniors should model deleting impressive-looking output. The goal is not purity. It is a culture where speed never outranks the ability to reason about what ships.
Use the magic wand. Just remember that somebody still has to know where the wires run, why the database constraint exists, and what happens when the trick catches fire in production. That somebody is you. Huge aura, if true.