เจเรมี ฟรีแมน Co-Founder และ CTO ของ Allstacks – สัมภาษณ์ ซีรีส์

เจเรมี ฟรีแมน Co-Founder และ CTO ของ Allstacks เป็นนักพัฒนาซอฟต์แวร์ สถาปนิกเทคโนโลยี และนักธุรกิจที่มีประสบการณ์ยาวนานในด้านการพัฒนาซอฟต์แวร์ วิศวกรรมฮาร์ดแวร์ การเรียนรู้ของเครื่อง และนวัตกรรมผลิตภัณฑ์ ตั้งแต่เริ่มก่อตั้ง Allstacks ในปี 2017 เขาได้นำการออกแบบและพัฒนาพลatform หลักของบริษัท ซึ่งช่วยเปลี่ยนแปลงการบริหารจัดการซอฟต์แวร์ผ่านการวิเคราะห์เชิงพยากรณ์และการคาดการณ์ที่ขับเคลื่อนด้วย AI ก่อนที่จะเข้าร่วม Allstacks ฟรีแมน曾ดำรงตำแหน่งผู้นำที่ Ravioli Labs และ CertiRx โดยทำงานเกี่ยวกับการพัฒนาซอฟต์แวร์ การวิจัย เทคโนโลยีต่อต้านการปลอมแปลง และการพัฒนาผลิตภัณฑ์ ในช่วงต้นอาชีพของเขา เขาได้รับประสบการณ์จากสตาร์ทอัพ บริษัทเทคโนโลยี และสถาบันการศึกษา รวมถึงการสอนพัฒนาวебที่ Wake Technical Community College ประสบการณ์ทางเทคนิคของเขาพูดถึงระบบฝังตัว การออกแบบฮาร์ดแวร์ แพลตฟอร์มซอฟต์แวร์ขนาดใหญ่ การเรียนรู้ของเครื่อง และการเป็นผู้นำด้านวิศวกรรม ซึ่งทำให้เขามีมุมมองที่เป็นเอกลักษณ์ในการสร้างผลิตภัณฑ์ที่ขับเคลื่อนด้วยข้อมูลเพื่อช่วยให้องค์กรปรับปรุงผลลัพธ์ของการนำซอฟต์แวร์ไปใช้

Allstacks เป็นแพลตฟอร์มสำหรับวิศวกรรมอัจฉริยะและจัดการคุณค่าของกระบวนการซอฟต์แวร์ที่ช่วยให้องค์กรปรับปรุงความสามารถในการคาดการณ์และประสิทธิภาพในการพัฒนาซอฟต์แวร์ แพลตฟอร์มนี้รวมข้อมูลจากเครื่องมือต่างๆ ที่ใช้ตลอดวงจรชีวิตการพัฒนาซอฟต์แวร์ รวมถึงระบบจัดการโครงการ ระบบควบคุมแหล่งที่มา และระบบการนำไปใช้ จากนั้นใช้ AI และการเรียนรู้ของเครื่องเพื่อระบุความเสี่ยง คาดการณ์ผลลัพธ์การส่งมอบ และแสดงข้อมูลเชิงลึกที่สามารถนำไปใช้ได้ โดยการให้ความสามารถในการมองเห็นสถานะโครงการ ประสิทธิภาพทีม และแนวโน้มการพัฒนาแก่ผู้นำด้านวิศวกรรมและผลิตภัณฑ์ Allstacks ช่วยให้องค์กรตัดสินใจได้อย่างมีข้อมูล ลดความไม่แน่นอนในการส่งมอบ และจัดแนวความพยายามด้านวิศวกรรมให้สอดคล้องกับวัตถุประสงค์ทางธุรกิจ เทคโนโลยีนี้ได้รับการออกแบบมาเพื่อช่วยให้บริษัทต่างๆ ละทิ้งการวางแผนโดยอาศัย直觉 และใช้ข้อมูลการดำเนินงานแบบเรียลไทม์เพื่อปรับปรุงประสิทธิภาพการนำซอฟต์แวร์ไปใช้และความสามารถในการดำเนินกลยุทธ์

