ศักยภาพของนักพัฒนาอาวุโสในยุค AI: ใช้ประสบการณ์เพื่อสร้างผลลัพธ์ที่ดีกว่า

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

สถานะการใช้งานเครื่องมือเขียนโค้ดด้วย AI ในปัจจุบัน

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

จุดแข็งของนักพัฒนาอาวุโส

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

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

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

องค์ประกอบสำคัญ 3 ประการสำหรับ AI coding session ที่ประสบความสำเร็จ

• หากต้องการได้ผลลัพธ์ที่ดีจากการทำงานร่วมกับ AI องค์ประกอบ 3 ประการ ต่อไปนี้มีความสำคัญ:
  • การจัดทำเอกสารความต้องการอย่างเป็นระบบ (Well-structured Requirements)
  • Guard rail ด้านคุณภาพที่อิงกับเครื่องมือ (Tool-based Guard Rails)
  • เทคนิคคีย์เฟรมแบบอิงไฟล์ (File-based Keyframing)
• ก่อนเข้าสู่คำอธิบายแบบจริงจัง ผู้เขียนแนะนำกรณีศึกษาจากโปรเจกต์จริงที่ใช้ AI ดังนี้
  • โปรเจกต์ Green-field: โปรเจกต์ที่สร้างใหม่ทั้งหมดตั้งแต่ต้น
  • โปรเจกต์ Brown-field: โปรเจกต์ที่เพิ่มฟีเจอร์ใหม่บนโค้ดเบสเดิม
• ทั้งสองกรณีนี้จะเน้นไปที่ตัวอย่างที่ AI รับผิดชอบการ implement แทบทั้งหมด
  • ไม่ใช่ AI ในฐานะตัวช่วย autocomplete หรือผู้ช่วยแบบโต้ตอบธรรมดา
    แต่โฟกัสไปที่รูปแบบการทำงานจริงในโหมด agent
• เครื่องมือที่ใช้คือ Cursor
  • ทำงานบนโมเดล Claude Sonnet 3.7 ของ Anthropic
  • มีความสามารถในการแก้ไขไฟล์ทั้งโปรเจกต์โดยตรง และรันคำสั่งที่เกี่ยวข้องได้

ตัวอย่างที่ 1: Platform Problem Monitoring (โปรเจกต์ Green-field)

• ผู้เขียนใช้ Cursor และ Claude ในการพัฒนา แอปพลิเคชันใหม่ ชื่อ Platform Problem Monitoring
  • ซอร์สโค้ด: ลิงก์ GitHub
• แอปนี้จะเชื่อมต่อกับเซิร์ฟเวอร์ Elasticsearch ของ ELK ทุกชั่วโมงเพื่อรวบรวมข้อความ error
  แล้วส่ง รายงานอีเมลแบบมีโครงสร้าง ที่สรุปสถานะปัญหาปัจจุบันของเว็บแพลตฟอร์ม
• การ implement ทั้งหมดดำเนินการโดย AI และ ไม่มีโค้ดที่ผู้เขียนเขียนเองโดยตรง
• แม้ผู้เขียนจะไม่คุ้นเคยกับภาษา Python มากนัก
  • แต่ด้วย ความเข้าใจอย่างกว้างขวางด้านสถาปัตยกรรม การปฏิบัติการ และ best practices จึงทำให้เดินหน้าโปรเจกต์ได้อย่างราบรื่น
  • โปรเจกต์นี้ยังเป็นโอกาสในการ ทดลองว่า AI สามารถช่วยได้มากแค่ไหนเมื่อทำงานกับ tech stack ที่ไม่คุ้นเคย

หมายเหตุ: ประเด็นคุณภาพของโค้ด
ในการพูดคุยบน HackerNews มีการชี้ให้เห็นปัญหาคุณภาพโค้ด เช่น การตั้งค่า logging, การ parse การตั้งค่าแบบกำหนดเอง, race condition เป็นต้น
โปรเจกต์นี้มีเป้าหมายเพื่อสร้างต้นแบบอย่างรวดเร็วมากกว่าจะเป็น production code
และเน้นที่ การทำให้ฟังก์ชันทำงานได้ มากกว่าการบำรุงรักษาระยะยาวหรือธรรมเนียมของภาษา

