Beyond Vibe Coding: How Akwa Builds Reliable AI Fashion Infrastructure
By Egoyibo Okoro · July 2026
Published by Akwa | akwa.design
AI can help build software faster. It cannot remove the responsibility to make that software reliable.
Akwa was built in the age of AI-assisted development. We do not hide that. AI has accelerated parts of our engineering process, helped us explore product ideas, supported debugging, assisted with code review and testing, and made it possible for a small team to build across web, mobile, generative design, fashion intelligence and production documentation at a pace that would previously have required substantially more resources.
But speed creates its own risk. A feature can look complete while failing on mobile. A generated document can be polished while contradicting the user's instruction. A fallback can exist in code but fail under a real timeout. A test can pass while an end-to-end workflow remains broken. A system can produce a technically valid response that should never have been released to a user.
This is why we have become increasingly uncomfortable with a simplistic narrative around vibe coding. The interesting question is not whether AI helped write the code. The interesting question is this: what happens after the code appears to work? At Akwa, that question has changed how we build.
The uncomfortable lesson: shipped is not the same as working
Some of our most important engineering decisions came from failures. We have had features that appeared operational but did not work reliably across environments. We have found workflows that succeeded on one device and failed on another. We have seen asynchronous processes stall, revision loops exceed execution limits, metadata disappear between stages, and generated outputs preserve a user instruction in one section while contradicting it elsewhere.
These are not abstract risks. They are the kinds of failures that become visible only when a product moves beyond a demo.
One recent example came from our Tech Pack pipeline. A user instruction had been correctly captured as an authoritative garment fact. The system knew the garment required a particular closure. That fact survived in one part of the production record, but downstream metadata used by other stages of the pipeline was silently dropped. The result was revealing: one part of the system preserved the instruction while another could diverge from it.
The problem was not that the AI forgot. The deeper problem was architectural. The system had become complex enough for a verified instruction to be captured correctly and then lose authority as it travelled through the pipeline. That distinction matters. Prompting harder is not a sufficient response to an authority problem. So we changed the system.
From generated documents to governed production artefacts
A fashion tech pack is not merely a long PDF. It can contain material specifications, bills of materials, points of measurement, grading information, construction sequences, seam and stitch requirements, quality-control checkpoints, flats, annotations and atelier notes. If AI is involved, fluency is not enough. A beautifully written pack can still be wrong.
Akwa's direction is therefore increasingly based on a different principle: the model may generate, but the system must govern. That means separating what the user said from what a model inferred. It means preserving provenance. It means checking whether different sections of a document agree. It means preventing a production-facing output from presenting unresolved assumptions as confirmed facts. And it means treating contradictions as system events rather than stylistic imperfections.
1. Preserving user authority
When a designer explicitly confirms a production-critical fact, that instruction should not become just another sentence inside a prompt. Akwa increasingly treats confirmed instructions as structured authority. A garment fact can carry information about where it came from and how certain the system is about it. The distinction between a user-confirmed instruction and a model inference is important, because they should not have equal authority.
For example, if a designer confirms a hidden centre-front zipper, a later generation stage should not casually relocate that closure because another model finds a side seam more conventional. The user's instruction must survive. This sounds obvious. In a multi-stage AI pipeline, it is not automatic. Information can be extracted correctly, transformed, passed between services, merged into a composition payload, reviewed asynchronously and rendered into multiple sections. At every boundary, authority can be weakened or lost. Our work has therefore focused not only on better generation, but on maintaining an auditable chain of design intent through the system.
2. Cross-section coherence
A production document can be individually plausible and collectively wrong. Imagine a pack where the brief specifies one closure, the bill of materials lists hardware for another, the construction sequence describes a third, and the flat drawing shows something different again. Each section might look professional in isolation. Together, they reveal a failure.
Akwa has been developing cross-section coherence controls to detect this class of problem. The purpose is not to ask whether the prose sounds convincing. It is to ask whether the production artefact agrees with itself. This is a materially different problem from text generation. It is closer to invariant checking: if a production-critical fact is authoritative, where else in the pack must that fact remain true?
3. Deterministic contradiction gates
Some contradictions should not merely generate a warning. They should block release. This is especially important where the system has a clear, authoritative instruction and a downstream output conflicts with it. Akwa has been building deterministic gates around these cases. The goal is straightforward: where a contradiction can be established by system logic, we should not rely solely on another language model to decide whether the contradiction matters.
This reflects a broader architectural principle: use AI where interpretation is valuable, and use deterministic controls where certainty is available. The two are not competitors. Reliable AI systems need both.
4. Production readiness should be computed, not narrated
One of the easiest mistakes in generative systems is allowing the model to describe its own output as complete. A model can say that all facts are confirmed even when unresolved or inferred items remain. That is why Akwa has been moving toward computed production-readiness logic. If unresolved states exist, the system should know. If confirmation is still required, the interface should say so. If a production-critical section is absent, the pack should not become ready because the generated narrative sounds confident. Readiness is a state. It should be derived from evidence.
5. Failure should be visible
One of our strongest lessons has been that graceful failure is part of product quality. If a composer fails to generate critical sections of a tech pack, the worst response is to quietly ship an incomplete document that looks finished. A better system identifies what is missing. It can say that the bill of materials exists but the points of measurement, grading, construction sequence or quality-control sections were not successfully produced. It can block or qualify the output. It can preserve recoverable work without pretending that recovery is completeness.
This is why our pipeline increasingly distinguishes between successful composition, outputs requiring refinement, unresolved production assumptions, stalled processes, incomplete packs, and genuine blockers. Transparency is not a cosmetic feature. It is part of reliability.
6. Audits are part of the development cycle
Testing asks whether something works. Auditing asks a broader set of questions: what has changed, what assumptions are we carrying, what controls are actually present, what has drifted, and what are we missing?
At Akwa, audits are not reserved for an annual compliance exercise or a moment of crisis. They are part of how we build and maintain the product. Our engineering workflow includes recurring reviews of the codebase and system state. Before new development sessions or significant workstreams begin, we use audit-oriented reviews to re-establish what is actually present: current architecture, deployed behaviour, open issues, unresolved risks, prior decisions and areas requiring verification.
This matters particularly in AI-assisted development. AI can accelerate implementation, but rapid implementation can also create architectural drift. A new session should not begin by assuming that prior context is complete, that documentation perfectly reflects production, or that a previously proposed control was actually wired end-to-end. We have learned to distinguish between what is proposed, what is implemented, what is deployed, what is tested, what is verified in a live workflow, and what is safe to rely on. Those are different states. An audit can reveal that a control exists in one layer but is not propagated downstream. It can show that a fallback is configured but ineffective under the actual timeout window. It can identify stale routes, duplicated logic, inconsistent state handling, broken acquisition paths or security assumptions that no longer match the system.
We audit beyond code. Our reviews are deliberately multidisciplinary. Akwa periodically examines its security posture, including access controls, secrets handling, authentication boundaries, storage behaviour, exposed surfaces, dependencies, and whether previously identified risks remain adequately controlled. It examines its privacy posture, including data flows, retention, user rights, uploaded content, generated artefacts, account behaviour, and whether product evolution has changed the assumptions behind earlier assessments. It examines its legal stance, including terms, disclaimers, intellectual-property positioning, user responsibilities, production-output limitations, and whether public claims still match the product that actually exists. It examines UI and workflow integrity, including whether critical journeys work across web and mobile, whether users can recover from failure, whether error states are intelligible, and whether a feature that appears available is genuinely operational end-to-end. And it examines AI and production governance, including provenance, authority preservation, unresolved assumptions, cross-section coherence, and whether production-facing outputs accurately communicate their readiness state.
This is important because reliability failures do not respect organisational categories. A broken deletion workflow may be a UI defect, a privacy problem and a trust issue at the same time. An incomplete tech pack may be a generation failure, a contractual risk and a production-cost risk. A public claim may be technically true when first published and become misleading as the product changes. Auditing helps us examine the system across those boundaries.
7. QA automation is a living control system
Manual review does not scale on its own. Akwa therefore uses a QA Automation Suite to test critical product surfaces and workflows. The suite is not treated as a static checklist that was written once and assumed to remain sufficient. It is applied, reviewed and enhanced as the product evolves.
This distinction matters because Akwa is not a single-screen AI generator. It includes multiple product surfaces and user journeys across design creation, saved designs, illustration workflows, uploaded inspiration, production documentation, catalogues, collections, educational content and other acquisition and conversion paths. Each surface can fail differently. A page can load while its primary action is broken. A generation request can start but never complete. A workflow can succeed on desktop and fail on mobile. A public page can appear correct to a human visitor while exposing incomplete or incorrect metadata to search engines and automated crawlers. A feature can technically exist while the user cannot recover from a failed intermediate state.
Our QA automation work therefore focuses increasingly on journeys, not merely pages. When a defect escapes existing coverage, the response should not end with fixing that defect. We ask why the current assurance system failed to catch it. Where appropriate, the escaped defect becomes new regression coverage, and the QA suite is strengthened so that the same class of failure becomes harder to reintroduce. This creates a feedback loop: failure, diagnosis, fix, regression coverage, suite enhancement, re-test. The purpose is not to claim that automation catches everything. It does not. The purpose is to make each meaningful failure improve the system that guards against the next one.
8. Regression testing, smoke testing and live proofs
Automated tests matter. They are also insufficient on their own. We use multiple forms of validation because different failures appear at different layers. Regression tests help determine whether new changes break previously working behaviour. Smoke tests help verify whether critical workflows still function after deployment. Unit tests validate bounded pieces of logic. End-to-end checks test whether the actual chain works across its stages. And live proofs test real workflows against real deployed behaviour.
This distinction has mattered in practice. We have encountered cases where unit tests passed but a live workflow exposed a genuine integration defect. In one such case, the relevant parsing logic behaved correctly in tests, but production metadata did not survive a later composition boundary as expected. The live proof caught what the narrower test could not. That is not an argument against unit testing. It is an argument against confusing unit coverage with system reliability.
9. Mobile and web are different failure environments
Akwa operates across web and mobile experiences. That creates another category of risk: a workflow that succeeds in one environment may fail in another because of session behaviour, upload handling, browser differences, asynchronous state, permissions or platform-specific integration issues. We have learned to treat cross-environment validation as a first-class requirement rather than an afterthought. Works on my laptop is not a release standard. Neither is worked once on mobile. For critical acquisition and production workflows, reliability has to be tested where users actually encounter the product.
10. Multi-provider resilience
Generative AI infrastructure can fail for reasons unrelated to the quality of the underlying model. Providers can return rate limits. Spend caps can be reached. Requests can time out. Large generations can exceed practical execution windows. A model that performs exceptionally well under normal conditions can still become the wrong dependency for a particular failure mode.
Akwa has therefore been developing multi-provider fallback paths for parts of its generation infrastructure. The purpose is not to treat every model as interchangeable. They are not. Different models have different strengths, latency characteristics, context behaviour and output constraints. The purpose is resilience. A fallback should be selected because it can meaningfully handle the failure condition, not simply because it is another model name in a configuration file. We have also learned that fallback logic itself must be tested. A fallback that exists but cannot complete before the surrounding infrastructure times out is not operational resilience. It is theoretical resilience.
11. Stop regenerating everything
One of the most consequential changes to our Tech Pack architecture has been rethinking revisions. A naive generative workflow can respond to a small correction by asking a model to regenerate an entire large production document. That is expensive. It is slow. It increases timeout risk. And it creates a new problem: sections that were already correct can drift during regeneration.
Akwa has developed a gated revision patch approach designed around a different principle: change what changed, and preserve what did not. Instead of automatically recomposing the entire pack, the revision workflow can work from the existing pack, generate only the affected sections and merge validated changes over the prior state. If the patch is empty or unusable, the system can fall back rather than silently accepting a broken revision. This approach can reduce unnecessary generation and make revisions faster. More importantly, it changes the reliability model. A correction to one part of a production artefact should not casually destabilise unrelated parts.
12. AI-assisted interpretation, deterministic rendering
We have applied the same philosophy to visual production annotations. For parts of our flat-marker workflow, AI-assisted vision can help identify semantic anchor locations. Those anchors can then be persisted as structured data, while deterministic markers are rendered over the flats page. The distinction is deliberate: AI helps interpret, and code renders. This reduces the need to ask a generative model to recreate the entire visual artefact every time an annotation changes. It is another example of a principle that increasingly shapes Akwa: not everything in an AI product should be generated. Sometimes the strongest architecture uses AI for the ambiguous step and deterministic software for the reproducible one.
13. Feature flags before confidence
New reliability mechanisms should themselves be treated carefully. Some of our newer infrastructure has been deployed behind feature flags so that it can be validated against live cases before becoming the default path. This matters because the fix passed tests and the fix is safe to rely on in production are not identical statements. A gated rollout creates room to verify whether revision patches remain complete, whether cross-section dependencies update correctly, whether visual markers align across different garment geometries, whether fallbacks behave under real failure conditions, and whether recovery paths preserve state. Progressive validation is slower than simply turning everything on. It is also more defensible.
A worked example: distrusting the system's own assumptions
A recent internal review made this concrete. In one generated production document, the system had read a decorative visual element as a functional component, and then faithfully elaborated an entire chain of manufacturing detail for it: materials, an assembly step, a quality-control check. Every one of those lines was internally detailed. None of them should have existed, because the component itself did not.
What is instructive is the order in which the system responded. The coherence checks flagged that the invented details contradicted one another, and the review layer blocked the document from release. But the deeper defect was upstream: a visual misreading that the downstream logic then dutifully built on. So the fix was not another rule for that one case. It was a principle: do not let the system elaborate a component before it has established that the component exists. And when the human designer corrected the underlying visual fact, that correction was recorded as authoritative, so no later stage could quietly reintroduce the error.
There was a second lesson in the same episode, one about measurement. Some of the document's apparent richness was detail about a thing that was not there. Depth, counted naively, had been inflated by a mistake. That is why we treat our own success metrics with suspicion too: a document that looks more complete is not thereby more correct, and a quality bar that can be satisfied by producing more lines is the wrong bar.
Even publishing this article exercised the same discipline. Before changing the code that renders it, the tooling checked the current architecture rather than trusting its own record of how the system worked, and found that a remembered assumption was already out of date. It proceeded from what the codebase actually was, not from what it was assumed to be. That is the whole idea in miniature. Reliability emerges when a system is designed to distrust unverified assumptions, including the AI's assumptions, the team's assumptions, stale memory, prior architecture, its own generated output, and even the metrics it uses to judge success.
What AI-assisted development means to us
We are not interested in pretending Akwa emerged from a traditional software-development process untouched by generative AI. It did not. AI has been part of how we think, prototype, debug, test, document and build. We see that as a strength. But AI assistance does not transfer accountability away from the people building the product. If anything, it increases the need for discipline. Faster code generation can produce more software. More software creates more states. More states create more failure modes. And an AI product operating between creative intent and physical production has a particular responsibility: the output does not remain on a screen. It can influence fabric purchasing, sampling, construction decisions, manufacturing communication and cost.
That is why our engineering and governance work increasingly focuses on the less glamorous layers: recurring codebase and architecture audits; security posture reviews; privacy reviews and data-flow reassessment; legal-position and public-claims reviews; UI and workflow audits; an evolving QA Automation Suite; regression testing; smoke testing; end-to-end validation; live proofs; cross-device testing; structured provenance; authority preservation; deterministic gates; coherence checks; failure recovery; timeout handling; multi-provider resilience; revision patching; production-readiness logic; and explicit blockers.
We do not treat these as one-time certification events. Akwa changes. Its dependencies change. Its models change. Its workflows change. Its legal and regulatory environment changes. A control that was appropriate for yesterday's product may be incomplete for tomorrow's. So we return to the system. We audit it again. We test it again. We challenge whether documented controls are actually deployed, whether deployed controls are actually effective, and whether effective controls still address the risks the product now creates. This is slower than assuming that yesterday's assurance remains valid. It is also how trust is maintained.
The future is not AI-generated everything
We believe the stronger future is hybrid. Human intent. Structured design state. AI interpretation where interpretation adds value. Deterministic logic where rules can be enforced. Provenance where origin matters. Review where uncertainty remains. Visible failure where the system cannot safely proceed. And production artefacts that earn trust through their architecture, not merely through polished presentation.
Akwa is still evolving. Some reliability mechanisms remain gated while we validate them against live workflows. We continue to find defects. We continue to change the architecture when real behaviour shows that our assumptions were wrong. We consider that a sign of engineering maturity, not something to conceal.
The question was never whether AI helped build Akwa. It did. The question is what we do with the speed AI gives us. Our answer is increasingly clear: build faster, test harder, audit continually, preserve human authority, make uncertainty visible, and never confuse a convincing output with a trustworthy system.
The model may generate. The system must govern. And the controls must be tested, audited and improved. Production readiness must be earned.
Explore how this discipline shows up in the product: what makes a tech pack factory-ready, and why we built Design Trust.