Case study 02, 2026
Entode
I built a backend generator around a reviewed schema, a deterministic compiler and a bounded agent loop. The compiler builds the app structure, models fill the business logic, and executable checks drive the repairs.
01
The idea
A short request can describe an app, but it cannot settle every decision about data, access, and behavior. I wanted the generated backend to have an architecture I could inspect before treating the code as finished.
Entode holds that architecture in one internal representation. The ERD, business-logic and state-machine view, generative design surface, and running app all come from it. A change to the design reaches every view without a separate copy to keep in sync.
02
The pipeline
- Propose. A schema model turns the request into architecture changes. I review the proposal before accepting it into the JSON schema.
- Compile. A deterministic compiler emits FastAPI routes, SQLAlchemy models, request and response schemas, and the declared permissions.
- Write. A separate code model fills marked business-logic stubs. Larger jobs are split into function chunks, and only the permitted functions are merged back.
- Evaluate. Static checks inspect the code and protect compiler-owned parts. Generated pytest cases exercise the app through HTTP requests, including behavior across routes.
- Repair. The evaluator recursively feeds failures back into generation. Each correction starts from the clean compiler baseline and the latest failure report.
The schema proposal and code-generation stages have separate responsibilities. A failed code attempt cannot silently redefine the architecture it was asked to implement.
03
Where the model can write
The compiler owns the permission dependencies, state-transition helpers and encryption runtime. The code model implements the business logic around them. Integrity checks compare these protected parts against saved compiler output, so a rewritten permission check cannot pass just because the rest of the route still works.
Fresh context for each correction
I restore the compiler stub before every correction. The next attempt receives the schema, the clean stub and a concrete report of what failed. Failed code and a growing chat history do not become the next attempt's starting point.
The loop stops when the checks pass, failures repeat, or the attempt budget runs out. It also stops when the failure belongs to the schema or compiler; rewriting business logic cannot fix those problems. The remaining failure is surfaced for a decision.
04
The test that changed the result
The running app had to prove the wiring.
Every earlier check passed. One route was still wired wrong.
A generated backend passed the other checks in the pipeline, but an end-to-end test found a real cross-route wiring defect. The individual pieces looked correct; the request path through the running app was not.
That case is why the evaluator exercises behavior across routes, rather than accepting code shape or isolated route checks as proof. The model that wrote the code does not decide whether the result passes.
05
What it produced
From the sentence "build a basic social network," Entode generated a backend with auth, a relational data model, RBAC with row-level permissions, encrypted fields, and a REST API. The useful part was being able to inspect the schema and check the generated behavior against it.
I also exercised the pipeline against six application archetypes: marketplace, CRM, booking, helpdesk, LMS, and ticketing.
Passing the configured checks tells me how the app behaved on those cases. Entode is a local development tool; a generated app still needs deployment review and tests for requirements its schema does not describe.