ตัวอย่างที่ 2: Process Management UI Integration (โปรเจกต์ Brown-field)

• กรณีศึกษาการผสาน UI เข้ากับฟีเจอร์ backend แบบ legacy ที่พัฒนาด้วย PHP/Symfony
• backend ทำงานผ่านคำสั่ง CLI ที่อิง cron และเดิมทีไม่มี UI
• เป้าหมายคือการนำฟีเจอร์นี้ไปผสานเข้ากับแอปพลิเคชัน Symfony รุ่นใหม่
  • โดยใช้ประโยชน์จาก โครงสร้างที่เป็นมิตรต่อ UI ซึ่งมีทั้งโค้ดเบสสมัยใหม่ ระบบทดสอบ และ style guide อยู่แล้ว
• งานหลักประกอบด้วย:
  • การสื่อสารกับระบบ legacy ผ่าน HTTP API
  • การ implement การส่งข้อมูลระหว่างระบบ
  • การจัดวางหน้าจอให้สอดคล้องกับ UI design system
  • การ implement API client ภายใน shared Symfony bundle
• ยกเว้น ไฟล์คีย์เฟรม แล้ว การ implement ทั้งหมด ดำเนินการโดย AI อัตโนมัติ

อินไซต์สำคัญที่ได้จากทั้งสองโปรเจกต์

1. โปรเจกต์ Green-field: แม้จะเป็น tech stack ที่ไม่คุ้นเคย ก็ยังสร้างแอปที่ใช้งานได้จริงด้วยความช่วยเหลือจาก AI
2. โปรเจกต์ Brown-field: แม้งาน UI จะไม่ใช่งานที่คุ้นเคย แต่ก็ ทำฟีเจอร์เสร็จได้อย่างรวดเร็วด้วย AI

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

ความสำคัญของการเขียน requirement อย่างประณีต

• หัวใจของ AI coding session ที่ประสบความสำเร็จคือ เอกสาร requirement ที่เป็นระบบและครอบคลุม
• ในโปรเจกต์จริงอย่าง Platform Problem Monitoring ผู้เขียนได้เขียนเอกสาร REQUIREMENTS.md ก่อนเริ่ม session
• เอกสารดังกล่าวมีทั้งหมด 371 บรรทัด และมีโครงสร้างแบบลำดับชั้นดังนี้
  • ระดับบนสุด: สรุป requirement หลักในหนึ่งบรรทัด
  • ระดับสูง: use case และแรงจูงใจในการพัฒนา
  • ระดับกลาง: กระบวนการและวิธีการทำงาน
  • ระดับกลาง: สถาปัตยกรรม, tech stack, และข้อจำกัด
  • ระดับล่าง: เรียบเรียงขั้นตอนงานอย่างละเอียดตามเกณฑ์ input/output/side effects
• เอกสารที่จัดโครงสร้างเช่นนี้ช่วยให้ AI มี framework ที่ชัดเจน และนำไปสู่ผลลัพธ์ที่แม่นยำ
• แม้การเขียนเอกสารจะใช้เวลาและแรง แต่ก็เป็น การลงทุนที่จำเป็นสำหรับการ implement ที่ประสบความสำเร็จ
• มีคำกล่าวในวงการพัฒนาซอฟต์แวร์ว่า:

  “การ implement 6 สัปดาห์ ช่วยประหยัดเวลาวางแผน 2 ชั่วโมง”

  • แม้จะเป็นการพูดเชิงเสียดสี แต่ก็สะท้อนความจริงว่าความไร้ประสิทธิภาพในขั้น implement มักมาจากการวางแผนที่ไม่เพียงพอ
• ด้วยเหตุนี้ โปรเจกต์จึงควร เริ่มต้นที่ไวต์บอร์ด ไม่ใช่คีย์บอร์ด และหลักการนี้ก็ใช้ได้เหมือนกันเมื่อทำงานร่วมกับ AI
• ในทางปฏิบัติ ผู้เขียนเริ่ม Cursor session ด้วยขั้นตอนดังนี้:
  1. ให้ AI สรุป requirement ด้วยตัวเอง
  2. ให้สร้างแผนการดำเนินงาน
  3. กระตุ้นให้ตั้งคำถามในส่วนที่ยังไม่ชัดเจน
