Jeremy Freeman, Đồng sáng lập và CTO của Allstacks – Loạt phỏng vấn

Jeremy Freeman, Đồng sáng lập và CTO của Allstacks, là một kỹ sư phần mềm, kiến trúc sư công nghệ và doanh nhân với sự nghiệp bao gồm phát triển phần mềm, kỹ thuật phần cứng, học máy và đổi mới sản phẩm. Kể từ khi đồng sáng lập Allstacks vào năm 2017, ông đã lãnh đạo kiến trúc và phát triển nền tảng cốt lõi của công ty, giúp chuyển đổi quản lý giao hàng phần mềm thông qua phân tích dự đoán và dự báo dựa trên AI. Trước khi tham gia Allstacks, Freeman đã giữ các vị trí lãnh đạo tại Ravioli Labs và CertiRx, nơi ông đã làm việc về kỹ thuật phần mềm, nghiên cứu, công nghệ chống giả mạo và phát triển sản phẩm. Sớm trong sự nghiệp của mình, ông đã có kinh nghiệm trong các công ty khởi nghiệp, công ty công nghệ doanh nghiệp và học viện, bao gồm cả việc giảng dạy phát triển web tại Trường Cộng đồng Kỹ thuật Wake. Bối cảnh kỹ thuật của ông bao gồm các hệ thống nhúng, thiết kế phần cứng, các nền tảng phần mềm lớn, học máy và lãnh đạo kỹ thuật, mang lại cho ông một quan điểm độc đáo về việc xây dựng các sản phẩm dựa trên dữ liệu giúp các tổ chức cải thiện kết quả giao hàng phần mềm.

Allstacks là một nền tảng trí tuệ kỹ sư phần mềm và quản lý luồng giá trị giúp các tổ chức cải thiện khả năng dự đoán và hiệu quả của phát triển phần mềm. Nền tảng này tích hợp dữ liệu từ các công cụ được sử dụng trong toàn bộ chu kỳ phát triển phần mềm, bao gồm quản lý dự án, kiểm soát nguồn và hệ thống triển khai, sau đó áp dụng AI và học máy để xác định rủi ro, dự báo kết quả giao hàng và cung cấp thông tin chi tiết có thể hành động. Bằng cách cung cấp cho các nhà lãnh đạo kỹ thuật và sản phẩm cái nhìn sâu sắc vào sức khỏe dự án, hiệu suất của nhóm và xu hướng phát triển, Allstacks cho phép các tổ chức đưa ra quyết định sáng suốt hơn, giảm thiểu sự không chắc chắn trong giao hàng và căn chỉnh tốt hơn nỗ lực kỹ thuật với mục tiêu kinh doanh. Công nghệ của nó được thiết kế để giúp các công ty vượt qua việc lập kế hoạch dựa trên trực giác bằng cách tận dụng dữ liệu hoạt động thời gian thực để cải thiện hiệu suất giao hàng phần mềm và thực hiện chiến lược.

Bạn đã có một hành trình độc đáo từ việc lãnh đạo các nhóm nghiên cứu và kỹ thuật áp dụng học máy vào dữ liệu phát triển phần mềm đến việc đồng sáng lập Allstacks vào năm 2017. Những khoảng trống hoặc vấn đề nào mà bạn quan sát thấy đã thúc đẩy bạn xây dựng công ty?

Khi chúng tôi bắt đầu Allstacks, chúng tôi đã dành rất nhiều thời gian để khám phá khách hàng, và mẫu mà chúng tôi nhận thấy là nhất quán: công ty này qua công ty khác có một lượng lớn dữ liệu nhưng vẫn không biết điều gì thực sự đang diễn ra. Việc giao hàng phần mềm là không thể dự đoán được mặc dù có những người thông minh nhất trong phòng. Vấn đề đó chưa được giải quyết.

Điều trở nên rõ ràng khá nhanh là đó không phải là một vấn đề báo cáo hoặc tích hợp. Đó là một vấn đề về mối quan hệ. Để biết liệu một điều gì đó có rủi ro hay không, bạn cần biết cách một mục công việc kết nối với một nhánh, nhánh kết nối với một yêu cầu kéo, yêu cầu kéo kết nối với một mục tiêu chạy nước rút và mục tiêu chạy nước rút kết nối với một sáng kiến kinh doanh. Đó là một đồ thị không tồn tại theo mặc định ở bất kỳ nơi nào trong chuỗi công cụ tiêu chuẩn. Bạn phải xây dựng nó. Và xây dựng nó một cách tốt là một vấn đề suy luận cơ bản, nơi mà nền tảng học máy trở nên hữu ích trực tiếp.

