How to be fearlessly AI native

Thank you so much. I'm so happy to be here with you.

非常感謝。我很高興能來和你一起聊聊。

Fantastic. So I'm at my core a mobile engineer. I've done a lot of a lot of work and specifically iOS over the years. I got an into the discipline right around the same time that the Apple announced the App Store way back in 2009 ish or 2008 and 9:00-ish as when I got my start in the industry. So I became an app developer near after then and have spent quite a bit of time building apps across many different verticals, categories, businesses, et cetera. You know, I spent some time in the beginning working for a design agency where we did a sort of broad swath of all sorts of different apps for different companies who didn't, you know, would come to us with ideas of like, oh, this new thing, apps. We want an app, but we don't know exactly what it looks like. And we spend some time working building with their brand strategy and how they would do that. And then, you know, I spent a good amount of time working for some of the larger app platforms that you may have heard of. I've worked for Microsoft for a little while.

當然。我的核心背景是行動應用工程，這些年尤其做了很多 iOS 相關工作。我進入這個領域的時間，差不多正好是 Apple 在 2008、2009 年前後推出 App Store 的時候。我從那時成為 App 開發者，之後為許多不同產業、類別和企業打造應用程式。職涯初期我待過設計公司，替各式各樣的客戶開發 App。當時不少公司只知道 App 是新趨勢，想做一個，卻不知道具體應該長什麼樣子；我們便會配合他們的品牌策略，一起釐清並完成產品。我後來也在一些大家耳熟能詳的大型 App 平台工作過，包括 Microsoft。

I was at Twitter a number of years ago and then spent a good amount of time at Uber platform working on real time networking, which is rather important for Uber and other sort of platform low level language compiler optimizations for networking and binary size and all these other sorts of things. And then I came to Amazon where I had been sort of a principal or lead engineer for the main shopping app for a long time. And through that journey and sort of our efforts to modernize Amazon, you know, from a classic.com company into the Mobile World, that led me to large scale cultural change and or migrating technologies from one stack to the other, which was a very natural fit for the AI revolution. And so I got into AI native development as a sort of natural consequence of that and found out that like these sort of cultural organizational change elements were in extremely important. How do we change our processes for these new constraints? And so that's led me to where I am today as sort of leading the AI native charge across the Amazon stores organization.

幾年前我待過 Twitter，也在 Uber 的平台團隊做過一段時間的即時網路技術；這對 Uber 很重要，工作也涵蓋平台底層、語言與編譯器最佳化、網路和執行檔大小等。後來我加入 Amazon，長期擔任主要購物 App 的首席或領導工程師。在把 Amazon 從傳統的 .com 公司現代化、帶進行動世界的過程中，我接觸到大規模文化轉型以及技術堆疊遷移。這和 AI 革命非常契合，所以我很自然地投入 AI-native development，也發現文化和組織變革極為重要：面對新的限制，我們要如何改變流程？這一路把我帶到今天，負責推動 Amazon Stores 組織的 AI-native 轉型。

I do agree with that, especially some of the more traditional human driven pipeline management sort of aspects of the software development life cycle. We talk a ton about how software agentic development effects how we write code and how much code we can write etcetera. But like we found very quickly that the real bottlenecks in the process tend to be downstream in the pipeline of that. So for if you have tons of human testers because your end to end test environment isn't set up to be able to actually test the functionality accordingly, that's a huge problematic bottleneck because the agent needs that feedback and it can't get it if it's in the in the hands of your human testers, you know, so they need to be able to write the test cases and have the agents be able to execute them themselves. If your pipeline management is different for the many different teams, deployments, micro services, libraries that all lead up to what ends up being your end project, it's really difficult for an agent to navigate 1000 different, slightly different nuanced pipeline and deployment execution. And so there's a lot of energy spent on the front of the software development life cycle.

我同意，尤其是軟體開發生命週期中那些較傳統、由人員管理 pipeline 的部分。大家常談 agentic development 如何影響寫程式的方式，以及我們能產生多少程式碼；但我們很快發現，真正的瓶頸往往會轉移到 pipeline 的下游。假如端到端測試環境不足，所以仍需要大量人工測試，這就會成為嚴重瓶頸：代理需要回饋，但工作握在人工測試人員手上時，它就無法自行取得。團隊必須能撰寫測試案例，並讓代理自行執行。若不同團隊、部署、microservice 和函式庫各自採用略有差異的 pipeline 管理方式，代理就很難在上千種細微不同的流程和部署方式間穿梭。因此，目前很多精力雖然投入在開發生命週期的前端，真正的問題卻可能在後端。

But our biggest wins really have been when we took the advantages that we saw in the front with spec-driven development and authoring and then use those to fix the entire software development life cycle so that we could then take that spec and verify that it the behavior is correct. So that we don't necessarily need manual human testing. We can take the test cases and the spec and the requirements and see did it actually fulfill those requirements and have the system itself verify this and then standardize that across the teams. Because we found very quickly that the weakest link in the bottleneck brings the whole system down. So if you have a whole bunch of different teams with, you know, who owned their own pipelines and had their standards and so that team was responsible for the quality of the service and they maybe follow best practices. Most teams do, but some didn't. Or the person who set this up left or etcetera, or were relying on manual testing or something like that, or, you know, this just looks good. So I'll press the approval by now.

