วิศวกรรมการบูรณาการที่เน้น AI เป็นหลักด้วย Claude Code: การทดสอบการแก้ไขข้อผิดพลาดในสถานการณ์จริง

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

ประเด็นไม่ได้อยู่ที่ว่า AI นั้นน่าประทับใจ แต่ประเด็นอยู่ที่ว่าการทำงานร่วมกันจริงๆ นั้นเป็นอย่างไร เมื่อคุณนั่งลงและลงมือทำงาน

การตั้งค่า

ผลิตภัณฑ์นี้คือหนึ่งในระบบเชื่อมต่อ CRMConnect ของเรา Mindbody ไปยัง HubSpotลูกค้ารายหนึ่งรายงานว่า การขายที่ชำระเงินด้วยวิธีการชำระเงินมากกว่าหนึ่งวิธีนั้นมีการซิงค์ข้อมูลผิดพลาด การขายมูลค่า 8,400 ดอลลาร์ที่แบ่งชำระด้วยสามวิธี แสดงใน HubSpot เป็นดีลเดียวมูลค่า 400 ดอลลาร์ ส่วนอีก 8,000 ดอลลาร์หายไปจากไปป์ไลน์

เราติดตามความคืบหน้างานด้านวิศวกรรมใน GitHub Issues ส่วนการสนทนากับลูกค้าจะอยู่ใน HubSpot Service Hub โดยเซสชันเริ่มต้นด้วยนักพัฒนาชี้ให้ AI ดูงานนั้น

ข้อความแจ้งเตือน: “ตรวจสอบประเด็นเรื่องการชำระเงิน”

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

ข้อความแจ้งเตือน: “ตรรกะนี้ทำอะไร และมีการทำงานอัตโนมัติ/การดำเนินการอะไรบ้าง?”

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

มีประโยชน์ แต่ผู้รับเหมาก่อสร้างมีข้อได้เปรียบมากกว่าอยู่แล้ว

คำใบ้ที่เปลี่ยนทิศทางทุกอย่าง

ข้อความแจ้งเตือน: “ลองเปรียบเทียบตัวระบุเฉพาะสำหรับข้อตกลงนี้กับวิธีการที่เราใช้กับโครงการ crmconnect-mindbody-zoho ดูสิ ผมคิดว่าเราแก้ปัญหาตรงนั้นได้แล้ว ลองเปรียบเทียบแบบเจาะจงดูอีกครั้ง”

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

และ AI ก็ทำเช่นนั้น มันเปิด... Mindbody ไปยัง Zoho โปรแกรม Integration ซึ่งเป็นผลิตภัณฑ์ที่แยกต่างหากโดยสิ้นเชิง ได้ค้นหาและอ่านข้อมูลการทำงานอัตโนมัติที่จัดการยอดขายในอดีต จากนั้นก็ค้นหาและอ่านซับรูทีนที่เขียนบันทึกการชำระเงิน ไม่ใช่ข้อมูลสรุป แต่เป็นตรรกะการทำงานอัตโนมัติที่แท้จริงทีละขั้นตอน

ผลลัพธ์ที่ได้คือการเปรียบเทียบที่เน้นเฉพาะจุด การผสานรวม Zoho ช่วยแก้ปัญหานี้ได้จริง แต่ด้วยโครงสร้างที่แตกต่างออกไป:

• ผลิตภัณฑ์ของ HubSpot สร้างดีลแบบคงที่หนึ่งดีลต่อรายการขาย โดยใช้เอนด์พอยต์การขายแบบเก่าของ Mindbody ซึ่งส่งคืนแถวการชำระเงินที่แบ่งไว้ล่วงหน้า
• ผลิตภัณฑ์ของ Zoho จะสร้างบันทึกการซื้อหลักหนึ่งรายการ พร้อมด้วยบันทึกย่อยแยกต่างหากสำหรับรายการสินค้าและสำหรับการชำระเงิน โดยใช้เอนด์พอยต์รุ่นใหม่ของ Mindbody ซึ่งการชำระเงินแต่ละรายการจะมีรหัสการชำระเงินจริงของตนเอง

ระบบ AI วิเคราะห์ว่า Zoho มีโครงสร้างที่เรียบง่ายกว่า และในเบื้องต้นได้เสนอให้ย้ายโมเดลสามส่วนทั้งหมดไปไว้ใน HubSpot

ผู้สร้างลดขอบเขตงานลง

นี่คือจุดที่มนุษย์คอยยึดเหนี่ยวสิ่งต่างๆ ให้คงอยู่

ข้อความแจ้งเตือน: “ยังไม่พร้อมสำหรับเวอร์ชัน 4.0 ในตอนนี้ เก็บไว้ก่อน ตอนนี้เราต้องแก้ไขปัญหาดีลที่หายไปซึ่งลูกค้าแจ้งมาก่อน”

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

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

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

ลางสังหรณ์

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

ช่างก่อสร้างไม่มีเอกสารอ้างอิงทางกฎหมายให้โต้แย้ง เขาแค่จำคำพูดตัวเองได้

ข้อความแจ้งเตือน: “ฉันจำได้ว่าฉันเพิ่มวันที่เข้าไปเพราะมันจำเป็น (เช่น การชำระเงิน 2 ครั้งในธุรกรรมเดียวกัน หรืออะไรทำนองนั้น)”

ทั้งสองฝ่ายไม่สามารถพิสูจน์ได้จากระบบอัตโนมัติในปัจจุบัน ดังนั้น AI จึงเข้าไปดูประวัติเวอร์ชันของระบบอัตโนมัติ ระบบอัตโนมัติมีเวอร์ชันที่บันทึกไว้เก้าสิบสามเวอร์ชัน ย้อนกลับไปถึงปี 2021 AI อ่านคำอธิบายการเปลี่ยนแปลงจนกระทั่งพบเวอร์ชันที่เกี่ยวข้อง

ตั้งแต่เดือนมกราคม 2022:

“เพิ่ม EPOCH MILLIS เพื่อบันทึกรหัสธุรกรรมลงในฐานข้อมูล เพื่อให้รหัสไม่ซ้ำกันเมื่อมีการชำระเงินหลายรายการสำหรับสินค้าชิ้นเดียวกัน”

ตั้งแต่เดือนกุมภาพันธ์ 2022:

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

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

ปัญญาประดิษฐ์ (AI) ตอบสนองโดยการเปลี่ยนคำแนะนำทันทีและระบุอย่างชัดเจนว่า:

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

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

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

ส่วนที่ไม่น่าดึงดูดใจ: สร้าง, รัน, อ่านข้อมูลการติดตาม, แก้ไข

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

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

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

สิ่งนี้หมายความว่าอย่างไรสำหรับผู้รับเหมาก่อสร้าง

หากตัดเรื่องราวออกไป นี่คือแบบจำลองที่ใช้งานได้จริง:

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

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

นั่นคือขั้นตอนการทำงานที่คุ้มค่าแก่การสร้างขึ้นมา