Код перестал быть главным дефицитом

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

AI-агенты меняют эту экономику.

Они не отменяют инженерные решения и не делают любую разработку простой. Но они резко уменьшают стоимость реализации конкретного решения. Поэтому вопрос постепенно меняется с «какой готовый фреймворк выбрать?» на другой:

Какие возможности действительно нужны этому приложению — и как быстро мы можем собрать, проверить и изменить именно их?

Именно этот вопрос мы исследуем в HAIH.

Мы не строим ещё один универсальный движок

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

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

Мы хотим проверить другой подход.

Архитектура должна расти из требований конкретного приложения.

Публичному сайту может понадобиться HTML до выполнения JavaScript, хорошая индексация, быстрый development feedback и HTTP-кеширование. Внутренней CRM SEO может быть вообще не нужно. Сервису без интерфейса не нужен React. Приложению без собственного состояния не нужна база данных. Появление API само по себе не означает появление persistence.

Поэтому HAIH — это не лестница вида «установите сначала A, потом B, потом C». Это пространство совместимых инженерных решений, из которого под конкретные требования собирается нужная архитектура.

Главный потребитель этой системы — AI

Здесь есть принципиальная для нас мысль.

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

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

Человек формулирует задачу и ограничения. Агент получает предметный контекст HAIH и быстро строит карту решений:

requirements
    ↓
существенные инженерные вопросы
    ↓
подходящие решения
    ↓
альтернативы и trade-offs
    ↓
совместимость и зависимости
    ↓
реальные showcase
    ↓
способы проверки
    ↓
evidence

Современная модель и без нас знает, что существуют React, PostgreSQL, Varnish, GraphQL и тысячи других технологий. Проблема не в том, чтобы ещё раз объяснить ей синтаксис этих инструментов.

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

HAIH должен давать именно такой предметный контекст.

Showcase важнее абстрактной документации

Поэтому основной единицей знания для нас становится не модуль и не tutorial, а законченный предметный showcase.

Не «как подключить Varnish».

А примерно так:

Контекст
Требования
Ограничения

→ Какие варианты рассматривались?
→ Почему было выбрано это решение?
→ Что оно добавило в систему?
→ Как оно реализовано?
→ Как мы проверили результат?
→ Что показали измерения?
→ Какие проблемы обнаружились?
→ При каких условиях это решение перестанет быть правильным?

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

Это важнее самого кода: следующий проект почти наверняка будет другим.

Мы хотим сохранять инженерный опыт, а не только реализации

Библиотека сохраняет реализацию некоторой возможности.

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

Мы хотим попробовать сохранять ещё один слой: опыт принятия решения.

Почему здесь достаточно статической генерации? Почему здесь нужен runtime? Когда кеширование действительно уменьшает стоимость системы? Когда persistence ещё не нужен? Где разумнее взять зрелый primitive, а где небольшой собственный код даёт больше контроля? Чем доказать, что решение работает?

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

Каждый новый реальный эксперимент должен делать эту карту богаче.

Почему мы считаем обучение агентов перспективнее обучения людей этой системе

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

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

Возможно, эффективнее сосредоточиться на обучении именно AI-агентов.

Агент способен за короткое время обработать объём инженерной информации, который человеку пришлось бы изучать неделями. Ему не обязательно помнить всю базу знаний постоянно: он может получить нужный контекст в момент решения конкретной задачи. А предметные showcase позволяют резко сузить область поиска и показать не абстрактные возможности технологии, а реальные связи «требование → решение → результат».

Получается другая модель распространения инженерного опыта:

раньше

опыт → документация → человек → код

возможное будущее

опыт + experiments + evidence
              ↓
       knowledge for AI
              ↓
           agent
              ↓
requirements → implementation → verification

Это пока гипотеза. Но её можно проверять практически.

Собственный код снова становится интересным активом

Есть ещё одно следствие AI-разработки.

Open source традиционно даёт доступ к исходному коду, но это не всегда означает практический контроль над поведением зависимости. Если проект упирается в чужую abstraction, обычный путь выглядит знакомо: issue, обсуждение, pull request, review, merge, release, upgrade. Иногда это дни. Иногда месяцы. Иногда нужное изменение никогда не становится приоритетом upstream.

Можно поддерживать fork, но исторически это тоже было дорого.

AI снижает стоимость ещё одного действия: локального изменения собственного кода.

Если нужное поведение находится в понятной части нашего проекта, мы можем прямо сейчас попросить агента изменить его, запустить тесты и измерения и посмотреть результат. Агент может ошибиться. Задача может оказаться сложной. Но у нас хотя бы существует прямой путь от requirement к коду, который мы контролируем.