我們最大的成果，來自把前端在 spec-driven development 與程式撰寫方面得到的優勢，延伸到整個軟體開發生命週期。我們讓系統能根據規格驗證行為是否正確，而不必完全仰賴人工測試；它可以拿測試案例、規格和需求去檢查實作是否真的符合要求，並把這套方式標準化到各團隊。我們很快發現，整個系統會被最弱的一環拖垮。假如許多團隊各自擁有 pipeline 和標準，並自行負責服務品質，多數團隊可能遵循最佳實務，但有些沒有；也可能原本設置流程的人已離職，或團隊仍依賴人工測試，只憑『看起來沒問題』就按下核准。

As the agents are making changes, the bottleneck tends to be whoever your weakest link was, whoever didn't set up the automated test and who didn't have their pipelines clean, etcetera. And so we have to then spend a lot of time taking these or consolidating these many disparate software development life cycles into a standardized way so that there aren't bottlenecks in the process. So that one individual team can't bring the whole system to a crawl, which is what we found was happening when the volume of code that was being written was going up, but the end stream of the pipeline didn't reflect the those changes and had had human bottlenecks in it.

當代理開始大量修改程式碼，瓶頸就會落在那個最弱的環節：沒有自動化測試、pipeline 沒整理乾淨的團隊等等。因此，我們必須投入許多時間，把原本各自為政的軟體開發生命週期整合成標準化方式，排除流程瓶頸，避免任何單一團隊讓整個系統慢到幾乎停擺。當程式碼產量提升，但 pipeline 下游沒有同步改變、仍存在人工瓶頸時，我們看到的正是這種情況。

So there's many different ways that the agents can help us with this in that like code review is a great example. So we'll take the code review use case. It used to be that, you know, we'd, we'd sort of spend a bunch of time in code review in the traditional way that you built stuff and that this is again, a cultural thing. But like, code review evolved into something it was never really supposed to be, IE, it's the last line of defense where you treat the human engineers as though they're extensions of the compiler, right? Here's a syntax problem. Oh, you dereference this pointer incorrectly, etcetera. Or, you know, I don't like this particular styling, which is a little bit less valuable, but you know, you sort of treated the code review itself as a way to sort of catch bugs and, and, or catch compiler issues that maybe your particular compiler didn't tell you, runtime issues that your compiler couldn't catch.

代理可以用許多方式協助，而 code review 就是很好的例子。傳統開發時，我們會花大量時間進行 code review；這同樣是一個文化問題。Code review 後來演變成它原本不該成為的東西：最後一道防線。我們把人類工程師當成編譯器的延伸，請他們指出語法錯誤、錯誤的指標解參照，甚至只是『我不喜歡這種程式碼風格』。換句話說，我們把 code review 當成捕捉 bug、編譯器沒指出的問題，以及只有執行時才會出現之錯誤的工具。

Right, Exactly, exactly right. We've now found that a lot of that element of code review can be automated very well. A code review agent with the right set of steering and context can catch can catch syntactical issues and or runtime, you know, non compiled time, but runtime issues that we're that we're it's very good at taking large swaths of code and catching those nitpicky little details of like the exact implementations very well. So it gets the humans to be able to now focus on what code review was actually intended to in the beginning was are we building the right thing, right? Is this exactly, is this what we're trying to accomplish? You know, are you, are we building what we're supposed to be building or should it be built a different way? And another thing that is happening much earlier in the cycle now is that we spend a lot of time, my team extensively uses spec-driven development for laying out how features and functionality and library should be built and behave. We use this to standardized behavior across Android and iOS, but also, you know, as a reference point in the design mechanism, etcetera.

完全正確。我們現在發現，code review 的很多部分都可以妥善自動化。只要有正確的 steering 和 context，code review agent 就能抓到語法問題、非編譯期的 runtime 問題，也很擅長掃過大範圍程式碼，找出實作上那些瑣碎卻重要的細節。這讓人類能專注於 code review 最初真正要回答的問題：我們做的是正確的東西嗎？這真的是我們想達成的目標嗎？我們是否應該用另一種方式建造它？另一項改變發生在生命週期更早的階段。我的團隊大量使用 spec-driven development，先說清楚功能、行為與函式庫應如何建立及運作；它既用來統一 Android 與 iOS 的行為，也作為設計機制的參考依據。

We find that a lot of our human code review goes into that design, IE all of our code review cycles are did you get the spec and system design correct? And then when the agent actually goes and implements that design another agent, the code review agent can then go check against that spec. Did you follow the design, catch all those, you know, syntax errors or, and, or little things that we used to rely on humans to do and it frees the humans to do the high level judgement piece of this, which is what you wanted them to be doing anyway.

我們發現，人類 code review 的大量心力現在轉向設計：規格和系統設計是否正確？代理依照設計完成實作後，另一個 code review agent 可以拿規格來核對：有沒有遵循設計？是否存在語法錯誤或過去需要人工檢查的小問題？如此便能釋放人類，讓他們負責高層次判斷——這本來就是我們真正希望他們做的事。

