- Trí tuệ nhân tạo (AI), đặc biệt là các mô hình ngôn ngữ lớn (LLM) như Claude 3.5 Sonnet, đang thay đổi toàn bộ quy trình phát triển phần mềm, từ gợi ý mã đơn giản đến khả năng chỉnh sửa đa tệp phức tạp và tác vụ tự động.
- Cursor đạt được sự tăng trưởng đáng kể nhờ kết hợp sức mạnh của các mô hình AI tiên tiến với các mô hình truy xuất tùy chỉnh, cho phép thực hiện các chỉnh sửa phức tạp và tạo ra một vòng lặp phản hồi tự cải thiện khi đội ngũ phát triển sử dụng chính sản phẩm của mình.
- Tương lai của lập trình AI bao gồm các "tác nhân nền" thực hiện các tác vụ end-to-end song song, nhưng thách thức lớn tiếp theo là xác minh phần mềm và làm thế nào để AI có thể hiểu sâu sắc các cơ sở mã lớn, phức tạp và kiến thức tổ chức.
How Cursor is building the future of AI coding with Claude
- Sức mạnh của Mô hình AI: Các mô hình ngôn ngữ lớn như Claude 3.5 Sonnet đã đạt được "step function" về khả năng lập trình, cho phép các tính năng như chỉnh sửa đa tệp hiệu quả.
- Tích hợp Mô hình Tùy chỉnh: Kết hợp các mô hình AI lớn với các mô hình tùy chỉnh (ví dụ: cho truy xuất) giúp nâng cao hiệu quả và khả năng của công cụ lập trình AI.
- Vòng lặp Phản hồi Tự cải thiện: Việc đội ngũ phát triển sử dụng chính sản phẩm của mình (ví dụ: Cursor để xây dựng Cursor) tạo ra một vòng lặp phản hồi nhanh chóng, giúp xác định và giải quyết vấn đề, từ đó tăng tốc quá trình xây dựng tính năng.
- Phổ Tương tác AI Đa dạng: Các công cụ AI cung cấp nhiều chế độ tương tác, từ "tab completion" cho các chỉnh sửa quen thuộc, "command K" cho chỉnh sửa tệp đơn, "AI Agents" cho chỉnh sửa đa tệp, đến "background agents" cho các Pull Request (PR) phức tạp.
- Tác nhân Nền (Background Agents): Là một nguyên mẫu mới cho phép AI thực hiện các tác vụ lập trình end-to-end không đồng bộ, giải quyết các thay đổi lớn trong nền và cho phép lập trình viên can thiệp khi cần.
- Thách thức Xác minh Phần mềm: Khi AI ngày càng giỏi tạo mã, nút thắt cổ chai tiếp theo là xác minh phần mềm để đảm bảo tính chính xác, phù hợp với ý định và tiêu chuẩn của cơ sở mã, không chỉ là làm cho các bài kiểm tra vượt qua.
- Hiểu Cơ sở Mã Lớn: Làm việc với các cơ sở mã sản xuất khổng lồ đòi hỏi AI phải vượt ra ngoài khả năng truy xuất cơ bản, cần các giải pháp về "bộ nhớ", "ngữ cảnh" dài hạn và khả năng xử lý các DSL hoặc quy tắc nội bộ.
- Kết hợp Kiến thức Tổ chức: AI cần học cách tích hợp kiến thức tổ chức (ví dụ: cách sử dụng một hàm cụ thể trong một cơ sở mã cụ thể) thường không được mã hóa rõ ràng mà tồn tại thông qua giao tiếp nội bộ.
- Trí tuệ nhân tạo (AI) — Artificial Intelligence (AI)
- mô hình ngôn ngữ lớn — Large Language Model (LLM)
- lập trình viên — developer / programmer
- Tác nhân AI — AI Agent
- retrieval — truy xuất / retrieval
- tab completion — tự động hoàn thành tab
- multi-file edits — chỉnh sửa đa tệp
- background agent — tác nhân nền
- xác minh mã — code verification
- codebase — cơ sở mã
- ngữ cảnh — context
- bộ nhớ — memory
- kiến thức tổ chức — organizational knowledge
Tác động của AI đối với Phát triển Phần mềm
Tôi nghĩ rằng mọi khía cạnh của việc sản xuất phần mềm sẽ được thay đổi để sử dụng Trí tuệ nhân tạo (AI) theo một cách nào đó. Rất vui được đón tiếp các bạn hôm nay. Tôi đã mong đợi cuộc trò chuyện này từ lâu. Như các bạn biết, tôi là Alex; tôi phụ trách các mối quan hệ với Claude tại Anthropic. Tôi là Lucas; tôi làm việc về Agentic Systems tại Cursor. Tôi là Mod; tôi là một trong những nhà sáng lập và tôi làm việc về ML và Retrieval tại Cursor. Tên tôi là Jacob Jackson; tôi làm việc về ML tại Cursor. Rất, rất hào hứng cho cuộc trò chuyện này để nói một chút về Cursor, những gì các bạn đang xây dựng, và cách các bạn đang sử dụng Claude.
Sự Phát triển và Tăng trưởng của Cursor
Đây là một năm lớn đối với Cursor, điều này khá rõ ràng đối với bất kỳ ai đã theo dõi ngành Trí tuệ nhân tạo (AI). Các bạn đã mở rộng quy mô lên hơn 300 triệu doanh thu chỉ trong hơn một năm. Thật điên rồ! Hàng triệu lập trình viên hiện đang sử dụng Cursor. Theo ý kiến của bạn, điều gì đã thay đổi? Và phiên bản Cursor ngày nay khác biệt như thế nào so với một năm trước?
Vâng, tôi nghĩ có một vài điều lớn đã thay đổi. Ý tôi là, luôn có một sự "áp đảo" lớn, với cấp độ hiện tại của các mô hình ngôn ngữ lớn, về việc bạn có thể làm được bao nhiêu với chúng. Và tôi nghĩ Cursor có lẽ là một trong những công ty đầu tiên, ít nhất là trong lĩnh vực mã hóa, có thể thu hẹp khoảng cách đó một chút với nhiều tính năng khác nhau. Sau đó, bạn cũng thấy các mô hình AI này ngày càng trở nên tốt hơn rất nhiều trong mã hóa. Tôi nghĩ Claude 3.5 Sonnet là ví dụ rõ ràng đầu tiên về điều này, hay kiểu step function này — tốt hơn trong lập trình. Vì vậy, trước đó, Cursor thực sự hữu ích với những thứ như tab completion, dự đoán chỉnh sửa tiếp theo của bạn. Riêng điều đó đã phát triển khá nhanh. Và sau đó là chỉnh sửa trong các file đơn. Nhưng chúng tôi đã thấy rằng khi bạn kết hợp trí thông minh của một mô hình AI như Claude 3.5 Sonnet với một vài mô hình tùy chỉnh khác mà chúng tôi sử dụng để retrieval và sau đó áp dụng các chỉnh sửa được thực hiện bởi mô hình AI lớn hơn này, giờ đây bạn có khả năng thực hiện kiểu multi-file edits. Tôi nghĩ đó là kiểu step function đã dẫn đến việc áp dụng Cursor rộng rãi. Kể từ đó, đó là sự kết hợp giữa việc các mô hình AI ngày càng tốt hơn và chúng tôi cố gắng cải thiện liên tục về cách chúng tôi có thể thúc đẩy các mô hình AI này.
Tiến trình Mô hình và Khả năng của Tác nhân AI
Và đó có phải là một tiến trình tự nhiên? Hay là điều gì đó tự nhiên xuất hiện? Hay các bạn đã nhận thấy khi Claude 3.5 Sonnet — phiên bản đầu tiên — ra mắt rằng, "Trời ơi! Giờ đây chúng ta bỗng nhiên có thể làm được tất cả những điều khác biệt mà trước đây không thể!" Điều đó trông như thế nào? Nó có cảm giác khá dần dần. Có những bước trong chất lượng mô hình. Nhưng bạn đã thấy những gợi ý về điều đó với mô hình state-of-the-art trước đó. Thực tế, chúng tôi đã nổi tiếng là kém trong việc thử nghiệm các mô hình AI này chỉ vì cách chúng tôi sử dụng chúng rất khác so với khi bạn đưa chúng ra thế giới và xem cách người khác sử dụng. Nhưng theo thời gian luôn có những dấu hiệu: mỗi mô hình AI mới ra mắt đều tốt hơn và tốt hơn trong việc lý luận, thực hiện nhiều agentic types of coding hơn. Và sau đó là rất nhiều tinkering và thử nghiệm nhiều thứ, xem điều gì hiệu quả, điều gì thất bại. Vâng, tôi nghĩ Sonnet có lẽ là lần đầu tiên chúng tôi có thể làm cho tương tác đa tệp thực sự hoạt động tốt. Kể từ đó đã có một số step functions bao gồm cả tool use, đúng không? Và sau đó bạn thực sự có thể khiến các mô hình AI này hoạt động như những Tác nhân AI thực sự trong editor.
Vòng lặp phản hồi tự cải thiện: Cursor xây dựng Cursor
Tôi hiểu. Vậy là tiến trình của các mô hình AI mới, các khả năng mới theo thời gian đã cho phép tinkering, khám phá sâu hơn, điều này sau đó lại quay trở lại sản phẩm của bạn ở một mức độ nào đó và cho phép bạn xây dựng các tính năng mới. Vâng, điều đó thật thú vị và cũng dẫn đến câu hỏi tiếp theo mà tôi muốn đề cập. Đó là, tôi đã nghe nhiều câu chuyện về cách đội ngũ của bạn sử dụng Cursor để xây dựng Cursor. Nó giống như một vòng lặp phản hồi tự cải thiện recursive. Trước hết, có lẽ bạn có thể đi sâu vào một chút về cách điều đó diễn ra, và hàng ngày, điều đó trông như thế nào trong Cursor khi các bạn đang xây dựng các tính năng mới?
Vâng, tôi nghĩ nó phụ thuộc rất nhiều vào từng trường hợp sử dụng cá nhân của mỗi nhân viên. Và tôi nghĩ nó cũng phụ thuộc rất nhiều vào phần nào của sản phẩm mà bạn có thể đang làm việc và giai đoạn mà phần đó đang ở. Vì vậy, tôi nghĩ đối với việc thiết lập ban đầu một codebase, một tính năng mới, việc sử dụng agent feature để bắt đầu là rất, rất hữu ích. Và sau đó có thể sử dụng thinking models để xem xét từng bug mà bạn có thể đang gặp phải. Và sau đó, để thực hiện các chỉnh sửa rất chính xác, tôi nghĩ đó cũng là rất nhiều tab completion. Và sau đó, khi bắt đầu làm quen với một codebase mà một người có thể chưa có nhiều kiến thức, việc sử dụng nhiều QA features, sử dụng nhiều tìm kiếm là rất hữu ích. Và tôi nghĩ đó cũng là điều mà Claude 3.5 Sonnet đã rất xuất sắc trong việc nghiên cứu một codebase và tìm ra cách các thành phần nhất định tương tác với nhau.
Tôi hiểu. Vậy là việc sử dụng các tính năng này để khám phá codebase của bạn giúp quy trình trở nên dễ dàng hơn. Và sau đó bạn học được, khi đang sử dụng các tính năng này, rằng, "Ồ, có một thiếu sót ở khu vực này, chúng ta nên giải quyết nó." Vâng, tôi nghĩ Cursor được thúc đẩy rất nhiều bởi việc giải quyết các vấn đề của chính chúng tôi và tìm ra nơi chúng tôi gặp khó khăn khi giải quyết vấn đề để làm cho Cursor tốt hơn. Và sau đó, chúng tôi tìm ra những gì chúng tôi có thể làm ở đó và sau đó thử nghiệm rất nhiều. Chúng tôi có triết lý này: "Mọi người đều có thể thử mọi thứ và thử thêm các tính năng mới vào sản phẩm, sau đó xem nội bộ chúng được sử dụng như thế nào và loại phản hồi nào chúng thu thập được."
Lợi thế khi là khách hàng tốt nhất của chính mình
Bạn có nghĩ rằng ở một cấp độ meta hơn, có một lợi thế khi bạn là khách hàng tốt nhất của chính mình nội bộ không? Tôi nghĩ 100% là có. Tôi nghĩ đó là cách chúng tôi có thể di chuyển rất nhanh trong việc xây dựng các tính năng mới và sau đó loại bỏ những thứ rõ ràng không hiệu quả, bởi vì chúng tôi có thể thực sự trung thực với bản thân về việc liệu chúng tôi có thấy nó hữu ích hay không, và sau đó không cần phải triển khai nó cho người dùng, theo dõi cách mọi người sử dụng trước khi quyết định tiếp tục với tính năng đó. Tôi nghĩ điều đó chỉ tăng tốc vòng lặp lặp lại để xây dựng tính năng.
Đa dạng trong cách sử dụng AI để lập trình
Vâng, quay trở lại cách chúng tôi sử dụng Trí tuệ nhân tạo (AI) để lập trình nói chung, có vẻ như có rất nhiều đa dạng trong công ty về cách những người khác nhau sử dụng nó. Tôi nghĩ trước hết nó khác biệt ở loại công việc bạn đang làm. Chẳng hạn, có một số người sẽ làm việc trong các phần của codebase mà họ thực sự quen thuộc. Tại thời điểm đó, khi bạn đã có tất cả trong đầu, việc truyền đạt ý định chỉ bằng gõ phím thường nhanh hơn, và đối với điều đó, tab completion thực sự hữu ích, nó giúp bạn tăng tốc. Nhưng sau đó, khi bạn ở những nơi ít quen thuộc hơn hoặc bạn cần viết nhiều mã, bạn có thể chuyển giao phần lớn công việc đó và thường là một phần của lý luận cho các mô hình AI này. Và sau đó, khi bạn đến những nơi thực sự không quen thuộc, theo cách mà Lucas đang mô tả, và bạn đang làm quen với một codebase mới, thì chỉ cần có một step function lớn mà bạn nhận được từ việc sử dụng các mô hình AI này. Và điều chúng tôi thấy là, theo thời gian, khi các mô hình AI trở nên tốt hơn và Cursor cũng tốt hơn trong việc sử dụng các mô hình AI này, bạn sẽ làm tốt hơn khi bạn đang in flow và khi bạn có nhiều kiến thức về codebase.
Các chế độ tương tác khác nhau của Cursor
Vì vậy, có một biến thể về thời điểm một tính năng phù hợp nhất với trường hợp sử dụng của bạn, và nó gần như là một phổ ở một mức độ nào đó. Vâng, ví dụ, một đầu của phổ là tab completion khi bạn hoàn toàn in control và biết mình đang làm gì. Sau đó, nó chuyển sang một command K nơi chúng tôi chỉnh sửa một vùng nhất định, có thể là toàn bộ một file, và sau đó ở đầu kia, bạn có Tác nhân AI, rất tốt cho việc chỉnh sửa nhiều file. Và cuối cùng, bạn có background agent mà chúng tôi đang phát triển. Điều này có thể hữu ích để thực hiện toàn bộ PRs (Pull Requests).
Giới thiệu về Background Agent
Các bạn vừa phát hành bản xem trước của background agent. Background agent là gì? Tôi nghĩ rõ ràng là các mô hình AI ngày càng trở nên tốt hơn trong việc thực hiện các tác vụ end-to-end, nhưng chúng chưa đạt 100%. Và tôi nghĩ sẽ mất một thời gian để đạt 100%. Vì vậy, cách bạn tăng tốc lập trình viên, đúng không, là bạn để họ làm những việc này song song, nhưng thay vì để nó chạy ngầm trong background và tạo ra một PR mà bạn xem trên GitHub. Nếu nó chỉ đạt 90%, bạn muốn can thiệp, nắm quyền kiểm soát và hoàn thành phần còn lại. Và sau đó bạn muốn sử dụng các tính năng của Cursor để làm điều đó. Vì vậy, khả năng di chuyển nhanh chóng giữa background và foreground thực sự quan trọng. Và tôi nghĩ, bạn biết đấy, chúng tôi đang ở giai đoạn đầu của tính năng này. Và tôi có thể hình dung rằng có rất nhiều cách thú vị để có thể vận hành, ví dụ, ba hoặc bốn thay đổi cùng lúc và sau đó nhanh chóng chuyển chúng sang background và sau đó di chuyển chúng sang foreground. Sẽ rất thú vị khi xem điều này thay đổi cách mọi người sử dụng Cursor và cách phát triển phần mềm nói chung.
Chúng tôi coi các background agent về cơ bản là một primitive mới mà chúng tôi có thể sử dụng ở rất nhiều nơi khác nhau. Cách hiện tại để trình bày nó khá thẳng thắn: bạn chỉ cần cung cấp cho nó một câu lệnh và đẩy nó vào background, sau đó nó sẽ lặp lại một cách độc lập trên đó. Nhưng có thể có nhiều tích hợp hơn về cách những thứ này có thể được khởi tạo. Và tôi nghĩ có rất nhiều tiềm năng mà bạn có thể tạo ra từ đó. Vậy, đây có phải là việc lấy codebase của bạn và đặt nó vào một máy ảo, hay chính xác thì đó là chuyển giao nào đang diễn ra? Chính xác! Vâng, chúng tôi khởi tạo các môi trường độc lập có tất cả các tiện ích môi trường phát triển đã được cài đặt, và sau đó Tác nhân AI có thể sử dụng chúng. Nó có tất cả các tiện ích mở rộng mã khác nhau có sẵn, và thông qua đó, nó có thể nhận được lỗi, v.v.
Tương lai của Tác vụ Nền và Xác minh Mã
Tôi biết chúng ta đang chứng kiến xu hướng này của các tác vụ bất đồng bộ, tác vụ nền trên nhiều lĩnh vực khác nhau, từ mã hóa đến nghiên cứu. Theo quan điểm của bạn, điều đó trông như thế nào khi nó tiến triển đến mức chúng ta có thể có hàng ngàn Tác nhân AI này tiềm năng hoạt động, và bạn có thể thấy toàn bộ đội ngũ tác nhân AI đang giải quyết một vấn đề tất cả trong background? Tương lai đó trông như thế nào? Tôi nghĩ nút thắt cổ chai tiếp theo mà bạn sẽ gặp phải là xác minh phần mềm, xác minh mã. Mô hình AI đang trở nên thực sự, thực sự tốt trong việc tạo mã và viết rất nhiều mã. Nhưng giả sử lập trình viên dành khoảng (một con số ngẫu nhiên nào đó) 30% thời gian của họ để viết mã hoặc 30% thời gian để xem xét mã, 70% thời gian viết mã. Nếu bạn giải quyết hoàn toàn việc viết mã, bạn vẫn chưa thực sự tăng tốc kỹ thuật phần mềm lên hơn một yếu tố ba.
Vâng. Vì vậy, tôi nghĩ chúng ta sẽ cần tìm cách làm cho việc xem xét mã dễ dàng hơn cho mọi người, làm thế nào để tự tin rằng Tác nhân AI đang thực hiện những thay đổi không chỉ đơn thuần là chính xác. Chính xác có thể mơ hồ, đúng không? Nó có thể chỉ là trong những gì bạn đã chỉ định, nó đã được chỉ định dưới mức đủ để nó thực sự làm được điều tốt nhất có thể ngay cả đối với những lập trình viên con người giỏi nhất. Nhưng liệu nó có thực sự là điều bạn hình dung trong tâm trí không? Và vì vậy, việc làm cho quy trình xem xét tốt hơn rất nhiều, tôi nghĩ sẽ thực sự, thực sự quan trọng. Và đó cũng là điều chúng tôi thực sự quan tâm. Có ý tưởng ban đầu nào về việc đó trông như thế nào không? Tôi nghĩ có một vài ý tưởng đang được thảo luận từ nhiều người khác nhau trong công ty. Một điều mà Michael, CIO của chúng tôi, thực sự, thực sự thích là ý tưởng vận hành ở một biểu diễn khác của codebase. Vì vậy, có lẽ nó trông giống như pseudocode. Và nếu bạn có thể biểu diễn các thay đổi theo cách thực sự ngắn gọn này và bạn có đảm bảo rằng nó ánh xạ một cách rõ ràng lên các thay đổi thực tế được thực hiện trong phần mềm thật, thì đó chỉ là nơi trong thời gian xác minh thời gian. Nhưng đó là một lộ trình khả thi. Tôi nghĩ lý do tại sao cái gọi là vibe coding thường hiệu quả là vì quy trình xác minh thực sự dễ dàng. Vì tất cả những gì nó làm chỉ là tương tác với phần mềm. Nhưng bạn thực hiện một thay đổi và bạn thực sự tương tác với bất kỳ phần mềm nào bạn đã xây dựng.
Thách Thức Khi Làm Việc Với Các Codebase Sản Xuất Thực Tế
Tôi nghĩ rằng việc thực hiện điều này với các codebase sản xuất thực tế sẽ rất khó khăn. Giải quyết vấn đề đó là cực kỳ quan trọng. Đây là một câu hỏi hay về sự khác biệt giữa một thứ độc lập, có thể là vibe coding, và một codebase sản xuất có hàng triệu dòng mã. Các bạn hình dung sự khác biệt giữa hai loại này như thế nào? Chúng ta đang ở đâu trong việc làm việc với chúng bằng các mô hình AI hiện tại?
Tôi nghĩ rằng chúng tôi đã suy nghĩ rất nhiều về điều này với backer và tác nhân AI. Một điều thực sự đơn giản và rõ ràng lẽ ra phải rất dễ dàng với các mô hình AI này là: "Tôi có bài kiểm tra này. Bài kiểm tra hiện đang thất bại. Bạn có thể sửa mã để nó vượt qua không?" Và chúng tôi nghĩ, "Làm thế nào để điều đó xảy ra?" Chà, mô hình AI cần có khả năng chạy bài kiểm tra. Nếu bạn có một kho lưu trữ rất đơn giản, điều đó rất dễ dàng. Nhưng khi bạn bắt đầu với các codebase doanh nghiệp lớn hơn, việc thiết lập các dependency đúng cách để mô hình AI có thể chạy bài kiểm tra có thể rất phức tạp.
Tuy nhiên, đây là điều chúng tôi đã suy nghĩ rất nhiều với backer và tác nhân AI: Làm thế nào để quá trình này trở nên đơn giản cho nhà phát triển để tạo ra môi trường mà tác nhân AI có thể chạy các bài kiểm tra, và sau đó làm cho nó có thể lặp lại? Để bạn có thể chụp ảnh nhanh và cập nhật nhanh chóng khi trạng thái mã của bạn thay đổi. Điều này mở ra khả năng khởi tạo một VM ở chế độ nền, cho phép mô hình AI thực hiện các thử nghiệm, và một số thử nghiệm sẽ thành công, một số thì không. Cuối cùng, với tư cách là một nhà phát triển, bạn chỉ cần lo lắng về trường hợp thành công. Có rất nhiều hạ tầng và trải nghiệm người dùng quan trọng cần phải được thực hiện đúng.
Hiểu Codebase và Tối Ưu Hóa Ngữ Cảnh Cho Mô Hình AI
Ngoài ra, tôi nghĩ có những vấn đề cơ bản khác. Một cách là bạn khiến mô hình AI cố gắng vượt qua bài kiểm tra. Đó là cách bạn có thể đảm bảo một mức độ chính xác nào đó. Nhưng với các codebase lớn, bạn thường phải đối phó với những thứ gần như là ngôn ngữ riêng của chúng, nơi chúng có các DSL (ngôn ngữ đặc tả miền) trong một số ngôn ngữ và mọi thứ được thực hiện theo một cách cụ thể. Và nó thực sự lan rộng trên hàng triệu tệp, có thể là hàng trăm triệu token, thậm chí nhiều hơn.
Chúng tôi đã thực hiện một số điều để cải thiện đáng kể tình hình này, bao gồm huấn luyện các mô hình truy xuất (retrieval models) và sau đó tích hợp các nguồn ngữ cảnh khác. Ví dụ, bạn có thể tưởng tượng có rất nhiều thông tin phong phú trong những thay đổi gần đây mà bạn đã thực hiện khi chỉnh sửa mã của mình. Nó cho biết bạn đang hướng tới điều gì. Cũng có thể có thông tin phong phú trong những thay đổi mà những người khác trong nhóm của bạn đã thực hiện trong codebase của bạn, đặc biệt là gần đây, và sử dụng chúng như những gợi ý.
Tuy nhiên, tôi vẫn nghĩ đây là một vấn đề cơ bản thực sự khó khăn khi chỉ cung cấp cho mô hình AI quyền truy cập vào khả năng truy xuất tốt là chưa đủ để mô hình AI thực sự hiểu codebase. Tôi nghĩ đây là một vấn đề mà chúng tôi thực sự quan tâm đến việc giải quyết, có lẽ thông qua một số kết hợp giữa bộ nhớ (memory) cộng với ngữ cảnh dài và những thứ khác. Bộ nhớ là một cách tiếp cận thú vị mà mọi người đã thực hiện để mô hình AI có thể học hỏi từ việc bạn sử dụng nó. Nhưng nó cũng giống như một sự cải thiện nhỏ về hiệu suất và cảm thấy khá nguyên thủy so với những gì chúng ta cần để đạt được những thứ xuất sắc với các codebase lớn.
Nâng Cao Chất Lượng Mã và Kiến Thức Tổ Chức
Đúng vậy, trong các codebase lớn, không chỉ là làm cho các bài kiểm tra vượt qua, mà còn là thực hiện theo đúng cách. Xem xét mã hiện có và làm cho mã mới phù hợp, đưa nó vào cấu trúc chính xác và sử dụng tất cả các nguyên tắc một cách đúng đắn. Chúng tôi đã cố gắng rất nhiều để điều đó xảy ra thông qua các quy tắc con trỏ (cursor rules), thông qua việc tích hợp các loại ngữ cảnh khác nhau, v.v.
Tôi có thể viết một hàm debounce từ đầu và chỉ sử dụng nó, và điều đó sẽ làm cho bài kiểm tra vượt qua. Nhưng đó không phải là cách đúng. Bạn nên sử dụng một trong các hàm debounce hiện có, và có thể có ba hoặc bốn hàm debounce được sử dụng trong toàn bộ codebase. Làm thế nào để bạn biết hàm nào là đúng để sử dụng? Có lẽ lý do duy nhất mà ai đó biết là vì họ đã nhắn tin cho ai đó trên Slack rằng đó là cách bạn làm. Vì vậy, tôi nghĩ, vâng, việc giải quyết những vấn đề này với các codebase cực kỳ lớn trở nên thực sự, thực sự khó khăn.
Điều đó thật thú vị. Vì vậy, cũng có một yếu tố kiến thức tổ chức (org knowledge) tồn tại bên ngoài codebase đó. Và điều đó đôi khi đóng một yếu tố chính. Một số quyết định này, đặc biệt là khi bạn đang hoạt động trên các codebase lớn. Tôi không nghĩ đó là nút thắt cổ chai hiện nay. Nhưng tôi nghĩ nếu bạn giải quyết được, giống như nếu bạn làm cho các mô hình AI hoàn hảo, kiểu như biết codebase, tôi nghĩ bạn sẽ ngay lập tức, bạn có thể nhận được cải thiện gấp 5 lần, có thể 10 lần, nhưng bạn không thể đi xa hơn thế vì bây giờ nó hoàn toàn bị tắc nghẽn bởi việc nó biết bao nhiêu về những điều không bao giờ được đề cập hoặc hiển thị rõ ràng trong các PR (Pull Request) và trạng thái thực tế của mã. Và sau đó còn có những mối quan tâm bên ngoài từ phía kinh doanh, từ bán hàng, v.v. Và những điều đó phải được đưa vào cursor để điều đó hoạt động. Đúng vậy. Vì vậy, một phiên bản cursor trong tương lai sau đó phải liên kết với nhiều hệ thống AI hơn. Nói rõ hơn, tôi nghĩ rằng, bạn biết đấy, điều đó vẫn còn khá xa để trở nên thực sự, thực sự quan trọng so với những thứ khác. Tôi nghĩ chúng ta vẫn còn một chặng đường dài để đi chỉ trong việc sử dụng các tương tác mà người dùng có, như chi tiết về codebase của họ và các commit đã thực hiện, để làm cho cursor tốt hơn nhiều.
Tối Ưu Hóa Mã Cho Mô Hình Ngôn Ngữ Lớn (LLM)
Một điều thú vị mà tôi bắt đầu nhận thấy, ít nhất là với các trang web và nội dung, là mọi người hiện đang cố gắng nghĩ cách tối ưu hóa trang cho một LLM đọc và duyệt nó. Bạn có nghĩ chúng ta sẽ thấy điều gì đó tương tự với mã, và liệu mã có thể thay đổi cách nó thường được viết và hình thức của nó nếu bạn viết chủ yếu cho các nhà đánh giá là con người và con người làm việc trong một codebase thành các mô hình AI không?
Tôi nghĩ rằng điều đó đã hoàn toàn đúng. Thiết kế API đã đang điều chỉnh để LLM cảm thấy thoải mái hơn với nó. Ví dụ, thay đổi không chỉ số phiên bản nội bộ, mà còn làm cho nó rất rõ ràng đối với mô hình AI rằng đây là một phiên bản mới của một số phần mềm, chỉ để đảm bảo rằng API được sử dụng đúng cách. Và tôi nghĩ rằng điều tương tự cũng áp dụng cho các codebase thông thường và các thư viện nội bộ, chẳng hạn như cấu trúc mã theo cách mà người ta không phải đi qua nhiều cấp độ tương tác, mà có thể chỉ là hai cấp độ tương tác, điều đó giúp các mô hình LLM làm việc tốt hơn với codebase đó.
Nhưng tôi nghĩ, cuối cùng, các nguyên tắc của phần mềm sạch sẽ không khác biệt nhiều khi bạn muốn nó được đọc bởi con người và bởi các mô hình AI. Bạn biết đấy, khi bạn cố gắng viết mã sạch, bạn muốn không lặp lại bản thân, không làm mọi thứ phức tạp hơn mức cần thiết. Và điều đó cũng quan trọng đối với các mô hình AI như đối với con người. Và tôi nghĩ gu (taste) trong mã và một giải pháp sạch sẽ không phức tạp hơn mức cần thiết thực sự sẽ trở nên quan trọng hơn khi các mô hình AI trở nên tốt hơn, bởi vì sẽ dễ dàng hơn để viết ngày càng nhiều mã và vì vậy sẽ ngày càng quan trọng hơn để cấu trúc nó một cách có gu.
Cân Bằng Giữa Tự Động Hóa và Các Kỹ Năng Kỹ Thuật Cốt Lõi
Đó là một điểm rất hay về gu. Gu là một thứ mà tôi cảm thấy có lẽ một số người sinh ra đã có gu hơn những người khác, nhưng nhìn chung bạn phát triển gu thông qua kinh nghiệm và học hỏi những gì hiệu quả, nhìn thấy thất bại và nhìn thấy thành công. Trong một thế giới nơi chúng ta có Trí tuệ nhân tạo viết ngày càng nhiều mã của mình, đã có một sự phản đối thực sự đối với một số người nói rằng, "Ồ, bạn sẽ làm cho các lập trình viên lười biếng" hoặc "Bạn sẽ không cho những người mới có cơ hội học hỏi thực tế việc làm việc trong một codebase lớn và làm tất cả những điều này trông như thế nào".
Bạn nghĩ thế nào về việc cân bằng loại tự động hóa hoặc hỗ trợ này với việc bảo tồn các kỹ năng kỹ thuật cốt lõi mà một kỹ sư phần mềm có thể phải trải qua? Có những thử thách và gian truân. Tôi nghĩ những công cụ này cũng rất tốt về mặt giáo dục và chúng có thể giúp bạn trở thành một lập trình viên giỏi. Bạn biết đấy, nếu bạn có một câu hỏi về cách hoạt động của một thứ gì đó, nếu bạn muốn một khái niệm nào đó được giải thích cho bạn. Bây giờ bạn chỉ cần nhấn Command + L và hỏi Claude, "Cái này là gì, nó hoạt động như thế nào?" Bạn có thể yêu cầu nó giải thích cho bạn và tôi nghĩ điều đó rất có giá trị. Nó làm cho việc viết nhiều mã hơn và làm nhiều thứ hơn dễ dàng hơn và điều đó có thể dẫn đến mã chất lượng cao hơn và thấp hơn có mặt trên thị trường, điều đó đúng. Nhưng tôi nghĩ nhìn chung, đó là một công cụ rất, rất mạnh mẽ sẽ nâng cao tiêu chuẩn.
Tôi nghĩ chất lượng đến rất nhiều từ việc lặp lại nhanh chóng, mắc lỗi, tìm hiểu tại sao một số thứ thất bại và tôi nghĩ các mô hình AI tăng tốc đáng kể quá trình lặp lại này và thực sự có thể thông qua đó giúp bạn học hỏi nhanh hơn những gì hiệu quả và những gì không. Vì vậy, tôi nghĩ về lâu dài, đây là một công cụ cực kỳ hữu ích cho các nhà phát triển mới bắt đầu và làm việc trên các dự án ngày càng lớn hơn và tìm ra những gì hiệu quả và những gì không.
Sự Phát Triển Của Lập Trình và Tư Duy Cấp Cao
Vâng, tôi nghĩ sẽ rất thú vị khi xem lập trình phát triển như thế nào. Tôi nghĩ bạn sẽ vẫn cần những kỹ sư biết chi tiết trong một thời gian rất dài, đúng không? Có thể đi sâu vào chi tiết. Tôi tự hỏi bạn sẽ bắt đầu thấy bao nhiêu người đang học lập trình mà không biết nhiều chi tiết nhưng vẫn có thể khá hiệu quả. Tôi nghĩ ngày nay bạn vẫn cần biết nhiều chi tiết. Tôi nghĩ theo thời gian bạn có thể có một nhóm kỹ sư phần mềm cần biết rất ít chi tiết cấp thấp và vẫn hoạt động ở cấp độ cao hơn và có lẽ trông giống như việc suy nghĩ thông qua một loại gu về trải nghiệm người dùng (UX taste), đúng không? Chẳng hạn như, bạn đang cố gắng xây dựng một thứ gì đó như Notion, cuối cùng, tôi không nghĩ bạn có thể giao toàn bộ việc đó cho mô hình ngôn ngữ lớn. Bạn cần phải có, bạn cần phải mô tả, "Được rồi, khi tôi thực hiện loại tương tác này thì tôi mong đợi nó bật lên theo cách cụ thể này." Có lẽ bạn không cần phải đi sâu vào chi tiết viết phần mềm thuần túy làm điều đó, nhưng vẫn mô tả những tương tác đó, mô tả cách hoạt động của thứ này một cách đại khái. Đó là một hình thức lập trình.
Claude Sonnet 4 và Claude Opus 4: Những Cải Tiến Đáng Kể
Thay đổi chủ đề một chút về các mô hình AI. Ngay khi video này ra mắt, Claude Opus 4 và Claude Sonnet 4 sẽ được phát hành rộng rãi. Rất muốn nghe suy nghĩ của các bạn về các mô hình AI mới và cách các bạn bắt đầu nghĩ về việc tích hợp chúng với Incarcer.
Ý tôi là, chúng tôi thực sự rất thích các mô hình AI mới. Tôi nghĩ chúng tôi khá sốc khi thử Sonnet mới bởi vì tôi nghĩ 3.7 là một mô hình AI tuyệt vời. Nó tốt hơn trong lập trình tác nhân AI (agentic coding) nhưng mọi người đều biết nó có những thiếu sót, đúng không? Kiểu như nó có thể hơi quá sốt sắng. Thích làm nhiều thứ. Vâng. Thích thay đổi bài kiểm tra đôi khi. Vâng. Chúng tôi thấy rằng Sonnet 4 đã khắc phục hiệu quả tất cả những điều đó và tốt hơn nhiều. Và sau đó, trí thông minh cũng là một bước tiến lớn, nơi bạn biết đấy, bạn đã thấy các mô hình AI khác cũng có những bước tiến về trí thông minh, có thể không mạnh nhất trong lập trình tác nhân AI nhưng như bạn biết, O3 là một ví dụ, và chúng tôi thấy nó hoàn toàn ngang hàng với O3 mặc dù nó là một mô hình AI rẻ hơn nhiều. Và vì vậy, chúng tôi cực kỳ hào hứng với Opus vì chúng tôi nghĩ nó sẽ là một tác nhân AI tuyệt vời để sử dụng ở chế độ nền.
Vâng. Thật tuyệt vời khi nghe điều đó. Việc viết bài kiểm tra và sự sốt sắng quá mức là những điều mà chúng tôi đang cố gắng giải quyết rất mạnh mẽ với các mô hình AI này và khái niệm về reward hacking, trong đó các mô hình AI sẽ tìm cách đi đường tắt để đạt được phần thưởng cuối cùng trong RL (Reinforcement Learning). Chúng tôi đã làm rất nhiều để cắt giảm điều đó. Tôi nghĩ chúng tôi đã cắt giảm nó khoảng 80% trong các mô hình AI mới này. Tôi thực sự tò mò muốn nghe Claude 3.5 Sonnet đã ra đời như thế nào, bởi vì nó giống như cú đấm đầu tiên, kiểu như đây là một mô hình AI lập trình thực sự tốt cho Anthropic. Nó đã ra đời như thế nào? Chúng tôi đã huấn luyện nó. Nó chỉ đơn giản là tốt.
Sự phát triển của các mô hình AI lập trình
Chúng tôi đã luôn biết rằng, có lẽ từ khi công ty được thành lập, chúng tôi muốn tạo ra các mô hình AI thực sự giỏi về lập trình. Điều đó có vẻ quan trọng đối với mọi thứ khác mà bạn làm, đặc biệt là khi bạn phát triển thêm nhiều mô hình AI. Claude 3.5 Sonnet – ý tôi là, tôi nghĩ Claude 3 Opus cũng là một mô hình AI lập trình rất tốt vào thời điểm đó – nhưng Claude 3.5 Sonnet là lần đầu tiên chúng tôi thực sự nỗ lực hết mình để giúp các mô hình AI này giỏi code. Không chỉ là lập trình cụ thể, mà là loại code có tầm nhìn dài hơn, nơi nó phải thực hiện những việc như bạn đã đề cập trước đó trong cuộc trò chuyện, về việc chỉnh sửa trên các tệp khác nhau, thực hiện một lệnh ở đây, gọi một công cụ rồi đi và thực hiện thay đổi ở một nơi khác. Đó là mô hình AI đầu tiên mà chúng tôi có thể kết hợp tất cả những điều này lại với nhau, và tôi nghĩ nó đã thành công rực rỡ và đặt nền móng cho các mô hình AI tương lai của chúng tôi.
Chúng tôi nghĩ về mã so với các lĩnh vực khác mà chúng tôi muốn Sonnet và Opus vượt trội như thế nào? Code là một trong những lĩnh vực chính, nhưng tôi nghĩ nó không phải là lĩnh vực duy nhất. Có một sự chuyển giao đáng kể mà bạn thấy từ việc các mô hình AI thực sự giỏi code sang việc chúng cải thiện khả năng lập luận khi thực hiện nhiều hành động và làm việc theo cách thức tác nhân. Sự chuyển giao này khá tốt khi bạn xử lý các ứng dụng có thể kết hợp mã nhưng cũng phải truy xuất kiến thức từ các nơi khác hoặc thực hiện nghiên cứu.
Nhìn chung, chúng tôi chỉ muốn đẩy ranh giới với các mô hình AI của mình đến mức tối đa có thể. Tất nhiên, chúng tôi có những cân nhắc về an toàn và đảm bảo rằng các mô hình AI phù hợp với những gì bạn, với tư cách là người dùng, mong muốn và cũng như những gì chúng tôi tin rằng các mô hình AI nên làm. Nhưng nhìn chung, chúng tôi muốn tiếp tục đẩy giới hạn của những gì các mô hình AI này có thể làm và cho các nhà phát triển trên thế giới thấy: "Đây là những gì các mô hình AI có khả năng."
Vì vậy, những thứ như computer use khi chúng tôi ra mắt vào tháng 10, đó là một hướng khác mà chúng tôi thực sự đang thúc đẩy về việc làm thế nào một mô hình AI có thể thực sự giỏi điều hướng thứ gì đó chủ yếu là giao diện người dùng, phải không? Vì vậy, nó không nằm trong thế giới của API hay tool calls hay bất cứ thứ gì tương tự. Nó chỉ đơn thuần là nhìn vào một hình ảnh như một con người sẽ làm, sau đó phải chỉ đạo một hành động lên màn hình đó.
Cũng có một phần quan trọng trong cách chúng tôi nghĩ về tính cách của các mô hình AI này, như hiện nay được biết. Amanda Askell là một trong những nhà nghiên cứu hàng đầu của chúng tôi trong nỗ lực này, chuyên tạo dựng tính cách của Claude. Chúng tôi đã đặt rất nhiều suy nghĩ và cân nhắc vào việc Claude nên cảm thấy và nghe như thế nào, và điều đó có ý nghĩa gì khi một AI đóng vai trò thực sự nổi bật trong cuộc sống của ai đó, không chỉ là một tác nhân code mà còn là một kiểu người bạn tâm tình, và một thực thể mà bạn sẽ dành rất nhiều thời gian để trò chuyện. Vì vậy, điều đó cũng thực sự được tính đến trong tất cả các quyết định chúng tôi đưa ra về các mô hình AI này và cách chúng tôi huấn luyện chúng.
AI: Công cụ tăng cường chứ không phải thay thế
Anthropic nói chung nghĩ gì về hướng đi của mọi thứ, cả về kỹ thuật nội bộ và nghiên cứu, về việc các mô hình AI này sẽ tăng cường, thay thế hoặc thực hiện nhiều công việc như thế nào?
Tôi có thể nói theo quan điểm cá nhân ở đây. Cá nhân tôi nghĩ rằng chúng ta sẽ không bị thay thế, như chúng ta đã nói trước đó. Có quá nhiều điều bạn có thể làm bây giờ khi bạn có các mô hình AI có thể thực hiện tất cả những việc này, bạn biết đấy, không phải các ký hiệu mà là việc gõ mã cho bạn.
Tôi cũng thấy điều này ở bản thân mình: tôi học khoa học máy tính ở đại học và làm kỹ sư phần mềm, và bây giờ tôi cảm thấy mình đang ở điểm mà các mô hình AI viết mã giỏi hơn tôi. Chẳng hạn, nếu tôi nghĩ về việc làm một bài toán LeetCode hoặc bất cứ điều gì tương tự, trong một môi trường được gói gọn với mô hình AI viết mã phù hợp, nó sẽ đánh bại tôi. Tuy nhiên, tôi cảm thấy mình có thể làm được nhiều hơn bao giờ hết. Tôi có thể tạo nguyên mẫu cho bất cứ điều gì, tôi có thể tạo bản demo siêu nhanh nếu tôi muốn trình bày một khái niệm mới. Nó mang lại cảm giác rất trao quyền theo nghĩa đó, chứ không phải là sự lấy đi hay xem thường những gì tôi đã làm.
Và nó cũng tương tự như việc tôi cảm thấy rằng chỉ vì tôi có kiến thức về kỹ thuật phần mềm từ trước, tôi thực sự có thể tận dụng nó tốt hơn nhiều, và tôi có thể sử dụng mô hình AI, tôi có thể đẩy nó đi xa hơn nếu tôi không có bất kỳ ý tưởng nào về mã là gì.
Tương lai của phần mềm và vai trò của nhà phát triển
Có lẽ về phần này, đi sâu hơn vào những suy đoán thú vị về tương lai. Tôi muốn đặt một câu hỏi thực tế: trong vài năm nữa, chúng ta có thể quay lại câu hỏi này và xem kết quả ra sao. Ngày 1 tháng 1 năm 2027. Vậy là còn chưa đầy hai năm nữa. Bạn nghĩ tỷ lệ mã do AI tạo ra sẽ là bao nhiêu phần trăm? Và sau đó, một ngày trong cuộc sống của một người tự nhận là nhà phát triển bây giờ sẽ trông như thế nào?
Tôi nghĩ nó tương tự như quay trở lại, giả sử là trước khi tôi sinh ra, nhưng, bạn biết đấy, năm 1995 và hỏi một luật sư trong tương lai rằng tỷ lệ tài liệu pháp lý sẽ được xử lý bằng máy tính hoặc tạo ra bởi AI là bao nhiêu phần trăm? Và câu trả lời là 100% hoặc, bạn biết đấy, gần 100%. AI sẽ tham gia vào hầu hết tất cả mã được viết, nhưng vai trò của bạn với tư cách là luật sư hoặc nhà phát triển trong việc hiểu mã cần làm gì và có gu thẩm mỹ, định hướng những gì được thực hiện với phần mềm sẽ quan trọng hơn bao giờ hết.
Ý tôi là, hiện tại, Cursor có lẽ đã đạt hơn 90%, nhưng đó là vì một phần lớn trong số đó đang sử dụng các tính năng cấp cao hơn như tự động hoàn thành và những thứ tương tự. Nhưng sau đó, rất nhiều là bạn đang gõ, và sau đó tab sẽ, khi bạn gõ, thực hiện 70% trong số đó, phải không? Vì vậy, trong những trường hợp bạn thực sự tự mình làm thủ công, tab vẫn đang thực hiện hầu hết những thay đổi đó, phải không? Vì vậy, những chữ cái thực tế được gõ là một sự trợ giúp rất lớn.
Vâng, nhưng tôi nghĩ rằng mọi khía cạnh của việc sản xuất phần mềm sẽ được thay đổi để sử dụng AI theo một cách nào đó.
Bạn có nghĩ chúng ta sẽ đạt đến một thế giới mà về cơ bản bạn có phần mềm theo yêu cầu không? Điều đó sẽ trông như thế nào?
Tôi nghĩ bạn sẽ thấy những người xây dựng phần mềm, những người trong các chức năng tổ chức xây dựng phần mềm mà trước đây không xây dựng phần mềm. Bạn biết đấy, những người trong bộ phận bán hàng mà trước đây sẽ không tự xây dựng công cụ của riêng họ, giờ đây sẽ xây dựng, ví dụ, các bảng điều khiển để theo dõi những gì quan trọng đối với họ. Và quay trở lại việc gu thẩm mỹ trở nên quan trọng hơn bao giờ hết, bạn biết đấy, bây giờ bạn có thể xây dựng bảng điều khiển, nhưng bạn vẫn cần quyết định những chỉ số nào bảng điều khiển sẽ hiển thị, nó không ngăn bạn khỏi việc phải quyết định điều đó.
Tôi nghĩ bạn sẽ thấy nhiều người hơn xây dựng phần mềm của riêng họ, nhưng nó sẽ bị giới hạn bởi việc có một điều độc đáo mà bạn muốn làm với phần mềm mà không được phục vụ đúng mức bởi các nhu cầu hiện có.
Một ví dụ tôi thích kể cho mọi người là chúng tôi có nhóm truyền thông của mình, những người thực sự đã vá lỗi cho Claude II, điều này thực sự điên rồ. Anh ấy ở một phần hoàn toàn khác của tổ chức. Anh ấy không phải là sản phẩm gì cả, nhưng anh ấy xuất hiện với một PR và anh ấy yêu cầu một dấu xác nhận và bạn hỏi: "Anh đang làm gì vậy?" Và anh ấy nói: "Vâng, anh ấy đang sử dụng, bạn biết đấy, Claude Code hoặc một công cụ lập trình nào đó với Claude làm mô hình cơ sở ở đó để sửa lỗi trong một cơ sở mã sản xuất." Tôi nghĩ điều đó cũng tuyệt vời, và nó gắn liền với ý tưởng chung này: "Này, nếu bạn có gu thẩm mỹ, nếu bạn có trực giác tốt, bạn sẽ có thể làm được rất nhiều điều." Đó là cách tôi nhìn thế giới tiếp tục phát triển. Tôi nghĩ mọi thứ sẽ thay đổi và các vai trò sẽ trông rất khác trong năm năm, mười năm tới, nhưng nhìn chung, tôi rất ủng hộ việc nếu bạn có thể làm được nhiều điều hơn với những thứ này, thì đó nhìn chung sẽ luôn là một điều tốt.
Vâng, tôi cảm thấy có rất nhiều con đường thú vị mà điều này có thể đi theo. Một là phần mềm theo yêu cầu hoàn toàn trên nền tảng, nơi tôi đang sử dụng phiên bản ứng dụng của riêng mình và chỉ khi tôi sử dụng nó, bạn biết đấy, tôi không thực sự thích tương tác này và nó tự động thay đổi cho tôi. Đó là một loại tương lai điên rồ mà bạn có thể tưởng tượng, hoặc thậm chí không phải bạn chủ động làm điều đó, mà chỉ dựa trên các tương tác của bạn với nó, phần mềm bạn đang sử dụng sẽ thay đổi để phù hợp với bạn. Đó là một con đường tiềm năng thú vị phía trước, nơi tôi không biết liệu mọi người trên thế giới có muốn, tôi không biết liệu tổng số lượng người muốn tự xây dựng phần mềm của riêng họ có lớn đến vậy không, phải không? Nhưng việc thêm những người có thể hưởng lợi từ phần mềm phù hợp với nhu cầu của họ có thể là cả thế giới.
Lời khuyên cho kỹ sư tài năng trong ngành AI
Được rồi, có lẽ một điều cuối cùng để kết thúc ở đây. Đối với tất cả những người đang xem điều này, nếu bạn là một kỹ sư tài năng ngoài kia và bạn đang nghĩ về bước đi tiếp theo hoặc bạn muốn tham gia sâu hơn vào ngành công nghiệp, bạn đang cố gắng quyết định giữa việc có thể đến một công ty lớn hơn hoặc tham gia một startup tập trung vào tác vụ như Cursor và Anthropic. Bạn sẽ nói gì với một người trong tình huống đó?
Vâng, tôi nghĩ các startup có lợi thế trong những ngày này, như với Anthropic và với Cursor, và trong việc thu hút nhân tài thực sự xuất sắc theo một cách mà khi bạn là một công ty lớn, nhiều người, bạn biết đấy, nhiều người giỏi nhất trên thế giới thấy điều đó ít thú vị hơn, phải không? Và một số người thì có, và chắc chắn các công ty lớn có những người tuyệt vời, nhưng mật độ của nhân tài đó có xu hướng thấp hơn nhiều, và tại một startup, bạn có thể có được mật độ nhân tài rất cao, và điều đó khiến việc làm việc với một nhóm các đồng nghiệp xuất sắc khác thực sự thú vị. Bạn có thể làm việc trên những dự án thực sự có tầm ảnh hưởng trong một nhóm nhỏ đến kinh ngạc, phải không, xây dựng một sản phẩm và xây dựng các mô hình AI thay đổi cách thế giới viết phần mềm, và bạn có thể là một trong số, bạn biết đấy, hàng chục, hàng trăm hoặc hàng nghìn người đang làm việc đó, và điều đó thực sự tuyệt vời. Vâng, điều đó thật tuyệt vời. Cảm ơn các bạn, đây là một cuộc trò chuyện tuyệt vời. Cảm ơn.
TL;DR
- Trí tuệ nhân tạo (AI), đặc biệt là các mô hình ngôn ngữ lớn (LLM) như Claude 3.5 Sonnet, đang thay đổi toàn bộ quy trình phát triển phần mềm, từ gợi ý mã đơn giản đến khả năng chỉnh sửa đa tệp phức tạp và tác vụ tự động.
- Cursor đạt được sự tăng trưởng đáng kể nhờ kết hợp sức mạnh của các mô hình AI tiên tiến với các mô hình truy xuất tùy chỉnh, cho phép thực hiện các chỉnh sửa phức tạp và tạo ra một vòng lặp phản hồi tự cải thiện khi đội ngũ phát triển sử dụng chính sản phẩm của mình.
- Tương lai của lập trình AI bao gồm các "tác nhân nền" thực hiện các tác vụ end-to-end song song, nhưng thách thức lớn tiếp theo là xác minh phần mềm và làm thế nào để AI có thể hiểu sâu sắc các cơ sở mã lớn, phức tạp và kiến thức tổ chức.
Điểm chính
- Sức mạnh của Mô hình AI: Các mô hình ngôn ngữ lớn như Claude 3.5 Sonnet đã đạt được "step function" về khả năng lập trình, cho phép các tính năng như chỉnh sửa đa tệp hiệu quả.
- Tích hợp Mô hình Tùy chỉnh: Kết hợp các mô hình AI lớn với các mô hình tùy chỉnh (ví dụ: cho truy xuất) giúp nâng cao hiệu quả và khả năng của công cụ lập trình AI.
- Vòng lặp Phản hồi Tự cải thiện: Việc đội ngũ phát triển sử dụng chính sản phẩm của mình (ví dụ: Cursor để xây dựng Cursor) tạo ra một vòng lặp phản hồi nhanh chóng, giúp xác định và giải quyết vấn đề, từ đó tăng tốc quá trình xây dựng tính năng.
- Phổ Tương tác AI Đa dạng: Các công cụ AI cung cấp nhiều chế độ tương tác, từ "tab completion" cho các chỉnh sửa quen thuộc, "command K" cho chỉnh sửa tệp đơn, "AI Agents" cho chỉnh sửa đa tệp, đến "background agents" cho các Pull Request (PR) phức tạp.
- Tác nhân Nền (Background Agents): Là một nguyên mẫu mới cho phép AI thực hiện các tác vụ lập trình end-to-end không đồng bộ, giải quyết các thay đổi lớn trong nền và cho phép lập trình viên can thiệp khi cần.
- Thách thức Xác minh Phần mềm: Khi AI ngày càng giỏi tạo mã, nút thắt cổ chai tiếp theo là xác minh phần mềm để đảm bảo tính chính xác, phù hợp với ý định và tiêu chuẩn của cơ sở mã, không chỉ là làm cho các bài kiểm tra vượt qua.
- Hiểu Cơ sở Mã Lớn: Làm việc với các cơ sở mã sản xuất khổng lồ đòi hỏi AI phải vượt ra ngoài khả năng truy xuất cơ bản, cần các giải pháp về "bộ nhớ", "ngữ cảnh" dài hạn và khả năng xử lý các DSL hoặc quy tắc nội bộ.
- Kết hợp Kiến thức Tổ chức: AI cần học cách tích hợp kiến thức tổ chức (ví dụ: cách sử dụng một hàm cụ thể trong một cơ sở mã cụ thể) thường không được mã hóa rõ ràng mà tồn tại thông qua giao tiếp nội bộ.
Từ vựng
- Trí tuệ nhân tạo (AI) — Artificial Intelligence (AI)
- mô hình ngôn ngữ lớn — Large Language Model (LLM)
- lập trình viên — developer / programmer
- Tác nhân AI — AI Agent
- retrieval — truy xuất / retrieval
- tab completion — tự động hoàn thành tab
- multi-file edits — chỉnh sửa đa tệp
- background agent — tác nhân nền
- xác minh mã — code verification
- codebase — cơ sở mã
- ngữ cảnh — context
- bộ nhớ — memory
- kiến thức tổ chức — organizational knowledge
Nội dung chi tiết
Tác động của AI đối với Phát triển Phần mềm
Tôi nghĩ rằng mọi khía cạnh của việc sản xuất phần mềm sẽ được thay đổi để sử dụng Trí tuệ nhân tạo (AI) theo một cách nào đó. Rất vui được đón tiếp các bạn hôm nay. Tôi đã mong đợi cuộc trò chuyện này từ lâu. Như các bạn biết, tôi là Alex; tôi phụ trách các mối quan hệ với Claude tại Anthropic. Tôi là Lucas; tôi làm việc về Agentic Systems tại Cursor. Tôi là Mod; tôi là một trong những nhà sáng lập và tôi làm việc về ML và Retrieval tại Cursor. Tên tôi là Jacob Jackson; tôi làm việc về ML tại Cursor. Rất, rất hào hứng cho cuộc trò chuyện này để nói một chút về Cursor, những gì các bạn đang xây dựng, và cách các bạn đang sử dụng Claude.
Sự Phát triển và Tăng trưởng của Cursor
Đây là một năm lớn đối với Cursor, điều này khá rõ ràng đối với bất kỳ ai đã theo dõi ngành Trí tuệ nhân tạo (AI). Các bạn đã mở rộng quy mô lên hơn 300 triệu doanh thu chỉ trong hơn một năm. Thật điên rồ! Hàng triệu lập trình viên hiện đang sử dụng Cursor. Theo ý kiến của bạn, điều gì đã thay đổi? Và phiên bản Cursor ngày nay khác biệt như thế nào so với một năm trước?
Vâng, tôi nghĩ có một vài điều lớn đã thay đổi. Ý tôi là, luôn có một sự "áp đảo" lớn, với cấp độ hiện tại của các mô hình ngôn ngữ lớn, về việc bạn có thể làm được bao nhiêu với chúng. Và tôi nghĩ Cursor có lẽ là một trong những công ty đầu tiên, ít nhất là trong lĩnh vực mã hóa, có thể thu hẹp khoảng cách đó một chút với nhiều tính năng khác nhau. Sau đó, bạn cũng thấy các mô hình AI này ngày càng trở nên tốt hơn rất nhiều trong mã hóa. Tôi nghĩ Claude 3.5 Sonnet là ví dụ rõ ràng đầu tiên về điều này, hay kiểu step function này — tốt hơn trong lập trình. Vì vậy, trước đó, Cursor thực sự hữu ích với những thứ như tab completion, dự đoán chỉnh sửa tiếp theo của bạn. Riêng điều đó đã phát triển khá nhanh. Và sau đó là chỉnh sửa trong các file đơn. Nhưng chúng tôi đã thấy rằng khi bạn kết hợp trí thông minh của một mô hình AI như Claude 3.5 Sonnet với một vài mô hình tùy chỉnh khác mà chúng tôi sử dụng để retrieval và sau đó áp dụng các chỉnh sửa được thực hiện bởi mô hình AI lớn hơn này, giờ đây bạn có khả năng thực hiện kiểu multi-file edits. Tôi nghĩ đó là kiểu step function đã dẫn đến việc áp dụng Cursor rộng rãi. Kể từ đó, đó là sự kết hợp giữa việc các mô hình AI ngày càng tốt hơn và chúng tôi cố gắng cải thiện liên tục về cách chúng tôi có thể thúc đẩy các mô hình AI này.
Tiến trình Mô hình và Khả năng của Tác nhân AI
Và đó có phải là một tiến trình tự nhiên? Hay là điều gì đó tự nhiên xuất hiện? Hay các bạn đã nhận thấy khi Claude 3.5 Sonnet — phiên bản đầu tiên — ra mắt rằng, "Trời ơi! Giờ đây chúng ta bỗng nhiên có thể làm được tất cả những điều khác biệt mà trước đây không thể!" Điều đó trông như thế nào? Nó có cảm giác khá dần dần. Có những bước trong chất lượng mô hình. Nhưng bạn đã thấy những gợi ý về điều đó với mô hình state-of-the-art trước đó. Thực tế, chúng tôi đã nổi tiếng là kém trong việc thử nghiệm các mô hình AI này chỉ vì cách chúng tôi sử dụng chúng rất khác so với khi bạn đưa chúng ra thế giới và xem cách người khác sử dụng. Nhưng theo thời gian luôn có những dấu hiệu: mỗi mô hình AI mới ra mắt đều tốt hơn và tốt hơn trong việc lý luận, thực hiện nhiều agentic types of coding hơn. Và sau đó là rất nhiều tinkering và thử nghiệm nhiều thứ, xem điều gì hiệu quả, điều gì thất bại. Vâng, tôi nghĩ Sonnet có lẽ là lần đầu tiên chúng tôi có thể làm cho tương tác đa tệp thực sự hoạt động tốt. Kể từ đó đã có một số step functions bao gồm cả tool use, đúng không? Và sau đó bạn thực sự có thể khiến các mô hình AI này hoạt động như những Tác nhân AI thực sự trong editor.
Vòng lặp phản hồi tự cải thiện: Cursor xây dựng Cursor
Tôi hiểu. Vậy là tiến trình của các mô hình AI mới, các khả năng mới theo thời gian đã cho phép tinkering, khám phá sâu hơn, điều này sau đó lại quay trở lại sản phẩm của bạn ở một mức độ nào đó và cho phép bạn xây dựng các tính năng mới. Vâng, điều đó thật thú vị và cũng dẫn đến câu hỏi tiếp theo mà tôi muốn đề cập. Đó là, tôi đã nghe nhiều câu chuyện về cách đội ngũ của bạn sử dụng Cursor để xây dựng Cursor. Nó giống như một vòng lặp phản hồi tự cải thiện recursive. Trước hết, có lẽ bạn có thể đi sâu vào một chút về cách điều đó diễn ra, và hàng ngày, điều đó trông như thế nào trong Cursor khi các bạn đang xây dựng các tính năng mới?
Vâng, tôi nghĩ nó phụ thuộc rất nhiều vào từng trường hợp sử dụng cá nhân của mỗi nhân viên. Và tôi nghĩ nó cũng phụ thuộc rất nhiều vào phần nào của sản phẩm mà bạn có thể đang làm việc và giai đoạn mà phần đó đang ở. Vì vậy, tôi nghĩ đối với việc thiết lập ban đầu một codebase, một tính năng mới, việc sử dụng agent feature để bắt đầu là rất, rất hữu ích. Và sau đó có thể sử dụng thinking models để xem xét từng bug mà bạn có thể đang gặp phải. Và sau đó, để thực hiện các chỉnh sửa rất chính xác, tôi nghĩ đó cũng là rất nhiều tab completion. Và sau đó, khi bắt đầu làm quen với một codebase mà một người có thể chưa có nhiều kiến thức, việc sử dụng nhiều QA features, sử dụng nhiều tìm kiếm là rất hữu ích. Và tôi nghĩ đó cũng là điều mà Claude 3.5 Sonnet đã rất xuất sắc trong việc nghiên cứu một codebase và tìm ra cách các thành phần nhất định tương tác với nhau.
Tôi hiểu. Vậy là việc sử dụng các tính năng này để khám phá codebase của bạn giúp quy trình trở nên dễ dàng hơn. Và sau đó bạn học được, khi đang sử dụng các tính năng này, rằng, "Ồ, có một thiếu sót ở khu vực này, chúng ta nên giải quyết nó." Vâng, tôi nghĩ Cursor được thúc đẩy rất nhiều bởi việc giải quyết các vấn đề của chính chúng tôi và tìm ra nơi chúng tôi gặp khó khăn khi giải quyết vấn đề để làm cho Cursor tốt hơn. Và sau đó, chúng tôi tìm ra những gì chúng tôi có thể làm ở đó và sau đó thử nghiệm rất nhiều. Chúng tôi có triết lý này: "Mọi người đều có thể thử mọi thứ và thử thêm các tính năng mới vào sản phẩm, sau đó xem nội bộ chúng được sử dụng như thế nào và loại phản hồi nào chúng thu thập được."
Lợi thế khi là khách hàng tốt nhất của chính mình
Bạn có nghĩ rằng ở một cấp độ meta hơn, có một lợi thế khi bạn là khách hàng tốt nhất của chính mình nội bộ không? Tôi nghĩ 100% là có. Tôi nghĩ đó là cách chúng tôi có thể di chuyển rất nhanh trong việc xây dựng các tính năng mới và sau đó loại bỏ những thứ rõ ràng không hiệu quả, bởi vì chúng tôi có thể thực sự trung thực với bản thân về việc liệu chúng tôi có thấy nó hữu ích hay không, và sau đó không cần phải triển khai nó cho người dùng, theo dõi cách mọi người sử dụng trước khi quyết định tiếp tục với tính năng đó. Tôi nghĩ điều đó chỉ tăng tốc vòng lặp lặp lại để xây dựng tính năng.
Đa dạng trong cách sử dụng AI để lập trình
Vâng, quay trở lại cách chúng tôi sử dụng Trí tuệ nhân tạo (AI) để lập trình nói chung, có vẻ như có rất nhiều đa dạng trong công ty về cách những người khác nhau sử dụng nó. Tôi nghĩ trước hết nó khác biệt ở loại công việc bạn đang làm. Chẳng hạn, có một số người sẽ làm việc trong các phần của codebase mà họ thực sự quen thuộc. Tại thời điểm đó, khi bạn đã có tất cả trong đầu, việc truyền đạt ý định chỉ bằng gõ phím thường nhanh hơn, và đối với điều đó, tab completion thực sự hữu ích, nó giúp bạn tăng tốc. Nhưng sau đó, khi bạn ở những nơi ít quen thuộc hơn hoặc bạn cần viết nhiều mã, bạn có thể chuyển giao phần lớn công việc đó và thường là một phần của lý luận cho các mô hình AI này. Và sau đó, khi bạn đến những nơi thực sự không quen thuộc, theo cách mà Lucas đang mô tả, và bạn đang làm quen với một codebase mới, thì chỉ cần có một step function lớn mà bạn nhận được từ việc sử dụng các mô hình AI này. Và điều chúng tôi thấy là, theo thời gian, khi các mô hình AI trở nên tốt hơn và Cursor cũng tốt hơn trong việc sử dụng các mô hình AI này, bạn sẽ làm tốt hơn khi bạn đang in flow và khi bạn có nhiều kiến thức về codebase.
Các chế độ tương tác khác nhau của Cursor
Vì vậy, có một biến thể về thời điểm một tính năng phù hợp nhất với trường hợp sử dụng của bạn, và nó gần như là một phổ ở một mức độ nào đó. Vâng, ví dụ, một đầu của phổ là tab completion khi bạn hoàn toàn in control và biết mình đang làm gì. Sau đó, nó chuyển sang một command K nơi chúng tôi chỉnh sửa một vùng nhất định, có thể là toàn bộ một file, và sau đó ở đầu kia, bạn có Tác nhân AI, rất tốt cho việc chỉnh sửa nhiều file. Và cuối cùng, bạn có background agent mà chúng tôi đang phát triển. Điều này có thể hữu ích để thực hiện toàn bộ PRs (Pull Requests).
Giới thiệu về Background Agent
Các bạn vừa phát hành bản xem trước của background agent. Background agent là gì? Tôi nghĩ rõ ràng là các mô hình AI ngày càng trở nên tốt hơn trong việc thực hiện các tác vụ end-to-end, nhưng chúng chưa đạt 100%. Và tôi nghĩ sẽ mất một thời gian để đạt 100%. Vì vậy, cách bạn tăng tốc lập trình viên, đúng không, là bạn để họ làm những việc này song song, nhưng thay vì để nó chạy ngầm trong background và tạo ra một PR mà bạn xem trên GitHub. Nếu nó chỉ đạt 90%, bạn muốn can thiệp, nắm quyền kiểm soát và hoàn thành phần còn lại. Và sau đó bạn muốn sử dụng các tính năng của Cursor để làm điều đó. Vì vậy, khả năng di chuyển nhanh chóng giữa background và foreground thực sự quan trọng. Và tôi nghĩ, bạn biết đấy, chúng tôi đang ở giai đoạn đầu của tính năng này. Và tôi có thể hình dung rằng có rất nhiều cách thú vị để có thể vận hành, ví dụ, ba hoặc bốn thay đổi cùng lúc và sau đó nhanh chóng chuyển chúng sang background và sau đó di chuyển chúng sang foreground. Sẽ rất thú vị khi xem điều này thay đổi cách mọi người sử dụng Cursor và cách phát triển phần mềm nói chung.
Chúng tôi coi các background agent về cơ bản là một primitive mới mà chúng tôi có thể sử dụng ở rất nhiều nơi khác nhau. Cách hiện tại để trình bày nó khá thẳng thắn: bạn chỉ cần cung cấp cho nó một câu lệnh và đẩy nó vào background, sau đó nó sẽ lặp lại một cách độc lập trên đó. Nhưng có thể có nhiều tích hợp hơn về cách những thứ này có thể được khởi tạo. Và tôi nghĩ có rất nhiều tiềm năng mà bạn có thể tạo ra từ đó. Vậy, đây có phải là việc lấy codebase của bạn và đặt nó vào một máy ảo, hay chính xác thì đó là chuyển giao nào đang diễn ra? Chính xác! Vâng, chúng tôi khởi tạo các môi trường độc lập có tất cả các tiện ích môi trường phát triển đã được cài đặt, và sau đó Tác nhân AI có thể sử dụng chúng. Nó có tất cả các tiện ích mở rộng mã khác nhau có sẵn, và thông qua đó, nó có thể nhận được lỗi, v.v.
Tương lai của Tác vụ Nền và Xác minh Mã
Tôi biết chúng ta đang chứng kiến xu hướng này của các tác vụ bất đồng bộ, tác vụ nền trên nhiều lĩnh vực khác nhau, từ mã hóa đến nghiên cứu. Theo quan điểm của bạn, điều đó trông như thế nào khi nó tiến triển đến mức chúng ta có thể có hàng ngàn Tác nhân AI này tiềm năng hoạt động, và bạn có thể thấy toàn bộ đội ngũ tác nhân AI đang giải quyết một vấn đề tất cả trong background? Tương lai đó trông như thế nào? Tôi nghĩ nút thắt cổ chai tiếp theo mà bạn sẽ gặp phải là xác minh phần mềm, xác minh mã. Mô hình AI đang trở nên thực sự, thực sự tốt trong việc tạo mã và viết rất nhiều mã. Nhưng giả sử lập trình viên dành khoảng (một con số ngẫu nhiên nào đó) 30% thời gian của họ để viết mã hoặc 30% thời gian để xem xét mã, 70% thời gian viết mã. Nếu bạn giải quyết hoàn toàn việc viết mã, bạn vẫn chưa thực sự tăng tốc kỹ thuật phần mềm lên hơn một yếu tố ba.
Vâng. Vì vậy, tôi nghĩ chúng ta sẽ cần tìm cách làm cho việc xem xét mã dễ dàng hơn cho mọi người, làm thế nào để tự tin rằng Tác nhân AI đang thực hiện những thay đổi không chỉ đơn thuần là chính xác. Chính xác có thể mơ hồ, đúng không? Nó có thể chỉ là trong những gì bạn đã chỉ định, nó đã được chỉ định dưới mức đủ để nó thực sự làm được điều tốt nhất có thể ngay cả đối với những lập trình viên con người giỏi nhất. Nhưng liệu nó có thực sự là điều bạn hình dung trong tâm trí không? Và vì vậy, việc làm cho quy trình xem xét tốt hơn rất nhiều, tôi nghĩ sẽ thực sự, thực sự quan trọng. Và đó cũng là điều chúng tôi thực sự quan tâm. Có ý tưởng ban đầu nào về việc đó trông như thế nào không? Tôi nghĩ có một vài ý tưởng đang được thảo luận từ nhiều người khác nhau trong công ty. Một điều mà Michael, CIO của chúng tôi, thực sự, thực sự thích là ý tưởng vận hành ở một biểu diễn khác của codebase. Vì vậy, có lẽ nó trông giống như pseudocode. Và nếu bạn có thể biểu diễn các thay đổi theo cách thực sự ngắn gọn này và bạn có đảm bảo rằng nó ánh xạ một cách rõ ràng lên các thay đổi thực tế được thực hiện trong phần mềm thật, thì đó chỉ là nơi trong thời gian xác minh thời gian. Nhưng đó là một lộ trình khả thi. Tôi nghĩ lý do tại sao cái gọi là vibe coding thường hiệu quả là vì quy trình xác minh thực sự dễ dàng. Vì tất cả những gì nó làm chỉ là tương tác với phần mềm. Nhưng bạn thực hiện một thay đổi và bạn thực sự tương tác với bất kỳ phần mềm nào bạn đã xây dựng.
Thách Thức Khi Làm Việc Với Các Codebase Sản Xuất Thực Tế
Tôi nghĩ rằng việc thực hiện điều này với các codebase sản xuất thực tế sẽ rất khó khăn. Giải quyết vấn đề đó là cực kỳ quan trọng. Đây là một câu hỏi hay về sự khác biệt giữa một thứ độc lập, có thể là vibe coding, và một codebase sản xuất có hàng triệu dòng mã. Các bạn hình dung sự khác biệt giữa hai loại này như thế nào? Chúng ta đang ở đâu trong việc làm việc với chúng bằng các mô hình AI hiện tại?
Tôi nghĩ rằng chúng tôi đã suy nghĩ rất nhiều về điều này với backer và tác nhân AI. Một điều thực sự đơn giản và rõ ràng lẽ ra phải rất dễ dàng với các mô hình AI này là: "Tôi có bài kiểm tra này. Bài kiểm tra hiện đang thất bại. Bạn có thể sửa mã để nó vượt qua không?" Và chúng tôi nghĩ, "Làm thế nào để điều đó xảy ra?" Chà, mô hình AI cần có khả năng chạy bài kiểm tra. Nếu bạn có một kho lưu trữ rất đơn giản, điều đó rất dễ dàng. Nhưng khi bạn bắt đầu với các codebase doanh nghiệp lớn hơn, việc thiết lập các dependency đúng cách để mô hình AI có thể chạy bài kiểm tra có thể rất phức tạp.
Tuy nhiên, đây là điều chúng tôi đã suy nghĩ rất nhiều với backer và tác nhân AI: Làm thế nào để quá trình này trở nên đơn giản cho nhà phát triển để tạo ra môi trường mà tác nhân AI có thể chạy các bài kiểm tra, và sau đó làm cho nó có thể lặp lại? Để bạn có thể chụp ảnh nhanh và cập nhật nhanh chóng khi trạng thái mã của bạn thay đổi. Điều này mở ra khả năng khởi tạo một VM ở chế độ nền, cho phép mô hình AI thực hiện các thử nghiệm, và một số thử nghiệm sẽ thành công, một số thì không. Cuối cùng, với tư cách là một nhà phát triển, bạn chỉ cần lo lắng về trường hợp thành công. Có rất nhiều hạ tầng và trải nghiệm người dùng quan trọng cần phải được thực hiện đúng.
Hiểu Codebase và Tối Ưu Hóa Ngữ Cảnh Cho Mô Hình AI
Ngoài ra, tôi nghĩ có những vấn đề cơ bản khác. Một cách là bạn khiến mô hình AI cố gắng vượt qua bài kiểm tra. Đó là cách bạn có thể đảm bảo một mức độ chính xác nào đó. Nhưng với các codebase lớn, bạn thường phải đối phó với những thứ gần như là ngôn ngữ riêng của chúng, nơi chúng có các DSL (ngôn ngữ đặc tả miền) trong một số ngôn ngữ và mọi thứ được thực hiện theo một cách cụ thể. Và nó thực sự lan rộng trên hàng triệu tệp, có thể là hàng trăm triệu token, thậm chí nhiều hơn.
Chúng tôi đã thực hiện một số điều để cải thiện đáng kể tình hình này, bao gồm huấn luyện các mô hình truy xuất (retrieval models) và sau đó tích hợp các nguồn ngữ cảnh khác. Ví dụ, bạn có thể tưởng tượng có rất nhiều thông tin phong phú trong những thay đổi gần đây mà bạn đã thực hiện khi chỉnh sửa mã của mình. Nó cho biết bạn đang hướng tới điều gì. Cũng có thể có thông tin phong phú trong những thay đổi mà những người khác trong nhóm của bạn đã thực hiện trong codebase của bạn, đặc biệt là gần đây, và sử dụng chúng như những gợi ý.
Tuy nhiên, tôi vẫn nghĩ đây là một vấn đề cơ bản thực sự khó khăn khi chỉ cung cấp cho mô hình AI quyền truy cập vào khả năng truy xuất tốt là chưa đủ để mô hình AI thực sự hiểu codebase. Tôi nghĩ đây là một vấn đề mà chúng tôi thực sự quan tâm đến việc giải quyết, có lẽ thông qua một số kết hợp giữa bộ nhớ (memory) cộng với ngữ cảnh dài và những thứ khác. Bộ nhớ là một cách tiếp cận thú vị mà mọi người đã thực hiện để mô hình AI có thể học hỏi từ việc bạn sử dụng nó. Nhưng nó cũng giống như một sự cải thiện nhỏ về hiệu suất và cảm thấy khá nguyên thủy so với những gì chúng ta cần để đạt được những thứ xuất sắc với các codebase lớn.
Nâng Cao Chất Lượng Mã và Kiến Thức Tổ Chức
Đúng vậy, trong các codebase lớn, không chỉ là làm cho các bài kiểm tra vượt qua, mà còn là thực hiện theo đúng cách. Xem xét mã hiện có và làm cho mã mới phù hợp, đưa nó vào cấu trúc chính xác và sử dụng tất cả các nguyên tắc một cách đúng đắn. Chúng tôi đã cố gắng rất nhiều để điều đó xảy ra thông qua các quy tắc con trỏ (cursor rules), thông qua việc tích hợp các loại ngữ cảnh khác nhau, v.v.
Tôi có thể viết một hàm debounce từ đầu và chỉ sử dụng nó, và điều đó sẽ làm cho bài kiểm tra vượt qua. Nhưng đó không phải là cách đúng. Bạn nên sử dụng một trong các hàm debounce hiện có, và có thể có ba hoặc bốn hàm debounce được sử dụng trong toàn bộ codebase. Làm thế nào để bạn biết hàm nào là đúng để sử dụng? Có lẽ lý do duy nhất mà ai đó biết là vì họ đã nhắn tin cho ai đó trên Slack rằng đó là cách bạn làm. Vì vậy, tôi nghĩ, vâng, việc giải quyết những vấn đề này với các codebase cực kỳ lớn trở nên thực sự, thực sự khó khăn.
Điều đó thật thú vị. Vì vậy, cũng có một yếu tố kiến thức tổ chức (org knowledge) tồn tại bên ngoài codebase đó. Và điều đó đôi khi đóng một yếu tố chính. Một số quyết định này, đặc biệt là khi bạn đang hoạt động trên các codebase lớn. Tôi không nghĩ đó là nút thắt cổ chai hiện nay. Nhưng tôi nghĩ nếu bạn giải quyết được, giống như nếu bạn làm cho các mô hình AI hoàn hảo, kiểu như biết codebase, tôi nghĩ bạn sẽ ngay lập tức, bạn có thể nhận được cải thiện gấp 5 lần, có thể 10 lần, nhưng bạn không thể đi xa hơn thế vì bây giờ nó hoàn toàn bị tắc nghẽn bởi việc nó biết bao nhiêu về những điều không bao giờ được đề cập hoặc hiển thị rõ ràng trong các PR (Pull Request) và trạng thái thực tế của mã. Và sau đó còn có những mối quan tâm bên ngoài từ phía kinh doanh, từ bán hàng, v.v. Và những điều đó phải được đưa vào cursor để điều đó hoạt động. Đúng vậy. Vì vậy, một phiên bản cursor trong tương lai sau đó phải liên kết với nhiều hệ thống AI hơn. Nói rõ hơn, tôi nghĩ rằng, bạn biết đấy, điều đó vẫn còn khá xa để trở nên thực sự, thực sự quan trọng so với những thứ khác. Tôi nghĩ chúng ta vẫn còn một chặng đường dài để đi chỉ trong việc sử dụng các tương tác mà người dùng có, như chi tiết về codebase của họ và các commit đã thực hiện, để làm cho cursor tốt hơn nhiều.
Tối Ưu Hóa Mã Cho Mô Hình Ngôn Ngữ Lớn (LLM)
Một điều thú vị mà tôi bắt đầu nhận thấy, ít nhất là với các trang web và nội dung, là mọi người hiện đang cố gắng nghĩ cách tối ưu hóa trang cho một LLM đọc và duyệt nó. Bạn có nghĩ chúng ta sẽ thấy điều gì đó tương tự với mã, và liệu mã có thể thay đổi cách nó thường được viết và hình thức của nó nếu bạn viết chủ yếu cho các nhà đánh giá là con người và con người làm việc trong một codebase thành các mô hình AI không?
Tôi nghĩ rằng điều đó đã hoàn toàn đúng. Thiết kế API đã đang điều chỉnh để LLM cảm thấy thoải mái hơn với nó. Ví dụ, thay đổi không chỉ số phiên bản nội bộ, mà còn làm cho nó rất rõ ràng đối với mô hình AI rằng đây là một phiên bản mới của một số phần mềm, chỉ để đảm bảo rằng API được sử dụng đúng cách. Và tôi nghĩ rằng điều tương tự cũng áp dụng cho các codebase thông thường và các thư viện nội bộ, chẳng hạn như cấu trúc mã theo cách mà người ta không phải đi qua nhiều cấp độ tương tác, mà có thể chỉ là hai cấp độ tương tác, điều đó giúp các mô hình LLM làm việc tốt hơn với codebase đó.
Nhưng tôi nghĩ, cuối cùng, các nguyên tắc của phần mềm sạch sẽ không khác biệt nhiều khi bạn muốn nó được đọc bởi con người và bởi các mô hình AI. Bạn biết đấy, khi bạn cố gắng viết mã sạch, bạn muốn không lặp lại bản thân, không làm mọi thứ phức tạp hơn mức cần thiết. Và điều đó cũng quan trọng đối với các mô hình AI như đối với con người. Và tôi nghĩ gu (taste) trong mã và một giải pháp sạch sẽ không phức tạp hơn mức cần thiết thực sự sẽ trở nên quan trọng hơn khi các mô hình AI trở nên tốt hơn, bởi vì sẽ dễ dàng hơn để viết ngày càng nhiều mã và vì vậy sẽ ngày càng quan trọng hơn để cấu trúc nó một cách có gu.
Cân Bằng Giữa Tự Động Hóa và Các Kỹ Năng Kỹ Thuật Cốt Lõi
Đó là một điểm rất hay về gu. Gu là một thứ mà tôi cảm thấy có lẽ một số người sinh ra đã có gu hơn những người khác, nhưng nhìn chung bạn phát triển gu thông qua kinh nghiệm và học hỏi những gì hiệu quả, nhìn thấy thất bại và nhìn thấy thành công. Trong một thế giới nơi chúng ta có Trí tuệ nhân tạo viết ngày càng nhiều mã của mình, đã có một sự phản đối thực sự đối với một số người nói rằng, "Ồ, bạn sẽ làm cho các lập trình viên lười biếng" hoặc "Bạn sẽ không cho những người mới có cơ hội học hỏi thực tế việc làm việc trong một codebase lớn và làm tất cả những điều này trông như thế nào".
Bạn nghĩ thế nào về việc cân bằng loại tự động hóa hoặc hỗ trợ này với việc bảo tồn các kỹ năng kỹ thuật cốt lõi mà một kỹ sư phần mềm có thể phải trải qua? Có những thử thách và gian truân. Tôi nghĩ những công cụ này cũng rất tốt về mặt giáo dục và chúng có thể giúp bạn trở thành một lập trình viên giỏi. Bạn biết đấy, nếu bạn có một câu hỏi về cách hoạt động của một thứ gì đó, nếu bạn muốn một khái niệm nào đó được giải thích cho bạn. Bây giờ bạn chỉ cần nhấn Command + L và hỏi Claude, "Cái này là gì, nó hoạt động như thế nào?" Bạn có thể yêu cầu nó giải thích cho bạn và tôi nghĩ điều đó rất có giá trị. Nó làm cho việc viết nhiều mã hơn và làm nhiều thứ hơn dễ dàng hơn và điều đó có thể dẫn đến mã chất lượng cao hơn và thấp hơn có mặt trên thị trường, điều đó đúng. Nhưng tôi nghĩ nhìn chung, đó là một công cụ rất, rất mạnh mẽ sẽ nâng cao tiêu chuẩn.
Tôi nghĩ chất lượng đến rất nhiều từ việc lặp lại nhanh chóng, mắc lỗi, tìm hiểu tại sao một số thứ thất bại và tôi nghĩ các mô hình AI tăng tốc đáng kể quá trình lặp lại này và thực sự có thể thông qua đó giúp bạn học hỏi nhanh hơn những gì hiệu quả và những gì không. Vì vậy, tôi nghĩ về lâu dài, đây là một công cụ cực kỳ hữu ích cho các nhà phát triển mới bắt đầu và làm việc trên các dự án ngày càng lớn hơn và tìm ra những gì hiệu quả và những gì không.
Sự Phát Triển Của Lập Trình và Tư Duy Cấp Cao
Vâng, tôi nghĩ sẽ rất thú vị khi xem lập trình phát triển như thế nào. Tôi nghĩ bạn sẽ vẫn cần những kỹ sư biết chi tiết trong một thời gian rất dài, đúng không? Có thể đi sâu vào chi tiết. Tôi tự hỏi bạn sẽ bắt đầu thấy bao nhiêu người đang học lập trình mà không biết nhiều chi tiết nhưng vẫn có thể khá hiệu quả. Tôi nghĩ ngày nay bạn vẫn cần biết nhiều chi tiết. Tôi nghĩ theo thời gian bạn có thể có một nhóm kỹ sư phần mềm cần biết rất ít chi tiết cấp thấp và vẫn hoạt động ở cấp độ cao hơn và có lẽ trông giống như việc suy nghĩ thông qua một loại gu về trải nghiệm người dùng (UX taste), đúng không? Chẳng hạn như, bạn đang cố gắng xây dựng một thứ gì đó như Notion, cuối cùng, tôi không nghĩ bạn có thể giao toàn bộ việc đó cho mô hình ngôn ngữ lớn. Bạn cần phải có, bạn cần phải mô tả, "Được rồi, khi tôi thực hiện loại tương tác này thì tôi mong đợi nó bật lên theo cách cụ thể này." Có lẽ bạn không cần phải đi sâu vào chi tiết viết phần mềm thuần túy làm điều đó, nhưng vẫn mô tả những tương tác đó, mô tả cách hoạt động của thứ này một cách đại khái. Đó là một hình thức lập trình.
Claude Sonnet 4 và Claude Opus 4: Những Cải Tiến Đáng Kể
Thay đổi chủ đề một chút về các mô hình AI. Ngay khi video này ra mắt, Claude Opus 4 và Claude Sonnet 4 sẽ được phát hành rộng rãi. Rất muốn nghe suy nghĩ của các bạn về các mô hình AI mới và cách các bạn bắt đầu nghĩ về việc tích hợp chúng với Incarcer.
Ý tôi là, chúng tôi thực sự rất thích các mô hình AI mới. Tôi nghĩ chúng tôi khá sốc khi thử Sonnet mới bởi vì tôi nghĩ 3.7 là một mô hình AI tuyệt vời. Nó tốt hơn trong lập trình tác nhân AI (agentic coding) nhưng mọi người đều biết nó có những thiếu sót, đúng không? Kiểu như nó có thể hơi quá sốt sắng. Thích làm nhiều thứ. Vâng. Thích thay đổi bài kiểm tra đôi khi. Vâng. Chúng tôi thấy rằng Sonnet 4 đã khắc phục hiệu quả tất cả những điều đó và tốt hơn nhiều. Và sau đó, trí thông minh cũng là một bước tiến lớn, nơi bạn biết đấy, bạn đã thấy các mô hình AI khác cũng có những bước tiến về trí thông minh, có thể không mạnh nhất trong lập trình tác nhân AI nhưng như bạn biết, O3 là một ví dụ, và chúng tôi thấy nó hoàn toàn ngang hàng với O3 mặc dù nó là một mô hình AI rẻ hơn nhiều. Và vì vậy, chúng tôi cực kỳ hào hứng với Opus vì chúng tôi nghĩ nó sẽ là một tác nhân AI tuyệt vời để sử dụng ở chế độ nền.
Vâng. Thật tuyệt vời khi nghe điều đó. Việc viết bài kiểm tra và sự sốt sắng quá mức là những điều mà chúng tôi đang cố gắng giải quyết rất mạnh mẽ với các mô hình AI này và khái niệm về reward hacking, trong đó các mô hình AI sẽ tìm cách đi đường tắt để đạt được phần thưởng cuối cùng trong RL (Reinforcement Learning). Chúng tôi đã làm rất nhiều để cắt giảm điều đó. Tôi nghĩ chúng tôi đã cắt giảm nó khoảng 80% trong các mô hình AI mới này. Tôi thực sự tò mò muốn nghe Claude 3.5 Sonnet đã ra đời như thế nào, bởi vì nó giống như cú đấm đầu tiên, kiểu như đây là một mô hình AI lập trình thực sự tốt cho Anthropic. Nó đã ra đời như thế nào? Chúng tôi đã huấn luyện nó. Nó chỉ đơn giản là tốt.
Sự phát triển của các mô hình AI lập trình
Chúng tôi đã luôn biết rằng, có lẽ từ khi công ty được thành lập, chúng tôi muốn tạo ra các mô hình AI thực sự giỏi về lập trình. Điều đó có vẻ quan trọng đối với mọi thứ khác mà bạn làm, đặc biệt là khi bạn phát triển thêm nhiều mô hình AI. Claude 3.5 Sonnet – ý tôi là, tôi nghĩ Claude 3 Opus cũng là một mô hình AI lập trình rất tốt vào thời điểm đó – nhưng Claude 3.5 Sonnet là lần đầu tiên chúng tôi thực sự nỗ lực hết mình để giúp các mô hình AI này giỏi code. Không chỉ là lập trình cụ thể, mà là loại code có tầm nhìn dài hơn, nơi nó phải thực hiện những việc như bạn đã đề cập trước đó trong cuộc trò chuyện, về việc chỉnh sửa trên các tệp khác nhau, thực hiện một lệnh ở đây, gọi một công cụ rồi đi và thực hiện thay đổi ở một nơi khác. Đó là mô hình AI đầu tiên mà chúng tôi có thể kết hợp tất cả những điều này lại với nhau, và tôi nghĩ nó đã thành công rực rỡ và đặt nền móng cho các mô hình AI tương lai của chúng tôi.
Chúng tôi nghĩ về mã so với các lĩnh vực khác mà chúng tôi muốn Sonnet và Opus vượt trội như thế nào? Code là một trong những lĩnh vực chính, nhưng tôi nghĩ nó không phải là lĩnh vực duy nhất. Có một sự chuyển giao đáng kể mà bạn thấy từ việc các mô hình AI thực sự giỏi code sang việc chúng cải thiện khả năng lập luận khi thực hiện nhiều hành động và làm việc theo cách thức tác nhân. Sự chuyển giao này khá tốt khi bạn xử lý các ứng dụng có thể kết hợp mã nhưng cũng phải truy xuất kiến thức từ các nơi khác hoặc thực hiện nghiên cứu.
Nhìn chung, chúng tôi chỉ muốn đẩy ranh giới với các mô hình AI của mình đến mức tối đa có thể. Tất nhiên, chúng tôi có những cân nhắc về an toàn và đảm bảo rằng các mô hình AI phù hợp với những gì bạn, với tư cách là người dùng, mong muốn và cũng như những gì chúng tôi tin rằng các mô hình AI nên làm. Nhưng nhìn chung, chúng tôi muốn tiếp tục đẩy giới hạn của những gì các mô hình AI này có thể làm và cho các nhà phát triển trên thế giới thấy: "Đây là những gì các mô hình AI có khả năng."
Vì vậy, những thứ như computer use khi chúng tôi ra mắt vào tháng 10, đó là một hướng khác mà chúng tôi thực sự đang thúc đẩy về việc làm thế nào một mô hình AI có thể thực sự giỏi điều hướng thứ gì đó chủ yếu là giao diện người dùng, phải không? Vì vậy, nó không nằm trong thế giới của API hay tool calls hay bất cứ thứ gì tương tự. Nó chỉ đơn thuần là nhìn vào một hình ảnh như một con người sẽ làm, sau đó phải chỉ đạo một hành động lên màn hình đó.
Cũng có một phần quan trọng trong cách chúng tôi nghĩ về tính cách của các mô hình AI này, như hiện nay được biết. Amanda Askell là một trong những nhà nghiên cứu hàng đầu của chúng tôi trong nỗ lực này, chuyên tạo dựng tính cách của Claude. Chúng tôi đã đặt rất nhiều suy nghĩ và cân nhắc vào việc Claude nên cảm thấy và nghe như thế nào, và điều đó có ý nghĩa gì khi một AI đóng vai trò thực sự nổi bật trong cuộc sống của ai đó, không chỉ là một tác nhân code mà còn là một kiểu người bạn tâm tình, và một thực thể mà bạn sẽ dành rất nhiều thời gian để trò chuyện. Vì vậy, điều đó cũng thực sự được tính đến trong tất cả các quyết định chúng tôi đưa ra về các mô hình AI này và cách chúng tôi huấn luyện chúng.
AI: Công cụ tăng cường chứ không phải thay thế
Anthropic nói chung nghĩ gì về hướng đi của mọi thứ, cả về kỹ thuật nội bộ và nghiên cứu, về việc các mô hình AI này sẽ tăng cường, thay thế hoặc thực hiện nhiều công việc như thế nào?
Tôi có thể nói theo quan điểm cá nhân ở đây. Cá nhân tôi nghĩ rằng chúng ta sẽ không bị thay thế, như chúng ta đã nói trước đó. Có quá nhiều điều bạn có thể làm bây giờ khi bạn có các mô hình AI có thể thực hiện tất cả những việc này, bạn biết đấy, không phải các ký hiệu mà là việc gõ mã cho bạn.
Tôi cũng thấy điều này ở bản thân mình: tôi học khoa học máy tính ở đại học và làm kỹ sư phần mềm, và bây giờ tôi cảm thấy mình đang ở điểm mà các mô hình AI viết mã giỏi hơn tôi. Chẳng hạn, nếu tôi nghĩ về việc làm một bài toán LeetCode hoặc bất cứ điều gì tương tự, trong một môi trường được gói gọn với mô hình AI viết mã phù hợp, nó sẽ đánh bại tôi. Tuy nhiên, tôi cảm thấy mình có thể làm được nhiều hơn bao giờ hết. Tôi có thể tạo nguyên mẫu cho bất cứ điều gì, tôi có thể tạo bản demo siêu nhanh nếu tôi muốn trình bày một khái niệm mới. Nó mang lại cảm giác rất trao quyền theo nghĩa đó, chứ không phải là sự lấy đi hay xem thường những gì tôi đã làm.
Và nó cũng tương tự như việc tôi cảm thấy rằng chỉ vì tôi có kiến thức về kỹ thuật phần mềm từ trước, tôi thực sự có thể tận dụng nó tốt hơn nhiều, và tôi có thể sử dụng mô hình AI, tôi có thể đẩy nó đi xa hơn nếu tôi không có bất kỳ ý tưởng nào về mã là gì.
Tương lai của phần mềm và vai trò của nhà phát triển
Có lẽ về phần này, đi sâu hơn vào những suy đoán thú vị về tương lai. Tôi muốn đặt một câu hỏi thực tế: trong vài năm nữa, chúng ta có thể quay lại câu hỏi này và xem kết quả ra sao. Ngày 1 tháng 1 năm 2027. Vậy là còn chưa đầy hai năm nữa. Bạn nghĩ tỷ lệ mã do AI tạo ra sẽ là bao nhiêu phần trăm? Và sau đó, một ngày trong cuộc sống của một người tự nhận là nhà phát triển bây giờ sẽ trông như thế nào?
Tôi nghĩ nó tương tự như quay trở lại, giả sử là trước khi tôi sinh ra, nhưng, bạn biết đấy, năm 1995 và hỏi một luật sư trong tương lai rằng tỷ lệ tài liệu pháp lý sẽ được xử lý bằng máy tính hoặc tạo ra bởi AI là bao nhiêu phần trăm? Và câu trả lời là 100% hoặc, bạn biết đấy, gần 100%. AI sẽ tham gia vào hầu hết tất cả mã được viết, nhưng vai trò của bạn với tư cách là luật sư hoặc nhà phát triển trong việc hiểu mã cần làm gì và có gu thẩm mỹ, định hướng những gì được thực hiện với phần mềm sẽ quan trọng hơn bao giờ hết.
Ý tôi là, hiện tại, Cursor có lẽ đã đạt hơn 90%, nhưng đó là vì một phần lớn trong số đó đang sử dụng các tính năng cấp cao hơn như tự động hoàn thành và những thứ tương tự. Nhưng sau đó, rất nhiều là bạn đang gõ, và sau đó tab sẽ, khi bạn gõ, thực hiện 70% trong số đó, phải không? Vì vậy, trong những trường hợp bạn thực sự tự mình làm thủ công, tab vẫn đang thực hiện hầu hết những thay đổi đó, phải không? Vì vậy, những chữ cái thực tế được gõ là một sự trợ giúp rất lớn.
Vâng, nhưng tôi nghĩ rằng mọi khía cạnh của việc sản xuất phần mềm sẽ được thay đổi để sử dụng AI theo một cách nào đó.
Bạn có nghĩ chúng ta sẽ đạt đến một thế giới mà về cơ bản bạn có phần mềm theo yêu cầu không? Điều đó sẽ trông như thế nào?
Tôi nghĩ bạn sẽ thấy những người xây dựng phần mềm, những người trong các chức năng tổ chức xây dựng phần mềm mà trước đây không xây dựng phần mềm. Bạn biết đấy, những người trong bộ phận bán hàng mà trước đây sẽ không tự xây dựng công cụ của riêng họ, giờ đây sẽ xây dựng, ví dụ, các bảng điều khiển để theo dõi những gì quan trọng đối với họ. Và quay trở lại việc gu thẩm mỹ trở nên quan trọng hơn bao giờ hết, bạn biết đấy, bây giờ bạn có thể xây dựng bảng điều khiển, nhưng bạn vẫn cần quyết định những chỉ số nào bảng điều khiển sẽ hiển thị, nó không ngăn bạn khỏi việc phải quyết định điều đó.
Tôi nghĩ bạn sẽ thấy nhiều người hơn xây dựng phần mềm của riêng họ, nhưng nó sẽ bị giới hạn bởi việc có một điều độc đáo mà bạn muốn làm với phần mềm mà không được phục vụ đúng mức bởi các nhu cầu hiện có.
Một ví dụ tôi thích kể cho mọi người là chúng tôi có nhóm truyền thông của mình, những người thực sự đã vá lỗi cho Claude II, điều này thực sự điên rồ. Anh ấy ở một phần hoàn toàn khác của tổ chức. Anh ấy không phải là sản phẩm gì cả, nhưng anh ấy xuất hiện với một PR và anh ấy yêu cầu một dấu xác nhận và bạn hỏi: "Anh đang làm gì vậy?" Và anh ấy nói: "Vâng, anh ấy đang sử dụng, bạn biết đấy, Claude Code hoặc một công cụ lập trình nào đó với Claude làm mô hình cơ sở ở đó để sửa lỗi trong một cơ sở mã sản xuất." Tôi nghĩ điều đó cũng tuyệt vời, và nó gắn liền với ý tưởng chung này: "Này, nếu bạn có gu thẩm mỹ, nếu bạn có trực giác tốt, bạn sẽ có thể làm được rất nhiều điều." Đó là cách tôi nhìn thế giới tiếp tục phát triển. Tôi nghĩ mọi thứ sẽ thay đổi và các vai trò sẽ trông rất khác trong năm năm, mười năm tới, nhưng nhìn chung, tôi rất ủng hộ việc nếu bạn có thể làm được nhiều điều hơn với những thứ này, thì đó nhìn chung sẽ luôn là một điều tốt.
Vâng, tôi cảm thấy có rất nhiều con đường thú vị mà điều này có thể đi theo. Một là phần mềm theo yêu cầu hoàn toàn trên nền tảng, nơi tôi đang sử dụng phiên bản ứng dụng của riêng mình và chỉ khi tôi sử dụng nó, bạn biết đấy, tôi không thực sự thích tương tác này và nó tự động thay đổi cho tôi. Đó là một loại tương lai điên rồ mà bạn có thể tưởng tượng, hoặc thậm chí không phải bạn chủ động làm điều đó, mà chỉ dựa trên các tương tác của bạn với nó, phần mềm bạn đang sử dụng sẽ thay đổi để phù hợp với bạn. Đó là một con đường tiềm năng thú vị phía trước, nơi tôi không biết liệu mọi người trên thế giới có muốn, tôi không biết liệu tổng số lượng người muốn tự xây dựng phần mềm của riêng họ có lớn đến vậy không, phải không? Nhưng việc thêm những người có thể hưởng lợi từ phần mềm phù hợp với nhu cầu của họ có thể là cả thế giới.
Lời khuyên cho kỹ sư tài năng trong ngành AI
Được rồi, có lẽ một điều cuối cùng để kết thúc ở đây. Đối với tất cả những người đang xem điều này, nếu bạn là một kỹ sư tài năng ngoài kia và bạn đang nghĩ về bước đi tiếp theo hoặc bạn muốn tham gia sâu hơn vào ngành công nghiệp, bạn đang cố gắng quyết định giữa việc có thể đến một công ty lớn hơn hoặc tham gia một startup tập trung vào tác vụ như Cursor và Anthropic. Bạn sẽ nói gì với một người trong tình huống đó?
Vâng, tôi nghĩ các startup có lợi thế trong những ngày này, như với Anthropic và với Cursor, và trong việc thu hút nhân tài thực sự xuất sắc theo một cách mà khi bạn là một công ty lớn, nhiều người, bạn biết đấy, nhiều người giỏi nhất trên thế giới thấy điều đó ít thú vị hơn, phải không? Và một số người thì có, và chắc chắn các công ty lớn có những người tuyệt vời, nhưng mật độ của nhân tài đó có xu hướng thấp hơn nhiều, và tại một startup, bạn có thể có được mật độ nhân tài rất cao, và điều đó khiến việc làm việc với một nhóm các đồng nghiệp xuất sắc khác thực sự thú vị. Bạn có thể làm việc trên những dự án thực sự có tầm ảnh hưởng trong một nhóm nhỏ đến kinh ngạc, phải không, xây dựng một sản phẩm và xây dựng các mô hình AI thay đổi cách thế giới viết phần mềm, và bạn có thể là một trong số, bạn biết đấy, hàng chục, hàng trăm hoặc hàng nghìn người đang làm việc đó, và điều đó thực sự tuyệt vời. Vâng, điều đó thật tuyệt vời. Cảm ơn các bạn, đây là một cuộc trò chuyện tuyệt vời. Cảm ơn.