Раздел: Компьютерная документация -> Компьютеры -> Разное

Есть у меня привычка, которая бесит половину команды: я не начинаю читать чужой код с начала файла. Открываю diff, смотрю на изменения и пытаюсь угадать, зачем автор это сделал. Иногда угадываю. А иногда сижу в час ночи над стектрейсом длиной в три экрана и понимаю, что уже минут двадцать перечитываю одни и те же строки и не вижу в них ничего.

Раньше в такой ситуации было два пути: идти спать или идти к коллеге. Теперь есть третий — скопировать кусок в чат с нейросетью и попросить: «объясни человеческим языком, что здесь ломается». За последние полтора года это стало самой частой вещью, которую я делаю с ИИ. Не генерация кода с нуля, не «напиши мне приложение за вечер» — а вот эта мелкая, скучная, но бесконечная работа: разобраться, перевести, проверить, переформулировать.

Ниже — не рекламный обзор и не подборка «топ-10 инструментов». Это скорее заметки о том, куда нейросети встроились у меня в рабочий день, что из этого прижилось, а что я попробовал и выкинул.

Сначала я относился к этому скептически

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

Что изменилось? Не столько модели (хотя они стали заметно лучше), сколько я. Я перестал воспринимать их как «автора кода» и начал воспринимать как очень начитанного коллегу, который никогда не устаёт отвечать на глупые вопросы, но при этом иногда уверенно говорит ерунду. С таким коллегой можно работать. С таким коллегой нельзя работать без проверки.

Разница в подходе, на самом деле, огромная. Когда ждёшь от нейросети готового решения — разочаровываешься. Когда используешь её как ускоритель понимания — начинаешь экономить часы.

Стектрейсы, логи и чужая боль

Вернусь к той ночи. Проблема была в проде: сервис начал отдавать 502 на одном эндпоинте, причём не всегда, а примерно раз в двадцать запросов. Логи — три тысячи строк. В глазах уже рябит.

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

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

С тех пор я делаю так почти всегда: сначала прошу не «исправить», а «объяснить и предложить три версии». Три версии — ключевой момент. Если попросить одну, получишь самую правдоподобную, а не самую вероятную. Если попросить три, начинаешь думать сам.

Регулярки, SQL и прочая мелочь, которая съедает день

Вот где нейросети для меня бесспорно полезны — на мелочах.

Регулярное выражение для парсинга строки лога, где формат менялся три раза за два года. SQL-запрос с оконной функцией, которую я каждый раз гуглю, потому что в голове не держится синтаксис ROWS BETWEEN. Bash-однострочник для поиска файлов старше тридцати дней, которые никто не трогал, но которые всё ещё лежат на диске. Команда find с пятью флагами, из которых я помню два.

Всё это раньше означало: открыть поисковик, пролистать Stack Overflow, найти ответ 2013 года, адаптировать под текущую версию. Минут десять на каждую мелочь. За день таких мелочей набирается десяток. Полтора часа, которые просто исчезают.

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

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

Документация, перевод и та самая ссылка

Отдельная боль — документация. Не потому, что её нет, а потому, что её много и она на английском, причём написанном людьми, которые считают, что «simply» и «just» делают объяснение понятнее.

Когда я разбирался с одним внутренним фреймворком, у которого документация представляет собой сто двадцать страниц в Confluence, я делал так: закидывал нужные разделы и просил пересказать своими словами, с примерами на нашем стеке. Не перевести дословно — пересказать. Дословный перевод технических текстов часто бесполезен: слова знакомые, смысл ускользает.

Именно на этом этапе мне пригодился Нейрочат — когда под рукой бесплатная нейросеть, которая спокойно принимает PDF и не требует ни карты, ни регистрации по SMS, разбор чужой документации перестаёт быть отдельным проектом. Загружаешь файл, задаёшь вопрос по конкретной главе, получаешь ответ со ссылкой на страницу. И это принципиально другой режим работы, чем «копировать куски в переводчик и собирать смысл по частям».

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

