В последнее время все чаще и больше в разработке использую генеративные нейросети в агентском режиме, для простоты будем называть это как все, вайб-кодингом. Ну а чего? Сейчас каждый утюг и его бабушка вайб-кодят и рассказывают о том, как это стало здорово. И в плане доступа к разработке тех, кто раньше разрабатывать не умел, это, кстати, действительно здорово.
Но кто и раньше умел разрабатывать сам, всё-таки смотрит на предмет немножко под другим углом. Поэтому решил немного растечься мыслями, поворчать, позанудствовать и поразмышлять не о том, как настроить Codex, MCP-сервер, или натравить Claude Code на KWork. А об эффектах, о неизбежных изменениях, которые внесли, вносят и будут вносить в нашу повседневную работу — в разработку программного обеспечения живыми человеческими людьми — нейросети.
Сначала коротко определим наше место в пространстве и времени относительно самого феномена нейросетей (здесь и далее — в разработке ПО). Обсуждать, нужны ли они, помогают ли они, следует ли их использовать — уже поздно. Этот вопрос больше не стоит. Если вдруг еще не начали, надо начать. Кот смотрит на часы и говорит — Пора!
Итак,
Что это меняет
Когда ты выступаешь лидом в проекте, основная часть работы сводится к следующему циклу. Ты изучаешь требования, планируешь архитектуру, декомпозируешь всё это в задачи, навешиваешь оценки и назначаешь разработчикам. Затем получаешь от разработчиков результаты, проводишь ревью, изучаешь реализацию, обсуждаешь узкие места и тонкости, и в конечном итоге отвечаешь за то, чтобы выполненная задача попала в продакшн.
И в этом смысле разработка с агентом очень похожа на работу лида: ты делаешь то же самое, включая обсуждение, только часть, где ты ждёшь результатов, проходит несколько быстрее. А часть, где ты их описываешь, обсуждаешь и проверяешь — наоборот, несколько дольше. Поэтому если ты лид, или просто склонен к именно такой работе — вайб-кодинг очень хорошо сразу заходит.
Плюс кому-то может импонировать что машина не живая и с ней можно не пытаться овладеть всякими там софт-скиллами типа говорить так, чтобы тебя слушали, или вообще как-то с людьми разговаривать.
Когда ты выступаешь разработчиком, процесс немножко отличается. Ты получаешь задачу откуда-то (от тимлида, начальника, заказчика, самого себя), пишешь её, потом тестируешь, потом отправляешь на ревью. И тут внезапно у тебя в руках чудо-инструмент, который забирает у тебя написание кода и даже часть тестирования. Что мы можем сказать про эту часть работы? Она:
- Обычно самая длительная — фактически реализовывать поставленную задачу, писать и отлаживать код обычно дольше, чем все остальные этапы. Когда не дольше тоже бывает, но и нейросеть тогда не то чтобы сильно ускорит задачу.
- Самая сбалансированная — задача уже поставлена, архитектура придумана (или получена), мы более-менее прикинули хвост к носу, как будем работать. Дело за технической реализацией. Постучал по кнопочкам, подумал, опять постучал, посмотрел, проверил, подумал, постучал…
И вот этого как раз вайба мы лишаемся. Сбалансированной и достаточно долгой части работы, когда мы можем писать код, возможно даже в состоянии потока, при этом контролировать как скорость написания, так и интенсивность наших размышлений в процессе. Всё, нет больше этой части. Мы можем разве что наблюдать за рассуждениями иишечки, пока голова не закружится от бегущих строчек.
Но. Вместо кодинга нам нужно в два раза чётче поставить задачу (мы ставим её не себе) и в пять раз внимательнее проверить результат (опять же, писали не мы). А времени отдохнуть между постановкой задачи и проверкой теперь почти нет. В результате
Повышается когнитивная нагрузка
Мы экономим время на более рутинной части — написании кода, но за это мы вынуждены гораздо усерднее и дольше думать. Даже если допустить, что в сумме мы бы думали ровно столько же, если бы писали сами — в случае с нейросетью это займет меньше времени. Нагрузка на мозг возрастёт.
Да, безусловно, в итоге мы больше задач решим, но исключая из решения самую рутинную и хотя долгую, но не всегда сложную часть, мы оставляем концентрированную нагрузку на мозг, переходя к следующей задаче, затем к следующей, и к следующей. Безусловно, мы можем взять паузу: просто ничего не делать, раз уж роботы все сделали быстрее. Но тогда мы проиграем в гонке за продуктивностью тому, кто такой паузы не взял и следовательно сделает больше, пока мы расслабляемся. Не вариант.
И если, повторюсь, тимлидам это менее страшно, поскольку именно так они в основном и работают (хотя с нейроагентом в качестве разработчика нагрузки всё же больше), то просто программистам без этого опыта может быть куда тяжелее. Так что впору запасаться повышающими мозговую активность витаминами.
Со временем, конечно, мозг адаптируется — как адаптировался к письму, чтению, и бесконечному листанию мобильников. Но пока придётся постараться.
Роботы делают рутину, человеки предаются достойным человеков занятиям — творчеству. Это ли не мечта прогрессоров.
Стоит заметить, что робот-помощник может когнитивную нагрузку и снизить. Каждому из нас наверняка хоть раз попадались
Задачи, которые не хочется делать
Потому что что-нибудь непонятное, потому что нужно погрузиться часа на три, а свободно сейчас только полтора, и кажется лучше не начинать. Потому что shotgun surgery — нужно внести много-много мелких изменений по всему проекту. Просто чувство какого-то внезапного внутреннего уныния каждый раз, когда видишь эту задачу в бэклоге.
Я-то уж точно с таким сталкивался, и не только сам. Как-то раз даже пришлось попросить человека из проекта, потому что он упёрся, что не хочет эту задачу делать, и надо дать ему другую.
Здесь агент — отличное подспорье. И разобрать документацию на API, и подумать над архитектурой, и просканировать проект, чтобы найти эти 150 файлов, где нужно поменять пару строчек. И записать всё это во внятный план. С таким помощником за пазухой мысли о том, что «я не хочу вот это делать» быстро стремятся к нулю, так как барьер входа в неприятную задачу снижается.
А значит, вместе с нагрузкой стремительно меняется наша
Оценка рабочих задач
Да, порой задачи, на которые мы раньше закладывали 50 часов, в обнимку с ИИ-агентом решаются за 25, или даже за 15. Но штука в том, что правильная оценка задач — по-прежнему важнейшая часть коммерческой разработки. И при всех современных гибких методиках, стори-пойнтах, пертах и план-покерах она, в своей основе, всё еще эмпирическая.
Мы декомпозируем и рассчитываем оценки, основываясь на нашем прошлом опыте решения таких же, или похожих задач. И поэтому не можем взять и просто поделить все бюджеты пополам. Пока не можем. Еще не выработан длительный опыт, позволяющий сказать, что если мы возьмем вот этот черный ящик и сунем в него любую задачу, она станет именно в два раза дешевле (а не в три, или на 20%). Этот опыт нам сейчас нужно вырабатывать.
Да, акт написания кода стал быстрее. Но процесс планирования и постановки задач — дольше (и в чем-то точнее). Процесс проверки — дольше и пристрастнее. И часть усилий с написания кода не испарилась, а перетекла в другие процессы.
К слову, переоценка наших способностей с чудесным новым инструментом в руках может сыграть по первости злую шутку. Мы взяли задачу, разбили на части, чтобы было проще её объять и знать за что хвататься, решая по частям. И раньше мы бы распланировали — в соответствии с нашими оценками — что мы завершим сегодня, завтра, и так далее. Каждую подзадачу закончим, проверим, выкатим, всё как обычно. Но теперь у нас в руках инструмент, который щёлкает наши подзадачки как орехи. Эвон как быстро, закрой еще эту, и еще одну. Да чего уж там, хорошо получается. Промпты писать легко и приятно. Месье клод, закрывай все подзадачи сразу, сильвупле.
И если попасть в этот поток, поймать пресловутый вайб кодинга — можно увидеть перед собой в конце PR на 100+ файлов. И чего с ним делать? Мы на подзадачи-то всё разбивали, чтобы нашему мозгу было проще решить большую задачу, решив составляющую её сумму маленьких задач по одной. А теперь получили готовое большое решение большой задачи, которое нужно заново объять нашим мозгом — чтобы проверить, поправить и утвердить. Для чего, видимо, придется декомпозировать заново уже решение (см. увеличение нагрузки). Потому что если мы кодим не инструментик для себя, а проект за деньги, то у нас должно быть
Доверие к полученному результату
Генеративные нейросети часто описывают как черный ящик: положи туда задачу, забери результат, не терзай себя, что происходило внутри. Но если согласиться не терзать себя мы можем, то мы никак не можем просто взять и принять результат. Мы должны знать, что результат — это то, что нам нужно, что это работает как нужно, что технический долг, порожденный этим результатом, минимален и что этот результат ничего не сломал.
Начнём с конца — техдолга и регрессий. Код, который писали мы сами, мы проверяли в процессе, мы знаем как он работает — нам нужно меньше усилий для его полного одобрения (даже если мы прошляпили пару багов и не заметили). А с чужим кодом, чтобы разобраться, порой надо потратить времени сравнимо с собственно разработкой этого кода заново. Но и отвергать бесконечно мы его не можем, поскольку работа должна идти вперёд. И с учетом этого давления темпа разработки, всегда есть риск принять что-то, что мы поняли не до конца. Тем более, что зажмуриться, махнуть рукой и шагнуть — соблазнительно: мозг охотно сэкономит энергию при возможности.
Поэтому ошибки, регрессии, антипаттерны и даже уязвимости нет-нет да и будут возникать, как бы мы не старались быть пристрастными и бдительными. Они и сейчас возникают в командной работе, кодер-агент тут ничего не меняет.
Но что агент может поменять совершенно точно — это наше отношение к тестам. Конечно, я давно тяготею к TDD, но в современных условиях с агентами-нейросетями тесты — это просто наше всё. Это наш критерий истины. Это то, что позволит нам не поехать кукухой, когда контекстного окна нейросети уже не хватает заметить, что сломалось после новой фичи. Но главное — агенты их пишут очень хорошо.
Особенно те самые 10 краевых случаев валидации, которые ты знаешь что надо проверять, но писать тесты на них так нудно и тоскливо… Напиши один, скажи агенту, и он добавит остальные 9 и еще 3, о которых ты не подумал.
Это я проверял последние года полтора, с тестов я собственно начинал свои маленькие шажочки в вайб-кодинге.
Конечно, мало попросить агента работать по TDD — я пробовал, какие-то вещи он все равно забывает протестить. Нужно немножко разобраться в тестировании самому. И под влиянием нейросетей, я думаю, это то, чему стоит уделить внимание всем нам.
Ну а когда пакет тестов уже есть, проводить на его фоне рефакторинг, сокращая технический долг и убеждаясь в отсутствии регрессий — одно удовольствие, хоть руками, хоть через нейросеть.
Но остается еще первая часть того, что мы должны знать: что результат — это то, что нам нужно, что это работает как нужно. Казалось бы, тут всё ясно: если мы такие из себя опытные программисты, то глядя на результат мы должны это уметь понять. Иначе какие мы программисты?
Но сможем ли мы продолжать понимать и дальше?
Эта проблема несколько перекликается с вопросом «Должен ли тимлид сам писать код?» Да, должен, но не чтобы руки не отсохли. А потому что, если этого не делать, то через некоторое время код твоих подопечных — особенно если они крутые толковые ребята — начнет вызывать вопросы: что это за новое решение? Я его не видел раньше.
И проблема не в том, что нужно разбираться. А в том, что у этого вновь увиденного решения может быть три альтернативы, которых ты не увидел вовсе. И если такое будет происходить достаточно часто, лид может превратиться из ведущего (lead) в ведомого. В того кто молча нажимает «Одобрить», а не предлагает решения, инновации, и приносит пользу своими код-ревью.
Вдобавок, без регулярной практики мы не будем совершать собственных ошибок — таким образом не узнаем о них и не сможем никому о них рассказать.
И если в случае с разработчиками худо-бедно так можно ещё прожить, то с нейросетью не получится. Нужно продолжать писать самому — и тут речь не о том, как мы выживем с одним ножиком в лесу, когда нам наши интернеты и электричества отключат, а токены станут дороже бензина. Речь о том, что нужно уметь найти решение лучше предложенного агентом. Это нужно, чтобы увидеть, когда код достаточно хорош, чтобы его принять, и когда достаточно плох — чтобы его отвергнуть.
Более того. Откуда возьмутся новые паттерны, новые примеры разработки кода, если код теперь разрабатывается нейросетями, и в то же время нейросети учатся на нашем коде?
Как сообщил нам Дэвид Линч очаровательным ртом Моники Беллуччи
Мы подобны сновидцу, который видит сон, а потом живет в нём. Но кто этот сновидец?
За прошедшие десятилетия мы наспали миллиарды строчек кода, накормив ими генеративного сновидца. И теперь мы видим наяву, как эти строчки складываются в новые сны лишь с опосредованным нашим участием. Но вот вопрос: а кто наспит новые сны, когда старых не хватит? Кто создаст новые паттерны, архитектурные приемы, способы решения задач?
Кто, если ценность очередной статьи «Как интегрировать A с B?» стремится к нулю с той же скоростью, с которой читатель, задавшийся этим вопросом получает в ответ готовый код от нейросети? Если эту статью будет некому читать — её незачем будет писать. А если её никто не напишет — её не прочитает и нейросеть. Но ведь её обучение должно продолжаться. Ведь должно же?
В то же время, программирование постоянно меняется. Сейчас мало кому нужно уметь разбирать биты на флаги в уме, или помнить законы де Моргана. Компиляторы избавляют многих (хоть и не всех) из нас от мыслей о регистрах, DMA, SIMD и прочих низкоуровневых вещах. Многие абстракции, паттерны и вовсе нужны только людям, чтобы лучше понимать и поддерживать код.
Мы можем написать функцию по принципу DRY, чтобы не повторять код 20 раз — а компилятор 20 раз вставит её тело в код, потому что она маленькая и так быстрее, чем со стеками возиться.
Возможно, генеративные нейросети в свою очередь сделают ненужными для среднего разработчика знания о хороших практиках архитектуры в её современном понимании. Но каким образом — пока неясно. Пока, как мне кажется, эти знания стали даже более ценными.
В качестве заключения хочется сказать вот что. Нейросети как агенты-программисты — прекрасный инструмент. Мы делаем с ним многое, сможем делать ещё больше. Но нельзя на 100% утверждать, что теперь это многое достигается по цене одного ужина в месяц. Мы должны подстраиваться, больше думать, решать, планировать. Вовремя останавливаться. Вовремя рефлексировать.
И да, вовремя прикладывать карточку к терминалу, чтобы оплатить дополнительные токены.
