Core Skills ของ AI-Era Developer — Andrew & Nicole, Google I/O 2026

อีก session ที่ Google I/O 2026 ที่อยากเก็บมาเขียนสรุปไว้ — Build Core Skills to Thrive as an AI-Era Developer โดย Andrew และ Nicole ทั้งสองเป็น lead ที่ทีม Developer Intelligence ของ Google

มุมที่ session นี้ใช้ต่างจาก session อื่นที่พูดเรื่อง AI กับ engineering — แทนที่จะพูดเรื่อง tool หรือ infrastructure มันโฟกัสที่ skill กับ pattern ของคนเองว่าต้องเปลี่ยนอะไรเพื่อโตในยุคที่ AI generate code ได้เร็วระดับนี้

โพสต์นี้สรุปประเด็นที่อยากเก็บไว้

Setting the Scene — Stats ที่ปูประเด็น

ก่อนเข้าเนื้อหา Andrew วาง stats สามตัวให้เห็นภาพ:

• 90% ของ technology professional ใช้ AI ที่งาน
• 40% บอกว่าพึ่ง AI มาก
• 75% ของ code ที่ Google เขียนโดย AI

ระดับ adoption ไม่ใช่คำถามอีกแล้ว คำถามถัดไปคือ — แล้วคนที่ทำงานกับ AI ได้ดีที่สุดทำอะไรต่างจากคนทั่วไป?

The Productivity Paradox — เร็วขึ้นเฉพาะตัว ช้าลงระดับทีม

DORA (DevOps Research and Assessment) ของ Google เจอ pattern ที่น่ากังวล:

• AI adoption +25%
• Individual productivity +2.1%
• Team software delivery throughput -1.5%

แต่ละคนเร็วขึ้น ทีมรวมช้าลง

ที่น่าสนใจมากกว่านั้นคือพฤติกรรมของ engineer ที่ได้ benefit จาก AI สูงสุดในทีม — counterintuitively พวกเขา ไม่ได้ทำงานน้อยลง พวกเขาใช้เวลา code มากขึ้น ideate มากขึ้น และ collaborate มากขึ้น delegate execution ให้ AI แต่ active ใน steering ตลอด

Andrew วาง frame ที่ใช้ตลอด session — software engineering ไม่ได้ติดคอขวดที่จำนวน line of code มาตั้งแต่แรก การ transform เกิดเมื่อองค์กรเลิกใช้ AI optimize task เดิม ๆ แล้วยกระดับ SDLC ทั้งกระบวนการ

5 Emerging Patterns ของ High-Performing AI-Native Engineers

ทีม Developer Intelligence track cycle time end-to-end (seed idea ไป production) ของ top engineer แล้วเจอ pattern 5 อันที่ซ้ำกัน

1. Shift up: Higher altitudes — top developer ผสม technical depth กับ business context และ user empathy ที่ลึก focus ที่ why ของ feature มากกว่า what หรือ how

2. Shifting left: Structured intent — ก่อนหน้านี้ shift left หมายถึงเลื่อน security หรือ testing ไปต้น pipeline ในปี 2026 หมายถึงเลื่อน intent ไปต้นกระบวนการสุดเลย source of truth ย้ายจาก raw code ไปอยู่ที่ upfront structured intent file และ spec file

3. System design: The environment — Elite engineer ไม่นั่งพิมพ์ loose prompt ทีละ block พวกเขาสร้าง system of reasoning — กำหนด boundary, guardrail, environment rule เพื่อให้คนและหลาย agent ทำงานไปหา goal ได้อย่างปลอดภัย Andrew ใช้คำว่า Verified output > Faster code

4. System design: The workforce — AI decouple job role ออกจาก executable task ทีมรวมตัวเป็น cross-functional micro-team (pod) ที่ communication overhead น้อย แต่ละ pod orchestrate fleet ของ agent ที่ทำให้ feature velocity สูงระดับ massive Andrew สรุปว่า Capability > Job title

5. System design: New values — ความเร็วของ evolution ต้องการความสัมพันธ์ที่เปิดกับ failure top engineer experiment ทุกสัปดาห์ บันทึก failure และ success ของตัวเองกลับเข้า shared knowledge ของทีมตลอดเวลา Intelligent failure > The status quo

