Разборы · Статья: · Видео: · 44 мин

Почему AI-агент ломает уже работающий код — и как это чинит проектная документация (ТЗ)

Разбор Alexey Andreevsky: почему вайбкод-приложения разваливаются при росте не из-за слабой модели, а из-за отсутствия «карты проекта». Как написать ТЗ-документацию для AI-агента, разбить её по файлам с оглавлениями, задать user stories с критериями готовности, собрать Roadmap и правилами Cursor заставить агента ей следовать.

ИИ Программирование Продуктивность
Смотреть на YouTube

Почему твоё ВАЙБКОД-приложение разваливается на 3-й день (и как это починить навсегда)

Alexey Andreevsky · 44 мин
Главы видео — нажми, чтобы перейти к моменту 9
  1. 0:00 Почему вайбкод-приложения ломаются на третий день Знакомая боль: чинишь одно — ломается другое, добавляешь фичу — отваливается старая.
  2. 1:42 Две причины поломок: забитый контекст и потерянные связи Нейронка забывает указания в переполненном чате и не замечает, что правит компонент, используемый в других местах.
  3. 3:45 Визуализация: как агент рвёт связи в большом проекте На схеме видно, как при пяти связях фикс формы «роняет» вход, профиль, список и уведомления.
  4. 6:18 Корень проблемы — у агента нет карты проекта Дело не в крутости модели, а в управлении ею: агенту нужно тезисное описание, что с чем связано.
  5. 7:03 ТЗ для агента ≠ подробный промт ТЗ — это файл, к которому агент возвращается; промт тонет в контексте, файл снижает галлюцинации.
  6. 13:42 Что писать в ТЗ: маркетинг и разработка Идея и ЦА — коротко; ядро — стек, экраны, дизайн, фичи, база данных, безопасность.
  7. 18:07 Экраны через ASCII-схемы, дизайн, фичи, база, безопасность Wireframe-схемы экранов, дизайн-система, user stories с критериями готовности, структура БД, требования безопасности.
  8. 30:26 Roadmap, оркестрация и тесты Из ТЗ собираем план по этапам, гоняем агента поэтапно, тесты ловят сломанные связи.
  9. 36:04 Как заставить агента читать документацию (правила Cursor) Папка с документацией + правила/скиллы, где она лежит и что ей нужно руководствоваться.

Коротко

Вайбкод-приложения разваливаются не из-за слабой модели, а потому что у агента нет карты проекта: он забывает детали в забитом контексте и не видит связи между частями кода. Лечение — заранее написать подробное ТЗ-документацию, разбить её по файлам с оглавлениями и правилами заставить агента всегда на неё опираться.

Выжимка голосом

Самое ценное из разбора — за пару минут

0:00 2:17
Показать текст выжимки
Если коротко, это разбор о том, почему вайбкод-приложение разваливается на третий день — и почему дело вовсе не в том, что модель «тупая». Настоящая причина в том, что у агента нет карты проекта. Отсюда две беды. Первая — забитый контекст: агент забывает ваши указания даже внутри одного чата, ведь контекстное окно похоже на письменный стол, заваленный кучей сообщений. Вторая — невидимые связи: правя один компонент, агент не знает, где ещё этот компонент используется, и, починив форму, роняет вход, профиль, список и уведомления. Лечится это не более дорогой моделью, а документацией. Идея простая: вынести знание о проекте из переписки в отдельное ТЗ — файл, к которому агент возвращается снова и снова. В отличие от подробного промта, который тонет в истории чата, файл лежит рядом, и агент в него подглядывает, поэтому реже галлюцинирует. Дальше — готовая структура, которую можно просто повторить. Технический стек, ASCII-схемы всех экранов, дизайн-система, фичи в виде user stories с критериями готовности и разделом «что мы НЕ делаем», база данных, описанная своими словами, и отдельный блок про безопасность. Ключевой приём — не сваливать всё в один файл, иначе агент переполнит контекст, а дробить по папкам с README-оглавлениями, чтобы он подгружал только нужный узел. Из готового ТЗ агент собирает Roadmap по этапам, а правила Cursor или скиллы заставляют его всегда сверяться с документацией. Честная оговорка: метод не чинит поломки «навсегда», как обещает название. Это снижение риска, а не гарантия — руками всё равно приходится прокликивать. И тяжёлое ТЗ до старта близко к водопаду: для проектов с неясными требованиями оно может устареть раньше, чем пригодится. Но вывод важнее частностей: самый сложный этап теперь — не писать код, а чётко описать задачу. Кодинг дешевеет, а умение думать структурно — дорожает.

