AI 正在改變軟件開發，最大機遇不在於加快編寫程式碼

AI Is Changing Software Development. The Biggest Opportunity Isn't Writing Code Faster.

The future of software engineering isn't just about what AI can build. It's about what we can accomplish together.

Artificial intelligence is challenging some of the most established practices in software development. We're seeing remarkable advances in how quickly software can be written, tested, and delivered, but I believe the most significant opportunity lies somewhere else entirely.

It's changing how we work together.

Throughout my career, I've seen software organizations invest considerable effort in improving engineering productivity. We've introduced new frameworks, methodologies, automation, and development tools, all with the goal of delivering better software more efficiently. Yet much of the way we organize our teams and move work between disciplines has remained relatively unchanged.

Recently, I've had the opportunity to work with teams embracing AI throughout the product development lifecycle. That experience has reinforced something I've come to appreciate more as an engineering leader: the greatest improvements don't always come from making individuals faster. Sometimes they come from changing how people collaborate.

And I believe AI is giving us an opportunity to rethink that collaboration in a meaningful way.

Rethinking How We Work

For most of my career, software development has followed a relatively familiar process.

Product works with the business to understand a problem and define requirements. UX takes those requirements and creates designs and workflows. Engineering evaluates the designs, considers the technical implications, and begins implementation. Eventually, the feature makes its way through testing and into the hands of our customers.

Of course, that's a simplified view. Good teams have always collaborated across disciplines, and the boundaries have never been quite as rigid as a process diagram might suggest.

But there's something about this approach that has always bothered me.

The waiting.

Waiting for requirements to be completed. Waiting for designs to be approved. Waiting for engineering to implement something tangible enough to evaluate. Waiting for feedback that sometimes sends us right back to where we started.

We spend an enormous amount of time coordinating the movement of work between people who are ultimately trying to accomplish the same thing.

And for a long time, much of that waiting was understandable.

Each discipline brought specialized skills and tools to the process. Creating a working prototype required engineering effort. Exploring an alternative user experience could mean another round of design work. Testing an idea often meant committing time and resources before we knew whether it was worth pursuing.

AI is beginning to change those constraints.

Today, a product manager can explore an idea through a working prototype. A UX designer can experiment with actual interactions rather than relying entirely on static representations. An engineer can evaluate different approaches without investing days in exploratory implementation.

That doesn't mean everyone suddenly possesses the same expertise.

It means the barriers that once prevented people from contributing at different stages of development are becoming less significant.

And if those barriers are changing, shouldn't we be questioning the process we've built around them?

From Handoffs to Collaboration

One of the things I've found most exciting about AI-assisted development is what happens when you bring people from different disciplines together around a customer problem and give them the ability to explore solutions collaboratively.

Rather than beginning with a predetermined set of requirements and moving immediately toward implementation, we can spend more time understanding what we're actually trying to accomplish.

We can bring product, UX, engineering, and other stakeholders into the same conversation, use AI to explore possibilities, challenge assumptions, and turn ideas into something tangible while the discussion is still happening.

And here's where I think things get particularly interesting.

Everyone can participate in creating a solution.

Imagine a product manager who has spent years understanding a customer's frustrations being able to demonstrate an idea rather than simply describe it. Or a UX designer who can explore the nuances of a workflow in a functional prototype, immediately identifying interactions that don't feel quite right.

Engineering can participate in those same conversations, evaluating feasibility, considering architectural implications, and helping shape the solution before anyone has committed to building it.

Instead of waiting for one discipline to finish its work before another can begin, everyone has an opportunity to contribute their expertise to a shared understanding of the problem.

And when multiple ideas emerge, we can evaluate them together.

Sometimes one approach is clearly better. Other times the best solution comes from combining ideas that no single person would have arrived at independently.

The prototypes and experiments don't need to become production software. Their purpose is to help us learn, challenge our assumptions, and determine which direction makes the most sense.

The code may be disposable, but the understanding we've gained isn't.

I think this is an important distinction because the goal isn't to make everyone capable of doing everyone else's job.

It's to make everyone more capable of contributing to the same outcome.

Product still brings a deep understanding of the business and customer. UX still brings expertise in how people interact with technology. Engineering still brings the experience required to turn an idea into something reliable, secure, and maintainable.

Those skills haven't become less important.

If anything, we're creating more opportunities for them to influence the product we're building.

And once we've developed that shared understanding, the benefits carry directly into engineering.

Changing Where We Spend Our Engineering Effort

I've spent a significant part of my career thinking about architecture, engineering practices, and what it takes to build software that can evolve over time.

One thing I've learned is that writing the code is rarely the hardest part of building a successful system.

The difficult decisions usually happen before, during, and sometimes long after implementation.

Understanding the requirements. Choosing an architecture. Evaluating tradeoffs. Anticipating failure. Making sure what we're building will remain maintainable as the needs of the business change.

AI doesn't eliminate those responsibilities.

But it does change how much of our time we can dedicate to them.

As AI agents become increasingly capable of generating implementations, I believe the role of an engineer is shifting toward developing thoughtful specifications, designing systems, and evaluating whether the resulting software meets the expectations we've established.

Instead of spending most of our time translating a well-understood design into code, we have an opportunity to spend more time making sure the design is well understood in the first place.

That means thinking carefully about functional requirements, security, reliability, performance, testing, and the many other considerations that separate a working demonstration from production software.

It also means becoming more deliberate about how we review what AI produces.

