TLDR: LLM неплохо справляются с кодингом, но в больших проектах они пишут запутанный сумбур. Я уменьшил объём использования ИИ при кодинге и вернулся к работе головой, ручке и бумаге.

Несколько месяцев назад мне нужно было создать новую инфраструктуру для моего SaaS, потому что связка из PHP+MySQL перестала отвечать нашим требованиям. Мне не терпелось воспользоваться этой возможностью, чтобы максимально задействовать все новые LLM, с которыми я экспериментировал. Поэтому я временно отказался от должности разработчика ПО, став сам себе продакт-менеджером. Я обсуждал с Claude технологии, проводил собственные исследования и спустя много итераций составил план. В итоге я решил использовать Go+Clickhouse.

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

Потом я закинул это всё в Cursor Notepads и начал составлять промпты. Cursor пишет код, я собираю и тестирую его. Меня вполне устраивало происходящее, кодовая база была не самой чистой, но вроде работала. Мне важнее была скорость разработки, а не чистота кода — мои бизнес-клиенты SaaS сказали, что им нужны определённые данные, а эта новая инфраструктура была единственным способом их доставки. У меня было ещё несколько потенциальных клиентов, ожидающих моего сообщения о том, что всё готово, чтобы можно было приобрести тарифный план. Пока всё не готово, я в буквальном смысле каждый день теряю деньги.

Но прошло ещё несколько недель, и начали появляться первые признаки проблем. Меня начал раздражать процесс. Каждый день мне казалось, что я очень близок к конечному продукту, но потом находил ещё одну проблему, из-за которой приходилось откладывать выпуск ещё на несколько дней. Я оправдывал это тем, что никогда до этого не работал с Go и Clickhouse, поэтому логично, что для устранения проблем требуется чуть больше времени, чем я привык. Однако проблемы продолжались, а моё раздражение усиливалось. Cursor теперь особо мне не помогал. Я копипастил сообщения об ошибках и в ответ получал исправление, но потом что-то ломалось в другом месте. Чем более детализированной была проблема, тем сложнее было LLM дать реальное решение. Поэтому я начал сам внимательнее изучать код, пытаясь понять его.

Я пятнадцать лет был разработчиком ПО, а в колледже изучал C++ и Java, поэтому приблизительно понимал, что происходит в этих файлах на Go. Но у меня не было концепций оптимального применения Go и Clickhouse.

Я начал изучать их чуть глубже. Прочитал документацию, статьи, посмотрел на YouTube видео о Clickhouse. Я стал пытливее допрашивать Claude, задавая подробные вопросы и подвергая сомнениям его ответы.

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

Итак, я провёл сессию «ревью кодинга». И меня обуял ужас.

Два файла сервиса в одной папке с похожими названиями, очевидно, выполняющие очень схожие задачи. Но имена методов отличались. Свойства не были согласованы. Одно называлось WebAPIprovider, другое — webApi. Они обозначали ровно один и тот же параметр. Один и тот же метод многократно объявлялся заново в различных файлах. Один и тот же файл конфигурации вызывался по-разному и обрабатывался разными методами.

Никакой согласованности, никакого общего плана. Как будто я попросил десяток джунов или мидлов поработать над этой кодовой базой без доступа к Git, закрыв каждого в кабинете и не давая им общаться.

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

Возвращаемся назад

К этому моменту стало понятно, что нужно менять подход. Я в первую очередь разработчик ПО, поэтому глупо будет не использовать бо́льшую часть моих навыков. Я больше начал изучать Go и Clickhouse и перестал гнаться за скоростью разработки. Я открывал файл за файлом и переписывал код. Не всё, только то, от чего меня начинало подташнивать. Пусть язык и отличается, но я понимал, как всё должно выглядеть и какой должна быть структура.

Так как я вернулся назад, отладка стала проще. Пусть я двигался не так быстро, зато у меня теперь не возникало странное ощущение, что я как будто написал этот код, но понятия не имею, что там внутри. Я продолжаю пользоваться LLM, но для более тупых вещей: «переименуй все вхождения этого параметра» или «вот тебе псевдокод, сгенерируй эквивалент на Go».

Сложнее всего было сопротивляться искушению пользоваться ИИ. У меня есть этот потрясающий инструмент, способный за минуту написать десять файлов. Я впустую трачу время, не используя его! И тут меня осенило: теперь я реже стал пользоваться мозгом. Я подсознательно стремлюсь использовать ИИ для всего, что связано с кодингом.

Я меньше стал писать на бумаге. Когда мне нужно запланировать новую фичу, я первым делом думаю, что надо спросить о ней o4-mini-high, а не поработать нейронами. Меня это бесит. И я должен изменить ситуацию.

Так что да, меня беспокоит влияние ИИ, но не из-за риска потерять работу, а из-за утери ясности мысли, способности планировать фичи, писать красивый и функциональный код.

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

Но я не прошу его писать что-то новое с нуля, придумывать идеи или писать полностью новый план. План пишу я. Я — сениор-разработчик. А LLM — помощник.

Золотая середина

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

Но меня беспокоят ноу-кодеры. Я почти уверен, что теперь для них ситуация хуже, чем в эпоху «no code» без ИИ. По крайней мере, инструменты no code писались людьми, имеющими здравый смысл, и, несмотря на ограниченность фич, у таких инструментов была хоть какая-то структура.

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

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

Обращение к любителям ИИ

Я почти слышу, как толпа специалистов по ИИ-кодингу кричит мне: нужно было работать с <самой-новой-моделью>! Надо было пользоваться правилами Cursor! Нужно было реализовать этот процесс из пятнадцати этапов, который я недавно нашёл на Reddit!

Я пользовался. Я на самом деле пытался. Надо лишь признать, что сегодня ИИ просто на кое-что неспособен.

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

Она просто не справится, даже если дать ей полную схему SQL, даже если указать ссылку на самую свежую документацию по Clickhouse, даже если в мельчайших подробностях описать необходимости бизнеса и ограничения инфраструктуры. Новейшая Gemini не справится, o4-mini-high не справится, o3 не справится, Sonnet 3.7 не справится.

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

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

Странное положение. Как будто мне надо куда-то добраться, и я могу или идти пешком, или лететь на космическом корабле со скоростью 1000 км/ч, но надписи на приборах наполовину на венгерском, наполовину на древнегреческом. Путём проб и ошибок я, вероятно, могу долететь до нужной мне точки, но это само по себе серьёзный труд, и в конечном итоге я буду задаваться вопросом, а не лучше ли было добраться пешком.

Кроме того, меня постоянно мучает ощущение, что нас обманывают бенчмарки, инфлюэнсеры, которые теперь могут продавать золотоискателям новые волшебные лопаты, и кучей компаний, пытающихся убедить нас, что это «агент», а не просто ещё одна cron-задача.

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

Они троттлят GPU? Эти инструменты просто нельзя контролировать? Какого чёрта вообще происходит?