And so you create this feedback loop about the software development life cycle itself, where you spend more time thinking about the iterative process of that. And how do we get the context of the agent to be precise and higher quality so that it doesn't make errors in the 1st place. So it writes the code the right way the first time. There's great examples of this that I can pull from. In the beginning of our one of the bigger AI native products that we were working on, I was building a new system and it would the agent every time I would build a new subsystem in this, in this architecture like, you know, networking or navigation or whatever the library was, it would build a logging library from scratch just out of its out of its model knowledge. It would just, I need a logging library, I'll just go quickly build one with a, you know, info, debug logging levels, etcetera. And it would do this consistently almost exactly the same way, with slight newest differences across the whole thing. Well, we quickly realized that's not a good pattern at all. We need a centralized way to handle this. We then fed that back into hey, let's go build a spec for how logging behaviour should be.

這就替軟體開發生命週期本身建立了 feedback loop。我們會更深入思考如何反覆改善流程：怎樣讓代理的 context 更精確、品質更高，使它一開始就少犯錯、第一次便把程式碼寫對。舉例來說，我們早期開發一項較大型的 AI-native 產品時，每當我在架構中建立新的子系統，無論是網路、導覽或其他函式庫，代理都會憑模型知識從零寫一套 logging library。它會想：『我需要 logging，那就快速做一個，加入 info、debug 等級。』它每次都用幾乎相同、卻略有差異的方式重做。很快我們就意識到這不是好模式，應該集中處理；於是我們把問題回饋到流程中，先為 logging 的行為建立規格。

We generated a logging library, and then into the steering goes. Don't ever write your own logging library, use this one instead. That sort of iterative process started out very, you know, as we were building and the humans were hands-on with the process started very iteratively and then later on evolved where we like we're able to then track this feedback over time. We were able to track defects of like, hey, this agent ignored steering and we caught we it ignored this particular piece of context and we caught an issue at the code review phase. Let's change that context so that it won't ignore it next time. And is this getting better or worse over time? You know, to be evaluate the traces and steps of the process to create a feedback loop that doesn't require a human to sit there and make a judgment call on the quality of the output. We can measure that over time and and use that as a direct feedback loop.

我們產生一套共用 logging library，並把規則加入 steering：永遠不要自己另寫 logging library，請使用這一套。起初，這種改善是由親自參與流程的人員邊做邊反覆調整；後來則逐漸演變成可以長期追蹤的回饋。我們可以記錄 defect，例如代理忽略某段 steering 或 context，直到 code review 才抓到問題；那就修改 context，避免下次再忽略。我們也能評估情況究竟隨時間變好或變差，分析流程中的 trace 和步驟，建立不必由人一直坐在旁邊判斷輸出品質的 feedback loop，並持續量測，直接用結果改善系統。

Or you fed it a screenshot and it would imply that from that screenshot what the styling should be and it would get it right most of the way, but it would pick slightly wrong color or something like that, or it wouldn't translate correctly into the right coordinate space of the underlying system. So then what you really want to do is get the agent out of the business of doing that styling judgement itself, because it will make mistakes or suddenly do the wrong thing or propagate those changes across the whole code base. And even if it does it perfectly right, somebody later on will make a change to the design system and swap that color out. And then you have to have the agent scan the entire code base and go do that. It's way better if you can then define that design system deterministically and then tell the agent here is the semantic tokens for the actual design system. Go use those tokens. Don't invent your own. And then later on, if we want to make a change about like, Oh yeah, we'll add functionality, let's say for dark mode, or we'll change the primary color of XYZ thing.

你也可能餵給它一張截圖，讓它從畫面推論樣式。它大致能做對，卻可能選到稍有偏差的顏色，或無法正確轉換到底層系統的座標空間。真正應該做的，是不再讓代理自行判斷樣式，因為它可能犯錯、突然做出錯誤決定，或把問題擴散到整個 codebase。即使這次做得完全正確，日後若有人更改 design system、替換那個顏色，又得叫代理掃描整個 codebase。更好的方式是用確定性的方式定義 design system，然後告訴代理：這些是 design system 的 semantic tokens，請使用它們，不要自行發明。未來要新增 dark mode，或改變某個元件的主色，就會容易得多。

It could be done very easily and simply without the agent having to do the heavy lifting of making the actual changes under the hood, which it can get confused about, lose context on, and may miss things depending on how widespread that is. And so it's a direct trade off between how much can you take off the agent's plate and code into the system itself. So the agent can just do the business of applying the business requirements or the actual feature you're trying to build and not have to pull in huge swaths of context about the details about how this should actually behave that it may not have.

這些變更可以簡單完成，不必讓代理負責底層的大量修改。那種工作容易使它混淆、失去 context，也可能因影響範圍太廣而有所遺漏。這裡存在直接的取捨：能把多少工作從代理手上拿走、直接寫進系統？如此代理便只需專注套用 business requirements 或實作真正要做的功能，不必載入大量『底層究竟該如何運作』的細節，而那些細節可能根本不在它擁有的 context 中。