คุณมีเส้นทางที่ไม่เหมือนใครตั้งแต่การนำทีมการวิจัยและวิศวกรรมที่ใช้การเรียนรู้ของเครื่องกับการพัฒนาซอฟต์แวร์ ไปจนถึงการร่วมก่อตั้ง Allstacks ในปี 2017 ปัญหาหรือความท้าทายแบบใดที่คุณสังเกตเห็นซึ่งผลักดันให้คุณสร้างบริษัทนี้

เมื่อเริ่ม Allstacks เราใช้เวลามากในการทำการค้นหาลูกค้า และรูปแบบที่ปรากฏออกมาอย่างต่อเนื่องคือ บริษัทต่างๆ มีข้อมูลจำนวนมาก แต่ก็ยังไม่เข้าใจสิ่งที่เกิดขึ้นจริงๆ การส่งมอบซอฟต์แวร์ไม่สามารถคาดเดาได้ แม้ว่าจะมีคนฉลาดที่สุดในห้อง

สิ่งที่ชัดเจนมากคือปัญหานี้ไม่ใช่ปัญหาในการรายงานหรือการรวมตัว แต่เป็นปัญหาเกี่ยวกับความสัมพันธ์ หากต้องการทราบว่าสิ่งใดอยู่ในความเสี่ยง คุณต้องทราบว่างานใดเชื่อมโยงกับสาขาใด สาขานั้นเชื่อมโยงกับ PR PR เชื่อมโยงกับสปรินต์เป้าหมาย และสปรินต์เป้าหมายเชื่อมโยงกับโครงการธุรกิจ กราฟนี้ไม่มีอยู่ในเครื่องมือมาตรฐานใดๆ คุณต้องสร้างมัน และการสร้างมันให้สำเร็จเป็นปัญหาการอนุมาน ซึ่งเป็นที่ที่ประสบการณ์ทางด้าน ML มีประโยชน์โดยตรง

เป้าหมายของเราตั้งแต่เริ่มต้นไม่ใช่ทำให้นักพัฒนาบุคคลหนึ่งเร็วขึ้นในฟีเจอร์ X แต่เป็นการทำให้องค์กรทั้งหมดดีขึ้น วิธีใดที่จะจัดแนวความพยายามด้านวิศวกรรมให้สอดคล้องกับผลลัพธ์ทางธุรกิจ วิธีใดที่จะทำให้วิศวกรรมมีจริงในการรับใช้ธุรกิจแทนที่จะอยู่ข้างๆ ธุรกิจ คุณต้องมีความเข้าใจที่ดีขึ้นเกี่ยวกับความสัมพันธ์ของข้อมูลเพื่อตอบคำถามเหล่านั้น

Allstacks มุ่งเน้นไปที่การวิเคราะห์ข้อมูลตลอดวงจรชีวิตการพัฒนาซอฟต์แวร์ สัญญาณหรือรูปแบบใดที่มีความสามารถในการคาดการณ์ความเสี่ยงในการส่งมอบได้ดีที่สุด

ฉันไม่คิดว่ามีเซตของเมตริกที่สามารถคาดการณ์ได้ดีหรือไม่ดี แต่สิ่งที่ฉันพบว่ามีประโยชน์มากกว่าคือการรู้ว่าองค์กรวิศวกรรมผ่านช่วงเวลาในการปรับปรุง

