Nhà Phát Triển Trẻ Bị Sa Thải Vì Lỗi Do AI Viết: Khi Tốc Độ Ấn Tượng Hơn Sự Chính Xác

Hai Lỗi Và Hộp Giấy Carton

Một kỹ sư trẻ tại một startup AI đã gửi 2 lỗi ra môi trường sản xuất và bị sa thải. Hãy đọc lại câu đó. Hai lỗi. Từ một lập trình viên năm nhất. Tại một công ty đã yêu cầu anh ta sử dụng công cụ viết code AI. Đó không phải là vấn đề về hiệu năng. Đó chỉ là một ngày thường.

Công ty đã "khuyến khích mạnh mẽ" mọi kỹ sư phụ thuộc vào các công cụ như Cursor. Gửi nhanh hơn. Viết nhiều hơn. Để máy móc lo phần nhàm chán. Vì vậy, kỹ sư trẻ đã làm đúng những gì được bảo. Máy móc tạo ra mã. Mã có lỗi. Lỗi xuất hiện trên sản xuất. Và người tuân thủ chỉ dẫn đã bị đuổi khỏi tòa nhà.

Reddit bùng nổ. Hàng nghìn bình luận chỉ trích công ty vì dựng bẫy và trừng phạt người đã rơi vào nó. Vì chính xác là điều đó đã xảy ra. Lãnh đạo đặt ra quy tắc, chọn công cụ, quyết định tốc độ quan trọng hơn sự chính xác, rồi ngạc nhiên khi sự chính xác bị tổn thương.

Sự Kết Nối Coinbase

Không có gì xảy ra trong chân không. Nó diễn ra trong cùng ngành công nghiệp nơi CEO Coinbase Brian Armstrong công khai ra lệnh cho mọi kỹ sư phải chấp nhận công cụ AI và cấp cho họ một tuần để làm chủ. Bảy ngày. Không phải một quý. Thậm chí không phải một chu kỳ sprint đầy đủ. Bảy ngày lịch để tái cấu trúc cách họ viết phần mềm.

Mục tiêu được tuyên bố của Armstrong: một nửa cơ sở mã của Coinbase được tạo ra bởi AI. Con số hiện tại ở mức 33% và đang tăng lên. Đối với một công ty xử lý hàng tỷ giao dịch tiền điện tử, nơi một lỗi ủy quyền đơn lẻ trong điểm cuối giao dịch có thể rút sạch ví của khách hàng.

Một tuần để học công cụ tạo ra 1.7 lần nhiều lỗi hơn mã do con người viết, theo nghiên cứu của CodeRabbit. Sẽ có gì sai sót.

Hình mẫu được viết rõ ràng trên bảng trắng. Công ty ép buộc sử dụng công cụ AI. Công cụ tạo ra mã với khối lượng và các lỗ hổng chất lượng đã biết. Lỗi xuất hiện. Một người bị đổ lỗi. Người đó không phải là giám đốc đã ký biên bản chỉ đạo.

Tầm Nhìn Từ Dưới Đối Với "Phát Triển AI-First"

Hãy tưởng tượng vị trí của kỹ sư trẻ trong vòng 30 giây.

Sáu tháng vào công việc kỹ sư thực tế đầu tiên. Lãnh đạo gửi email tổng hội về "phát triển AI-first". Trưởng nhóm bắt đầu theo dõi tốc độ trong số Pull Request mỗi tuần. Cursor được cài đặt trên mọi máy. Có một kênh Slack gọi là #ai-wins nơi mọi người đăng ảnh chụp màn hình mã được tạo ra. Không ai tạo kênh gọi là #ai-failures. Kênh đó sẽ quá hoạt động.

Một người 23 tuổi không có "vảy sừng" để biết AI sai ở đâu. Họ chưa từng gỡ lỗi một tình trạng cạnh tranh lúc 2 giờ sáng. Chưa từng chứng kiến một lỗi im lặng nuốt chửng thanh toán. Chưa từng dành ba ngày để truy vết một kiểm tra ủy quyền bị thiếu bên trong mã được tạo ra mà trông hoàn hảo.

Vì vậy, kỹ sư trẻ làm đúng những gì được bảo. Sử dụng công cụ. Gửi kết quả ra. Và khi nó bị lỗi, công ty sa thải nhà phát triển, không phải quy trình.

