За пределами кода

Когда ИИ возвращает специалисту внимание | Часть 1
Из цикла «Почему сильный специалист с ИИ становится еще сильнее»

Раньше специалист тратил много времени на повторяющиеся операции: заготовки, поиск документации, тестовые данные, однотипные исправления и оформление. По отдельности это мелочи, но вместе они постоянно переключают внимание.

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

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

В следующей части — почему качество результата зависит от постановки задачи и проверки.

Почему изменение требует правок в десятках мест | Часть 3
Из цикла «ИИ код без архитектора и появление технического долга»

В хорошо спроектированной системе бизнес-правило находится в одном понятном месте. Если нужно изменить формат данных, статус или проверку доступа, команда меняет общий механизм и проверяет связанные компоненты.

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

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

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

Поэтому ИИ полезен как исполнитель внутри заданной архитектуры. Но если архитектора нет, скорость генерации может ускорить не развитие проекта, а накопление технического долга.

Полная версия статьи: https://dzen.ru/a/atZgkdgCpHkQ42Oa

Как появляются дубли и технический долг | Часть 2
Из цикла «ИИ код без архитектора и появление технического долга»

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

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

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

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

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

Как ИИ решает задачу вне архитектуры | Часть 1
Из цикла «ИИ код без архитектора и появление технического долга»

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

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

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

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

В следующей части — почему ИИ начинает дублировать код вместо унификации.

Почему вернутся не все | Часть 3
Из цикла «Куда уйдут специалисты, если рынок обесценит их работу?»

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

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

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

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

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

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

Полная версия статьи: https://dzen.ru/a/atKX94SAtyZVBRiC

Куда уходят специалисты | Часть 2
Из цикла «Куда уйдут специалисты, если рынок обесценит их работу?»

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

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

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

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

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

В следующей части — почему даже рост спроса не вернёт всех ушедших специалистов.