Даже меня в это ай-яй болото затянули. Спасибо, Декс.

Ладно, давайте-те всё же поговорим про искуственный интеллект, и то, как мы сами пустили его в наши дома.

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

---

Сверим часы:

• ИскИн, ИИ, Ай-Яй – Искуственный Интеллект. Предсказыватель символов, калькулятор на анаболиках, чат-бот второго поколения.
• Е(стественная) Т(упость), кожаный мешок, оператор, читатель (в большинстве случаев, но не всегда) – человек.
• Агент – искин с руками.
• Руки – части обвязки, определенный инструмент, который может использовать искин.
• Обвязка – совокупность рук-инструментов и мониторов, которые навесили на аяйку, чтобы та могла взаимодействовать с внешним миром.

---

Агенты как понятие появились в далеких 50-х годах (а то и раньше), спасибо папаша Тьюринг и фантасты. Но в действительности, реальные агенты на базе кремниевых друзей появились пару лет назад, и сразу же устроили "всех программистов погонят взашеи!".

И вот, уже два года мы с ними живем. Рука об руку, так сказать.

И поменялось достаточно многое.

Часть первая, вводная, рассказывающая о том, что поменялось в работе.

Помните, как вы, в свое время, чтобы найти работу, ходили и прорешивали LeetCode, вникали в алгоритмы, даже, может System Design тыкали?

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

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

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

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

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

Потом, на собеседовании техническом, вам надо показать, что вы всё знаете и без ИИ, но при этом демонстрировать, что вы умеете им пользоваться.

А на самой работе, конечно же, вам нужно филигранно пользоваться ИИ, потому что так захотел менеджмент. А руками клавиатуру лучше вообще не трогать – случайно понизите метрику, и кому-то не дадут премию.

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

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

Хуже всего, конечно, то, что появляются метрики формата "AI Adoption". Я понимаю ещё метрики типа hours-to-prod (на русском – "сколько времени заняло выполнение задачи от постановки до выхода в свет"), они были всегда, и всегда были очень ценны. Но считать процент работы, выполненной калькуляторами? Увольте. Не-не, не буквально.

Менеджмент (в любой уважающей себя конторе) считает, что скорость важнее качества. В чём-то они действительно правы – выкатываешь новый функционал раньше всех -> альтернатив нет -> все идут к тебе -> PROFIT. Вот только никого не интересует, а что же произойдёт, если вдруг этот функционал окажется некорректным. Менеджменту важна лишь скорость, и участие ИИ – при средней температуре по палате хорошую компанию должно лихорадить, чтобы об этом написали. Реклама, フリ です.

А теперь давайте мы немно-ого отправимся поговорить о моём опыте. Опыте как системного инженера.

---

Часть вторая, вводящая соотношение цены токенов искинов и человеческих нервов.

Вся история – выдумка, и проходила на закрытом RP-сервере Watch Dogs 2. Но в каждой истории есть капелька истории, и конкретно эта история очень важна для того, чтобы понять, как не надо делать.

Предположим, существует такая компания, в которой победил менеджмент. Для простоты будем называть её компанией "Е", где я бы работал в подразделении "I".

А ещё предположим, что аналитика вся делается Claude Haiku, гендиректор лезет в репозитории и создает дикие мердж-конфликты используя Claude Sonnet, и при этом весь управляющий состав громко онанирует на идею о том, что за день можно сделать любую задачу и фичу.

Хорошо бы, конечно, если бы на этом всё заканчивалось. Но, к сожалению, я ещё не закончил.

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

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

Получаем следующий флоу: гендир ставит задачу в формате "хочу", после чего менеджмент просто форвардит её команде, накидав от балды аналатики через Claude, и ставит срок "вчера". К слову, перепутав понятие "DevOps" и "Раб Ебучий Обыкновенный", такие задачи в такой компании, конечно же, попадали бы ко мне.

Я, конечно же, в такой ситуации бы не растерялся, и сказал бы им пойти как можно дальше, а не отвлекать меня от инфраструктурных задач, поставленных ранее (сроки которых я и так едва бы отбил). Особенно учитывая что при средней стоимости килограмма курицы в магазине я бы получал примерно 12 тугриков, чего не хватило бы даже на экологичный гроб из картона.

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

Но и на этом бы дело не закончилось.

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

И вот тут, дорогие мои друзья, произошла бы шедевроситуация. В субботу, когда у меня выходной, гендир бы надавил на ИБ, получил бы прямой доступ до прода в обход меня, и запустил бы туда Claude Sonnet.

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

Хорошая басня, да? Жаль, что я наврал, сказав, что это выдумка.

Давайте посчитаем, что ли. При зарплате в 12 тугриков, рабочей неделе 5/2 8 часов с неоплачиваемыми онколлами, и ублюдском менеджменте, я бы получил увольнение "по соглашению" за оживление трупа в свой выходной. Всего лишь за пятнадцать минут работы Claude Code в руках маразматичного оператора.

В руках оператора, который не умеет ставить задачи, следить за ними, и ограничивать кремниевый разум в определенные рамки, искин превращается в смертельное оружие. Ствол этого оружия, правда, смотрит в сторону стреляющего или его команды.

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

А если точнее – ему надо правильно ставить задачи.

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

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

А когда я задаю вопросы "а какой куб? версия какая? CNI какой? CSI?", то получаю в ответ "да я не знаю, я просто сказал, он сделал". Вот так быть не должно.

---

Часть третья: а как быть должно?

А вот тут каждому на вкус и цвет. Главное – не считайте, что сказать ИИ "сделай хорошо, не делай плохо, не задавай вопросов" решит все ваши проблемы. Или что есть какой-то супер-промпт, который резко повышает квалификацию ИИ. Не повышает.

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

