From web-code-generator to TeaQL
TeaQL did not appear from nowhere, and it is not simply a rename of an old generator.
It came from a long engineering lineage around one persistent problem: business software repeats the same structures across projects. Domain models, relationships, permissions, queries, validation, workflows, persistence rules, and presentation metadata appear again and again. The hard question is not whether code can be generated. The hard question is where the generation boundary should live.
Before the Git History
The earliest internal version of this direction was built in 2003.
That first version was already focused on reducing repetitive business application code in enterprise systems. The visible Git history of web-code-generator starts on April 1, 2016, but that commit should be read as a preserved snapshot of an older internal lineage, not as the beginning of the idea.
This history matters because the core problem stayed consistent for more than two decades. What changed was the shape of the generated output.
The Workspace Generation Era
The early web-code-generator approach generated source code directly into application workspaces.
That made sense for the development model of its time. A team could describe domain objects and generate a working application surface:
- Java POJOs, DAO interfaces, JDBC mappers, SQL, and manager services
- JSP and later React DVA admin pages
- Android, Swift, and miniapp client templates
- generated forms, tables, dashboards, search pages, and locale resources
- IAM, validation, event, and service scaffolding
This proved that model-driven generation could cover much more than CRUD. It could generate a large part of the repetitive structure around real business systems.
But generating source code into the developer workspace also has a cost. Generated files become mixed with handwritten files. Reviews get noisy. Upgrades create large diffs. AI coding agents must search through many repeated files before finding the business logic that actually matters. DevOps teams have to govern generated behavior indirectly through each application repository.
The Transition After 2022
After 2022, web-code-generator became less of a standalone product story and more of the engineering transition path into TeaQL.
Some important work still happened in the old repository during this overlap period:
- Request DSL improvements
- JSON search and list search
- aggregation, count, sum, average, month, and year support
- safe delete and recovery semantics
- SQL logging
- multi-database JDBC template improvements
- override-class and large-result handling
These were not just old-template maintenance tasks. They helped validate the capabilities that TeaQL later moved behind a cleaner library and runtime boundary.
The TeaQL Boundary
Modern TeaQL moved the generation boundary.
Instead of scattering generated source files across application workspaces, TeaQL focuses on generating versioned libraries, deterministic business APIs, query DSLs, object graph persistence behavior, and runtime capabilities that applications consume as artifacts.
That difference is important.
The old model was:
domain model -> generated source files inside the application workspace
The TeaQL model is:
domain model -> generated library/runtime artifact -> application dependency
The generated output becomes something that can be tested, published, versioned, upgraded, rolled back, and shared through normal release pipelines.
Why This Matters for AI Coding
AI-assisted coding changes the cost of generated source.
If thousands of generated files live beside handwritten business code, the AI agent has to navigate a noisy workspace. It may spend context on repeated scaffolding instead of the business workflow, integration, test, or product behavior that needs attention.
TeaQL's newer boundary gives AI agents a cleaner surface:
- generated behavior lives behind stable APIs
- business code depends on deterministic query and persistence contracts
- repetitive infrastructure becomes library behavior
- application changes stay focused on business intent
This does not remove generation. It makes generation more governable.
Why This Matters for DevOps
The same boundary helps DevOps.
Generated capabilities can move through normal engineering controls:
- CI checks
- automated tests
- package publication
- dependency upgrade
- release notes
- rollback
- multi-environment deployment
That is much cleaner than repeatedly regenerating large source trees inside many application repositories.
How to Read the Old History
The older web-code-generator articles should be read as capability history.
They document how the system learned to generate persistence code, service code, frontend pages, mobile clients, forms, validation, search, aggregation, and runtime helpers. Some technologies mentioned there, such as JSP, DVA, older Android and Swift templates, or Taro miniapp generation, are no longer the current recommended stack.
Their lasting value is not the specific old framework. Their lasting value is the engineering lesson: complex business software has repeatable structures, and those structures should be generated from a domain model.
TeaQL is the AI-era productization of that lesson.