But in reality, the feedback mechanism the agent needs the most is do I have a test environment that I can execute and know whether or not the change that I made was good and correct and right and get that feedback loop very quickly. And so we have employed a number of testing and validation techniques across the the software development life cycle phase to help create that environment. And this includes better steering for like, because out-of-the-box, a lot of the agents can go write tests for you for sure. And so like, you know you can.

但實際上，代理最需要的回饋機制是：我是否有一個能自行執行的測試環境，可以快速知道剛才的變更是否良好、正確？因此，我們在軟體開發生命週期各階段採用了多種測試與驗證方法，來建立這種環境。其中也包括更完善的 steering。一般代理開箱即用便能替你寫測試，你當然可以直接要求它。

Give me give me, you know, 95% test coverage for XYZ package and it will go do that. And then you go read the quality of the test and like, well, it did exactly what you said. It improved the coverage, but this coverage doesn't actually test anything. It like I'll create a test new up an object, call the function and I didn't do anything with the output. I didn't actually test it like like the agent will follow your rules to a T on exactly what you want to do and it'll improve the.

例如要求：『把 XYZ package 的 test coverage 提高到 95%。』它會照做。但等你查看測試品質，可能會發現它雖然完全達成指示、提高了 coverage，那些測試卻沒有真正驗證任何事情。它可能只在測試裡建立一個物件、呼叫函式，卻完全不檢查輸出。代理會一字不差地遵循規則，確實提高……

Exactly right. And so, but that doesn't actually give you a the real validation environment that the agent needs in order to actually test it. So we spent a lot of time steering and training the actual test. You know what what makes the the actual test quality of the unit test, what you actually need to be testing, you know, define the functionality. And this is where like one of the AWS tools we use a lot is called is called Kiro. And they have invested heavily in property based testing where they build business requirements of here's exactly what we're spec'ing out. We're building the business requirements of what we want this feature or library or whatever to do. From that, I will build a test suite of property tests and other types of testing frameworks off these requirements, right, right. And so if I take these business requirements and actually write a set of property tests that verify that requirements and we've all agreed upon, here's what the requirements are. When the coding agent actually goes to build that, it will create the property tests against the requirements spec and not necessarily just off the random API code generation or existing interface that it has already.

沒錯，而那並沒有提供代理真正需要的驗證環境。因此，我們花很多時間引導和訓練測試流程：高品質 unit test 應該是什麼？真正需要測試哪些行為？如何定義功能？我們常用的一項 AWS 工具叫 Kiro，它大量投入 property-based testing。流程先建立 business requirements，明確寫出功能或函式庫應完成什麼，再依據需求產生 property tests 與其他測試套件。若我們先根據共同認可的需求寫出一組 property tests，coding agent 進行實作時，便會依 requirements spec 建立測試，而不是只根據隨機生成的 API 程式碼或現有介面來測試。

It will take the requirements as input and build right a significantly higher quality test on the other end to verify, did you actually do what you set out to in the requirements in spec phase in your implementation. So that's the unit testing piece.

它會把需求當成輸入，在另一端建立品質高得多的測試，用來驗證實作是否真的完成了需求與規格階段設定的目標。以上是 unit testing 的部分。

Another more robust testing environment that we've invested a lot in is the actual end to end testing of the customer journey. And so this is, this is one of the, I think, truly novel inventions that that our teams have come up with where, you know, we take a an actual natural language fed agent that has a connection to AWS device farm. And so it can go run a bunch of real devices and take your app and execute it inside there or a simulated environment or a browser, if you're doing the web and it will attach itself to that browser and or device. Take screenshots of the interface and then you write a natural language test case. Hey, go to Amazon.com, search for Pokémon cards and in the results tell me if there's a Charizard on screen. Now that's a bad test. You wouldn't write a test like that because it's a little flaky, but it can literally read the image and say is there, you know, is that Pokémon on the screen? I'm using this example because my kids love but and so that type of end to end journey based testing where the agent actually walks through the user journey was actually really hard to do before, like it was very.

我們還大量投入另一種更穩健的測試環境：針對完整 customer journey 進行端到端測試。我認為這是團隊真正有創意的發明之一。我們把能接收自然語言的代理連接到 AWS Device Farm，讓它在許多真實裝置、模擬環境或瀏覽器裡執行 App；代理會連上瀏覽器或裝置、擷取介面畫面，再執行自然語言測試案例。例如：『前往 Amazon.com，搜尋寶可夢卡片，告訴我結果畫面是否出現噴火龍。』這其實不是一個好測試，因為有點不穩定，但代理確實能讀取圖片，判斷畫面上是否有那隻寶可夢。我用這個例子是因為我的孩子很喜歡。過去要做這種由代理實際走完整個 user journey 的端到端測試非常困難。

These types of UX testing tend to be really brittle and so like or procedural. And so if anybody, if you got, let's say 1000 engineers working on a particular part of the interface and somebody moves a button from one side of the screen to the other, it's likely that might break somebody else's test suite because they were relying procedurally on that exact set of steps to work. But an agent can just go, if you say go search, it'll just find the magnifying glass wherever it is, and it will click on it, you know? And so these types of tests tend to be significantly more resilient and more representative of what our users actually do. And so then we can run that test suite against the functionality. We spend a lot of time actually improving the robustness of that test environment for our existing systems so that when we go modernize or update them, we have a template to run against.

