ระบุทักษะที่มีมูลค่าเพิ่มขึ้นเมื่อการสร้างโค้ดกลายเป็นเรื่องปกติ และเตรียมตัวคุณเองให้บ่มเพาะมันอย่างจงใจ
เปิดบทเรียนนี้ใน Kodokonเมื่อความสามารถหนึ่งกลายเป็นเรื่องปกติ มูลค่าตลาดของมันจะลดลงและเลื่อนไปสู่สิ่งที่อยู่รอบๆ มัน การแปลเป็นลายลักษณ์อักษรผ่านสิ่งนี้มาแล้ว การถ่ายภาพก็เช่นกัน สำหรับการพัฒนา ความสามารถที่กลายเป็นสินค้าโภคภัณฑ์นั้นชัดเจน: การผลิตโค้ดที่ถูกต้องจากข้อกำหนดที่แม่นยำ สิ่งที่มีมูลค่าเพิ่มขึ้นโดยกลไกคือปลายทั้งสองของห่วงโซ่ที่ AI ไม่ได้ครอบคลุม ต้นทาง: การกำหนดข้อกำหนด - การเปลี่ยนความต้องการที่คลุมเครือ ขัดแย้ง และมีเรื่องการเมือง ให้เป็นปัญหาที่ตั้งไว้อย่างดี มันคือทักษะที่ผู้ใช้ผู้ช่วยทุกคนค้นพบใหม่ด้วยความยากลำบาก เพราะพรอมต์ก็เป็นเพียงข้อกำหนดที่คุณต้องจ่ายราคาให้กับทุกความไม่แม่นยำ ปลายทาง: การตรวจสอบยืนยัน - การตรวจทาน การทดสอบ การตรวจสอบความปลอดภัย ความสามารถที่จะพูดว่า "โค้ดที่ดูสมเหตุสมผลนี้ผิด" มันกลายเป็นสิ่งสำคัญยิ่ง เพราะปริมาณโค้ดที่ดูสมเหตุสมผลระเบิดขึ้น และเหนือทั้งสองอย่าง: สถาปัตยกรรม การตัดสินใจเชิงโครงสร้างที่วัดผลกระทบเป็นปี และที่โมเดล - ซึ่งไม่มีความทรงจำเกี่ยวกับองค์กรของคุณและไม่มีความรับผิดชอบต่อคำแนะนำของมัน - ไม่สามารถแบกรับได้
อันตรายสำหรับผู้อาวุโสไม่ใช่การถูกแทนที่ แต่คือ การฝ่อลงที่ตรวจไม่พบ ทักษะเชิงลึกเสื่อมลงอย่างไม่เจ็บปวด: ไม่มีอะไรส่งสัญญาณว่าความสามารถของคุณในการดีบั๊กโดยไม่มีตัวช่วยหรือการออกแบบ API จากศูนย์ได้เสื่อมลงไปแล้ว จนกระทั่งวันที่มันถูกต้องการ คำตอบคือการตรวจสอบที่จงใจและสม่ำเสมอถึงสิ่งที่คุณฝึกฝนจริงๆ - ตรงข้ามกับสิ่งที่คุณคิดว่าคุณฝึกฝน มันคือการใช้ AI ที่ขัดกับความรู้สึกอย่างน่ายินดี: การใช้โมเดลเพื่อวัดสิ่งที่โมเดลทำให้คุณสูญเสีย
คุณคือโค้ชอาชีพด้านเทคนิคของฉัน ตรงไปตรงมาและไม่ยกยอ นี่คือบันทึกที่ซื่อสัตย์ของสัปดาห์การทำงานของฉันด้วยความช่วยเหลือจาก AI:
- งานที่ฉันสร้างผลงานเอง (AI เป็นผู้ตรวจทาน): [รายการ]
- งานที่มอบหมายให้ AI ทั้งหมด: [รายการ]
- โค้ดที่ยอมรับโดยไม่สามารถอธิบายมันอย่างละเอียดได้: [รายการ แม้จะรู้สึกอึดอัดก็ตาม]
- การตัดสินใจทางเทคนิคที่ทำในสัปดาห์นี้: [รายการ]
การวิเคราะห์สามส่วน:
1. ทักษะที่ฝึกฝนจริงในสัปดาห์นี้ (ที่กำลังเพิ่มขึ้น) เทียบกับทักษะที่มอบหมายออกไป (ที่เสี่ยงต่อการฝ่อ)
2. หนี้ความเข้าใจของฉัน: แต่ละรายการในรายการที่สาม พร้อมความเสี่ยงที่เป็นรูปธรรมที่เกี่ยวข้อง
3. แบบฝึกหัด 30 นาทีหนึ่งอันสำหรับสัปดาห์หน้า เล็งไปที่ทักษะที่เปราะบางที่สุดของฉัน โดยทำโดยไม่มีตัวช่วยใดๆ
รูปแบบ: การประเมินไม่เกิน 10 บรรทัด ฉันชอบคำวิจารณ์ที่เป็นธรรมมากกว่ากำลังใจที่คลุมเครือการรักษาความคิดเชิงวิพากษ์ก็เป็นทักษะที่ต้องฝึกเช่นกัน จุดยืนที่ถูกต้องเรียกว่า ความไว้วางใจที่ปรับเทียบแล้ว: ไม่ใช่ความไม่ไว้วางใจอย่างเป็นระบบที่ทำลายผลกำไรด้านผลิตภาพ และไม่ใช่ความไว้วางใจแบบตาบอดที่ติดตั้งความชะล่าใจ การปรับเทียบหมายถึงการปรับความเข้มข้นของการตรวจสอบให้เข้ากับตัวแปรสองอย่าง: ต้นทุนของข้อผิดพลาด (regex ในสคริปต์ใช้แล้วทิ้งกับนโยบายการอนุญาตไม่สมควรได้รับการตรวจสอบเท่ากัน) และ อัตราข้อผิดพลาดที่สังเกตได้ ของโมเดลในงานประเภทนั้น - ซึ่งคุณจะรู้ก็ต่อเมื่อตรวจสอบจริงๆ ในตอนแรก ทุกอย่างที่มันผลิตในสาขาของคุณ จงนับจำนวนนี้เป็นเวลาสองสามสัปดาห์: คุณจะรู้ว่าโมเดลเก่งตรงไหน มันหลอนตรงไหน และความระมัดระวังของคุณจะลงตรงจุดที่มันให้ผลตอบแทนพอดี
ตั้งแต่นี้เป็นต้นไปและตลอดทั้งบทสนทนานี้ จงรับบทบาทเป็นพี่เลี้ยงมากกว่าผู้ปฏิบัติงาน กฎถาวร:
1. เมื่อฉันขอโค้ดจากคุณ จงเริ่มด้วยการขอให้ฉันเสนอแนวทางของฉัน แล้วค่อยนำเสนอแนวทางของคุณหลังจากนั้น โดยเปรียบเทียบกับของฉันอย่างชัดเจน
2. เมื่อคุณแก้ไขฉัน จงระบุหลักการทั่วไปที่อยู่เบื้องหลังการแก้ไข ไม่ใช่แค่การแก้เฉพาะจุด
3. หนึ่งครั้งต่อคำตอบ จงถามคำถามที่ตรวจสอบว่าฉันเข้าใจ และรอคำตอบของฉันก่อนดำเนินการต่อ
4. หากฉันแค่ขอให้คุณ "ทำให้ฉันที" จงเตือนฉันถึงคำสั่งนี้และเสนอเวอร์ชันแบบมีคนนำทาง
ยืนยันว่าคุณเข้าใจโดยการกล่าวกฎเหล่านี้ใหม่ในประโยคเดียวในที่สุด ความสามารถในการจ้างงานสรุปลงเป็นคำถามที่ผู้สรรหาบุคลากรทุกคนในปีต่อๆ ไปจะถาม: คุณนำอะไรมาที่โมเดลไม่มี? คำตอบที่ป้องกันได้สรุปได้ในสามคำที่เห็นตลอดเส้นทางนี้: กำหนดข้อกำหนด ตรวจสอบยืนยัน ตัดสินใจ - บวกกับวิธีการหนึ่ง: เรียนรู้อย่างลึกซึ้งต่อไป โดยมี AI เป็นติวเตอร์ที่เข้มงวดมากกว่าเป็นเครื่องจ่ายโซลูชัน นักพัฒนาที่เข้าใจสิ่งที่พวกเขาปรับใช้ยังคงหายาก และดังนั้นจึงแพง นั่นคือแก่นเรื่องของบทเรียนแรก และมันก็เป็นบทสรุปของเส้นทางนี้ด้วย