สิ่งที่ช่วยได้คือการเริ่มต้นด้วยปัญหาที่คุณเห็นจริงๆ ไม่ใช่เมตริกที่คุณต้องการปรับปรุง หากคุณถามว่า “ทำไมมันรู้สึกเหมือนว่าเราส่งมอบน้อยกว่าปีที่แล้ว” นั่นคือจุดเริ่มต้นที่ถูกต้อง จากนั้น ฉันคิดว่าคุณต้องมีสามประเภทของเมตริก: ประการแรก คุณรู้ว่าปัญหาเป็นจริงหรือไม่ (อาจเป็นจำนวน PR ต่อผู้พัฒนาในระยะเวลา); ประการที่สอง สิ่งที่คุณเปลี่ยนแปลงและติดตามไปพร้อมกัน (เช่น การนำ AI PR reviewer มาใช้หากนั่นคือการแทรกแซงของคุณ); และประการที่สาม ความสำคัญของปัญหานั้นต่อธุรกิจ

คุณทำงานในอุตสาหกรรมต่างๆ เช่น การดูแลสุขภาพ พลังงาน และเทคโนโลยี ความท้าทายในการส่งมอบซอฟต์แวร์แตกต่างกันอย่างไรในอุตสาหกรรมเหล่านี้ และสิ่งนี้มีอิทธิพลต่อแพลตฟอร์ม Allstacks อย่างไร

ฉันให้คุณค่ากับประสบการณ์ของฉันในภาคอุตสาหกรรมที่ไม่ใช่เทคโนโลยีบริสุทธิ์ ในบริษัท SaaS มันง่ายที่จะสูญเสียความคิดที่ว่าซอฟต์แวร์เองเป็นเป้าหมาย เมื่อคุณอยู่ในธุรกิจที่ไม่ได้ขายซอฟต์แวร์โดยตรง บทบาทของคุณจะชัดเจนขึ้น: เทคโนโลยีมีไว้เพื่อสนับสนุนธุรกิจ

มุมมองนี้มีประโยชน์ มันทำให้เราทราบว่าเรากำลังทำอะไรในอุตสาหกรรมนี้ และทำให้การถกเถียงทางเทคนิคหลายอย่างกลับเข้าไปในสถานที่ของมัน ธุรกิจไม่สนใจว่าคุณใช้ Python หรือ Go การใช้เวลาในการเขียนใหม่ไม่ใช่สิ่งที่ให้ผลตอบแทนที่แท้จริง

สิ่งที่คงเส้นคงวาในอุตสาหกรรมทุกอุตสาหกรรมคือปัญหาในการกระจายตัวของข้อมูล องค์กรวิศวกรรมทุกแห่งมีข้อมูลกระจายอยู่ทั่วเครื่องมือต่างๆ โดยมีการเชื่อมต่อระหว่างกันอย่างจำกัด ปัญหาเฉพาะอาจแตกต่างกัน: อุตสาหกรรมที่มีการควบคุมมีช่วงการวางแผนยาวขึ้นและความทนต่อความไม่แน่นอนในข้อกำหนดที่ต่ำกว่า เนื่องจากต้นทุนในการสร้างสิ่งที่ไม่ถูกต้องสูงกว่า ร้านค้าเทคโนโลยีที่มีความเร็วสูงสะสมหนี้ที่ซ่อนอยู่ได้เร็วขึ้น แต่โหมดการล้มเหลวหลักนั้นเหมือนกัน ทีมสามารถบอกคุณได้ว่าสิ่งใดที่ส่งมอบ แต่พวกเขาไม่สามารถระบุได้ว่าทำไมบางสิ่งลื่นไถลไป และไม่สามารถระบุความเสี่ยงก่อนที่จะกลายเป็นปัญหาได้

มีเรื่องราวที่เพิ่มขึ้นเกี่ยวกับการเร่งความเร็วในการเขียนโค้ดโดย AI ในขณะเดียวกันก็เปิดเผยจุดอ่อนในที่อื่น ทำไมข้อกำหนด การวางแผน และความพร้อมของสเปคจึงกลายเป็นปัญหาอุดตันจริงๆ