這類 UX 測試通常很脆弱，也很依賴固定程序。假設一千名工程師共同維護某部分介面，其中一人把按鈕從畫面一側移到另一側，就可能破壞別人的測試，因為測試依賴一連串位置固定的操作。但如果你告訴代理『去搜尋』，它會自己找到放在哪裡的放大鏡並點擊。這種測試更有韌性，也更接近真實使用者的行為。我們因此能用整套測試來驗證功能。為了日後現代化或更新既有系統，我們也花很多時間提升測試環境的穩健性，預先建立可供新系統對照的基準。

So if I want to move a library, let's say from Objective-C, sort of A, you know, the older non type safe, non thread safe, non memory safe language that iOS development used to be into a better, you know, a more thread safe, type safe and memory safe language like Swift, which is also better for the agents, by the way, because they they do well with those types of guarantees. I'll have a test suite of that end to end test functionality of that library that I can then go run the new library against to make sure that I didn't break the journey on the way of doing that. And so a lot of teams have had to focus on improving having their automated test coverage. And that's not necessarily naturally where your first instinct is, oh, I can write a ton of code, let me go improve the test suite. But the teams who did that got significantly better results out of the AI native development pipeline. Then the teams that just sort of tried to attach their agents to their environment and just sort of use it to help them write code. And the deal there is as the system continues to evolve the test, this this test suite gets more robust.

例如要把函式庫從 Objective-C——iOS 過去使用、缺少型別安全、執行緒安全與記憶體安全的舊語言——遷移到 Swift 這類更安全的語言時，我會先有一套涵蓋該函式庫端到端功能的測試，再用它驗證新函式庫，確保遷移過程沒有破壞 customer journey。Swift 的安全保證對代理也更有利。許多團隊因此必須優先改善自動化測試覆蓋率。當你發現 AI 能大量寫程式時，第一直覺通常不是『先改善測試套件』；然而，這麼做的團隊從 AI-native development pipeline 得到的成果，遠勝過只是把代理接到環境、拿它輔助寫程式的團隊。隨著系統持續演進，測試套件也會愈來愈穩健。

It's more able to verify itself and we improve the quality over time rather than the opposite, which can happen if you have sort of unguided AI adoption. It can produce a large amount of low quality code and make that problem worse. It will actually make the cycle worse and harder to test. And so there's a lot of architectural design that comes into where do we need to apply this and what part of the systems need to be most robust in order for us to not actually make the problems worse.

它會更有能力驗證自身，讓品質隨時間提升。若毫無引導地採用 AI，情況可能完全相反：系統會產生大量低品質程式碼，使問題惡化，讓整個循環更差、更難測試。因此需要很多架構設計上的思考：AI 應該用在哪裡？系統哪些部分必須最穩健，才不會反而把問題放大？

And it would takes a good amount of time, IE it takes a number of weeks to collect the requirements, takes a number of weeks to do the design. And there'd be review and failure points at each, at each step of the way where we, oh, we'll go review the design. Oh, that doesn't look good. Back to the drawing board another week, right. Or we get to the, you know, principal or architect review at the end of the software design. And that person would and say, oh, no, that's entirely wrong. Go back to the drawing board. You know, this cycle time took forever, you know, just in the amount of coordination costs. Now we find very where teams will get together, where the designer, the product person and the engineer will sit down in the room with, with the laptop open on the projector with a Kiro agent up. And then they'll just build the specs straight out of it. Here's the requirements, here's the customer, here's the problems we're trying to solve. Well, brainstorm, build the specs, the mocks and build a POC code implementation together. And this whole process is incredibly condensed.

整個流程耗時很久：蒐集需求幾週、完成設計又幾週，每一步還有審查與退回點。設計審查可能說『這看起來不對，回去重做一週』；等軟體設計送到首席工程師或架構師審查，又可能被判定方向完全錯誤、必須重新開始。光是協調成本就讓 cycle time 漫長。現在我們看到的做法是：設計師、產品人員和工程師一起坐在會議室，把筆電接上投影機並開啟 Kiro agent，直接共同建立規格。他們輸入需求、客戶背景和待解決的問題，一起 brainstorm，完成 specs、mocks 及 POC 程式碼。整個流程因此大幅壓縮。

And this does a lot of great things in that, like if you've been working on this doc requirements design, whatever it might be for a number of weeks, the human psychology gets you really attached to that approach, right?

這帶來許多好處。假如你已經在需求文件或設計上工作了好幾週，人的心理會非常依戀那個方案，對吧？

Energy or an effort. If we all sat together in a room for 15 minutes to an hour hashing this out and the end result or the POC ends up being sort of the wrong answer, then we just throw it out and do it again, right? We, you know, we iterate on the whole process again because it's really since these artifacts can be produced so quickly and collaboratively. I'm significant. The psychology is significantly less attached to this.

