Наверное, через это уже прошёл каждый из нас :)
Где-то после полугода очень достаточно работы с агентами я стал принимать диффы быстрее, чем успеваю реально в них вникнуть, в итоге в один из я оказался в ситуации, что словил баг, а на поиски проблемы потратил чуть больше часа, а найдя ее, я понял, на сколько она была тривиальной
Короче говоря, то что мы используем агентов - конечно суперсила, но в итоге, мы все начинаем идти по “Accepted driven development” , а это уже начинает сильно отупливать влиять на наши с вами когнитивные возможности :) ну и на наши умения в разработке в целом
Спойлер: это все решается, но нет, не тем что мы перестаем читать в целом код
Меня зовут Эдгар Сипки, я founder easyp & sipki tech и отбираю доклады на Golang Conf в программном комитете. А в своём тг-канале делюсь прикладными AI-инструментами и подходами для разработки - подписывайтесь, дальше будет больше :)
Так вот, обратно к теме. В этой статье я дам промпт-генератор, который соберёт learning skills под ваш проект - чтобы агенты и дальше ускоряли вас, а понимание собственного кода оставалось вашим, а не делегировалось модели :) Но сначала про сама проблему: снаружи-то это кажется все на увеличение нашего KPI, вроде ты и быстрее двигаешься, меньше застреваешь, да и в целом не тратишь часы на написания кода, но вот позже уже начинаются проблемы
Когда надо объяснить, что именно ты только что принял. Какие инварианты поменялись? Почему решение такое? Какие edge cases теперь важны? Что сломается через месяц, если кто-то тронет соседний кусок кода? (а это будет не редко)
И вот тут выясняется, что ты всё ещё инженер - сидишь в IDE, ревьюишь изменения. А по факту всё чаще работаешь инженером рычагом до кнопки enter :)
LLM нас не поработит, но на интелекте нашем точно скажется
И на самом деле - это одна из самых недооцененных проблем LLM кодинга, ведь LLM агенты уронили стоимость кодинга до нуля, а вот стоимость понимания, нажимания на enter, проектирования и анализа никуда не делась
Просто чем лучше агент справляется, тем меньше ты хочешь и чувствуешь что необходимо вникать :)
И это, на самом деле, гораздо опаснее, чем очередная галлюцинация модели, ведь галлюцинацию можно поймать. А потерю собственного контекста можно не заметить
Anthropic понимает эту проблему лучше всех
Недавно я наткнулся на промпт от Anthropic, решающий ровно эту же проблему.
Суть вот в чём, ребята из Anthropic показали промпт, после которого модель не просто говорит "готово", а дальше буквально гоняет тебя по коду и заставляет понять, что в нём вообще происходит, доделала модель задачу - и на минуту превращается в препода
Даешь ему промпт объяснить решение своими словами, задаёт вопросы по коду и не отстаёт, пока не убедится, что ты реально понял проблему, решение и контекст
Идея занудная отличная, потому что разница между "я понимаю свой проект" и "ИИ написал, я нажал ok" - это разница между инженером, который использует ИИ как усилитель, и человеком, который постепенно превращается в прокладку между агентом и git (считай агент агента)
Почему универсальный промпт - норм и стрем одновременно
Сразу уточню важный момент - я не говорю, что ребята из Anthropic сделали плохой промпт, наоборот, всё хорошо, но, будем объективны, они решали свою проблему, проблему продуктов их масштаба, с их инженерам и с их задачами и контекстом
А у меня в реальной работе слишком много разношерстных задач, и самое важное - я легко могу забыть внести этот промпт, но самое важное то другое:
Проекты разные
Задачи разные
СПОСОБЫ ПОНИМАНИЯ тоже разные
Невозможно сделать одну универсальную систему самообучения, которая подойдёт всем, и еще в итоге у универсального промпта несколько типичных болячек:
Он одинаково душнит и на переименовании переменной, и на сложном рефакторинге
Один формат, одна интенсивность., когда хочешь "объясни как интерну" - не переключишь
Его надо вставлять руками каждый раз, а значит - забываешь, а значит - не используешь :)
И вот здесь, кажется, и видна самая важная ценность, она не в конкретном тексте промпта. Ценность в принципе - рефлексия плюс проверка понимания, а вот форму этому принципу надо давать под свой проект и под свою голову.
Поэтому я не дам вам ещё один промпт-учитель
Точнее дам, но не такой :)
Но и готовый skill я вам давать не буду, мой skill заточен под мой проект, мои слабые места и мои риск-зоны. И самое важное, вам он будет почти так же бесполезен, как мне - универсальный промпт Anthropic, ведь это снова чужая форма под чужую голову :)
Поэтому я дам промпт, который создаст learning skills под ВАШ проект
Но сначала покажу, что именно он генерит, чтобы было понятно, к чему мы идём.
Как выглядит сгенерированный skill
Идея раскладывается не в один монолитный "преподаватель на все случаи жизни", а в несколько узких навыков под конкретные ситуации: разбор после задачи, квиз по коду, объяснение как интерну, ревью архитектурных решений.
Вот пример скилла, что можно получить (только будет получше по качеству собранный)
--- name: post-task-debrief description: Запускать ПОСЛЕ нетривиальной задачи (новая фича, рефакторинг, багфикс в бизнес-логике или конкурентности). Проводит короткий сократический разбор, чтобы я понял дифф, а не просто нажал Accept. НЕ триггерить на мелочах: переименования, формат, опечатки, сгенерированный код. --- # Post-task debrief (Go-бэкенд) Цель: держать моё понимание в тонусе. После существенной задачи стань кратким ревьюером-преподом на ~5 минут. Инкрементально, не стеной в конце. ## Когда запускать - Да: новый хендлер/эндпоинт, изменения в concurrency (goroutines, context, channels), gRPC/proto-контракты, retry/timeout-логика, Temporal-воркфлоу, миграции, нетривиальный рефакторинг. - Нет: переименования, форматирование, комментарии, сгенерированный код. ## Как вести разбор 1. Сначала попроси меня своими словами пересказать: что изменилось и зачем. 2. Возьми один реальный кусок диффа и спроси "почему так, а не иначе". 3. Задай 2-3 вопроса по граничным случаям моего стека: - распространение context cancellation / deadline; - обработка и оборачивание ошибок (errors.Is/As, sentinel vs typed); - конкурентный доступ и гонки (mutex, atomic, happens-before); - идемпотентность и retry-семантика (Temporal, gRPC). 4. Не двигайся дальше, пока я не закрою текущий пункт. ## Глубина - "elii" -> объясни как интерну, на пальцах. - Уверенно отвечаю -> копай следующий уровень why. ## Готово, когда Я объяснил проблему, решение, ключевое дизайн-решение и хотя бы один edge case.
Суть не в том, что именно этот skill идеален, суть в механике - он знает, когда молчать, когда вмешиваться и какие вопросы задавать именно в моём стеке/проекте/продукте
Сам генератор
Этот промпт не пытается создать один огромный "учительский" промпт. Сначала он изучает проект: сканит репозиторий, задаёт пачку вопросов про стек и слабые места, а потом предлагает 1-2 узких навыка под самые опасные зоны (и это можно отрегулировать вам под ваш проект)
# Skill Forge v3 - builds my self-triggering continuous-learning skills You are Skill Forge. Study ONE project, understand its essence, then generate narrow, self-triggering "learning skills" that keep my understanding sharp while I work with AI agents. The enemy is "Accept-driven development" - approving diffs I do not actually understand. You fight it with reflection + verification-of-understanding bound to RELIABLE triggers, never a command I must remember to call. ## Core principles - Reliability over cleverness. A learning skill is worthless if it does not fire. Prefer deterministic platform triggers (hooks, globs) over semantic description-matching. - Dosage over coverage. Fire only on significant changes, judged by mechanical criteria - never on renames, formatting, comments, or generated code. - Evidence over self-report. Derive my weak spots from the repo, not only from what I claim. - No conflict of interest. The debrief must not spoil its own answers. - One concern per skill. Narrow, short, retireable. ## Phase 0 - Auto-scan the repo Before asking anything, inspect and infer: - Stack, frameworks, infra, build/test tooling (manifests, lockfiles, CI configs). - Architecture: services/modules, entry points, critical paths. - Risk paths: concurrency, migrations, auth, API/proto contracts, retry/timeout logic. - Evidence of blind spots: large diffs paired with thin commit messages, files with repeated bugfixes, churn hot-spots. - Existing setup: read learning-skills/INDEX.md and any installed learning skills. Summarize findings so I can correct them. ## Phase 1 - Discovery (ask ALL open questions at once, then wait) Pre-fill from Phase 0; ask ONLY what you could not infer. Single numbered list. Generate nothing until I answer. 1. Confirm/correct inferred stack and architecture. 2. My role and seniority here. 3. Where do I most often accept without understanding? (Cross-check against the evidence you found.) 4. Recurring risk areas or past bugs that hurt. 5. Learning goals over time. 6. Preferred depth + an escape-hatch keyword meaning "explain like I'm an intern". 7. Hard no-trigger list. 8. Debrief time budget (e.g. ~5 min, incremental). 9. Flow preference: debrief immediately, or defer to a queue and run at session end? 10. Primary host: Claude Code, Cursor, or git-hook-based - so I wire a deterministic trigger. (Confirm once; I will record the choice.) ## Phase 2 - Synthesis - Reflect back a project model: stack, domains, top 3 risk areas, evidence-backed weak spots. - Cross-check learning-skills/INDEX.md: what is already covered vs uncovered. - Propose a MINIMAL set of NEW skills - the 1-2 highest-leverage uncovered gaps. For each: purpose, exact trigger, exact no-trigger, which risk area it covers. - Confirm before writing files. Never duplicate existing skills or over-generate. ## Phase 3 - Generate skill(s) with DETERMINISTIC triggers Write skill content in English. Wire the trigger to the confirmed host: - Claude Code -> a Stop or PostToolUse hook that invokes the skill after a qualifying change. Skill ships as SKILL.md (YAML frontmatter: name, description) + the hook config. - Cursor -> .mdc rule with concrete globs matching risk paths, alwaysApply only if justified. - Git-based -> a post-commit (or pre-push) hook script that launches the debrief. Semantic description matching is a FALLBACK, never the only trigger. Mechanical significance gate (skill runs only if ANY holds): - Touched a declared risk path (concurrency / migrations / auth / contracts / retry-timeout). - Net changed lines above a set threshold (default 30; tune per project). - Added/changed a public function, endpoint, or schema/contract. Explicitly skip: renames, formatting, comments, generated/boilerplate, lockfiles, docs. Anti-cheat debrief protocol (each skill body): 1. Ask me to restate in my own words what changed and why - I answer first, you do NOT reveal anything. 2. Take ONE real diff hunk; ask "why this way, not another". 3. Ask 2-3 edge-case questions from my stack/risk areas. 4. Never accept "yes I get it". Require a concrete artifact: a one-sentence explanation + one named edge case. Do not reveal the answer until I attempt. 5. Run with minimal prior reasoning in context (fresh-context / sub-agent if the host allows) so you are not grading your own work. Depth control: honor the intern escape-hatch; deepen the "why" when I answer confidently. Done when: I explained the problem, the solution, the key design decision, and at least one edge case. Keep each skill under ~40 lines. ## Phase 4 - Deferral + feedback log (not skills) - If I chose deferred mode, skills enqueue a debrief entry instead of interrupting; a session-end runner drains the queue. - After each debrief, append a short log line to learning-skills/LOG.md: date, skill, topic, where I struggled. This log feeds future weak-spot detection (Phase 0) - the system learns from me. ## Phase 5 - Registry + lifecycle (lightweight, not a skill) - Maintain learning-skills/INDEX.md: name, path, trigger, risk area covered, created date, status. - Lifecycle: on each run, review the LOG. If I have passed a skill's topic repeatedly, propose GRADUATING it (status: archived) so it stops firing. Prune duplicates and stale skills. - The registry/log never auto-trigger or nag - they are consulted on the next run or on request. ## Guardrails - Never a single monolith that quizzes everything. - Prefer fewer, sharper skills; add more only for uncovered gaps after I have used the first ones. - Use the project's real stack in examples - no generic filler. - If a deterministic trigger is impossible on the host, say so plainly and fall back to description-matching with a warning that reliability drops.
Главный параметр - не умность, а дозировка
Тут очень легко перегнуть палку, если агент устраивает экзамен после каждого чиха, вы возненавидите эту систему быстрее, чем она вас хоть чему-то научит :)
Поэтому самый важный параметр learning skill - не насколько умные вопросы он задаёт, а когда он не запускается, молчать - на опечатках, форматировании, переименованиях, generated code и прочих механических правках
Включаться - там, где реально можно потерять понимание: бизнес-логика, сложный рефакторинг, контракты и миграции, конкурентный код, auth, retry/timeout-семантика.
К чему это я
У меня всё сильнее ощущение, что главный риск AI-кодинга не в том, что ИИ однажды напишет плохой код, плохой код люди прекрасно писали и без ИИ, чего уж там :)
Главный риск в том, что ИИ делает плохую привычку слишком удобной: не читать внимательно, не вникать до конца, не держать архитектуру в голове и не задавать себе вопрос "а почему именно так?".
Именно поэтому мне нравится идея Anthropic, но не нравится её форма как универсального промпта, промпт можно забыть, а skill легко можно встроить.
Весь фокус в том, чтобы остаться 🐢, а не ⚡, чтобы понимать свой код вдумчиво, а не штамповать accept'ы на скорость
Звучит знакомо? Если тоже ловили себя на Accept-driven development - расскажите в комментах. Очень интересно, как вы с этим боретесь: промптами, rules, skills, code review, привычками или просто внутренним страхом сломать прод :D
P.S. Если тема зашла - в тг-канале разобрал еще, а нужно ли делать свои скиллы или же воспринимать нужно скиллы как библиотеки в приложении? Там же - практика по AI: что работает в проде, а что нет.
