AI coding tools have made building software faster, but writing code is only one part of engineering. Keeping a system consistent as it grows is often the harder problem.
Consider a microservice application. One service depends on another, configuration values are shared across environments, and different developers make changes to the same architecture. If an AI coding agent introduces an invalid configuration or circular dependency, who catches it?
This question led me to explore Aontu, an open-source language and tool for defining constraints, validating structured data, and modeling relationships.
I installed Aontu on Ubuntu and tested it myself. My goal wasn't to explore every feature. I wanted to understand whether its approach could solve problems I might face in a real software project.
My First Impression: Easy Installation, Unfamiliar Concepts
I installed Aontu version 0.73.0 using npm. The installation succeeded without dependency audit warnings, and the CLI worked immediately through npx.
However, understanding the tool was harder than installing it.
Aontu has commands for schema validation, relationship analysis, provenance, compatibility checking, code generation, and more.
That flexibility is attractive, but it creates an onboarding problem. Someone looking for a configuration validator may feel overwhelmed before understanding the basic workflow.
Its syntax also takes adjustment. Developers familiar with JSON, YAML, or JavaScript validation libraries need to understand concepts such as unification, defaults, and map templates.
I found myself asking whether Aontu was simplifying configuration management or introducing another abstraction I would have to maintain.
The Interesting Part: Architecture as a Constraint
My first experiment involved defining two services: an API service and an authentication service.
I gave both services a common structure and specified a default tier. Aontu correctly applied the default to the API service while preserving the authentication service's explicit value.
That sounds simple, but the underlying approach matters.
Traditional configuration files primarily describe values. Aontu can describe both the values and the rules those values must satisfy.
The more compelling experiment involved circular dependencies.
I modeled an API service calling an authentication service while the authentication service called the API service.
For the relationship, I used Aontu's constraint:
calls?: rel() & acyclic()
Aontu rejected the model with a relation_cycle error.
I liked this result because circular dependencies are architectural problems, not merely incorrect data types.
In a larger project, expressing such restrictions as constraints could provide a useful safeguard during code reviews or automated changes.
However, Aontu cannot automatically understand every rule of an application. Developers must still identify and define the right constraints. An incomplete model can provide a misleading sense of confidence.
That distinction matters, particularly when AI agents are generating code.
Error Detection Was Good. Error Communication Was Mixed.
I deliberately changed a numeric configuration value to a string.
Aontu correctly rejected it and identified both the invalid value and the relevant schema declaration.
Technically, that is excellent behavior. Knowing where a conflicting value originated is much better than receiving a generic validation failure.
But the diagnostic also included:
Empty disjunction. The disjunction has no valid alternatives.
I understood that the values were incompatible, but this terminology would probably confuse a beginner.
The circular-dependency diagnostic had a similar issue. It detected the problem correctly, yet it did not display the complete api → auth → api cycle in my test.
Instead, it identified an offending relationship path and pointed to the schema constraint.
I would prefer an error message that begins with an explanation developers can act on immediately, followed by the more detailed technical reasoning.
A validation tool should not only identify what's wrong; it should make fixing the problem easier.
The Feature That Impressed Me Most
One of the most useful things I discovered was Aontu's ability to explain where configuration values came from.
When I queried the API service's tier, Aontu traced the value back to the default declaration in my source file.
This might seem like a small feature, but configuration debugging becomes difficult when teams introduce shared defaults, overrides, and multiple sources.
Usually, developers must search through files to figure out why an application received a particular value.
Aontu's provenance functionality provides that explanation directly.
I can imagine this being particularly valuable in infrastructure repositories or systems with many interconnected configuration definitions.
For me, this was one of the clearest advantages over simply storing configuration in ordinary JSON files.
A Small Problem That Says a Lot About Developer Experience
I also tried Aontu's project initialization command.
It generated a sample model, example data, and a shell script containing validation checks.
That was encouraging because it provided a working starting point.
But when I executed the generated script, it failed:
check.sh: 16: aontu: not found
The issue was straightforward. I had installed Aontu locally, while the generated script expected the executable to be available on my shell's PATH.
After adding the local npm executable directory to PATH, the script worked correctly.
This wasn't a serious technical defect, but it was unnecessary friction.
Developers often evaluate tools through their first successful experience. A starter project should account for common installation methods or clearly explain its assumptions.
Validation Coverage Is More Important Than It Sounds
My final experiment revealed another interesting feature.
Aontu can report how much input data was actually checked against a schema.
The generated example showed that all four data leaves had been constrained.
I then intentionally wrote an ineffective schema using "*" where Aontu expected its &: map-template syntax.
The result was revealing: none of the four data leaves were checked.
Normal validation reported an incomplete result. Strict coverage returned a failure and explicitly explained that validation had examined nothing.
This is a useful safeguard because successful-looking validation workflows can give developers confidence even when their rules do not cover the intended data.
I particularly appreciated that Aontu exposed this problem instead of leaving developers to discover it through unexpected behavior.
Would I Use Aontu in a Real Project?
After these experiments, I have a more balanced view.
I wouldn't introduce Aontu into every application. For a small project with straightforward configuration requirements, conventional schema validation would probably be easier to understand and maintain.
But for a system with interconnected services, complex configuration rules, and frequent automated changes, I can see its value.
The strongest features I tested were relationship validation, clear source provenance, and validation coverage.
Its main weaknesses were the learning curve, specialized diagnostic language, and small onboarding inconsistencies.
I also wouldn't treat Aontu as a complete solution for AI-generated code quality. It can reject violations of defined constraints, but it cannot replace meaningful tests, security reviews, or engineering judgement.
Final Thoughts
What interests me most about Aontu is not its connection to AI tools. It's the idea that architectural expectations can become executable constraints rather than remaining only in documentation.
My local experiments showed that this approach can catch real inconsistencies.
At the same time, powerful abstractions come with costs. Teams need to understand the language, maintain accurate models, and interpret validation results correctly.
My verdict: Aontu is worth exploring when architectural consistency is a recurring problem, but I would validate its benefits through a small proof of concept before adopting it across a project.
That seems like a more meaningful reason to use it than simply adding another tool to an AI development workflow.
Project reviewed: Aontu
Top comments (0)