Нужен ли мне разработчик, или достаточно AI?

Вопрос уже не в том, может ли AI писать софт. Может. Вопрос в том, кто решает, что должно быть построено, зачем это должно существовать, и заработает ли результат реально для бизнеса.

Нас спросили об этом напрямую, не гипотетически, во время разговора про проект.

Мы дали честный ответ, не защитный.

Ответ, да и нет. И полезная часть не в да или нет. Она в том, где реально проходит граница.

Инструменты вроде Claude Code, Codex и других AI-агентов для кода реально могут писать хороший софт. Они могут читать кодовую базу, планировать реализацию, редактировать несколько файлов, гонять тесты, использовать git, изучать ошибки и итерировать, когда что-то ломается.

Мы сами используем эти инструменты. Они чрезвычайно продуктивны. И они станут намного способнее.

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

Более интересный вопрос в том, что остаётся ценным, когда само исполнение становится всё дешевле.

WHAT AI CHANGES

1. AI уже может удивительно много в исполнении

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

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

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

Но есть важное различие.

Написать решение, не то же самое, что определить решение.

HARDEST PART

2. Самая сложная часть никогда не была в наборе кода

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

Спецификация, это не бизнес. Это чья-то интерпретация того, что бизнесу нужно в конкретный момент.

Это различие становится критичным с AI. AI-агент отвечает на вопрос, что ты ему задал. Он автоматически не знает, был ли это вопрос, что стоило задавать.

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

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

Узкое место смещается вверх по течению.

GENERATION VS JUDGMENT

3. Генерация подешевела. Суждение нет.

Мы писали об этом с другого угла раньше: стоимость AI никогда не была в генерации. Она была в верификации.

Кому-то всё ещё нужно определить, реально ли софт корректен. Не работает ли он. Корректен ли он. Выдержит ли архитектура удвоение бизнеса. Тот ли edge case, что никогда не появился в тестировании, реальный клиент встретит через шесть месяцев. Уместны ли допущения безопасности. Отражает ли модель данных реальный бизнес. Останется ли интеграция поддерживаемой. Решает ли продукт изначальную проблему вообще.

AI всё больше может помогать и с частями этого процесса верификации. И станет лучше в этом.

Мы видели этот разрыв напрямую, не гипотетически, в Четыре AI согласились. Мы всё ещё ничего не проверили.

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

AI WILL IMPROVE

4. AI станет лучше. Это не делает аргумент против него.

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

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

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

Мы не считаем, что с этим стоит спорить. Мы считаем, что это стоит использовать.

Вопрос в том, что происходит с ролью людей, что используют эти инструменты. И здесь становится полезным сравнение с архитектурой.

ARCHITECT ANALOGY

5. Великие архитекторы не тратят карьеру на рисование каждой линии

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

Это не делает его менее важным. Это делает его роль другой.

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

Архитектор ценен не потому, что он самый быстрый в рисовании линии. Он ценен, потому что знает, какие линии должны существовать и зачем.

Софт движется в точно том же направлении.

SOFTWARE ARCHITECT

6. Когда код становится дешёвым, архитектура становится важнее

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

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

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

JUDGMENT LAYER

7. Кому-то нужно понимать продукт, не только промпт

Это то различие, что мы бы провели между AI-инструментом для кода и инженерной командой.

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

Это не аргумент против AI. Это причина использовать AI внутри компетентной команды.

WHERE ENGINEERING MOVES

8. AI не убирает инженерию. Он меняет, где инженерия происходит.

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

Часть инженерной работы смещается от реализации в сторону: discovery → архитектура → спецификация → оркестрация → верификация → эволюция.

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

Потому что когда реализация стоит $100 вместо $10,000, число вещей, что можно построить, становится огромным. Сложный вопрос становится: какие из них реально стоит построить?

MEMORY

9. Продукт, это больше, чем его текущая кодовая база

Есть ещё одно различие, что легко недооценить.