Đó không phải là trách nhiệm giải trình. Đó là hy sinh.

Lỗi Thoáng Nhìn Không Có Vấn Đề

Điều mà những người bên ngoài kỹ thuật không hiểu về các lỗi do AI tạo ra: chúng không trông có vẻ bị lỗi. Chúng trông sạch sẽ, có cấu trúc tốt, ngôn ngữ chuẩn. Mã làm đúng mọi trường hợp trừ trường hợp tốn tiền.

Hãy xem xét dịch vụ tính giảm giá cho một nền tảng thương mại điện tử. AI tạo ra mã này:

def apply_discount(cart_total: float, discount_code: str) -> float:
    discount = get_discount(discount_code)
    if discount is None:
        return cart_total
    if discount.type == "percentage":
        return cart_total * (1 - discount.value / 100)
    if discount.type == "fixed":
        return cart_total - discount.value
    return cart_total

Đọc được. Xử lý giảm giá phần trăm và cố định. Trả về tổng gốc cho các mã không hợp lệ. Các bài kiểm tra vượt qua vì bộ kiểm tra bao gồm các mã giảm giá hợp lệ, không hợp lệ và cả hai loại.

Được gửi ra sản xuất. Hoạt động tốt trong hai tuần. Không ai hoảng hốt.

Sau đó, một khách hàng áp dụng giảm giá cố định 50 đô la cho giỏ hàng 30 đô la. Hàm trả về mười lăm đô la âm. Bộ xử lý thanh toán đọc đó như một khoản tín dụng 15 đô la vào tài khoản khách hàng. Công ty rò rỉ tiền trên mỗi đơn hàng nơi giảm giá vượt quá tổng giỏ hàng. Không ai phát hiện trong 11 ngày vì bảng điều khiển giám sát theo dõi khối lượng giao dịch, không phải cực tính giao dịch.

Cách khắc phục:

def apply_discount(cart_total: float, discount_code: str) -> float:
    discount = get_discount(discount_code)
    if discount is None:
        return cart_total
    if discount.type == "percentage":
        discounted = cart_total * (1 - discount.value / 100)
    elif discount.type == "fixed":
        discounted = cart_total - discount.value
    else:
        return cart_total
    return max(discounted, 0.0)  # <-- toàn bộ sự khắc phục

Một dòng. max(discounted, 0.0). Đó là khoảng cách giữa phần mềm hoạt động và rò rỉ doanh thu 11 ngày. Một người có kinh nghiệm đã bị lửa đốt bởi các tổng âm sẽ phát hiện điều này trong khi duyệt mà không ngừng nghỉ. AI không báo hiệu nó vì các tổng âm không có trong dữ liệu huấn luyện của nó. Kỹ sư trẻ không báo hiệu nó vì không ai dạy anh ta biết cách nhìn vào nó.

Và chính người đó bị sa thải.

Trước Và Sau: Quy Trình Duyệt Đúng Cách

Phần khó chịu: lỗi đó không nên đến sản xuất bất kể ai viết nó. Không phải kỹ sư trẻ. Không phải AI. Không phải cả hai cùng nhau. Quy trình duyệt của công ty thất bại, giả sử quy trình đó tồn tại.

Đây là sự khác biệt giữa một đội ngũ gửi mã do AI an toàn và một đội ngũ gửi thư sa thải.

Quy trình bị hỏng (có thể đã xảy ra):

• Kỹ sư trẻ tạo mã bằng công cụ AI
• Kỹ sư trẻ mở PR
• Kỹ sư trẻ khác hoặc trung cấp duyệt lướt qua nó, thấy mã sạch sẽ, phê duyệt
• CI chạy kiểm tra. Kiểm tra vượt qua (vì không ai viết kiểm tra trường hợp cạnh tranh)
• Mã hợp nhất và triển khai
• Lỗi xuất hiện trên sản xuất
• Kỹ sư trẻ bị đổ lỗi

Quy trình thực sự hoạt động:

Tạo PR:

• Mọi PR chứa mã hỗ trợ AI nhận nhãn tự động ai-generated
• Không có ngoại lệ. Đội ngũ cần biết họ đang duyệt cái gì.

Gán Duyệt:

