Постоянное переключение между задачами – одна из привычных проблем в работе разработчика. Нужно разобраться с ошибкой в коде, проверить SQL-запрос, а вечером ещё переключится на учёбу и бытовые дела. В итоге много времени уходит даже не на саму задачу, а на то, чтобы снова восстановить контекст.
B cтатье backend-разработчик и автор курсов по программированию IT Gopher делится своим опытом использования ИИ в таких ситуациях и рассказывает, как с его помощью сохранять ход рассуждений, разбирать сложные задачи и быстрее возвращаться к работе после перерыва.
В какой-то момент я заметил, что устаю не столько от количества задач, сколько от постоянного переключения между ними. На работе нужно разобраться, почему медленно отвечает API, проверить SQL-запрос или понять, на каком этапе пропало сообщение. После работы нужно заниматься дипломом, изучать новые темы и готовиться к собеседованиям. Между всем этим остаются тренировки, питание и обычные бытовые дела.
Сами задачи по отдельности обычно решаемы, сложнее после каждого перерыва заново погружаться в контекст, вспоминать, что уже проверено, какие версии отброшены, почему я выбрал именно это направление и что собирался делать дальше. Иногда на такое возвращение уходило больше сил, чем на следующий шаг.
Сначала я использовал ИИ вполне обычно, просил написать небольшой фрагмент кода, составить запрос или объяснить незнакомую тему. Со временем я понял, что его главная польза для меня не в скорости написания текста. Он помогает в тот момент, когда проблема уже видна, но ещё непонятно, что именно проверять дальше. Постепенно ИИ стал для меня не источником готовых ответов, а инструментом, с которым проще разобрать задачу и сохранить ход рассуждений. Можно сказать, стал моим маленьким сторонним мозгом, к которому я могу подключиться.
Если коротко, ИИ помогает мне:
Сами задачи по отдельности обычно решаемы, сложнее после каждого перерыва заново погружаться в контекст, вспоминать, что уже проверено, какие версии отброшены, почему я выбрал именно это направление и что собирался делать дальше. Иногда на такое возвращение уходило больше сил, чем на следующий шаг.
Сначала я использовал ИИ вполне обычно, просил написать небольшой фрагмент кода, составить запрос или объяснить незнакомую тему. Со временем я понял, что его главная польза для меня не в скорости написания текста. Он помогает в тот момент, когда проблема уже видна, но ещё непонятно, что именно проверять дальше. Постепенно ИИ стал для меня не источником готовых ответов, а инструментом, с которым проще разобрать задачу и сохранить ход рассуждений. Можно сказать, стал моим маленьким сторонним мозгом, к которому я могу подключиться.
Если коротко, ИИ помогает мне:
- собрать разрозненные факты и понять, с чего начать проверку;
- сохранить ход мыслей, чтобы после перерыва не начинать всё заново;
- заметить пробелы в знаниях и слабые места в собственных выводах;
- тратить меньше сил на мелкие решения в учёбе и повседневных делах.
Не один чат, а разные режимы работы
Один формат с чатом быстро оказался неудобен для разных задач и на помощь подошли агенты. Claude я обычно использовал для долгих обсуждений, например при работе над главой диплома, большой статьёй или архитектурным решением. Cursor был полезен непосредственно во время работы с кодом, когда нужно видеть соседние файлы и сразу вносить небольшие изменения. Codex я подключал к более конкретным задачам внутри репозитория, например чтобы пройтись по связанным файлам, сравнить реализацию с тестами, изменить нужное поведение и запустить проверки.
В одном случае нужно быстро разобрать свои мысли, в другом несколько раз критически пересмотреть решение, в третьем внимательно изучить отдельный модуль. При этом границы задачи всегда задаю я сам. Заранее указываю, что можно менять, какой результат считаю готовым, какие проверки нужно выполнить и что отдельно перечислить, если что-то проверить не получилось.
Постепенно у меня сложился простой рабочий порядок. Сначала я собираю известные факты и отделяю их от предположений, затем выбираю следующую проверку, выполняю её в реальной системе и кратко фиксирую результат. ИИ помогает не потеряться в этом процессе, но окончательный ответ всё равно дают тесты, метрики, профилирование, документация и моя собственная проверка.
В одном случае нужно быстро разобрать свои мысли, в другом несколько раз критически пересмотреть решение, в третьем внимательно изучить отдельный модуль. При этом границы задачи всегда задаю я сам. Заранее указываю, что можно менять, какой результат считаю готовым, какие проверки нужно выполнить и что отдельно перечислить, если что-то проверить не получилось.
Постепенно у меня сложился простой рабочий порядок. Сначала я собираю известные факты и отделяю их от предположений, затем выбираю следующую проверку, выполняю её в реальной системе и кратко фиксирую результат. ИИ помогает не потеряться в этом процессе, но окончательный ответ всё равно дают тесты, метрики, профилирование, документация и моя собственная проверка.
Схема 1. Рабочий цикл с ИИ
Кейс 1. Когда «данные пропадают» — слишком плохое описание
В одном из проектов бэкенд получал данные через REST, WebSocket и автоматизированный браузер, сохранял их в базу, а часть событий отправлял через брокер. Иногда проблему описывали просто: «данные пропали», «данных недостаточно» Но для поиска причины такая формулировка почти ничего не даёт. Она уже предполагает, что данные успешно пришли в систему, а потом где-то потерялись. На практике источник мог их вообще не отправить, десериализация могла завершиться ошибкой, обработка могла прерваться, а запись в базу могла не выполниться.
Сначала я пытался искать проблему сразу в нескольких местах. Проверял логи, код записи в базу и обработчик очереди, но целостной картины всё равно не было. Тогда я перестал спрашивать ИИ, почему теряются данные. Вместо этого описал все этапы обработки и попросил восстановить полный путь события, пока ничего не меняя в коде. Агент прошёлся по связанным файлам и помог найти участки, где пропадал идентификатор, игнорировалась ошибка или просто не хватало информации для проверки.
Запрос выглядел примерно так:
Сначала я пытался искать проблему сразу в нескольких местах. Проверял логи, код записи в базу и обработчик очереди, но целостной картины всё равно не было. Тогда я перестал спрашивать ИИ, почему теряются данные. Вместо этого описал все этапы обработки и попросил восстановить полный путь события, пока ничего не меняя в коде. Агент прошёлся по связанным файлам и помог найти участки, где пропадал идентификатор, игнорировалась ошибка или просто не хватало информации для проверки.
Запрос выглядел примерно так:
«Для каждого этапа предложи, что нужно фиксировать, чтобы проследить путь одного события. Покажи, где нужны счётчики и как убедиться, что этап завершился успешно. Не называй причину, пока её нельзя подтвердить этими данными».
После этого в системе появился единый идентификатор события, счётчики на основных этапах, категории ошибок, а также информация о времени обработки и повторной доставке. Теперь вместо общего вопроса «где-то что-то потерялось» можно было увидеть, сколько событий пришло, сколько прошло проверку, сколько записалось в базу и сколько было отправлено дальше. Если между двумя этапами число уменьшалось, область поиска сразу становилась намного уже.
В этом случае ИИ не нашёл ошибку сам, а помог точнее сформулировать проблему, выстроить путь события и понять, каких данных не хватает, чтобы двигаться дальше.
В этом случае ИИ не нашёл ошибку сам, а помог точнее сформулировать проблему, выстроить путь события и понять, каких данных не хватает, чтобы двигаться дальше.
Кейс 2. Почему ИИ не должен начинать с оптимизации
В проекте, связанном с арбитражем в Solana, процесс потреблял около 6 ГБ памяти. После изменений этот объём удалось снизить примерно до 1 ГБ. Сначала я пошёл по самому очевидному пути и спросил у ИИ, как уменьшить потребление памяти в Go. В ответ получил стандартный набор советов: сократить количество аллокаций, переиспользовать буферы, пересмотреть структуры данных и попробовать sync.Pool. Все эти рекомендации были разумными, но без измерений непонятно, какие из них вообще относятся к реальной причине проблемы. Можно потратить несколько часов на оптимизацию кода, который почти не влияет на общее потребление памяти.
Поэтому я изменил порядок работы и снял heap profile и зафиксировал сценарий нагрузки, чтобы дальнейшие результаты можно было сравнивать в одинаковых условиях. Затем передал профиль ИИ и попросил связать основные строки отчёта с конкретными функциями проекта. Отдельно указал, что нужно разделить факты, которые видны в профиле, и предположения, которые ещё предстоит проверить.
Запрос выглядел примерно так:
Поэтому я изменил порядок работы и снял heap profile и зафиксировал сценарий нагрузки, чтобы дальнейшие результаты можно было сравнивать в одинаковых условиях. Затем передал профиль ИИ и попросил связать основные строки отчёта с конкретными функциями проекта. Отдельно указал, что нужно разделить факты, которые видны в профиле, и предположения, которые ещё предстоит проверить.
Запрос выглядел примерно так:
«Сопоставь строки heap profile с функциями проекта. Отдели то, что подтверждается профилем, от гипотез. Предложи один эксперимент, который поможет понять, память долго удерживается или приложение создаёт слишком много временных объектов. Код пока не меняй».
Когда появилась конкретная гипотеза, агент внёс небольшое изменение и запустил тесты, однако результат я оценивал только после повторного замера при той же нагрузке. Без этого легко принять изменение входных данных или случайное колебание за реальное улучшение.
После этого случая я почти перестал начинать с просьбы «оптимизируй код». Сначала нужны измерения и понятная гипотеза, затем небольшое изменение и повторная проверка. В таких задачах ИИ оказался полезнее при разборе профиля и поиске направления для эксперимента, чем при выдаче общих советов по оптимизации.
После этого случая я почти перестал начинать с просьбы «оптимизируй код». Сначала нужны измерения и понятная гипотеза, затем небольшое изменение и повторная проверка. В таких задачах ИИ оказался полезнее при разборе профиля и поиске направления для эксперимента, чем при выдаче общих советов по оптимизации.
Учёба и диплом: не писать за меня, а находить слабые места
В обучении мне долго мешало ощущение, что тема уже знакома. Я узнавал термины про PostgreSQL, индексы или MVCC и думал, что в целом понимаю материал. Но стоило копнуть в тему чуть глубже и уверенность пропадала. Поэтому вместо очередного конспекта я начал использовать ИИ как интервьюера.
Один из запросов выглядел так:
Один из запросов выглядел так:
«Проведи собеседование по индексам PostgreSQL. Задавай по одному вопросу. После моего ответа указывай только на неточности и задавай один уточняющий вопрос. В конце перечисли темы, в которых я отвечал хуже всего».
После такого разговора остаётся не общее ощущение, что PostgreSQL нужно ещё подучить, а конкретный список слабых мест. Например, MVCC, уровни изоляции или выбор плана выполнения запроса. Через несколько дней я могу вернуться именно к этим вопросам и проверить, стал ли отвечать лучше. Иногда вместо обычных вопросов прошу дать практическую задачу, например объяснить план запроса, подобрать индекс или найти ошибку в конкурентном коде.
С дипломом я пришёл примерно к тому же подходу. Сначала просил ИИ писать большие фрагменты текста и получал аккуратные абзацы, которые звучали убедительно, но которые я не всегда мог нормально защитить. После этого начал приносить свои тезисы и просить модель вести себя как член комиссии. Мне было важно не переписать текст красивее, а найти слабые выводы, спорные утверждения и места, по которым мне могут задать неудобный вопрос.
Запрос мог выглядеть так:
С дипломом я пришёл примерно к тому же подходу. Сначала просил ИИ писать большие фрагменты текста и получал аккуратные абзацы, которые звучали убедительно, но которые я не всегда мог нормально защитить. После этого начал приносить свои тезисы и просить модель вести себя как член комиссии. Мне было важно не переписать текст красивее, а найти слабые выводы, спорные утверждения и места, по которым мне могут задать неудобный вопрос.
Запрос мог выглядеть так:
«Представь, что ты член комиссии. Не переписывай текст. Найди выводы, для которых не хватает доказательств, составь вопросы по этим местам и отдельно отметь технические утверждения, которые стоит проверить по источникам».
В итоге в учёбе ИИ оказался для меня полезен не как источник готовых знаний и не как автор диплома. Он помогает заметить разницу между ситуацией, когда термин просто кажется знакомым, и ситуацией, когда я действительно могу объяснить тему своими словами.
Быт и самоорганизация: меньше решений каждый день
Похожая проблема была с питанием и тренировками. Каждый день приходилось заново решать, что есть, когда заниматься и как вообще вместить это между работой и учёбой. Несколько раз я составлял идеальный план, который должен был начаться с понедельника, но потом появлялась срочная задача, режим сбивался, и всё приходилось начинать заново.
Я описал ИИ свой реальный график, привычные продукты и количество свободного времени. Попросил составить не идеальный режим, а такой, которого можно придерживаться из недели в неделю. Потом возвращался с конкретными наблюдениями, рассказывал, какие тренировки чаще всего пропускаю, какой приём пищи неудобно готовить и в какие дни после работы уже ни на что не хватает сил. Вместо того чтобы каждый раз составлять новый план, я менял одну или две детали и смотрел, стало ли лучше.
В результате мне удалось похудеть на 10 килограммов. Но главным изменением для меня было даже не это- питание и тренировки наконец-то перестали каждый день начинаться с нуля, а вместо мысли «мне просто не хватает дисциплины» появлялось более конкретное объяснение. Например, если я три раза подряд пропустил часовую тренировку после работы, значит, проблема может быть во времени или продолжительности занятия, и тогда можно изменить один параметр и посмотреть, поможет ли это.
В таких задачах ИИ помогает сократить количество ежедневных решений и спокойнее разбирать причины срывов, не отказываясь сразу от всего плана. При этом вопросы диагностики и лечения я с ним не решаю, здесь последнее слово всегда остаётся за врачом.
Я описал ИИ свой реальный график, привычные продукты и количество свободного времени. Попросил составить не идеальный режим, а такой, которого можно придерживаться из недели в неделю. Потом возвращался с конкретными наблюдениями, рассказывал, какие тренировки чаще всего пропускаю, какой приём пищи неудобно готовить и в какие дни после работы уже ни на что не хватает сил. Вместо того чтобы каждый раз составлять новый план, я менял одну или две детали и смотрел, стало ли лучше.
В результате мне удалось похудеть на 10 килограммов. Но главным изменением для меня было даже не это- питание и тренировки наконец-то перестали каждый день начинаться с нуля, а вместо мысли «мне просто не хватает дисциплины» появлялось более конкретное объяснение. Например, если я три раза подряд пропустил часовую тренировку после работы, значит, проблема может быть во времени или продолжительности занятия, и тогда можно изменить один параметр и посмотреть, поможет ли это.
В таких задачах ИИ помогает сократить количество ежедневных решений и спокойнее разбирать причины срывов, не отказываясь сразу от всего плана. При этом вопросы диагностики и лечения я с ним не решаю, здесь последнее слово всегда остаётся за врачом.
Схема 2. Как изменился подход к задачам
Правила, без которых подход быстро перестаёт работать
- Начинать с фактов. Вместо фразы «сервис работает медленно» лучше указать конкретные значения, нагрузку и участок, на котором появляется задержка.
- Просить не готовый ответ, а способ проверки. Для каждой гипотезы должны быть понятны ожидаемый признак и действие, которое поможет её подтвердить или отбросить.
- Фиксировать результат. После каждой проверки полезно коротко записывать, что было сделано, что получилось, какие версии отпали и какой шаг будет следующим.
- Проверять всё вне чата.
- Сразу задавать границы. Важно заранее указать, какие файлы можно менять, какие проверки обязательны и какой результат считается готовым. Секреты, персональные данные и другую чувствительную информацию в чат лучше не передавать.
Что в итоге изменилось
ИИ не стал помнить за меня всё и не сделал меня автоматически продуктивнее. Он не заменил знания Go и PostgreSQL, не написал за меня диплом и, конечно, не может сходить вместо меня на тренировку.
Но, когда ломается сервис – я быстрее собираю факты и понимаю, что проверять дальше. Когда изучаю новую тему – возвращаюсь к вопросам, на которых запутался, а не начинаю читать всё с самого начала. Когда перестаёт работать план на неделю – меняю конкретную часть, а не пытаюсь снова полностью перестроить свою жизнь с понедельника.
Поэтому выражение «второй мозг» мне всё ещё нравится, хотя оно и не совсем точное. ИИ не знает ничего вместо меня и не принимает решения за меня. Он просто помогает не держать в голове десятки незаконченных мыслей, сохранять ход работы и возвращаться к задаче через несколько дней не с пустого места.
Но, когда ломается сервис – я быстрее собираю факты и понимаю, что проверять дальше. Когда изучаю новую тему – возвращаюсь к вопросам, на которых запутался, а не начинаю читать всё с самого начала. Когда перестаёт работать план на неделю – меняю конкретную часть, а не пытаюсь снова полностью перестроить свою жизнь с понедельника.
Поэтому выражение «второй мозг» мне всё ещё нравится, хотя оно и не совсем точное. ИИ не знает ничего вместо меня и не принимает решения за меня. Он просто помогает не держать в голове десятки незаконченных мыслей, сохранять ход работы и возвращаться к задаче через несколько дней не с пустого места.