เราจะเห็นสิ่งนี้ทุกวัน ด้วยตัวแทนและฮาร์เนสที่ดี คุณสามารถย้ายจากความคิดไปสู่การผลิตได้ภายในเวลาเพียงไม่กี่ชั่วโมง

สิ่งหนึ่งที่ทำให้การเปลี่ยนแปลงนี้มีนัยสำคัญคือการเปลี่ยนแปลงของวงจรการให้ข้อมูลกลับ เมื่อใช้เครื่องมือประเภท copilot มนุษย์อยู่ในวงจรการให้ข้อมูลกลับทุกคำแนะนำ AI เสนอการเติมเต็ม; คุณยอมรับหรือปฏิเสธทันที เมื่อมันผิด คุณจับได้อย่างรวดเร็ว พื้นที่ที่ถูกทำลายของคำแนะนำที่ไม่ดีคือบรรทัดโค้ดเดียว การเขียนโค้ดแบบ agentic ทำงานแตกต่าง: คุณให้ตัวแทนเป้าหมาย ตัวแทนจะแบ่งงานออกเป็นหลายขั้นตอนและดำเนินการตามแผนหลายขั้นตอนเพื่อส่งมอบโมดูลที่ทำงานได้ มนุษย์ตรวจสอบผลลัพธ์ ไม่ใช่ทุกขั้นตอน เมื่อสเปคไม่ถูกต้อง ตัวแทนสร้างการดำเนินการเต็มรูปแบบตามสเปคที่ไม่ถูกต้อง และคุณพบว่ามันผิดพลาดเมื่อตรวจสอบ

การเปลี่ยนแปลงนี้ดูเหมือนจะมีแต่ข้อดีจนกระทั่งคุณรู้ว่าเวลาที่ล่าช้ามาก่อนหน้านี้มีจุดมุ่งหมายที่แท้จริง มันทำให้คนฉลาดหลายคนสามารถตรวจสอบ วางแผน ทดสอบ และทำงานผ่านความคิดเพื่อสร้างระบบที่ดีกว่า

หลายองค์กรยังคงวัดผลผลิตโดยใช้เมตริกที่ล้าสมัย สิ่งที่ผู้นำได้ไม่ถูกต้องเกี่ยวกับผลผลิตใน môi trườngการพัฒนาที่ขับเคลื่อนด้วย AI คืออะไร

คนส่วนใหญ่เติบโตขึ้นในเรื่องนี้อย่างมากตั้งแต่เริ่ม Allstacks การวัดได้เปลี่ยนไปสู่สิ่งที่มีความหมายจริงๆ และเฟรมเวิร์กได้กลายเป็นมีประสิทธิภาพมากขึ้น AI เปลี่ยนแปลงทุกอย่าง

การพัฒนาซอฟต์แวร์แบบดั้งเดิมถูกจำกัดโดยพื้นฐานจากความเร็วที่นักพัฒนาสามารถเขียนโค้ดที่ตรงตามข้อกำหนดของธุรกิจและเทคโนโลยีใต้พื้นผิวได้ ต้นทุนนั้นใกล้จะถึงศูนย์แล้ว สิ่งที่เรากำลังจะเข้าไปสู่คือสิ่งที่ใกล้เคียงกับนักพัฒนาบุคคลหนึ่งเป็นผู้จัดการตัวแทน ซึ่งต้องการแนวทางใหม่ในการวัดผลผลิตที่ไม่ขึ้นอยู่กับโทเค็นที่สร้างขึ้นหรือชั่วโมงทำงานของนักพัฒนา