• PR có nhãn AI được gửi đến kỹ sư cấp cao. Không phải kỹ sư trẻ khác. Người đã dành nhiều năm xây dựng bản năng cho các điều kiện biên, kiểm tra ủy quyền bị thiếu và lỗi im lặng.

Yêu Cầu Kiểm Tra Trường Hợp Cạnh Tranh Trước Khi Hợp Nhất:

def test_discount_does_not_go_negative():
    """Giảm giá cố định lớn hơn tổng giỏ hàng nên trả về 0."""
    assert apply_discount(30.0, "SAVE50") == 0.0

def test_percentage_discount_at_boundary():
    """Giảm giá 100% nên đặt giỏ hàng bằng 0, không thấp hơn."""
    assert apply_discount(100.0, "FULL100") == 0.0

def test_zero_cart_with_discount():
    """Giảm giá áp dụng cho giỏ hàng trống nên trả về 0."""
    assert apply_discount(0.0, "SAVE10") == 0.0

def test_negative_cart_rejected():
    """Tổng giỏ hàng âm nên ném lỗi, không tính toán im lặng."""
    with pytest.raises(ValueError):
        apply_discount(-5.0, "SAVE10")

Bộ Kiểm Tra Trước Khi Hợp Nhất Cho Mã Hỗ Trợ AI:

• Mã này xử lý đầu vào null, trống và bằng 0 có không?
• Điều gì xảy ra ở các ranh giới? Số âm, giá trị tối đa, bộ sưu tập trống?
• Có tình trạng cạnh tranh dưới các yêu cầu đồng thời không?
• Mã này kiểm tra ủy quyền, không chỉ xác thực có không?
• Điều gì thất bại im lặng? Ở đâu các lỗi bị nuốt chửng?

Sau Tai Nạn:

• Postmortem xem xét quy trình, không chỉ người. Mã đã được duyệt? Bởi ai? Các bài kiểm tra trường hợp cạnh tranh đã được viết không? Nếu câu trả lời cho bất kỳ điều nào là "không", quy trình đã thất bại. Không phải nhà phát triển.

Quy trình thứ hai không cách mạng. Nó gần như không mới. Nhưng công ty sa thải kỹ sư trẻ này không có nó. Cũng như hầu hết các công ty đang cố gắng đạt các chỉ số KPI chấp nhận AI.

Những Số Liệu Không Có Trên Bảng Thống Kê

Nghiên cứu của CodeRabbit xác nhận những gì câu chuyện này cho thấy ở quy mô nhỏ: mã do AI tạo ra tạo ra 1.7 lần nhiều lỗi hơn mã do con người viết. Không phải rủi ro lý thuyết. Lỗi phá vỡ sản xuất, lỗi trực tiếp đối với khách hàng với tỷ lệ gần gấp đôi.

Số lượng sự cố trên mỗi pull request tăng 23.5% trên các đội đã chấp nhận công cụ AI một cách quyết liệt. Thời gian trung bình để giải quyết các sự cố đó tăng lên 62%. Tại sao? Vì những người hiểu hệ thống đủ tốt để sửa nhanh thường là những người cùng có vai trò bị "tối ưu hóa" đi.

Kết hợp những con số đó với việc chấp nhận cưỡng chế. Một công ty đẩy các nhà phát triển hướng đến các công cụ tạo ra 1.7 lần nhiều lỗi, đo lường thành công bằng khối lượng đầu ra, đầu tư ít hơn vào duyệt, và sau đó sa thải người có cấp bậc thấp nhất khi toán học hoạt động như toán học.

Đó không phải là chiến lược quản trị. Đó là bom hẹn tài sản với một nhà phát triển trẻ bị trói ở phía trước.

Trách Nhiệm Chảy Xuống. Nó Không Nên Thế.

Có một mẫu bực bội trong cách tổ chức xử lý sự thất bại của công cụ.

Khi phần mềm doanh nghiệp gây ra vấn đề, nhà cung cấp bị đổ lỗi. Khi cơ sở dữ liệu mới làm hỏng dữ liệu, đội ngũ kiến trúc phải chịu sự giám sát. Khi một pipeline CI/CD giới thiệu regressions, đội ngũ nền tảng tổ chức một buổi retrospec và viết một kế hoạch hành động.