Бизнес накапливает контекст. Почему была выбрана эта архитектура? Почему конкретная фича была отклонена? Почему у этого клиента особый процесс? Какая интеграция сломалась два года назад? Какое допущение оказалось неверным? Какую часть системы нельзя безопасно менять? У какого стейкхолдера реально есть право вето? Почему существует это на первый взгляд странное бизнес-правило из-за реального ограничения?

Часть этого можно задокументировать. Многое из этого исторически живёт в людях.

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

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

ACCOUNTABILITY

10. Кто владеет результатом?

Есть ещё один слой, что технология не может просто стереть. Ответственность.

Если продакшн-система падает в 2 ночи, кому-то нужно решить, что делать. Если AI-сгенерированная реализация создаёт уязвимость безопасности, кому-то нужно взять на себя ответ. Если автоматизированный процесс приводит к потере денег клиентом, кому-то нужно понять бизнес-последствия. Если продукт в итоге решает не ту проблему, кому-то нужно это распознать до того, как на него потратят ещё шесть месяцев разработки.

У AI-агента нет доли в бизнесе. У компетентной команды есть.

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

SHOULD YOU USE AI

11. Так стоит ли использовать AI? Однозначно.

Здесь ответ должен быть намеренно неудобным для традиционного агентства разработки.

Да. Используй его.

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

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

И всё это может улучшить финальный продукт.

Правильный ответ, это не защищать старый процесс разработки. Это сделать процесс лучше.

WRONG QUESTION

12. Неправильный вопрос: «Может ли AI построить мой сайт?»

Вероятно может. Лучший вопрос: может ли AI построить правильный сайт для моего бизнеса? И потом: кто решает, что значит «правильный»?

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

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

Именно здесь команда становится ценной.

NEW TEAM

13. Лучшие команды не будут конкурировать с AI. Они будут работать над ним.

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

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

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

Реальный разлом будет не AI против людей. Он всё больше будет между командами, что знают, как использовать AI, и командами, что не знают. А под этим: командами, что знают, что они строят, против команд, что просто строят то, что им сказали построить.

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

Команда со слабым суждением и чрезвычайно мощным исполнением может стать чрезвычайно эффективной в производстве посредственных продуктов. Команда с сильным суждением и мощными AI-инструментами может стать необычайно продуктивной.

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

PREMIUM CONNECTS

14. Что это значит для того, чем на самом деле является «премиальность»

Это напрямую связано с идеей, что мы разбирали в что реально отличает премиальную сборку на Laravel или Symfony от просто рабочей.

Премиальная сборка софта не премиальна, потому что разработчик набрал каждую строку вручную. И она не премиальна, потому что AI не использовался. Она премиальна, когда система хорошо продумана. Когда её архитектура отражает бизнес. Когда её технические решения намеренны. Когда она может меняться, не разваливаясь. Когда её риски понятны. Когда кто-то знает, почему она построена именно так. И когда люди, что за неё отвечают, могут отличить «код работает» от «продукт работает». Это очень разные утверждения.

Ирония AI в разработке софта в том, что чем лучше AI становится в исполнении, тем менее ценным исполнение становится как отличие. Это уже происходит.

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

Именно это произошло в других профессиональных дисциплинах. Архитекторы не исчезли, когда появился CAD. Дизайнеры не исчезли, когда появился Photoshop. Инженеры не исчезли, когда стал мощным симуляционный софт. Инструменты изменили, на что профессионалы тратят время. Инженерия софта проходит через тот же переход.

SO DO YOU NEED ONE

15. Так нужен ли тебе разработчик?

Иногда. Но это в итоге может быть неправильным способом формулировать вопрос.

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

Этот человек может писать код. Он может руководить разработчиками. Он может работать через AI-агентов. Он может делать всё три.

Работа меняется. Ответственность нет.

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

Команды, что понимают этот переход, не будут конкурировать с AI. Они будут строить лучшие продукты благодаря ему.