投入了時間、精力和心力。但如果大家只在同一個房間花十五分鐘到一小時共同推演，最後發現成果或 POC 是錯的，我們就把它丟掉再做一次，重新迭代整個流程。這些產物能快速且協作地生成，因此人的心理不會那麼依附於它。

Yeah, exactly. In the beginning of the project that I'm working on now, I I picked the wrong Swift language. In the design phase, I picked Swift 5.9 instead of 6. And the nuance of why that's important is that Swift 6 is thread safe at compile time where Swift 5.9 is not. I realized this after it already generated 20,000 lines of code. In the old days I would have been very attached to that code. I went and told the agent, hey, let's switch the project to Swift 6. It switched. It did that, switched it to Swift 6. There were suddenly 600 compile errors because there's syntactic breaking changes between those languages and the agent couldn't work through all of them because it couldn't build the entire thing, get the and burn down the 600 errors get the feedback necessary. So I ended up throwing out those 20,000 lines going back, adding this into the original spec and steering, hey, use Swift 6 by default and then just regenerating it. And that whole process took me 15–20 minutes to throw all 20,000 lines out and then rerun the task execution through Kiro.

完全正確。我目前的專案在設計階段選錯 Swift 版本，用了 Swift 5.9，而不是 Swift 6。這點很重要，因為 Swift 6 在編譯期便提供 thread safety，Swift 5.9 沒有。我發現時，代理已經產生兩萬行程式碼。從前我一定很捨不得放棄；但我告訴代理把專案改成 Swift 6，切換後立刻出現六百個 compile errors，因為兩個版本之間存在破壞性語法變更。代理無法一次處理所有錯誤：整個專案無法建置，也就拿不到逐步消除六百個錯誤所需的回饋。最後我丟掉那兩萬行，回頭在原始 spec 和 steering 裡加入『預設使用 Swift 6』，再透過 Kiro 重新執行任務。捨棄並重建兩萬行只花了十五到二十分鐘。

And I hardly hardly caused me any heartburn at all because all of the process of work that I had done to sort of think about the system design, etcetera was preserved in the context of the agent. And I could just regenerate that spec on the on the fly and reproduce all that code and have the right answer on the other end of it in a in a tiny little amount of time, which would have taken me weeks if I was to, let's say, do that migration manually line by line in the old world.

這幾乎沒有讓我感到痛苦，因為先前對系統設計的思考都保存在代理的 context 裡。我可以即時重新產生規格與所有程式碼，很快在另一端得到正確答案。若用舊方法逐行手動遷移，可能需要好幾週。

Know somebody had and so we spend a lot of time going and, and standardizing the definition of what a clean deployment environment is and applying that across the board so that we don't end up with these bottlenecks of the system. And so there's, there's a couple of different ways to do this. One is consolidation. If you end up with 1000 different teams writing in a whole bunch of different languages that they chose for reasons that were not necessarily like this is the best language for the job. It was more, well, my team knows Java, so I picked Java, you know, which has different deployment and infrastructure characteristics than, let's say, a micro service written in Rust or or some other language. And so we found a huge advantage in sort of consolidating a ton of how that works in the end of the pipeline. So if like there is one way to build a micro service and deploy it across the platform and there's one standardized bar for the quality of pipelines and how they get changes and how they how up to date and modernized they are.

因此，我們花很多時間定義『乾淨的部署環境』，並把標準全面套用，避免形成系統瓶頸。其中一種方法是整併。若一千支團隊各自選擇不同語言，理由未必是『最適合這份工作的語言』，可能只是『我的團隊懂 Java，所以選 Java』；但 Java 的部署與基礎設施特性，和 Rust microservice 或其他語言不同。我們發現，整併 pipeline 尾端的運作方式帶來巨大優勢。假如整個平台只有一種建置與部署 microservice 的方式，pipeline 的品質、變更程序和現代化程度也有同一套標準，情況就會簡單許多。

We can get that out of the hands of the individual teams and get them out of the business of doing that anyway, because it's mostly mundane work to keep a pipeline up to date and to handle the deployment infrastructure. And as we say, non differentiated work like this is not the core part of this engineer's job is to solve business problems is not to babysit pipelines. And so we had to standardize how a lot of this works. We standardized a lot of the runtimes into a smaller set of what we can guarantee that this particular language runtime environment will build and deploy safely following this set of standards in a centralized way. And we'll move you to that centralized, standardized way so that I don't have to train the agents on 1000 different nuanced ways of navigating that deployment structure. So this is part of the cultural change you have to give. You have to give to get here because a lot of people liked the control they had.

如此便能把工作從個別團隊手上移走。維護 pipeline 和部署基礎設施大多是例行工作，也是所謂沒有差異化價值的工作；工程師的核心職責是解決商業問題，不是照顧 pipeline。我們因此標準化許多流程，把 runtime 收斂到較小的集合，集中保證特定語言與 runtime environment 能依照標準安全建置及部署，再協助團隊移到這種中央化方式。這樣就不必教代理辨識上千種細微不同的部署結構。這也是文化轉型需要付出的交換，因為許多人喜歡原本擁有的控制權。

