Сегодня я и моя командой заняли первое место на хакатоне гражданских проектов. Сделали бота, ищущего контракты на капремонт по адресу, и выкачивалку-парсилку Госзакупок для него. Можно использовать как референс или брать готовый код в свои проекты, он в Public Domain: https://github.com/unxed/crwatch
Для меня это был первый хакатон и первый проект, с нуля сделанный вайбкодингом. Учитывая, что пользуюсь я нейронками в разработке довольно давно, накопился некоторый опыт, которым решил поделиться и с вами.
Сперва о сложностях
Главная проблема программирования нейронками уже не галлюцинации, а уметь прерваться, когда нейронка начинает ходить по кругу, и подсказать ей принципиально другой поход. Пока в 4 случаях из 5 это может только человек.
Какие ещё есть сложности? Необходимость всё время гонять код между своим компом и нейронкой. Возможно, это решается использованием редактора со встроенным AI-помощником, но я довольно консервативен и не хочу менять редактор. Кроме того, мне нравится возможность самому решать, какие части кода держать в контекстном окне.
В процессе перегонки кода туда-сюда у вас скорее всего поедет синхронизация версий (потому что вы будете вносить свои изменения поверх нейроношных или тем или иным способом компилировать разные ответы нейронки и свой код, а она не будет в курсе всех этих изменений). Чтоб справиться с этой проблемой, я иногда скидываю сетке архив с текущей версией, чтоб она не путалась. И ещё — они не умеют писать патч-файлы. Бесит.
Выбор инструмента
Он довольно прост: есть Gemini 2.5 Pro (доступна бесплатно на aistudio.google.com) и есть всё остальное. Потому что всё остальное не даёт ничего даже близко похожего на окно контекста в 1 миллион токенов. Иными словами, всё остальное может работать только помощниками в программировании, но никак не программировать под вашим руководством.
Повышаем эффективность
Если задача сложная, просите сначала написать план решения. Потом попросите покритиковать его, поискать слабые места и альтернативы. И только потом код.
Формулировка «напиши систему X» часто приводит к нерабочему коду. Гораздо лучше просить кусками: «сделай функцию Y», «напиши модуль Z с интерфейсом таким-то». Иными словами, делите сложные задачи на простые части, результат которых легко проверить. У меня нет скрипта «скачать всё нужные данные с Госзакупок, распарсить и залить в базу». Есть скрипты: «скачать все закупки в JSON», «обогатить JSON, загрузив и распарсив подробные свойства каждой закупки (адрес объекта и т. п.)», «сделать из JSONа SQL дамп», «провести постобработку в БД».
Пусть нейросеть сначала выдаёт черновой вариант, а вы уточняете. В режиме «быстрого прототипа» модель работает эффективнее, чем если сразу требовать идеально чистый код. Даже если нужна сложная логика, сначала просите минимальный рабочий пример (MWE). Так проще понять, где модель ошибается — в логике или в деталях её реализации.
Итерации должны быть короткими. Не гоняйте модель на десятках экранов кода. Лучше так: «вот функция на 40 строк, сделай оптимизацию», это снизит вероятность того, что она запутается.
Сложные функции, такие как «распарсить строку со 100500 адресами с произвольными разделителями и форматами», отлаживайте не на живой БД, а тестовым скриптом, куда легко добавлять новые данные из багрепортов. Там и правьте. А потом копируйте готовую и отлаженную функцию в рабочий код.
Специально просите вставлять всюду много отладочного вывода. Потом уберёте, а процесс ускорит в разы. И не забывайте о контроле версий: git diff и git show полезны при разработке нейронкой не меньше, чем при обычной.
Задавайте формат ответа. Сразу уточняйте: «код без пояснений», «код с комментариями», «только отличия от предыдущей версии, и как их внести, языком, понятным джуну». Это экономит токены и снижает хаос в диалоге.
LLM может придумать API, которое «выглядит правдоподобно», но не существует (или не существует в вашей версии софта), к этому надо быть готовым. Сетка обычно сама осознает это, если показать ей логи приложения и/или ошибки компилятора. Если это не помогает, можно скормить сетке доки на фреймворк или его релевантную часть.
Комбинируйте несколько моделей. Одна может хорошо писать код, другая — находить баги, третья — объяснять. Разнести роли эффективнее, чем нагружать одну модель всеми задачами сразу. У меня обычно открыта Gemini 2.5 Pro для разработки и ChatGPT для запросов справочной инфы в процессе, а ещё она иногда, пусть и не часто, подсказывает решения, которые не приходят Gemini в голову.
Просите писать либо на языке, который знаете лучше всего (для коммерции и случаев, где важна скорость), либо на языке, который хотите изучить (для проектов для души). Ей пофиг, а вам — повышение эффективности. Но учитывайте: на непопулярных языках она пишет хуже.
Если боитесь за надёжность и предпочитаете код, написанный человеками, или если требования к ИБ повышены, пишите нейронкой прототипы, PoC, MVP. Потом по той же архитектуре сделаете руками. Ускорит в разы: fail fast. Ещё ими можно: писать тесты, искать по коду, документировать его автоматически, находить узкие места и возможности для оптимизации, писать сборочные скрипты и другую вспомогательную инфраструктуру. Да, и просите писать комментарии таким языком чтобы понял джун — всегда может так оказаться, что с кодом будете работать не только вы.
Даже контекстное окно Gemini в миллион токенов когда-нибудь закончится, а ещё после 300к она знатно тупит. Экономьте токены. Неудачные ходы нейронки трите вместе с запросом, и потом пишите новый с учётом её ошибок.
Регулярно перезапускайте сессии. После долгого диалога контекст замусоривается, и качество падает. Просите сетку написать текстовое резюме всей проделанной работы. Потом создаёте новый чат, кидаете туда исходники и резюме из прошлого, и продолжаете с этого места дальше. Тут есть некоторое ограничение в плане глубины понимания сеткой тех или иных решений, принятых в предыдущем чате, и это может в теории создать проблемы (например, при оптимизации будет выкинут кусок кода, смысл которого сетка без доступа к предыдущему чату не уловила), но это приемлемое зло: то же самое могло бы случиться, если бы вам нужно было продолжить разработку любого чужого кода с произвольного места. Зато так вы сможете продолжать разработку неограниченно долго — до тех пор, пока релевантные для текущей задачи части исходников помещаются в 1 млн контекстное окно с запасом раза в четыре.
Каждый диалог должен кончатся чем-то логически завершенным, работающим и т.д. — или комментарием, на чём остановились.
В тупике, чувствуете что ходите по кругу? Пробуйте три вещи: добавить отладочного вывода, откатиться назад, продолжить в новом диалоге.
И помните: это инструмент со своими ограничениями. Люди, впрочем, тоже 🤷♂️ 🙂
А ещё это делает программирование весёлым снова!
P.S.: Статья писалась на основе твиттерского треда, но для Хабра я добавил ещё несколько полезных рекомендаций и скомпоновал всё логичнее.