Nhưng khi công cụ viết code AI được ép buộc tạo ra lỗi? Nhà phát triển cá nhân bị sa thải. Công cụ giữ giấy phép ghế của nó. Mệnh lệnh vẫn ở đó. Lãnh đạo viết một bài blog về "văn hóa AI-first".

Điều này chỉ hoạt động theo một hướng: xuống dưới. Lãnh đạo ép buộc công cụ. Lãnh đạo đặt mục tiêu tốc độ. Lãnh đạo quyết định PR mỗi tuần là thước đo quan trọng nhất. Lãnh đạo bỏ qua việc đầu tư cơ sở hạ tầng duyệt. Và khi kết quả hoàn toàn có thể dự đoán đến, lãnh đạo sa thải người có ít quyền lực nhất để thay đổi bất kỳ quyết định nào trong số đó.

Kỹ sư trẻ đó không chọn công cụ. Không đặt mục tiêu. Không thiết kế quy trình duyệt. Không quyết định rằng tốc độ quan trọng hơn sự chính xác. Anh ta chỉ may mắn là đang giữ mã khi nhạc tắt.

Armstrong's 50% và Ý Nghĩa Của Nó Đối Với Coinbase

Hãy nghĩ về ý nghĩa của 50% mã do AI tạo ra đối với một công ty dịch vụ tài chính.

Coinbase không phải là ứng dụng mạng xã hội nơi lỗi tồi tệ nhất làm cho người đó xem meme sai. Tuân thủ quy định không phải là tùy chọn. Lỗi bảo mật không chỉ làm mất uy tín; chúng làm mất tiền thật từ tài khoản khách hàng thật. Một tình trạng cạnh tranh trong động cơ khớp lệnh có thể tạo ra các giao dịch ảo. Một kiểm tra biên bị thiếu trong điểm cuối rút tiền có thể để cho kẻ tấn công rút sạch vốn.

50% mã do AI tạo ra trong môi trường đó, mà không có đầu tư tương xứng trong cơ sở hạ tầng xác minh, là một cược rằng các công cụ sẽ không tạo ra chính lớp lỗi chúng được chứng minh thống kê là tạo ra. Và những kỹ sư được kỳ vọng sẽ phát hiện những lỗi đó trước khi chúng được gửi? Họ chỉ có 7 ngày để học công cụ đã viết chúng.

Kỹ sư trẻ bị sa thải tại startup AI đó là một bản xem trước. Phóng đại động động học tương tự cho một công ty quản lý tiền của khách hàng, và rủi ro sẽ không còn là về sự nghiệp của một người nữa.

Những Điều Reddit Làm Đúng

Reddit đã chốt điểm cốt lõi: sa thải kỹ sư trẻ vì hai lỗi là vô lý. Kỹ sư cấp cao gửi lỗi. Kỹ sư cấp cao gửi lỗi. Kỹ sư cấp cao Distinguished gửi lỗi. Sự khác biệt là các kỹ sư có kinh nghiệm thường làm việc trong các quy trình với đủ lớp duyệt mà lỗi của họ được phát hiện trước khi khách hàng thấy chúng.

Reddit cũng xác định đúng sự thất bại hệ thống. Ép buộc công cụ mà không xây dựng hàng rào. Đo lường tốc độ mà không đo lường chất lượng. Bỏ qua việc đầu tư làm cho mã hỗ trợ AI an toàn để gửi.

Nơi cuộc trò chuyện đi sai hướng: coi đây là một trường hợp tách biệt của quản lý tồi. Nó không tách biệt. Nó cấu trúc. Hệ thống khuyến khích trong ngành công nghiệp hiện tại thưởng tốc độ chấp nhận AI và trừng phạt sự thận trọng. Các công ty chậm lại để xây dựng cơ sở hạ tầng duyệt không được khen ngợi vì trách nhiệm. Chúng bị hỏi bởi hội đồng của họ tại sao các chỉ số chấp nhận tụt hậu so với đối thủ cạnh tranh đã sa thải nhân viên để đạt được các con số nhanh hơn.

Những Điều Nên Xảy Ra Thực Sự

Ngừng sa thải kỹ sư trẻ cho các kết quả có thể dự đoán. Đó là sàn. Mọi thứ khác được xây dựng trên nó.