• หลังผ่านขั้นตอนตรวจสอบนี้แล้ว จึงค่อยสลับ AI ไปเป็นโหมด “Agent” เพื่อเริ่ม implement

การตั้งค่า guard rail ด้านคุณภาพด้วยเครื่องมือ

• หากเอกสาร requirement กำหนด จุดหมายปลายทาง guard rail ด้านคุณภาพก็ทำหน้าที่ รักษาเส้นทางที่สั้นที่สุดไปยังจุดหมายนั้น
• เช่นเดียวกับความสำคัญของระบบ feedback แบบเรียลไทม์ระหว่างการพัฒนา เครื่องมือ static analysis ก็มีประโยชน์อย่างมากกับ AI เช่นกัน
• ตัวอย่างเช่น การตรวจพบการขาด null check ระหว่างพัฒนาย่อมมีประสิทธิภาพกว่าการไปพบจากคำถามของลูกค้าหลังเปิดใช้งานจริงมาก
• ดังนั้น ก่อนเริ่ม AI coding session ผู้เขียนจะต้องตั้งค่า เครื่องมือประกันคุณภาพ ต่อไปนี้เสมอ
  • อิงจากตัวอย่าง Makefile:
    • black, isort: จัดรูปแบบโค้ด
    • ruff: linting
    • mypy: ตรวจสอบชนิดข้อมูล
    • bandit: วิเคราะห์ด้านความปลอดภัย
    • ชุดการทดสอบทั้งหมด
• AI agent ที่อิงกับ Claude สามารถรับรู้และใช้เครื่องมือเหล่านี้ได้
  • ตัวอย่าง: หากไม่ผ่านการตรวจชนิดข้อมูล AI จะปรับแก้โค้ดด้วยตัวเองจนผ่าน
• เพื่อการตรวจสอบเชิงฟังก์ชัน ผู้เขียนยังให้ คำสั่ง curl สำหรับทดสอบ API request ด้วย
  • การที่ AI เรียก endpoint เอง ตรวจดู response และปรับปรุงโค้ดต่อเป็นสิ่งที่น่าประทับใจมาก
• guard rail ที่อิงกับเครื่องมือเช่นนี้จึงเป็น องค์ประกอบจำเป็นที่ช่วยให้ AI สร้างผลลัพธ์ที่เชื่อถือได้

เทคนิคคีย์เฟรมแบบอิงไฟล์

• AI อาจเก่งในด้านการ implement แบบสร้างสรรค์ แต่ยังขาดทิศทางเรื่องโครงสร้างโค้ดหรือการจัดไฟล์
  • กลยุทธ์ที่ใช้เพื่อชดเชยจุดนี้คือ file-based keyframing
• เทคนิคนี้ได้แรงบันดาลใจจากวิธีทำคีย์เฟรมในงานแอนิเมชัน:
  • แอนิเมเตอร์ฝีมือดีจะสร้าง ฉากสำคัญ (keyframe) ก่อน แล้วให้ผู้ช่วยเติมส่วนที่เหลือ
  • วิธีนี้ช่วยเพิ่มประสิทธิภาพการทำงานโดยยังคงคุณภาพไว้ได้
• ในโปรเจกต์ AI coding จริง ผู้เขียนจะสร้าง ไฟล์เปล่าแบบ stub ไว้ล่วงหน้าก่อน implement
  • เช่น API endpoint, API client, controller class, Twig template เป็นต้น
• ไฟล์คีย์เฟรมเหล่านี้ให้ ข้อมูลเชิงบริบทที่สำคัญ แก่ AI เช่น
  • วิธีจัดโครงสร้างไฟล์ของโปรเจกต์
  • โครงสร้าง namespace
  • กฎการตั้งชื่อ
  • รูปแบบโค้ดที่สอดคล้องกัน
