Как мы реально работаем с AI в середине 2026-го
Хочу зафиксировать, как мы реально работаем с AI сейчас, в середине 2026-го — не прогноз и не манифест, а ежедневную практику, которая успела устояться. Я слежу за этими инструментами уже несколько лет, и поначалу отношение было скорее раздражённым, чем восторженным: AI в редакторе был игрушкой, которая уверенно подсказывала несуществующие методы и ломала поток внимания чаще, чем помогала. В 2025-м случился перелом — инструмент перестал быть автодополнением на стероидах и начал брать на себя законченные куски работы. С тех пор сложился рабочий процесс, и его я и хочу описать. Без пафоса, без обещаний про «конец профессии». Просто то, как это устроено на практике.
Сразу зафиксирую главное, чтобы не было ложных ожиданий. За последние пару лет AI прошёл путь от раздражающей игрушки до инструмента, который реально ускоряет разработку. Прирост есть, он измеримый, и отрицать его сегодня — значит просто не открывать редактор. Но вывод тут не такой, какого ждёшь по инерции: дело не в том, что машина научилась писать код вместо человека. Дело в том, что человек научился раздавать машине ровно ту работу, которую не жалко отдать, и оставлять себе ту, которую отдавать нельзя.
Это не упрощение, а взросление. Разница принципиальная. Упрощение — это когда задача становится тривиальной и про неё можно не думать. Взросление — это когда ты научился думать о задаче иначе: не «как написать этот код», а «кто и на каком шаге должен этот код произвести, проверить и взять за него ответственность». Именно этот сдвиг оптики и есть всё, что произошло с нашей профессией за эти годы. Дальше — как это выглядит на практике.
Workflow держится на разделении ролей, а не на одной кнопке
Самая вредная картинка про работу с AI в 2026-м — это образ единственного всемогущего ассистента, которому ты диктуешь задачу, а он выдаёт готовый pull request. Так не работает, и тех, кто пытался так работать, обычно видно по качеству кодовой базы через полгода. Реальный workflow устроен иначе: это конвейер из трёх принципиально разных уровней ответственности, и путать их между собой — самая дорогая ошибка.
Уровни такие. Внизу — AI на рутине и бойлерплейте, где цена ошибки низкая, а проверка дешёвая. Посередине — агенты на проверяемых операциях, где задача имеет чёткий критерий «сделано правильно». Сверху — человек на архитектуре, решениях и ревью, где ошибка стоит дорого, а критерий правильности нельзя свести к зелёным тестам. Весь смысл зрелого процесса — не дать работе протечь с нижнего уровня на верхний. Самое опасное — это когда архитектурное решение по факту принял агент, просто потому что человек поленился его принять сам.
Почему это так важно? Потому что инструмент не знает, на каком уровне он сейчас находится. Он одинаково уверенно перепишет тебе форматирование и спроектирует слой доступа к данным. Граница между «дёшево отдать» и «нельзя отдавать» проходит не в модели — она проходит в голове инженера. И именно поддержание этой границы стало главным навыком за последние два года.
Внизу машина просто размножает образец без опечаток
Нижний уровень — самый бесспорный и самый скучный. Сюда уходит всё, что раньше съедало время не интеллектом, а механикой. Генерация типовых компонентов по уже существующему паттерну, раскладка DTO, написание однообразных тестов на очевидные случаи, перевод небольшого куска с одного синтаксиса на другой, заполнение длинногоswitch по справочнику, который ты и так держишь перед глазами. Это работа, где есть готовый образец, и задача — размножить его без опечаток.
Здесь AI даёт честный и стабильный прирост, потому что выполняются два условия: ошибка дешёвая и проверка быстрая. Если модель сгенерировала тридцать строк однотипного маппинга и одну строку перепутала, я увижу это за секунды — глазами или на первом же прогоне. Стоимость моей проверки кратно меньше стоимости ручного написания. Вот формула, по которой вообще стоит отдавать работу вниз: отдавай машине то, что дороже написать руками, чем проверить глазами.
Тут же важно не свалиться в другую крайность. Бойлерплейт — это сигнал. Если ты третий раз за неделю просишь сгенерировать один и тот же скелет, проблема не в скорости генерации, а в том, что у тебя нет абстракции, которая этот скелет убирает. AI отлично умеет заклеивать симптом повторяемости и тем самым прятать от тебя архитектурный запах. Поэтому генерацию рутины я рассматриваю не только как экономию времени, но и как индикатор: часто это повод не сгенерировать быстрее, а вынести общий код и больше его не генерировать вовсе.
Агенту можно отдать ровно то, у чего есть машинный критерий «готово»
Средний уровень — самое интересное, что появилось за последний год и реально вошло в ежедневную практику. Агенты — это уже не подсказка в строке, а исполнитель, который сам декомпозирует задачу, ходит по файлам, запускает команды, читает вывод и итерирует. Агентные CLI стали частью обычного инструментария, MCP дал им доступ к внешним системам по понятному контракту, а мульти-агентные схемы позволяют запустить несколько таких исполнителей параллельно на изолированных кусках.
Но ключевое слово здесь — не «агент», а «проверяемый». Агенту можно отдавать ровно ту работу, у которой есть машинно проверяемый критерий успеха. Прогнать миграцию по всему репозиторию и убедиться, что компилируется и тесты зелёные. Поднять покрытие на модуле, где тесты — и есть критерий. Прошерстить кодовую базу на устаревший API и заменить его, где замена механическая. Разобрать упавший прогон, найти причину, починить, дождаться зелёного. Во всех этих случаях у агента есть петля обратной связи, которая ему самому говорит «ещё не готово» или «готово».
А вот там, где критерий «сделано правильно» нельзя выразить машинно, агент опасен. Не потому что он плохой, а потому что он будет уверенно оптимизировать ту метрику, которую ему дали, и ровно настолько, насколько эта метрика совпадает с тем, что тебе на самом деле нужно. Зелёные тесты — это не «код хороший», это «код проходит тесты». Если граница задачи проходит по смыслу, а не по проверке, агент дойдёт до края проверки и остановится, оставив тебе уверенный, аккуратный и неправильный результат. Поэтому моё правило простое: чем размытее критерий успеха, тем выше по уровням поднимается задача — к человеку.
Отдельно про большие контекстные окна и мульти-агентные схемы, на которые сейчас много надежд. Возможность скормить агенту целый модуль и запустить три исполнителя параллельно — это реальное ускорение, и мы им пользуемся. Но это не магически всё решено. Большой контекст не делает решение верным, он делает его более информированным; параллельные агенты не складывают качество, они складывают объём, а сводить их результаты в одно связное целое всё равно приходится человеку. Масштаб вырос — цена ошибки масштаба выросла вместе с ним.
Верхний уровень не сократился — он стал плотнее
Верхний уровень не сократился за эти годы — он стал плотнее. Когда нижние два уровня закрывают механику и проверяемую механику, у человека остаётся концентрат: то, что требует контекста, ответственности и вкуса. Это архитектурные решения — какие границы провести между модулями, какой контракт зафиксировать, что мы сознательно не будем поддерживать. Это компромиссы, у которых нет правильного ответа, только подходящий под нашу ситуацию. И это ревью — не вычитка синтаксиса, а вопрос «мы точно хотим так жить ближайший год».
Ревью, кстати, изменилось сильнее всего, и это стоит проговорить отдельно. Раньше ревью во многом ловило механические дефекты: опечатки, забытую обработку ошибки, неаккуратный кусок. Сейчас механику в основном ловят нижние уровни и линтеры, а до человека код доходит синтаксически чистым и убедительным на вид. Это коварно. Убедительный код проходит беглую проверку легче, чем код корявый, — а ошибка в нём ровно та же или хуже. Поэтому ревью сместилось с «правильно ли это написано» на «правильную ли вещь это делает и впишется ли она в систему». Читать код стали медленнее и внимательнее, а не быстрее.
Здесь и важно быть честным до конца про весь подход. AI не снял с инженера ответственность — он перераспределил её. Раньше ты отвечал за то, что написал. Теперь ты отвечаешь за то, что принял: что пропустил в ревью, какому агенту дал какую задачу, где не стал перепроверять. Ownership никуда не делся, он сместился на шаг выше и стал менее заметным, а потому более коварным. Код, который ты не писал, но смержил, — это твой код. Это самая важная вещь, которую стоит усвоить про работу с AI в 2026-м.
За скорость мы платим, и счёт вполне конкретный
Было бы нечестно описать workflow и умолчать о том, что он не бесплатный. Цена есть, и она вполне конкретная. Перечислю то, с чем сталкиваешься на практике:
- Эрозия навыка. Когда рутину годами пишет машина, мышцы атрофируются. Джуниор, который ни разу не написал тот самый бойлерплейт руками, хуже чувствует, что в нём может сломаться. Это не повод запрещать инструмент, но повод осознанно иногда писать вещи самому — не ради скорости, а ради понимания.
- Иллюзия понимания. Сгенерированный код легко принять за понятый. Ты прочитал, выглядит разумно, смержил — и обнаружил, что не держишь в голове, как он на самом деле себя поведёт в проде. Чтение чужого кода и понимание чужого кода — разные операции, и AI стирает между ними границу.
- Стоимость надзора. Управление агентами — это работа. Сформулировать задачу так, чтобы критерий успеха был машинно проверяем, проверить результат, свести параллельные ветки — всё это время. Иногда проще и быстрее сделать самому, и важно честно это признавать, а не запускать агента из принципа.
- Дрейф контекста. Модель не знает, почему полгода назад вы приняли именно такое неочевидное решение. Она предложит «правильный» рефакторинг, который сломает договорённость, нигде не записанную в коде. Контекст команды живёт в головах и решениях, и пока он туда не вынесен, отдавать его нельзя.
Ничего из этого не отменяет ценности инструмента. Но игнорировать эту цену — значит расплачиваться ею вслепую. Зрелая команда платит её осознанно: иногда пишет руками ради навыка, держит ревью медленным там, где это важно, и не путает скорость генерации с качеством системы.
Есть участки, куда я не пускаю ни AI, ни агентов
Есть участки, где я сознательно не пускаю ни AI, ни агентов, и не считаю это консерватизмом. Это места, где либо нет проверяемого критерия, либо цена ошибки несоразмерна экономии. Решения о безопасности и о данных пользователей — здесь «выглядит правильно» не аргумент. Тонкая работа с конкурентностью и состоянием, где баг невоспроизводим и стоит недели. Установление контракта между сервисами, который переживёт несколько релизов, — wire contract проектируется людьми, потому что цена его смены огромна. И первые версии незнакомой подсистемы, где я сам ещё не понимаю задачу: пока я не могу сформулировать критерий, я не могу его никому делегировать.
Логика везде одна, и она сводится к той же границе. Чем хуже формализуется «сделано правильно» и чем дороже ошибка, тем меньше тут места автоматике и тем больше — голове инженера. Это не про недоверие к технологии. Это про то, что не всякую работу вообще можно делегировать, кем бы ни был исполнитель — человеком или моделью.
Менялся не столько инструмент, сколько мы сами
Полезно держать в голове короткий контекст, как мы сюда пришли, потому что он объясняет логику процесса. Раннее раздражение было по делу: автодополнение, выдающее правдоподобную чушь, мешало работать. В 2025-м случился перелом — не потому, что модель вдруг стала гениальной, а потому, что она стала достаточно надёжной на ограниченном классе задач, и мы научились этот класс очерчивать. К середине 2026-го это уже не новость и не революция, а спокойный рабочий процесс, в котором у каждого уровня своя зона ответственности.
Самое честное, что можно сказать про сегодняшний день: прирост реальный, и мы им пользуемся каждый день без всякого пиетета — просто работаем, и работа идёт ощутимо быстрее, чем пару лет назад. Но это деловая уверенность, а не эйфория. Быстрее — не значит «само». Ускорение пришло ровно там, где мы научились отдавать работу с проверяемым результатом, и нигде больше. Там, где результат не проверяется машинно, всё осталось как было: думать, решать, отвечать.
Из этого видно, что вопрос «заменит ли AI инженера» был поставлен неправильно с самого начала. Рабочий вопрос звучит иначе — «что инженер отдаёт инструменту, а что оставляет себе», и ответ на него индустрия за это время в основном нащупала. Граница между «дёшево отдать» и «нельзя отдавать» — это и есть профессия в её сегодняшнем виде, и проходит она каждый день заново, на каждой конкретной задаче.
Это конвейер из трёх уровней, а не умная кнопка
Если собрать всё вместе, устоявшийся workflow середины 2026-го — это не одна умная кнопка, а конвейер из трёх уровней ответственности: AI на дешёвой и быстро проверяемой рутине, агенты на операциях с машинным критерием успеха, человек на архитектуре, неформализуемых решениях и ревью. Прирост реальный и измеримый, но он держится целиком на том, что мы не путаем уровни и не даём работе протекать снизу вверх. Цена у подхода есть — эрозия навыка, иллюзия понимания, стоимость надзора, дрейф контекста — и зрелая команда платит её осознанно, а не вслепую.
Если сформулировать главный практический вывод совсем прямо, он звучит так. AI в середине 2026-го — это инструмент, который усиливает инженера, а не заменяет его: он берёт на себя проверяемую работу, чтобы человек мог сосредоточиться на решениях, которые проверить нечем, кроме как собственной ответственностью. Всё остальное — детали настройки конвейера, и их каждая команда подкручивает под себя.