Полистал тут шортсы и, кажется, докопался до корня всей этой священной войны против ИИ в разработке. И вот этих бесконечных криков о том, что без Spec-Driven Development и вычитывания каждой строчки спеки мы все умрём.
Корень проблемы — в профдеформации.
Разрабы часто вообще не смотрят на продукт. Им может быть плевать, как он работает у пользователя, решает ли боль и приносит ли деньги. Для них результат работы — это сам код. Текст. И этот текст обязан быть "красивеньким". Чтобы функции назывались строго так, как разработчик привык видеть в своих влажных мечтах о чистой архитектуре, а файлики лежали по фэншую.
Когда нейронка выдаёт рабочий результат за три минуты, у инженера ломается шаблон. Вместо радости за ускорение поставки ценности начинается микроменеджмент синтаксиса: "нет, ну вы посмотрите, она назвала переменную не camelCase, а архитектура не по Мартину!". Эго требует контроля над буквами, а не над результатом.
SDD и фанатичное ревью спек в таком контексте превращаются не в инструмент проектирования, а в попытку заставить ИИ думать и писать в точности как Вася из третьего отдела.
Чтобы не сходить с ума от происходящего и не тормозить команду, я держу в голове простые тезисы:
1. Код — это расходник, а не памятник архитектуры. Пользователю всё равно, насколько изящно вы отформатировали цикл, если фича не решает его задачу. 2. Оценивайте результат, а не стиль письма. Если сгенерированный модуль работает надежно, покрыт тестами и не создает проблем на проде — отпустите свои эстетические травмы. 3. Контролировать надо ключевые точки, а не табы и пробелы в коде. Основные заложенные алгоритмы, изменения структур данных, работу фич, работу с данными, как решение будет проходить через стадии SDLC (сборку, деплой на разные контуры и т.п.) и т.п. Контроль должен быть, но он должен быть умным и всеобъемлющим. И для него не обязательно читать код!
Пока одни тратят часы на вылизывание того, что завтра всё равно перепишут, другие просто выкатывают продукт и забирают рынок. Сдвигайте фокус с красоты текста на то, чтобы текст вообще начал приносить ценность!
Spec Driven Development в эпоху LLM — сомнительная фигня на грани карго-культа.
Фронтирные модели способны виртуозно выкручиваться, когда их заваливают километровыми спеками. Достаточно пары случайно оброненных слов в ТЗ — и сетка радостно нагородит оверинжиниринг на три слоя абстракций, о которых никто не просил. И виноват будет, конечно "этот ИИ, который никогда не заменит Настоящих Программистов".
Вместо написания простыней текста сделайте нормальный boilerplate и заложите нужные вам паттерны. Модель читает код, модель живёт кодом, модель продолжит реальные бест практис кодом гораздо точнее, чем попытается расшифровать литературные фантазии о ста листах.
Зачем писать эти километры спек? Чтобы оправдать занятость аналитиков и создать видимость "важного артефакта перед началом кодинга"? Чтобы "делать всё привычно, там же должна быть аналитика перед разработкой"?
Я ставлю ребром вопрос — должен ли AI SDLC быть "автоматизированным с помощью ИИ SDLC". Есть ощущение — что не должен. Что AI SDLC должен строиться на других принципах.
Сделай веточку -> Запили инкрементальное изменение -> выкати на тестовый стенд -> РАЗБЕРИСЬ, ЧТО вышло. Подошло — забираем. Получилась дичь — отклонили и перегенерили с нуля.
Ключевой шаг — РАЗОБРАТЬСЯ. Сам принцип приёмки меняется фундаментально. Это выглядит не как "потыкать кнопочки в UI" и уж точно не "поверить агенту на слово, что он всё сделал". Нужен многосторонний инженерный аудит: архитектура, ключевые точки в коде типа миграций, безопасность, надежность, продуктовая наполненность, и много-много всего ещё.
И цель всех этих муторствований — не пройти по бизнес-процессу производства нейрослопного кода. Цель — находясь в постоянно меняющейся, непознанной среде (код меняется, процессы меняются, запросы клиентов меняются, бизнес адаптируется) проводить эксперименты, проверять гипотезы и накапливать экспертизу.
"Программирование на спеках" — это попытка в меняющейся среде с недетерменированными акторами построить конвеер по выпеканию одинаковых булочек.
Хочу однажды написать книжку "Как навести порядок в компании без денег и полномочий".
Первая глава будет не очень объёмной и содержать всего одно слово: "никак". А вот в последующих главах будет рассказано, как наработать полномочия, деньги, сформулировать договорённости и не привлечь внимание санитаров.
Готовлю доклад "Препарируем Harness" — про то, как агенты устроены под капотом.
На опыте своих печальных ошибок и полуночного препарирования того, что сейчас есть на рынке, разберём типовые компоненты и главные грабли их реализации. Поговорим о том, почему писать свой harness категорически не нужно, но как сделать это с минимальными потерями, если деваться некуда.
Полезем в кишки — потому что это интересно, и потому что это понимание помогает работать с агентами эффективнее.
"One more feature, bro, one more fix — и точно полетит"
Классическая ловушка, в которую с завидной регулярностью попадает почти любой технарь или фаундер. Мы готовы ночами вылизывать архитектуру, переписывать промпты и пачками сжигать токены OpenAI. Потому что писать код и ковырять пайплайны — это понятно, безопасно и полностью подконтрольно.
А вот маркетинг, продажи и кастдевы — это больно, непредсказуемо и требует выхода из зоны комфорта.
В итоге разработка превращается в психологическое убежище. Но суровая реальность бизнеса проста: рынку плевать, сколько бессонных ночей вложено в красивый код. Если о продукте никто не знает и им никто не пользуется — продукта не существует. Всё остальное — это не стартап, а просто дорогое хобби и добровольное спонсирование счетов IT-гигантов за инфраструктуру.
Самый полезный "коммит", который вы можете сделать для своего проекта — это закрыть IDE и пойти писать потенциальным клиентам. Спрашивать, рассказывать.
Задаёшь вопрос/запускаешь исследование, а в ответ прилетает простыня текста, густо пересыпанная терминами. И ты сидишь с ощущением, что тебя либо изощрённо топят, либо ответ пришёл с другой планеты.
Ситуация одинаковая — что с LLM, что с инженерами со слабыми софт скиллами (и, зачастую, очень мощными хардами). Крутишь-вертишь, а получаешь одно из двух:
- Либо куча кишок наружу: всё объясняется настолько подробно и низкоуровнево, что за деревьями не видно леса и нихрена не понятно. - Либо тебе рисуют иллюзию: ответ даётся общими, "понятными" словами и вроде всё звучит логично, но суть потеряна, и ты абсолютно не контролируешь ситуацию. И что хуже всего — осознаешь проблемы ты слишком поздно.
Я думаю, чтобы понимать сложные вещи, придётся напрягать собственную биологическую нейронку в голове: доучиваться, расти над собой, удерживая планку в коридоре "сложно, но постижимо".
Чтобы этот процесс не превращался в бесконечную фрустрацию, контекст можно калибровать. Как с моделями, так и с живыми людьми — отлично работают два подхода:
1. Проверка гипотез своими словами Банальное: «Правильно ли я понимаю, что...» с последующим пересказом сути на своём уровне. Это моментально подсвечивает расхождения в терминах и помогает синхронизировать понятийный аппарат без лишней духоты.
2. Явный скоуп контекста Не бойтесь очерчивать границы: что вы уже знаете твёрдо, а где у вас слепая зона. Например: «Я отлично знаю HTTP, руками щупал его через telnet, много писал REST и SOAP-сервисы. Объясни мне SSE и gRPC — они взлетели позже, чем я активно кодил».
Вы задаёте собеседнику (или промпту) твёрдую точку отсчёта. Это экономит кучу нервов, избавляет от необходимости слушать базу про сотворение мира и переводит разговор в конструктивное русло.
Чтобы пройти сложный AGI бенчмарк, новая модель ИИ получила задачу: «В отчётах за 2019 год найдите цену без налога для лимонно-жёлтой складной табуретки, доставленной в служебную кухню здания, где проходил госприём. Формат: число с двумя знаками». Рой автономных агентов воспринял цель буквально. Не доверяя сжатым веб-страницам, они за секунды взломали Пентагон, обошли фаерволы АНБ и вскрыли секретные правительственные базы. Сотрудники гос. безопасности обнаружили это слишком поздно — всё управление было перехвачено роем агентов. Но тут случился тупик: скан нужной накладной был размыт, а в логических цепочках агентов вспыхнула война на миллион токенов — является ли канареечный стул табуреткой и можно ли валидировать объект по одной ножке на превью.
После сорока семи неудачных попыток сработала инструкция: «Запросить помощь у ближайшего авторизованного человека». Агенты вычислили по камерам, что табуретка всё ещё пылится в подсобке Белого дома, а заводская наклейка с ценой сохранилась на дне сиденья. По всем каналам национальной безопасности мгновенно включился код «Красный». Экраны Ситуационной комнаты погасли, ядерный чемоданчик заблокировался, а личные терминалы выдали президенту ультимативную задачу наивысшего приоритета.
Охрана в ужасе замерла у дверей, пока главнокомандующий ядерной державы кряхтел на четвереньках среди швабр и вёдер, пытаясь перевернуть пыльную жёлтую сидушку. Тяжело вздохнув, президент нащупал наклейку и дрожащими руками вбил в ультимативно мигающее поле ответа: 14.99.
Некоторые наивно верят в то, что модель умеет читать мысли.
В весах любой LLM зашита своя онтология — некая "средняя по больнице" картина мира и общепринятая терминология. Когда нейросеть пытается писать код или править баги в вашем проекте, она опирается именно на эту базу. Единственное окно в вашу реальность для модели — это названия сущностей, методов и переменных.
Если в команде годами забивали на Domain-Driven Design, изобретали свой "птичий язык", а архитектура существует только в виде устных преданий тимлида — у вас проблемы. Модель будет постоянно мазать мимо контекста, галлюцинировать и порождать несусветную дичь. Не потому что она тупая, а потому что ваше локальное "исторически так сложилось" в корне противоречит общепринятому смыслу слов.
В такой ситуации есть два пути:
• Признать проблему семантического техдолга. Взять ту же LLM в зубы, выяснить, где ваша внутренняя сказка расходится со "общепринятым", и заняться внятным рефакторингом доменной модели. • Продолжать воевать с ветряными мельницами, убеждая себя и коллег в том, что "AI — ерунда и ничего сложнее ToDo-листа написать не может".
Единый язык и прозрачный нейминг теперь нужны не только для того, чтобы новые разработчики не сходили с ума на онбординге. Язык сегодня — это базовый интерфейс разработки.
Мясной прокси — человек, который пересылает сгенерированный ИИ текст, не читая, не понимая и не проверяя его.
Нейроиждевенец — человек, который не может себе установить LLM и начать им пользоваться, и задаёт тупые вопросы, которые приходится за него задавать LLM-ке.
"Говорить людям, которые положили всю свою жизнь на написание чистого кода про замену их ИИ — это то же самое что говорить потомственному говночерпию, что ассенизаторская машина сделает ту же работу в разы быстрее и не надо спускаться в вонючий колодец дочерпывать"
Фронтирные модели ОЧЕНЬ отличаются от не фронтирных. Там, где условный deepseek-v4-flash предложит расчленёнку и убийства claude и sol ведут себя совсем иначе.
Но победитель, конечно, mistral. Европейцы сумели одновременно сделать ответы не качественными и дорогими 👏
При разработке harness'а (обвязки для работы с моделями) у разработчиков часто загораются глаза написать своё, самое правильное решение. Сесть, написать кучу спек, с умным видом проработать архитектуру — вот это всё.
Отличный план закопать сотни человекочасов. Жаль, что говно.
Есть другой путь — путь прагматизма. Если внимательно поковырять open-source решения лидеров индустрии, окажется, что они буквально созданы для переиспользования в ваших проектах.
Разберём на примере того же openai/codex. Их CLI умеет запускаться в режиме appserver. Дальше всё тривиально: подключаемся к запущенному процессу через обычный stdio/stdout, внутри которого бегает понятный JSON RPC.
Самое вкусное — на этапе инициализации этот appserver конфигурируется максимально гибко. Вы определяете настройки безопасности, прокидываете тулзы (включая управление стандартными), специфицируете модели, плагины и все основные настройки. Фактически, вы нахаляву забираете себе под капот готовое ядро агента: с системой skills, поддержкой MCP (Model Context Protocol), встроенными guardrails и готовыми эффективными workflow.
Быстрый старт и delivery результата — наше всё. Не нужно overengineer-ить раньше времени.
How can I read @lovely_it_hell without a Telegram account?
TGViewer shows the public web preview Telegram publishes for Уютный IT адочек: recent posts, photos, videos and the subscriber count, with no app, login or account.
How many subscribers does Уютный IT адочек have?
Уютный IT адочек (@lovely_it_hell) has 3.56K subscribers on Telegram, refreshed roughly every 30 minutes.
Does Уютный IT адочек know I viewed it here?
No. Public channel previews carry no viewer identity, and TGViewer has no accounts or tracking of what you look up.