Ревью, тесты и скучная часть профессии

Есть три вещи, которые я делаю с нейросетью почти автоматически.

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

Второе — объяснение собственного кода через полгода после написания. Открываешь свой же модуль и понимаешь, что автор был явно умнее тебя и явно что-то знал. Спросить некого. Спросить нейросеть — работает.

Третье — code review в роли «второго мнения». Я не заменяю этим ревью коллеги. Но перед тем как отправить MR, прогоняю diff через модель с вопросом: «что здесь может сломаться при конкурентных запросах, чего я не вижу?» Примерно в одном случае из пяти получаю дельную ремарку. В четырёх — «всё хорошо, код читаемый». Двадцать процентов попаданий при затратах в минуту — это очень хорошая экономика.

Где нейросеть врёт, и почему это нормально

А теперь неприятное. Нейросети галлюцинируют, и никакие улучшения последних лет это не отменили. Они выдумывают методы у классов, путают версии библиотек, предлагают конфиги для пакетов, которых не существует, и — самое опасное — уверенно объясняют, почему решение, которое не работает, на самом деле работает.

У меня было три случая, когда я доверился и пожалел. Один раз модель предложила использовать флаг, который удалили из утилиты два мажорных релиза назад. Второй раз — «оптимизировала» SQL-запрос так, что он стал в сорок раз медленнее, потому что добавила подзапрос в WHERE вместо JOIN. Третий раз выдала код, который был корректен, но лицензионно нечист — фрагмент подозрительно совпадал с известной библиотекой под GPL, а у нас коммерческий проект.

Выводы я для себя сделал такие: любой код — на ревью, любые факты про версии и API — в официальную документацию, любой чужой фрагмент — через проверку на плагиат. И ещё одно правило, которое я теперь соблюдаю железно: не копировать в чат секреты. Токены, ключи, пароли, персональные данные, внутренние адреса. Даже если сервис обещает не хранить — привычка важнее обещаний.

Как я формулирую запросы (и почему это важнее модели)

Люди часто спрашивают: какая нейросеть лучше? По моему опыту, разница между «хорошей» и «средней» моделью меньше, чем разница между хорошим и плохим запросом.

Работают примерно такие формулировки:

– «Вот код и вот ошибка. Не исправляй, сначала объясни, что происходит, потом предложи три причины». – «Вот мой вариант. Укажи, что в нём плохо, но не переписывай целиком». – «Дай ответ в виде таблицы: что делаем, чем рискуем, как откатываем». – «Ты — сисадмин, который не любит магию. Объясни, что реально делает эта команда».

Не работают: «напиши мне идеальный код», «сделай быстро», «ну ты понял». Нейросеть не понимает контекста, которого вы не дали. Если вы не сказали, что проект на Python 3.9, а не на 3.12, она будет писать под актуальную версию и вы получите синтаксическую ошибку на ровном месте. Это не её вина.

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

Что я не отдаю нейросети

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

Оценку сроков. Совершенно бесполезно. Любая оценка, которую выдаёт модель, — это среднее по больнице, а не по вашей команде, где один разработчик в отпуске, а второй впервые трогает этот модуль.

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

Что в итоге

Я не стал от этого ни быстрее в десять раз, ни «разработчиком, который не пишет код». Я стал меньше времени тратить на то, что не приносит удовольствия: на поиск синтаксиса, на разбор чужих логов, на перечитывание документации, на формулирование писем. Освободившиеся часы уходят туда, где меня пока никто не заменит, — в понимание того, что вообще нужно сделать и зачем.

И да, тот ночной баг с 502 я тогда закрыл. Не потому, что нейросеть была гениальной, а потому что она подсказала направление, а дальше уже работала голова. Пожалуй, это самая честная характеристика того, чем эти инструменты являются сегодня: не замена, а ускоритель мышления. При условии, что мышление включается.

Опубликовано: 19.10.2026г.