Озвучено синтезом речи · голос alena

Объясни проще

Суть без жаргона

Простыми словами

AI-агент ломает уже работающий код по двум причинам: при длинной переписке у него забивается контекст и он забывает ваши указания, а в большом проекте он не видит, что правит компонент, который используется и в других местах. Автор предлагает лечение: до старта проекта написать подробную документацию (техническое задание) — идея, стек, схемы экранов, дизайн, фичи, база данных, безопасность — разбить её по файлам с оглавлениями и правилами заставить агента всегда с ней сверяться.

Как ребёнку

Представь, что ты строишь замок из лего, а помощник каждый вечер достраивает по памяти. Через пару дней он ставит новую башню и случайно ломает мост, который вы сделали вчера, потому что не помнит, как всё соединено. Дай ему нарисованную инструкцию — что с чем скреплено — и он перестанет ломать готовое.

Аналогия — «это как…»

Техническое задание — это как чертёж дома для бригады. Без чертежа строители каждый раз достраивают по памяти и сносят стену, которую возвели вчера; с чертежом любой новый рабочий видит, где несущая стена и где проводка, и не рушит соседнее.

Зачем это мне

Как только проект перерастает уровень «тудушки на пару промтов», вайбкодинг без документации превращается в бесконечную починку того, что вчера работало. Это ровно та граница, которая отделяет «поиграл вечер» от «запустил продукт, которым пользуются живые люди».

Для тех, кто в теме

По сути это приземление context engineering: превратить одноразовый промт в персистентный, перелинкованный спек-слой, дроблённый по файлам с README-индексами, чтобы агент подгружал только релевантный узел вместо всей папки. Сверху — правила/скиллы, форсящие чтение доки, user stories с acceptance-критериями и явным out-of-scope, Roadmap с ссылками на файлы фич и тесты как регрессионный детектор порванных связей.

Оценка видео

Чем выше — тем больше пользы на минуту

4.2

средняя из 5

Актуальность информации 4.6

Контекст-инжиниринг и spec-driven разработка — горячая тема середины 2026, приёмы прямо применимы в Cursor и Claude Code сегодня.

Содержательность 4.2

Плотный практический разбор структуры ТЗ по разделам, хотя финал заметно уходит в рекламу авторского курса и повторы.

Практичность 4.5

Даёт конкретную структуру документации и порядок действий, который можно повторить на своём проекте почти без адаптации.

Доступность изложения 4.3

Простым языком, с наглядными аналогиями (заваленный стол, визуализация связей) — понятно даже новичку-вайбкодеру.

Инновационность идей 3.3

Сами идеи (spec-driven, context engineering) не новые; ценность в систематизации и приземлении под вайбкодинг, а не в открытии.

Кому будет полезно

Чем выше оценка — тем больше пользы для профессии. Разверни — почему.

Для вайбкодеров 5 /5

Прямое попадание: весь ролик отвечает на их главную боль — как перестать чинить приложение, которое ломается при каждой доработке.

Для продакт-билдеров и no-code-основателей 4.6 /5

Даёт структуру ТЗ, по которой можно собрать серьёзный продукт через агента, не умея кодить руками.

Для программистов, работающих с AI-агентами 4.2 /5

Систематизирует context engineering: как дробить доку по файлам, перелинковывать связи и правилами форсить её чтение.

Для стартаперов и индихакеров 3.8 /5

Показывает, как довести MVP до стадии «им пользуются люди» без развала кода, но не покрывает деплой, монетизацию и рост.

Для продакт-менеджеров 3.4 /5