Mục tiêu của chúng tôi từ đầu không phải là làm cho một nhà phát triển cá nhân nhanh hơn trên tính năng X. Đó là làm cho toàn bộ tổ chức tốt hơn. Làm thế nào để bạn căn chỉnh nỗ lực kỹ thuật với kết quả kinh doanh? Làm thế nào để bạn làm cho kỹ thuật thực sự phục vụ kinh doanh chứ không chỉ tồn tại bên cạnh nó? Bạn cần hiểu rõ hơn về mối quan hệ dữ liệu để trả lời những câu hỏi đó. Đó là những câu hỏi đã thúc đẩy gần như mọi quyết định sản phẩm mà chúng tôi đã đưa ra.

Allstacks tập trung vào phân tích dữ liệu trên toàn bộ chu kỳ phát triển phần mềm. Những loại tín hiệu hoặc mẫu nào là dự đoán nhất khi xác định rủi ro giao hàng sớm?

Tôi không nghĩ có một tập hợp các chỉ số duy nhất dự đoán tốt và xấu, mà là các mẫu cho các giai đoạn và loại tổ chức khác nhau. Điều mà tôi thấy hữu ích hơn là nhận ra rằng các tổ chức kỹ thuật đi qua các mùa cải tiến. Tháng này, đó là hiệu suất cơ sở dữ liệu. Tháng sau, đó là giao tiếp giữa các nhóm. Sau đó là “tại sao chúng tôi không thể đóng bất kỳ yêu cầu kéo nào?” Sau đó là khả năng quan sát được. Với tư cách là một nhà lãnh đạo kỹ thuật, bạn đang bơi trong các tín hiệu: một số chẩn đoán, một số giám sát và nhiều tín hiệu chỉ là tiếng ồn.

Điều giúp ích là bắt đầu từ vấn đề bạn thực sự đang thấy, không phải là chỉ số bạn muốn cải thiện. Nếu bạn đang hỏi “tại sao có vẻ như chúng tôi đang giao hàng ít hơn so với năm ngoái”, đó là điểm xuất phát đúng. Từ đó, tôi nghĩ bạn cần ba loại chỉ số: đầu tiên, làm thế nào bạn biết vấn đề là thực sự tồn tại (có thể là số yêu cầu kéo trên mỗi nhà phát triển theo thời gian); thứ hai, những thay đổi bạn đang thực hiện và cách bạn theo dõi chúng dọc theo đường đi (ví dụ: việc áp dụng một người xem xét yêu cầu kéo AI nếu đó là can thiệp của bạn); và thứ ba, mức độ quan trọng của vấn đề đối với kinh doanh. Cảm giác trực giác của bạn có thể đúng rằng bạn đang giao hàng ít hơn 20% mã, nhưng câu chuyện thực sự có thể là QA hiện đang mất nhiều thời gian hơn ba lần. Bạn cần cả ba ống kính để biết liệu bạn đang giải quyết vấn đề đúng hay không.

Bạn đã làm việc trong các ngành như chăm sóc sức khỏe, năng lượng và công nghệ. Những thách thức trong giao hàng phần mềm khác nhau như thế nào trên các lĩnh vực này và làm thế nào điều đó đã định hình nền tảng Allstacks?

Tôi thực sự đánh giá cao kinh nghiệm của mình trong các lĩnh vực phi công nghệ thuần túy. Trong các công ty SaaS, rất dễ bị mất tập trung vào ý tưởng rằng phần mềm chính nó là mục tiêu. Khi bạn ở trong một doanh nghiệp nơi bạn không trực tiếp bán phần mềm, vai trò của bạn trở nên rõ ràng hơn: công nghệ được sử dụng để hỗ trợ kinh doanh. Tôi thường đùa rằng nếu kinh doanh có thể đạt được mọi thứ với cùng tốc độ mà không phải đối phó với tôi, họ sẽ chọn tùy chọn đó mà không chớp mắt.

Quan điểm đó thực sự hữu ích. Nó đặt lại bối cảnh cho tất cả những gì chúng ta đang làm trong ngành này và nó đặt lại nhiều cuộc tranh luận về công nghệ vào đúng vị trí của chúng. Kinh doanh không quan tâm liệu bạn sử dụng Python hay Go. Việc chi tiêu chu kỳ cho việc viết lại đó có thể không phải là nơi có lợi nhuận thực sự.