I have ownership over my, my stack and I got to choose what it was and it works really well for me. And I have a high standard for myself. And so therefore, but like very quickly, you realize that these standards are not the same across the board. And very in a, in a large enterprise system and in an app as complex as, let's say the Amazon app is, you quickly become dependent on a lot of different pipelines and services that you don't have control over. And so giving them the ability to systematize, standardize and get their code flowing sort of universally across the board, they're willing to, to let go of some of that the automation paradox, the human elements of control and all this of like, it may not be perfect, but I have control over it. And if I need to press the override button or do a rollback, I know I can will you have to be able to give them the the security that they still be able to have the right control mechanisms when they need them. But we'll take a lot of this very mundane, repetitive work off of your plate and standardize it so that you don't have to do that anymore.

人們會說：『我擁有自己的 stack，可以自行選擇，而且它對我運作得很好；我也對自己要求很高。』但很快就會發現，各團隊的標準並不一致。在大型企業系統，尤其像 Amazon App 這麼複雜的產品裡，你很快會依賴許多自己無法控制的 pipeline 與服務。當團隊看到系統化、標準化能讓程式碼在全組織順暢流動，就願意放下一部分控制權。這就是 automation paradox：即使系統不完美，人還是會因為自己能按 override 或執行 rollback 而偏愛它。我們必須讓團隊確信，必要時仍保有正確的控制機制；同時，我們會替他們拿走大量單調重複的工作並加以標準化，使他們不必再親自處理。

And we find very quickly that the teams who really embrace the AI native development workflow, their desire to move quickly and be able to iterate on the on their processes fast, quickly overrides whatever leftover sentiment they had about the control of of how their stacks work downstream. And so then they rail against these barriers instead of putting them up right. And so then they it, it sort of demands these more, more systematic fixes across the board.

我們很快發現，真正擁抱 AI-native development workflow 的團隊非常渴望快速前進、迅速迭代流程；這種需求很快就超過他們對下游 stack 控制權的留戀。於是，他們不再設置障礙，反而會主動反對那些障礙，進一步要求整個組織採取更系統化的改善。

Still, the you know, you're building a, you're building a, a, a system approach that can be applied everywhere and take a bunch of problems off people's plates. In the beginning of the AI revolution, I was a little worried that losing touch with the keystrokes would, would take some of the magic out of it for me. And in reality, the architecture in the system building was the creativity that I loved. And now I can apply that across the whole board instead of, you know, just only being able to do it for the small areas that I had direct control over. And so the magic is some ways even more magical rather than less because these tools exist. And my job as an engineer, I can do even better. And I can apply that engineer architectural thinking much more broadly than I ever was able to before.

是的。你是在建立一套能廣泛套用的系統方法，替人們移除許多問題。AI 革命初期，我有點擔心不再親手敲鍵盤，會讓工程對我失去一些魔力。但我後來發現，自己真正喜愛的創造力是在架構和系統建造。現在我能把這種思考運用到整個組織，而不只限於自己直接控制的小範圍。因為有了這些工具，那份魔力不但沒有減少，某些方面反而更強；我能把工程與架構思維運用得比以往更廣。

Like if you're starting from a complete sort of brownfield system, it's really great to start with first open up the agent, open up the Kiro in IDE for example, and go generate the steering files. Get the agent to sort of look at your package and figure out if it can understand what's going on. And if it gets it wrong, go iterate on get a starting point where you can start building that truth in your system. If you don't have the specs already, if you don't already have good system design and documentation, you can open up the the IDE, open up the agent and and have it go go generate that. See if it's right, right. And then that gives you an anchor point of like, you know, here's truth in the system, here's how I think your style guideline works, even if you don't have it articulated, you know, in a in a formal document, etcetera. And then that gives you an iteration point. OK. So from this steering that's been generated by the agent, what it's sort of inferred from your existing package structure, how much of that or patterns you actually want to follow or how much of that is tech debt leftover from from arbitrary decisions that were made years ago.

如果從既有的 brownfield system 開始，可以先打開代理，例如 IDE 裡的 Kiro，請它產生 steering files。讓代理檢視 package，看看它是否理解目前系統；若理解錯誤，就反覆修正，建立可以開始累積 system truth 的起點。假如尚未具備 specs、良好的 system design 或文件，也可以請 IDE 裡的代理先產生，再檢查是否正確。這會形成一個錨點：系統目前認定的事實是什麼？即使團隊從未正式寫下 style guidelines，代理推論出的規則又是什麼？接著便能逐步判斷：代理從既有 package structure 推論出的 steering，有多少是團隊真正想遵循的模式？又有多少只是多年以前任意決策留下的 tech debt？

Now I have an iteration point of where I can say, oh, that's tech debt. I don't want to enforce that pattern. Let me go steer to remove that debt, right? So from now on when you write new code, don't do that anymore. Do this right and you can start iterating on that process. From there, you can start building out the specs that represent your system design, and you can iterate and improve on them. You can, once you had to design that define system behavior, you can use it as an anchor point for you to go improve your test coverage. And then it that becomes the way you start iterating on the rest of the parts of the software development life cycle. And then it's a bottlenecking exercise as you start to then generate more code, start fixing these problems. Where do you get hung up the most? Where is the where are the problems you're having? And go standardize that. And the standard answer may not be point an agent at it, get AI to fix it. It might be go clean up your pipelines and maybe you get an agent to help you do that. But like maybe it means switching to a mono repo where all your context is together, which is something that I did on my team.

