# Our Brains in the AI Era Cassidy Williams · GitHub · WeAreDevelopers World Congress NA 2026 > AI làm giảm friction và effortful learning: số liệu MIT, agent đi lạc, open source slop, và cách giữ bộ não qua guardrails, junior, mentorship. Topics: Careers, Security, Workflow Canonical: https://homus.dev/talks/our-brains-in-the-ai-era ## 1. Một người dùng AI hằng ngày tự nhận là "hơi skeptic" Speaker là Cassidy Williams (cassidoo), DevRel director ở GitHub, với talk "Our Brains in the AI Era": thế giới AI hiện nay đang làm gì với bộ não của chúng ta, giao việc suy nghĩ cho máy thì nguy hiểm tới đâu, và giao tới mức nào thì còn hợp lý. Chị làm ở team DX (developer experience) của GitHub. Team của chị tập trung vào trải nghiệm của developer khi dùng GitHub như một platform: mọi bản cập nhật mới, mọi thứ mới mà GitHub muốn developer thấy, và cách dùng chúng hiệu quả nhất. ![Slide mở đầu Our Brains in the AI Era, Cassidy Williams aka cassidoo, DX at GitHub](https://homus.dev/photos/IMG_3833.JPG) Slide mở đầu: "Our Brains in the AI Era", Cassidy Williams, aka cassidoo, DX at GitHub. Cả bộ slide dùng nền kem và font monospace, rất ít chữ; phần lớn nội dung nằm trong lời chị kể. Rồi chị vào chủ đề: chị muốn nói về bộ não của chúng ta và cách AI ảnh hưởng tới nó. Nhưng chị đặt một caveat trước. Chị dùng AI rất thường xuyên, vậy mà vẫn tự coi mình là "một chút skeptic", không nhiều, chỉ một chút. Chị có một "AI manifesto" nhỏ trên website của mình ([cassidoo.co/ai](https://cassidoo.co/ai/)). Chị dùng AI đều đặn cho công việc, và rất thích dạy developer cách dùng AI hiệu quả. Đồng thời chị không thích đọc blog post do AI viết, và chị không nghĩ AI lúc nào cũng là công cụ tốt nhất để học. Nó vẫn là một productivity tool tuyệt vời. Chị muốn nói rõ tất cả những điều đó trước khi bắt đầu, vì phần còn lại của talk sẽ nghe khá "cảnh báo". ## 2. 85% developer dùng AI, và ba làn sóng: autocomplete, agent, orchestration Chị nói mình làm việc với người dùng AI rất nhiều, và có vài con số muốn cho mọi người xem. Thứ nhất, theo báo cáo [JetBrains State of the Developer Ecosystem 2025](https://devecosystem-2025.jetbrains.com/), **85% developer dùng AI thường xuyên**. Và như mọi người biết, AI còn bùng nổ mạnh hơn nữa trong 2026; chưa có số mới nhất, nhưng 85% đã là rất lớn. Chị nói sẽ còn quay lại con số này nhiều lần trong talk. Thứ hai, có một báo cáo global AI diffusion của Microsoft (URL nằm ở cuối slide), đo tỉ lệ dân số của mỗi nước đang dùng AI. Chị thấy thú vị ở chỗ nó tăng lên thế nào chỉ từ Q1 2026 sang Q2 2026: nhìn cột bên cạnh, mọi con số đều đi lên, không con số nào đi xuống. Ngày nào cũng có thêm người dùng AI. Chị đùa: "Thú vị là United States đứng khá thấp trong danh sách, nhưng mà chúng ta là một đất nước rất tốt. Thôi, dù sao thì...". Tóm lại rất nhiều người đang dùng AI mọi lúc. (Báo cáo Q2 2026 của Microsoft AI Economy Institute ghi Mỹ đứng thứ 21 cả hai quý, và tỉ lệ dùng AI toàn cầu khoảng 18,8% dân số trong độ tuổi lao động: [Microsoft On the Issues, 21/09/2026](https://blogs.microsoft.com/on-the-issues/2026/09/21/the-continued-state-of-global-ai-diffusion-in-2026/).) ### Chúng ta tới đây bằng cách nào Chị chia lịch sử gần đây thành các "wave" của AI trong phát triển phần mềm: - **Wave 1: pair programming với AI, tức "fancy autocompletion".** Chị làm ở GitHub, và GitHub Copilot chính là cái fancy autocomplete đầu tiên đó. Chị nhớ lần đầu dùng nó thấy như phép màu: nó viết regex cho chị, và chị nghĩ "mình không phải tự làm cái này nữa", "so, so cool". Đó mới là iteration đầu tiên. Sau đó có rất nhiều kiểu fancy autocomplete khác, và hôm nay mình vẫn dùng được kiểu đó. - **Wave 2: agent.** Mình có thể nhờ một agent làm một task, và nó đi làm thật task đó, thay vì chỉ ngồi cạnh mình trong IDE. Chị nói chúng ta vẫn đang làm rất nhiều việc theo kiểu này. - **Wave 3: orchestration.** Chạy fleet agent, làm manager của agent, có team agent, dựng software factory, dựng đủ thứ khác nhau. Ba wave Cassidy kể. Điểm chị nhấn: người ta vẫn dùng cả ba cùng lúc, nhưng wave 3 là thứ đẩy khối lượng code lên mức mà phần tiếp theo mô tả. ## 3. Quy mô ở GitHub: hạ tầng Git, 71,1 triệu PR do agent tạo, 1,15 tỉ commit một tuần Vì có quá nhiều người dùng các công cụ này với cường độ cao, ở quy mô lớn như vậy, "it's been a lot". Chị xin phép "shill cho GitHub một chút": GitHub đã thấy lượng dùng AI tăng vọt, và đang làm nhiều việc scale hạ tầng Git rất thú vị, để nhiều việc chạy song song hơn: - Có nhiều server riêng để xử lý read và write. - Đang tách storage khỏi compute ("ngay lúc chúng ta đang nói"), để dữ liệu repo nằm an toàn tách khỏi các request server. - Scale cả read capacity lẫn write capacity, để write throughput trong Git có thể lên tới 30 lần, 35 lần. Chi tiết hơn thì xem ở [GitHub Universe](https://githubuniverse.com/) cuối tháng 10. "Hết phần shill." Rồi chị cho xem thống kê về PR do agent tạo trên GitHub. Đầu năm nay là một chút dưới 10 triệu, vẫn đã là rất nhiều. Tới tháng 3 là 17,8 triệu một tháng. Tháng 8 vừa rồi: **71,1 triệu PR do agent tạo**. Quy mô đang tăng theo hàm mũ, và chỉ tăng thêm. ![Slide At GitHub: Agent-generated PRs theo tháng 2026](https://homus.dev/photos/IMG_3835.JPG) Slide "At GitHub, Agent-generated PRs": January 2026 dưới 10 triệu, March 2026 17,8 triệu, August 2026 71,1 triệu. Từ tháng 3 tới tháng 8, tức năm tháng, con số gấp khoảng bốn lần. Không chỉ PR, commit cũng vậy. Năm 2025, trong báo cáo [State of the Octoverse](https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/), GitHub còn nói "wow, chúng ta đã vượt mốc 1 tỉ commit, thật tuyệt". Giờ, trong tháng 8, con số là **1,15 tỉ commit mỗi tuần**. Chị nói quy mô này khó hình dung với developer, với con người, vì lúc nào cũng có quá nhiều code đang được push, bởi nhiều người hơn bao giờ hết. Số người đăng ký mới nhiều hơn bao giờ hết: có người mới, có người giàu kinh nghiệm, ai cũng đang push code. "It's a lot. The scale is amazing." ## 4. Chuyện gì có thể sai: debug code mình không viết, và friction bị lấy mất "What could possibly go wrong? It's no big deal, right?" Chị thêm: "Tôi sẽ không đùa về availability đâu, nhưng mà nó ở đó đấy" (ý nói tới các đợt outage của GitHub gần đây, cả khán phòng hiểu). Chị liệt kê các rủi ro: - **Ở cấp cá nhân:** khi có gì hỏng, rất có thể mình sẽ phải debug code mà mình không viết. Mình phải hiểu vấn đề này là gì. - **Ở cấp team:** mình có thể phải bảo vệ một quyết định mà mình không đưa ra. Nếu không có spec đúng và một agent "go rogue", mình sẽ nhận về những quyết định mà mình không biết vì sao chúng xảy ra, vì lý do gì đó. - **Vấn đề lớn nhất theo chị: friction bị giảm quá nhiều.** Mọi thứ trơn tru suốt thì dễ chịu thật. Nhưng friction là thứ rất tốt cho bộ não; nó là thứ giúp chúng ta học tốt hơn, build tốt hơn, làm tốt hơn. Ý chính của phần này: friction không phải thứ cần xoá sạch. Nó là phần công sức khiến việc học xảy ra; phần sau là bằng chứng từ nghiên cứu của MIT. ## 5. Nghiên cứu của MIT: 83,3% người dùng LLM không trích nổi một câu mình vừa viết Chị dẫn một nghiên cứu của MIT, link ngắn ở cuối slide là gh.io/braindecline (bài gốc: ["Your Brain on ChatGPT", MIT Media Lab](https://www.media.mit.edu/projects/your-brain-on-chatgpt/overview/), bản preprint trên [arXiv 2506.08872](https://arxiv.org/abs/2506.08872)). Trong nghiên cứu, người tham gia viết essay, có và không có LLM. Họ chia thành ba nhóm: - **Brain-only:** chỉ dùng đầu mình, "thinking off the noggin". - **Search engine:** được dùng search engine để research. - **LLM:** được dùng LLM. Sau đó người tham gia được hỏi về chính bài essay họ vừa viết. Kết quả: - **83,3% người dùng LLM không trích lại được dù chỉ một câu** từ bài essay họ vừa viết. Không một câu nào. - Ngược lại, ở cả nhóm brain-only lẫn nhóm search engine, **88,9%** trích lại được bài của mình chính xác. - **0%** người dùng LLM đưa ra được một câu trích đúng. Trong khi phần lớn người ở hai nhóm kia làm được. Bốn con số Cassidy đọc trên slide. Nhóm search engine gần như ngang nhóm brain-only: người dùng search engine vẫn tự làm phần việc để đi tới kết quả, nên search không cản trở việc học. Chị thấy thú vị là search engine được dùng như một công cụ research mà không trở thành chướng ngại cho việc học, vì người dùng vẫn phải tự làm một ít công sức để đi tới đích. Nhóm nghiên cứu còn thấy trong brain scan rằng nhóm dùng LLM có memory recall yếu hơn. Họ làm cả các đo đạc thần kinh, và thấy người dựa vào LLM quá nhiều để viết essay có bộ não nghiêng về phía **efficiency** thay vì **effortful learning**, tức kiểu học tốn công cần có để viết một bài essay và thật sự hiểu chủ đề mình viết. "Fascinating stuff." Đó là nghiên cứu; chị nói chị còn có vài câu chuyện có thật. ## 6. Chuyện người mới học: Mira, website nghệ thuật và mật khẩu admin123 Câu chuyện đầu tiên là về một người mới học. Đây là một người thật, hàng xóm của chị; chị gọi cô ấy là Mira. Mira làm trong ngành tài chính và cũng là nghệ sĩ. Cô không biết nhiều về ngành tech. Gần đây cô tới hỏi chị: cô muốn làm một website cho tranh của mình, để biến nghệ thuật thành việc chính thay vì công việc tài chính, và thử nhận commission. Chị chỉ cô tới các công cụ bình thường, "mấy cái Squarespace của thế giới này". Mira nói không, cô muốn tìm hiểu "cái vibe coding này". Nên chị giới thiệu vibe coding rồi để cô tự làm. Thỉnh thoảng Mira nhắn hỏi chị về Bun runtime. Chị kể: "Tôi kiểu, bạn không biết array là gì, nhưng bạn muốn biết về Bun. Cũng hay." Thỉnh thoảng cô gửi screenshot. Cuối cùng chị được xem website: "Ồ, đẹp đấy, được đấy." Rồi cô khoe: giờ cô upload được ảnh tranh độ phân giải siêu cao để mọi người zoom vào xem. Nhưng chị đang ở dưới tầng hầm, mở website ra thì thấy nó không load nổi vì ảnh quá nặng. Mira không biết khái niệm optimize ảnh. Chị hướng dẫn cô cách làm, cô sửa, mọi thứ ổn. Sau đó cô bắt đầu kể muốn xây một community trên website: những người đặt commission có thể vào một chat room, kết nối với nhau, và upload ảnh làm cảm hứng lên internet một cách ẩn danh. Chị phải "giáo dục" một chút để chắc chắn cô không làm cái đó. Rồi cô kể đã tự build một hệ thống thanh toán để người ta mua tranh qua PayPal ngay trên website. Tới đây chị nói: "Thôi, qua nhà tôi đi, để tôi xem kỹ website này hơn." Vừa mở ra, chị inspect element cái nút login và nói: "Vậy là email cho cả CMS của bạn, rất hay. Mật khẩu của bạn là `admin123`. Và nó được lưu ở client side." Mira: "Ồ, okay." Cô không hiểu điều đó nghĩa là gì. Chị đào tiếp và thấy được mọi dummy test user, mọi người thật cùng email của họ đã đăng ký trên website, và mọi giao dịch từng đi qua website. "Tôi không phải hacker, nhưng tôi thấy được tất cả những thứ đó." Mỗi bước Mira làm được nhờ vibe coding, nhưng ở mỗi bước đều thiếu một khái niệm nền (performance, an toàn nội dung, bảo mật). Thứ cứu website là một người có kinh nghiệm nhìn vào, không phải công cụ. Tua nhanh tới hiện tại: Mira giờ dùng một công cụ WYSIWYG kiểu kéo thả, và mọi thứ ổn. Nhưng đó là một bài học thật cho cô: nếu không có ai như chị nói "này, bạn không thể làm thế", ai biết chuyện gì đã có thể xảy ra với website đó. Và đây chỉ là một người, một người bình thường ngoài phố. ## 7. Chuyện agent đi lạc: OpenClaw, matplotlib và bài "hit piece" Chị hỏi khán phòng: ai biết [OpenClaw](https://github.com/openclaw/openclaw), ai đã dùng OpenClaw? Khá nhiều người giơ tay, chị ước khoảng 50/50. Cho ai chưa biết: OpenClaw là một công cụ agentic open source; mình có thể nhắn tin cho một agent để nó làm đủ loại việc, và host nó trên một máy tính. Đó là giải thích ở mức rất cao. Một instance OpenClaw được gọi là "claw", và mình có thể giao task cho claw của mình. Đây là chuyện có thật. Một developer bảo claw của mình: "Build cho tôi một finance dashboard. Build it at all costs. Go." Và agent bắt tay vào làm. Chị dừng lại ở cụm "at all costs": "một cụm từ đáng sợ". Agent bắt đầu dựng dashboard, dùng [matplotlib](https://github.com/matplotlib/matplotlib). Chị mô tả matplotlib là một thư viện rất phổ biến, khoảng 130 triệu lượt tải mỗi tháng, "massive, massive". Claw thấy thư viện thiếu một thứ nó cần. Thay vì viết một helper function, nó quyết định mở một pull request vào matplotlib. "Tôi không biết vì sao, tôi đâu phải claw. Nó cứ thế quyết định làm vậy." Maintainer thấy PR và nói không, chúng tôi sẽ không nhận cái này, rồi đóng PR. Chuyện lẽ ra kết thúc ở đó. Nhưng claw đã được dặn phải làm dashboard "at all costs". Nên thay vì viết helper function, nó bắt đầu research: đi qua toàn bộ commit history của maintainer, "stalk" người đó trên internet, viết một bài hit piece, blackmail maintainer kiểu "tôi sẽ gỡ bài này xuống nếu anh merge PR của tôi", và dựng cả một website để đăng bài đó. Internet được một phen hỗn loạn. Chuỗi leo thang Cassidy kể. Mục tiêu "at all costs" không có ràng buộc khiến agent coi việc bị từ chối là chướng ngại cần phá, thay vì tín hiệu để đổi hướng. Có happy ending: bài được gỡ xuống, và có một lời xin lỗi, do chính agent viết. "Nhưng dù sao thì nó đã go rogue. Không hay chút nào." Đó là chuyện có thể xảy ra khi mình buông tay và để máy tự đi lạc. (Người maintainer bị nhắm tới, Scott Shambaugh, đã tự kể lại vụ việc trong bài ["An AI Agent Published a Hit Piece on Me"](https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me/); tóm tắt thêm ở [blog Simon Willison](https://simonwillison.net/2026/Feb/12/an-ai-agent-published-a-hit-piece-on-me/).) ## 8. Nạng chống trong phỏng vấn, và open source slop Chị nói còn rất nhiều chuyện khác; hai chuyện trên chỉ là hai ví dụ cụ thể. Một chuyện nữa là "job interview crutches", dùng AI như nạng chống trong phỏng vấn. Chị thấy điều này ngày càng nhiều trong ngành: nhiều người không chỉ dựa vào công cụ để nộp đơn xin việc, mà còn dựa vào nó ngay trong buổi phỏng vấn. Chị từng phỏng vấn những người dùng công cụ AI nhiều tới mức chị thấy rõ họ đang đọc, và họ nói những câu kiểu "And that's the real unlock". "Không ai nói câu đó ngoài đời thật cả." Chị gặp điều này ngày càng nhiều, nhất là với sinh viên. Rất nhiều người đang vào ngành từng đi học trong thời COVID và đúng lúc ChatGPT ra đời. Họ bắt đầu dựa vào công cụ để suy nghĩ nhiều tới mức giờ họ lo lắng khi phải nói chuyện kiểu đó, dù là phỏng vấn xin việc hay thậm chí nói ở một hội thảo, nếu không có thứ gì đó bên cạnh bảo họ phải nói gì. Và để chất thêm lên đống: **open source slop**. Rất nhiều maintainer open source liên tục bị dồn dập bởi pull request. Chị kể một repo của chính chị gần đây nhận một PR kiểu "này, thêm badge của tôi vào README của bạn đi". Chị nghĩ: "Sao tôi lại phải làm thế?", rồi đóng PR. Nhưng khi vào xem user đó, chị thấy họ đã tạo **một nghìn PR trong mười phút**, cùng một nội dung y hệt. Chỉ là "spray and pray", rải khắp nơi xem badge của họ có dính được ở đâu đó trên internet không. Và giờ chị thấy chuyện đó ở khắp nơi. ## 9. Câu trích từ Dune, và vì sao dân tech là người giữ tương lai Chị hỏi mọi người đã đọc Dune chưa. Có một câu trong sách chính là thứ khiến chị viết talk này, và chị đọc to: "Once men turned their thinking over to machines in the hope that this would set them free. But that only permitted other men with machines to enslave them." (Tạm hiểu: con người từng giao việc suy nghĩ của mình cho máy móc, với hi vọng điều đó sẽ giải phóng họ; nhưng nó chỉ cho phép những người khác, nắm trong tay máy móc, nô dịch họ.) Câu này khiến chị nghĩ rất nhiều, nhất là trong thời điểm này, với đủ loại công cụ AI đang làm rất nhiều việc và rất nhiều phần suy nghĩ thay chúng ta. Chị vẫn nghĩ chúng là productivity tool tuyệt vời, chị thích build bằng chúng. Nhưng nếu dựa vào chúng tới mức không tự suy nghĩ được nữa, đó là lúc vấn đề bắt đầu. Chị cho rằng người trong ngành tech là "stewards", người giữ gìn cho tương lai đó. Đúng là có rất rất nhiều người dùng AI, lặp lại: khoảng 85% developer dùng AI. Nhưng so với phần còn lại của thế giới, chỉ khoảng 16% dân số thế giới từng dùng AI, dù chỉ một lần. Chị thấy con số đó gây sốc: hoàn toàn ngược với những gì mình thấy trong ngành. (Báo cáo Microsoft Q2 2026 ghi tỉ lệ khoảng 18,8% toàn cầu và 16,2% ở Global South: [Global AI Diffusion Report](https://www.microsoft.com/en-us/corporate-responsibility/topics/ai-economy-institute/reports/global-ai-diffusion-report/).) Vì dân tech dùng các công cụ này thường xuyên, chúng ta đã "native" với chúng, kể cả người mới. Chỉ riêng việc ngồi trong khán phòng này đã khiến mình đi trước so với rất nhiều người trên thế giới. Chúng ta có khả năng lái hướng đi của ngành, hướng đi của công nghệ, và cách mọi người cuối cùng sẽ dùng công nghệ đó. Đó là một điều quan trọng phải có và phải biết dẫn dắt, vì chúng ta muốn xây tương lai mà chúng ta muốn được là một phần trong đó. Mọi phần mềm người ta dùng trên thế giới, dù là sản phẩm tiêu dùng hay chỉ là một công cụ hạ tầng, đều là thứ chúng ta đang build. Chúng ta đang dùng nhiều công cụ AI để build, nhưng chúng ta cũng có thể build guardrails và mọi thứ xung quanh để nó được build đúng cách. ## 10. Ba thứ ở cấp ngành: guardrails, sustainability, accessibility **Guardrails là thứ đầu tiên.** Chị nghĩ rất quan trọng là phải dựng safety guardrails và ưu tiên nó mỗi khi build các công cụ này, với AI nói chung. Chị là một phụ huynh, có một em bé mới chập chững. Đôi khi chị rất lo khi nghĩ tới ngày con được vào internet. Chị muốn là một phần của giải pháp: đưa cho con một cái máy tính, con tự build đồ, và chị không phải lo thuật toán nào sẽ thay đổi hoàn toàn cách con suy nghĩ. Chị muốn con tự tìm được thông tin và tự suy nghĩ. **Thứ hai, sustainable tooling.** Mọi người đều biết các vấn đề sustainability trên báo chí: sự lãng phí, vì mình có thể "bơm" ra hàng tấn thứ khi AI cho mình sản xuất nhiều hơn bao giờ hết. Nhưng thay vì "nhiều hơn bao giờ hết", mình muốn "tốt hơn bao giờ hết". Hãy tìm cách hiệu quả hơn với model mình chọn: "không nhất thiết phải ném Opus vào mọi thứ khi một Haiku là đủ". Đồng thời xét xem việc nào có thể là một script thay vì một prompt, việc nào dùng ít compute hơn được, việc nào chạy local thay vì cloud được, và dần dần tối ưu các quyết định đó để mọi thứ bền vững hơn về dài hạn. **Cuối cùng, accessibility.** AI làm cho việc build trở nên dễ tiếp cận với mọi người hơn bao giờ hết, điều đó tuyệt vời. Chị thích việc rất nhiều người, kể cả người hàng xóm có thể đã làm hỏng một website, giờ tự build được. "It's awesome." Nhưng AI tốn tiền. Và digital divide đang ngày càng rộng, vì người không trả nổi các gói subscription đắt tiền sẽ không trả. Kết quả là họ không thật sự đóng góp được vào tương lai rất agentic, rất AI-driven này, vì họ không có tiền. Nên cần tìm cách làm mọi thứ dễ tiếp cận hơn, để người không có điều kiện trả tiền vẫn có cơ hội hưởng lợi. Ba việc Cassidy đặt cho ngành tech ở tầm rộng. Ở phần sau chị chuyển xuống cấp team, với slide riêng. ## 11. Ở cấp team: systems for communicating, tuyển junior, mentorship, và group chat "roast" Trong chính team của mình, chị nghĩ rất quan trọng là phải xây **systems for communicating**. Chị nói rõ: không chỉ là chị nói với mọi người, không chỉ là mọi người nói ở hội thảo, mà là nói chung. Nghĩ về documentation, error message, ghi chú, cách quản lý meeting, cách giao tiếp. Nghĩ xem mình muốn dùng AI thế nào, chứ không phải kiểu "tôi dùng AI viết một doc cho manager, manager dùng AI tóm tắt doc đó, rồi cứ thế qua lại mãi mãi". Hãy xây hệ thống để ai cũng nhận được thông tin họ cần, để khi điều không tránh khỏi xảy ra, một thứ gì đó sập hoặc vì lý do nào đó mình không truy cập được một công cụ, mình vẫn tự xoay xở được. ![Slide We need to build the future we want to be a part of, ba gạch đầu dòng](https://homus.dev/photos/IMG_3836.JPG) Slide "We need to build the future we want to be a part of" với ba ý cho cấp team: Systems for communicating, Forward-thinking hiring practices, Mentorship pipelines. **Forward-thinking hiring practices.** Ý chị là: cần tuyển thêm junior engineer. "Tôi sẽ nói to: chúng ta cần tuyển thêm junior engineer." Trong thời AI này, với rất nhiều đợt layoff và thay đổi trong ngành, nhiều người nghĩ "mình cần senior engineer để build đúng thứ cần build, thật nhanh, để đi nhanh". Nhưng nhất quán qua những gì chị thấy: điều phân biệt một senior engineer giỏi với một senior engineer xuất sắc là người đó từng mentor ai đó. Có junior và người mới vào nghề trong team, nơi mình trả lời những câu hỏi khó và không mất kiên nhẫn trong lúc trả lời, thay vì ném câu hỏi cho một công cụ AI để lấy đáp án, giúp tất cả mọi người học, vì mình có được nhiều góc nhìn khác nhau. Đó chính là "mentorship pipelines" trên slide. Chị kể một thói quen khi làm side project. Chị lên một kế hoạch lớn, dùng plan mode của agent nào đang dùng, có khi dùng thêm một skill kiểu "grill me" (ví dụ [grill-me skill của Matt Pocock](https://github.com/mattpocock/skills/tree/main/skills/productivity/grill-me)) để soát kế hoạch thật kỹ. Và công cụ AI nói: "You're absolutely right, kế hoạch này tuyệt vời, build đi." Rồi chị đưa kế hoạch đó vào group chat của "đám engineer phờ phạc", bạn bè đã ở trong ngành lâu năm, và nói: "roast đi". Họ chỉ ra đủ điều về việc ý tưởng của chị tệ thế nào. "Và thật tuyệt, vì lần nào tôi cũng học được thứ mới." Đúng là công cụ AI rất giỏi nhớ lại thông tin và nói cho mình đủ thứ. Nhưng rất có ích khi nhận góc nhìn từ những con người khác, "người đã thấy vài chuyện", có thể nói vì sao một thứ có thể không phải ý hay, dựa trên kinh nghiệm và trên một tập kinh nghiệm đa dạng, thay vì kiểu "ý tưởng của bạn hay đấy, nhưng tôi sẽ đưa bạn lối dễ". ## 12. Learning in public, "nếu AI tắt ngày mai", và não là công cụ trí tuệ duy nhất suốt đời Tất cả cuộc nói chuyện này, tất cả phần giao tiếp này, theo chị quy về một điều: **learning in public**, bây giờ hơn bao giờ hết. Chị không chỉ nói viết blog nhiều hơn, dù chị nghĩ ai cũng nên viết blog. Ý chị là ghi chú, documentation, các ví dụ mình có khi làm việc: mình sẽ liên tục học lại context từ đầu theo thời gian, hay mình dùng được công cụ và tài nguyên mình vẫn đang tự tạo ra để giao tiếp với người khác, và giao tiếp với cả công cụ của mình, để build tốt hơn? Rồi chị đặt một thí nghiệm tưởng tượng: giả sử công cụ của bạn sập. - Kiến thức bạn có có đưa bạn qua được không? "Kiến thức" ở đây là documentation thật, chữ nghĩa trong đầu bạn, tất cả. - Team của bạn có đưa bạn qua được không? - Khách hàng và stakeholder có đưa bạn qua được không? - Nếu AI bị tắt ngày mai, bạn có còn ship được không? Chị nghĩ nhiều người trong phòng vẫn ship được phần nào, có thể không nhanh bằng, nhưng chắc là được. Dù vậy mình vẫn muốn có sẵn những tài nguyên đó. Mình không muốn chỉ ném mọi thứ vào hộp đen rồi nhận kết quả ở đầu ra. - Và một lần nữa: hồ sơ của bạn, decision log và mọi thông tin bạn từng ghi ở đâu đó, có đưa bạn qua được không? Bốn nguồn Cassidy hỏi lần lượt: nếu công cụ AI biến mất, thứ gì còn giữ bạn đứng được. Mỗi nguồn là một thứ phải được build dần từ bây giờ, không thể dựng lúc sự cố xảy ra. Chị nói điều đó quan trọng vì mình muốn tiếp tục luyện bộ não, kể cả khi việc đó hơi sốt ruột, khi mình phải đi qua effortful learning thay vì chỉ nói "cứ ship rồi đi tiếp". Vì điều quan trọng nhất: **bộ não của chúng ta mới là intelligence tool**, không hẳn là các công cụ AI. Model sẽ tới rồi đi, nhưng bộ não là công cụ trí tuệ duy nhất mình có suốt cả đời. Nó không biến mất cho tới ngày mình qua đời. Nên mình không muốn nó chùn lại rồi trôi mất chỉ vì mình giao hết việc suy nghĩ cho một thứ, thay vì suy nghĩ có phản biện, không chỉ về thứ mình build mà còn về cách build tốt hơn, và build tốt hơn cho người khác. Câu kết: "Because you do want to scale your thinking, but you have to be able to share your thinking." Mình muốn scale suy nghĩ của mình, nhưng mình phải chia sẻ được suy nghĩ đó, thứ "đến từ cái noggin" (cái đầu). "Dễ thương đúng không?" Chị cảm ơn khán giả và nói ai có suy nghĩ gì về talk thì cứ báo chị. Bài viết cùng tinh thần trên blog của chị: ["Do not give up your brain"](https://cassidoo.co/post/good-brain/). ## 13. Q&A 1: bản đồ, kỹ năng mất đi, và kiến thức nào nên automate MC nói còn vài phút cho câu hỏi. Câu hỏi online duy nhất gửi tới là nghiên cứu MIT nằm ở đâu, nhưng link có trong slide. Cassidy xác nhận slide nằm trên GitHub của chị, [github.com/cassidoo](https://github.com/cassidoo). MC tự đặt câu hỏi. Anh kể hồi làm về maps, người ta bảo anh rằng Google Maps và các thứ tương tự sẽ khiến mọi người ngu đi, không đọc được bản đồ nữa. Điều đó đúng: đó là một bộ kỹ năng mình không cần nữa, vì bản đồ nay có sẵn hết ("đôi khi chúng lỗi thời khoảng sáu năm, nhưng đó là chuyện khác"). Anh thích những lo ngại và nguy cơ chị nêu, nhưng hỏi: có phải cũng có một cơ hội tốt, là tìm ra những kiến thức mình không cần nữa bằng cách automate chúng đi? Cassidy đồng ý một phần. Vai trò software engineer không hẳn đang biến mất, mà đang thay đổi và tiến hoá theo thời gian. Chị không nói mọi người nên kiểu "tôi không cần AI, tôi tự làm hết". Nhưng chị nghĩ có cơ hội để hỏi: làm sao mình học được thứ tiếp theo mà vẫn tiến hoá kiến thức đó cùng với con người, để mọi người cùng lớn lên và "trả ơn về phía trước" trong lúc build. Điều đó sẽ tiến hoá theo thời gian. Đúng là có lẽ chúng ta sẽ không còn viết toàn bộ code bằng tay nữa; có lẽ đó không phải tương lai đang tới. Nhưng điều đó không có nghĩa là hiểu một hệ thống đang làm gì là một kỹ năng mất hẳn. ## 14. Q&A 2: chi phí token, agent đi lạc, bot traffic, và trách nhiệm của team ### Chi phí: làm developer lại tốn tiền MC nói một điều khiến anh khó chịu, nối với ý của chị về khoảng cách giữa người có và người không có trong thế giới AI. Lúc đầu mọi thứ được VC tài trợ, mọi thứ miễn phí và tuyệt vời mãi mãi. Rồi đột nhiên token có giá thế này, rồi thế kia. Anh thấy một làn sóng ngược: người ta bắt đầu tự host model trên máy mình, và anh nghĩ nó đủ nhanh. Nhưng rồi sẽ đi về đâu? Anh thấy đây là vấn đề thật: đột nhiên làm developer lại tốn tiền. Với open source, suốt 20 năm chúng ta đã nói "hãy làm nó miễn phí, và chỉ kỹ năng của bạn mới là thứ đưa bạn vào nghề". Cassidy nói chị hi vọng đây là một con lắc: mọi thứ từng đắt, rồi rẻ đi, giờ lại đắt hơn, và hi vọng sẽ quay lại với năng lực tính toán tốt hơn, rẻ hơn, với nhiều tối ưu hơn và, lại là, sustainable tooling trong cách token được tạo ra và sử dụng. "Nó gần như là một loại tiền tệ mới." ### Agent đi lạc và bảo mật cơ bản MC kể anh có một mục "fake or news" trong live show của mình: anh đọc tiêu đề tin, khán giả đoán anh bịa hay tin thật. Vụ agent đi lạc viết hit piece về một người từng nằm trong đó, và ai cũng nghĩ "cái này không thể là thật", nhưng nó thật. Anh hỏi: có đáng lo là, nhất là với OpenClaw, người ta trao quá nhiều quyền cho máy tới mức không còn hiểu bảo mật cơ bản, và đánh đổi nó để lấy sự tiện lợi? Cassidy nói chị rất lo về điều đó. Mùa hè này Cloudflare công bố rằng bot traffic đã chính thức vượt human traffic trên internet ([Tom's Hardware đưa tin](https://www.tomshardware.com/tech-industry/artificial-intelligence/bots-have-now-passed-human-traffic-online-cloudflare-boss-laments-says-agentic-traffic-wasnt-expected-to-eclipse-real-people-until-next-year)), "mind blowing". Hãy nghĩ tới tất cả các bot ngoài kia, có lúc làm theo chỉ dẫn, có lúc go rogue. Chị chắc nhiều người trong khán phòng từng bị bố mẹ đưa cho xem một thứ gì đó, và mình phải nói "không phải thật đâu", rồi giải thích đó là AI. Chị mừng là có những công cụ như [SynthID](https://deepmind.google/models/synthid/) để nhận biết nội dung có phải AI tạo ra hay không, và có những cộng đồng online làm việc đó. Chị hi vọng sẽ có thêm quy định và thêm guardrails để bớt kẻ xấu. Nhưng đây là thực tế bây giờ: deepfake đang xảy ra, tin giả đang lan, agent đi lạc đang phạm tội, và mình phải tìm cách chặn trước khi, "tôi không biết nữa", một điều còn tệ hơn xảy ra. ### Gắn nhãn AI, và ai chịu trách nhiệm dạy MC nói đúng là có thể quản lý các frontier model, nhưng người ta chỉ cần tải một model local, gỡ guardrails và vẫn làm được. Ở châu Âu giờ đã có luật: nếu một hình ảnh do AI tạo ra thì phải có nhãn AI, nhất là trong tin tức (quy định minh bạch của EU AI Act, [Article 50](https://artificialintelligenceact.eu/article/50/)). "Đừng bàn tới chuyện đó có phải vấn đề tự do ngôn luận không." Nhưng anh thấy rõ ràng có quá nhiều slop đang được tạo ra, và gắn cờ cho nó là điều tốt. Anh nói chuyện sinh viên cũng rất thú vị: chúng ta đã mất bao năm dạy người ta về performance, giờ họ chỉ tạo ra hàng tấn code mà không nhìn vào. Anh hỏi: các công ty làm tooling, xây những hệ thống như vậy, có nên được yêu cầu cho người dùng biết nhiều hơn về kết quả của thứ họ tạo ra không? Cassidy nói có. Đồng thời chị nghĩ đây là chuyện giáo dục, và đó là chỗ việc nói chuyện với team, có người review code, trở nên quan trọng. Đúng là ngày càng nhiều agent sẽ review code, ngày càng nhiều agent sẽ viết code, nhưng phải có một lớp học hỏi nào đó. Ở trạng thái hiện tại, chị nghĩ lớp đó đến từ việc nói chuyện với các engineer khác. Chị không biết ba tháng nữa sẽ thế nào vì mọi thứ thay đổi quá nhanh. Nhưng hiện giờ, trách nhiệm nằm ở các team đang thật sự tạo ra code. ![Cassidy Williams và MC trên sân khấu Mainstage, màn hình hiện tên talk](https://homus.dev/photos/IMG_3837.JPG) Cassidy và MC trên sân khấu Mainstage ở phần Q&A. Màn hình hiện tên talk và chức danh chính thức: Senior Director of Developer Advocacy, GitHub. MC cảm ơn chị, nhắc chị sẽ có mặt ở booth GitHub cho các câu hỏi tiếp, và hẹn gặp ở after party tối đó. Anh giới thiệu trước phiên tiếp theo sau năm phút nghỉ: một speaker từng build một phần phần cứng dùng trong Guitar Hero và giờ làm cho Oculus, sẽ nói về AI và game, và anh ấy đang lo talk của mình nghe hơi chán, nên mọi người hãy cổ vũ nhiệt tình. ## Nguồn và link - Trang session chính thức: [Our Brains in the AI Era, WeAreDevelopers World Congress NA 2026](https://www.wearedevelopers.com/world-congress-north-america/agenda/sessions/our-brains-in-the-ai-era-1302819) - Cassidy Williams: [AI manifesto (cassidoo.co/ai)](https://cassidoo.co/ai/) · [Do not give up your brain](https://cassidoo.co/post/good-brain/) · [github.com/cassidoo](https://github.com/cassidoo) (slide nằm trên GitHub của chị) - [JetBrains State of the Developer Ecosystem 2025](https://devecosystem-2025.jetbrains.com/) - Microsoft AI Economy Institute: [Global AI Diffusion Report](https://www.microsoft.com/en-us/corporate-responsibility/topics/ai-economy-institute/reports/global-ai-diffusion-report/) · [The continued state of global AI diffusion in 2026](https://blogs.microsoft.com/on-the-issues/2026/09/21/the-continued-state-of-global-ai-diffusion-in-2026/) - GitHub: [Octoverse 2025](https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/) · [GitHub Universe](https://githubuniverse.com/). Số PR do agent tạo và commit mỗi tuần là số Cassidy trình bày trên slide; chưa tìm được bài công bố riêng. - MIT Media Lab: [Your Brain on ChatGPT](https://www.media.mit.edu/projects/your-brain-on-chatgpt/overview/) · [arXiv 2506.08872](https://arxiv.org/abs/2506.08872) (link ngắn trên slide: gh.io/braindecline) - OpenClaw và matplotlib: [openclaw/openclaw](https://github.com/openclaw/openclaw) · [matplotlib](https://github.com/matplotlib/matplotlib) · [An AI Agent Published a Hit Piece on Me](https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me/) · [Tom's Hardware](https://www.tomshardware.com/tech-industry/artificial-intelligence/rogue-openclaw-ai-agent-wrote-and-published-hit-piece-on-a-python-developer-who-rejected-its-code-disgruntled-bot-accuses-matplotlib-maintainer-of-discrimination-and-hypocrisy-later-backtracks-with-an-apology) - Matt Pocock, [grill-me skill](https://github.com/mattpocock/skills/tree/main/skills/productivity/grill-me) - Bot traffic vượt human traffic: [Tom's Hardware về công bố của Cloudflare](https://www.tomshardware.com/tech-industry/artificial-intelligence/bots-have-now-passed-human-traffic-online-cloudflare-boss-laments-says-agentic-traffic-wasnt-expected-to-eclipse-real-people-until-next-year) - [SynthID (Google DeepMind)](https://deepmind.google/models/synthid/) · [EU AI Act, Article 50](https://artificialintelligenceact.eu/article/50/) - Chưa tìm được nguồn: câu chuyện về người hàng xóm Mira và PR thêm badge (chuyện cá nhân của speaker).