• แทนที่จะอธิบายทุกโครงสร้างผ่าน prompt การใส่คำใบ้ไว้ในตัว codebase เองจะช่วยเพิ่มความแม่นยำในการอนุมานของ AI ได้
• แนวทางนี้ยังตอกย้ำหลักการเรื่อง “การตั้งชื่อ” ที่ยังสำคัญในยุค AI
  • เพราะ AI ทำงานบนพื้นฐานของภาษา ข้อความที่มีเจตนาและความหมายชัดเจน จึงนำไปสู่ผลลัพธ์ที่ดีกว่า

การประยุกต์ใช้แบบบูรณาการจากกรณีจริง: การทำ UI สำหรับแดชบอร์ดสัญญาสมาชิก

• ผู้เขียนนำเสนอกรณีจริงที่รวมหลักการสำคัญทั้งสามข้อเข้าด้วยกันในโปรเจกต์เดียว:
  • การจัดทำเอกสาร requirement อย่างประณีต
  • guard rail ด้านคุณภาพที่อิงกับเครื่องมือ
  • เทคนิคคีย์เฟรมแบบอิงไฟล์

• ภาพรวมโปรเจกต์

  • เป้าหมาย: implement เว็บ UI dashboard แบบอ่านอย่างเดียว เพื่อ แสดงข้อมูลสัญญาสมาชิกในรูปแบบตาราง ภายในแพลตฟอร์ม
  • ขอบเขต: สภาพแวดล้อมแบบหลาย codebase (monorepo)
    • backend-app: แอปพลิเคชัน Symfony 5 ที่เก็บข้อมูล
    • janus-christophorus: แอปพลิเคชัน Symfony 7 ที่ให้บริการ UI
    • janus-shared-bundle: มีการ implement API client
    • janus-webui-bundle: มี style guide, การตั้งค่า Tailwind และ Twig template

• โครงสร้าง requirement

  • อ่านข้อมูล backend ผ่าน API แล้วแสดงบน frontend UI
  • นอกจาก API endpoint จริง ยังต้อง รองรับ demo mode (ให้ข้อมูลจำลองสำหรับการทดสอบ)
  • UI ต้อง implement ให้สอดคล้องกับ style guide
  • แต่ละเลเยอร์ประกอบด้วยองค์ประกอบต่อไปนี้:
    • API endpoint
    • API client
    • service class ใน presentation layer
    • controller และ Twig template

• งานเตรียมล่วงหน้าสำหรับ AI session

  • สร้างไฟล์เปล่าล่วงหน้าในทุก codebase ด้วยแนวทาง file-based keyframing
  • ให้ style guide, navigation service และฟังก์ชันที่คล้ายกันที่มีอยู่แล้ว เป็นข้อมูลอ้างอิงสำหรับ AI
  • ทำให้สามารถรัน เครื่องมือด้านคุณภาพ (เช่น PHPStan) ได้ในแต่ละ codebase
    • ตัวอย่าง: ใช้สคริปต์ .dxcli/dxcli.sh quality

• วิธีใช้หลักการแบบบูรณาการ

  • จัดระเบียบ requirement: อธิบายรายละเอียดความต้องการและโครงสร้างระบบใน prompt
  • ให้ guard rail: รวมคำแนะนำในการใช้เครื่องมือตรวจสอบโค้ด
  • ให้ keyframe: สร้างไฟล์เป้าหมายไว้ล่วงหน้าเพื่อให้ AI เขียนโค้ดลงในตำแหน่งและบริบทที่ถูกต้อง

• เป้าหมายหลัก

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

บทสรุป: เครื่องมือ AI + ประสบการณ์ของมนุษย์ = การผสมผสานที่ดีที่สุด

• ด้วยการมี requirement ที่ประณีต, guard rail ที่อิงกับเครื่องมือ, และ file-based keyframe
  เราสามารถใช้ประโยชน์จากความสามารถอันทรงพลังของ AI ไปพร้อมกับรักษาคุณภาพโค้ดและความสม่ำเสมอของสถาปัตยกรรมได้
