Заметки из окопа: Практика «выращивания кода» с помощью LLM

Дискуссии об ИИ и больших языковых моделях (LLM) в разработке часто скатываются в бинарные споры: «замена», «выживание», «деградация». LLM — не против нас, а с нами. Не угроза, а помощь в рутине. Не замена, а инструмент. При умелом использовании ИИ освобождает от рутины и ускоряет реализацию, но не отменяет глубокое понимание предметной области. Без навыка писать код и ясности, что и зачем ты делаешь — ИИ бесполезен. Важнее понять, как LLM усиливают нас, трансформируют работу и рождают новые практики.

Середина спектра

Спектр использования LLM широк: от полного контроля, где я пишу всё руками, опираясь на опыт, до «вайба», где код кое‑как пишет сам себя, а человек лишь ловит кайф от собственной бесполезности. Первое ценно в критически важных задачах с высокой ценой ошибки, второе — пустая забава. Мой подход — между крайностями. С LLM я сохраняю критическое мышление и контроль над процессом, но ускоряю результат, получая пользу без потери смысла.

Анатомия

Для меня LLM — одновременно «шестой палец» (автодополнение) и «третья рука» (генерация). «Шестой палец» экономит секунды, «третья рука» меняет анатомию разработки. LLM создают новый цикл разработки: формулировка → генерация → оценка → уточнение → интеграция → улучшение. Код не пишется, а «выращивается» в диалоге с ИИ. Этот цикл требует как развития существующих навыков, так и освоения новых:

1. Промптинг: Формулирование мыслей с точностью, достаточной для их продолжения ИИ. Это больше, чем просто «точная формулировка». Это искусство и наука создания таких запросов (промптов), которые с наибольшей вероятностью дадут желаемый результат от конкретной LLM. Включает понимание того, как модель «думает», какие формулировки работают лучше, как использовать негативные промпты, few‑shot prompting (примеры в запросе) и т. д.

2. Контекстное ремесло: Нужен навык быстро и точно определять, какой именно существующий код, документация или описание паттернов необходимо предоставить LLM для конкретной задачи, чтобы она «попала» в стиль, архитектуру и логику проекта. Это включает умение отбирать релевантную информацию и отсекать лишнюю.

3. Декомпозиция задач: Умение разбивать большие или сложные задачи на более мелкие, управляемые и однозначно формулируемые подзадачи, подходящие для генерации с помощью LLM. Это отличается от классической декомпозиции тем, что нужно учитывать «понимание» и ограничения модели.

4. Критический анализ и валидация кода: Навык «быстрой оценки качества» нужно углубить. Это не просто поверхностный взгляд, а способность быстро выявлять не только синтаксические ошибки, но и потенциальные логические просчеты, проблемы с производительностью, уязвимости безопасности, нарушение паттернов проекта, неоптимальные решения, которые может сгенерировать LLM. Нужно уметь «читать между строк» сгенерированного кода.

5. Навыки итеративной отладки и коррекции (в диалоге): Умение не просто оценить код как «плохой», а понять, почему он не подходит, и сформулировать уточняющий запрос к LLM, который направит ее в нужную сторону. Это требует понимания вероятных причин ошибок модели и способности вести с ней эффективный «отладочный диалог».

6. Системное мышление и интеграционные навыки: Поскольку код «выращивается» как часть существующей системы, усиливается важность понимания общей архитектуры. Нужно не просто сгенерировать работающий фрагмент, но и предвидеть, как он будет взаимодействовать с остальными частями системы, и уметь его бесшовно интегрировать.

7. Выбор адекватного инструмента (модели LLM): Разные модели хороши для разных задач. Нужен навык понимания сильных и слабых сторон различных LLM и выбора наиболее подходящей для конкретной задачи, языка программирования или этапа разработки.

8. Адаптивность и готовность к обучению: Технологии LLM развиваются стремительно. Появляются новые модели, техники промптинга, инструменты. Ключевым становится умение быстро учиться, адаптироваться к новым возможностям и ограничениям, постоянно экспериментировать.

Я меньше работаю на уровне синтаксиса и больше — на уровне архитектуры и интеграции.

Интуиция через практику

«Это не работает! Программирование с LLM — идиотизм!» — рычат матёрые программисты. Ноги растут из бездумного применения, потери контроля, деградации навыков. Я скажу иначе: инструмент не «идиотский» сам по себе — идиотским его делает подход. Идиотизм — не в наличии молотка, а в том, чтобы бить им себе по пальцам или пытаться забивать им шурупы.