สิ่งหนึ่งที่เป็นอันตรายในเมตริกปัจจุบันคือการซ่อนสิ่งที่เกิดขึ้นจริงๆ ที่ระดับทีม วิศวกรอาวุโสที่มีเครื่องมือ AI มีการสะสมความได้เปรียบ: พวกเขามีบริบทของโค้ดเบสและความตัดสินที่จะชี้นำผลลัพธ์ของตัวแทนและจับข้อผิดพลาดที่ล้มเหลว นักพัฒนาที่มีอายุน้อยกว่าสร้างปริมาณโค้ดเท่ากัน แต่ใช้เวลามากขึ้นในการตรวจสอบผลลัพธ์ที่พวกเขาไม่สามารถประเมินได้อย่างเต็มที่ ความเร็วรวมดูเหมือนดี แต่ความแตกต่างระหว่างสองกลุ่มนี้ไม่ปรากฏในแดชบอร์ดมาตรฐาน

เรายังไม่มีฉันทามติในอุตสาหกรรมเกี่ยวกับแบบจำลองการวัดที่ถูกต้อง แต่ทีมที่เริ่มต้นทำการ跟踪คุณภาพของผลลัพธ์และอัตราการทำงานซ้ำ ไม่ใช่แค่ปริมาณและความนิยม จะมีตำแหน่งที่ดีกว่าทีมที่รอใครสักคนมาค้นหาวิธีแก้ปัญหา

แพลตฟอร์มของคุณเชื่อมต่อข้อมูลจากเครื่องมือต่างๆ เช่น ระบบจัดการโครงการและคลังโค้ด ความสำคัญของการรวมข้อมูลที่กระจัดกระจายเหล่านี้คืออะไร และสิ่งที่เกิดขึ้นเมื่อองค์กรล้มเหลวในการทำเช่นนั้น

Allstacks ประสบความสำเร็จในพื้นที่นี้เพราะเราได้สร้างกราฟบริบทตั้งแต่ก่อนที่จะเรียกว่า “กราฟบริบท” เรารับรู้ตั้งแต่เนิ่นๆ ว่าการเชื่อมต่อข้อมูลทั้งหมดเข้าด้วยกันจำเป็นต่อการตอบคำถามที่ลูกค้าถามจริงๆ

เมื่อการเชื่อมต่อนั้นไม่มีอยู่ AI ที่ทำงานบนข้อมูลวิศวกรรมของคุณสามารถมองเห็นเพียงส่วนหนึ่งของภาพเท่านั้น มันสามารถวิเคราะห์สิ่งที่อยู่ในระบบจัดการโครงการของคุณ มันสามารถวิเคราะห์สิ่งที่อยู่ในคลังโค้ดของคุณ แต่สิ่งที่มันทำไม่ได้คือการตรวจสอบความล่าช้าในการส่งมอบกลับไปยัง依存ที่ถูกบล็อกข้ามเครื่องมือสามเครื่อง เพราะ ความสัมพันธ์ระหว่างสัญญาณเหล่านั้นไม่มีอยู่ในระดับข้อมูล คุณได้รับการวิเคราะห์ระดับผิวเผินในระดับดีที่สุด และคำแนะนำที่มั่นใจและผิดพลาดในทางที่แย่ ทั้งนี้ไม่ว่าโมเดลจะมีคุณภาพสูงเพียงใด คุณต้องการการเชื่อมต่อนั้นเป็นพื้นฐาน มันทำให้เราเป็นคนแรกที่เข้าสู่ตลาดด้วยความสามารถที่ยังไม่ได้ถูกทำซ้ำ

เมื่อตัวแทน AI ถูกฝังอยู่ในกระบวนการทำงานของการพัฒนา ซึ่งองค์กรวิศวกรรมที่เตรียมพร้อมแตกต่างจากที่ไม่พร้อมอย่างไร

จริงๆ แล้วไม่แตกต่างจากการที่จะเตรียมพร้อมที่จะนำผู้ฝึกงานฤดูร้อนเข้ามา คุณต้องมีชุดการทดสอบอัตโนมัติที่แข็งแกร่ง เอกสารที่ดี ปายพิ้น CI/CD ที่มีประสิทธิภาพ และราวanguard ที่คุณวางไว้เมื่อคุณเพิ่มนักพัฒนาที่เชื่อถือได้แต่ไม่ได้รับการฝึกอบรมเข้าทีม

