Архитектор, параноик, фантазёр и другие сотрудники IT-компании будущего
Известно, что развитие часто идёт по спирали. Сейчас мы, кажется, находимся на очередном технологическом витке, когда вход в профессию IT становится сложнее - возможно, даже сложнее, чем 30 лет назад, когда программисты считались гиками и заумными чудаками, которых многие сторонились и держались от них подальше.
Конечно, здесь легко возразить: сейчас любой человек может открыть Codex или другое AI-средство разработки, описать свою идею и за несколько часов получить некий IT-продукт, который будет выглядеть вполне настоящим. И это действительно так. Но только отчасти.
Я наблюдаю за коллегами, партнёрами, студентами и просто знакомыми, у которых нет классического образования программиста, но которые с помощью генеративного ИИ пытаются создавать цифровые продукты. И довольно часто оказывается, что ИИ резко снизил стоимость создания программного кода, но почти не снизил стоимость понимания того, какой код вообще нужно создавать.
Можно быстро получить красивый интерфейс, API, базу данных и даже развернуть всё это на сервере. Но за внешней убедительностью нередко скрываются непонимание архитектуры, неконтролируемые зависимости, отсутствие нормального тестирования, странные решения по работе с данными и требованиями безопасности. Код становится неуправляемым, системы начинают ломаться в самых неожиданных местах, а результаты их работы - непредсказуемыми.
Именно поэтому мне кажется ошибочной мысль, что ИИ делает профессиональных разработчиков ненужными. Скорее наоборот: ИИ делает производство кода дешёвым, а архитектуру, ответственность, инженерное мышление и здравый смысл - более дорогими.
Раньше разработчик преимущественно писал код. Теперь сильный разработчик всё чаще проектирует ограничения, правила и архитектуру, внутри которых код пишет машина.
Отсюда мои размышления привели меня к следующей модели. Современная небольшая AI-native IT-компания - это уже не уменьшенная копия большой IT-компании. Это небольшое человеческое ядро из сильных универсальных специалистов, окружённое цифровыми исполнителями.
Я бы построил команду разработки такой компании примерно из следующих ролей:
1. Системный и бизнес-аналитик.
В небольшой компании эти роли, на мой взгляд, имеет смысл объединять в одном сильном специалисте. Он должен быть гуру в предметной области или быть готов очень быстро им стать. Его задача - погрузиться с головой в бизнес, прожить боли заказчика, собрать знания и опыт функциональных специалистов и превратить всё это не просто в традиционное ТЗ, а в структурированный и понятный человеку и машине контекст системы.
Он должен описывать предметную область, бизнес-правила, ограничения, исключения, модель данных, пользовательские сценарии и критерии приёмки. В качестве формата такой работы вполне может использоваться структурированный Vibe++ или его аналог.
По сути, главным артефактом разработки постепенно становится уже не сам программный код, а качественно сформированный контекст, из которого этот код может быть создан.
2. Архитектор-разработчик.
Это технический специалист уровня senior, который на основании требований аналитика способен понять, какую систему действительно необходимо создать. Он определяет архитектуру, границы компонентов, структуру данных, интеграции и технические ограничения.
Его задача теперь состоит не только и даже не столько в непосредственном написании кода. Он должен уметь правильно поставить задачу ИИ, декомпозировать её, задать архитектурные ограничения, проверить результат и не позволить модели постепенно превратить систему в неуправляемый набор красиво написанных фрагментов.
ИИ хорошо умеет создавать локально правдоподобный код, но гораздо хуже удерживает глобальную архитектуру системы. Поэтому senior в AI-разработке нужен не меньше, а, возможно, даже больше, чем раньше.
3. Супертестировщик.
Совершать сотни одинаковых действий человеку больше не нужно - такую работу лучше отдать автоматизации и ИИ. Ценность нового тестировщика в другом: он должен профессионально уметь ломать систему.
Он должен мыслить как обычный пользователь, человек, который совершенно не понял интерфейс, злоумышленник, пользователь с плохим интернетом, интеграция, приславшая неожиданные данные, или человек, который двадцать раз подряд нажал одну и ту же кнопку.
Такой специалист должен понимать предметную область и архитектуру продукта, уметь находить нестандартные сценарии и превращать найденные проблемы в структурированные задания, понятные разработчику и ИИ.
По сути, это уже не просто тестировщик, а профессиональный разрушитель продукта.
4. Фантазёр.
Это технический визионер с внекоробочным мышлением, свежим взглядом и собственным мнением. Человек, который умеет влюбляться в свои идеи и способен влюблять в них других.
По сути, это R&D в одном лице. Он смотрит на продукт не с позиции того, как принято делать, а постоянно задаёт вопрос: а почему вообще это должно работать именно так?
Эта роль становится особенно важной в эпоху генеративного ИИ. Модели воспроизводят накопленный человечеством опыт и естественным образом тяготеют к усреднённым решениям.
Без человека, способного выходить за границы существующих шаблонов, можно научиться невероятно быстро создавать очень качественные, технически правильные и совершенно ничем не примечательные продукты.
5. DevOps-инженер.
Кто-то всё ещё должен понимать, как система действительно работает после того, как красивый код покинул окно Codex. DevOps отвечает за инфраструктуру, CI/CD, среды, мониторинг, резервное копирование, секреты, доступы и отказоустойчивость. Рутинную часть этой работы всё больше можно отдавать машинам.
6. Безопасник, или параноик.
Отдельного специалиста по информационной безопасности маленькая IT-компания может себе не позволить. Не иметь самой функции безопасности она позволить себе уже не может. Кто-то внутри команды должен постоянно смотреть на систему глазами человека, который пытается получить то, что ему получать не положено.
Но есть ещё один элемент компании, который я бы выделил отдельно. Это даже не совсем производственная роль.
7. Питомник айтишников.
Если строить компанию только из senior-специалистов и ИИ, архитектура выглядит почти идеальной. Есть только одна проблема: непонятно, откуда через несколько лет возьмутся новые senior.
Типовые задачи, через которые раньше росли начинающие разработчики, сегодня первыми забирает ИИ. CRUD, простая вёрстка, небольшие процедуры, исправление элементарных ошибок - всё то, на чём джун постепенно набивал руку, машина уже делает быстрее.
Поэтому джуниоров я бы не включал непосредственно в производственное ядро маленькой AI-native компании. Я бы создал для них отдельный контур - своеобразный питомник айтишников.
Это отдел обучающихся сотрудников: студентов, стажёров и начинающих инженеров, которым компания сознательно выделяет настоящие задачи, предоставляет наставника и позволяет безопасно ошибаться. Их задача - не конкурировать с ИИ в скорости написания простого кода. Новый джун должен учиться понимать систему: читать чужой и сгенерированный код, объяснять, почему он работает, находить его слабые места, проверять решения ИИ и постепенно принимать на себя ответственность. В питомнике джуны должны рисовать блок-схемы, писать алгоритмы, оптимизировать их и проверять.
С точки зрения короткой экономики такой питомник выглядит как издержка. Но повторюсь, если не выращивать специалистов внутри, через несколько лет человеческое инженерное ядро компании просто некем будет обновлять. Хотя кто-то (привет, Илон Маск) считает, что через 10 лет наступит эра всеобщего благополучия и всемирного безделия =)
Так что я думаю, что IT-компания будущего, как ни странно, должна одновременно быть очень технологичной и немного учебным заведением. Тут, кстати, надо подумать как забрать часть финансирования у ВУЗов и направить на этих практикантов.
Есть и роли, которые в такой компании перестают быть обязательными отдельными штатными единицами. При этом исчезают не функции, а необходимость держать под каждую из них отдельного человека.
Технический писатель. Документация нужна, но значительная её часть должна автоматически формироваться из требований, кода, архитектурных решений и истории изменений.
Дизайнер. Для небольшого продукта можно один раз определить общий дресс-код - дизайн-систему и UX-принципы, которые дальше соблюдают люди и ИИ. А ваш фантазёр вполне может придумать что-то интереснее очередной четырёхколоночной вёрстки со скруглениями и мягкими тенями.
Проектный менеджер. В маленькой команде декомпозицию, протоколирование, статусы, контроль задач и напоминания можно в значительной степени автоматизировать, а функцию управления распределить между аналитиком и архитектором. Но при этом, кто-то, конечно, должен общаться с заказчиками по ВКС и писать им письма, чтобы не обесценивать труд всей команды.
Получается довольно необычная конструкция: несколько сильных специалистов формируют человеческое ядро компании, вокруг которого работает множество цифровых исполнителей. И кстати, эти несколько, вполне могут быть и одним человеком, но прямо очень опытным и занятым, как я.
Проектируя компанию, стоит упомянуть, что чтобы такая компания действительно работала, ей понадобится ещё одна вещь - память, содержащая в структурированном виде знания и опыт компании, в человеко-машинно читаемом виде.
Сегодня одна из главных проблем AI-разработки заключается в потере контекста. Модель может забыть ограничения, заново принять уже принятое решение или предложить архитектуру, противоречащую предыдущей.
Поэтому у должна существовать единая машиночитаемая база знаний (снова предлагаю Vibe++): описание бизнеса, требования, архитектура, правила разработки, требования безопасности, дизайн-система, история решений, тестовые сценарии и ограничения. Немаловажно для всех проектов вести паспорт проекта в формате маркдаун, например, и держать его как часть проекта, внося в него постоянные правки (автоматически, конечно).
Раньше корпоративную документацию писали преимущественно для людей и проверяющих органов, а теперь значительная её часть должна создаваться и для людей и для машин.
Отсюда меняются и требования к людям. На первое место выходят системное мышление, грамотная письменная речь, способность точно формулировать мысли, высокая скорость обучения, широкая эрудиция, критическое отношение к результатам ИИ и готовность лично отвечать за конечный результат.
И, как ни странно, в эпоху ИИ умение хорошо читать может стать едва ли не важнее умения хорошо писать код. ИИ генерирует тысячу строк за секунды. Но кому-то всё равно придётся понять, что она там написала и почему это вообще должно работать.
Поэтому я не думаю, что IT-компания будущего будет компанией без людей. Скорее она будет компанией с гораздо меньшим числом людей и гораздо более высокими требованиями к каждому из них.
Причём роль человека постепенно смещается именно туда, где машина слабее: понимать предметную область, сомневаться, видеть систему целиком, выходить за шаблоны, искать способы её сломать и в конечном счёте отвечать за результат.
Такая организация уже не очень похожа на классическую компанию разработки со множеством узких специальностей. Это небольшое человеческое ядро, окружённое цифровыми исполнителями, общей памятью, автоматизированной инфраструктурой и системой ограничений.
И здесь находится главный парадокс текущего технологического витка: создавать программный код стало проще, чем когда-либо. Создавать хорошие программные системы - возможно, стало сложнее, чем когда-либо, а конкурировать и доказывать состоятельность компании, стало просто мегасложно.
Компания будущего - это не много людей, использующих ИИ. Это несколько сильных и амбициозных людей, управляющих большим количеством цифровых исполнителей.