有了起點，團隊就能指出：『這是 tech debt，我不想繼續強制這種模式。』然後透過 steering 告訴代理，日後寫新程式碼時不要再這麼做，改用新的方式，並持續迭代。接著可建立代表系統設計的 specs，不斷改進；當設計已定義系統行為，它也能成為提升 test coverage 的錨點，進而逐步改善軟體開發生命週期其他部分。之後的工作就是找瓶頸：隨著程式碼產量增加，哪裡最常卡住？問題在哪裡？把那個環節標準化。標準答案不一定是『丟給代理，讓 AI 修好』，也可能是整理 pipeline，或讓代理協助整理；也可能代表改用 monorepo，把所有 context 集中在一起——我的團隊就做過這件事。

You know, you'll start to see where these bottlenecks in the process are and then go optimize those processes away or take that, take that problem off the table for your agent and get the feedback mechanism loop running where you start to improve this agentic workflow over time. You take the the downstream signals from the testing and code review processes and all that sort of stuff. Incorporate it back into the steering so the code generation agents stop making mistakes, you know, those types of mistakes anymore and start improving it over time. And so get that flywheel going. The other thing we always say, and I, I'll quote one of my colleagues on this name is Tony Chore. He's the head of our, our builder works department. It's like you got to go slower to go faster in the beginning, IE get off the treadmill of continuously making incremental changes and do some system thinking. Like if you're constantly shipping features all the time, just adding AI onto that treadmill of like constantly iterating on top of tech debt doesn't get you where you want to go.

你會逐漸看見流程瓶頸，接著把它們最佳化掉，或直接替代理移除問題。建立能長期改善 agentic workflow 的 feedback loop：把測試與 code review 的下游訊號送回 steering，讓 code generation agent 不再犯同類錯誤，形成持續改善的 flywheel。我們常引用一位同事的說法：一開始必須『go slower to go faster』。離開持續做微小變更的跑步機，先進行 system thinking。若團隊不斷交付功能，只把 AI 疊加在持續累積 tech debt 的流程上，最終不會到達想去的地方。

Take a step back, get off the treadmill, do a little system design thinking, really get to know how the tools work, like force them into places you weren't naturally using them before. Figure out where the bottlenecks are, go slower to go faster. And we find that the teams that did that sort of took a step back, looked at the process, did the systematic thinking, ended up way outpacing the teams that just sort of tried to add it on to what they were already doing. You know, they went slower for a few weeks while they sort of stopped feature development or stopped iterative development and worked on the system. But once they got those pieces of the puzzle in place, we across the board, the teams that did that improve their own deployment rate by a factor of an average of about 4.5× over where their deployment rate rate was before when they were just sort of having the agent do what we were already doing. But I asked the agent to help me with it, right?

退一步、離開跑步機，做一些 system design，真正了解工具的運作方式；甚至刻意把它用在原本不會使用的地方，找出瓶頸。先慢下來，才能更快。我們發現，願意退一步審視流程、進行系統化思考的團隊，最後遠遠超過只是把 AI 加到既有工作上的團隊。他們可能先花幾週暫停部分功能或迭代開發，專心整理系統；但關鍵拼圖到位後，這些團隊的 deployment rate 平均提升到原來的 4.5 倍。過去他們只是讓代理協助執行既有流程，並沒有真正改變系統。

And that was universal. And across the board, the teams who took the time to do that upfront got massive improvements over the teams that did not. The last thing that I would tack on to that is like now is the best time if you haven't, go.

這個結果在各團隊都一致：願意前期投入時間的團隊，改善幅度遠超過沒有這麼做的團隊。最後我想補充的是，如果你還沒開始，現在就是投入的最佳時機。

The industry is constantly shifting and changing and even the stuff that I told you in this in this session may evolve and be different by the time you adopted etcetera. So the the key thing is to learn the Amazon principle we apply the most here is learn to be curious, you know, do it. Get in now, get be ready to flexible and learn and get comfortable with the pace of change. And now is the best time.

產業一直快速移動和改變；甚至我今天分享的內容，到你真正採用時也可能已經演進。關鍵是保持學習與好奇——這也是我們最常運用的 Amazon leadership principle。親自去做、現在就開始，準備保持彈性、持續學習，並習慣這種變化速度。現在正是最好的時候。

I'm McLaren Stanley, I'm a senior principal engineer here at Amazon stores. It's been great to be on and I too. You can find me on LinkedIn if you want to follow along. Been a long time user of Stack Overflow. It's great to be here.

我是 McLaren Stanley，目前是 Amazon Stores 的資深首席工程師。很高興參加本集；如果想繼續關注，也可以在 LinkedIn 找到我。我使用 Stack Overflow 已經很久了，今天能來到這裡非常開心。