AI 正在改變優秀前端工程師的定義

For a long time, being a good frontend engineer meant being really good at writing code. You needed to understand JavaScript, know your frameworks, write clean components, and be able to solve problems without constantly looking things up.

Those things still matter, but I think AI is forcing us to rethink what actually makes an engineer valuable.

We are entering a time where writing code is becoming the easiest part of building software. And I think that should challenge how we approach our work.

Writing Code Is No Longer the Hardest Part

I remember when being able to build something from scratch was a big deal. You had to understand how everything worked, scrub through Stackover, and spend hours figuring out why something was not behaving the way you expected.

Now, I can describe what I want to build, provide some context, and have AI generate a working implementation in minutes.

That is a pretty big shift.

But just because something works does not mean it was built correctly UNLESS we give it that context.

And that is where I think our value as engineers is starting to shift.

We Need to Become Better at Defining What Good Looks Like

I think one of the biggest opportunities for frontend engineers right now is becoming really good at defining expectations.

Not just telling AI what to build, but explaining how something should be built and what makes the implementation acceptable.

That means having clear specifications, established patterns, testing expectations, accessibility standards, and an understanding of how a feature fits into the rest of the application.

For example, asking AI to build a form is easy.

But does that form handle validation correctly? Does it account for loading and error states? Is it accessible? Does it use the components we already have? Does it follow the same data fetching patterns as the rest of our application?

Those are the things that matter.

And those are the things that can easily be overlooked when we become too focused on how quickly something gets built.

I think we should spend more time defining what good looks like before we ever start writing code.

Staying Close to the Code Still Matters

One thing I do not agree with is the idea that engineers no longer need to understand code because AI can write it for them.

I actually think the opposite.

The more code AI writes, the more important it becomes for us to understand what is happening.

You cannot properly review something you do not understand. You cannot identify a bad architectural decision if you do not understand the architecture. And you cannot confidently approve an implementation just because the application appears to work.

Being close to the code does not mean you have to personally write every line.

It means understanding the system well enough to recognize when something does not belong.

I want to be able to look at an implementation and understand why certain decisions were made, what could potentially break, and whether the solution makes sense for the application we are building.

AI should make us faster, but it should not make us disconnected.

Our Codebase Should Be Able to Explain Itself

This is something I have been thinking about more lately.

What if we approached our codebases with the expectation that any engineer or AI should be able to contribute without compromising the quality of the application?

Not because everyone has the same level of experience, but because the codebase has clear expectations.

Imagine having documented architectural decisions, reusable patterns, feature specifications, and testing standards that make it easy to understand how things should be done.

When someone introduces a new feature, they should not have to guess how state is managed, how components are structured, or how errors should be handled.

Those decisions should already have some level of consistency.

And when AI is introduced into that workflow, those same standards should apply.

I think that is a much better use of our experience than repeatedly correcting the same mistakes in pull requests.

Instead of just reviewing code for what is wrong, we should be building systems that make it harder to get things wrong in the first place.

Of course, no amount of documentation or testing will guarantee a bug free application. But we can absolutely reduce the number of avoidable mistakes.

Specs Might Become More Valuable Than Implementations

I have started thinking about how much time we spend explaining what we want after something has already been built.

We review a pull request and realize the implementation missed an important state. We discover that a component does not follow an existing pattern. Or we find out that the original requirements were never clear enough.

Then we spend more time going back and correcting those things.

What if we moved more of that effort to the beginning?

Before building a feature, we could define how it should behave, what scenarios it needs to support, what existing patterns it should follow, and how we will know it works.

That specification becomes something both an engineer and AI can work from.

And more importantly, something we can validate against.

What I imagine is like unit tests, we have spec files that ensure the AI that is reading the codebase understands what feature/bug was already implemented and can never be altered for that feature/bug to stay in tact becomes where a lot of the codebase value will live. If we can clearly define expected behavior, we can build tests that help protect that behavior regardless of who or what writes the implementation.

The goal should not be to generate more code.

The goal should be to deliver working software that continues to work as the application grows.

Experience Will Be Measured by the Problems We Prevent

Something else I think AI is going to challenge is how we recognize engineering experience.

For years, we have associated seniority with technical knowledge and the ability to solve difficult implementation problems.

And while those things still matter, I think there is another level of value that deserves more attention.

The ability to prevent problems before they happen.

A good engineer can fix a bug.

An experienced engineer should also be thinking about why that bug was possible in the first place and what can be done to prevent it from happening again.

That might mean improving a shared component, adding a test, documenting an architectural decision, or changing how we approach feature development.

Those improvements might not be as exciting as shipping a new feature, but they make every feature that comes after it easier to build and maintain.

To me, that is real engineering value.

And with AI increasing the amount of code we can produce, that kind of thinking becomes even more important.

We Should Be Focused on Value, Not Just Output

I think there is a real danger in measuring the success of AI by how much faster we can write code.

If AI helps us produce twice as much code, but we introduce twice as many bugs or create a codebase that becomes harder to maintain, what did we actually gain?

Writing more code has never automatically meant delivering more value.

The value comes from solving the right problems, making good decisions, and building something that people can depend on.

Sometimes that means writing less code.

Sometimes that means spending more time thinking through a specification.

And sometimes that means deciding not to build something at all.

AI gives us an opportunity to spend less time on repetitive implementation work and more time thinking about the actual problems we are trying to solve.

I think we should take advantage of that.

So What Does Being a Good Frontend Engineer Look Like Now?

I do not think the answer is to stop learning how to code.

I also do not think the answer is to reject AI because we want to protect the way we have always worked.

I think the answer is somewhere in the middle.

We should still understand JavaScript, React, browser behavior, performance, accessibility, and the fundamentals that make good frontend engineering possible.

But we should also become better at communicating requirements, defining standards, reviewing decisions, designing systems, and creating environments where quality is repeatable.

The engineers who understand both sides are going to be extremely valuable.

Because at the end of the day, someone still needs to understand what we are building, why we are building it, and whether it was built well.

AI can help us write the code.

But we still have to own the outcome.

One Final Thought

I keep coming back to this question.

If AI can write the same code I can, what value am I bringing to the engineering process that AI cannot provide on its own?

I do not see that as a threat. I see it as a question worth asking ourselves.

Maybe the next evolution of frontend engineering is not about becoming better at writing code faster.

Maybe it is about becoming better at creating the standards, specifications, and systems that allow good software to be built consistently, regardless of who or what is writing the code.

And maybe that is where we should have been focusing our attention all along.

Happy Coding 👍