Điều gì vẫn nhất quán trên mọi ngành là vấn đề phân mảnh. Bất kể lĩnh vực nào, mọi tổ chức kỹ thuật đều có dữ liệu phân tán trên một tá công cụ với mô hình kết nối hạn chế giữa chúng. Các chi tiết khác nhau: các ngành được quản lý có chu kỳ lập kế hoạch dài hơn và sự khoan dung thấp hơn đối với sự mơ hồ trong yêu cầu vì chi phí xây dựng điều gì đó sai là cao hơn. Các cửa hàng công nghệ có tốc độ cao tích lũy nợ ẩn nhanh hơn. Nhưng chế độ thất bại cốt lõi là như nhau. Các nhóm có thể cho bạn biết những gì đã được giao hàng. Họ không thể theo dõi tại sao một điều gì đó trượt hoặc chi phí của nó là gì hoặc rủi ro ở đâu có thể nhìn thấy trước khi nó trở thành một vấn đề. Đó là những gì đã định hình cách chúng tôi xây dựng nền tảng.

Có một câu chuyện ngày càng tăng rằng AI đang tăng tốc mã hóa trong khi暴露 điểm yếu ở nơi khác. Tại sao các yêu cầu, lập kế hoạch và sự sẵn sàng của thông số kỹ thuật đang trở thành những nút thắt thực sự?

Chúng tôi đang chứng kiến điều này hàng ngày. Với một tác nhân tốt và một bộ phận bảo vệ vững chắc xung quanh nó, bạn có thể di chuyển từ ý tưởng, đôi khi trực tiếp từ miệng của khách hàng, đến sản xuất trong vài giờ.

Một phần của điều làm cho sự thay đổi này trở nên quan trọng là sự thay đổi trong vòng phản hồi. Với các công cụ kiểu đồng hành, con người nằm trong vòng lặp trên mỗi gợi ý. AI đưa ra một hoàn thành; bạn chấp nhận hoặc từ chối nó ngay lập tức. Khi nó sai, bạn bắt gặp nó nhanh. Vùng ảnh hưởng của một gợi ý sai là một dòng mã. Mã hóa tác nhân hoạt động khác: bạn đưa cho tác nhân một mục tiêu, nó phân rã công việc, thực hiện một kế hoạch nhiều bước và cung cấp một mô-đun hoạt động. Con người xem xét đầu ra, không phải mỗi bước. Khi thông số kỹ thuật sai, tác nhân xây dựng toàn bộ thực hiện theo thông số kỹ thuật sai và bạn tìm ra nó tại thời điểm xem xét.

Điều đó nghe có vẻ như thuần túy là ưu điểm cho đến khi bạn nhận ra rằng thời gian trễ trước đây thực sự phục vụ một mục đích thực sự. Thời gian trễ đã phục vụ một mục đích thực sự. Nhiều vòng của những người thông minh xem xét, lập kế hoạch, kiểm tra và làm việc thông qua ý tưởng để tạo ra một hệ thống tốt hơn.

Sự cám dỗ bây giờ là bỏ qua tất cả những điều đó và cảm nhận nó. Nhưng các tác nhân và bộ bảo vệ không sẵn sàng cho toàn bộ chu kỳ phát triển phần mềm yet. Tốc độ là thực. Chất lượng kiểm soát mà trước đây đã xảy ra trên tất cả các bước chậm hơn không được thay thế. Đó là khoảng trống.

Nhiều tổ chức vẫn đo lường năng suất bằng các chỉ số lỗi thời. Những nhà lãnh đạo đang sai lầm cơ bản về năng suất trong môi trường phát triển được thúc đẩy bởi AI?

Người ta đã trưởng thành đáng kể về chủ đề này kể từ khi chúng tôi bắt đầu Allstacks. Việc đo lường đã chuyển sang những thứ thực sự quan trọng, và các khuôn khổ đã trở nên tinh vi hơn. AI làm đảo lộn tất cả.

Phát triển phần mềm truyền thống cơ bản bị giới hạn bởi tốc độ một nhà phát triển có thể viết mã đáp ứng yêu cầu của kinh doanh và công nghệ cơ bản. Chi phí đó đang tiếp cận zero. Điều chúng tôi đang chuyển sang là một điều gì đó gần giống với một nhà phát triển cá nhân như một người quản lý các tác nhân. Mô hình đó yêu cầu một cách tiếp cận hoàn toàn khác để đo lường năng suất, một cách tiếp cận dựa trên một điều gì đó khác với mã được tạo ra hoặc giờ làm việc của nhà phát triển.