T-Shaped Developer แบบใหม่

Model T-shaped แบบเดิม — depth ในแนวตั้ง breadth ในแนวนอน — ถูก evolve ใหม่ในยุค AI

• GenAI usage (top bar) — layer ที่บังคับ ความสามารถในการเข้าใจ AI constraint, assess output quality, และ steer model ตาม task context
• Left wing - Adjacent engineering — cybersecurity, privacy regulation, experimentation infrastructure, cloud deployment pipeline ถ้าไม่มี breadth ฝั่งนี้ AI แค่สร้างของผิดให้เร็วขึ้น
• Right wing - Adjacent non-engineering — business metrics, product strategy, user context AI ดูแลเรื่อง how ของ code engineer ต้องคุมเรื่อง what และ why

Case study ที่ Andrew เล่าจาก Google Search org — ปัจจุบัน Product Manager ส่ง feature เข้า live production experiment ได้โดยไม่ต้องเขียน code แบบเดิม PM ทำงานผ่าน internal platform ที่ engineer สร้างไว้ Engineer ไม่ได้หยุดเขียน programming — พวกเขายกระดับ abstraction layer ไป precision engineer ecosystem ข้างใต้ ให้ feature autogenerate ออกมาได้อย่างปลอดภัย

Verification คือคอขวดใหม่ — Delegate Tasks, Not Judgment

เพราะ code generation เกิดที่ความเร็วแสง human cognitive limit ทำให้ validate ทีละบรรทัดไม่ไหวแล้ว Engineer ต้องสร้าง continuous automated feedback loop เพื่อ isolate และจับ regression ใน low-stakes environment

Nicole ย้ำหลักว่า — Delegate tasks, not judgment Model ฟังดูมั่นใจมาก แต่มี style drift และ structural hallucination เกิดได้ตลอด engineer ต้องบังคับ style-guide convention ลงบน agent ความ taste, architectural guardrail และ judgment ของมนุษย์ยังเป็นตัวกำหนดทิศทางของระบบ

วิธีรักษา deep technical edge ที่ Andrew แนะนำ:

• Reimplementation as learning tool — ไม่รับ first draft ของ agent บังคับให้ AI ทำลายของเดิมและเขียนใหม่ด้วย pattern อื่น พร้อม document architectural logic และ trade-off
• Walkthrough ของ alien code trace — ทีมต้องมี whiteboarding session อธิบาย alien code คือ distributed system และ agent decision trace ที่ไม่มีใครในทีมเขียนเองด้วยมือ เพื่อรักษา shared mental model ของระบบ
• Structured agent role profile — ไม่ใช้ chatbot สำเร็จรูป team ที่ทำได้ดีสุดสร้าง, maintain, version-control rule/skill file ของ agent เอง พร้อม playbook, behavioral constraint, และ recipe ที่ unique กับ product (เช่น YouTube-specific style playbook)

Practical Tips สำหรับ Agent Orchestration

Developer ต้องย้ายจากการเป็น conductor ของ prompt window เดียวไปเป็น orchestrator ของ multi-agent system แบบ asynchronous

Google ใช้ tiered risk environment เพื่อ contain blast radius — feature ย้ายจาก autogenerated prototype ไปสู่ production แบบ incremental ทดสอบ performance data ใน insulated environment ก่อนเข้าระบบ production

ด้าน code review Google deploy agent หลายตัวประกบกัน — Shepherding agent ไกด์ pull request ผ่าน CI/CD smooth ๆ, Code review agent check security, performance, maintainability, style หลายรอบ, Risk assessor agent scan in-flight change เพื่อ flag block ที่ซับซ้อนและเสี่ยงสูงสำหรับ manual human review เก็บ human focus ไว้กับ task ที่มี cognitive value สูง

Tip ที่ Andrew ย้ำสำหรับ orchestrator:

• Upskill on eval architecture — develop realistic, grounded, automated evaluation framework เป็น developer skill หลักที่จะ unblock verification bottleneck
• Mandate agent journaling — บังคับ agent maintain reflection journal ว่ามันติดที่ขั้นไหน, tool ใช้ยากที่ตำแหน่งใด, instruction ทำให้สับสนที่ส่วนใด
• 3-to-5 Agent Balance — เพื่อกัน agent sprawl เก็บ multi-agent architecture ให้อยู่ใน bound Google share architecture ที่ใช้ได้ดีกับ TensorFlow → JAX migration: Planner agent gen sequential step, Orchestrator agent batch และ coordinate, Coder agent ทำ raw file modification