Tài trợ cho lớp xác minh trước khi ép buộc công cụ. Nếu lãnh đạo muốn 50% mã do AI tạo ra, lãnh đạo cần trả tiền cho cơ sở hạ tầng duyệt làm cho nó an toàn. Nhà duyệt cấp cao. Danh sách kiểm tra chuyên về AI. Yêu cầu kiểm tra tập trung vào ranh giới. Phân tích tự động chỉ ra các mẫu thất bại thường gặp của AI. Điều này tốn tiền. Ít tiền hơn nhiều so với sự cố sản xuất và các vụ kiện sa thải sai luật.

Đặt tỷ lệ lỗi lên cùng bảng điều khiển với tốc độ. Bất kỳ chỉ số đội nào hiển thị PR mỗi sprint mà không hiển thị sự cố mỗi PR là một sự giả dối qua lăng kính. Cả hai con số được đặt trên cùng một trang trình bày, hoặc không có cái nào.

Xây dựng onboarding có cấu trúc cho phát triển hỗ trợ AI. Kỹ sư trẻ cần học điều gì sai khi AI trước khi được yêu cầu sử dụng nó trong sản xuất. Các ví dụ được chọn lọc về sự thất bại của AI. Các phiên duyệt theo cặp với kỹ sư cấp cao. Khoảng thời gian tăng tốc độ dài hơn một tuần lịch. Xây dựng sự phán đoán trước, triển khai công cụ sau.

Làm cho trách nhiệm giải trình tương xứng với quyền hạn. Người ép buộc công cụ mang nhiều trách nhiệm hơn người được bảo sử dụng nó. Khi mã do AI tạo ra phá vỡ sản xuất, postmortem xem xét chuỗi quyết định, không chỉ là người cuối cùng đã nhấp "phê duyệt".

Xử lý đầu ra AI như đầu vào không tin cậy. Mọi khối mã do AI tạo ra xứng đáng với sự hoài nghi tương tự như đầu vào người dùng trong biểu mẫu web. Xác thực nó. Kiểm tra ranh giới của nó. Giả định nó sai cho đến khi được chứng minh là khác. Các đội ngũ tích hợp điều này sẽ gửi ít lỗi hơn các đội ngũ coi đầu ra AI giống như công việc của một đồng nghiệp đáng tin cậy.

Bảo vệ kỹ sư trẻ trong quá trình chuyển đổi. Nhà phát triển trẻ là những người dễ bị tổn thương nhất bởi các lỗi do AI tạo ra vì họ có ít kinh nghiệm nhất để phát hiện chúng. Đó không phải là lý do để sa thải kỹ sư trẻ. Đó là lý do để đầu tư nhiều hơn trong việc hướng dẫn họ. Kỹ sư cấp cao của 2031 là những kỹ sư trẻ bị sa thải vào năm 2026 cho các lỗi họ không viết và không thể phát hiện.

Câu Hỏi Không Ai Trong Lãnh Đạo Muốn Đặt

Nếu một công ty ép buộc một công cụ, và công cụ đó tạo ra đầu ra tồi, và một nhân viên gửi đầu ra đó trong thiện chí theo chính sách công ty, ai phải chịu trách nhiệm?

Không phải đạo đức. Pháp lý.

Vì khi mã do AI tạo ra mở rộng từ 33% lên 50% lên bất cứ điều gì tiếp theo, và khi các lỗi mở rộng cùng lúc, ai đó sẽ đặt câu hỏi đó trước một thẩm phán thay vì trên Reddit. Câu trả lời không phải là "nhà phát triển trẻ".

Các công ty hiểu điều này ngay bây giờ, xây dựng cơ sở hạ tầng và quy trình duyệt và cấu trúc trách nhiệm giải trình trước khi bị ép buộc, sẽ vẫn đứng vững khi bụi mờ đi. Những người tiếp tục sa thải kỹ sư trẻ vì sử dụng các công cụ họ được bảo sử dụng sẽ học bài học theo cách đắt đỏ.

Kỹ sư trẻ đó xứng đáng với một quy trình tốt hơn. Không phải hộp giấy.

Bạn có bị ép buộc sử dụng công cụ viết code AI cho đội nhóm không? Quy trình duyệt của bạn trông như thế nào? Có quy trình duyệt nào tồn tại không?