Một phần của sự nguy hiểm với các chỉ số hiện tại là chúng che giấu những gì thực sự đang xảy ra ở cấp độ nhóm. Các kỹ sư cao cấp với các công cụ AI đang tích lũy lợi thế của họ: họ có bối cảnh cơ sở mã và phán quyết để điều khiển đầu ra của tác nhân và bắt những thất bại tinh vi. Các kỹ sư sự nghiệp sớm thường tạo ra cùng một lượng mã nhưng dành nhiều thời gian hơn để kiểm tra đầu ra mà họ không thể đánh giá đầy đủ. Tốc độ tổng hợp trông ổn, có thể thậm chí được cải thiện. Khoảng cách giữa hai nhóm đó không hiển thị ở bất kỳ nơi nào trong bảng điều khiển tiêu chuẩn. Câu hỏi đúng để bắt đầu hỏi là không phải “chúng tôi nhanh hơn bao nhiêu” mà “bao nhiêu trong những gì chúng tôi đã giao hàng là đúng từ đầu tiên”.

Chúng tôi vẫn chưa có sự đồng thuận của ngành về mô hình đo lường đúng, nhưng các nhóm bắt đầu theo dõi chất lượng đầu ra và tỷ lệ làm lại, không chỉ là sản lượng và việc áp dụng, sẽ được đặt ở vị trí tốt hơn so với các nhóm chờ đợi ai đó khác để tìm ra.

Nền tảng của bạn kết nối dữ liệu từ các công cụ như hệ thống quản lý dự án và kho mã. Làm thế nào quan trọng để thống nhất các nguồn dữ liệu phân mảnh này và điều gì xảy ra khi các tổ chức không làm như vậy?

Allstacks đã thành công trong không gian này vì chúng tôi đã xây dựng các đồ thị ngữ cảnh từ trước khi đó là một thuật ngữ. Chúng tôi đã nhận ra sớm rằng việc kết nối tất cả dữ liệu lại với nhau là cần thiết để trả lời các câu hỏi mà khách hàng thực sự đang hỏi.

Khi kết nối đó không tồn tại, AI hoạt động trên dữ liệu kỹ thuật của bạn chỉ có thể nhìn thấy một phần của bức tranh. Nó có thể phân tích những gì trong hệ thống quản lý dự án của bạn. Nó có thể phân tích những gì trong kho mã của bạn. Điều nó không thể làm là theo dõi một sự chậm trễ trong giao hàng trở lại một sự phụ thuộc bị chặn trên ba công cụ, vì mối quan hệ giữa những tín hiệu đó không tồn tại trong lớp dữ liệu. Bạn sẽ nhận được phân tích nông nhất, và các khuyến nghị sai lầm tự tin nhất, tồi tệ nhất. Chất lượng mô hình không giải quyết được điều này. Bạn có thể đặt mô hình có khả năng nhất có sẵn trên các tích hợp API thô và vẫn bỏ lỡ nguyên nhân thực sự của một vấn đề vì dữ liệu không mã hóa mối quan hệ giữa các tín hiệu. Dữ liệu rác, rác ra, bất kể mô hình thông minh như thế nào.

Kết nối đó là nền tảng. Đó là điều đã cho phép chúng tôi là người đầu tiên trên thị trường với các khả năng vẫn chưa được nhân rộng.

Khi các tác nhân AI trở nên nhúng sâu vào các quy trình phát triển, một tổ chức kỹ thuật được chuẩn bị tốt trông như thế nào so với một tổ chức không sẵn sàng?

Ironically, nó không khác nhiều so với việc chuẩn bị để đưa một lớp thực tập sinh mùa hè vào. Bạn cần các bộ thử nghiệm tự động mạnh, tài liệu vững chắc, một đường ống CI/CD trưởng thành và các rào cản bạn sẽ đặt khi bạn thêm một nhà phát triển được đào tạo nhưng không được đào tạo vào nhóm.

Điều gì cũng quan trọng, và mọi người có xu hướng đánh giá thấp điều này, là quay lại thường xuyên để xem lại các cơ bản: các quy tắc tác nhân của bạn, các tệp AGENTS.MD của bạn. Bạn có thể làm một lượt đầu tiên vững chắc, nhưng rất dễ bị rơi vào nhịp điệu của việc giao hàng theo cách mới và quên rằng bạn thực sự có thể đào tạo đi nhiều mặc định xấu. Những thứ như việc dạy cho tác nhân chạy các thử nghiệm trước mỗi lần cam kết không nên yêu cầu một lời nhắc nhở của con người mỗi lần.

