8 posts tagged with "code-generation"

Generated query APIs contain language, not only identifiers. That makes a small grammatical choice part of the public contract.

For a collection of people, TeaQL uses whoAreActive(), not whoIsActive(). For an ordinary human attribute it uses whoseEmailIs(...). A non-human entity uses whichAreActive() and withCodeIs(...).

These forms sound related, but they solve different problems: whose expresses possession, while who are agrees with the plural result set.

One of the smallest code generator shortcuts creates one of the most persistent API defects:

plural = name + "s"

It works for order, which makes it look harmless. Then it produces order_statuss, categorys, persons, childs, and inventorys.

During TeaQL's six-language acceptance work, we found this assumption in Python and Go query templates and in a Rust diagnostic. The generated code compiled often enough for the mistake to survive until an entity ending in status exposed it.

“Supports six languages” should mean more than producing six directories that compile. The same model must preserve the same query meaning, loaded-state behavior and governance boundaries in every generated API.

TeaQL recently used Java's generated Request API as the semantic reference and ran paired generation tests across Rust, Go, Python, .NET and TypeScript. The work exposed gaps that ordinary runtime unit tests had missed.

TeaQL now has a dated, executed database baseline across six generated language runtimes: Java, Rust, Go, Python, C#/.NET, and TypeScript.

The headline result is Java's real nine-database matrix:

tests=9 failures=0 errors=0 skipped=0

The databases were PostgreSQL, MySQL, SQLite, Oracle, DB2, DM8 (Dameng), SAP HANA, SQL Server, and DuckDB.

That is meaningful only because these were not adapter-discovery tests. The generated domain APIs compiled and executed schema creation, graph persistence, reconnect queries, optimistic updates, and direct database checks.

TeaQL Java did not remove every use of reflection from the repository. We did something more practical: we removed reflection from the core entity execution path, isolated the remaining reflective utilities, and added build-time guardrails to stop reflection from quietly returning.

GraalVM Native Image was an important forcing function, but it was not the highest-level reason for the work. The larger goal was to make the runtime environment more deterministic: important behavior should be explicit, inspectable, bounded, and enforceable before a production request reaches it.

We see that as harness engineering. The reliability of a system should not depend only on developers or coding agents remembering the right conventions. The surrounding environment—generated code, metadata, module boundaries, compiler-visible calls, build rules, and tests—should constrain execution into known-good paths.

Our most important practical finding today was simple:

The shorter and clearer the prompt, the more effectively the coding agent works.

That does not mean removing constraints. It means moving detailed constraints out of prose and into an executable harness: the TeaQL Generation Service, generated typed APIs, model-aware assist, compiler feedback, and tests.

Today we rebuilt TeaQL Agent Kit around that finding. The agent creates a typed domain contract, the Generation Service evaluates it, generated guidance constrains the implementation, and human review happens in parallel.

The smaller, clearer workflow is now distributed as a standard Agent Skill named build-teaql-app.

Reading system information on Linux is not difficult. Open /proc/meminfo, /proc/[pid]/stat, and /proc/[pid]/task, parse the text, and send the results to a terminal UI.

The harder part is keeping that code maintainable. As process fields grow, filtering becomes more complex, or the same system data needs to serve monitoring agents, alerting jobs, and management APIs, file reads and string parsing scattered through application code quickly become a liability.

Linux System Info using TeaQL demonstrates another approach: model Linux system information as domain objects, let TeaQL generate type-safe Rust query APIs, and use teaql-provider-linux to execute those queries against /proc. The example then builds an interactive process and thread monitor with ratatui.

We are excited to announce a massive overhaul of the teaql-forge-rs code generation engine. This update fundamentally transforms how our templates are structured and significantly enhances how AI coding agents interact with TeaQL-generated codebases.