BlaNote

«анти-vibe-coding» Мне тут ChatGPT сказал, что я, оказывается, занимаюсь «анти-vibe-coding'ом». Методология SDD (Spec-Driven Development) - это не формальный стандарт вроде Scrum или TDD, а современный подход к разработке, который делает спецификацию центральным элементом всего процесса. По сути, это «анти-vibe-coding» подход: - Сначала - чётко формулируем, что и зачем мы делаем. - Потом - реализуем ровно то, что описано. - И проверяем, что результат соответствует спецификации. Суть SDD (Spec-Driven Development) можно описать формулой: | Спецификация - План - Реализация - Проверка соответствия В отличие от классического "code-driven" подхода, где код рождает документацию постфактум, здесь всё наоборот: - Спецификация задаёт направление. - Реализация служит доказательством. - Документация - не побочный продукт, а фундамент. Основные принципы. Specification First - любая фича начинается с текстовой (или формальной) спецификации - описания цели, сценариев, ограничений, допущений. Traceability - каждый кусок кода должен иметь соответствующую запись в спецификации. Это обеспечивает прозрачность и контроль изменений. Predictable Outcomes - мы формулируем, что считаем успешным результатом заранее. Код проверяется не просто на корректность, а на соответствие ожидаемому поведению. Iterative Refinement - спецификация не статична - её можно уточнять по мере исследования, но изменения должны быть осознанными и фиксироваться. Human-AI Co-development (новая черта) - в эпоху Copilot/ChatGPT спецификация становится интерфейсом не только между людьми, но и между человеком и ИИ-ассистентом: она описывает намерения, чтобы ИИ мог правильно генерировать код.

VibeCode. Как не назови все равно полетит Plain Text vs XML or Markdown: на чём писать промпты для ИИ-кодера? Структура — это новый язык общения с ИИ. Особенно когда дело касается кода. Есть миф: чтобы попросить ИИ написать код, достаточно набросать запрос в чат «как есть». Plain text, без правил. Сработает? Иногда. Будет эффективно? Редко. Почему ИИ «понимает» структурированный промпт (с тегами, отступами, чёткими блоками) лучше, чем простой текст? Читать далее habr.com/...794/

Инструкции, а не Вайб. К теме про процесс передачи инструкций Агенту. Вот очередное подтверждение: Задаю инструкцию по шагам о переходе с Basic Auth на JWT токен, агент пишет код, вношу правки на каждом этапе тестирую - все круто access_token работает, не круто refresh_token то же работает. - Генерация access и refresh токенов оказывается идентична: у них одинаковая подпись и нет отличительного признака (claim) типа токена. В итоге фильтр просто проверяет подпись/срок действия и принимает оба. - Аутентификация в фильтре проверяет только валидность и извлекает username, не различая тип токена. - Логика логина/рефреша генерирует два токена одним методом, без различий в claim’ах. - Сервис не добавляет claim о типе токена. Ожидаемое поведение в системе: API должны принимать ТОЛЬКО access_token. Refresh_token используется только для выпуска нового access_token и не должен авторизовать доступ к обычным защищенным эндпоинтам. Задаем задачу - Агент исправляет. Виноват ли ИИ, конечно нет. Это хороший пример - легкого вайба не получится. Все так же придется учить "базу"

"Не рви страницы" Когда мы работаем с искусственным интеллектом, важна последовательность текста. Модель учится не просто на отдельных словах, а на целой логике рассуждений. Это называется семантическая связность. Если хранить код отдельно от документации или подсовывать ИИ куски текста из разных мест (например, через RAG), он теряет нить и начинает хуже понимать. Это похоже на ситуацию, когда вы не даёте человеку книгу целиком, а вырываете из неё страницы и бросаете в руки - история уже не складывается. Даже маленькие ИИ могут быть очень сильными, если читать и генерировать текст последовательно. Код, комментарии и требования должны идти вместе - тогда ИИ активирует все "механизмы внимания" и работает намного лучше. Вывод: не дробите контент ради удобства. Для ИИ важна целостность текста, как для нас — сюжет книги.

