การระเบิดของ API เป็นเรื่องจริง – และ Vibe Coding เป็นตัวจุดชนวน

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

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

แต่ตอนนี้? เครื่องมือพัฒนาที่ใช้ AI ได้ทำลายข้อจำกัดนั้น

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

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

การเพิ่มขึ้นของ “Vibe Coding”

API ที่สร้างขึ้นโดย AI รุ่นใหม่นี้มักจะมาถึงโดยไม่มีการวางแผนการออกแบบ การจัดทำเอกสาร หรือการตรวจสอบ เราเรียกปรากฏการณ์นี้ว่า “การเขียนโค้ดตามความรู้สึก” – การเขียนซอฟต์แวร์โดยอาศัยความเข้าใจอย่างคร่าวๆ การส่งสัญญาณที่หลวมๆ และความรู้สึกทั่วไปว่า “ควรทำงาน” มากกว่าการเข้าใจระบบหรือรูปแบบการออกแบบอย่างลึกซึ้ง

อย่างไม่น่าดี API ที่สร้างขึ้นในลักษณะนี้มักจะไม่สอดคล้องกับมาตรฐานที่กำหนดไว้ขาดการตรวจสอบที่มั่นคง และมักจะละเลยมาตรฐานภายในที่กำหนดไว้แล้ว นอกจากนี้ยังสามารถนำไปสู่ความเสี่ยงด้านความปลอดภัยหรือการปฏิบัติตามกฎระเบียบที่ร้ายแรง โดยเฉพาะอย่างยิ่งเมื่อเชื่อมต่อกับข้อมูลที่มีความละเอียดอ่อนหรือจุดสิ้นสุดภายนอก AI ไม่ทราบถึงแบบจำลองการกำกับดูแลหรือความต้องการการปฏิบัติตามกฎระเบียบของคุณ ถ้าไม่ได้รับคำสั่งโดยชัดเจน มันจะไม่เขียนโค้ดโดยคำนึงถึงสิ่งเหล่านั้น

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

Patchwork APIs และวิกฤตการเป็นเจ้าของ

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

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

ขั้นตอนปฏิบัติที่เป็นไปได้

1. ความชัดเจน

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

ขั้นตอนพื้นฐานแรกคือความชัดเจน คุณไม่สามารถควบคุมสิ่งที่คุณไม่เห็น องค์กรต่างๆ ต้องการการค้นพบ API อย่างต่อเนื่อง ไม่ใช่เอกสารที่ไม่เปลี่ยนแปลงที่ล้าสมัยทันทีที่เผยแพร่

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

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

2. การตั้งค่าการมาตรฐานขององค์กรในการเขียนโค้ดและเครื่องมือ

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

สิ่งที่มีพลังมากกว่านั้นคือการกำหนด rules.md ประเภทไฟล์ที่คุณกำหนดให้ AI-coders ให้ข้อมูลบริบทแก่ตัวแทน AI เพื่อสร้างโค้ดที่ทำงานได้ดีที่สุดกับโครงสร้างที่มีอยู่แล้ว ยิ่งฐานโค้ดที่ซับซ้อนมากเท่าไหร่ ก็ยิ่งจำเป็นที่วิศวกรทุกคนจะต้องทำงานด้วยชุดกฎที่เหมือนกัน โดยให้ข้อมูลบริบทแก่ AI Agent ว่าจะสร้างโค้ดที่เหมาะสมที่สุด

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