• Spec-driven development — vague prompt ให้ผลขยะ team ที่ทำได้ดีถือ product/architecture specification file เป็น engineering deliverable ที่ปกป้องสุดชีวิต debate constraint, edge case, business logic ใน spec file รัน review agent กับ spec ก่อน code generation เริ่ม

Identity Threat — Engineer คือ Value Translator

Andrew และ Nicole ใช้คำว่า identity threat — developer ที่ derive worth ของตัวเองจากการเขียน syntax กลายเป็นกลุ่มที่เผชิญ existential crisis worth ต้องย้ายไปอยู่ที่การเป็น Value Translator — แปลง raw user/business need ไปเป็น high-fidelity technical spec

Engineer ถูกเตือนเสียงดัง ๆ ว่าอย่า offload user feedback loop ทั้งหมดให้ LLM summary Top team ที่ Google ยังบังคับ traditional high-touch user feedback session ฟังลูกค้าด้วยตัวเองเพื่อสร้าง empathy ที่ใช้ steer agent optimization priority ได้แม่นยำ

Boundary ของแต่ละ discipline (PM, UX, Eng) เริ่มเบลอ Internal AI platform จัดการ execution safety ให้ ทำให้ PM และ UX designer fix layout bug หรือ ship live experiment component ได้เอง สร้าง product development ที่ลื่นไหลกว่าเดิมมาก

Leadership Directive — สำหรับ Manager และ Director

Nicole warn ไปที่ leadership ด้วยประโยคหนัก:

“You can’t mandate a T-shaped developer inside of a broken system.”

AI จะส่องกระจกกลับมาให้เห็น process ที่พัง, tooling ที่กระจัดกระจาย, และ data ที่ siloed

Directive 3 ข้อ:

• เลิก track flawed metrics — หยุดวัด engineering performance ด้วย PR throughput, commit frequency หรือ line of code accepted Metrics พวกนี้จูงใจให้ developer accept raw AI output โดยไม่ verify ใช้ business outcome ที่ทำได้และ system quality ที่ maintain ไว้เป็นรางวัลแทน
• Protect productive struggle — กั้นเวลาทำงานแบบไม่กดดันให้ developer ได้ step through architecture, experiment กับ agent config, สร้าง deep system mental model ไม่งั้นจะจมใน cognitive debt
• Foster radical psychological safety — agentic workflow จะพังตอน rollout แรก ๆ ถ้า culture ลงโทษ failure developer จะถอยกลับไปใช้ legacy slow non-AI method Celebrate intelligent failure และทำ blameless postmortem แบบเข้มงวด

ปิดท้าย

ที่เก็บกลับมาจาก session นี้

Quote ที่ติดที่สุดของ talk:

“Software engineering is not vanishing; it is stepping up to its most powerful level. Developers must stop thinking in bits of code and start thinking in systems design.”

ส่วนใหญ่ session เรื่อง AI กับ engineering มักโฟกัส tool หรือ workflow Andrew กับ Nicole เปลี่ยนมุมเป็น operating mode ของคน — ทำไมบางทีมเร่งได้ บางทีม throughput ลด ไม่ได้อยู่ที่ AI tool ที่ใช้ อยู่ที่ pattern ของคนที่ใช้มัน

ถ้าเก็บได้สามอย่าง:

1. Verification เป็น bottleneck ใหม่ — code generation ไม่ใช่ปัญหา การ assess และ steer agent คือ skill ที่ขาด
2. T-shape ขยายทั้งบนและล่าง — GenAI usage เป็น horizontal layer บังคับ, business/user context กลายเป็น wing ที่ขาดไม่ได้
3. Leadership pattern ต้องเปลี่ยน — metrics เก่า ๆ ทำให้ทีมเร่ง output โดยไม่ verify, system quality ตกได้ง่าย

คำว่า Value Translator น่าจะติดอยู่ในหัวไปอีกพักใหญ่

Original session: Build Core Skills to Thrive as an AI-Era Developer — Andrew & Nicole, Google I/O 2026