Формат user stories с критериями готовности и явным «что НЕ делаем» полезен для постановки задач агенту и команде.

Инсайты

Нажми, чтобы раскрыть — то, что меняет взгляд на тему

01 Проблема не в модели, а в управлении ею 6:18

Соблазн лечить поломки покупкой модели помощнее обманчив. Даже сильная модель в большом проекте не видит всех связей — корень в том, что у агента нет карты проекта, а не в том, что он «тупой».

02 Контекст забивается даже внутри одного чата 1:50

Распространённое заблуждение — что агент помнит всё, пока не вышел за лимит окна. На деле уже забитый контекст (как заваленный стол) заставляет его терять указания из начала и середины переписки.

03 ТЗ — это кэш, а не просто «промт получше» 7:03

Ключевое различие: подробный промт со временем тонет в истории чата, а файл-документация лежит рядом, и агент в него подглядывает — вероятность галлюцинации падает. Технически похоже, по надёжности — нет.

04 Сама документация должна быть контекст-оптимизированной 9:13

Мало написать ТЗ — его дробят по файлам с README-оглавлениями. Агент грузит не всю папку, а только нужный узел: это экономит контекст без потери информации о связях.

05 Тесты — детектор порванных связей 33:34

Упавший старый тест — сигнал, что новый код сломал то, что уже работало. В связке с документацией, где описаны связи, это даёт быстрый способ поймать регрессию, а не обнаружить её у пользователя.

Ключевые цитаты

Сильные фразы из видео — нажми тайм-код, чтобы услышать в оригинале

«Контекстное окно чата можно сравнить с письменным столом, если он завален кучей промтов и сообщений.»
Почему агент забывает указания даже в пределах одного чата. 1:50
«Так вот, корень проблемы здесь не в крутости модели, а в управлении этой моделью.»
Главный тезис: поломки лечатся не сменой модели, а картой проекта. 6:13
«Как говорится, без ТЗ результат хз.»
Про необходимость чётко описывать требования, чтобы агент не домысливал. 9:04
«Самый сложный этап вайпкодинга на текущий момент — это чётко и структурированно описать вот это техническое задание в документации.»
Где на самом деле лежит основная работа при разработке с агентами. 34:09
«Главное это всё в один файл не пихать, потому что вот если мы это всё в один файл засунем, вот тогда и агент реально офигеет, у него контекст переполнится.»
Почему документацию дробят по файлам с оглавлениями. 35:40
«Само написание документации достаточно муторный процесс, долгий, всегда очень в падлу им заниматься. Но когда документация написана, начинается самый кайф вайп-кодинга.»
Честное признание: сначала нудно, зато потом разработка идёт легко. 32:24

Полезные советы

Что можно применить уже сегодня. Разверни совет — сколько займёт, что даст и что конкретно делать

1

Напиши ТЗ до первой строчки кода

вечер агент перестанет ломать рабочий код при каждой доработке

Начинай проект не с «создай мне приложение», а с описания: идея, ЦА, стек, экраны, фичи, база, безопасность. Пиши это не руками, а вместе с агентом.

Что делать

  1. 1 Создай в проекте отдельную папку под документацию (например, ai-docs).
  2. 2 Промтами попроси агента описать идею проекта и целевую аудиторию с её болью.
  3. 3 Обсуди с агентом технический стек до старта — язык, фреймворки, библиотеки.
  4. 4 Только после этого переходи к написанию кода по документации.
2

Раздроби документацию по файлам с оглавлениями

полчаса агент грузит только нужный раздел — контекст не переполняется

Не сваливай всё в один файл: агент «офигеет» и переполнит контекст. Разбей по папкам (маркетинг, разработка, экраны, дизайн, фичи, база) и в корень каждой положи README с содержанием.

Что делать

  1. 1 Разбей документацию на тематические папки.
  2. 2 В корне и в каждой папке заведи README со списком того, что внутри.
  3. 3 На вход агенту давай сначала файлы-оглавления, а не всю папку.
  4. 4 Проверь, что по цепочке README агент находит нужный файл.