Я говорю и про деньги, и про специалистов – что, в общем-то, одно и то же. Если Декс говорит с точки зрения системного архитектора, то я буду говорить с точки зрения поддержки платформы.

Да, можно выбрать SurrealDB вместо pgvector, потому что она работает лучше, и заставить искин работать с ним, и у него это получится даже лучше вашего, но вот вам пара нюансов. SurrealDB – не база данных. Суррил – абстракция, построенная на любой kv-базе (ключ-значение, как etcd), или же вообще работающее in-memory и хранящее всё в JSON, и он ещё не полностью вышел в этап "взрослости". И инженеров, которые в случае отключения ИИ будут знать, что с ним делать – меньше. И даже у искуственного интеллекта информации об сурриле меньше, а шанс галлюцинаций – больше.

А вот pgvector тупой как дубовая пробка, но зато давно известный. Его легче поддерживать, его надежнее оставлять, и айяй точно справится с его конфигурацией и восстановлением в случае чего. И если в случае с суррилом вы будете закладывать куда больший буфер ошибки, и куда меньший SLA, то в случае с постгресом вы сможете позволить себе развернуться сильнее. И стоить это будет меньше. Да, может скорость и диски сожрут чуть больше, но эта сумма явно будет меньше, чем то, сколько в случае крита по SLA придется выплачивать клиентам.

ИИ не примет за вас волшебное правильное решение. Если попросить его выбрать вам базу данных – он поднимет Postgres или сольет весь ваш бюджет в AWS Firebase.

Как-то раз я, нарушая это самое правило, попросил его написать мне графовую базу данных, расчитанную на минимальные задержки, и дал отмашку "прими сам все важные решения". Знаете, что сделал этот огузок? RAM-first graph DB. РАМ-ФЕРСТ ГРАФ ДБ, бл*ть!

То есть он посмотрел на ТЗ, и решил, что база может быть не больше размера плашки ОЗУ в сервере. А иначе она падает с критом. Ему показалось это крутым. Он и написал это круто и оптимально. Но это решение просто нежизнеспособно.

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

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

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

Три столпа "иификации":

• Полный и автоматически обновляющийся контекст/документация/перечни ресурсов. Очень важная штука, чтобы ИИ не спрашивал вас постоянно, и чтобы не галлюцинировал, вспоминая неактуальные данные. И доступ в интернет только через SearXNG, зарезанный всюду, куда нельзя. Пусть он умеет только то, что в доке, и только то, что внутри – ну не надо ему знать, как варить космическое топливо с форума 2010 года. Лично я использую самописное решение, ещё не вышедшее в публичный доступ, которое держит одну графовую (нет, это никак не относится к предыдущему проекту) базу знаний с постоянной перестройкой графа по весам и тегам при помощи классификатора. Быстро, сердито, дешево, и эффективно. Если ответ нерелевантен – LLM ответит об этом инструменту сама, вызвав перестройку дерева. Остальные агенты, подключенные к сети, видят всё сразу. И изменения тоже получают все сразу.
• Четкое ТЗ, написанное либо через несколько прогонов через другую нейросеть, либо ручками, и очень внимательно. Обязательно учитывая все обязательства и ограничения. Иначе можно получить сжирающий кучу денег сервис на четыре девятки, который так-то мог быть Cron Job (скрипт, выполняющийся раз в какое-то время), и вообще не ебать никому мозг. А сервис, которому были нужны четыре девятки, станет чудищем Франкенштейна, чья поддержка будет стоить больше всей выручки компании. За квартал.
• Prempti. Да, блять, ИИ можно и нужно ограничивать. Нельзя его сажать в продовый стенд, нельзя ему давать /bin/bash -c. Выворачивайте ему все ручки через MCP, отслеживайте его права алгоритмически с той стороны, и всегда верифицируйте агента против его OAuth, которому стоило бы совпадать с айдентити работника. И сажайте кусак по типу Prempti+Falco (который должен ловить syscall), чтобы они в случае попытки обхода ограничений откусывали ИИ еблет так, чтобы он больше пошевелиться не мог.

Если уж говорить про стоимость и "эффективность", а не безопасность, то Декс и сам прорекламирует – Cantrip. Машина для пользовательской оркестрации агентов разных провайдеров (включая локальных, чем я и пользуюсь, втыкая туда llama-server с зажженым Qwen-3.6-Heretic-8B, ценой своего оконного менеджера, которому не хватает видеопамяти). Но его тоже нужно ограничивать – благо, для этого он более гибкий. Я, конечно, всё ещё к нему не привык.

Наверно, самое время для этого несвязного текста получить свой

Вывод

Не надо учиться писать на Go, Rust, C++, Assembler, React, JS, Kotlin и так далее. Особенно, конечно, Rust и JS. Машина справится лучше вас. Машина умнее, быстрее, и дешевле (если правильно ей пользоваться) вас. Машина бездушная, она пока что не умеет обижаться. Вам надо лишь уметь это прочитать, понять, и оценить.

Не надо уметь работать со всеми технологиями баз данных сразу – главное, понять, в чем отличие, и знать, что и в чём выигрывает, чтобы выбрать. Если ИИ советует вам использовать VasyanDataBaseC++ – можете перекусить клавиатуру, но не дайте ему её использовать.

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

Учитесь понимать бизнес. Аналитику. Составлять ТЗ, архитектуру, понимать концепции failure budget, метрик, сласлосли, и так далее. Без этого вы дальше уже не уедете.

Сейчас джун – тот, кто умеет запускать клод код. Миддл – тот, кто умеет поставить задачу. А сеньор – тот, кто умеет поставить задачу правильно, и кого ночью будут будить поднимать стенд после агента джуна.

Будьте быстрее амбассадоров ИИ. Они ошибаются.