Формат: Мнение Контекст: 2026 год, продакшн‑проекты, AI‑агенты как часть процесса О чём: что реально изменилось в работе разработчика, без хайпа и без хайтерства

Преамбула

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

Сразу про мой контекст, чтобы было понятно с какой позиции я пишу.

Я — соло‑разработчик. У меня в проде несколько продуктов одновременно: мессенджер на React Native + Electron + FastAPI, AI‑платформа с собственным backend'ом, marketing‑автоматизация, и desktop‑приложение для производственного предприятия на Rust + Tauri. Я не cofounder в стартапе с раундом финансирования и пятью junior'ами в команде. Я один человек, который делает несколько продуктов и зарабатывает на этом.

Использую Claude Code в агентском режиме на подписке Max. Это $200/месяц — не дёшево, но в моей экономике это меньше, чем я платил бы одному джуну за два дня работы. По моей грубой оценке, около 70% кода, который попадает в репозитории моих проектов, написано с активным участием AI. Это не значит «Claude взял мою задачу и закодил» — это значит, что я и Claude работаем как‑то совместно, и финальный код — результат этой совместной работы.

Ниже — что я об этом думаю после года такого режима.

Главный тезис: моя роль изменилась, но не исчезла

Год назад моя работа состояла из двух больших частей: придумать как сделать и сделать. Сейчас осталась почти только первая часть.

Это не значит что я не пишу код руками. Пишу — но другой. То, что раньше занимало часы (написать CRUD‑эндпоинт, сверстать форму, реализовать стандартный паттерн) — сейчас занимает минуты. Не потому что я стал быстрее печатать, а потому что для этих задач я не печатаю код. Я формулирую что мне нужно, проверяю результат, корректирую.

То, что не ушло — это все архитектурные решения. Почему именно три уровня кэша, а не два. Какие индексы в SQLite положить и почему именно по этим колонкам. Когда стоит делать собственную реализацию протокола, а когда взять готовую библиотеку. Это решения, которые AI не принимает за меня — он может предложить варианты, но выбираю я.

И это, на мой взгляд, правильное распределение труда. Скучную, повторяющуюся, шаблонную часть работы делает машина. Содержательную, контекстно‑зависимую, требующую понимания продукта — делаю я. Раньше я был вынужден делать обе части, потому что других вариантов не было. Теперь могу сосредоточиться на одной.

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

Что AI делает хорошо в моих руках

Не претендую на универсальность — это мой опыт, в моих стеках. У меня FastAPI на бэкенде и React Native на фронте — две очень популярные технологии с огромным количеством примеров в обучающих данных. AI на них работает хорошо. Если у вас Erlang или OCaml — ваш опыт может сильно отличаться.

Что у меня работает стабильно: написание стандартных UI‑компонентов в React Native, бойлерплейт API‑эндпоинтов на FastAPI, миграции Pydantic‑схем, простые refactor'ы в духе «переименуй переменную везде и обнови импорты», добавление новой функциональности по существующему паттерну («у меня есть endpoint для X, сделай по аналогии для Y»).

Особенно хорошо AI делает то, что я раньше делал плохо — писал документацию и комментарии к коду. Раньше я их откладывал на потом и потом не возвращался. Теперь они появляются вместе с кодом, потому что попросить написать док‑строку — это один промпт, а не отдельное дело на тридцать минут.

Что у AI получается плохо — общими словами

Не буду выдумывать конкретные истории «AI меня предал». Расскажу паттернами того что я наблюдаю.

Костыли вместо использования возможностей стека. AI иногда пишет 200 строк кода для задачи, которая решается одним вызовом библиотеки или одной фичей стандартной библиотеки. Это происходит чаще всего когда задача описана недостаточно конкретно — AI берёт первое подходящее решение, не оценивая альтернативы. Лечится более точным промптом («используй встроенную возможность X, не пиши своё») и code review.

Логические ошибки, которые компилируются. Самый коварный тип ошибок. Код выглядит грамотно, проходит линтер, проходит тесты которые сам AI к нему написал. А в проде в каком‑то edge‑case он работает не так, как нужно. Эта категория ошибок — главная причина почему я читаю каждую строчку которую генерирует AI, даже если она в итоге попадает в код почти без изменений.