Можно ли использовать артефакты ИИ в разработке? Когда мы даём задачу ИИ-агенту, он может оставить после себя не только код, но и артефакт — например, технический документ. Вот кусок такого документа: # Обработка ошибок в модуле Create ## Описание В модуле `create` реализована специализированная обработка ошибок для валидации создания постов. Обработка ошибок организована по модульному принципу и работает независимо от глобального обработчика. ## Структура ### Исключения - **`PostValidationException`** - базовое исключение для ошибок валидации постов - **`EmptyTextException`** - исключение для пустого или отсутствующего текста поста - **`InvalidCategoryException`** - исключение для недопустимых категорий ... Возникает вопрос: а можно ли использовать такие артефакты в последующей разработке/тестировании. "Скармливать" Агенту как контекст. Контролировать создание таких артефактов и встраивать в общий процесс разработки. Возможности здесь интересные: Документ может стать основой для других задач. Например, тестировщик получит готовый сценарий тестов, а аналитик - описание бизнес-правил. (Тут интереснее про тестировщик и аналитик как агенты) Такой артефакт можно встроить в пайплайн: использовать для автоматической генерации тестов, документации API или как контрольную точку при ревью. Если контролировать процесс генерации артефактов (например, задавать структуру документа и формат), то они будут стандартизированы и реально полезны для всей команды. Проблема в том, что без рамок артефакты могут быть слишком «размытыми»: ИИ может написать много текста, но без практической пользы. Поэтому ключевой вопрос - как встроить их в процесс так, чтобы они стали настоящим инструментом, а не побочным продуктом. Возможно, в будущем артефакты от ИИ станут обязательной частью разработки: код - это одно, а вот спецификации это и есть та ценность которая нам нужна, о чем и говорили ранее.

PromptOps: стандартизация промптов в команде В продолжение предыдущего поста давайте посмотрим, как может выглядеть минимальный PromptOps workflow на базе GitHub Actions. Идея простая: любое новое issue автоматически превращается в XML-промпт по XSD, сохраняется в папку prompts/ и при необходимости отправляется в PromptOps сервис на Spring Boot. Как это работает 1. Любое новое issue запускает workflow. GitHub Action делает следующее: - берёт заголовок и описание issue; - генерирует XML-файл (prompts/issue-123.xml); - валидирует его по схеме XSD (schemas/task.xsd); - коммитит файл обратно в репозиторий; - при необходимости отправляет XML на PromptOps сервис через REST API. В результате каждое GitHub issue становится точкой входа в PromptOps-пайплайн. GitHub хранит "живой backlog", а IDE или AI всегда получают строго формализованные промпты. Интеграция с AI IDE Так как современные AI IDE поддерживают MCP, то никакая дополнительная поставка не нужна - IDE сама может запросить нужное issue. Упрощенный воркфлоу 1. Разработчик создал issue в GitHub. 2. GitHub Action проверил его по XSD и сохранил в prompts/. 3. IDE через MCP-плагин видит: - список доступных промптов, - возможность открыть и выполнить любой из них. По сути, интеграция с AI IDE через MCP - это просто "дать IDE доступ к папке prompts/" как к ресурсу.

PromptOps: стандартизация промптов в команде Что если выстроить процесс передачи задач AI-агенту так, чтобы от бизнес-задачи до готовых инструкций всё было максимально формализовано? Главный вызов, который я сейчас вижу - как стандартизировать формат промптов внутри команды. Допустим, у нас уже есть такой стандарт. Основная идея: XSD как триггер - XML - единый формат промпта. - XSD - фиксирует правила и шаблон (автовалидация). - Проверка - ручная, перед отправкой в AI-агента. И вот тут появляется интересный момент: XSD можно воспринимать не только как инструмент валидации, но и как триггер. Почему XSD = триггер 1. Стандартизация входа Модель никогда не получает «любой XML». Всё валидируется по XSD - значит, структура предсказуема. 2. Триггеры внутри схемы Например, в XSD есть <Status> с ограничением CREATED | PROCESSING | .... Это не просто валидация, а чёткий сигнал: модель работает только с этими статусами. 3. Расширяемость Добавили новый элемент <Module> или <Agent> - теперь он обязателен во всех промптах. Это превращается в контракт: модель всегда получает нужный контекст. Чем это похоже на триггерный промптинг - XSD = заготовка (trigger template). - XML = конкретный вызов (trigger input). - Валидация по схеме = защита от «шума» и «лишних слов». По сути, мы превращаем формат в инструмент управления моделью. Как это использовать в команде - Для каждого типа промптов пишем свою XSD (например, Task, BugReport, RefactorRequest). - Все участники формируют промпты только через XML, валидный по схеме. - LLM всегда получает стандартизированные входы - одинаковое поведение. Дополнительно можно генерировать XML-промпты автоматически, например, прямо из Jira. Фактически, XSD становится DSL (domain-specific language) для работы с AI. Триггерный промптинг = гарантированное выполнение схемы.