สิ่งที่สำคัญและคนมักจะประเมินค่าต่ำคือการกลับมาทบทวนพื้นฐานเป็นประจำ: กฎของตัวแทนของคุณ ไฟล์ AGENTS.MD ของคุณ คุณสามารถทำการผ่านครั้งแรกได้ดี แต่มันง่ายที่จะเข้าไปในจังหวะการส่งมอบในแบบใหม่และลืมไปว่าคุณสามารถฝึกหัดตัวแทนให้หลีกเลี่ยงค่าเริ่มต้นที่ไม่ดีได้จริงๆ สิ่งเช่นการฝึกตัวแทนให้ทำงานทดสอบก่อนทุกการ提交ไม่ควรต้องมีการเตือนของมนุษย์ทุกครั้ง

คำถามการวินิจฉัยที่ฉันจะถามผู้นำวิศวกรรมทุกคนคือ: คุณสามารถบอกฉันได้หรือไม่ว่าตัวแทนของคุณสร้างอะไรในสปรินต์ที่แล้ว อะไรที่ถูกยอมรับตามที่เป็น และความพยายามในการแก้ไขมีศูนย์กลางอยู่ที่ไหน หากคุณสามารถตอบคำถามนั้นได้ คุณมีเครื่องมือในการปรับปรุง หากคุณไม่สามารถตอบได้ คุณบินโดยไม่มีการมองเห็น

คุณเน้นย้ำถึงความสำคัญของการเชื่อมโยงงานวิศวกรรมกับผลลัพธ์ทางธุรกิจ องค์กรสามารถข้ามช่องว่างนี้ได้อย่างไรในทางปฏิบัติและวัดผลได้

ฉันเห็นสองรูปแบบการล้มเหลวหลัก รูปแบบแรกคือบริษัทที่ไม่จับคู่ทีมวิศวกรรมกับผลิตภัณฑ์ โครงสร้างทีมส่วนใหญ่เป็นมรดกที่มีอยู่มานาน ทีมหนึ่งอาจเป็นเจ้าของส่วนหนึ่งของผลิตภัณฑ์สามชิ้น ในขณะที่อีกทีมหนึ่งอาจเป็นเจ้าของผลิตภัณฑ์สี่ชิ้นโดยสมบูรณ์ การลงทุนด้านวิศวกรรมส่วนใหญ่ขึ้นอยู่กับจำนวนพนักงาน เมื่อทีมไม่จับคู่กับผลิตภัณฑ์ มันจะยากที่จะเห็นว่าที่ไหนที่ความคาดหวังทางธุรกิจเบี่ยงเบนไปจากความเป็นจริง

รูปแบบการล้มเหลวที่สองคือการไม่คำนึงถึงงานวิศวกรรมทั้งหมดที่เกี่ยวข้องกับการสร้างและบำรุงรักษาซอฟต์แวร์ มีหมวดงานวิศวกรรมที่ไม่มองเห็นได้จากธุรกิจ ตัวอย่างที่ฉันชื่นชอบคือการอัปเดตแพ็คเกจ นักธุรกิจที่ไม่ใช่เทคนิคมักจะดิ้นรนที่จะเข้าใจคุณค่าหรือทำไมมันจึงดำเนินต่อไปและไม่คาดเดาได้ แต่พวกเขาสามารถเข้าใจหมวดการลงทุนได้ หากคุณวางกรอบมันเป็น “การอัปเดตความปลอดภัยที่สำคัญ” และแสดงให้เห็นว่าโดยเฉลี่ยใช้ความสามารถไปเท่าใด คุณกำลังพูดภาษาที่พวกเขาสามารถทำงานร่วมกันได้

