Ворклог по задаче "Разработать и запустить сайт"

Прогресс: от application engine к базе инженерных решений для AI

В ходе дальнейшего проектирования уточнена общая парадигма HAIH и проверено, как она уже проявляется в текущем haih.site, в частности на странице /solutions.

1. Переиспользовать не обязательно application engine

Основная гипотеза стала радикальнее: в эпоху coding agents значительная часть ценности большого application framework/engine может переноситься из готового универсального кода в повторно используемое инженерное знание.

Новая схема:

requirements
+ best practices
+ showcases
+ evidence
+ mature primitives
        ↓
   coding agent
        ↓
project-specific implementation

То есть reuse остаётся, но его объектом всё чаще становится не универсальная реализация бизнес- и application-слоя, а проверенный способ решения задачи.

2. Граница проходит не между «готовым» и «самописным»

Нет цели переписывать PostgreSQL, OpenSSL, Sharp и другие зрелые специализированные primitives. Но интеграционные framework'и следует оценивать по фактически используемым capabilities.

Пример с Next.js: задача не в создании собственного аналога Next.js, а в определении того, какие его возможности реально требуются проекту — routing, layouts, build, SSR/SSG, image processing и т. п. Если конкретный набор требований дешевле и прозрачнее реализуется через React + Vite + специализированные primitives + небольшой project-specific glue, большой framework перестаёт быть обязательным.

Ключевой эффект coding agents: стоимость написания и сопровождения небольшого специализированного glue-кода резко снизилась. Поэтому старое правило «не писать своё, потому что придётся поддерживать» больше нельзя применять без сравнения с ценой чужой abstraction model, upgrade path и compatibility constraints.

3. React — пример dependency с высоким architectural leverage

Отдельно уточнено, что минимализм не означает механическое исключение framework/library dependencies.

React хорошо соответствует новой модели: при сравнительно компактной концептуальной поверхности он снимает большой объём сложной универсальной работы по декларативному UI, состоянию, композиции и rendering, не навязывая архитектуру persistence/API/deployment всего приложения.

Полезный критерий:

Сколько полезной сложности dependency забирает у проекта и сколько чужой сложности заставляет проект принять?

Таким образом, HAIH не должен оптимизировать dependency count. Нужно оптимизировать architectural leverage и суммарный friction.

4. /solutions уже является зачатком knowledge layer

Текущая страница haih.site/solutions фактически реализует часть этой модели. Она разделяет application, development/build, production runtime и optional deployment services и описывает технологии через выполняемые ими capabilities и зависимости.

Особенно полезна модель статусов решений: In use, Optional, Configured, Connected; verification in progress, Implementation open, Future branches. Это позволяет coding agent видеть не только решение, но и статус достоверности знания о нём.

Страница также оставляет будущие capabilities открытыми — standalone API, persistence, typed API/data contracts, identity/authorization, payments, formal solution composition — не назначая заранее обязательную технологию каждому требованию.

5. Следующий шаг — инвертировать каталог решений

Сейчас /solutions преимущественно отвечает на вопрос: «Что используется в haih.site и какую работу выполняет?»

Следующий уровень должен позволить идти от требования к композиции решений:

Requirement
    ↓
Capabilities needed
    ↓
Trade-offs
    ↓
Solution composition
    ↓
Implementation
    ↓
Verification
    ↓
Evidence

Пример: responsive images → on-demand transformation → Sharp → expensive deterministic computation → cache → Varnish/CDN/другая подходящая реализация.

Важно, что showcase не обязан предписывать конкретный стек. Агент должен уметь взять инженерный опыт и адаптировать его: например, не ставить Varnish, если требуемое кеширование уже обеспечивает существующий CDN.

6. Возможное развитие: machine-readable solution graph

Перспективное направление — машиночитаемое описание solutions: какие capabilities решение предоставляет, какие prerequisites требует, какие verification checks подтверждают корректность и с какими решениями оно композиционно совместимо.

Тогда HAIH сможет быть не runtime framework, присутствующим в каждом production-проекте, а engineering knowledge system, из которой coding agent синтезирует архитектуру конкретного проекта под requirements.

Текущая формулировка направления

Не «новый модульный движок», а система повторного использования инженерного опыта:

Libraries provide primitives. Cases provide engineering experience. Agents synthesize the application. Evidence verifies it.

haih.site/solutions уже можно рассматривать как первый практический слой этой системы; showcases должны добавить законченные вертикальные переходы от requirement к проверенному результату.