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

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

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

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

Что показывают исследования

Тема уже вышла за пределы личных ощущений. В 2025 году Microsoft Research и Carnegie Mellon опубликовали исследование про влияние генеративного AI на критическое мышление knowledge workers. Они опросили 319 специалистов и собрали 936 реальных примеров использования AI в рабочих задачах. Один из важных выводов звучит очень знакомо: чем выше доверие к AI, тем меньше усилий человек тратит на критическое мышление. А чем выше уверенность человека в собственных навыках, тем активнее он проверяет и осмысляет результат.

То есть проблема не в самом AI. Проблема в режиме использования. Если модель становится инструментом для проверки, ускорения и расширения вариантов — это одно. Если она становится заменой внутреннего диалога — совсем другое.

В исследованиях по программированию картина похожая. Например, в Google провели randomized controlled trial с 96 инженерами и получили примерно 21% сокращение времени на enterprise-grade задаче при использовании AI-инструментов. Это хороший результат. Но даже в таких работах исследователи подчёркивают: продуктивность разработчика сложно измерять только временем, потому что AI меняет сам процесс работы.

Есть и другая сторона. В статье The Widening Gap про novice programmers исследователи заметили, что сильные студенты использовали GenAI как ускоритель: они уже понимали, что хотят написать, и могли отфильтровать плохие подсказки. А тем, кто и так испытывал трудности, AI иногда добавлял новые метакогнитивные проблемы: отвлекал, уводил не туда и создавал иллюзию компетентности.

Мне кажется, этот вывод касается не только новичков. У опытных инженеров иллюзия компетентности тоже возможна. Просто выглядит она солиднее: не «я скопировал ответ из ChatGPT», а «агент сделал diff, тесты вроде зелёные, значит можно принимать».

AI меняет не только скорость, но и мышечную память

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

Когда мы часто работаем без AI, эта цепочка тренируется сама собой. Не всегда приятно, иногда медленно, зато мозг удерживает карту местности. Ты понимаешь, почему ошибка возникла, какие решения уже пробовал, где границы системы и что может сломаться рядом.

С AI часть этой цепочки можно пропустить. Модель быстро находит подозрительное место, предлагает фикс и объясняет его уверенным голосом. В моменте это кайф. Но если всё время пропускать этапы, они начинают слабеть.

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

Первое правило: сначала своя гипотеза, потом AI

Самая простая практика, которая мне помогает: перед тем как спросить AI, сформулировать свою версию. Даже если она сырая. Даже если занимает две минуты.

Например, не сразу писать: «почему падает тест?» А сначала самому ответить:

что именно падает;
какое поведение я ожидал;
какая часть системы может быть причиной;
что я проверю первым;
какой результат подтвердит или опровергнет гипотезу.

После этого AI становится не костылём, а собеседником. Ты не просишь его думать вместо тебя. Ты приносишь ему свою модель мира и говоришь: «проверь, где я ошибаюсь».

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

Второе правило: не принимать объяснение, пока не можешь пересказать

AI умеет объяснять очень убедительно. Иногда настолько убедительно, что хочется кивнуть и пойти дальше. Но хорошая проверка простая: могу ли я объяснить это решение другому человеку без помощи модели?

Если нет — я ещё не понял. У меня просто есть текст, который выглядит как понимание.

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

Полезный приём: после ответа AI закрыть чат и своими словами написать короткое резюме. Не красиво, не для документации, а для себя:

Проблема была в том, что сервис возвращал пустой список не как ошибку, а как валидный результат. Старый тест ожидал exception и поэтому проверял не тот контракт. Мы поменяли проверку на явное ожидание пустого массива и добавили негативный кейс для настоящей ошибки API.

Если такое резюме не получается, лучше не принимать изменение сразу. Значит, понимание ещё не догнало скорость генерации.

Третье правило: иногда отлаживать руками

Да, AI может быстро разобрать stack trace. Да, агент может сам запустить тесты, прочитать лог и предложить фикс. Но если всегда отдавать ему отладку целиком, очень легко потерять навык расследования.

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

Иногда полезно вообще устроить себе маленький “manual mode”: один баг или один тест пройти без AI. Не потому что так быстрее. Обычно медленнее. Но это как тренировка. Нельзя всё время ездить на лифте и ожидать, что ноги останутся в форме.

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

Четвёртое правило: ревьюить AI как человека, а не как оракула

Я всё чаще ловлю себя на мысли, что AI-результат нужно ревьюить примерно как код junior-разработчика. Не снисходительно, а внимательно.

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

Поэтому при просмотре diff я задаю себе несколько вопросов:

каждое изменение относится к задаче?
не появился ли незапрошенный рефакторинг?
не изменился ли контракт API или поведение теста незаметно?
не добавилась ли сложность “на будущее”?
есть ли проверка именно того сценария, ради которого всё делалось?
смогу ли я защитить это решение на ревью?

Главная ловушка — зелёные тесты. Они важны, но не являются доказательством правильности. Тесты могут быть неполными, мок может быть неверным, сценарий может не покрывать реальный edge case. AI особенно хорошо создаёт ощущение завершённости: diff есть, отчёт есть, тесты прошли. Но инженерное мышление как раз начинается там, где мы спрашиваем: «а что именно мы проверили?»

Пятое правило: просить не только ответ, но и альтернативы

Если попросить AI «реши задачу», он часто даст один путь. Иногда хороший. Иногда первый попавшийся. Чтобы не застрять в его траектории, полезно просить варианты:

Предложи 2-3 подхода. Для каждого покажи плюсы, минусы, риски и когда ты бы его не выбирал.

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

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

Шестое правило: не путать скорость с ростом

AI может создать ощущение, что ты резко стал сильнее. И частично это правда: ты быстрее делаешь задачи, быстрее читаешь незнакомый код, быстрее пишешь черновики. Но рост навыка — это не только результат на выходе. Это ещё и то, что осталось в голове после задачи.

Если после работы с AI я могу объяснить систему лучше, чем до неё, значит, инструмент помог мне вырасти. Если я просто получил готовый diff и не понимаю деталей, значит, я купил скорость ценой понимания.

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

Как я стараюсь держать баланс

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

Перед запросом к AI я формулирую свою гипотезу хотя бы в одной фразе.
Для неоднозначных задач прошу сначала план и допущения, а не сразу код.
После сложного ответа пересказываю решение своими словами.
Не принимаю diff, если не понимаю каждое существенное изменение.
Иногда специально разбираю баг без AI, чтобы не терять навык отладки.
Прошу альтернативы, когда задача архитектурная или продуктовая.
Отдельно проверяю факты, ссылки, версии библиотек и всё, что модель могла уверенно придумать.

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

Где AI действительно помогает мышлению

Важно не уйти в другую крайность. AI не только ослабляет мышление. При правильном использовании он может его усиливать.

Он помогает увидеть альтернативу, которую ты не рассматривал. Может объяснить незнакомый кусок кода. Может сформулировать контраргумент. Может найти дыру в плане. Может быстро собрать список edge cases. Может выступить в роли резиновой уточки, только более разговорчивой.

Мне особенно нравится использовать AI в режиме спора:

Вот мой подход. Покритикуй его. Где я переусложняю? Какие риски не вижу? Какой самый простой вариант решит задачу?

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

Главный вывод

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

AI в 2026 году — сильный рабочий инструмент. Я не хочу от него отказываться и не вижу в этом смысла. Но хочу использовать его так, чтобы через год стать не просто быстрее, а сильнее как инженер.

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

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

Ссылки

Как не потерять инженерное мышление, работая с AI каждый день