Честно скажу: к большим языковым моделям я относился скептически довольно долго. Первые мои эксперименты два года назад закончились тем, что нейросеть уверенно придумала мне метод, которого не существует в природе, и я минут двадцать искал его в документации. После этого я закрыл вкладку и сказал себе, что это игрушка для маркетологов. Но потом начал замечать, что коллеги, которых я уважаю, всё чаще используют LLM в мелочах, и не для того, чтобы писать за них код, а для того, чтобы не тратить время на рутину. Я решил попробовать ещё раз, но уже с трезвой головой: не как на оракула, а как на быстрого, начитанного, но иногда слегка самоуверенного джуниора под рукой. Прошло около года, и теперь я могу честно перечислить задачи, где нейросеть реально экономит мне часы.
Начну с самого очевидного — генерация однотипного кода и шаблонов. Когда мне нужно написать десяток похожих классов, DTO, схем валидации или обёрток над внешним API, я больше не печатаю их руками. Я описываю структуру словами, иногда кидаю пример одного уже готового класса, и получаю остальные за пару минут. Да, потом я всё равно прохожусь глазами и правлю нейминг, но экономия колоссальная: то, что раньше занимало сорок минут унылого копирования, теперь занимает десять. Второе — тесты. Я не буду врать, что модель пишет идеальные тесты, но она отлично генерирует каркас, набор граничных случаев и скучные параметризованные проверки, до которых у меня руки часто не доходят. Третье — рефакторинг мелких кусков. Попросить разбить длинную функцию на части, вынести дублирование, переименовать переменные по смыслу — это работает на удивление хорошо, особенно если дать модели контекст, зачем это делается.
Четвёртая задача — объяснение чужого и старого кода. У меня в проекте есть модуль, который писал человек, уволившийся ещё до моего прихода, и там комментарии вида «не трогать, работает». Раньше я сидел и пошагово разбирал эту логику сам. Теперь я вставляю функцию и прошу объяснить, что она делает, какие у неё побочные эффекты и где она может сломаться. Пятая — регулярные выражения. Я, наверное, как и многие, умею их читать, но писать с нуля каждый раз — это боль. Модель делает это за секунды, и я потом проверяю на своих примерах. Шестая — разбор логов и стектрейсов. Когда из продакшена прилетает стог ошибок, быстрее всего просто скормить его модели и спросить, какие гипотезы о причине она видит. Седьмая — SQL. Сложные аналитические запросы с оконными функциями, которые я каждый раз гуглю, теперь пишутся в диалоге, и это заметно ускоряет аналитику.
Восьмая задача, которая недооценена, — работа с текстом вокруг кода. Это документация к модулям, понятные описания коммитов, черновики сообщений для тимлида, перевод бизнес-требований в список технических задач. Я часто думаю быстрее, чем формулирую, и модель помогает мне превратить сырые мысли в структуру. Девятая — быстрое погружение в новую технологию или библиотеку. Вместо чтения длинной документации я прошу собрать минимальный рабочий пример под мою задачу, запускаю его, а потом уже лезу в детали. Десятая — ревью собственного кода перед пушем. Я прошу модель посмотреть на дифф и указать на возможные проблемы: обработку ошибок, гонки, забытые кейсы, утечки. Это не заменяет ревью коллеги, но ловит добрую половину глупых ошибок до того, как я отвлеку команду.
Теперь о том, где я обжёгся и чего советую избегать. Модель уверенно придумывает несуществующие методы, параметры и даже целые библиотеки, причём делает это с интонацией эксперта. Она плохо знает ваш внутренний фреймворк, свежие версии пакетов и всё, что не попало в её обучающие данные. Она не понимает бизнес-контекст: то, что выглядит как баг, иногда является осознанным решением, за которое кто-то получил премию. И самое важное — я никогда не отдаю во внешние сервисы клиентские данные, ключи, приватные куски продакшена и вообще ничего, что подпадает под NDA. Это железное правило, и его лучше проговорить с командой заранее, а не после инцидента.
Из этого вытекают мои рекомендации. Во-первых, относитесь к модели как к инструменту для черновика, а не для финального ответа: она генерирует, вы проверяете. Во-вторых, давайте контекст — чем точнее вы опишете задачу, ограничения и то, какой результат хотите, тем меньше мусора получите. В-третьих, начните с безопасных задач: тесты, документация, регулярки, объяснение кода. Там цена ошибки низкая, а выгода мгновенная. В-четвёртых, не пытайтесь делегировать ей архитектурные решения: проектирование системы всё ещё ваша работа, и именно здесь ваш опыт стоит дороже всего. И в-пятых, замерьте свою экономию хотя бы за неделю — обычно после этого скепсис уходит сам собой.
Я не считаю, что нейросеть заменит разработчика, но я точно считаю, что разработчик, который научился с ней работать, будет заметно быстрее того, кто принципиально печатает всё руками. За год практики я вернул себе, наверное, несколько полных рабочих дней в месяц, и потратил их не на рутину, а на задачи, которые мне действительно интересны. А теперь вопрос к вам, форумчане: какие приёмы работы с LLM оказались для вас самыми полезными, что вы пробовали и бросили и есть ли у вас свой список задач, которые вы принципиально не отдаёте нейросети? Буду рад почитать ваш опыт в комментариях.
Начну с самого очевидного — генерация однотипного кода и шаблонов. Когда мне нужно написать десяток похожих классов, DTO, схем валидации или обёрток над внешним API, я больше не печатаю их руками. Я описываю структуру словами, иногда кидаю пример одного уже готового класса, и получаю остальные за пару минут. Да, потом я всё равно прохожусь глазами и правлю нейминг, но экономия колоссальная: то, что раньше занимало сорок минут унылого копирования, теперь занимает десять. Второе — тесты. Я не буду врать, что модель пишет идеальные тесты, но она отлично генерирует каркас, набор граничных случаев и скучные параметризованные проверки, до которых у меня руки часто не доходят. Третье — рефакторинг мелких кусков. Попросить разбить длинную функцию на части, вынести дублирование, переименовать переменные по смыслу — это работает на удивление хорошо, особенно если дать модели контекст, зачем это делается.
Четвёртая задача — объяснение чужого и старого кода. У меня в проекте есть модуль, который писал человек, уволившийся ещё до моего прихода, и там комментарии вида «не трогать, работает». Раньше я сидел и пошагово разбирал эту логику сам. Теперь я вставляю функцию и прошу объяснить, что она делает, какие у неё побочные эффекты и где она может сломаться. Пятая — регулярные выражения. Я, наверное, как и многие, умею их читать, но писать с нуля каждый раз — это боль. Модель делает это за секунды, и я потом проверяю на своих примерах. Шестая — разбор логов и стектрейсов. Когда из продакшена прилетает стог ошибок, быстрее всего просто скормить его модели и спросить, какие гипотезы о причине она видит. Седьмая — SQL. Сложные аналитические запросы с оконными функциями, которые я каждый раз гуглю, теперь пишутся в диалоге, и это заметно ускоряет аналитику.
Восьмая задача, которая недооценена, — работа с текстом вокруг кода. Это документация к модулям, понятные описания коммитов, черновики сообщений для тимлида, перевод бизнес-требований в список технических задач. Я часто думаю быстрее, чем формулирую, и модель помогает мне превратить сырые мысли в структуру. Девятая — быстрое погружение в новую технологию или библиотеку. Вместо чтения длинной документации я прошу собрать минимальный рабочий пример под мою задачу, запускаю его, а потом уже лезу в детали. Десятая — ревью собственного кода перед пушем. Я прошу модель посмотреть на дифф и указать на возможные проблемы: обработку ошибок, гонки, забытые кейсы, утечки. Это не заменяет ревью коллеги, но ловит добрую половину глупых ошибок до того, как я отвлеку команду.
Теперь о том, где я обжёгся и чего советую избегать. Модель уверенно придумывает несуществующие методы, параметры и даже целые библиотеки, причём делает это с интонацией эксперта. Она плохо знает ваш внутренний фреймворк, свежие версии пакетов и всё, что не попало в её обучающие данные. Она не понимает бизнес-контекст: то, что выглядит как баг, иногда является осознанным решением, за которое кто-то получил премию. И самое важное — я никогда не отдаю во внешние сервисы клиентские данные, ключи, приватные куски продакшена и вообще ничего, что подпадает под NDA. Это железное правило, и его лучше проговорить с командой заранее, а не после инцидента.
Из этого вытекают мои рекомендации. Во-первых, относитесь к модели как к инструменту для черновика, а не для финального ответа: она генерирует, вы проверяете. Во-вторых, давайте контекст — чем точнее вы опишете задачу, ограничения и то, какой результат хотите, тем меньше мусора получите. В-третьих, начните с безопасных задач: тесты, документация, регулярки, объяснение кода. Там цена ошибки низкая, а выгода мгновенная. В-четвёртых, не пытайтесь делегировать ей архитектурные решения: проектирование системы всё ещё ваша работа, и именно здесь ваш опыт стоит дороже всего. И в-пятых, замерьте свою экономию хотя бы за неделю — обычно после этого скепсис уходит сам собой.
Я не считаю, что нейросеть заменит разработчика, но я точно считаю, что разработчик, который научился с ней работать, будет заметно быстрее того, кто принципиально печатает всё руками. За год практики я вернул себе, наверное, несколько полных рабочих дней в месяц, и потратил их не на рутину, а на задачи, которые мне действительно интересны. А теперь вопрос к вам, форумчане: какие приёмы работы с LLM оказались для вас самыми полезными, что вы пробовали и бросили и есть ли у вас свой список задач, которые вы принципиально не отдаёте нейросети? Буду рад почитать ваш опыт в комментариях.