Поэтому мы не считаем минимальное количество собственного кода самостоятельной целью.

И не считаем целью написать всё самостоятельно.

TLS, база данных, графическая библиотека, UI runtime и множество других зрелых primitives могут иметь огромную инженерную ценность.

Вопрос другой:

Где стоимость владения собственным понятным кодом становится ниже стоимости потери контроля из-за чужой abstraction?

Чем дешевле агенту понимать, менять и проверять локальный код, тем интереснее становится эта граница.

Не минимальное число зависимостей, а минимальный friction

По той же причине HAIH не является упражнением в аскетизме.

Если Vite радикально ускоряет цикл «изменение → браузер → проверка», он может быть полезнее самодельной минимальной сборки.

Если React позволяет локально и предсказуемо развивать интерфейс, его зависимость оправдана тем объёмом сложности, который он снимает.

Если небольшой собственный production server прозрачнее и легче изменяется, чем большой framework runtime, это тоже может быть рациональным выбором.

У каждой технологии должен быть ответ на простой вопрос:

Какую реальную стоимость она уменьшает?

Не количество dependencies определяет простоту системы. Важнее суммарный friction разработки, эксплуатации, изменения и проверки.

Главная метрика — время

Поэтому HAIH интересуют не списки функций.

Нас интересует время от появления реального требования до достаточного и проверенного решения.

Для каждого следующего шага можно наблюдать несколько величин:

Time to Capability
сколько заняло получить нужное поведение

Time to Verify
сколько заняло доказать, что оно работает

Time to Change
сколько занимает изменить решение при новом requirement

Time to Escape
сколько стоит отказаться от abstraction, если она перестала подходить

К ним добавляются производительность, потребление ресурсов, объём появившейся сложности и нерешённые вопросы.

Это позволяет обсуждать архитектуру не как религию и не как соревнование feature lists, а как эксперимент.

Первый эксперимент уже идёт

haih.site — не только сайт с описанием идеи. Это первый рабочий showcase.

Первый вопрос был намеренно практическим:

Можем ли мы отказаться от Next.js для серьёзного публичного сайта и как быстро собрать только те возможности, которые действительно нужны этому проекту?

Примерно за один день появился работающий vertical slice на React, React Router, Vite, небольшом Node.js runtime, Traefik и Varnish. Мы проверили development workflow, production build, маршрутизацию, HTML, кеширование и нагрузку.

Первый публичный checkpoint зафиксирован в релизе v0.1.0 — One day without Next.js.

В локальном синтетическом тесте production delivery path обработал 100 000 запросов при concurrency 1000 без ошибок примерно за 6,7 секунды — около 15 тысяч запросов в секунду. Lighthouse одновременно показал, что работа не закончена: Performance 79 при Accessibility 100, Best Practices 96 и SEO 100.

Для нас особенно важна именно последняя часть.

79 — не провал. Это следующий вопрос.

Нужна ли другая стратегия доставки изображений? Что даст compression? Что действительно влияет на показатель? Какие оптимизации оправданы именно для публичного SEO-сайта, а какие были бы бессмысленны для закрытой CRM?

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

Релиз как лабораторная запись

Поэтому релизы HAIH мы хотим использовать не столько как changelog функций, сколько как checkpoints исследования:

Requirement
    ↓
Time
    ↓
Investigation
    ↓
Implementation
    ↓
Verification
    ↓
Evidence
    ↓
Adopted / Rejected / Unresolved

Успешное решение полезно.

Неудачное решение тоже полезно.

Обнаруженный edge case полезен.

И особенно полезно знать, сколько времени всё это заняло.

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

Какое будущее мы хотим проверить

Сегодня reuse в разработке в основном означает повторное использование кода:

library → framework → application

Мы хотим проверить другую модель:

engineering experience
        +
showcases
        +
evidence
        ↓
AI agent
        ↓
architecture for current requirements
        ↓
implementation
        ↓
verification

Библиотеки никуда не исчезают. Хорошие primitives никуда не исчезают. И фреймворки тоже не обязаны исчезнуть.

Но framework перестаёт быть обязательной исходной единицей архитектуры.

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

Мы не знаем, где находится предел этой модели.

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

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

Это тоже надо доказать.

Именно поэтому HAIH строится публично.

Не как обещание идеального стека.

А как последовательность требований, экспериментов и доказательств.

Requirements. Experiments. Evidence.