Дядя Боб написал правила для ИИ-агентов: разбираем ub-mode
Автор «Чистого кода» Роберт Мартин aka Дядя Боб взялся за ИИ-агентов. В скилле ub-mode, который Дядя Боб на днях выложил на GitHub, всего около 750 слов. Этими словами Мартин выстраивает работу агента так, будто сам стоит рядом и смотрит на монитор строгим взглядом.
На днях Роберт Мартин aka Дядя Боб, автор «Чистого кода», выложил на GitHubub-mode — набор правил для ИИ-агентов. Весь скилл — один файл примерно на 750 слов: короткие ёмкие правила, написанные по тем же принципам «чистого кода». Теперь у каждого разработчика будет свой Дядя Боб: он встанет над ИИ-агентом с линейкой и проследит за гигиеной кода.
При разборе багов агент приносит правку и пишет «готово, шеф». По одному диффу не понять, так ли это: старые тесты могли остаться зелёными и при неверной логике, а новая проверка — просто спрятать сбой. Скилл ub-mode заставляет агента обосновать свою работу: сначала показать тест, который падает из-за бага, потом предъявить правку, после которой тест проходит.
В репозитории ub-mode нет кода: там только README.md и SKILL.md. Второй файл описывает порядок действий, а README отсылает к утилитам, которые меряют сложность кода, ищут дубли и проверяют, ловят ли тесты ошибки. Автор пишет, что частично использовал идеиpoteto-mode / pstack.
Правила разбиты на три части: First Make it Work, Then Make it Right и Practice.
Воспроизводимость ошибки
Мартин требует от агента начать с TDD: тест надо написать до изменения кода. Агент должен проверить, что тест падает по ожидаемой причине. Затем — минимальная правка, которая сделает тест зелёным. Никакого формализма быть не должно: если написать честный тест слишком сложно — не нужно писать фиктивный.
Архитектура: данные, ввод и повторный запуск
Дядя Боб требует от агента архитектурных решений. До того, как писать логику, агент должен продумать структуру данных и проверить всё, что приходит извне, прямо на входе в систему.
Код, который изменяет данные (например, пишет в базу или обращается к внешним сервисам), агент должен писать так, чтобы повторный запуск или перезапуск после сбоя на середине приводил к тому же результату, что и первый запуск.
Важен принцип «убери лишнее перед тем, как добавлять». Прежде чем писать новый код, агент должен упростить то, что уже есть: например, удалить ненужные ветки, обёртки и дубли. Новая функциональность ложится уже на расчищенную основу.
Первопричина вместо заплатки
В разделе Then Make it Right Мартин требует искать первопричину ошибки, а не маскировать симптом.
Это правило он сформулировал так: «Защитная проверка, которая только прячет падение, — это не исправление» ("A guard that only hides the crash is not a fix"). Например, проверка на null уберёт падение, но не ответит на вопрос, откуда в этом месте null и может ли он там быть по модели данных. Иногда guard и в самом деле нужен, но правило требует понять причину сбоя, а не считать защитную проверку достаточным исправлением.
По той же логике скилл запрещает агенту глушить ошибки компилятора: заглушённая ошибка прячет проблему, как и проверка на null.
Спрятать баг может и сам тест. Поэтому Мартин требует, чтобы тесты проверяли поведение так, как его видит пользователь кода. Если тест пройдёт даже тогда, когда каждая функция возвращает пустой результат, этот тест надо выбросить.
На тестах, которые проверяют поведение, держится и рефакторинг: сначала тесты фиксируют, что делает код, потом агент небольшими шагами меняет структуру и на каждом шаге проверяет, что поведение не изменилось.
Проверки качества: утилиты Crapper, Dryer и Mutator
Мартин не полагается на оценку кода, которую даст сам агент. Скилл ub-mode требует от агента прогонять код через три утилиты:
Crapper оценивает, насколько рискованно менять каждую функцию: чем функция сложнее и чем хуже покрыта тестами — тем выше балл.
Dryer ищет похожие фрагменты кода.
Mutator вносит в код мелкие ошибки и смотрит, увидят ли тесты проблему.
По итогам проверок агент должен разбить или покрыть тестами рискованные функции, убрать дубли, дописать тесты там, где ошибки прошли незамеченными, и удалить мёртвый код. Пороги Мартина (риск меньше 10 для каждой функции, дубли с похожестью от 0,8) — его личные требования, здесь каждый решает сам.
Журнал решений, worktree и коммиты
Последний блок скилла, Practice, описывает рабочую дисциплину. Агент должен фиксировать все свои действия и причины решений, беречь контекстное окно, делать небольшие коммиты и не удалять Git-worktree, если в нём есть незакоммиченные изменения. В сообщении коммита должны быть изложены причина, суть изменения и способ проверки.
Есть пункт, который командам придётся адаптировать: скилл требует в конце работы отправлять изменения в основную ветку. Это правило нельзя переносить без изменений, если в команде обязательны pull request, ревью и CI. Скилл задаёт предпочтения Мартина, а не универсальную политику.
Встраивать работу агентов в командный процесс учит программа Хекслета «AI SDLC»: от спецификации и ревью до CI/CD.
Как подключить ub-mode
В README описан простой способ: скопировать SKILL.md в каталог skills своего агента. Для Claude указан путь ~/.claude/skills/ub-mode/SKILL.md; в примерах есть Grok и Cursor. Затем вызовите скилл командой /ub-mode.
Для полноценной работы скилла нужно самостоятельно установить Crapper, Dryer и Mutator.
Для тестирования скилла можно взять небольшую задачу с понятным ожидаемым результатом. После выполнения работы нужно посмотреть, написал ли агент падающий тест до того, как изменить код, ограничился ли нужным диффом и какие проверки действительно выполнил. Одна удачная правка ничего не скажет об эффективности скилла.
Работу с агентами, контекстом и проверкой результата мы разбираем на курсе Хекслета «ИИ для разработчиков».
В README и SKILL.md нет результатов сравнительных испытаний: неизвестно, насколько хорошо агенты соблюдают эти инструкции и насколько этот скилл уменьшает количество проблем в коде.
Вопросы и ответы
Что такое ub-mode?
Это файл с инженерными правилами для агента, от TDD до проверок качества и коммитов.
С какими агентами можно использовать ub-mode?
В README приведены пути для Claude, Grok и Cursor. Для других сред потребуется проверить, поддерживают ли они такой формат скилла и команду его вызова.
Где взять всё, что нужно для скилла Дяди Боба?
ub-mode — скилл: файл SKILL.md с правилами для агента и README с инструкцией по установке для Claude, Grok и Cursor.
Crapper — утилита, которая оценивает, насколько рискованно менять каждую функцию, по её сложности и покрытию тестами. Поддерживает Clojure, Java, Go, TypeScript, Rust и Python.
Dryer — утилита, которая ищет похожие фрагменты кода.
Mutator — утилита мутационного тестирования: вносит в код мелкие ошибки и показывает, какие из них прошли незамеченными при тестировании.
Mentions
Дядя Боб написал правила для ИИ-агентов: разбираем ub-mode Автор «Чистого кода» Роберт Мартин aka Дядя Боб взялся за ИИ-агентов. В скилле ub-mode, который Дядя Боб на днях выложил на GitHub, всего около 750 слов. Этими словами Мартин выстраивает работу агента так, будто сам стоит рядом и смотрит на монитор строгим взглядом. На днях Роберт Мартин aka Дядя Боб, автор «Чистого кода», выложил на GitHubub-mode — набор правил для ИИ-агентов. Весь скилл — один файл примерно на 750 слов: короткие ёмкие правила, написанные по тем же принципам «чистого кода». Теперь у каждого разработчика будет свой Дядя Боб: он встанет над ИИ-агентом с линейкой и проследит за гигиеной кода. При разборе багов агент приносит правку и пишет «готово, шеф». По одному диффу не понять, так ли это: старые тесты могли остаться зелёными и при неверной логике, а новая проверка — просто спрятать сбой. Скилл ub-mode заставляет агента обосновать свою работу: сначала показать тест, который падает из-за бага, потом предъявить правку, после которой тест проходит. В репозитории ub-mode нет кода: там только README.md и SKILL.md. Второй файл описывает порядок действий, а README отсылает к утилитам, которые меряют сложность кода, ищут дубли и проверяют, ловят ли тесты ошибки. Автор пишет, что частично использовал идеиpoteto-mode / pstack. Правила разбиты на три части: First Make it Work, Then Make it Right и Practice. Воспроизводимость ошибки Мартин требует от агента начать с TDD: тест надо написать до изменения кода. Агент должен проверить, что тест падает по ожидаемой причине. Затем — минимальная правка, которая сделает тест зелёным. Никакого формализма быть не должно: если написать честный тест слишком сложно — не нужно писать фиктивный. Архитектура: данные, ввод и повторный запуск Дядя Боб требует от агента архитектурных решений. До того, как писать логику, агент должен продумать структуру данных и проверить всё, что приходит извне, прямо на входе в систему. Код, который изменяет данные (например, пишет в базу или обращается к внешним сервисам), агент должен писать так, чтобы повторный запуск или перезапуск после сбоя на середине приводил к тому же результату, что и первый запуск. Важен принцип «убери лишнее перед тем, как добавлять». Прежде чем писать новый код, агент должен упростить то, что уже есть: например, удалить ненужные ветки, обёртки и дубли. Новая функциональность ложится уже на расчищенную основу. Первопричина вместо заплатки В разделе Then Make it Right Мартин требует искать первопричину ошибки, а не маскировать симптом. Это правило он сформулировал так: «Защитная проверка, которая только прячет падение, — это не исправление» ("A guard that only hides the crash is not a fix"). Например, проверка на null уберёт падение, но не ответит на вопрос, откуда в этом месте null и может ли он там быть по модели данных. Иногда guard и в самом деле нужен, но правило требует понять причину сбоя, а не считать защитную проверку достаточным исправлением. По той же логике скилл запрещает агенту глушить ошибки компилятора: заглушённая ошибка прячет проблему, как и проверка на null. Спрятать баг может и сам тест. Поэтому Мартин требует, чтобы тесты проверяли поведение так, как его видит пользователь кода. Если тест пройдёт даже тогда, когда каждая функция возвращает пустой результат, этот тест надо выбросить. На тестах, которые проверяют поведение, держится и рефакторинг: сначала тесты фиксируют, что делает код, потом агент небольшими шагами меняет структуру и на каждом шаге проверяет, что поведение не изменилось. Проверки качества: утилиты Crapper, Dryer и Mutator Мартин не полагается на оценку кода, которую даст сам агент. Скилл ub-mode требует от агента прогонять код через три утилиты: Crapper оценивает, насколько рискованно менять каждую функцию: чем функция сложнее и чем хуже покрыта тестами — тем выше балл. Dryer ищет похожие фрагменты кода. Mutator вносит в код мелкие ошибки и смотрит, увидят ли тесты проблему. По итогам проверок агент должен разбить или покрыть тестами рискованные функции, убрать дубли, дописать тесты там, где ошибки прошли незамеченными, и удалить мёртвый код. Пороги Мартина (риск меньше 10 для каждой функции, дубли с похожестью от 0,8) — его личные требования, здесь каждый решает сам. Журнал решений, worktree и коммиты Последний блок скилла, Practice, описывает рабочую дисциплину. Агент должен фиксировать все свои действия и причины решений, беречь контекстное окно, делать небольшие коммиты и не удалять Git-worktree, если в нём есть незакоммиченные изменения. В сообщении коммита должны быть изложены причина, суть изменения и способ проверки. Есть пункт, который командам придётся адаптировать: скилл требует в конце работы отправлять изменения в основную ветку. Это правило нельзя переносить без изменений, если в команде обязательны pull request, ревью и CI. Скилл задаёт предпочтения Мартина, а не универсальную политику. Встраивать работу агентов в командный процесс учит программа Хекслета «AI SDLC»: от спецификации и ревью до CI/CD. Как подключить ub-mode В README описан простой способ: скопировать SKILL.md в каталог skills своего агента. Для Claude указан путь ~/.claude/skills/ub-mode/SKILL.md; в примерах есть Grok и Cursor. Затем вызовите скилл командой /ub-mode. Для полноценной работы скилла нужно самостоятельно установить Crapper, Dryer и Mutator. Для тестирования скилла можно взять небольшую задачу с понятным ожидаемым результатом. После выполнения работы нужно посмотреть, написал ли агент падающий тест до того, как изменить код, ограничился ли нужным диффом и какие проверки действительно выполнил. Одна удачная правка ничего не скажет об эффективности скилла. Работу с агентами, контекстом и проверкой результата мы разбираем на курсе Хекслета «ИИ для разработчиков». В README и SKILL.md нет результатов сравнительных испытаний: неизвестно, насколько хорошо агенты соблюдают эти инструкции и насколько этот скилл уменьшает количество проблем в коде. Вопросы и ответы Что такое ub-mode? Это файл с инженерными правилами для агента, от TDD до проверок качества и коммитов. С какими агентами можно использовать ub-mode? В README приведены пути для Claude, Grok и Cursor. Для других сред потребуется проверить, поддерживают ли они такой формат скилла и команду его вызова. Где взять всё, что нужно для скилла Дяди Боба? ub-mode — скилл: файл SKILL.md с правилами для агента и README с инструкцией по установке для Claude, Grok и Cursor. Crapper — утилита, которая оценивает, насколько рискованно менять каждую функцию, по её сложности и покрытию тестами. Поддерживает Clojure, Java, Go, TypeScript, Rust и Python. Dryer — утилита, которая ищет похожие фрагменты кода. Mutator — утилита мутационного тестирования: вносит в код мелкие ошибки и показывает, какие из них прошли незамеченными при тестировании.
I have always said that leetcode is a terrible metric for hiring. If none of that proves it, @poteto had a massive open source repo for all companies that don't hire this way. poteto/hiring-without-whiteboards
@poteto Everyone supports woman until she's doing so much better than you I've been following your work since this repo on GitHub, I don't think that pstack of yours came out of no where, keep your head high let them talk 🦜 poteto/hiring-without-whiteboards
จาก Excel สู่ Grok Bot: Lauren Tan เรียนเขียนโค้ดและใช้ AI agent ทำงานอย่างไร? โดย Nokka (นก-กา) | ตรวจข้อมูล 25 ต.ค. 2026 · ตอนที่ 1 จาก 6 ของชุด "หนึ่งคนกับทีม agent" บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา) !ภาพเปิด: แล็ปท็อปเปิดอยู่บนโต๊ะไม้ในห้องมืด จอแสดงตารางกริดเรืองแสงสีฟ้าอมน้ำเงิน และมีเก้าอี้ว่างอยู่ด้านหลัง ตัวเลขที่ทำให้ผมสะดุดคือ 2,000 พูลรีเควสต์ (PR) ในหนึ่งเดือน จากวิศวกรคนเดียว [6] หรือเกือบ 100 PR ต่อวันทำการ ซึ่งถ้าคุณเคยรีวิวโค้ดจะรู้ว่าวิธีเดิมทำไม่ได้ ผมจึงไปตามหาว่าเธอเป็นใคร และเส้นทางจากเด็กที่ไม่ได้เรียนคอมพิวเตอร์มาถึงจุดนี้หน้าตาเป็นอย่างไร ตอนนี้เป็นตอนเปิดชุด ผมจะเล่าเส้นทางอาชีพของ Lauren Tan และสิ่งที่ผมคิดว่าเอามาใช้ได้จริง ส่วนสถาปัตยกรรม Grok Bot กับ pstack จะอยู่ในตอนถัดไป เริ่มจากเว็บโรงเรียน ไม่ใช่ห้องเรียนคอมพิวเตอร์ งานแรกที่ได้เงินคือ redesign เว็บโรงเรียน Lauren Tan เล่าในพอดแคสต์ของ Changelog ว่าเธอโตที่สิงคโปร์ และเริ่มจับเว็บตั้งแต่ยังเรียนมัธยม [1] งานที่ได้เงินงานแรกคือ redesign เว็บไซต์โรงเรียนตอนอายุราว 15 ถึง 16 ปี ทำด้วย HTML, CSS และ JavaScript นิดหน่อย [1] ก่อนจะมาถึงตรงนั้น เธอสนใจกราฟิกดีไซน์และ Photoshop มาก่อน โดยเรียนจากคอร์สออนไลน์ด้านดีไซน์ [2] เธอเล่าว่าในยุคที่เธอเติบโต ผู้คนรอบตัวยังไม่ค่อยรู้จัก dotcom boom เธอจึงไม่เคยคิดว่าการทำเว็บเป็นอาชีพที่เลี้ยงตัวเองได้ [1] ประโยคนี้สำคัญเพราะมันอธิบายการตัดสินใจหลายอย่างที่ตามมา เรียนการเงิน เพราะคิดว่าต้องทำอะไรที่จับต้องได้ วิชาเดียวที่ใกล้เคียงการเขียนโปรแกรม แทนที่จะเรียนคอมพิวเตอร์ เธอเลือกเรียนการเงินที่มหาวิทยาลัย Monash ในออสเตรเลีย ตามการสนับสนุนของพ่อแม่ และเพราะเธออยากทำอะไรที่จับต้องได้ [1][2] บทความชีวประวัติบน X อ้างคำพูดของเธอว่าเธอได้เรียนรู้การเขียนโค้ดผ่าน Excel ในวิชา financial modeling [2] วิชานี้ทำให้เธอได้เขียนโปรแกรมเป็นครั้งแรก และเธอบอกว่ารู้สึกสนุกทันที [2] ผมชอบรายละเอียดนี้เพราะมันต่างจากเรื่องเล่ามาตรฐานของคนในวงการ ซึ่งมักเริ่มจาก "ผมเขียนโปรแกรมตั้งแต่ 8 ขวบ" หลังเรียนจบ เธอทำสตาร์ทอัพและล้ม หลังจบการศึกษา เธอเริ่มทำสตาร์ทอัพกับเพื่อน ชื่อ ThePriceGeek เป็นเครื่องมือเช็กราคาสินค้าบน eBay และ Craigslist [1][2] รายได้ขึ้นถึงราว 1,000 ดอลลาร์สหรัฐต่อเดือน ก่อนเงินจะหมดและไปต่อไม่ไหว [2] เธอเล่าว่าได้เรียนรู้มหาศาลจากกระบวนการนั้น ทั้งเรื่องการสร้างผลิตภัณฑ์และการเขียนโค้ดให้ดีขึ้น [1] หลังความล้มเหลวครั้งนั้น เธอเริ่มเรียนรู้การเขียนเว็บอย่างจริงจัง เริ่มจากเขียนบล็อกเรื่อง Ember แล้วแชร์โพสต์เหล่านั้นออกไป [2] ผมอ่านช่วงนี้แล้วได้ข้อสรุปของตัวเองว่า สิ่งที่ทำให้เธอไปต่อได้ไม่ใช่ความมั่นใจ แต่เป็นการยอมรับว่าตัวเองเป็นมือใหม่ในสนามที่คนอื่นดูเก่งกว่า นั่นเป็นความเห็นของผม ไม่ใช่คำพูดของเธอ ช่วงที่สร้างชื่อในชุมชนนักพัฒนา เขียน พูด แล้วค่อยได้งาน เส้นทางหลังจากนั้นคือการทำซ้ำ ๆ ในสิ่งที่เธอถนัด คือลอง ล้ม แล้วลองใหม่ - เขียนบทความเทคนิคให้ชุมชน Ember - ขึ้นพูดที่งาน EmberConf - เขียนบล็อกส่วนตัวต่อเนื่อง - ได้งานพัฒนา frontend ที่ DockYard และย้ายไปบอสตันในปี 2015 [2] ในเว็บส่วนตัวของเธอระบุว่าพูดในงานประชุมมาแล้วมากกว่า 15 ครั้ง หัวข้อตั้งแต่ TypeScript, JavaScript, React ไปจนถึง Elixir และการเป็นหัวหน้าทีม [3] ถ้าดูรายการจริงจะเห็นว่าเธอหยิบแกนเรื่องเดิมไปเล่าใหม่ในงานต่างประเทศหลายรอบ ซึ่งผมคิดว่าเป็นวิธีบังคับให้ตัวเองอัปเดตเนื้อหาแต่ละรอบ ผมมองว่านี่คือรูปแบบการเรียนรู้ที่ใช้ได้กับทุกคน ไม่ใช่แค่คนที่ขึ้นเวทีเก่ง จากผู้จัดการที่ Netflix กลับมาเป็นวิศวกรที่ Meta ปี 2020 เธอเขียนบล็อกสั้น ๆ ว่าเธอลาออกจาก Netflix เพื่อกลับไปเป็นวิศวกร และจะประกาศที่ใหม่เดือนถัดไป [4] เธอเล่าใน Changelog ว่าตอนเป็นผู้จัดการที่ Netflix เธอมีเพื่อนร่วมตำแหน่งให้ปรึกษา แต่ปฏิสัมพันธ์ส่วนใหญ่เป็น one-on-one กับประชุมทีมรายสัปดาห์ ทำให้รู้สึกโดดเดี่ยวมากกว่าที่คาด [1] จากนั้นเธอย้ายไปอยู่ทีม React ที่ Meta และทำงานกับ React Compiler ซึ่งเป็นคอมไพเลอร์ที่แปลงโค้ด React ให้ทำงานเร็วขึ้นโดยไม่ต้องให้คนเขียน memo เอง [2][5] งานนี้สำคัญต่อเรื่องที่เราจะคุยกันในตอนหลัง เพราะมันคือการแก้ปัญหาด้วยการเปลี่ยนโครงสร้าง ไม่ใช่การเพิ่มคำเตือน ถึง Cursor แล้วถึง Grok Bot ปัจจุบัน GitHub ของเธอระบุว่าทำงานที่ xAI และเป็นสมาชิกทีม React Compiler [5] ชื่อบริษัทในปี 2026 ไม่ได้เรียกว่า xAI เฉย ๆ แล้ว เพราะ SpaceX เข้าซื้อ xAI เมื่อเดือนกุมภาพันธ์ [8] และปิดดีลซื้อ Cursor เมื่อวันที่ 14 สิงหาคม [9] หน้าเว็บประกาศของ xAI ใช้ SpaceXSI ต่อท้ายหัวเรื่อง และลงท้ายหน้าด้วย SpaceXAI LLC [8] ฝั่ง Cursor ระบุในบล็อกของบริษัทว่าการซื้อกิจการเสร็จสมบูรณ์ และเริ่มจากความร่วมมือกับ SpaceXAI เมื่อเดือนเมษายน [9] บทความของ The New Stack ระบุว่าเธออยู่ทีม Grok ที่ SpaceXAI และเคยอยู่ Cursor กับ Meta มาก่อน [6] ดังนั้นภาพที่ถูกต้องคือ Grok Bot กับ Cursor อยู่ใต้เจ้าของเดียวกัน ซึ่งผมคิดว่าเป็นเหตุผลที่คนคนเดียวทำงานข้ามสองผลิตภัณฑ์ได้ สิ่งที่ผมคิดว่าเป็นแกนของเส้นทางนี้ สี่รูปแบบที่เห็นซ้ำ ถ้าอ่านเส้นทางทั้งหมดแล้วตัดตัวเลขหรือชื่อบริษัทออก จะเห็นรูปแบบที่ไม่หวือหวา แต่ผมคิดว่ามันคือคำตอบของคำถามที่ว่าเธอทำได้อย่างไร หนึ่ง เธอไม่ได้เริ่มจากจุดที่ได้เปรียบ เด็กสิงคโปร์ที่ทำเว็บโรงเรียน คนเรียนการเงินที่ทำสตาร์ทอัพเจ๊ง คือจุดเริ่มที่ห่างจากซิลิคอนแวลลีย์มาก [1][2] สอง เธอใช้การเขียนและการพูดเป็นการบังคับเรียนรู้ บทความ การพูดในงานประชุม และบล็อก ไม่ใช่ผลพลอยได้จากงาน แต่เป็นกลไกที่ทำให้เธอต้องเข้าใจเรื่องนั้นจริง ๆ [2][3] สาม เธอเปลี่ยนบทบาทไปมาได้ ผู้จัดการที่ Netflix กลับมาเป็นวิศวกรที่ Meta ได้ เพราะทักษะสองด้านนี้ไม่ใช่บันไดที่เดินขึ้นอย่างเดียว [1][4] สี่ เธอแก้ที่โครงสร้าง React Compiler คือการยอมให้เครื่องมือจัดการเรื่องที่มนุษย์ลืมบ่อย มากกว่าการเขียนคำเตือนให้คนจำ [2] ข้อสี่คือสิ่งที่เชื่อมไปสู่ Grok Bot ทั้งหมด เพราะชุดสกิล pstack ที่ผูกกับ Grok Bot ก็ใช้ตรรกะเดียวกัน คือเปลี่ยนกฎที่คนต้องจำให้เป็นด่านที่ระบบบังคับ [7] ตัวอย่างแผน 90 วันสำหรับคนที่อยากเดินเส้นทางคล้ายกัน ผมไม่คิดว่าทุกคนต้องไปเป็นวิศวกรที่ SpaceXSI แต่ผมคิดว่าเส้นทางนี้ย่อยเป็นแผนที่ทำได้จริง เดือนที่ 1: หา "Excel ของตัวเอง" - เลือกงานที่ทำอยู่ทุกวัน แล้วเขียนสคริปต์เล็ก ๆ ที่ทำแทนได้ - เป้าหมาย: เห็นตัวแปร ลูป เงื่อนไขในงานจริง ไม่ใช่ในบทเรียน เดือนที่ 2: ทำอะไรที่คนอื่นใช้ - เปิด repo สาธารณะ หรือเขียนบล็อกอธิบายสิ่งที่เพิ่งเรียนรู้ - เป้าหมาย: มีคนอื่นอ่าน แล้วถามกลับอย่างน้อย 1 คำถาม เดือนที่ 3: พูดหรือสอน - ขึ้นพูด 5 นาทีในทีม หรือเขียนโพสต์ยาว 1 ชิ้น - เป้าหมาย: อธิบายให้คนที่ไม่รู้เรื่องเดียวกับเราเข้าใจได้ เกณฑ์ผ่าน: มีงานจริง 1 ชิ้นที่คนอื่นใช้ และมีคำอธิบาย 1 ชิ้นที่คนอื่นอ่าน ผมใส่เกณฑ์ผ่านไว้เพราะถ้าไม่มีเกณฑ์ ทุกคนจะเถียงว่าตัวเองทำครบแล้ว สิ่งที่ตอนต่อไปจะตอบ ตอนนี้เรารู้แล้วว่าเธอมาจากไหน แต่ยังไม่รู้ว่าเธอทำอะไรที่ทำให้คนเดียวดูแล agent ได้หลายสิบตัว ตอนที่ 2 ผมจะลงรายละเอียด Grok Bot ว่ามันแบ่งบทบาทอย่างไร มี Chief of Staff ทำอะไร และทำไมตัวเลข PR ถึงกระโดดได้ขนาดนั้น ตอนที่ 3 จะลงไปใน pstack ว่ามันมี playbook กี่เล่ม มี Skill กี่ตัว และ routing ทำงานอย่างไร ผมจะเขียนทีละตอนและรายงานความคืบหน้าให้คุณดูเหมือนเดิม REF [1] Changelog (2020) · Engineer to manager and back again (The Changelog #386) transcript. changelog.com [2] mvanhorn (17 ต.ค. 2026) · Who Is Lauren Tan, aka Poteto? The Architect Behind Grok Bot, and the Engineer Elon Keeps Reposting (บทความชีวประวัติบน X ซึ่งเป็นแหล่งชั้นรอง). x.com [3] Lauren Tan (2026) · Speaking. no.lol [4] Lauren Tan (17 ก.พ. 2020) · Does It Spark Joy? no.lol [5] GitHub (2026) · poteto profile. github.com/poteto [6] The New Stack (19 ก.ย. 2026) · One engineer shipped 2,000 PRs a month to production. Verification is the key. thenewstack.io [7] Cursor (2026) · pstack skill: principle-encode-lessons-in-structure. github.com/cursor/plugins/blob/main/pstack/skills… [8] xAI (2 ก.พ. 2026) · xAI joins SpaceX. x.ai [9] Cursor (14 ส.ค. 2026) · Cursor is now a part of SpaceX. cursor.com
@catalinmpit @dlqnt_xyz github.com/poteto A lot of her work is public t.co
Hiring Without Whiteboards: Companies that don't have a broken hiring process (52.6k stars) What it does All text below is quoted directly from the project README. >A list of companies (or teams) that don't do "whiteboard" interviews. "Whiteboards" are used as a metaphor, and are a symbol for the kinds of CS trivia questions that are associated with bad interview practices. Whiteboards are not bad – CS trivia questions are. >The companies and teams listed here use interview techniques and questions that resemble day-to-day work. For example, pairing on a real world problem or a paid/unpaid take home exercise. tl;dr - Discussing a real world problem (with or without whiteboard) is - Solving CS trivia, technical puzzles, riddles, brainteasers (with or without whiteboard) is Duds >If you've been through an interview with one of these companies recently, and your experience suggests otherwise from their description, please open a PR to remove them from this list. Repository poteto/hiring-without-whiteboards Repository stats |Metric|Value| |:-|:-| |Stars|52,595| |Forks|3,961| |Last release|None| |Languages|JavaScript 100%| |Contributors|1,023| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|None| |AI co-authored commits|None| Main contributor |Field|Value| |:-|:-| |Name|lauren| |GitHub|@poteto| |Commits to this repo|85 (top contributor)| |Bio|▼・ᴥ・▼ Software Engineer @xai-org & @react compiler core team| |Company / Location|@xai-org / socal| |Website|no.lol| |X / Twitter|@poteto| |Followers|12,516| |Public repos|85| |On GitHub since|2012-01-30| ------------------------------------------------------------------------------------------- Discover the best GitHub repos without the endless scrolling. Get top repos organized by category (AI, DevOps, Databases & more), plus key takeaways from developers' most useful comments - all in one free, twice-weekly newsletter. 👉 Get the best repos & community insights - Free
hey @poteto i just saw your github.com/poteto and i think i just fully passed behavioral interview with this
不小心点进了 poteto 的 GitHub 主页 github.com/poteto%EF%BC%8C%E6%B2%A1%E6%83%B3%E5%8… 😂 t.co