wling

Writing code should be a process of understanding, reasoning, and making trade-offs. Copy-pasting tells you 'it works,' but it doesn't tell you 'why.'

The emergence of similar code generation tools like GPT in recent years has had a huge impact on us, affecting every aspect of our lives and even those around us.

Have you noticed—

In the past, when using GPT, we could still learn something, especially when it first came out.
We were all using it with a problem-solving and learning attitude,
checking its thought process, asking questions when we didn’t understand.

Now? Everyone relies on it, copy-pasting.

And then there are so-called Coding Vibe and Coding Agent,
not looking, not modifying, not testing.
If it runs, it goes live, and three months later, you don’t even know what you wrote or the overall structure and package references of the project.

Debugging leaves your mind filled with little question marks:

“Who wrote this **code?”
“Oh my god, it’s GPT.”

I strongly oppose handing all coding work over to GPT.#

Writing code has turned into a process of copying answers; you no longer think.
Understanding requirements? Code design? Project maintainability? You’ve skipped all of these.

It seems highly efficient, but in reality, you are continuously losing your basic judgment and growth space as a programmer.
Writing code is not just about writing; it’s also about learning.

Bugs don’t decrease; they actually become harder to debug.#

The project code you pasted might not have even run through tests.
Why would GPT consider edge cases for you? Why would it care about your project context?
They just need to get the project done and write the code correctly.

The apparent “Wow, the functionality is implemented!”
results in a pile of hidden issues; even if triggered, debugging becomes even harder.
Because this isn’t your code; you don’t understand it at all.
After an error, you have no idea where the problem lies and can only go back to ask GPT
to fix the code it generated itself.

The more you write, the blurrier the code quality and style become.#

Today you paste an asynchronous function, tomorrow an old callback, the day after a strange, more abstract one.
The project looks like a jigsaw puzzle, and maintainers are passionately debugging freestyle.
Every piece of code runs, but no one wants to maintain it.

Outsourcing projects to LLMs, deceiving oneself.#

I still don’t understand why a bunch of people are answering,
“Oh, our Coding AI tool has new features!”
In the past, when it was said that “directly pasting GPT code is harmful,” some people would refute it.

“We are reformists; we have Cursor, Trae, Tongyi, Copilot Chat… full automation for writing projects, automated debugging.”

They claim to pinpoint bugs with one click, but the truth is that the tool takes your error log and constantly guesses your exception sources,
giving you a seemingly good, possibly useful patch.
What happens? Fix A and break B.

Automatic refactoring is not magic.#

So-called refactoring = Find-&-Replace.
It doesn’t understand what the complete testing process of this project looks like, nor does it understand any implicit agreements, often leaving a pile of hidden dangers when merging into old code.

It seems friendly to beginners, completely shielding the learning cost.
Low-threshold usage allows novices to “fix” bugs with a few clicks but without understanding the causes.
The next time they encounter the same problem, they will just rely on tools to put out fires.

Time savings are superficial; the actual cost is high.#

Saving time may be valid in some situations, but what about in the future?
You spend time reading its diffs, running that private regression, and still have to fix new issues.
In the end, the total time often exceeds that of a novice debugging.

Relying on tools ≠ solving problems.#

Now a bunch of people throw out, “Why not just use Cursor?”
This is a conceptual shift; it’s not solving problems but extending dependency from writing code to debugging, with a supercharged dosage.

These tools create pure illusions, leading some novices to believe, “As long as I have Cursor, I don’t need to understand debugging or code; I can also become an engineer.”
When it goes live and issues arise, what should you do as a novice? Keep relying on Cursor?

Short-term progress is rapid, but long-term maintenance feels like hell.
Those chaotic project structures, interface references (even allowing the creation of completely identical interfaces)
Whether in your company’s team collaboration or the open-source community,
the person taking over feels like they are in a mess.
You look at this pile of code; you first have to understand which parts were written by humans and which are AI “seasoning.”
Then you have to roll back or refactor each one.

In short, on top of the already existing “CPDD (Copy-Paste Driven Development)” wound, another layer of so-called “automatic debugging ointment” is applied, causing the code’s genetic mutation to happen faster and making it even less approachable.

Novices: It used to be just “not knowing how to write,” and now it’s bundled with “not knowing how to debug.”
One-click generation + one-click patching = “automatically cruising towards the cliff.”
Novices generate - paste - auto-fix, thinking everything is fine after one round, but they haven’t formed a debugging mindset: setting breakpoints, checking the stack, validating hypotheses…

The larger the project grows, the more hopeless it becomes towards the end.

Final choice: Trust yourself and stay proactive.#

I don’t even have to think; after reading this long rant, looking at those repetitive points, I say “makes sense,” but when it comes time to write features, I still open GPT and LLM without hesitation, continuing to paste and fix.
Pasting a whole new “magic code.”

I have to say I use it too; blindly rejecting new technology isn’t pure **.
But using it with understanding and using it mindlessly are two different outcomes.
You can ask, you can reference, you can even have it help you write tests and document.

But the code in the project must ultimately reflect your own understanding, not GPT’s output ability.

In the end: GPT is not you and will not serve only you.
The person who should write good code is you.
Don’t let tools think for you; otherwise, you will slowly lose your ability to solve problems.
Please trust yourself and stay proactive.

This article is synchronized and updated to xLog by Mix Space.
The original link is https://ling.crashvibe.cn/posts/think/thinking-about-coding-and-the-impact-of-gpt