3

Опиши экраны ASCII-схемами (wireframes)

1-2 часа на проект страницы собираются быстрее, а ты сам проясняешь, как устроено приложение

Для каждого экрана нарисуй символьную схему секций: навигация, hero, проблема, преимущества, тарифы, FAQ. Пока рисуешь — в голове складывается структура всего приложения.

Что делать

  1. 1 Заведи файл-wireframe на каждый экран (лендинг, дэшборд, настройки, оплата).
  2. 2 Сверху коротко укажи ЦА и боль, ниже — ASCII-схему секций.
  3. 3 Опиши, что должно быть написано в каждой секции.
4

Формулируй фичи как user stories с критериями готовности

15 минут на фичу агент делает ровно то, что нужно, и не расползается за рамки задачи

Под каждую фичу — отдельный файл: логика работы + критерии готовности («в базе создана запись», «повторный вход не дублирует пользователя») + явный раздел «что мы НЕ делаем в этой фиче».

Что делать

  1. 1 Опиши пошаговую логику фичи глазами пользователя.
  2. 2 Добавь список критериев готовности — что точно должно работать.
  3. 3 Добавь раздел «вне рамок» — что в этой фиче НЕ реализуем.
5

Пропиши раздел безопасности

вечер приложение не свалится ночью и не пустит злоумышленника через форму

Отдельный файл с требованиями: хранение паролей и сессий, рейт-лимиты на восстановление пароля и попытки входа, валидация загрузок, защита от SQL-инъекций, а если в приложении есть агент — защита от промт-инъекций.

Что делать

  1. 1 Обсуди с нейронкой, какие угрозы актуальны именно для твоего случая.
  2. 2 Зафиксируй правила хранения паролей, сессий и доступа к данным.
  3. 3 Добавь рейт-лимиты и ограничение попыток ввода пароля.
  4. 4 Опиши валидацию входных данных и защиту от SQL/промт-инъекций.
6

Собери Roadmap по этапам со ссылками на файлы

полчаса разработка превращается в «делай этап 1, делай этап 2» без больших промтов

Скорми агенту готовое ТЗ и попроси составить план реализации с разбивкой на этапы, где каждая задача ссылается на свой файл-фичу.

Что делать

  1. 1 Дай агенту всю документацию и попроси roadmap с этапами.
  2. 2 Попроси под каждую задачу отдельный файл или ссылку на файл фичи.
  3. 3 Дальше просто говори «делай этап 1», затем «делай этап 2».
7

Заставь агента читать документацию через правила

20 минут агент сам сверяется с ТЗ в каждом новом чате, без ручных напоминаний

Папку с документацией агент видит, но по умолчанию не использует. В правилах Cursor (или скиллах другого агента) пропиши: где лежит документация, её структура и что ей обязательно нужно руководствоваться.

Что делать

  1. 1 Создай правило (rule) или скилл в своём агенте.
  2. 2 Укажи путь к папке документации и её структуру папок.
  3. 3 Пропиши: перед задачей смотреть нужный раздел и учитывать связи.
8

Давай задачи поэтапно и проверяй руками

постоянно контекст не забивается, а баги ловятся сразу, а не копятся

Без оркестрации не вываливай на агента весь план — он переполнит контекст и сделает не то. Давай по этапу, проверяй, что работает, и только потом следующий.

Что делать

  1. 1 Разбей работу на небольшие задачи или этапы.
  2. 2 После каждого этапа руками прокликай, что всё работает.
  3. 3 Добавь тесты: упавший старый тест сигналит о сломанной связи.

Сценарии применения

Как разные люди применяют это на практике

Я как Вайбкодер-новичок

Проблема: приложение, собранное за вечер, разваливается, как только начинаешь его дорабатывать

Хочу: понять, почему агент ломает готовое и как это остановить

Поможет: узнаёт, что нужна карта проекта — ТЗ-документация, и получает её пошаговую структуру

Я как Основатель без навыков кода

Проблема: хочет запустить SaaS, но не понимает, как через нейронку собрать что-то серьёзнее лендинга