หากคุณถามผู้นำฝ่ายขายให้เลือกระหว่างการอัปเดตแพ็คเกจบางตัวและคุณลักษณะที่พวกเขาต้องการเพื่อปิดการขาย คุณลักษณะนั้นจะชนะทุกครั้ง แต่ถ้าคุณวางกรอบมันเป็น “เราออกจากการปฏิบัติตาม SOC หรือเราส่งคุณลักษณะนี้” ตอนนี้คุณกำลังให้พวกเขาเลือกระหว่างสองทางเลือกที่พวกเขาสามารถประเมินได้ การจัดกรอบนี้คือเกมทั้งหมด เราได้เห็นลูกค้าที่ลดเวลาในการรายงาน R&D ที่ต้องตั้งบัญชีมากกว่าสองในสามเพียงแค่ทำให้การจำแนกงานอัตโนมัติแทนการทำด้วยมือ

ด้วยพื้นหลังของคุณทั้งในด้านวิศวกรรมเชิงปฏิบัติและการสอนพัฒนาวェ็บ คุณเห็นว่าบทบาทของนักพัฒนาจะพัฒนาไปอย่างไรเมื่อ AI เข้ามาแบ่งปันงานเขียนโค้ด

ฉันซื่อสัตย์ ฉัน有点กังวล แม้ว่าฉันจะเชื่อว่าคนฉลาดจะแก้ปัญหาได้

ความกังวลของฉันคือเรื่องจริง จบการศึกษาใหม่ๆ จะเข้าสู่ตลาดแรงงานโดยไม่เคยเขียนโค้ดในโลกที่ไม่มีตัวแทนเขียนโค้ด การศึกษามีให้ทันการเปลี่ยนแปลงของเครื่องมือเหล่านี้หรือไม่ การเปลี่ยนแปลงของเครื่องมือเกิดขึ้นอย่างรวดเร็ว การศึกษาระดับอุดมศึกษามักจะไม่เคลื่อนไหวไปพร้อมๆ กับพวกมัน

สิ่งที่มีคุณค่ามากขึ้นคือการตัดสิน: ความสามารถในการกำหนดปัญหาให้เจาะจงพอที่ตัวแทนจะแก้ได้ ประเมินว่าวิธีแก้ปัญหานั้นถูกต้องหรือไม่ และจับข้อผิดพลาดเล็กๆ น้อยๆ ที่ผ่านการทดสอบ CI แต่สร้างปัญหาเชิงสถาปัตยกรรมในภายหลัง วิศวกรอาวุโสสะสมความได้เปรียบเพราะพวกเขาสามารถชี้นำผลลัพธ์ของตัวแทนและรู้ว่าผลลัพธ์ใดที่เชื่อถือได้

ความกังวลคือสำหรับเส้นทางอาชีพในช่วงแรก การสะสมการตัดสินแบบดั้งเดิมคือการเขียนโค้ดจำนวนมากและเรียนรู้จากข้อผิดพลาด วงจรการให้ข้อมูลกลับนี้กำลังเปลี่ยนแปลงไปในทางที่อุตสาหกรรมยังไม่ได้ทำงานผ่าน

ประวัติศาสตร์ให้ความมั่นใจบางอย่าง มีคนจำนวนมากที่เชื่อว่าคอมไพล์เลอร์จะทำให้นักพัฒนาซอฟต์แวร์แบบแอสเซมบลีออกจากงาน การเปลี่ยนแปลงทางเทคโนโลยีนั้นเกิดขึ้นตามที่พวกเขาคาดการณ์ไว้ สิ่งที่เกิดขึ้นกับนักพัฒนาซอฟต์แวร์ที่ไม่ได้ทำตามสคริปต์เดียวกัน คือจำนวนผู้พัฒนาทั้งหมดเพิ่มขึ้นในรอบทศวรรษถัดไป นักพัฒนาซอฟต์แวร์หลายคนที่เขียนโค้ดแอสเซมบลีได้เรียนรู้ภาษาใหม่และโดดเด่นเนื่องจากความรู้พื้นฐาน ฉันคิดว่ารูปแบบที่คล้ายกันนี้จะเกิดขึ้นอีกครั้ง