Неоптимальные алгоритмы. AI любит O(N²) там где можно O(N), любит создавать промежуточные структуры данных, любит мапить‑фильтровать‑сводить там где хватило бы одного прохода. Для большинства задач это неважно — даже плохо написанный код выполняется за миллисекунды. Но когда речь о hot path или о работе с большими данными, профайлер показывает что AI‑сгенерированный код можно ускорить в 10–50 раз простыми переписываниями.

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

Что я не доверяю AI

Несколько категорий задач, где я либо не использую AI вообще, либо использую с особой тщательностью проверяя каждую строчку.

Security‑критичный код. Криптография, аутентификация, обработка пользовательского ввода, всё что связано с правами доступа. AI здесь не «пишет неправильно» — он часто пишет правильно по форме, но может пропустить тонкость которая в данном контексте критична. Цена ошибки несоизмерима с экономией времени, поэтому здесь я работаю медленнее и руками.

Архитектурные решения. Не «напиши класс X», а «как нам построить N‑сервис чтобы он масштабировался». AI хорошо генерирует код по чёткому ТЗ. Хуже — придумывает само ТЗ. Архитектура — это в основном про компромиссы между конкурирующими требованиями. AI имеет тенденцию выбирать самый стандартный путь, что не всегда правильно.

Миграции данных в продакшн БД. Любой код, который имеет необратимые последствия для production. Здесь не работает «проверил локально, выкатываем» — здесь нужно понимать что произойдёт со всеми данными которые сейчас в БД. Это область где я плачу больше за то, чтобы сделать руками.

Что меняется в моих привычках

Несколько вещей я заметил в своей работе которые меня немного удивили.

Я стал больше думать перед тем как писать. Парадокс — раньше я часто писал‑проверял‑переписывал в коде, потому что это было быстрее чем рисовать в голове. Сейчас, прежде чем формулировать промпт, я обдумываю задачу полнее. Плохо сформулированный промпт даёт плохой код, и переделать его иногда дольше чем написать с нуля. Это похоже на ситуацию когда у меня был бы джун — я тратил бы время на то чтобы правильно объяснить задачу, потому что иначе джун потратит день впустую.

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

Я больше читаю чужой код. Звучит странно, но AI‑генерированный код — это всё равно чужой код, который мне надо понять прежде чем принять в свой репозиторий. Этого чтения у меня больше чем было год назад. Это полезная мышца — я лучше стал ориентироваться в незнакомом коде в целом.

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

Почему я не боюсь что AI меня заменит

Этот вопрос задают чаще всего, и я устал от обоих стандартных ответов — «AI скоро заменит всех» и «AI никогда не заменит настоящего разработчика». Оба ответа — это идеологические позиции, не наблюдения.

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

То что AI не заменил — это решения. Не «какой код написать», а «какую систему построить, для каких пользователей, с какими компромиссами, в какой последовательности». Эти решения требуют знания продукта, рынка, юзеров, бизнес‑контекста. AI этого контекста не имеет — и не будет иметь, пока соло‑разработчик сам не передаст его. А пока разработчик это делает — он остаётся незаменимым звеном.

Может ли это измениться? Возможно. Может ли AI стать способным самостоятельно проектировать продукт от идеи до релиза? Технически — наверное, когда‑нибудь. Практически — я не вижу этого в течение года‑двух точно. И если это произойдёт через пять лет, у меня будет пять лет на адаптацию к новой реальности, как и у всех нас.

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

Можно ли в одиночку делать то что я делаю — без AI?

Этот вопрос я задавал себе несколько раз. Честный ответ — да, можно. Без AI я бы делал ту же работу, просто на это уходило бы существенно больше времени. Возможно в два‑три раза больше. Вместо параллельной работы над несколькими продуктами я бы концентрировался на одном.

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

Заключение

Год вайб‑кодинга в продакшне — это год привыкания к новому режиму работы. Без эйфории, без катастрофы. Просто другой способ делать ту же работу.

Главный вопрос на 2026 год для соло‑разработчика, на мой взгляд, не «использовать ли AI» (тут ответ очевиден), и не «как использовать AI лучше всех» (тут много гайдов, выбирайте под себя). Главный вопрос — что вы будете делать с освободившимся временем.

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

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

Это пятая статья из моей серии про разработку. В предыдущих были конкретные кейсы из проектов: трёхуровневый кэш сообщений, Double Ratchet E2E, WebRTC звонки, vanilla Electron desktop. Эта — другой жанр, наблюдения общего характера. Если вы читаете и думаете «у меня иначе» — расскажите в комментариях. Мне интересно понять насколько мой опыт типичен или нет.