Plain Text vs XML or Markdown: на чём писать промпты для ИИ-кодера? Структура — это новый язык общения с ИИ. Особенно когда дело касается кода. Есть миф: чтобы попросить ИИ написать код, достаточно набросать запрос в чат «как есть». Plain text, без правил. Сработает? Иногда. Будет эффективно? Редко. Почему ИИ «понимает» структурированный промпт (с тегами, отступами, чёткими блоками) лучше, чем простой текст? Ясность ролей. Когда вы явно прописываете <role>Ты senior Java-разработчик</role>, ИИ не гадает, в каком стиле писать — он сразу включает нужный режим. Разделение задач. Отдельный блок с требованиями, примером и самим заданием помогает модели не путать условие с контекстом. Это как дать не кучу деталей, а чертёж со схемой сборки. Контроль формата. Хотите получить ответ в виде JSON, код с комментариями или готовый модуль? Скажите это явно в теге <output_format>. ИИ не будет добавлять от себя лишних пояснений, если вы просите только код. Как это работает на практике? Вместо: «Напиши на Java метод, который проверяет, является ли строка палиндромом. Игнорируй регистр и пробелы. С использованием StringBuilder.» Структурируем: <role> Ты senior Java-разработчик, который строго следует code convention и пишет надежный production-ready код. </role> <task> Напиши публичный статический метод для проверки, является ли строка палиндромом. </task> <requirements> - Название метода: `isPalindrome` - Параметры: `String input` - Возвращаемый тип: `boolean` - Игнорировать регистр символов (привести к нижнему регистру). - Удалить все не-буквенные символы (пробелы, знаки препинания). - Использовать `StringBuilder` для разворота строки. - Добавить JavaDoc комментарий. - Продемонстрировать работу метода в методе `main`. </requirements> <output_format> Предоставь готовый к компиляции Java-код класса `PalindromeChecker` без лишних объяснений. </output_format> Второй вариант даст более точный и готовый к использованию результат. Меньше правок — быстрее результат. Но! Не всегда нужно усложнять. Для простых задач вроде «напиши регулярное выражение для email» или «объясни этот код» достаточно plain text. Не стоит делать XML-каркас для одноразового запроса. Если хотите писать код с ИИ быстрее и точнее — учитесь структурировать промпты. Но используйте сложные форматы там, где они действительно нужны.

Как тестировать код, написанный ИИ? Может показаться удобным: ИИ написал фичу — и тут же сам начал покрывать тестами. Но на деле это ловушка. Ещё хуже, если разработчик просто даёт промпт без спецификации и предлагает «по логике» построить тесты. Это как подгонять тесты под код, а не проверять его работу. Проблема: тесты превращаются в формальность. Они не проверяют корректность реализации, а лишь повторяют то, что уже написал ИИ. В результате мы получаем красивый, но бесполезный набор тестов. Решение: тестирование должно опираться на спецификацию — чёткое описание того, как должна работать фича. ИИ не должен видеть сам код при генерации тестов: иначе он будет использовать его как инструкцию к действию. Если же дать ему только требования и сценарии использования, тесты будут действительно проверять логику работы, а не подгонять результат. Так тесты сохраняют свою основную задачу — выявлять ошибки и гарантировать, что продукт работает так, как задумано. (Но это не точно =))