За последние полгода я понял о себе одну вещь: если бы выяснилось, что «Гарри Поттер» — документальная проза и магия реальна, моя реакция была бы примерно такой: «Ок, интересно, а эта магия годится для чего-то сложнее юнит-тестов?» Впрочем, LLMs этот порог полезности уже перешагнули. По состоянию на июль 2026-го и исключительно по собственным наблюдениям, у них всё ещё есть фундаментальные ограничения, так что я пока не записался на курсы столярного дела на случай вымирания профессии «Software Engineer». И, судя по моей ментальной модели, в ближайшее время это не изменится.
Вот моя гипотеза: взрывной рост внедрения LLMs в 2026 году вызван тем, что они стали достаточно надёжными, чтобы успешно работать в автоматических циклах обратной связи. Дальнейший рост качества моделей будет приносить уже куда меньший прирост продуктивности, чем раньше. Аналогия такая: чтобы подняться по лестнице, нужно быть достаточно высоким, чтобы сделать хотя бы один шаг; но тот факт, что ты можешь шагать через две или три ступеньки, важен куда меньше.
LLMs хорошо справляются с написанием кода, потому что им можно сказать: «сделай кнопку, которая делает X, потом нажми кнопку и убедись, что она делает X». Они способны итеративно идти к цели шагами осмысленного размера, а не буксовать, и умеют надёжно предсказывать, когда человек сказал бы «да, кнопка теперь делает X» или «нет, ещё не делает». Поэтому LLMs полезны для кода, критерии приёмки которого легко и объективно проверяемы, и ты даёшь их явно. Это потрясающе, колоссально, меняет жизнь — возможно, даже удваивает продуктивность.
Но остаются важные вопросы, на которые LLMs пока не могут ответить с достаточной точностью. Например: «Можно ли структурировать этот код более поддерживаемым способом?» или «Содержит ли эта документация нужную информацию и отсекает ли лишнее?» Поэтому я использую LLMs в основном для генерации черновика кода, который затем сам сильно перерабатываю — по крайней мере до тех пор, пока общая структура не начнёт мне нравиться. В читаемости отдельных строк и функций я чуть халтурил (оговорка на случай, если коллеги прочитают). Но даже с этой халтурой я постоянно недооцениваю, сколько времени займёт итерация: раньше рабочая реализация означала 80% готовности задачи, теперь это скорее 20%.
Что касается документации, есть простая инструкция, которая радикально улучшает результат LLMs: «Никогда не пиши README, docstrings или комментарии. Я сделаю это сам позже. И да, я на полном серьёзе».
Можно было бы возразить: «LLMs колоссально улучшились за последний год, и будущие улучшения наверняка научат их писать хорошую документацию и поддерживаемый код». Но если принять мою гипотезу лестницы, такая реакция гораздо менее обоснованна. Умение забираться на высокую лестницу не означает умения плавать.
Мой текущий прогноз: одни лишь улучшения моделей вряд ли дадут нам 10-кратный рост продуктивности по сравнению с тёмными веками 2025-го. Главные выигрыши в обозримом будущем принесёт перестройка инструментов и рабочих процессов вокруг тех возможностей моделей, которые есть уже сейчас. Я не ранний последователь: прошёл путь от использования LLMs как навороченной замены поисковика и Stack Overflow, к написанию кода через интерактивный чат и затем — к декларативным спецификациям желаемого конечного состояния. Абсолютно незаменимыми стали изолированные sandbox-окружения, чтобы не давать модели разрешения каждые 30 секунд. Тут ещё очень много работы по шлифовке воркфлоу и инструментария.
Пробовал я и vibe coding (определяю это как «генерация кода без его чтения и понимания») для непродакшновых и нерабочих вещей. Вне работы это направление интересно, многие его увлечённо осваивают. Пока трудно сказать, насколько такой подход жизнеспособен в долгосрочной перспективе, ведь долгосрочной перспективы ещё и не было. Но, возможно, что-то в этом есть: вдруг определённые тестовые практики и инструменты позволят безопасно полагаться на чёрный ящик LLM-кода даже для критической инфраструктуры. Может, мы и выйдем на 10-кратное ускорение, просто обойдя фундаментальные слабости моделей. А пока я держусь за свои рукописные README.