ความรู้ขั้นต่ำสำหรับการพัฒนาซอฟต์แวร์ด้วย AI

AI คือเครื่องมือ มันไม่ได้มาแทนที่ความรู้ด้านสถาปัตยกรรมและวิศวกรรมของคุณ

เลิกผลักภาระการตัดสินใจไปให้ AI คุณต้องกำหนดข้อกำหนดทั้งด้านฟังก์ชัน (functional requirements) และด้านที่ไม่ใช่ฟังก์ชัน (non-functional requirements) ให้ชัดเจน และระบุรายละเอียดในทุกแง่มุม

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

ใช้ AI agents บนเครื่องของคุณเอง (local machine) ตัวเชื่อมต่อ (harness) นั้นสำคัญมาก ใช้ Codex สำหรับ GPT และ Claude Code สำหรับ Opus ตัวเชื่อมต่อที่แย่จะให้ผลลัพธ์ที่แย่ แม้จะใช้โมเดลเดียวกันก็ตาม

แผนราคาถูกเหมาะสำหรับโปรเจกต์ระดับสมัครเล่น แต่โปรเจกต์ระดับมืออาชีพต้องการแผนที่สามารถเข้าถึงโมเดลที่ดีที่สุดและมีขีดจำกัดการใช้งาน (usage limits) ที่สูง

ทุกโปรเจกต์จำเป็นต้องมีไฟล์ CLAUDE.md หรือ AGENTS.md เขียนให้สั้นและตรงไปตรงมา เขียนเป็นภาษาอังกฤษ และใส่เฉพาะข้อมูลที่สำคัญต่อโปรเจกต์เท่านั้น

อย่าเพิ่งเขียนโค้ดทันที ให้ทำตามกระบวนการนี้:

  • วิเคราะห์ปัญหา
  • สร้างแผนงาน
  • ตรวจสอบแผนงาน
  • เขียนโค้ด

แผนของคุณต้องครอบคลุมถึงสถาปัตยกรรม, เกณฑ์การยอมรับ (acceptance criteria), การทดสอบ และวงจรการตอบกลับ (feedback loops)

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

พัฒนาการคิดเชิงวิพากษ์ (critical thinking) ของคุณ AI ช่วยให้การทำงานเร็วขึ้น แต่มันไม่ได้มาแทนที่การตัดสินใจหรือการตัดสินใจทางวิศวกรรม

เปลี่ยนบทบาทของคุณ เลิกเป็นแค่คนลงมือทำตามสั่ง (task implementer) แต่จงทำหน้าที่เป็นสถาปนิก (architect), หัวหน้าทีมเทคนิค (tech lead) และเจ้าของผลิตภัณฑ์ (product owner) และคิดถึงภาพรวมของทั้งระบบ

บริบท (context) คือทุกสิ่ง การใช้ prompt เพียงครั้งเดียวไม่เพียงพอ คุณต้องระบุทั้งกฎทางธุรกิจ (business rules), สถาปัตยกรรม (architecture), ข้อกำหนดมาตรฐาน (conventions) และข้อจำกัด (constraints)

ตรวจสอบความถูกต้องโดยอัตโนมัติเสมอ ทุกรอบการทำงานต้องจบลงด้วยการ build, การทดสอบ (tests), linter และการวิเคราะห์แบบ static analysis

อย่ารับโค้ดเพียงเพราะมันทำงานได้ แต่ต้องเรียกร้องความอ่านง่าย (readability), ความเรียบง่าย (simplicity), ความปลอดภัย (security) และความสามารถในการบำรุงรักษา (maintainability)

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

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

คุณคือผู้รับผิดชอบ คุณต้องรับผิดชอบต่อโค้ดทุกบรรทัดที่อยู่ในระบบ production อย่าโทษ AI หรือเครื่องมือ เพราะบริษัทคาดหวังผลลัพธ์จากตัวคุณ

Source: https://dev.to/andredarcie/o-minimo-que-voce-precisa-saber-para-desenvolver-software-com-ia-1dc9