Coding 並未消亡，手動輸入程式碼或會變得不再必要

Coding Isn't Dead. Typing Code Might Be.

AI can write your code, review your PR, and suggest improvements. But does it know what your business actually needs?

Remember when writing code was the hard part?

You would spend hours understanding a requirement, designing a solution, writing code, debugging it, and finally raising a pull request.

Today, you can describe a requirement to an AI coding assistant, grab a coffee, and come back to a few hundred lines of beautifully formatted code.

You can even ask another AI to review it.

It might approve the implementation, suggest a few improvements, and congratulate you on a clean solution.

Congratulations! You've just automated coding and reviewing.

But there's a small problem.

Who is making sure the code is actually solving the right problem?

The PR looks perfect. But is it right?

Imagine a business requirement:

"When a device becomes unavailable, update its status on the dashboard."

You ask AI to implement it.

It generates:

A new status management service.
An abstraction layer.
A generic event-processing framework.
Three interfaces.
A configuration mechanism.
A retry strategy.
A factory to construct the handler.

The code is clean. The naming is consistent. The tests pass.

Another AI reviews the PR and finds no major issues.

Everyone is happy.

Except perhaps the original requirement only needed a simple status update in an existing event handler.

Congratulations. You've just introduced a framework to solve a problem that needed five lines of code.

AI can be very good at producing technically reasonable solutions. But technically reasonable and business-correct are not necessarily the same thing.

And that's where engineering knowledge becomes critical.

AI understands code. Engineers must understand intent.

A developer reviewing AI-generated code needs to ask questions that go beyond syntax, formatting, and whether the tests pass.

For example:

1. Does this actually meet the business requirement?

AI may implement exactly what you described, but your prompt might not capture all the domain rules.

Does the status change only under certain conditions? Should an existing state be preserved? Are there business exceptions?

The person approving the PR must understand these expectations.

2. Are we solving the problem or building a solution looking for a problem?

AI often has a tendency to be helpful.

Sometimes a little too helpful.

A simple requirement can turn into multiple abstractions, unnecessary interfaces, additional dependencies, and layers of indirection.

Not every problem needs a design pattern.

Not every repeated line of code needs a reusable framework.

And not every class deserves an interface.

Good engineering is also knowing what NOT to build.

3. Are we introducing problems that the AI review didn't catch?

A solution can compile, pass its unit tests, and still introduce:

Unnecessary database calls.
Race conditions.
Memory leaks.
Incorrect handling of concurrent events.
Unexpected changes to existing behavior.
Performance issues under realistic workloads.

Passing tests is evidence, not a guarantee of correctness.

4. Does this fit the existing system?

AI may suggest an elegant implementation in isolation.

But software doesn't exist in isolation.

It has existing contracts, architectural decisions, dependencies, operational constraints, and sometimes years of accumulated business knowledge.

An implementation that looks perfect in a new file might be completely wrong for the system it is joining.

The PR approval button hasn't become less important

This is perhaps the biggest change I see.

Previously, reviewing a PR involved understanding what another developer had written.

Now, reviewing a PR increasingly means understanding what an AI has generated, why it generated it, and whether the result deserves to exist.

An AI reviewer can tell you that the code follows certain patterns.

It can identify potential bugs.

It can suggest improvements.

But should we blindly trust its approval?

Absolutely not.

The AI reviewer might understand the implementation perfectly and still misunderstand the business.

It doesn't automatically know why a particular exception exists, why a seemingly redundant condition is important, or why a simpler implementation is preferred in a particular domain.

A green AI review is not a business sign-off.

The responsibility for approving the change still belongs to the engineer.

So, is coding becoming less important?

I would argue the opposite.

The mechanics of writing code may become less important.

But understanding code is becoming even more important.

When AI generates 300 lines in seconds, you need enough engineering knowledge to determine whether those 300 lines should exist at all.

You need to understand the language, runtime behavior, data structures, concurrency, architecture, performance, testing, and most importantly, the business domain.

Otherwise, you're not really reviewing code.

You're reviewing something that looks like code and hoping the AI got it right.

The developer of tomorrow

I don't think the future belongs to developers who can type the fastest.

It belongs to engineers who can:

Translate ambiguous business requirements into precise technical solutions.
Give AI the right context and constraints.
Recognize unnecessary complexity.
Challenge generated implementations.
Understand system-wide consequences.
Take ownership of what eventually goes into production.

AI can be your fastest programmer, your tireless pair programmer, and your always-available code reviewer.

But it shouldn't become the final decision-maker.

After all, when something breaks in production, nobody asks whether the AI approved the PR.

They ask who approved the change.

And that person needs to understand what went into production.

Coding isn't dead. Typing code might be becoming optional. Engineering judgment isn't.

Perhaps the most valuable skill in the AI era isn't knowing how to generate code. It's knowing when the generated code is wrong, even when it looks absolutely right.