Một câu hỏi chẩn đoán tôi sẽ đặt ra cho bất kỳ nhà lãnh đạo kỹ thuật nào: bạn có thể cho tôi biết những gì mà các tác nhân của bạn đã tạo ra trong sprint cuối cùng, đầu ra nào được chấp nhận như là và đầu ra nào được sửa lại, và nỗ lực sửa lại được tập trung ở đâu? Nếu bạn có thể trả lời điều đó, bạn có công cụ để cải thiện. Nếu bạn không thể, bạn đang bay bằng cảm giác.

Bạn đã nhấn mạnh tầm quan trọng của việc căn chỉnh công việc kỹ thuật với kết quả kinh doanh. Các tổ chức có thể bắc cầu khoảng trống này một cách thực tế và có thể đo lường như thế nào?

Tôi đã thấy hai chế độ thất bại chính. Đầu tiên là các công ty không ghép các nhóm kỹ thuật với sản phẩm. Nhiều cấu trúc nhóm là di sản và đã có từ lâu. Một nhóm có thể sở hữu một phần của ba sản phẩm khác nhau trong khi nhóm khác sở hữu bốn sản phẩm hoàn toàn. Đầu tư kỹ thuật chủ yếu dựa trên số lượng đầu người, và khi các nhóm không được căn chỉnh với sản phẩm, nó trở nên rất khó để thấy nơi kỳ vọng kinh doanh khác biệt với thực tế.

Chế độ thất bại thứ hai là không tính đến tất cả công việc đi vào xây dựng và duy trì phần mềm. Có một thể loại lớn công việc kỹ thuật vô hình đối với kinh doanh. Ví dụ yêu thích của tôi là giữ cho các gói được cập nhật. Các nhà lãnh đạo kinh doanh phi kỹ thuật thường gặp khó khăn trong việc hiểu giá trị hoặc tại sao nó liên tục và không thể đoán trước. Nhưng họ có thể hiểu các danh mục đầu tư. Nếu bạn định khung nó như “nâng cấp bảo mật quan trọng” và hiển thị trung bình bao nhiêu khả năng nó tiêu thụ, bạn đang nói một ngôn ngữ họ có thể làm việc với.

Nếu bạn hỏi một nhà lãnh đạo bán hàng để chọn giữa một số cập nhật gói npm và tính năng họ cần để đóng một thỏa thuận, tính năng sẽ thắng mọi lúc. Nhưng nếu bạn định khung nó như “chúng tôi không tuân thủ SOC hoặc chúng tôi giao hàng tính năng”, bây giờ bạn đang hiển thị cho họ hai sự đánh đổi mà họ thực sự có thể đánh giá. Việc định khung lại đó là toàn bộ trò chơi. Chúng tôi đã thấy khách hàng cắt giảm thời gian báo cáo vốn hóa R&D của họ hơn hai phần ba chỉ bằng cách làm cho công việc phân loại tự động chứ không phải thủ công. Cơ chế là như nhau cho dù mục tiêu là báo cáo vốn hóa, lý do đầu người, hoặc chứng minh ROI của AI: dữ liệu kết nối thay thế bảng tính tương quan.

Với nền tảng của bạn kết nối dữ liệu từ các công cụ như hệ thống quản lý dự án và kho mã, làm thế nào quan trọng để thống nhất các nguồn dữ liệu phân mảnh này và điều gì xảy ra khi các tổ chức không làm như vậy?

Allstacks đã thành công trong không gian này vì chúng tôi đã xây dựng các đồ thị ngữ cảnh từ trước khi đó là một thuật ngữ. Chúng tôi đã nhận ra sớm rằng việc kết nối tất cả dữ liệu lại với nhau là cần thiết để trả lời các câu hỏi mà khách hàng thực sự đang hỏi.

