В первой статье о HAIH речь шла об инженерных знаниях для AI-агентов вместо ещё одного фреймворка. Теперь эту методику удалось проверить на реальном brownfield-проекте — многолетней Пивной карте с legacy-стеком, десятками тысяч URL и живыми данными.

AI всё лучше пишет код, но рынок программной разработки не становится одинаково простым для всех. Наблюдаемые данные указывают на другой процесс: senior-разработчики получают от AI особенно большой leverage, junior-вакансии относительно senior сокращаются, а привычный путь накопления инженерного опыта начинает меняться. Разбираемся, почему особенно ценным специалистом становится hard-skilled практикующий senior, который одновременно глубоко интегрировал AI в свою работу.

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

Почему в эпоху AI-разработки полезнее не большой full-stack framework и не каталог готовых модулей, а минимальная основа, набор совместимых принципов и база законченных архитектурных кейсов.

AI резко снизил стоимость создания и изменения сайта, но почти не убрал повторяющуюся инфраструктурную работу: серверы, Docker, домены, HTTPS, deploy, stage/prod, логи и обновления. На одном-двух проектах это терпимо. На десятках сайтов мелкие операции превращаются в постоянный операционный налог. Возможно, следующий полезный слой — не очередной конструктор сайтов и не ещё одна закрытая PaaS, а AI-native open-source основа для управления собственным парком проектов.

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

SaaS победил не случайно: он снял с пользователя огромный пласт технической сложности. Но вместе с серверами, обновлениями и deploy мы часто отдали поставщику исходный код, runtime, данные и право менять систему за пределами предусмотренного API. Coding agents позволяют заново собрать другой баланс — сохранить владение проектом, не возвращая пользователю всю сложность самостоятельной разработки.

Старый репозиторий принято считать legacy, а облачный AI-конструктор — современной платформой. Но coding agents неожиданно меняют шкалу. Если старый проект можно получить целиком, поднять в Docker, исследовать, изменить и проверить, он может оказаться гораздо удобнее для развития, чем новый SaaS, который разрешает только операции, предусмотренные его API.

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

Когда мы начали делать «Учиться легко», задача выглядела почти слишком простой для отдельного технического проекта: картинка, слово, слоги, буквы и браузерная озвучка. Но первые прототипы быстро показали, что самое интересное начинается не в React-коде, а в том, как связать смысл, звучание и письменную форму так, чтобы ребёнок мог разобраться сам. Рассказываем, как устроена текущая реализация, какие ограничения обнаружились у Web Speech API и к чему привели первые реальные тесты.