Worklog for task "Develop and launch the website"

Progress: from application engine to engineering solutions base for AI

During further design, the general HAIH paradigm was refined and verified against how it already manifests in the current haih.site, specifically on the /solutions page.

1. Reusing an application engine is not required

The core hypothesis has become more radical: in the era of coding agents, a significant portion of the value of a large application framework/engine can shift from ready-made universal code to reusable engineering knowledge.

New schema:

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

That is, reuse remains, but its object is increasingly not a universal implementation of the business and application layer, but a proven way of solving a problem.

2. The boundary does not lie between "ready-made" and "custom-built"

There is no goal to rewrite PostgreSQL, OpenSSL, Sharp, and other mature specialized primitives. However, integration frameworks should be evaluated based on the capabilities actually used.

The Next.js example: the task is not to create a custom analogue of Next.js, but to determine which of its features the project actually requires — routing, layouts, build, SSR/SSG, image processing, etc. If a specific set of requirements can be implemented cheaper and more transparently via React + Vite + specialized primitives + a small project-specific glue code, a large framework ceases to be mandatory.

The key effect of coding agents: the cost of writing and maintaining small specialized glue code has dropped sharply. Therefore, the old rule "do not write your own because you will have to maintain it" can no longer be applied without comparing it to the cost of someone else's abstraction model, upgrade path, and compatibility constraints.

3. React is an example of a dependency with high architectural leverage

It is specifically clarified that minimalism does not mean the mechanical exclusion of framework/library dependencies.

React fits the new model well: with a comparatively compact conceptual surface, it removes a large volume of complex universal work regarding declarative UI, state, composition, and rendering, without imposing the persistence/API/deployment architecture of the entire application.

A useful criterion:

How much useful complexity does the dependency take away from the project, and how much foreign complexity does it force the project to accept?

Thus, HAIH should not optimize dependency count. It is necessary to optimize architectural leverage and total friction.

4. /solutions is already the inception of a knowledge layer

The current haih.site/solutions page effectively implements part of this model. It separates application, development/build, production runtime, and optional deployment services, and describes technologies through the capabilities they perform and their dependencies.

The solution status model is particularly useful: In use, Optional, Configured, Connected; verification in progress, Implementation open, Future branches. This allows the coding agent to see not only the solution, but also the reliability status of the knowledge regarding it.

The page also leaves future capabilities open — standalone API, persistence, typed API/data contracts, identity/authorization, payments, formal solution composition — without prematurely assigning a mandatory technology to every requirement.

5. The next step is to invert the solutions catalog

Currently, /solutions primarily answers the question: "What is used in haih.site and what work does it perform?"

The next level should allow going from a requirement to a composition of solutions:

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

Example: responsive images → on-demand transformation → Sharp → expensive deterministic computation → cache → Varnish/CDN/other suitable implementation.

Importantly, a showcase is not obligated to prescribe a specific stack. The agent must be able to take engineering experience and adapt it: for example, not installing Varnish if the required caching is already provided by an existing CDN.

6. Possible evolution: machine-readable solution graph

A promising direction is a machine-readable description of solutions: what capabilities a solution provides, what prerequisites it requires, what verification checks confirm correctness, and with which solutions it is compositionally compatible.

Then HAIH can be not a runtime framework present in every production project, but an engineering knowledge system from which a coding agent synthesizes the architecture of a specific project based on requirements.

Current formulation of the direction

Not a "new modular engine", but a system for reusing engineering experience:

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

haih.site/solutions can already be considered the first practical layer of this system; showcases should add complete vertical transitions from requirement to verified result.