Full-breadth Developers  全方位開發者

The software industry is at an inflection point unlike anything in its brief history. Generative AI is all anyone can talk about. It has rendered entire product categories obsolete and upended the job market. With any economic change of this magnitude, there are bound to be winners and losers. So far, it sure looks like full-breadth developers—people with both technical and product capabilities—stand to gain as clear winners.
軟體產業正處於一個前所未有的轉折點。生成式人工智慧成了人人熱議的話題。它使整個產品類別變得過時，並顛覆了就業市場。面對如此規模的經濟變革，必然會有贏家與輸家。到目前為止，看起來全方位開發者——具備技術與產品能力的人——似乎是明顯的贏家。

What makes me so sure? Because over the past few months, the engineers I know with a lick of product or business sense have been absolutely scorching through backlogs at a dizzying pace. It may not map to any particular splashy innovation or announcement, but everyone agrees generative coding tools crossed a significant capability threshold recently. It's what led me to write this. In just two days, I've completed two months worth of work on Posse Party.
我為什麼這麼確定？因為過去幾個月，我認識的那些稍具產品或商業敏感度的工程師，正以驚人的速度迅速消化積壓的工作。這或許不會對應到任何特別轟動的創新或公告，但大家都同意生成式程式碼工具最近跨越了一個重要的能力門檻。這也是促使我寫下這篇文章的原因。短短兩天內，我完成了 Posse Party 兩個月的工作量。

I did it by providing an exacting vision for the app, by maintaining stringent technical standards, and by letting Claude Code do the rest. If you're able to cram critical thinking, good taste, and strong technical chops into a single brain, these tools hold the potential to unlock incredible productivity. But I don't see how it could scale to multiple people. If you were to split me into two separate humans—Product Justin and Programmer Justin—and ask them to work the same backlog, it would have taken weeks instead of days. The communication cost would simply be too high.
我之所以能做到，是因為我為這個應用程式提供了嚴謹的願景，堅持嚴格的技術標準，然後讓 Claude Code 完成剩下的工作。如果你能將批判性思維、良好的品味和強大的技術能力融入一個大腦，這些工具就有潛力釋放驚人的生產力。但我看不出它如何能擴展到多人協作。如果你把我分成兩個獨立的人——產品 Justin 和程式設計師 Justin——並讓他們處理同一個待辦清單，這將花費數週而非數天。溝通成本實在太高了。

We can't all be winners
我們不可能人人都是贏家

When I step back and look around, however, most of the companies and workers I see are currently on track to wind up as losers when all is said and done.
然而，當我退後一步環顧四周時，我看到的大多數公司和工作者，最終都很可能成為輸家。

In recent decades, businesses have not only failed to cultivate full-breadth developers, they've trained a generation into believing product and engineering roles should be strictly segregated. To suggest a single person might drive both product design and technical execution would sound absurd to many people. Even for companies who realize inter-disciplinary developers are the new key to success, their outmoded job descriptions and salary bands are failing to recruit and retain them.
近幾十年來，企業不僅未能培養全方位開發者，反而訓練出一代人相信產品與工程角色應該嚴格分開。對許多人來說，若有人同時負責產品設計與技術執行，聽起來會非常荒謬。即使是那些意識到跨領域開發者是成功關鍵的新公司，他們過時的職務說明和薪資結構也無法吸引並留住這些人才。

There is an urgency to this moment. Up until a few months ago, the best developers played the violin. Today, they play the orchestra.
此刻充滿緊迫感。直到幾個月前，最優秀的開發者還像是在拉小提琴。如今，他們則是在指揮整個樂團。

Google screwed up
GOOGLE 搞砸了

I've been obsessed with this issue my entire career, so pardon me if I betray any feelings of schadenfreude as I recount the following story.
我整個職涯都對這個議題著迷，所以如果我在敘述以下故事時流露出幸災樂禍的情緒，還請見諒。