Хочу: каркас, по которому агент соберёт полноценный продукт

Поможет: получает разбивку ТЗ на маркетинг и разработку с примерами каждого файла

Я как Фрилансер на Cursor

Проблема: переключает чаты, и агент каждый раз забывает, что за проект и как всё связано

Хочу: чтобы контекст проекта жил вне переписки

Поможет: учится выносить контекст в файлы и правилами заставлять агента их читать

Я как Продакт-менеджер

Проблема: ставит агенту задачу, а он домысливает пробелы неправильно

Хочу: формат, который не оставляет агенту простора для отсебятины

Поможет: берёт user stories с критериями готовности и явным out-of-scope под каждую фичу

Я как Джуниор-разработчик

Проблема: не умеет проектировать базу данных и боится сломать связи в растущем коде

Хочу: способ описать данные и связи, не будучи архитектором

Поможет: видит, что БД можно описать словами вместе с агентом, а тесты ловят регрессии

Я как Разработчик, думающий о безопасности

Проблема: вайбкод-приложения часто уязвимы: нет рейт-лимитов, валидации, защиты форм

Хочу: чеклист требований безопасности для агента

Поможет: получает список: пароли, сессии, рейт-лимиты, валидация, SQL- и промт-инъекции

Логика повествования

Как устроена аргументация видео — пройди по шагам

Предпосылка Аргумент Пример Вывод
  1. Предпосылка Вайбкод-приложения ломаются при росте 0:00

    Чинишь одно — отваливается другое; добавляешь фичу — ломается старая. Знакомая боль вайбкодеров.

  2. Аргумент Две причины: забитый контекст и незамеченные связи 1:42

    Агент забывает указания в переполненном чате и не видит, что правит компонент, используемый в других местах.

  3. Пример Наглядно: фикс формы роняет вход, профиль, список 3:45

    Визуализация показывает, как при множестве связей агент учитывает не все и рушит соседнее.

  4. Аргумент Корень — нет карты проекта, а не слабая модель 6:18

    Проблема в управлении моделью: ей нужно тезисное описание того, что с чем связано.

  5. Аргумент Решение — ТЗ-документация, к которой агент возвращается 7:03

    Файл снижает галлюцинации сильнее, чем подробный промт, который тонет в контексте.

  6. Аргумент Доку дробим по файлам и перелинковываем связи 9:13

    README-оглавления экономят контекст, ссылки между файлами воссоздают карту связей.

  7. Пример Что писать: стек, экраны, дизайн, фичи, база, безопасность 13:42

    Раздел разработки — ядро ТЗ; фичи через user stories с критериями готовности.

  8. Вывод Roadmap + правила + этапность = вайбкодинг «с кайфом» 30:26

    Из ТЗ собирается план по этапам, правила форсят чтение доки, тесты ловят регрессии.

Подробный разбор

Полный разбор — разверни, если нужно глубже

Развернуть подробный разбор

Что реально забрать из видео

Главная мысль ролика короче его названия: вайбкод-приложение ломается не потому, что модель «тупая», а потому что у агента нет карты проекта. Две конкретные причины — забитый контекст (агент забывает указания даже внутри одного чата) и невидимые связи (правя один компонент, он не знает, где ещё тот используется). Оба лечатся одним и тем же: вынести знание о проекте из переписки в документацию, к которой агент возвращается.

Практическая часть — это готовая структура ТЗ, которую стоит просто повторить. Автор делит документацию на маркетинг (идея, ЦА и её боль — коротко) и разработку (ядро): технический стек, ASCII-схемы всех экранов, дизайн-система, фичи как user stories с критериями готовности и разделом «что НЕ делаем», структура базы данных своими словами и отдельный блок безопасности. Ключевой приём — не сваливать это в один файл, а дробить по папкам с README-оглавлениями и перелинковывать связанные файлы: так агент подгружает только нужный узел и не переполняет контекст. Из готового ТЗ агент собирает Roadmap по этапам, а правила Cursor (или скиллы в другом агенте) заставляют его всегда сверяться с документацией.

