Я программист с приличным стажем, ещё в школе писал игрушки для БК‑шек, а сейчас у меня годы коммерческой разработки на Python, и я считаю себя, в общем‑то, уверенным сеньором.
До недавнего времени из ИИ я пользовался только браузерным Gemini. Он быстрый, живой, отзывчивый — с ним можно приятно поболтать, однако кодит он неважно. Добиться нужного результата частенько получалось только через крепкое словцо, на которое, впрочем, Gemini охотно откликается. Но понятно, что это всё жутко неудобно и надо было переходить на кодинг‑агентов.
Так бы я и канителился, однако получилось так, что вайб‑кодинг, вместе с вайб‑планированием и вайб‑постановками задач в Jira, в нашей команде внедрили волевым решением. Никого не спрашивая, не выясняя, кто что умеет, кто как к этому относится и как это вообще повлияет на разработку.
Сначала я, как и положено старпёру, отнёсся к этой технологии настороженно. Однако Cursor оказался весьма дружелюбным инструментом, да и квест с оплатой оказался несложным.
Что же, вот новый инструмент — надо его осваивать. Распланировал и реализовал пару небольших фич — прикольно. Дальше получилось так, что надо было пофиксить баг, описание буквально такое: список на фронте грузится до какого‑то момента, а потом бэк начинает пятисотить. К логам сходу добраться не удалось, и я попробовал скормить Курсору описание прямо в таком виде. На бэке при этом FastAPI + MongoDB с самописной прослойкой — что‑то вроде ODM на минималках, с lookup‑ами (аналогами join‑ов в SQL) и декларативным описанием коллекций. Не то чтобы рокет‑сайнс, но и не совсем тривиально.
И что вы думаете? Этот друг нашёл, что projection делается после lookup и match, отчего список документов выжирал память в Монге, и она падала с Sort exceeded memory limit (честно говоря, до сих пор удивлён, что это не оптимизировано на уровне планировщика). И это всё, напомню, без всяких логов. То есть он фактически предсказал текст ошибки, которую я потом проверил — так точно, она и оказалась.
Ну, надо сказать, это меня весьма впечатлило. Я порядком уже поскакал вокруг Монги с бубном и уже знал, что с этим багом без ИИ я бы провозился не меньше пары часов, а то и денька‑другого.
К чему я это пишу: без сомнения, технология уже зрелая и рабочая, и то, что она изменила индустрию, — тоже не вопрос. Вот только направление лично мне нравится не очень.
Очевидно, что теперь любой с Курсором может делать вещи. Этим уже никого не удивить, порог входа в IT снижается буквально до нуля. Огромный пласт повседневных задач, ранее требовавших разработчиков, а вместе с ними — нелюбимого многими простого человеческого общения и различных финансовых рисков, теперь закрывается владельцем бизнеса или нанятым эникейщиком. Об этом много писали, и это в целом на поверхности.
Но есть и другое.
Я на примере своей команды вижу одержимость менеджеров этой технологией. Там, где раньше было «сесть, нарисовать архитектуру, выбрать вариант, помозговать, обсудить, распланировать, распилить на таски», теперь безжалостный цикл нейрослопа. Прилетает запрос от бизнеса — без всякого анализа «что, зачем» задача скармливается Курсору. Курсор выдаёт план без всякой архитектуры — ни системной, ни программной. План улетает на команду, команда берёт задачу, скармливает её опять Курсору. Хорошо, если инженер толковый и вовремя схватит Курсор за руку и не даст навалить в MR нейрослопа, но в целом и это уже необязательно. Тесты, разумеется, пишутся тоже Курсором. Что они там проверяют — понять уже невозможно, зато покрытие 100%.
Но при этом всё работает! Да, не всегда понятно, оптимально или нет и можно ли сделать лучше, но работает!
Поначалу Курсору не доверяешь, проверяешь и ловишь за руку, не давая протащить архитектурно или стилистически сомнительные решения. А потом привыкаешь, что оно работает, — и отдаёшь ему на откуп всё.
И тут, мне кажется, кроется одна из главным проблем повсеместного внедрения ИИ для кодинга, о которой мало пишут.
Вотчина программиста — бороться со сложностью программных систем, сводя её по возможности к сложности предметной области. Раньше программы писали на ассемблере — это сложно. В рамках борьбы со сложностью программисты придумали Фортран, Си, Паскаль и массу других языков программирования. Python, Go, Rust создавались из потребности изящно решать проблемы в своих предметных областях. Появились фреймворки, библиотеки, которые опять‑таки повышали уровень абстракции. Банально — позволяли писать меньше кода, а тот, что оставался, делать удобнее. Тот же ORM: мы задаём модели, что даёт нам возможности статической проверки типов, удобные подсказки в IDE, общую уверенность в устойчивости кода.
Чувствуете? Кодинг‑агенту это всё не надо. Его, я так подозреваю, можно заставить писать всё что угодно, хоть на ассемблере. Ладно, может, это преувеличение, однако нафигачить сырых запросов к базе без всякого ORM — это всегда пожалуйста. Запрети ему использовать библиотеки — так он на голых сокетах веб‑сервер напишет, без проблем.
У программиста теперь нет задачи решить проблему изящно. Проблемы решаются грубой силой.
В индустрии пропадает прежняя движущая сила. Уже давно всё развитие — это то, сколько у новых моделей параметров и как они рвут на лоскуты все бенчмарки. Новые языки и библиотеки ещё появляются, конечно, но упор уже давно не на том, как изящно решить задачу руками. Нет, я не утверждаю, что кодинг‑агентом нельзя написать хорошую архитектуру. Тут как в том меме: можно, а зачем?
Зачем нам гексагональная архитектура? Зачем KISS, зачем SRP? Зачем распиливать монолит на микросервисы и опасаться God‑object?
Это всё нужно было нам. Чтобы удержать систему в голове. Чтобы эффективно взаимодействовать с коллегами. Чтобы через полгода открыть модуль и не проклясть себя или не вспомнить того же коллегу крепким словом. Агенту без разницы, гексагон у вас или каша, — лишь бы работало.
Мы боролись со сложностью ограниченными методами, потому что вынуждены были использовать ограниченный инструмент — голову. LLM — вот наш новый уровень абстракции, который похоронил под собой все детали нижележащего слоя. Система как была сложной, так и осталась. Просто понимать её люди больше не обязаны, если её понимает агент и она работает.
Если работа программиста — борьба со сложностью, а сложности для человека больше нет, то и работы в старом смысле больше нет. Сеньорские и архитекторские навыки по большому счёту больше не востребованы.
Да, останутся любители поковыряться в том, что нагенерила нейронка, но участь их такая же, как у low‑level оптимизаторов, которые смотрят листинги после компилятора в надежде сэкономить пару тактов.
То, что полвека двигало индустрию вперёд, внезапно оказалось ненужным. Вместе с ним канет в лету то, что когда‑то называлось Искусством программирования. Во что трансформируется профессия — лично мне пока не очень понятно. Не исключено, что Илон наш Маск прав и профессия как таковая исчезнет. Не хотелось бы в это верить.
ссылка на оригинал статьи https://habr.com/ru/articles/1080742/