I managed to pass a phone screen with Google in 2007 before graduating college. This earned me an all-expense paid trip for an in-person interview at the vaunted Googleplex. I went on to experience complete ego collapse as I utterly flunked their interview process. Among many deeply embarrassing memories of the trip was a group session with a Big Deal Engineer who was introduced as the inventor of BigTable. (Jeff Dean, probably? Unsure.) At some point he said, "one of the great things about Google is that engineering is one career path and product is its own totally separate career path."
我在 2007 年大學畢業前，成功通過了 Google 的電話面試。這讓我獲得了一次全額付費的機會，前往傳說中的 Googleplex 進行面對面面試。接著，我經歷了徹底的自我崩潰，因為我完全沒通過他們的面試過程。這趟旅程中有許多令人深感尷尬的回憶，其中之一是在一場小組會議中，遇到了一位被介紹為 BigTable 發明者的重量級工程師。（大概是 Jeff Dean？不太確定。）他在某個時候說：「Google 的一大優點是工程師是一條職業路徑，產品經理則是完全獨立的另一條職業路徑。」

I had just paid a premium to study computer science at a liberal arts school and had the audacity to want to use those non-technical skills, so I bristled at this comment. And, being constitutionally unable to keep my mouth shut, I raised my hand to ask, "but what if I play a hybrid class? What if I think it's critical for everyone to engage with both technology and product?"
我剛剛花高價在一所文理學院學習電腦科學，還膽敢想要運用那些非技術性的技能，因此對這番話感到不悅。而且，我天生無法閉嘴，於是舉手問道：「如果我想走混合路線呢？如果我認為每個人都必須同時涉獵技術和產品，這很重要呢？」

The dude looked me dead in the eyes and told me I wasn't cut out for Google.
那位大哥直視我的眼睛，告訴我我不適合 Google。

The recruiter broke a long awkward silence by walking us to the cafeteria for lunch. She suggested I try the ice cream sandwiches. I had lost my appetite for some reason.
招募人員打破了長時間的尷尬沉默，帶我們去餐廳吃午餐。她建議我試試冰淇淋三明治。不知為何，我已經沒了食慾。

In the years since, an increasing number of companies around the world have adopted Silicon Valley's trademark dual-ladder career system. Tech people sit over here. Idea guys go over there.
這些年來，全球越來越多公司採用了矽谷標誌性的雙軌職涯制度。技術人員坐在這邊，點子人才坐在那邊。

What separates people
區分人的關鍵

Back to winners and losers.
回到贏家與輸家。

Some have discarded everything they know in favor of an "AI first" workflow. Others decry generative AI as a fleeting boondoggle like crypto. It's caused me to broach the topic with trepidation—as if I were asking someone their politics. I've spent the last few months noodling over why it's so hard to guess how a programmer will feel about AI, because people's reactions seem to cut across roles and skill levels. What factors predict whether someone is an overzealous AI booster or a radicalized AI skeptic?
有些人拋棄了所有既有的認知，轉而採用「AI 優先」的工作流程。另一些人則譴責生成式 AI，認為它像加密貨幣一樣只是曇花一現的炒作。這讓我帶著忐忑不安的心情開始探討這個話題——彷彿我在問別人的政治立場。過去幾個月我一直在思考，為什麼很難猜測一個程式設計師對 AI 的看法，因為人們的反應似乎跨越了職務和技能層級。有哪些因素能預測一個人是過度熱衷 AI 的支持者，還是激進的 AI 懷疑者？

Then I was reminded of that day at Google. And I realized that developers I know who've embraced AI tend to be more creative, more results-oriented, and have good product taste. Meanwhile, AI dissenters are more likely to code for the sake of coding, expect to be handed crystal-clear requirements, or otherwise want the job to conform to a routine 9-to-5 grind. The former group feels unchained by these tools, whereas the latter group just as often feels threatened by them.
然後我想起了那天在 Google 的經歷。我意識到，我認識的那些擁抱 AI 的開發者，往往更具創造力、更注重結果，且對產品有良好的品味。與此同時，反對 AI 的人更可能是為了寫程式而寫程式，期望能拿到明確無誤的需求，或者希望工作能符合例行的朝九晚五節奏。前者感覺這些工具讓他們獲得自由，而後者則同樣經常感到受到威脅。

When I take stock of who is thriving and who is struggling right now, a person's willingness to play both sides of the ball has been the best predictor for success.
當我盤點目前誰在蓬勃發展、誰在掙扎時，一個人願意在兩種立場間靈活切換，成為成功的最佳預測指標。

Breaking down the patterns that keep repeating as I talk to people about AI:
拆解我與人談論 AI 時不斷重複出現的模式：