Khi kết nối đó không tồn tại, AI hoạt động trên dữ liệu kỹ thuật của bạn chỉ có thể nhìn thấy một phần của bức tranh. Nó có thể phân tích những gì trong hệ thống quản lý dự án của bạn. Nó có thể phân tích những gì trong kho mã của bạn. Điều nó không thể làm là theo dõi một sự chậm trễ trong giao hàng trở lại một sự phụ thuộc bị chặn trên ba công cụ, vì mối quan hệ giữa những tín hiệu đó không tồn tại trong lớp dữ liệu. Bạn sẽ nhận được phân tích nông nhất, và các khuyến nghị sai lầm tự tin nhất, tồi tệ nhất. Chất lượng mô hình không giải quyết được điều này. Bạn có thể đặt mô hình có khả năng nhất có sẵn trên các tích hợp API thô và vẫn bỏ lỡ nguyên nhân thực sự của một vấn đề vì dữ liệu không mã hóa mối quan hệ giữa các tín hiệu. Dữ liệu rác, rác ra, bất kể mô hình thông minh như thế nào.

Kết nối đó là nền tảng. Đó là điều đã cho phép chúng tôi là người đầu tiên trên thị trường với các khả năng vẫn chưa được nhân rộng.

Bạn đã nhấn mạnh tầm quan trọng của việc căn chỉnh công việc kỹ thuật với kết quả kinh doanh. Các tổ chức có thể bắc cầu khoảng trống này một cách thực tế và có thể đo lường như thế nào?

Tôi đã thấy hai chế độ thất bại chính. Đầu tiên là các công ty không ghép các nhóm kỹ thuật với sản phẩm. Nhiều cấu trúc nhóm là di sản và đã có từ lâu. Một nhóm có thể sở hữu một phần của ba sản phẩm khác nhau trong khi nhóm khác sở hữu bốn sản phẩm hoàn toàn. Đầu tư kỹ thuật chủ yếu dựa trên số lượng đầu người, và khi các nhóm không được căn chỉnh với sản phẩm, nó trở nên rất khó để thấy nơi kỳ vọng kinh doanh khác biệt với thực tế.

Chế độ thất bại thứ hai là không tính đến tất cả công việc đi vào xây dựng và duy trì phần mềm. Có một thể loại lớn công việc kỹ thuật vô hình đối với kinh doanh. Ví dụ yêu thích của tôi là giữ cho các gói được cập nhật. Các nhà lãnh đạo kinh doanh phi kỹ thuật thường gặp khó khăn trong việc hiểu giá trị hoặc tại sao nó liên tục và không thể đoán trước. Nhưng họ có thể hiểu các danh mục đầu tư. Nếu bạn định khung nó như “nâng cấp bảo mật quan trọng” và hiển thị trung bình bao nhiêu khả năng nó tiêu thụ, bạn đang nói một ngôn ngữ họ có thể làm việc với.

Nếu bạn hỏi một nhà lãnh đạo bán hàng để chọn giữa một số cập nhật gói npm và tính năng họ cần để đóng một thỏa thuận, tính năng sẽ thắng mọi lúc. Nhưng nếu bạn định khung nó như “chúng tôi không tuân thủ SOC hoặc chúng tôi giao hàng tính năng”, bây giờ bạn đang hiển thị cho họ hai sự đánh đổi mà họ thực sự có thể đánh giá. Việc định khung lại đó là toàn bộ trò chơi. Chúng tôi đã thấy khách hàng cắt giảm thời gian báo cáo vốn hóa R&D của họ hơn hai phần ba chỉ bằng cách làm cho công việc phân loại tự động chứ không phải thủ công. Cơ chế là như nhau cho dù mục tiêu là báo cáo vốn hóa, lý do đầu người, hoặc chứng minh ROI của AI: dữ liệu kết nối thay thế bảng tính tương quan.

Với nền tảng của bạn kết nối dữ liệu từ các công cụ như hệ thống quản lý dự án và kho mã, làm thế nào quan trọng để thống nhất các nguồn dữ liệu phân mảnh này và điều gì xảy ra khi các tổ chức không làm như vậy?

Allstacks đã thành công trong không gian này vì chúng tôi đã xây dựng các đồ thị ngữ cảnh từ trước khi đó là một thuật ngữ. Chúng tôi đã nhận ra sớm rằng việc kết nối tất cả dữ liệu lại với nhau là cần thiết để trả lời các câu hỏi mà khách hàng thực sự đang hỏi.