Честный нюанс, который автор не прячет: написание документации — «муторный и долгий» этап, зато после него вайбкодинг превращается в «делай этап 1, делай этап 2». Стоит держать в голове и то, что метод не отменяет ручную проверку и не чинит поломки «навсегда» — это снижение риска, а не гарантия. Но как база для любого проекта серьёзнее тудушки подход рабочий и переносимый на любой AI-инструмент, а не только на Cursor.

План внедрения

С чего начать — отмечай шаги, прогресс сохранится

Выполнено 0 из 10

Проверь себя

Ответь на вопросы, чтобы материал закрепился

Отвечено: 0 / 6 Верно: 0

  1. 1. Какая главная причина, по которой вайбкод-приложение ломается при росте?

  2. 2. Чем ТЗ-документация принципиально отличается от подробного промта?

  3. 3. Зачем документацию дробят на много файлов с README-оглавлениями?

  4. 4. Что добавляют в user story «для агента» помимо описания логики фичи?

  5. 5. Как заставить агента реально пользоваться документацией?

  6. 6. Какую роль в этой схеме играют тесты?

Словарь терминов

Понять незнакомое простым языком

Показать 13 терминов
Вайб-кодинг (vibe coding)
Разработка приложений через AI-агента: вы описываете, что нужно, промтами, а код пишет нейросеть, а не вы руками.
ТЗ / спека (техническое задание, spec)
Документ (набор файлов) с требованиями к проекту, к которому агент возвращается снова и снова, вместо того чтобы каждый раз объяснять всё промтом.
Контекстное окно
Объём текста (переписки, файлов), который нейросеть держит «в голове» одновременно. Чем оно забитее, тем хуже агент помнит детали.
Контекст-инжиниринг
Управление тем, что и в каком виде попадает в контекст агента, чтобы он работал точнее. Следующий шаг после «просто вайб-кодинга».
Карта проекта
Тезисное описание, что с чем связано в приложении. Без неё агент, правя один компонент, ломает связанные с ним.
User story
Описание фичи глазами пользователя («как гость, я хочу войти через Telegram, чтобы...»). Для агента дополняется критериями готовности и границами.
Критерии готовности
Список условий, при которых фича считается сделанной («в базе создана запись», «повторный вход не создаёт дубликат»).
ASCII-визуализация / wireframe
Схема экрана символами: где навигация, hero, тарифы, FAQ. Фиксирует структуру страницы до написания кода.
Roadmap
План реализации проекта, разбитый на этапы, где каждая задача ссылается на свой файл-описание. По нему агента «гоняют» шаг за шагом.
Оркестрация агентов
Схема, где главный агент-оркестратор поочерёдно вызывает субагентов на мелкие задачи, а агенты-ревьюеры проверяют код и пишут тесты.
Правила Cursor (rules)
Инструкции, которые автоматически подключаются в каждом чате и заставляют агента следовать документации. В агентах без правил их роль играют скиллы.
SQL-инъекция
Атака, когда злоумышленник вписывает в поле ввода SQL-запрос, и тот выполняется в вашей базе. Защита — валидация и экранирование ввода.
Промт-инъекция
Атака на встроенного в приложение агента: пользователь подсовывает текст-команду, чтобы агент сделал не то, что задумано.

Критический взгляд

Объективно: с какими тезисами можно поспорить и что преувеличено

Преувеличение

«...и как это починить навсегда» — обещание в названии сильнее, чем даёт метод

Документация резко снижает частоту поломок, но не устраняет их «навсегда»: агент всё равно может не уловить связь, а сам автор в конце признаёт, что руками всё равно приходится всё прокликивать.

Может устареть

Цифра «в 66% случаев агент делает почти правильно» подана как факт

Автор сам оговаривается, что источник, похоже, из 2023 года и данные устаревшие, но цифра всё равно звучит как аргумент. К конкретным процентам стоит относиться как к иллюстрации, а не измерению.

Однобоко

Подход близок к «водопаду»: всё ТЗ до старта