• Junior engineers, as is often remarked, don't have a prayer of sufficiently evaluating the quality of an LLM's work. When the AI hallucinates or makes mistakes, novice programmers are more likely to learn the wrong thing than to spot the error. This would be less of a risk if they had the permission to decelerate to a snail's pace in order to learn everything as they go, but in this climate nobody has the patience. I've heard from a number of senior engineers that the overnight surge in junior developer productivity (as in "lines of code") has brought organization-wide productivity (as in "working software") to a halt—consumed with review and remediation of low-quality AI slop. This is but one factor contributing to the sense that lowering hiring standards was a mistake, so it's no wonder that juniors have been first on the chopping block
  初級工程師，正如常被提及的，根本無法充分評估 LLM 工作的品質。當 AI 出現幻覺或犯錯時，新手程式設計師更可能學到錯誤的東西，而非發現錯誤。如果他們有權利放慢速度，像蝸牛般慢慢學習一切，這種風險會小一些，但在這種氛圍下，沒有人有耐心。我聽過不少資深工程師說，初級開發者生產力（以「程式碼行數」計）一夜之間激增，卻讓整個組織的生產力（以「可運作軟體」計）陷入停滯——全被低品質 AI 產物的審查和修正所消耗。這只是造成降低招聘標準被認為是錯誤的眾多因素之一，因此初級工程師成為首當其衝的犧牲品也就不足為奇了。

• Senior engineers who earnestly adopt AI tools have no problem learning how to coax LLMs into generating "good enough" code at a much faster pace than they could ever write themselves. So, if they're adopting AI, what's the problem? The issue is that the productivity boon is becoming so great that companies won't need as many senior engineers as they once did. Agents work relentlessly, and tooling is converging on a vision of senior engineers as cattle ranchers, steering entire herds of AI agents. How is a highly-compensated programmer supposed to compete with a stable of agents that can produce an order of magnitude more code at an acceptable level of quality for a fraction of the price?
  認真採用 AI 工具的資深工程師，在學習如何引導 LLMs 產生「足夠好」的程式碼方面，速度遠快於他們自己手寫程式碼的速度，因此毫無問題。那麼，如果他們正在採用 AI，問題出在哪裡？問題在於生產力的提升變得如此巨大，以致公司不再需要像過去那樣多的資深工程師。代理人不知疲倦地工作，而工具正朝著將資深工程師視為牧場主的願景發展，負責指揮整群 AI 代理人。一位高薪程式設計師要如何與一群能以可接受的品質水準，且成本僅為一小部分，產出數量級更多程式碼的代理人競爭呢？

• Junior product people are, in my experience, largely unable to translate amorphous real-world problems into well-considered software solutions. And communicating those solutions with the necessary precision to bring those solutions to life? Unlikely. Still, many are having success with app creation platforms that provide the necessary primitives and guardrails. But those tools always have a low capability ceiling (just as with any low-code/no-code platform). Regardless, is this even a role worth hiring? If I wanted mediocre product direction, I'd ask ChatGPT
  以我經驗來看，初階產品人員大多無法將模糊的現實問題轉化為經過深思熟慮的軟體解決方案。而且要以必要的精確度溝通這些解決方案，讓它們得以實現？幾乎不可能。不過，許多人透過提供必要原件和護欄的應用程式創建平台取得成功。但這些工具的能力上限總是很低（就像任何低程式碼/無程式碼平台一樣）。不管怎樣，這樣的職位真的值得聘請嗎？如果我想要平庸的產品方向，我會問 ChatGPT。

• Senior product people are among the most excited I've seen about coding agents—and why shouldn't they be? They're finally free of the tyranny of nerds telling them everything is impossible. And they're building stuff! Reddit is lousy with posts showing off half-baked apps built in half a day. Unfortunately, without routinely inspecting the underlying code, anything larger than a toy app is doomed to collapse under its own weight. The fact LLMs are so agreeable and unwilling to push back often collides with the blue-sky optimism of product people, which can result in each party leading the other in circles of irrational exuberance. Things may change in the future, but for now there's no way to build great software without also understanding how it works
  資深產品人員是我見過對編碼代理最感興趣的一群人——他們為什麼不該這麼興奮呢？他們終於擺脫了那些書呆子告訴他們一切皆不可能的暴政。而且他們正在打造東西！Reddit 上充斥著展示半天內完成的半成品應用程式的貼文。不幸的是，如果不經常檢查底層程式碼，任何超過玩具等級的應用程式都注定會因自身重量而崩潰。LLMs 如此順從且不願反駁的特性，常常與產品人員的天馬行空樂觀相撞，導致雙方互相帶入非理性狂熱的循環。未來情況或許會改變，但目前沒有理解軟體運作原理，就無法打造出優秀的軟體。

