Уютный IT адочек

Нанять product engineer легко. Гораздо сложнее перестать согласовывать с семью людьми каждое его движение.

Сейчас продвигается концепт product engineer — человека-оркестра, который с помощью ИИ самостоятельно проходит весь путь от пользовательской проблемы до работающей фичи. Поговорил с пользователями, придумал решение, написал код, протестировал, выкатил и посмотрел на метрики. То есть — всё то, для чего раньше требовались аналитик, продакт, разработчик, тестировщик и несколько свободных слотов в календаре.

Инженеры, конечно, возражают. Мол, один человек не может быть специалистом во всём, независимая проверка исчезнет, качество упадёт, а техдолг однажды обретёт сознание.

Менеджеры тоже переживают: ведь аналитик должен проверить требования, тестировщик — разработчика, архитектор — всех сразу, а менеджер проконтролировать, что участники процесса не забыли проконтролировать друг друга.

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

И тут возникает неприятный вопрос: а зачем нам действительно было нужно столько отдельных ролей?

Возможно, разделение труда существует не только ради экспертизы. Оно ещё помогает компании справляться с недоверием.
Аналитик пишет требования, потому что разработчику нельзя доверить понимание пользователя. Архитектор согласовывает решение, потому что разработчику нельзя доверить архитектуру. Тестировщик проверяет код, потому что разработчику нельзя доверить качество.
В результате процесс производит не только продукт. Он ещё производит доказательства, что никто конкретно не виноват.

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

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

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

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

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

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

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

С ИИ такого не получится. Он не считывает авторитет. Не понимает интонацию. Не чувствует, что руководитель недоволен. Вместо того чтобы собраться и начать работать, просит уточнить требования и критерии готовности.

С мотивацией та же проблема. ИИ нельзя публично похвалить на общем собрании, выдать ему грамоту по итогам квартала или пообещать пересмотреть грейд, если он ещё немного постарается. На него не влияет перспектива лишиться премии. Он не переживает за своё будущее в компании.

А ведь управление — это искусство, оно требует опыта!

Ну вот как ты профессионально, по-менеджерски посмотришь ИИ в глаза? Придёшь в датацентр и будешь смотреть на серверы?

Это так не работает.

Потому что нет страха в глазах у серверов.

Монтирую новый видосик о внутреннем устройстве агента и harness, о том, какие подводные камни вас ждут при создании своего агента и как глубока кроличья нора.
О том, почему ни в коем случае нельзя лезть в историю с созданием своего агента и что делать, если это всё-таки нужно сделать.

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

Управлять требованиями и генерить/ревьювить километровые спеки - не одно и то же.

Первое - не автоматизируемо и является ключевой работой инженера.

Второе - бесполезно.

Вы переживаете, что ИИ делает вас тупым и заставляет забыть как кодить?

А кто вам сказал, что вы вообще умели кодить, по правде говоря?

• ты никогда не помнил шаблоны проектирования в Javascript.
• ты постоянно гуглил ответы людей на stackoverflow. Людей, у которых точно такие же проблемы. И ты просто брал и копипастил написанное решение.

Ну серьёзно.
Ты хоть раз писал хотя бы один HTTP запрос вручную, самостоятельно? Без документации, без примеров, просто ты — и чистый код, проистекающий из твоих пальцев.
Сомнительно.

Ты копипастил сообщение об ошибке в гугл. А теперь твой ИИ копипастит сообщение об ошибке в гугл. Это прям реально такая большая разница?

Нет, конечно, существуют настоящие, великие программисты. Программисты, которые исследуют и улучшают компиляторы, программисты, которые наполняют stackoverflow правильными ответами.
Но будем честны — это не мы с вами.

ИИ не лишает вас навыков программирования. Было бы чего лишать.

Полистал тут шортсы и, кажется, докопался до корня всей этой священной войны против ИИ в разработке. И вот этих бесконечных криков о том, что без Spec-Driven Development и вычитывания каждой строчки спеки мы все умрём.

Корень проблемы — в профдеформации.

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

Когда нейронка выдаёт рабочий результат за три минуты, у инженера ломается шаблон. Вместо радости за ускорение поставки ценности начинается микроменеджмент синтаксиса: "нет, ну вы посмотрите, она назвала переменную не camelCase, а архитектура не по Мартину!". Эго требует контроля над буквами, а не над результатом.

SDD и фанатичное ревью спек в таком контексте превращаются не в инструмент проектирования, а в попытку заставить ИИ думать и писать в точности как Вася из третьего отдела.

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

1. Код — это расходник, а не памятник архитектуры. Пользователю всё равно, насколько изящно вы отформатировали цикл, если фича не решает его задачу.
2. Оценивайте результат, а не стиль письма. Если сгенерированный модуль работает надежно, покрыт тестами и не создает проблем на проде — отпустите свои эстетические травмы.
3. Контролировать надо ключевые точки, а не табы и пробелы в коде. Основные заложенные алгоритмы, изменения структур данных, работу фич, работу с данными, как решение будет проходить через стадии SDLC (сборку, деплой на разные контуры и т.п.) и т.п. Контроль должен быть, но он должен быть умным и всеобъемлющим. И для него не обязательно читать код!

Пока одни тратят часы на вылизывание того, что завтра всё равно перепишут, другие просто выкатывают продукт и забирают рынок. Сдвигайте фокус с красоты текста на то, чтобы текст вообще начал приносить ценность!

Spec Driven Development в эпоху LLM — сомнительная фигня на грани карго-культа.

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

Вместо написания простыней текста сделайте нормальный boilerplate и заложите нужные вам паттерны. Модель читает код, модель живёт кодом, модель продолжит реальные бест практис кодом гораздо точнее, чем попытается расшифровать литературные фантазии о ста листах.