Khi kết nối đó không tồn tại, AI hoạt động trên dữ liệu kỹ thuật của bạn chỉ có thể nhìn thấy một phần của bức tranh. Nó có thể phân tích những gì trong hệ thống quản lý dự án của bạn. Nó có thể phân tích những gì trong kho mã của bạn. Điều nó không thể làm là theo dõi một sự chậm trễ trong giao hàng trở lại một sự phụ thuộc bị chặn trên ba công cụ, vì mối quan hệ giữa những tín hiệu đó không tồn tại trong lớp dữ liệu. Bạn sẽ nhận được phân tích nông nhất, và các khuyến nghị sai lầm tự tin nhất, tồi tệ nhất. Chất lượng mô hình không giải quyết được điều này. Bạn có thể đặt mô hình có khả năng nhất có sẵn trên các tích hợp API thô và vẫn bỏ lỡ nguyên nhân thực sự của một vấn đề vì dữ liệu không mã hóa mối quan hệ giữa các tín hiệu. Dữ liệu rác, rác ra, bất kể mô hình thông minh như thế nào.

Kết nối đó là nền tảng. Đó là điều đã cho phép chúng tôi là người đầu tiên trên thị trường với các khả năng vẫn chưa được nhân rộng.

Bạn đã nhấn mạnh tầm quan trọng của việc căn chỉnh công việc kỹ thuật với kết quả kinh doanh. Các tổ chức có thể bắc cầu khoảng trống này một cách thực tế và có thể đo lường như thế nào?

Tôi đã thấy hai chế độ thất bại chính. Đầu tiên là các công ty không ghép các nhóm kỹ thuật với sản phẩm. Nhiều cấu trúc nhóm là di sản và đã có từ lâu. Một nhóm có thể sở hữu một phần của ba sản phẩm khác nhau trong khi nhóm khác sở hữu bốn sản phẩm hoàn toàn. Đầu tư kỹ thuật chủ yếu dựa trên số lượng đầu người, và khi các nhóm không được căn chỉnh với sản phẩm, nó trở nên rất khó để thấy nơi kỳ vọng kinh doanh khác biệt với thực tế.

Chế độ thất bại thứ hai là không tính đến tất cả công việc đi vào xây dựng và duy trì phần mềm. Có một thể loại lớn công việc kỹ thuật vô hình đối với kinh doanh. Ví dụ yêu thích của tôi là giữ cho các gói được cập nhật. Các nhà lãnh đạo kinh doanh phi kỹ thuật thường gặp khó khăn trong việc hiểu giá trị hoặc tại sao nó liên tục và không thể đoán trước. Nhưng họ có thể hiểu các danh mục đầu tư. Nếu bạn định khung nó như “nâng cấp bảo mật quan trọng” và hiển thị trung bình bao nhiêu khả năng nó tiêu thụ, bạn đang nói một ngôn ngữ họ có thể làm việc với.

Nếu bạn hỏi một nhà lãnh đạo bán hàng để chọn giữa một số cập nhật gói npm và tính năng họ cần để đóng một thỏa thuận, tính năng sẽ thắng mọi lúc. Nhưng nếu bạn định khung nó như “chúng tôi không tuân thủ SOC hoặc chúng tôi giao hàng tính năng”, bây giờ bạn đang hiển thị cho họ hai sự đánh đổi mà họ thực sự có thể đánh giá. Việc định khung lại đó là toàn bộ trò chơi. Chúng tôi đã thấy khách hàng cắt giảm thời gian báo cáo vốn hóa R&D của họ hơn hai phần ba chỉ bằng cách làm cho công việc phân loại tự động chứ không phải thủ công. Cơ chế là như nhau cho dù mục tiêu là báo cáo vốn hóa, lý do đầu người, hoặc chứng minh ROI của AI: dữ liệu kết nối thay thế bảng tính tương quan.

Được biết bạn có nền tảng về cả kỹ thuật và giảng dạy phát triển web, bạn nhìn thấy vai trò của các nhà phát triển thay đổi như thế nào khi AI chiếm nhiều công việc mã hóa?

Thành thật mà nói, tôi有点 lo lắng, mặc dù tôi tin rằng những người thông minh sẽ tìm ra cách.

Mối quan ngại của tôi là thực sự. Các sinh viên tốt nghiệp mới sẽ sớm bước vào lực lượng lao động mà không bao giờ mã hóa trong một thế giới không có tác nhân mã hóa. Liệu giáo dục đã theo kịp điều đó? Các công cụ di chuyển nhanh; giáo dục đại học không luôn di chuyển cùng tốc độ. Sự thay đổi khác tôi đang theo dõi là sự mờ dần giữa các kỹ sư cao cấp và các chuyên gia sản phẩm cao cấp. Những người thực hành thành công nhất trong mô hình mới là các kỹ sư đã đầu tư sâu vào tư duy sản phẩm.

