Writing Your Own Code Considered Harmful
In modern, well-structured codebases with decent linting and tests, human-written code is often the weakest link.
Tools like Cursor, properly configured, consistently produce higher-quality code than humans—cleaner, faster, and bug-free. We’ve moved past the age of hero coders and into the era of high-leverage guidance.
The best engineers don’t write code—they steer it.
They shape context, define intent, and curate constraints.
Coding has become a meta-skill: less typing, more thinking.
Your job is to describe problems clearly, not solve them line by line.
Cursor doesn’t replace you—it promotes you.
Welcome to the age of the micro product manager.
> In modern, well-structured codebases with decent linting and tests, human-written code is often the weakest link.
This is a statement written by someone having little work experience. It seems trivially obvious until you get to work and realize what the real problem is: incomplete and/or inconsistent requirements. Close on those heels are poorly documented APIs. Poor architecture and design round at your problems.
Writing the code? That's the easy part. Maybe that's what we should be emphasizing to people wanting to be professional software developers: the code itself has never been the hard part. That's table stakes.
Am I supposed to be impressed that AI has taken the easiest part of code development and has made it a little bit easier? Maybe? Don't forget I still have to create tests because I need evidence the code actually does what it's claimed to do. Which is ironic, because test creation and management is an area software developers really struggle with and now it's more important than ever!
> Humans
Please describe in more specific terms. Are we talking non-technical, intern, junior, or senior experienced humans?
Literally just yesterday I was diverted to help someone who is a senior developer, but a novice in Python itself, figure out why code that AI helped them write was completely busted. They were extra perplexed because most of the code was identical to a block of logic we use today (and works), but in this new context didn’t work at all. Turns out whatever the AI did, it didn’t have a concept of method overloads, so the types being passed around were suddenly wrong.
AI works well for people who know nothing (it can do things for them that work well enough), or people who know ‘everything’ (it can get them 95% of the way, they can use their experience to find and fill the remaining 5%). It’s absolutely terrible for people with middling experience.
interesting
i've been writing code for my employers for the last 10years and i feel liberated
now i almost cheer when the product guys report bugs, mainly pre-llm legacy codebase i slice through like butter
well except on a few rare instances to be fair
i assume it can be counterproductive in the hands of an inexperienced dev?
For context, my experience is colored by the kind of work I do: building codebases from scratch that tackle ‘niche’ (read: not readily available as FOSS or described online) problems, usually in small teams or solo.
For a completely inexperienced dev, they may delegate to having AI draft the entire project for them. If a part doesn’t work, they just keep repeating the prompt until it does. They’re not tweaking and twiddling, so the mindset is ‘if it works then I’m done’.
For an experienced dev, usually they will define a structure and have a clear understanding of what the inputs and outputs of each component are. They’ll also write what are known to be critical code sections themselves. AI is usually used here as they might take advantage of an intern—to do the busy work—and because they have adequate experience it’s fairly trivial to review the code and manually fix problems before adding it to the codebase.
For people in the middle ground, they end up with hybrid of these qualities, and it generally doesn’t turn out well. They might define a structure, but not well enough to know exactly what components to create from an LLM, nor knowledge of which sections need to be done by hand, nor be adept at finding deficiencies in the code they’re given. Because they have the ability to debug, they spend time debugging failures instead of just promoting again, and because they let bad code slip into the codebase failures happen just as often as if done by hand, but with the disadvantage of not having authored the code in the first place.
> Tools like Cursor, properly configured, consistently produce higher-quality code than humans—cleaner, faster, and bug-free.
Just checked my phone. We are still in 2025, not 2035 or further.
> Tools like Cursor, properly configured, consistently produce higher-quality code than humans
This seems very doubtful to me. Do you have evidence?
only anecdotal evidence
with gemini 2.5 pro combined with a good https://docs.cursor.com/context/rules directory i've had consistently impressive quality code,
i spent quite some time crafting the .cursor directory though
i tried to be as exhaustive as possible in capturing the subtleties of our codebase and what our team considers good taste
>> In modern, well-structured codebases with decent linting and tests, human-written code is often the weakest link.
I call BS.
If a human has never written the code, how will AI generate it?
If a human does not know how to verify that code works correctly, how can the code (regardless of who writes it) be verified?
Do you trust AI to write the code that controls the airplane you fly in?
Would you trust your life (literally) to AI-generated code?
Sounds like very generated LinkedIn-ish: no substance, miraculous-PR-like, signs of lack of experience of the promoted solution's limitations in the discourse, and no call to action or discussion.