Hybrid-class operators, meanwhile, seem to be having a great time regardless of their skill level or years experience. And that's because what differentiates full-stack developers is less about capability than about mindset. They're results-oriented: they may enjoy coding, but they like getting shit done even more. They're methodical: when they encounter a problem, they experiment and iterate until they arrive at a solution. The best among them are visionaries: they don't wait to be told what to work on, they identify opportunities others don't see, and they dream up software no one else has imagined.
混合型操作員無論技能水平或經驗年限如何，似乎都玩得很開心。這是因為區分全端開發者的，不是能力，而是心態。他們以結果為導向：雖然喜歡寫程式，但更喜歡把事情完成。他們有條理：遇到問題時，會透過實驗和反覆嘗試直到找到解決方案。他們中最優秀的則是有遠見的人：不會等著別人告訴他們該做什麼，而是能發現他人看不到的機會，並構想出沒有人想過的軟體。

Many are worried the market's rejection of junior developers portends a future in which today's senior engineers age out and there's no one left to replace them. I am less concerned, because less experienced full-breadth developers are navigating this environment extraordinarily well. Not only because they excitedly embraced the latest AI tools, but also because they exhibit the discipline to move slowly, understand, and critically assess the code these tools generate. The truth is computer science majors, apprenticeship programs, and code schools—today, all dead or dying—were never very effective at turning out competent software engineers. Claude Pro may not only be the best educational resource under $20, it may be the best way to learn how to code that's ever existed.
許多人擔心市場對初級開發者的排斥，預示著未來資深工程師逐漸老去，卻無人能取代他們。我倒不那麼擔心，因為經驗較淺的全方位開發者在這種環境中表現得非常出色。他們不僅熱衷於採用最新的 AI 工具，更展現出謹慎的態度，能夠慢慢理解並批判性地評估這些工具所產生的程式碼。事實上，計算機科學系、學徒制計畫和程式碼學校——如今幾乎都已消亡或式微——從來就不是培養出稱職軟體工程師的有效途徑。Claude Pro 不僅可能是 20 美元以下最好的教育資源，也可能是有史以來學習程式設計的最佳方式。

There is still hope
仍然有希望

Maybe you've read this far and the message hasn't resonated. Maybe it's triggered fears or worries you've had about AI. Maybe I've put you on the defensive and you think I'm full of shit right now. In any case, whether your organization isn't designed for this new era or you don't yet identify as a full-breadth developer, this section is for you.
也許你已經讀到這裡，但這個訊息並沒有引起你的共鳴。也許它觸發了你對人工智慧的恐懼或擔憂。也許我讓你感到防備，現在覺得我在胡說八道。無論如何，不管你的組織是否尚未為這個新時代做好準備，或你還沒有認同自己是全方位開發者，這一節都是為你而寫。

Leaders: go hire a good agency
領導者們：去聘請一家優秀的代理機構吧

While my goal here is to coin a silly phrase to help us better communicate about the transformation happening around us, we've actually had a word for full-breadth developers all along: consultant.
雖然我在這裡的目標是創造一個有趣的詞彙，幫助我們更好地溝通周遭正在發生的轉變，但其實我們一直都有一個詞來形容全方位開發者：顧問。

And not because consultants are geniuses or something. It's because, as I learned when I interviewed at Google, if a full-breadth developer wants to do their best work, they need to exist outside the organization and work on contract. So it's no surprise that some of my favorite full-breadth consultants are among AI's most ambitious adopters. Not because AI is what's trending, but because our disposition is perfectly suited to get the most out of these new tools. We're witnessing their potential to improve how the world builds software firsthand.
並不是因為顧問們是天才什麼的。正如我在 Google 面試時所學到的，如果一個全方位開發者想要發揮最佳表現，他們需要存在於組織之外，並以合約形式工作。因此，毫不奇怪，我最喜歡的一些全方位顧問正是 AI 最積極的採用者。這並非因為 AI 是流行趨勢，而是因為我們的特質非常適合充分利用這些新工具。我們正親眼見證它們改善全球軟體開發方式的潛力。