ИИ вынуждает разработчика думать, если тот хочет получить что‑то полезное. Слепая копипаста возможна только в простейших случаях, а в реальных проектах она либо не работает, либо требует такого уровня осознанности, что перестает быть слепой. Парадоксально, но чтобы получить максимум пользы от LLM, нужен высокий уровень квалификации. LLM делает сильных сильнее, а слабых — беспомощнее.

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

1. Выбор правильной модели для конкретных задач: разные модели, разные стеки, разные результаты. Нет «лучшей» LLM, есть подходящая для твоей задачи. На фронтах для UI и логики — Claude; для бэка (говорят) — o3-mini, Claude тоже отлично справляется, или может быть дешёвая DeepSeek‑R1; в качестве эксперимента — дерзкий Grok; когда нужно переварить огромный код или документацию — Gemini с её окном выручит. Лучшая метрика — практика. Попробуй сам. Возьми реальную задачу и реши её с разными моделями. Главное — понимать, что ты делаешь.

2. Подбор качественного контекста отдельно под каждую задачу: не ‘напиши мне X’, а ‘вот существующий код […], используемые паттерны […], создай X, который будет интегрироваться в Y с учетом Z ограничений’.

3. Декомпозиция задач на однозначно интерпретируемые части: если задачу нельзя четко объяснить в 2–3 абзацах, она слишком велика для одного запроса (хотя для разных задач могут быть эффективны разные подходы).

4. Итеративный подход к улучшению результатов: качество результата пропорционально качеству вашего диалога с LLM.

5. Реалистичные ожидания: LLM не «сделает всю работу», но ускорит рутину, высвобождая время для более сложных концептуальных и творческих задач. Например, архитектурный уровень — это зона человека, а не LLM. Вы связываете блоки, LLM лишь ускоряет их создание. ИИ бесполезен для условных 20–30% критических задач (зона высокой цены ошибки), которые требующих опыта, интуиции, нестандартности. LLM не изобретает, а адаптирует. Полного «неожиданного решения» (как у человека «с высоты птичьего полета») не будет — модель не способна к интуиции, только к экстраполяции. Но для базового кода, что закрывает остальное, ИИ практически полезен при правильном подходе. Без глубокого понимания задачи и предмета промпты становятся лотерейным билетом, а результат — техническим долгом. LLM генерирует быстро, но отличать работающее от проблемного может только тот, кто понимает предмет. ИИ может как создавать технический долг (плохой код), так и уменьшать его (анализ и рефакторинг).

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

Разрыв интерпретаций

Главный вызов генерации кода из промптов — пропасть между человеческим мышлением (ассоциативным, эмоциональным, неточным) и машинной логикой (однозначной, строгой, алгоритмической). ИИ — молоток, и пока ты не знаешь, куда бить, он стучит наугад. Даже зная цель, он может промахнуться — твоё «ударить сюда» для него лишь вероятность. Мы можем сказать «хочу что‑то крутое», подразумевая миллион разных вещей, но машине нужен чёткий алгоритм. LLM угадывает по вероятностям («70% людей под „крутым“ имеют в виду это») вместо истинного понимания наших намерений. Сложность и неоднозначность естественного языка превращают перевод запросов в код в лотерею.

Каждый раз, когда модель выдает что‑то неожиданное, ловишь себя на мысли: «А что же я на самом деле хотел сказать?». Многословность юридических текстов — попытка зашить неоднозначность в слова, но даже контракты на 50 страниц оставляют «дыры», которые разбирают суды.

На практике этот разрыв существенно закрывается через точный контекст (существующий код «вокруг» новой функциональности), по которому ИИ «достраивает» логику, опираясь на структуру и назначение кода, и итерации, где ты уточняешь направление. Контекст сужает семантическую неоднозначность, а итерации корректируют траекторию.

LLM сам по себе — просто инструмент. Контекст определяет, где его применять, а итерации — как именно это делать.

Существующий код сужает пространство возможных интерпретаций до нескольких приемлемых вариантов. Контекст превращает размытое «собери что‑нибудь из дерева» в конкретное «завершим этот стол по имеющемуся чертежу, используя эти инструменты и эти соединения». Из кода модель извлекает: технический стек, зависимости, паттерны, подходы, стиль именования, соглашения — всё, что радикально сокращает нужду в детальных объяснениях. Это работает как «мгновенное обучение» ИИ всем неявным правилам проекта.

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

Правильно подобранный контекст решает 80% успеха — да, черт возьми! LLM без контекста — гадание на кофейной гуще, с тщательно подобранный контекстом — предсказуемое продолжение вашей мысли.

В итоге, качественный контекст + точные итерации = предсказуемый результат.

Зачем LLM?

Чем опытнее разработчик, тем скептичнее он относится к LLM. Опытные ценят точность ЯП, а не вероятности LLM. Сеньоры ворчат: «Зачем мне вероятности, если я могу написать гарантировано точно и, бывает, быстрее?».