Điều gì trở nên có giá trị hơn là phán quyết: khả năng định nghĩa một vấn đề chính xác đủ để một tác nhân có thể giải quyết nó, đánh giá xem giải pháp có đúng hay không và bắt những thất bại tinh vi mà vượt qua CI nhưng tạo ra vấn đề kiến trúc sau này. Các kỹ sư cao cấp tích lũy lợi thế của họ vì họ có thể điều khiển đầu ra của tác nhân và biết đầu ra nào để tin tưởng. Mối quan ngại là cho con đường sự nghiệp sớm. Cách truyền thống để xây dựng phán quyết đó là viết nhiều mã và học từ những sai lầm. Vòng phản hồi đó đang thay đổi theo những cách mà ngành chưa hoàn toàn làm việc.

Lịch sử cung cấp một số sự đảm bảo. Có một số lượng đáng kể những người tin rằng các trình biên dịch sẽ khiến các nhà phát triển assembly mất việc. Sự thay đổi công nghệ đã xảy ra như họ dự đoán. Điều gì đã xảy ra với những nhà phát triển không theo cùng kịch bản? Trong thập kỷ sau, tổng số nhà phát triển đã tăng. Nhiều nhà phát triển assembly đã học một ngôn ngữ mới và xuất sắc vì kiến thức cơ bản của họ. Tôi nghĩ một phiên bản của mẫu đó được phát lại.

Nhìn về tương lai, bạn nhìn thấy AI thay đổi chu kỳ phát triển phần mềm như thế nào trong ba đến năm năm tới và các công ty sẽ có lợi thế cạnh tranh lớn nhất ở đâu?

Chúng tôi sẽ chứng kiến một cuộc đua vũ trang về tính năng không giống bất cứ điều gì chúng tôi đã thấy trước đây. Khi chi phí xây dựng tiếp cận zero, các công ty, thậm chí cả các công ty lớn, phải đối mặt với một ràng buộc mới: thu thập và xác thực đủ phản hồi của khách hàng để tiếp tục xây dựng các sản phẩm chất lượng ở quy mô.

Sự thay đổi phải xảy ra là rằng tiêu chuẩn cho những gì được xây dựng cần phải tăng lên. Ràng buộc hiện tại trong hầu hết các tổ chức kỹ thuật là đơn giản: năm ưu tiên hàng đầu, có thể là hai được giao hàng. Với các tác nhân, tỷ lệ đảo lộn. Bạn có thể có năm ưu tiên hàng đầu, mười tiếp theo và hai mươi có thể, và giao hàng một trăm. Câu hỏi mà không ai đã trả lời đầy đủ yet là làm thế nào bạn giữ những cái cuối cùng trong số đó không bị suy nghĩ sai và thực hiện kém.

Hai điều tôi khá tự tin về khung thời gian ba đến năm năm. Đầu tiên, lợi thế cạnh tranh trong AI kỹ thuật sẽ đến từ độ sâu và độ rộng của ngữ cảnh, không phải chất lượng mô hình. Các mô hình đang trở thành những thứ cơ bản; mọi công cụ sẽ có những mô hình có khả năng. Điều sẽ phân biệt các nền tảng hàng đầu là cách sâu sắc chúng hiểu tổ chức cụ thể của bạn: các kho của bạn, cấu trúc nhóm của bạn, lịch sử giao hàng của bạn, mẫu triển khai của bạn. Các công cụ hiểu hệ thống của bạn sẽ tạo ra những câu trả lời cơ bản khác với những công cụ không hiểu. Thứ hai, sự thay đổi từ phản ứng sang chủ động. Ngày nay, các công cụ trả lời câu hỏi khi được hỏi. Trong vài năm, các công cụ hàng đầu sẽ quan sát liên tục và đưa ra rủi ro trước khi bạn hỏi. Các tổ chức xây dựng lớp ngữ cảnh đó bây giờ đang tích lũy một lợi thế. Thế hệ công cụ tiếp theo phải giải quyết vấn đề chất lượng ở quy mô, và các tổ chức tìm ra nó trước sẽ có một lợi thế thực sự. Cảm ơn bạn vì cuộc phỏng vấn tuyệt vời, những người đọc muốn tìm hiểu thêm nên truy cập Allstacks.

Cảm ơn bạn vì cuộc phỏng vấn tuyệt vời, những người đọc muốn tìm hiểu thêm nên truy cập Allstacks.