У цій серії дописів я покажу вам, як використовую pstack, свій набір навичок для виконання ретельної інженерної роботи. Це дозволило мені впевнено випускати 2000 PR на місяць у продакшн.
Особисто я ніколи не надавав великого значення тому, скільки рядків коду чи PR я роблю. До появи агентів нікого це не хвилювало, і цілком справедливо, оскільки сира продуктивність не завжди дорівнювала якості чи помітному результату для користувачів. Це була просто метрика марнославства.
Але, створюючи pstack, я зрозумів, що обсяг має значення, особливо коли ви можете підтримувати або навіть підвищувати рівень якості продукту за допомогою агентів. Наприклад, я почав працювати над Grok @Bot близько 2 місяців тому, коли він був ще на ранніх стадіях, а кодова база була свіжою, але вже починала зростати. Незважаючи на те, що команда зростає і тепер щодня вносить сотні PR у кодову базу Grok @Bot, pstack дозволив мені підтримувати високу якість коду для всіх, оскільки я постійно моніторю код, рефакторю, додаю нові перевірки та працюю над функціями.
https://x.com/poteto/status/2090546476464451907
https://x.com/poteto/status/2078527882499150286
Бути садівником і супроводжувачем Grok @Bot — це те, що я зміг робити лише завдяки pstack. Наш ранній імпульс після створення прототипу був дуже високим, і до команди приєднувалося багато людей. У мене був критичний момент можливості рефакторити всю кодову базу, поки вона створювалася та розширювалася без простоїв, перетворюючи її на щось із міцною основою. Кодова база високої якості, яка масштабується незалежно від того, скільки інженерів (і, що найважливіше, не-інженерів) роблять у неї внесок. Уся ця робота вимагає від мене рефакторингу та покращення основ Grok Bot у процесі його створення, і ви можете це робити лише тоді, коли основи встигають за кількістю внесків.
Grok Bot — один із найефективніших і найпродуктивніших AI десктопних додатків на ринку
Доказом є сам Grok @Bot. Протягом наступних кількох тижнів я розповім вам усе, що потрібно знати, щоб створювати та підтримувати високоякісний додаток за допомогою pstack.
Частина 1 – Верифікація — це все, що вам потрібно
Найважливіша навичка, яку потрібно мати у своєму арсеналі, — це високоякісна навичка верифікації. Ця навичка настільки важлива для підтримки, що я сприймаю її більше як критичну інфраструктуру, а не просто як "ще одну" навичку. Хороша верифікація підсилить результати всієї вашої команди, включаючи не-інженерів. Зроблена добре, вона збільшить продуктивність вашої команди в 100-1000 разів.
Якщо ви не знайомі з терміном, верифікація означає, що агент може перевіряти власну роботу. Він може продовжувати, доки не виконає завдання, оскільки тепер може замкнути цикл без вас як вузького місця. Якщо вам цікаво дізнатися більше про те, як я створив свою першу навичку верифікації для Cursor, перегляньте мій попередній допис Loops You Can Trust.
Давайте створимо навичку верифікації разом
Для початку встановіть pstack, а потім запустіть /create-verification-skill. Я також рекомендую додати Dr Eggbot, мого бота, який допомагає створювати високоякісних ботів, до вашого списку. Dr Eggbot постачається з pstack. Він навчить ботів для кодування, як ним користуватися, а також може створювати ботів, які не кодують, з такою ж ретельністю.
Ви можете попросити Dr Eggbot створити для вас бота-інженера, якого потім попросите запустити /create-verification-skill і налаштувати щоденну рутину для запуску /maintain-verification-skill.
Люблю Dr Eggbot
Поки це виконується, давайте розглянемо, що робить ця навичка і як вона створює для вас високоякісну навичку верифікації.
Я об'єднав усі наші навички верифікації, які ми використовуємо для створення Grok @Bot та Cursor, у цю навичку як свого роду мета-навичку. Вона навчає вашого агента, як створити високоякісну навичку для вашого власного додатку.
І ось тут вибір технологічного стеку має значення. Якщо ви створюєте додаток на Electron або для вебу, ви можете скористатися багатими інструментами налагодження, доступними в екосистемі JS. Наприклад, Chrome DevTools Protocol (CDP) дозволяє використовувати ті самі інструменти, що доступні в інструментах розробника вашого браузера. Або, якщо ви створюєте iOS додаток, використовуйте симулятор.
В ідеалі вам потрібна можливість взаємодіяти з вашим додатком, налагоджувати його, знімати профілі продуктивності та використовувати будь-які інші інструменти налагодження та розробки, які ви зазвичай використовували б під час ручної розробки. Якщо у вас немає багатого середовища виконання, вам може знадобитися попросити агента створити інструменти для вас (наприклад, використовуючи lldb або власний пакет, який працює як сайдкар у середовищах розробки), або просто використовувати те, що є.
Особисто я вважаю, що агентна верифікація настільки важлива, що я без іронії запропонував би створити власні потужні інструменти налагодження або навіть вибрати інший технологічний стек, щоб отримати несправедливі переваги та екстремальну продуктивність у створенні програмного забезпечення. Як я вже згадував, надання агентам можливості перевіряти власну роботу відкриває можливість для всіх у вашій організації робити внесок і підтверджувати, що їхні зміни дійсно працюють. Чим складніший ваш технологічний стек для налагодження та контролю, тим важче буде продуктивно використовувати агентів.
Зробіть це відтворюваним
У pstack ми маємо принцип під назвою "Build the Lever". У контексті створення навички це означає, що ми надаємо перевагу наданню агентам інструментів, а не просто markdown. Для навичок верифікації це означає створення невеликого CLI, який скриптує взаємодію та налагодження вашого додатку в невеликій, зручній для агента утиліті. Це означає, що агенти споживають менше токенів, намагаючись виконати завдання (запустити команду CLI замість написання одноразового скрипта для кліку), і робить вашу навичку верифікації більш відтворюваною та тестованою.
Ось гіпотетичний приклад CLI, який ваш агент може створити для Electron додатку:
1# health2node .cursor/skills/verify-atlas/control-atlas.mjs doctor34# open a blank thread and send5node .cursor/skills/verify-atlas/control-atlas.mjs new-session6node .cursor/skills/verify-atlas/control-atlas.mjs send "list open tasks in this project"78# keyboard path9node .cursor/skills/verify-atlas/control-atlas.mjs press "Meta+KeyN"1011# accessibility snapshot of the live UI12node .cursor/skills/verify-atlas/control-atlas.mjs snapshot1314# screenshot for evidence15node .cursor/skills/verify-atlas/control-atlas.mjs screenshot /tmp/atlas-proof.png1617# wait for streaming / layout to settle18node .cursor/skills/verify-atlas/control-atlas.mjs wait-settle1920# flip a feature flag for the session21node .cursor/skills/verify-atlas/control-atlas.mjs feature-flag rooms_v2 on
Тепер усі агенти можуть використовувати цей CLI для швидкої навігації та налагодження вашого додатку. Вам також варто почати думати про досвід розробки (dev experience) вашого додатку:
- заповнення тестової бази даних
- як обробляти аутентифікацію, тестових користувачів, API виклики до тестового/стейджингового середовища
- встановлення та запуск вашого середовища розробки узгодженим способом
Усе це — речі, про які вам, ймовірно, вже доводилося думати, коли ви писали код самостійно. Тож сприймайте це як основну утиліту ваших агентів для виконання роботи з розробки вашого додатку. Підтримуйте її в хорошому стані та тестуйте!
Ось ще кілька прикладів команд, які варто розглянути:
1- **Inspection:** `info`, `snapshot`, `screenshot`, `components`2- **Navigation:** `home`, `new-session`, `select-project`, `select-runtime`, `scroll`3- **Interaction:** `send`, `click`, `click-xy`, `aria-click`, `type`, `press`, `eval`, `upload-image`, `add-context`, `feature-flag`4- **Performance:** `trace`, `profile`, `record`, `perf-metrics`, `wait-settle`5- **Streaming:** `console`, `network-log`, `network-summary`6- **Health & cleanup:** `doctor`, `cleanup`, `watch --restart`
Після того, як ви налаштуєте цю базову конфігурацію, ви вже повинні помітити значне покращення у ваших агентах. Вони зможуть легко орієнтуватися та налагоджувати ваш додаток.
Я рекомендую витратити час на те, щоб зробити цей CLI хорошим і без помилок, перш ніж робити щось складніше. Вам також варто подумати (або попросити свого агента) про дизайн CLI, зручного для агента. В інтернеті є багато ресурсів, на які ви можете вказати своєму агенту, але ключові властивості, які мені подобаються:
- API легко компонувати — подумайте про філософію глибоких модулів Джона Аутерхаута
- будь-яка команда з потенційно деструктивними побічними ефектами повинна мати опцію --dry-run
- використовуйте підкоманди для поступового розкриття функціональності, а не все одразу
- повідомлення про помилки повинні бути дуже описовими та підказувати агенту, що робити замість цього
- багатий текст --help
- вивід у машиночитаному форматі (наприклад, JSON)
Прискорюйтеся за допомогою паралелізму з Cloud Agents замість worktrees
Коли ви досягнете певного успіху у використанні вашої навички верифікації для виконання кількох PR, ви можете почати замислюватися, чи можна паралелізувати більше. Наприклад, якщо агент тепер може взяти ваш запит і майже довести його до стану, готового до злиття, хіба це не звільняє вас для запуску більшої кількості агентів?
Вашим першим інстинктом буде додати підтримку worktree, тобто ваші агенти зможуть використовувати git для створення відстежуваної копії репозиторію, де вони можуть вносити зміни ізольовано від основної гілки. Теоретично це дозволяє запускати кількох агентів одночасно, не побоюючись, що їхні зміни перезапишуть одна одну.
Я б рекомендував цього не робити. По-перше, це використовує багато дискового простору та ресурсів вашого комп'ютера. Можливо, вам вдасться запустити до 10 агентів паралельно з worktrees, залежно від розміру вашого репозиторію та потужності вашого комп'ютера. Але є набагато кращий спосіб!
Cloud agents від Cursor — це агенти, які працюють у хмарі, на інфраструктурі Cursor. Ці агенти мають доступ до реального комп'ютера, тобто можуть встановлювати залежності, запускати ваш додаток, робити відео та скріншоти, а також взаємодіяти з вашим додатком як реальний користувач. Якщо ви достатньо інвестували в попередній крок, щоб зробити ваш досвід розробки хорошим, налаштування cloud agents не має бути надто складним. Коли ви вперше налаштовуєте своє хмарне середовище, ми надсилаємо агента, який допоможе вам налаштувати та запустити його правильно. Після першої збірки ми робимо snapshot, що означає, що наступні запуски cloud agents завжди стартують швидко.
Я дуже рекомендую знайти час для налаштування cloud agents, оскільки це відкриває величезне підвищення продуктивності за рахунок паралелізму. У наступному дописі я покажу вам, як запускаю сотні саб-агентів паралельно в хмарі! Але поки що налаштуйте своє середовище та приведіть його до стану, коли ви почнете впевнено запускати всіх своїх агентів у хмарі.
Підтримуйте агентів розумними за допомогою Feature Maps
У міру того, як ваш додаток стає складнішим, агентам потрібно більше вказівок, щоб знаходити функції та взаємодіяти з ними. Для цього я придумав те, що називаю Feature Map. Як випливає з назви, це легкодоступна карта всіх функцій, доступних у вашому додатку, що вони роблять і як до них дістатися з точки зору користувача.
Ось приклад Feature Map, який я підготував для вигаданого додатку під назвою Atlas. Це всього лише кілька markdown файлів, на які посилається SKILL.md навички верифікації.
Ви можете розмістити цей файл будь-де, але в /create-verification-skill ми автоматично створюємо директорію references/features разом із README.md. README — це сама карта: загальний огляд усіх основних доступних функцій із посиланнями на конкретні деталі. Приклад функції виглядає приблизно так:
1# Preferences23Full-screen preferences overlay and its tab set.45## Sub-features67- settings-overlay: full-screen overlay opened from the gear or Cmd/Ctrl+,8- settings-nav: left nav of tabs (General, Appearance, Models, Plan & Usage, ...).9- settings-search: in-overlay search (Cmd/Ctrl+K while settings is open).10- theme-picker: quick theme control on Appearance.1112## How to get to it (user POV)1314Click the gear next to the account avatar, or press Cmd/Ctrl+,. Pick a tab from the left nav. Type in the preferences search box to jump. Escape or the close control dismisses.1516## Driving it with control-atlas1718bash19node .cursor/skills/verify-atlas/control-atlas.mjs press "Meta+Comma"20node .cursor/skills/verify-atlas/control-atlas.mjs snapshot21node .cursor/skills/verify-atlas/control-atlas.mjs press "Escape"2223- Overlay root: look for a dialog/region named Preferences in the a11y tree.24- Tabs: click by visible name. Plan & Usage may be absent for some account states.25- While settings is open, Cmd/Ctrl+K is preferences search, not the global palette (see `multi-surface-journeys.md`).2627## Gotchas2829- Closing settings mid-suite can leave focus nowhere useful. `new-session` or `home` recovers.30- Some tabs are entitlement-gated. Skip with an explicit account reason.
Не хвилюйтеся про те, щоб писати це самостійно! Коли ви запускаєте /create-verification-skill, ваш агент автоматично перегляне ваш додаток, каталогізує все та створить ці посилання для вас.
Feature Map у поєднанні з CLI є однією з головних причин, чому навички верифікації pstack настільки хороші. Тепер агенти мають контекст про кожну окрему функцію та як до неї дістатися, що економить дорогоцінні токени в їхньому контекстному вікні та навчає їх, для чого вона призначена і як туди потрапити.
Ви можете розглядати Feature Map як форму "матеріалізованої пам'яті". Якщо ви вже деякий час користуєтеся агентами, ви, напевно, знайомі з концепцією пам'яті — зазвичай вона може зберігатися у вигляді простих markdown файлів (наприклад, сховище Obsidian) або навіть чогось складнішого, як векторна база даних. Особисто я вважаю, що ваша кодова база є найкращою формою пам'яті. Код — це проекція прийняття рішень вами та вашою командою і є джерелом правди про те, що сталося і як насправді все працює. Feature Map — це просто більш компактна форма цього, призначена для економії токенів. І оскільки це просто markdown всередині навички, кожен, хто робить внесок у вашу кодову базу, отримує вигоду від цієї спільної пам'яті.
Це означає, що підтримка навички верифікації дуже важлива. Я рекомендую запускати /maintain-verification-skill принаймні раз на день, щоб ваші агенти завжди мали найновіші деталі щодо керування вашим додатком. Ви також можете помітити, що в міру частішого використання навички верифікації агенти автоматично оновлюватимуть її під час роботи над вашим додатком. /maintain-verification-skill виловлює все, що було пропущено.
Як використовувати вашу навичку верифікації
Для довідки, ось приклад навички верифікації, створеної для вигаданого додатку: https://github.com/poteto/verification-skill-example. Нагадую, запустіть /create-verification-skill, щоб створити таку, яка включає базовий CLI та Feature Map.
Ось як я зазвичай використовую її з pstack.
По-перше, звичайно, потрібно почати ваш запит з /poteto-mode. Якщо ви використовуєте pstack через Cursor, ви також можете натиснути Opt + Enter замість просто Enter, коли автодоповнюєте /poteto-mode — це додає навичку як Custom Mode, який закріплює навичку, щоб ваш агент отримував нагадування використовувати її на кожному новому кроці.
Введіть /poteto-mode і натисніть Opt + Enter, щоб закріпити його як Custom Mode
У Grok @Bot встановіть плагін, потім введіть /poteto-mode.
Ви також можете використовувати pstack у Grok Bot!
Приклад: Створення нових функцій
Для створення нових функцій я зазвичай використовую навичку верифікації разом із /poteto-mode, щоб агент перевіряв свою роботу. Наприклад, я можу дати такий запит:
/poteto-mode build <опис функції, будь-який корисний контекст>. використовуй /control-app, щоб перевірити свої зміни та покажи мені відео та скріншоти як доказ
Де /control-app є результатом /create-verification-skill. У Grok @Bot я б дав такий запит:
spawn a cloud agent to use /poteto-mode to build <опис функції, будь-який корисний контекст>. використовуй /control-app, щоб перевірити свої зміни та покажи мені відео та скріншоти як доказ
Невелика відмінність тут полягає в тому, що в Grok @Bot ви кажете своєму боту створити cloud agent замість того, щоб виконувати роботу самостійно. Основна причина, чому я віддаю перевагу цьому, полягає в тому, що це звільняє вашого бота для інших справ і підтримує його контекстне вікно чистим. У цьому сенсі я сприймаю своїх ботів більше як координаторів, які керують cloud agents і контролюють їх. Cloud agents також означають, що ви можете скористатися повним набором моделей, доступних у Cursor, які мають власну окрему машину, тому комп'ютер вашого бота залишається вільним для інших речей.
Приклад: Робота з продуктивністю
spawn a cloud agent to use /poteto-mode to improve the initial loading time of our app. спочатку використовуй /control-app, щоб зняти профіль поточного стану та визначити можливості для покращення. потім зроби цілеспрямоване виправлення та використовуй /control-app +
/swarm щоб підтвердити результат
/swarm — одна з найкращих навичок для поєднання з вашою навичкою верифікації. Вона розгортає будь-яку кількість cloud agents для запуску вашої навички верифікації, тому ви можете робити такі речі, як підтвердження виграшу в продуктивності з достатньо великим розміром вибірки або фаззинг вашого додатку, щоб переконатися, що ви нічого не зламали та не регресували.
Приклад: Автоматичне відтворення звітів користувачів
Коли ви будете задоволені своєю навичкою верифікації, ви можете помістити їх у рутини Grok @Bot або Cursor Automations. Рутини та автоматизації дозволяють запускати речі за розкладом або тригером, коли відбувається якась подія.
Наприклад, якщо ви направляєте відгуки користувачів у Slack та/або маєте власний внутрішній канал зворотного зв'язку, ви можете налаштувати своїх ботів слухати кожен звіт і автоматично намагатися відтворити їх за допомогою cloud agent. Якщо ваша навичка верифікації та Feature Map досить хороші, ви навіть можете потім вирішити автоматично виправляти проблеми.
Ось чому я раніше сказав, що верифікація є однією з найважливіших навичок у вашому арсеналі. Вона дає вам основу для створення нових навичок і рутин на її основі. І, що найважливіше, від цього виграє вся ваша команда.
Інвестуйте у свою навичку верифікації
Після того, як ви створили свою навичку верифікації, підтримуйте її в гостроті за допомогою /maintain-verification-skill. Продовжуйте вдосконалювати CLI та інвестуйте в навичку, як у критичну інфраструктуру. Ви навіть можете захотіти встановити для неї чергування чергувань (oncall rotation) — ось наскільки це важливо для розблокування 100-1000-кратної продуктивності вашої команди.
Ця навичка є основою для багатьох інших навичок, які ми розглянемо в посібнику pstack, і чудово поєднується з усіма ними.
- pstack: https://x.ai/bot/plugin/9717366 (посилання на github
- Dr Eggbot: https://x.ai/bot/93gOz3op1UQdBdbekQFLK
Я рекомендую додати Dr Eggbot, мого бота, який допомагає створювати високоякісних ботів, до вашого списку. Dr Eggbot постачається з pstack. Він навчить ботів для кодування, як ним користуватися, а також може створювати ботів, які не кодують, з такою ж ретельністю.
Ви можете попросити Dr Eggbot створити для вас бота-інженера, якого потім попросите запустити /create-verification-skill і налаштувати щоденну рутину для запуску /maintain-verification-skill.
Дякую за читання та слідкуйте за Частиною 2!