Если языки программирования (ЯП) уже являются рабочим решением для преодоления пропасти между человеческим мышлением и машиной, то зачем вводить еще одного посредника (LLM) со своей, новой «пропастью интерпретаций» (человек → естественный язык → LLM → ЯП → машина)? Какой в этом смысл? Зачем LLM в мире, где ЯП уже «работают»?

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

• Ускорить рутинные и подготовительные этапы разработки: ЯП — это «медленно, но верно», LLM — «быстро, но с оговорками». Вместо формализации всего в классы и методы ты формулируешь задачу словами, ближе к своему ассоциативному мышлению, а модель её достраивает. Даже с правками это быстрее, чем писать руками. Достаточно идеи и контекста.

• Помочь в обучении, исследовании и анализе: ЯП не помогут с поиском примеров или чтением чужого кода. LLM даёт старт, переводит с ЯП на человеческий или наоборот.

• Предложить новый интерфейс: ЯП — абстракция над машинным кодом, LLM — над ЯП. Ты переходишь от «как это сделать» к «что я хочу». ЯП спускают тебя к машине, LLM поднимают машину к тебе.

Да, это вводит новый уровень неопределенности и требует новых навыков (промптинг, критическая оценка), но потенциальный выигрыш в продуктивности для многих задач заставляет разработчиков исследовать и использовать этот подход, несмотря на его недостатки. Это не замена ЯП, а попытка надстроить над ними еще один, более «человеко‑ориентированный», хоть и менее точный, слой для решения части задач разработки. ЯП требуют от тебя точности, LLM — контекста. Вместе они покрывают больше, чем по отдельности:

• ЯП: Ты формализуешь мысли → код точный.

• LLM: Ты даёшь намерение + контекст → код вероятностный, но быстрый.

Выращивание

«Выращивание кода» — интуитивный процесс. Достаточно прикрепить прилегающий код, логически связанный с новой функциональностью, и сказать, что нужно. С «кодом вокруг» общение с LLM становится простым и немногословным, как с коллегой, знающим проект. Чем больше связанного кода, тем короче промпт. Модель «понимает» задачу через кодовую базу. Код говорит сам за себя. Мы создаем условия (жесткие рамки через контекст), где модель «вынуждена» выдать нужный результат.

Обратная зависимость:

• Чем длиннее контекст → тем короче может быть промпт.

• Чем короче контекст → тем подробнее должен быть промпт.

Видится разумным адаптивный подход: использовать объем контекста, соответствующий сложности задачи. Каждая задача уникальна, и то, что считается «релевантным контекстом», зависит от намерений разработчика и требует его активного участия. Этот процесс («контекстное ремесло») творческий и трудоемкий.

Ты не пишешь руками, но задаёшь «почву» (контекст) и «семя» (запрос), направляя рост итерациями. Код растёт:

• Как часть структуры, а не изолированно.

• С учётом явных (импорты, вызовы) и неявных (паттерны) зависимостей.

• С бизнес‑логикой из «почвы».

• В едином стиле.

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

Трансформация

Интересно, как меняется процесс при использовании ИИ. Идея «держателя общей архитектуры и концепции» раскрывает трансформацию роли разработчика. Переход от непосредственного написания кода к управлению процессом: ИИ берёт тактику (анализ, генерация, отладка), человек — стратегию (архитектура, концепция, бизнес‑логика).

Подобно кинорежиссёру, современный разработчик:

1. Формирует общее видение — определяет цели, стиль и структуру всей системы.

2. Руководит «съёмкой» отдельных компонентов — направляет ИИ, задавая контекст и требования.

3. Производит «монтаж» — интегрирует компоненты в целостную систему.

4. Отвечает за целостность произведения — обеспечивает согласованность всех частей.

Режиссёр управляет процессом на всех уровнях:

• Работа с «актёрами» — ИИ‑инструменты, как актёры, обладают собственными сильными и слабыми сторонами, которые режиссёр должен учитывать.

• Итеративность процесса — как режиссёр просматривает дубли и просит переснять сцены, так и разработчик оценивает решения ИИ и запрашивает корректировки.

• Знание технического процесса — успешный режиссёр понимает операторскую работу и монтаж, хотя сам не выполняет их; так и разработчик должен понимать код, но может не писать его полностью.

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

Хороший разработчик сегодня:

• Знает, где ИИ тащит, а где тормозит.

• Понимает, проверяет и точит генерируемый код.

• Использует ИИ не только для «напиши», но и для обучения, анализа, рефакторинга, документирования.

Итог

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

P. S. Это лишь взгляд изнутри ежедневной работы с LLM. Считайте «заметки из окопа» началом разговора.