Зачем писать эти километры спек? Чтобы оправдать занятость аналитиков и создать видимость "важного артефакта перед началом кодинга"? Чтобы "делать всё привычно, там же должна быть аналитика перед разработкой"?

Я ставлю ребром вопрос — должен ли AI SDLC быть "автоматизированным с помощью ИИ SDLC".
Есть ощущение — что не должен. Что AI SDLC должен строиться на других принципах.

Сделай веточку -> Запили инкрементальное изменение -> выкати на тестовый стенд -> РАЗБЕРИСЬ, ЧТО вышло. Подошло — забираем. Получилась дичь — отклонили и перегенерили с нуля.

Ключевой шаг — РАЗОБРАТЬСЯ. Сам принцип приёмки меняется фундаментально. Это выглядит не как "потыкать кнопочки в UI" и уж точно не "поверить агенту на слово, что он всё сделал". Нужен многосторонний инженерный аудит: архитектура, ключевые точки в коде типа миграций, безопасность, надежность, продуктовая наполненность, и много-много всего ещё.

И цель всех этих муторствований — не пройти по бизнес-процессу производства нейрослопного кода. Цель — находясь в постоянно меняющейся, непознанной среде (код меняется, процессы меняются, запросы клиентов меняются, бизнес адаптируется) проводить эксперименты, проверять гипотезы и накапливать экспертизу.

"Программирование на спеках" — это попытка в меняющейся среде с недетерменированными акторами построить конвеер по выпеканию одинаковых булочек.

Хочу однажды написать книжку "Как навести порядок в компании без денег и полномочий".

Первая глава будет не очень объёмной и содержать всего одно слово: "никак".
А вот в последующих главах будет рассказано, как наработать полномочия, деньги, сформулировать договорённости и не привлечь внимание санитаров.

"One more feature, bro, one more fix — и точно полетит"

Классическая ловушка, в которую с завидной регулярностью попадает почти любой технарь или фаундер. Мы готовы ночами вылизывать архитектуру, переписывать промпты и пачками сжигать токены OpenAI. Потому что писать код и ковырять пайплайны — это понятно, безопасно и полностью подконтрольно.

А вот маркетинг, продажи и кастдевы — это больно, непредсказуемо и требует выхода из зоны комфорта.

В итоге разработка превращается в психологическое убежище. Но суровая реальность бизнеса проста: рынку плевать, сколько бессонных ночей вложено в красивый код. Если о продукте никто не знает и им никто не пользуется — продукта не существует. Всё остальное — это не стартап, а просто дорогое хобби и добровольное спонсирование счетов IT-гигантов за инфраструктуру.

Самый полезный "коммит", который вы можете сделать для своего проекта — это закрыть IDE и пойти писать потенциальным клиентам. Спрашивать, рассказывать.

Задаёшь вопрос/запускаешь исследование, а в ответ прилетает простыня текста, густо пересыпанная терминами. И ты сидишь с ощущением, что тебя либо изощрённо топят, либо ответ пришёл с другой планеты.

Ситуация одинаковая — что с LLM, что с инженерами со слабыми софт скиллами (и, зачастую, очень мощными хардами). Крутишь-вертишь, а получаешь одно из двух:

- Либо куча кишок наружу: всё объясняется настолько подробно и низкоуровнево, что за деревьями не видно леса и нихрена не понятно.
- Либо тебе рисуют иллюзию: ответ даётся общими, "понятными" словами и вроде всё звучит логично, но суть потеряна, и ты абсолютно не контролируешь ситуацию. И что хуже всего — осознаешь проблемы ты слишком поздно.

Я думаю, чтобы понимать сложные вещи, придётся напрягать собственную биологическую нейронку в голове: доучиваться, расти над собой, удерживая планку в коридоре "сложно, но постижимо".

Чтобы этот процесс не превращался в бесконечную фрустрацию, контекст можно калибровать. Как с моделями, так и с живыми людьми — отлично работают два подхода:

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

2. Явный скоуп контекста
Не бойтесь очерчивать границы: что вы уже знаете твёрдо, а где у вас слепая зона.
Например: «Я отлично знаю HTTP, руками щупал его через telnet, много писал REST и SOAP-сервисы. Объясни мне SSE и gRPC — они взлетели позже, чем я активно кодил».

Вы задаёте собеседнику (или промпту) твёрдую точку отсчёта. Это экономит кучу нервов, избавляет от необходимости слушать базу про сотворение мира и переводит разговор в конструктивное русло.

Некоторые наивно верят в то, что модель умеет читать мысли.

В весах любой LLM зашита своя онтология — некая "средняя по больнице" картина мира и общепринятая терминология. Когда нейросеть пытается писать код или править баги в вашем проекте, она опирается именно на эту базу. Единственное окно в вашу реальность для модели — это названия сущностей, методов и переменных.

Если в команде годами забивали на Domain-Driven Design, изобретали свой "птичий язык", а архитектура существует только в виде устных преданий тимлида — у вас проблемы. Модель будет постоянно мазать мимо контекста, галлюцинировать и порождать несусветную дичь. Не потому что она тупая, а потому что ваше локальное "исторически так сложилось" в корне противоречит общепринятому смыслу слов.

В такой ситуации есть два пути:

• Признать проблему семантического техдолга. Взять ту же LLM в зубы, выяснить, где ваша внутренняя сказка расходится со "общепринятым", и заняться внятным рефакторингом доменной модели.
• Продолжать воевать с ветряными мельницами, убеждая себя и коллег в том, что "AI — ерунда и ничего сложнее ToDo-листа написать не может".

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

Мясной прокси — человек, который пересылает сгенерированный ИИ текст, не читая, не понимая и не проверяя его.

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