When founding our consultancy Test Double in 2011, Todd Kaufman and I told anyone who would listen that our differentiator—our whole thing—was that we were business consultants who could write software. Technology is just a means to an end, and that end (at least if you expect to be paid) is to generate business value. Even as we started winning contracts with VC-backed companies who seemed to have an infinite money spigot, we would never break ground until we understood how our work was going to make or save our clients money. And whenever the numbers didn't add up, we'd push back until the return on investment for hiring Test Double was clear.
當我們在 2011 年創立顧問公司 Test Double 時，Todd Kaufman 和我告訴所有願意聽的人，我們的差異化──我們的核心──是我們是能寫軟體的商業顧問。科技只是達成目標的手段，而那個目標（至少如果你想要獲得報酬）就是創造商業價值。即使我們開始贏得由風險投資支持、似乎有無限資金的公司的合約，我們也從不會動工，直到了解我們的工作如何為客戶賺錢或節省成本。每當數字不合理時，我們會堅持反饋，直到聘用 Test Double 的投資報酬率明確為止。

So if you're a leader at a company who has been caught unprepared for this new era of software development, my best advice is to hire an agency of full-breadth developers to work alongside your engineers. Use those experiences to encourage your best people to start thinking like they do. Observe them at work and prepare to blow up your job descriptions, interview processes, and career paths. If you want your business to thrive in what is quickly becoming a far more competitive landscape, you may be best off hitting reset on your human organization and starting over. Get smaller, stay flatter, and only add structure after the dust settles and repeatable patterns emerge.
所以如果你是公司中的領導者，卻對這個軟體開發新時代毫無準備，我最好的建議是聘請一支具備全方位技能的開發團隊，與你的工程師並肩合作。利用這些經驗來鼓勵你最優秀的人才開始以他們的思維方式思考。觀察他們的工作，並準備徹底改寫你的職務說明、面試流程和職涯規劃。如果你希望你的企業在這個迅速變得更加競爭激烈的環境中茁壯成長，最好的做法可能是重新調整你的人力組織，從頭開始。規模縮小，組織扁平化，並且只有在塵埃落定、可重複的模式浮現後，才逐步增加結構。

Developers: congrats on your new job
開發者們：恭喜你們的新工作

A lot of developers are feeling scared and hopeless about the changes being wrought by all this. Yes, AI is being used as an excuse by executives to lay people off and pad their margins. Yes, how foundation models were trained was unethical and probably also illegal. Yes, hustle bros are running around making bullshit claims. Yes, almost every party involved has a reason to make exaggerated claims about AI.
很多開發者對於這一切帶來的變化感到害怕和絕望。沒錯，AI 確實被高層用來作為裁員和增加利潤的藉口。沒錯，基礎模型的訓練方式不道德，甚至可能違法。沒錯，那些忙碌的兄弟們到處發表荒謬的言論。沒錯，幾乎所有相關方都有理由對 AI 做出誇大的宣稱。

All of that can be true, and it still doesn't matter. Your job as you knew it is gone.
這些都可能是真的，但這並不重要。你原本的工作已經不存在了。

If you want to keep getting paid, you may have been told to, "move up the value chain." If that sounds ambiguous and unclear, I'll put it more plainly: figure out how your employer makes money and position your ass directly in-between the corporate bank account and your customers' credit card information. The longer the sentence needed to explain how your job makes money for your employer, the further down the value chain you are and the more worried you should be. There's no sugar-coating it: you're probably going to have to push yourself way outside your comfort zone.
如果你想繼續領薪水，可能有人告訴你要「往價值鏈上游移動」。如果這聽起來模糊不清，我說得更明白點：弄清楚你的雇主如何賺錢，然後把自己擺在公司銀行帳戶和顧客信用卡資訊之間。解釋你的工作如何為雇主賺錢需要的句子越長，代表你在價值鏈中越靠下，你就越該擔心。這沒什麼好粉飾的：你很可能得逼自己走出舒適圈很遠。