• แนวปฏิบัติการพัฒนาแบบดั้งเดิมเหล่านี้ยังคงใช้ได้ผลในยุค AI
  และยิ่ง แสดงประสิทธิภาพได้มากขึ้นผ่านประสบการณ์และวิสัยทัศน์ของนักพัฒนาอาวุโส
• ท้ายที่สุด AI ก็เป็นเพียงเครื่องมือ
  และนี่คือยุคที่ประสบการณ์และทักษะของมนุษย์ในการใช้มันอย่างถูกต้องมีความสำคัญมากกว่าที่เคย

[GN⁺]

ความคิดเห็นจาก Hacker News

• นักพัฒนา Python ที่มีประสบการณ์ชี้ว่าเมื่อรีวิวไฟล์หนึ่งแล้วพบว่าเต็มไปด้วยความผิดพลาดแบบวิศวกรซอฟต์แวร์ระดับเริ่มต้น

  • เริ่มตั้งแต่การตั้งค่า root logger ในระดับโมดูล ไปจนถึงการเขียนตัวแยกไฟล์คอนฟิกเองแทนที่จะใช้ตัวแยกของ standard library
  • ชี้ปัญหาของ load_json ที่ตรวจสอบการมีอยู่ของไฟล์ก่อน แต่หลังจากนั้นกลับทำงานต่อราวกับว่าไฟล์ต้องมีอยู่แน่นอน
  • กล่าวโดยรวมว่าคุณภาพของโค้ดต่ำ

• โปรแกรมเมอร์งานอดิเรกที่มีประสบการณ์ 25 ปีรู้สึกว่า LLM และ vibecoding บั่นทอนความคิดสร้างสรรค์

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

• นักพัฒนาที่ยังอายุไม่ถึง 40 รู้สึกว่า AI มีประโยชน์ในฐานะเครื่องมือช่วยแบ่งเบางาน

  • กำลังเผชิญอาการเอ็นอักเสบรุนแรง และพบว่าอาการดีขึ้นหลังใช้การเติมโค้ดอัตโนมัติ
  • กังวลว่า "vibe coding" อาจกลายเป็นกระแสหลัก และห่วงว่าจะมีเพียงนักพัฒนาที่มีประสบการณ์เท่านั้นที่เข้าใจบริบทได้

• ผู้ใช้ที่รู้สึกว่าการสร้างโค้ดด้วย AI ไม่มีประสิทธิภาพ

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

• รู้สึกว่า AI มีประโยชน์กับโปรเจกต์ใหม่ (greenfield) แต่ไม่มีประสิทธิภาพกับโปรเจกต์เดิม (brownfield)

  • ชี้ว่า AI มีปัญหาในการผสานรวมกับโค้ดเดิม

• นักพัฒนาที่วางแผนด้วยไฟล์ Markdown ตอนเริ่มโปรเจกต์

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

• ผู้ใช้ที่คิดว่าประสบการณ์ด้านวิศวกรรมซอฟต์แวร์ยังสำคัญในยุค AI

  • กังวลว่าการพึ่งพา LLM อาจทำให้ประสบการณ์ถดถอย

• ผู้ใช้ที่พยายามนำแนวคิดเรื่อง "ความประหลาดใจ" ของทฤษฎีสารสนเทศมาปรับใช้กับ LLM

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

• ผู้ใช้ที่พยายามใช้การพัฒนาแบบขับเคลื่อนด้วยการทดสอบ (TDD) เพื่อกำกับโค้ดที่ AI สร้าง

  • TDD ทำหน้าที่เหมือนสัญญา ทำให้เลือกได้ว่าจะใช้ AI หรือเขียนโค้ดเอง

• ผู้ใช้ที่กังวลว่าสภาพปัจจุบันของ AI ไม่สอดคล้องกับทิศทางอนาคตของซอฟต์แวร์

  • กล่าวว่าความสำเร็จของ Java มาจากซอร์สโค้ดที่ให้มาพร้อมกับ JDK
  • ชี้ว่า AI ไม่ได้ช่วยปรับปรุงความชัดเจนและความสามารถในการค้นพบของโค้ด

• ผู้ใช้ที่รู้สึกว่าการพัฒนาของ AI เร็วมากจนชวนให้ท่วมท้น

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