Where the human actually sits in the process
The question we hear most often from enterprise IT teams right now: how do you know AI-generated code is actually secure?
It's a fair question. Most vendors still answer it poorly.
The wrong answer: "our AI is trained on secure coding practices." That's a marketing sentence, not a process.
Webtown's answer rests on three elements: spec-driven development, the security model of the Liferay and Ibexa platforms, and strict governance. Here's how each one works.
What is spec-driven development?
Spec-driven development is a methodology where the weight of human review shifts away from the finished code and onto the specification and the plan. The developer doesn't review every generated line individually. Instead, they validate what gets created before the code exists: what the function does, what input it accepts, who can access it, and what happens on invalid input.
Why isn't the finished code the focus of review at Webtown? Because manually reviewing every single generated line would kill the exact speed gain AI is supposed to deliver.
A specification alone isn't enough for this. It's paired with a detailed rule set that defines what makes code efficient, maintainable, and secure: coding conventions, architectural principles, security rules that Webtown's developers have established. The AI operates within this rule set, not outside it. The goal is for the output to not just meet the specification, but to read as if a Webtown developer had written it, because ultimately it follows the same rules.
Validating the specification and the plan creates the opportunity for a permission gap or a missing data-handling rule to surface before a single line of code is even written.
Where does testing fit in?
Testing in Webtown's process runs with AI support. The benchmark it measures against has already gone through human approval. The goal is that only code meeting the pre-approved specification can ship. This asks a different question than traditional code review: not "is this code good?" but "does this match what we approved?"
Classic quality assurance runs alongside this: functional, performance, and security tests are carried out as usual. What the specification adds is a pre-approved, auditable benchmark to measure everything against, so QA shows not just that the code works, but that it does exactly what was agreed on.
The entire process is auditable and traceable, which matters significantly in enterprise environments, where compliance and documentation are baseline requirements.
Why the platform matters: the Liferay and Ibexa security model
Liferay and Ibexa run on mature, well-documented security models: permissions, authentication, data access. Building inside that model, rather than around it, means inheriting a lot of security you'd otherwise have to build and maintain yourself, in every single project.
This is the second pillar of Webtown's approach: the platform itself reduces the surface where errors can occur.
Governance and compliance: why it isn't optional
In enterprise environments, legal compliance isn't a nice-to-have, it's a baseline requirement. It's a core principle that sensitive client data never enters any AI tool, and that data protection guarantees are contractually secured with whatever tooling is in use.
What question should you ask a development partner?
The right question isn't "do you use AI?" It's "where does the human sit in the process, and what do they actually validate?"
If a development partner can't give a clear answer to that, it's worth knowing before the project starts.
If, alongside AI-assisted development, you're also exploring how to integrate an enterprise AI solution like IBM watsonx into your systems, we're happy to help with that too.