Get serious about learning and using these new tools. You will, like me, recoil at first. You will find, if you haven't already, that all these fancy AI tools are really bad at replacing you. That they fuck up constantly. Your new job starts by figuring out how to harness their capabilities anyway. You will gradually learn how to extract something that approximates how you would have done it yourself. Once you get over that hump, the job becomes figuring out how to scale it up. Three weeks ago I was a Cursor skeptic. Today, I'm utterly exhausted working with Claude Code, because I can't write new requirements fast enough to keep up with parallel workers across multiple worktrees.
認真學習並使用這些新工具。你會像我一樣，起初感到排斥。如果你還沒發現，這些花俏的 AI 工具其實很難取代你。它們經常出錯。你的新工作就是想辦法駕馭它們的能力。你會逐漸學會如何從中提取出接近你自己做法的東西。一旦你跨過這個難關，接下來的工作就是想辦法將它擴大運用。三週前我還是 Cursor 的懷疑者。今天，我因為無法快速寫出新需求來跟上多個工作樹中平行工作的進度，使用 Claude Code 工作到完全筋疲力盡。

As for making yourself more valuable to your employer, I'm not telling you to demand a new job overnight. But if you look to your job description as a shield to protect you from work you don't want to do… stop. Make it the new minimum baseline of expectations you place on yourself. Go out of your way to surprise and delight others by taking on as much as you and your AI supercomputer can handle. Do so in the direction of however the business makes its money. Sit down and try to calculate the return on investment of your individual efforts, and don't slow down until that number far exceeds the fully-loaded cost you represent to your employer.
至於如何讓自己對雇主更有價值，我並不是叫你一夜之間就要求換一份新工作。但如果你把工作職責當成保護自己不做不想做工作的盾牌……請停止這樣想。把它當作你對自己設定的新最低期望標準。盡力去驚喜並取悅他人，承擔你和你的 AI 超級電腦能夠處理的所有工作。方向要朝著企業賺錢的方式前進。坐下來試著計算你個人努力的投資回報率，並且不要放慢腳步，直到這個數字遠遠超過你對雇主所代表的全部成本。

Start living these values in how you show up at work. Nobody is going to appreciate it if you rudely push back on every feature request with, "oh yeah? How's it going to make us money?" But your manager will appreciate your asking how you can make a bigger impact. And they probably wouldn't be mad if you were to document and celebrate the ROI wins you notch along the way. Listen to what the company's leadership identifies as the most pressing challenges facing the business and don't be afraid to volunteer to be part of the solution.
開始在你上班的態度中實踐這些價值觀。如果你每次對功能需求都粗魯地反問：「喔？這怎麼幫我們賺錢？」沒有人會欣賞你這樣做。但你的主管會感激你問如何能產生更大影響。而且如果你記錄並慶祝一路上取得的投資回報率成果，他們大概也不會生氣。傾聽公司領導層指出的企業最緊迫挑戰，並且不要害怕自願成為解決方案的一部分。

All of this would have been good career advice ten years ago. It's not rocket science, it's just deeply uncomfortable for a lot of people.
這些建議十年前會是很好的職涯指導。這並非火箭科學，只是對很多人來說非常不舒服。

Good game, programmers
好遊戲，程式設計師們

Part of me is already mourning the end of the previous era. Some topics I spent years blogging, speaking, and building tools around are no longer relevant. Others that I've been harping on for years—obsessively-structured code organization and ruthlessly-consistent design patterns—are suddenly more valuable than ever. I'm still sorting out what's worth holding onto and what I should put back on the shelf.
我內心的一部分已經在哀悼過去時代的結束。有些我花了多年時間寫部落格、演講和開發工具的主題，現在已不再相關。另一些我多年來一直強調的——過度結構化的程式碼組織和嚴格一致的設計模式——如今卻比以往任何時候都更有價值。我仍在整理哪些值得保留，哪些應該放回架上。

As a person, I really hate change. I wish things could just settle down and stand still for a while. Alas.
作為一個人，我真的很討厭改變。我希望事情能夠安定下來，靜止一段時間。可惜啊。

If this post elicited strong feelings, please e-mail me and I will respond. If you find my perspective on this stuff useful, you might enjoy my podcast, Breaking Change. 💜
如果這篇文章激起了你的強烈感受，請寄電子郵件給我，我會回覆你。如果你覺得我對這些事情的看法有用，你可能會喜歡我的播客《Breaking Change》。💜