- Codex đã tạo ra phiên bản chạy được đầu tiên chỉ trong vài giờ cho thí nghiệm thuật toán sinh có cấu trúc mà .txt đã trì hoãn hơn một năm, nhưng thay đổi cốt lõi nằm ở việc bộc lộ ra điểm nghẽn cộng tác hơn là tốc độ lập trình cá nhân
- Khi agent đảm nhận phần triển khai, thứ làm chậm tốc độ của nhóm không còn là người viết mã mà chuyển thành việc tạo ra các đặc tả chính xác để agent có thể thực thi ngay, như roadmap, tiêu chí nghiệm thu và tài liệu thiết kế
- Khi chi phí viết mã giảm xuống, các nguyên mẫu và công cụ nội bộ mà trước đây người ta sẽ không làm sẽ tăng lên, trong khi tốc độ mà người dùng có thể hấp thụ vẫn giữ nguyên, khiến kỷ luật về tập trung — quyết định không làm gì — trở nên quan trọng hơn
- Agent có thể trích xuất các quyết định ngầm và quy ước từ Slack, PR, issue, commit và tài liệu thiết kế để tạo ra cơ sở tri thức, nhưng không thể khôi phục hoàn toàn bối cảnh chia sẻ mà con người trực tiếp tích lũy
- Lợi thế trong 10 năm tới nhiều khả năng sẽ thuộc về những công ty duy trì được tính nhất quán ở cấp tổ chức, tức vẫn căn chỉnh theo một tập quyết định ngày càng thu gọn ngay cả ở quy mô 50, 200 hay 2.000 người, hơn là chỉ sở hữu mô hình tốt nhất
Điểm nghẽn bị coding agent thay đổi
- Thí nghiệm mà .txt đã trì hoãn hơn một năm là kiểm thử thuật toán sinh có cấu trúc và các lựa chọn thay thế mã nguồn mở, đồng thời kiểm tra một vấn đề gần với việc “liệu nó có tạo ra phân phối token đúng hay không” hơn là chỉ “liệu nó có chấp nhận chuỗi này hay không”
- Thí nghiệm này vẫn luôn nằm trong roadmap, nhưng sau khi giải thích cách tiếp cận cho Codex khoảng 30 phút, phiên bản chạy được đầu tiên đã được tạo ra chỉ trong vài giờ
- Coding agent đã thay đổi mạnh mẽ cách cá nhân viết mã, nhưng khó có thể nói rằng việc tăng năng suất cá nhân sẽ ngay lập tức dẫn đến việc toàn bộ ngành phần mềm tăng tốc tương ứng
- Phần mềm có ảnh hưởng thường được tạo ra nhờ nhiều người cùng cộng tác, và đơn vị phân tích thú vị hơn không phải là năng suất cá nhân mà là cộng tác
- Phần mềm gần giống như thứ còn lại sau khi con người thương lượng về việc hệ thống phải làm gì; mã nguồn quan trọng, nhưng là phần dư của một công việc khó hơn
Roadmap trở thành giới hạn
- Trong các nhóm để agent đảm nhận triển khai, thứ làm chậm tốc độ là việc tạo ra các đặc tả đủ chính xác để agent có thể trực tiếp cầm lấy và thực thi
- Roadmap, tiêu chí nghiệm thu và “thứ chúng ta thực sự muốn” phải được viết rõ ràng dưới dạng test suite, ticket, tài liệu thiết kế và những hình thức tương tự
- Tính năng được triển khai rất nhanh, và thay vì kỹ sư chờ kỹ sư khác, họ rơi vào tình huống chờ đặc tả tiếp theo được viết đúng
- Điểm nghẽn chuyển từ người viết mã sang người quyết định loại mã nào cần tồn tại, và điều đó rốt cuộc là vấn đề của quản lý
Mã rẻ hơn đòi hỏi nhiều đồng thuận hơn
- Khi chi phí viết mã giảm xuống, điều xảy ra không phải là chỉ tốn 10% công sức để có cùng kết quả, mà là dùng lượng công sức tương tự cho những kết quả trước đây bị xem là không đáng làm
- Những nguyên mẫu mà 3 tháng trước còn bị coi là “lãng phí thời gian” nay có thể được tạo ra trong một buổi chiều, và các công cụ nội bộ không có nhu cầu rõ ràng cũng được làm ra rồi bị lãng quên
- Tốc độ mà người dùng có thể hấp thụ tính năng nhìn chung vẫn như cũ, bất kể nhóm phát hành 10 hay 50 tính năng
- Như Steve Jobs từng nói năm 1997, “tập trung là biết từ chối”, và Apple đã cắt giảm khoảng 70% danh mục sản phẩm trong năm đó
- Khi có agent, cảm giác tung ra tính năng mới trở nên dễ dàng hơn, nên kỷ luật để quyết định không chỉ làm gì mà còn không làm gì lại càng khó hơn
Bối cảnh trở thành tài nguyên cốt lõi
- Thương lượng và đồng thuận vận hành trên nền bối cảnh chia sẻ bên trong tổ chức
- Bối cảnh bao gồm việc đang xây cái gì, vì sao nó quan trọng, đã thử gì, ai đã quyết định điều gì, đâu là phần cốt lõi và đâu chỉ là dấu vết còn sót lại
- Con người trong một nhóm tích lũy bối cảnh một cách tự nhiên khi ở cùng phòng, đọc cùng kênh Slack và cùng debug một sự cố lúc 2 giờ sáng
- Phần lớn bối cảnh này không được tài liệu hóa, và khi một kỹ sư senior nói trong lúc review PR rằng “cái này sẽ làm hỏng migration”, họ có thể đang sử dụng loại bối cảnh không hề có trong tài liệu
- Agent không thể hấp thụ theo kiểu thẩm thấu đó; nó không ở trong phòng, không nghe lỏm nửa cuộc trò chuyện về kế hoạch, cũng không mang ký ức về sự cố trước đây để có được bối cảnh
- Bối cảnh nào không được đưa vào prompt, cây thư mục, công cụ hay chỉ dẫn tường minh thì agent không thể nắm giữ một cách ổn định
- Không có bối cảnh, agent có thể tạo ra câu trả lời nghe hợp lý cho một câu hỏi hơi sai
- Ngay cả khi agent làm được việc hữu ích tại .txt, thực chất con người đã làm sẵn công việc bối cảnh; điều đó không có nghĩa là 10 kỹ sư tiếp theo sẽ tự động có được cùng bức tranh
- Bối cảnh mà các tổ chức từ trước tới nay luôn ngầm dựa vào giờ đã trở thành đầu vào giới hạn tốc độ, và con người có xu hướng để nó ở dạng ngầm vì trước đây không có đối tượng nào cần đọc phiên bản tường minh của nó
Vòng lặp agent tạo ra bối cảnh
- Tạo ra bối cảnh mà con người có thể dễ dàng tiêu thụ là loại công việc mà con người không thích làm
- Agent có thế mạnh trong việc đọc không sót PR comment, issue đã đóng, commit message, tài liệu thiết kế cũ và kho lưu trữ Slack, rồi trích xuất các mẫu mà chưa từng có ai tài liệu hóa
- Tại .txt, họ đã bắt đầu xây dựng agent thu thập codebase, issue, PR và thread để biến các quyết định ngầm, quy ước và “vì sao lại làm như vậy” thành một cơ sở tri thức
- Cơ sở tri thức này không chỉ chứa kiểu thông tin “module này tồn tại”, mà còn cả bối cảnh như “module này kỳ quặc vì migration phải giữ nguyên hành vi hiện có” hoặc “benchmark này quan trọng vì lần tối ưu hóa trước đã âm thầm làm thay đổi phân phối”
- Các agent khác sử dụng cơ sở tri thức này khi cần hành động trên codebase
- Kiểu thẩm thấu mà trước đây con người thực hiện một cách phi chính thức được ngoại hóa thành dạng mà cả agent lẫn con người đều có thể đọc
- Agent tiêu thụ bối cảnh cần có agent sản xuất bối cảnh, và khi vòng lặp này vận hành, tổ chức sẽ có một nền tảng được tài liệu hóa mà nếu không thì họ đã không tự tạo ra
- Tuy vậy, thứ mà vòng lặp này tạo ra luôn chỉ là một bức tranh từng phần
- Như Michael Polanyi từng nói, “chúng ta biết nhiều hơn những gì có thể nói ra”, và một số bối cảnh cốt lõi tồn tại chính vì nó chưa bao giờ được viết thành lời, thậm chí có thể thay đổi ngay khi được viết ra
- Lớp thẩm thấu mà con người trực tiếp tích lũy khi gặp gỡ nhau không thể được phục dựng hoàn toàn chỉ bằng các sản phẩm phụ đã tài liệu hóa
- Kết quả đầu ra gần với một điểm khởi đầu hữu ích hơn là một bản phục dựng hoàn chỉnh, và liệu như vậy có đủ để tạo ra hiệu ứng tích lũy hay không vẫn còn là một câu hỏi mang tính thử nghiệm
Hào lũy mới nằm ở tổ chức hơn là công nghệ
- Người chiến thắng trong 10 năm tới không nhất thiết là công ty có mô hình tốt nhất hay hạ tầng agent tốt nhất, mà nhiều khả năng là công ty vẫn có thể tạo ra nhiều đầu ra hơn trên mỗi người trong khi mở rộng lên 50, 200 hay 2.000 người mà vẫn giữ được sự căn chỉnh theo một tập quyết định ngày càng được thu gọn
- Đó là những tổ chức vốn đã biết từ trước khi agent xuất hiện rằng vấn đề khó nhất là tính nhất quán
- Đây là vấn đề của văn hóa và quản lý, và thực ra từ trước tới nay vẫn luôn như vậy
- Các thế hệ công cụ trước như IDE, version control, CI, microservices và DevOps từng hứa sẽ giải quyết điều phối bằng công cụ tốt hơn, nhưng trên thực tế chúng chủ yếu đóng vai trò khuếch đại tính nhất quán tổ chức vốn đã tồn tại
- Các nhóm nhỏ gần như có được tính nhất quán miễn phí, nên hiệu ứng khuếch đại phần lớn là tích cực; đó cũng là lý do có nhiều tiếng nói ủng hộ agent mạnh mẽ đến từ các nhóm nhỏ, vì trong bối cảnh của họ điều đó phần lớn là đúng
- Khi vượt qua một quy mô nhất định, tính nhất quán phải được tạo dựng và duy trì, và hiệu ứng khuếch đại trở nên sắc bén theo cả hai hướng
- Tổ chức tốt trở nên tốt hơn, còn tổ chức kém thì hỏng nhanh hơn
- Agent là bộ khuếch đại lớn hơn nhiều so với các công cụ trước đây, và bị đánh giá quá cao như một phương tiện giúp cá nhân viết mã nhanh hơn nhưng lại bị đánh giá quá thấp như một phương tiện ngoại hóa những gì tổ chức biết
Agent như sự mở rộng của văn hóa công ty
- Agent có thể mang lại cảm giác như phần mở rộng của suy nghĩ cá nhân, và cảm giác đó rất mạnh
- Thách thức khó hơn là biến agent thành phần mở rộng của văn hóa công ty
- Để làm được điều đó cần có văn hóa viết lách, quản lý đủ sâu sắc để nhận ra những điểm mà bản thân vẫn là nút thắt bối cảnh, và những con người đối xử với tính nhất quán như một đầu ra thực sự cần phải được duy trì
- Điểm mới là hiện nay một phần trong số đó đã có thể được xây dựng
- Vòng lặp đọc và trích xuất là một hình thức như vậy, và có thể sẽ còn xuất hiện các hình thức khác
1 bình luận
Ý kiến trên Hacker News
Thật buồn cười khi suốt cả sự nghiệp, các kỹ sư luôn than phiền về mọi thứ làm gián đoạn vài giờ trạng thái tập trung sâu để viết code — như họp nhóm, nghi thức agile, trình theo dõi issue, backlog, Slack, email, review thiết kế — những thứ mà chính họ từng khăng khăng là hoạt động cốt lõi và thiêng liêng nhất; vậy mà giờ máy viết code nhanh hơn họ thì họ lại trắng trợn bắt đầu giảng đạo về tầm quan trọng của cộng tác và sự tầm thường của code·lập trình
Không hẳn sai, nhưng sự đạo đức giả lộ liễu từ những người vốn chống đối xã hội và ít hợp tác nhất trong mọi team cho tới tận một năm trước vẫn thật đáng ngạc nhiên
Dù sao thì hai điều vẫn có thể đúng cùng lúc: viết code không còn là nút thắt, nên ta có thể phát triển tính năng nhanh hơn tốc độ có thể deploy; và việc bị làm phiền khi đang làm thứ cần tập trung sâu vẫn rất khó chịu và phá vỡ dòng chảy
https://en.wikipedia.org/wiki/Group_attribution_error
Những cuộc họp giúp tăng đồng bộ giữa khách hàng và coder là hiếm và quý. Trong tổ chức lớn, các cuộc họp mang tính nghi thức lại tăng lên vì những lý do sai lệch. Mọi người cố chen mình vào quy trình giữa khách hàng và coder để chứng tỏ sự hiện diện của bản thân
Cá nhân tôi thích họp với khách hàng, người dùng cuối, UX designer và các bên liên quan thực sự. Tôi ghét các cuộc họp với những người bận rộn kiểu chính trị công ty chỉ biết ngốn băng thông để tranh ảnh hưởng nội bộ. Tôi không cần thêm một quản lý trung gian nào chen vào giữa tôi và người dùng của mình
Ngược lại, trong thế giới mới nơi việc viết code đã nhanh hơn rất nhiều và phần khó là hiểu được yêu cầu kinh doanh·kỹ thuật cần đạt, thì cùng một người có thể ưu tiên các nghi thức đó hơn và chấp nhận bị làm phiền trong lúc AI agent viết code
Việc thay đổi quan điểm khi sự thật của hoàn cảnh đã thay đổi không phải là đạo đức giả
Nếu bạn làm một dự án sáng tạo với ai đó ngoài công ty, có rất nhiều lý do khiến Scrum ritual hay Jira không phải là thứ đầu tiên bạn nghĩ đến. Coi trọng cộng tác mà vẫn chỉ trích những thứ đó là hoàn toàn nhất quán
Team than rằng có quá nhiều việc nên chẳng làm xong được gì, vì vậy manager đưa tôi vào. Rồi đột nhiên họ lại không muốn bàn giao bất cứ thứ gì. Hiện tại tôi vẫn đang ở đúng giữa tình huống đó
Team nói họ “ngập việc hoàn toàn”, nhưng vẫn có đủ thời gian để khăng khăng rằng gần như mọi thứ tôi có thể xử lý thì họ tự làm mới là tốt nhất và không cần hỗ trợ. Tôi thì ổn thôi, cứ ngồi đó lĩnh tiền. Nhưng mùi thì y hệt
A: họ không muốn thừa nhận rằng mình có thể bị thay thế và công việc không hề độc nhất đến vậy, B: họ không muốn thừa nhận nút thắt không phải ở quy trình hay khối lượng việc mà là ở chính họ
Có vẻ các kỹ sư kỳ cựu luôn biết nguyên nhân thật sự của vấn đề tốc độ nằm ở tổ chức nhiều hơn là ở kỹ thuật
Việc doanh nghiệp không thể xác định một roadmap tập trung và hiệu quả đã là vấn đề lâu năm của kỹ nghệ phần mềm. Cứ liên tục nhảy sang món bóng bẩy tiếp theo với ROI gần như bằng không, đồng thời không cho xử lý technical debt mang tính hệ thống, điều đó đã làm hỏng nhiều công ty nơi tôi từng làm về dài hạn
Tôi biết những kỹ sư junior dùng C++ cả năm mà vẫn không hiểu std::unique_ptr, và kiểu người này luôn là người chậm nhất team
Khi trước tôi từng viết đánh giá hiệu suất cho kỹ sư junior, hiệu suất thực sự bị chi phối mạnh bởi tốc độ, đo gần như bằng số dòng code không lỗi họ viết được trong một khoảng thời gian. Junior giỏi nhận một tính năng được định nghĩa rõ ràng rồi viết code tốt thật nhanh; junior kém nhận cùng việc đó nhưng viết chậm, hoặc viết nhanh mà đầy bug, tạo ra nhiều việc hơn hẳn cho debug và viết lại
Khi hiểu rõ cơ sở kinh doanh, phạm vi, đầu vào và đầu ra mong muốn, thì data model, thiết kế hệ thống và code gần như tự nhiên xuất hiện, hoặc ít nhất cũng trở nên rõ ràng hơn nhiều
— Melvin E. Conway, 1967
Trước hết nên tự hỏi liệu bạn có hiểu luật mở rộng như Chinchilla là gì và reinforcement learning kèm xác minh hoạt động nền tảng ra sao không
Tôi hoàn toàn đồng ý rằng giới hạn cốt lõi nằm ở việc doanh nghiệp có thể diễn đạt bản thân và chiến lược của mình một cách nhất quán hay không
Nhưng lợi thế hiện tại là ta gần như có thể tạo prototype miễn phí. Trước đây phải cực kỳ thận trọng khi đầu tư nguồn lực kỹ sư, còn giờ ta có thể thử nhiều thứ hơn rất nhiều trong cùng một ràng buộc thời gian
Việc phát hành tính năng và sửa lỗi nào vào thời điểm nào, và cách phát triển·quản lý sản phẩm tổng thể, mới luôn là thách thức thực sự; và phần lớn chiến lược này phụ thuộc vào các vòng phản hồi mà AI chưa thể tạo ra nhanh được
Đồng thời, tôi cũng cảm thấy rất nhiều lãnh đạo phía business dùng tốc độ của kỹ sư làm vật tế thần thay vì chịu trách nhiệm cho các quyết định tồi từ phía họ
Thường thì nút thắt đúng là code, nhưng không phải việc viết code mà là bản thân code. Trong sự nghiệp của tôi đã có vô số trì hoãn do ứng dụng chậm gây ra
Phải dùng editor dựa trên Eclipse mà chậm, định kỳ treo hoặc crash. Tác vụ build mất 15~20 phút. Tôi cũng thường gặp web app mất vĩnh viễn để xử lý những việc lẽ ra tối đa 50ms là xong
Danh sách này có thể kéo dài vô tận. Mỗi một độ trễ đều là một sự quấy nhiễu phá nát khả năng tập trung của tôi. Giờ tôi làm quản lý, xử lý hàng chục người và đủ loại gián đoạn hành chính, nhưng vẫn code ở công ty
Nếu phần mềm chậm, nó sẽ rơi xuống ưu tiên thấp nhất của tôi. Tôi không quan tâm nó ảnh hưởng đến ai. Nếu nó thật sự quan trọng, chúng ta đã không bị bắt làm con tin bởi lớp siro phần mềm chậm chạp đang kéo tất cả xuống như thế này
Code là nợ
Có thể dễ xem code là tài sản, nhưng về bản chất nó là nợ. Một phần các “nút thắt” trên đường đi tới code mới tồn tại để đảm bảo đầu ra lớn hơn phần nợ tăng thêm. Agent tạo nhiều code hơn nhanh hơn cũng là tạo nhiều nợ hơn nhanh hơn
Phần lớn sự hào hứng và hoài nghi quanh coding agent xoay quanh việc mức tăng năng suất tức thời — như tính năng mới, sản phẩm mới và doanh thu mới — có bù nổi phần nợ dài hạn gia tăng hay không. Câu trả lời phải 1~3 năm nữa mới biết, và sẽ khác nhau theo từng lĩnh vực
Nhìn từ góc này, việc cố đưa những nút thắt đó trực tiếp vào workflow kiểu agent có phần hợp lý. Cung cấp cho coding agent thêm ngữ cảnh để coi trọng một tầm nhìn dự án nhất quán và có thể phản đối tính năng mới hay quy trình không ràng buộc là điều có giá trị
Có phải bài viết đang muốn nói vậy không? Rằng một số agent sẽ nhận trách nhiệm quản lý sản phẩm để tổng hợp càng nhiều thứ càng tốt thành một tầm nhìn sản phẩm gắn kết, rồi nhắc coding agent về tầm nhìn đó một cách nghiêm ngặt nhất có thể?
Những agent như vậy có nên review đề xuất mới và pull request mới dưới góc độ “phù hợp với bức tranh tổng thể” hay không? Dù gọi đó là ngữ cảnh, tầm nhìn hay tên gì khác cũng vậy
Những agent kiểu này có thể rất giỏi trong việc tổng hợp ngữ cảnh và đưa ra roadmap nhất quán nghe có vẻ phù hợp về mặt ngôn ngữ với giá trị và tầm nhìn của team. Nhưng tôi hoài nghi liệu chúng có thể có được sự phán đoán mà một người quản lý hay một team giỏi sở hữu hay không. Việc phê duyệt một roadmap cụ thể quá nhanh và quá thuyết phục có thể hại nhiều hơn lợi
Lượng code tối thiểu cần thiết để giải quyết nhu cầu business mà không tạo thêm độ phức tạp là một tài sản đi kèm nợ bảo trì. Nó giống như chiếc máy kéo của nông dân: là tài sản cần được bảo dưỡng, và nếu bỏ mặc sẽ khấu hao vì bit rot
Còn code được viết ra để tạo thêm độ phức tạp không cần thiết thì là nợ thuần túy
Đúng, nhưng việc viết code luôn dạy cho ta điều gì đó
Tôi từng làm ở startup quy mô nhà sáng lập lẫn công ty đại chúng hàng chục tỷ đô, nhưng chưa bao giờ thấy một product spec, pitch deck hay PRD nào mô tả một giải pháp thực sự giải quyết được vấn đề nếu cứ triển khai đúng như đặc tả. Chỉ khi làm ra thật ta mới học được nó nên vận hành như thế nào
Phần mềm là một môi trường phức tạp và giàu tương tác. Cách duy nhất từng tạo ra được sản phẩm có giá trị là lặp đi lặp lại trong code cùng với những người muốn hiểu và giải quyết vấn đề. Họp và sơ đồ cũng hữu ích, nhưng trước khi viết ra phần mềm chạy được thì bạn không biết mình có gì trong tay cả
“Mục tiêu là kiểm thử thuật toán sinh có cấu trúc của chúng tôi và bản đối chiếu mã nguồn mở của nó, thay thế câu hỏi ngây thơ ‘nó có chấp nhận chuỗi này không?’ bằng câu hỏi gần với bài toán thực hơn là ‘nó có sinh ra đúng phân phối token không?’… Tháng trước tôi đã dành 30 phút giải thích cách làm cho Codex. Vài giờ sau, phiên bản đầu tiên chạy được đã xuất hiện. Chỉ có vậy thôi”
Điều này chứng minh nút thắt thực sự chính là code. Chỉ là giờ AI đã viết số code đó thay thôi
Người nghĩ rằng “nút thắt không phải code” là người vốn đã thảo luận mục tiêu và sắp xếp chúng nhất quán trong đầu từ trước
Nói code là nút thắt không nhất thiết phải mang nghĩa “tôi muốn tính năng này nhưng phải mất vài tháng mới code xong”. Nó cũng bao gồm kiểu “tôi đã muốn tính năng này suốt 2 năm, nhưng cứ trì hoãn vì ma sát của việc ngồi xuống chuyển nó thành code và dành ra 5~10 ngày”
Nếu code không phải nút thắt thì họ đã tự ngồi xuống viết rồi. Nhưng họ không muốn bỏ ra công sức và thời gian để tự code, và cũng biết rằng sẽ không thể ít công như dùng LLM
Ngay cả khi đặc tả cuối cùng chưa rõ, việc code theo hướng thăm dò, kiểm tra, bỏ đi rồi thử lại thiết kế mới cũng nhanh hơn khi dùng LLM. Chính xác là vì phần “code” nhanh hơn
Nói cách khác, nút thắt đúng là code
Ngay cả bài này cũng trông như bài viết do AI tạo ra có kèm chỉ dẫn tránh dùng lối diễn đạt sáo mòn, nên đọc vẫn chán như thường
Bài viết nói rằng “Jevons Paradox: khi một thứ rẻ hơn, ta không dùng nó ít đi mà lại dùng nhiều hơn”, nhưng cách diễn đạt đó đã làm hỏng nghịch lý Jevons
Câu đó không phải nghịch lý, mà là một hiệu ứng rất tự nhiên. Thứ gì rẻ hơn thì được dùng nhiều hơn là chuyện hiển nhiên
Điều mà nghịch lý Jevons thực sự mô tả là tình huống việc sử dụng một tài nguyên trở nên hiệu quả hơn, khiến lượng cần cho một công việc cụ thể giảm xuống, nhưng tổng mức tiêu thụ tài nguyên đó vẫn tăng lên
Nhưng khi việc sử dụng tài nguyên hiệu quả hơn, chẳng phải “giá” của việc sử dụng đó cũng sẽ rẻ hơn một cách hiển nhiên sao?
Vì vậy hiệu quả tăng lên thì mức sử dụng tất nhiên sẽ tăng. Sở dĩ gọi là nghịch lý là vì một số người ngây thơ nghĩ rằng tăng hiệu quả là cách tốt để giảm tiêu thụ
Hầu như mọi thứ được gọi là “nghịch lý” đều hiển nhiên như thế
Hoặc cũng có thể là khi một quy trình hiệu quả hơn, tức mất ít thời gian hơn, thì ta lại dành nhiều thời gian hơn cho chính quy trình đó
Nút thắt cho cái gì? Nhiều tính năng hơn à?
Tôi không nghĩ lượng phần mềm quyết định thành công của công ty. Tôi cũng không cho rằng việc nắm bắt số lượng ngữ cảnh là quan trọng đến vậy
Quan trọng là chất lượng của ngữ cảnh. Con người suy luận tốt đến đâu?
Kế đó là thái độ. Con người phản ứng tốt thế nào trước tình huống xấu?
Kế tiếp là quản lý nguồn lực. Công ty xử lý con người và tiền bạc tốt đến đâu?
Cuối cùng là may mắn. Có bao nhiêu yếu tố ngoài tầm kiểm soát đang đứng về phía ta?
Đó mới là những nút thắt khá điển hình của công ty. Tôi không thấy agent sẽ sớm giải quyết được những thứ này
Nút thắt để làm cho ứng dụng phần mềm mà doanh nghiệp phi phần mềm sử dụng trở nên tốt hơn nằm ở việc đảm bảo phần mềm thực sự làm tất cả những công việc phần mềm mang lại lợi ích cho doanh nghiệp
Những thứ như tiết kiệm thời gian, làm con người năng suất hơn, giảm lỗi do con người, giúp doanh nghiệp vận hành hiệu quả hơn và tăng biên lợi nhuận
Tất cả những điều này đều khá khó dự đoán và định lượng. Bạn có thể bắt đầu từ ý tưởng sẽ giúp ích cho business, thiết kế, làm prototype và thử nghiệm. Cuối cùng bạn xây hoặc cải thiện ứng dụng phần mềm rồi cố đo xem nó đã làm business tốt hơn bao nhiêu
Trong toàn bộ quá trình đó, việc đảm bảo phần mềm đang xử lý đúng vấn đề theo đúng cách và rốt cuộc thực sự làm business tốt hơn là bài toán khó. Điều này không liên quan đến việc làm phần mềm đã nhanh và dễ hơn bao nhiêu
Dù vậy, tốc độ vẫn có thể giúp rất nhiều. Bạn có thể tạo prototype, thử nghiệm và cải thiện vòng phản hồi
Với AI coding assistant, những việc trước đây được xem là công việc của developer junior giờ được thực hiện bằng một prompt nhanh và một agent chạy nền
Những công việc kiểu junior developer này giờ được coding assistant chuyển giao gần như dễ dàng mà hầu như không cần con người can thiệp. Backlog được dọn nhanh hơn tốc độ các mục mới được thêm vào. Và khi năng lực xử lý không còn là vấn đề, các mục mới cũng được thêm ngày càng nhiều
Giờ thách thức là theo kịp khối lượng thay đổi. Tôi đang thấy điều đó trực tiếp trong tổ chức của mình
Chỉ vì bạn có thể nghĩ ra các nút thắt khác không có nghĩa là việc sinh code trước đây không phải nút thắt, hoặc bây giờ không còn là nút thắt nữa. Chính khái niệm backlog đã cho thấy đó là nút thắt
“Phần mềm là thứ còn lại sau khi một nhóm con người thương lượng với nhau về việc hệ thống phải làm gì”
Tôi thích cách diễn đạt này. Đặc biệt là tôi đồng ý về ngữ cảnh. Đó chính là điểm mà một team giàu kinh nghiệm, gắn bó lâu dài được tưởng thưởng
Tôi đã quản lý những team như thế hàng chục năm. Cuối cùng khi bộ phận của chúng tôi được hợp nhất, kỹ sư ít thâm niên nhất cũng đã có 10 năm kinh nghiệm
Khi một team ở cùng nhau lâu đến vậy, chi phí giao tiếp giảm xuống gần như không đáng kể
Vì thế văn hóa nhiệm kỳ ngắn như chuồn chuồn hiện nay làm tôi buồn nhất
Giờ tôi chủ yếu làm việc một mình. Năng suất rất cao nhưng phạm vi thì thực sự hạn chế
Tôi nhớ thời mình thuộc về một team tốt
Rốt cuộc thì mọi người đang làm loại dự án gì mà phần khó duy nhất chỉ là hiểu tính năng ban quản lý muốn, còn mọi thứ khác thì chỉ việc “gõ ra” hoặc giờ giao cho LLM là xong?
Nếu đó là công việc của họ thì cũng chẳng lạ khi nhiều người trên HN nghĩ LLM có thể thay thế họ
Thế là chúng ta lại quay thêm một vòng nữa để nói về nỗi lo âu, nói trật nhịp với nhau, rồi chờ cơ hội bình luận tiếp theo sau 30 phút
Phần lớn đều là rác nóng về mặt chất lượng code do các chu kỳ offshore và sa thải