เมื่อมองไปข้างหน้า คุณเห็นว่า AI จะเปลี่ยนแปลงชีวิตการทำงานของการพัฒนาซอฟต์แวร์ในช่วงสามถึงห้าปีหน้าอย่างไร และที่ไหนที่บริษัทต่างๆ จะได้รับประโยชน์มากที่สุด

เราจะเห็นการแข่งขันฟีเจอร์ที่ไม่เคยเห็นมาก่อน เมื่อต้นทุนในการสร้างเข้าใกล้ศูนย์ บริษัทต่างๆ รวมถึงขนาดใหญ่ๆ ด้วย จะต้องเผชิญกับการจำกัดใหม่: การรวบรวมและตรวจสอบข้อเสนอแนะของลูกค้าเพียงพอที่จะสร้างสิ่งที่มีคุณภาพอย่างต่อเนื่อง

การเปลี่ยนแปลงที่ต้องเกิดขึ้นคือมาตรฐานที่จะสร้างสิ่งใดต้องสูงขึ้น ข้อจำกัดในปัจจุบันในองค์กรวิศวกรรมส่วนใหญ่คือเรื่องง่าย: ห้าลำดับความสำคัญสูงสุด อาจมีสองรายการถูกส่งมอบ ด้วยตัวแทน อัตราส่วนกลับกัน คุณอาจมีลำดับความสำคัญสูงสุดห้ารายการ ต่อไปเป็นสิบ และอาจเป็นรายการที่อาจเป็นไปได้ถึงยี่สิบ และส่งมอบได้ถึงหนึ่งร้อย สิ่งที่ไม่มีใครตอบได้เลยคือวิธีการป้องกันไม่ให้สิ่งเหล่านั้นหกสิบห้ารายการสุดท้ายไม่ถูกออกแบบและดำเนินการอย่างไม่ดี

สองสิ่งที่ฉันมั่นใจสำหรับช่วงสามถึงห้าปีแรก คือ ประการแรก ความได้เปรียบในการแข่งขันในด้าน AI ของวิศวกรรมจะมาจากความลึกและความกว้างของบริบท ไม่ใช่คุณภาพของโมเดล โมเดลเหล่านี้กำลังจะกลายเป็นมาตรฐาน; ทุกเครื่องมือจะมีโมเดลที่มีประสิทธิภาพ สิ่งที่จะทำให้แพลตฟอร์มชั้นนำแตกต่างออกไปคือความเข้าใจที่ลึกซึ้งเกี่ยวกับองค์กรของคุณ: โค้ดเบสของคุณ โครงสร้างทีม ประวัติการส่งมอบ รูปแบบการนำไปใช้ เครื่องมือที่เข้าใจระบบของคุณจะให้คำตอบที่แตกต่างไปจากเครื่องมือที่ไม่เข้าใจ

ที่สอง คือการเปลี่ยนจากการตอบสนองเป็นการคาดการณ์ เครื่องมือในปัจจุบันตอบคำถามเมื่อถูกถาม ในอีกไม่กี่ปี เครื่องมือชั้นนำจะสังเกตอย่างต่อเนื่องและแสดงความเสี่ยงก่อนที่คุณจะถาม องค์กรที่สร้างชั้นบริบทนี้ตอนนี้กำลังสะสมความได้เปรียบ การพัฒนาเครื่องมือรุ่นต่อไปจะต้องแก้ปัญหาเรื่องคุณภาพในระดับใหญ่ และองค์กรที่แก้ปัญหาได้ก่อนจะได้เปรียบจริงๆ

ขอขอบคุณสำหรับการสัมภาษณ์ที่ดี ผู้อ่านสามารถเรียนรู้เพิ่มเติมได้ที่ Allstacks