An agent can generate a tremendous amount of code in a relatively short period of time. Expecting an engineer to manually inspect every line with the same level of attention isn't necessarily practical, nor is it always the best use of their expertise.

AI-assisted reviews, automated testing, and other validation techniques can help us evaluate implementations and identify potential problems. But we still need experienced engineers making decisions about architecture, critical functionality, security, and the risks that matter most.

The responsibility for the software hasn't changed simply because an agent helped write it.

And that responsibility requires something that can't be measured by how quickly we generate code.

Engineering judgment.

The Importance of Growing Engineers

This is where I think we need to be particularly thoughtful about the future of our profession.

Experienced engineers have an advantage when working with AI, not necessarily because they're better at using the tools, but because they have years of experience to draw from when evaluating the results.

They've built systems that worked and systems that didn't. They've dealt with production failures, changing requirements, unexpected scaling problems, and architectural decisions that seemed reasonable at the time but became difficult to maintain.

Those experiences shape how they think about problems.

They provide the context needed to recognize when a solution is technically correct but fundamentally wrong for the system or customer it's intended to serve.

But that raises an interesting question.

How do we help junior engineers develop that same judgment when AI is increasingly responsible for the implementation work that traditionally helped them learn?

I don't think the answer is to avoid AI or insist that everyone continue writing code the way we always have.

I think the answer is mentorship.

Senior engineers need to lean into teaching good engineering practices. We need to spend time explaining architectural decisions, discussing tradeoffs, challenging assumptions, and helping less experienced developers understand why one approach might be better than another.

And junior engineers need to remain curious.

Just because an agent can produce an implementation doesn't mean we should stop trying to understand it.

Why was this approach chosen? What happens when something fails? What assumptions are we making? How will the system behave when the requirements change?

These questions have always been important. I would argue they're becoming even more important today.

I've always believed that great engineers do more than build great software. They help other engineers become better at their craft.

AI hasn't changed that belief.

It's reinforced it.

And I think the same principle extends beyond engineering to the entire product development team.

If we want people to embrace a more collaborative way of working, we need to help them see how their experience and expertise continue to matter.

Because that's where I believe the real challenge lies.

The Hardest Part Is Changing How We Think

Technology is changing quickly, but people and organizations don't always change at the same pace.

We've spent years developing processes, defining responsibilities, and building careers around the way software has traditionally been delivered.

Product owns the requirements. UX owns the experience. Engineering owns the implementation.

People understand those boundaries, and there's a certain comfort in knowing exactly where your responsibilities begin and end.

When AI starts to blur those lines, it's understandable that people become concerned about what their roles will look like in the future.

I understand that perspective.

But I see it as an opportunity to contribute more value, not less.

Bring your product mind into the discussion when we're exploring a feature. Use your understanding of the customer to challenge whether we're solving the right problem.

Let UX get their hands on working prototypes so they can evaluate the details of an experience and help shape it while there's still time to explore alternatives.

Let engineering participate in those conversations, then apply the discipline and judgment required to turn a promising idea into a reliable product.

We aren't asking people to abandon their expertise.

We're asking them to bring more of it to the table.

And that requires a different way of thinking about productivity.

I'm not particularly interested in how many lines of code an engineer can generate with AI or how many features a team can produce simply because implementation has become faster.

Those metrics might tell us something about output, but they don't necessarily tell us anything about value.

What interests me is whether we're solving better problems, making better decisions, reducing unnecessary rework, and creating experiences that genuinely improve our customers' lives.

We're not trying to do more with less.

We're trying to provide more value by introducing tools that help us accelerate brainstorming, deepen our understanding, and spend less time waiting on one another.

And I think that's a much more exciting goal.

The Future We Choose to Build

The older I get, the more I begin to appreciate the importance of collaboration, teamwork, and having a genuine desire to continue learning and creating.

I've spent much of my career building software, and I understand why some engineers are concerned about what AI means for the profession.

There's something satisfying about crafting code. Finding an elegant solution to a difficult problem, understanding a programming language deeply, or building something from nothing can be incredibly rewarding.

I don't want to dismiss that.

But speaking for myself, I don't believe the code was ever the ultimate goal.

It was the outcome.

The real craft has always been understanding a problem and finding a unique, creative, and thoughtful way to solve it.

Code was the tool we used to bring that solution to life.

And while the tools are changing, I don't believe the reason many of us became engineers has changed nearly as much as we might think.

AI has accelerated my learning and given me opportunities to explore technologies and build things I've wanted to create for years but could never seem to find the time for.

It hasn't made me less interested in engineering.

If anything, it's made me more curious about what's possible.

And I think that's ultimately what this conversation comes down to.

How do we choose to look at the future we're creating?

We could use AI primarily as a way to reduce the number of people required to build software. We could focus on generating more code, producing more features, and delivering more output with fewer engineers.

But I worry that approach risks filling the world with mediocre solutions, built quickly without the thoughtful collaboration and engineering judgment that make software genuinely valuable.

Or we can use AI as an advanced tool for understanding our craft a little better.

We can bring people closer together, give more people the opportunity to explore their ideas, and create an environment where engineers spend more time solving meaningful problems and helping one another grow.

We can make collaboration a central part of development rather than something that happens between handoffs.

We can continue learning, experimenting, and building things that previously seemed out of reach.

I don't believe the future of software engineering should be defined by how much code we can generate or how many tasks we can automate.

I believe it should be defined by the problems we're able to solve, the people we help grow, and the value we create together.

AI is going to change the way we build software.

But the kind of engineering culture we build around it is still very much our decision.

And that's the future I'm excited to help create.