Для проектов с неясными требованиями тяжёлое ТЗ заранее может устареть раньше, чем пригодится. Итеративный путь — минимальная спека плюс уточнение по ходу — иногда экономичнее, чем описать всё вперёд.

Упрощение

Документацию предлагается писать самим агентом — и сразу считать её фундаментом

Если агент галлюцинирует в промтах, он может галлюцинировать и в спеке. «Мусор на входе — мусор на выходе»: агентские файлы ТЗ всё равно требуют человеческой вычитки, о чём в ролике сказано мельком.

Однобоко

Много внимания уделено Cursor как эталону

Механика «правил» показана в основном на Cursor; в других агентах (Claude Code, Windsurf) устройство скиллов и авто-подгрузки контекста отличается, и рецепт нужно адаптировать, а не копировать один в один.

Взгляни иначе

Новый угол, смежные области и потенциал на стыке — пища для размышлений

Другой угол

Спека — это не про AI, это про онбординг

Та же «карта проекта» решает боль любого нового человека в команде: перелинкованная документация, которая объясняет, что с чем связано, ускоряет и джуна, и агента одинаково.

На стыке областей

README-оглавления — это библиотечное дело

Дробление доки по файлам с индексами и перелинковкой — ровно то, чем веками занимается информационная архитектура: каталог, рубрикатор, ссылки. Вайбкодинг переоткрывает библиотеку.

Смежная область

Тесты как контракт, а не как проверка

Если смотреть на тесты как на исполняемое ТЗ («что система обязана делать»), они становятся тем же, чем типы и CI: машиночитаемой частью спеки, которую агент не может незаметно нарушить.

Смежная область

ASCII-wireframe полезен и людям

Символьная схема экрана — отличный бриф не только агенту, но и живому дизайнеру или заказчику: она заставляет договориться о секциях страницы раньше, чем нарисован первый пиксель.

Другой угол

Узкое место сместилось с кода на постановку задачи

Раз самый сложный этап теперь — не писать код, а чётко описать требования, ценность разработчика смещается к системному анализу и декомпозиции. Кодинг дешевеет, «умение думать структурно» дорожает.

Похожие разборы

Разбор

Многоагентный вайб-кодинг: пошаговый workflow от идеи до продакшена

Автор показывает свой процесс вайб-кодинга: главный навык — не писать код, а оркестрировать рой агентов, масштабируя их число и планы под сложность задачи. За одно видео он вживую собирает полный стек (база, API, AWS, Discord-авторизация), но половина «обязательных инструментов» — его же платные продукты.

Читать → Разбор

Agent loops, goals и расписания в Claude Code и Codex: рабочий процесс без хайпа

Оуайн Льюис раскладывает четыре примитива работы с ИИ-агентами — prompt, goal, /loop и schedule — и показывает, где они реально экономят время, а не жгут токены. Главная идея: относись к агенту как к сотруднику — дай цель и критерий успеха вместо микроменеджмента и автоматизируй рутину, где цена ошибки управляема.

Читать → Разбор

Agentic-инженерия по Мэтту Пококу: почему «обвязка» важнее модели, а стратегия — важнее кода

Мэтт Покок объясняет свой рабочий процесс с ИИ-агентами: все смотрят на модель, но выигрывает «обвязка» вокруг неё — промпты, скиллы, кодовая база и режим AFK, а тактическое программирование ИИ уже забрал себе. Главный вывод: твои навыки и стратегическое мышление — это потолок того, что ИИ сделает за тебя, поэтому вкладываться нужно в них, а не в погоню за самой новой моделью.

Читать → Разбор

Loop Engineering: как перестать быть оператором LLM и начать проектировать циклы

Если ты общаешься с агентом больше, чем принимаешь инженерные решения, ты превратился из инженера в оператора LLM — и упёрся в потолок ручного промтинга. Loop Engineering предлагает проектировать не отдельный промт, а цикл вокруг модели: с внешней памятью, изоляцией, независимым чекером, измеримым контрактом и лимитами — но внедрять его по нарастающей, оставляя финальную ответственность на человеке.

Читать →
← Все разборы Смотреть видео-источник