Cybercoding Codex history

Picture two castles.

The first looks glorious from a distance — turrets catching the light, banners flying, a drawbridge that lowers on command. Walk closer, though, and you notice the foundations are sand. The walls are painted plywood. It's a film set, built fast, built to be seen, never built to be lived in.

The second castle is less photogenic. Thick stone walls, a moat, a keep that has survived sieges. It took longer to build, and it isn't trying to impress you from a distance — it's trying to still be standing in a hundred years.

That image — a castle split down the middle, fragile on one side, fortified on the other — is how we introduced the difference between vibecoding and cybercoding on stage at AI Summit Barcelona. It's a fair picture, and not an unkind one. Vibecoding isn't a mistake; it's a film set, and film sets have their place. The mistake is moving your family into one.

This book tells the story of how we found that out the hard way, what we built instead, and how you can use the same approach — whether you're a solo developer shipping your first SaaS, a CTO trying to get a scale-up's codebase under control, or a CISO staring down a NIS2 compliance deadline with a portfolio of legacy applications nobody wants to touch.

It starts, as these things often do, with someone staying up late on a weekend.

Thomas, one of our developers, spends a weekend playing with a new tool called bolt.new — one of the first browser-based platforms where you can describe an application in plain English and watch AI generate working code in front of you, live, in the browser.

It isn't the first AI coding tool anyone had seen. But it's the first one that feels like a demo made real — no local setup, no boilerplate, just a prompt and a running app a few seconds later. By Monday, Thomas has shown half the team.

That weekend is, as much as anything can be, the birth of what the industry would later call vibecoding: describing what you want in natural language and letting an AI model write — and often deploy — the code, with the human steering more by feel than by specification.

It's intoxicating. It's also, we would learn over the following year, incomplete.

We don't roll AI coding out gradually. We roll it out everywhere, on purpose, as fast as possible. Every internal tool, every prototype, every “we've been meaning to fix this” backlog item becomes a test case. The instruction to the team is simple: whatever you're about to build by hand, try building it with AI first.

The results are uneven, and that unevenness turns out to be the most valuable data we could have collected. Interfaces come together in hours. Anything involving business logic, data modeling, or — very noticeably — security, comes together in a much shakier way, if it comes together at all.

By spring, a pattern is obvious: AI-assisted coding is extraordinary at the parts of software a user can see, and unreliable at the parts a user can't. That gap — front-end brilliance, back-end fragility — would define the next year of our work.

We get our first real-world test outside the lab: TopFlix Academy, an online learning platform. The existing build had cost well over €1 million using traditional development. Our brief was to rewrite it.

Two people. One summer. AI-assisted from the ground up.

They deliver a working, deployed platform — not a demo, a real product handling real users — at a fraction of the cost and in a fraction of the time a traditional agency would have needed. It's the first project where “AI-assisted rewrite” stops being an internal experiment and starts looking like a genuine alternative to how software gets built.

It's also the project that convinces us this approach has commercial legs — and the direct seed of what would later become the WakaStart forge.

But TopFlix Academy is a green-field build with a small, contained scope. The real test — the one that would expose the cracks in the castle — was still ahead of us.

Claude Code and Opus 4.5 arrive, and with them a genuine step-change in what AI-assisted development can produce. But the more ambitious our projects get, the more clearly the limits of pure vibecoding show themselves.

A few patterns recur, project after project:

• Front-ends shine; back-ends don't. AI models are extremely good at producing interfaces that look right. They are far less reliable at producing back-end logic, data models, and integrations that hold up under real usage.
• Database design evolves ad hoc. Without a deliberate schema designed up front, tables get added and patched incrementally, prompt by prompt — a recipe for the kind of structural debt that's invisible until it isn't.
• Pre-packaged backends become a crutch. Tools like Supabase make it trivially easy to bolt on authentication and a database. They also come with real limits on scalability, cost, and — critically — security, once you move past prototype scale.
• The AI makes security decisions no one signed off on. Left unsupervised, a coding assistant will choose an authentication approach, a permissions model, a way of handling secrets — and it may well be a reasonable one for a demo. It is rarely one that would survive a security review, and it is almost never one a human deliberately chose. That's precisely what makes it exploitable — including, increasingly, by other AI systems designed to probe for exactly this kind of unreviewed decision-making.

None of this makes vibecoding useless. For mockups, demos, and iterative front-end work, it remains genuinely excellent — arguably unmatched. But once you're building something meant to run a business, hold customer data, or survive a security audit, the fragile castle stops being charming and starts being a liability.

We needed a different approach. Not “AI writes less code,” but “AI writes code within a structure a human designed first.”

Out of that realization comes WakaStart: not a rejection of AI-assisted coding, but a deliberate inversion of it. Where vibecoding starts with the interface and works inward, WakaStart starts with the foundations and works outward — infrastructure and security decisions made first, deliberately, by humans and documented exhaustively, before a single line of application code gets written.

Two disciplines sit at the center of the approach:

Reverse-engineering as a first step. For any existing system — legacy or otherwise — the forge begins by extracting everything: functional behavior, data structures, edge cases, undocumented quirks. Nothing is assumed; everything is verified against the real system.

Exhaustive specification before generation. Instead of prompting an AI incrementally and hoping the architecture holds together, WakaStart produces a complete Product Requirements Document — sometimes running to hundreds of pages — that captures every screen, every rule, every security requirement, before the coding phase begins. The AI doesn't improvise the architecture. It builds to a blueprint a human already validated.

This is the seed of what we'd come to call cybercoding: AI-native development, but with the discipline of traditional software engineering — security, architecture, and infrastructure — applied before the AI starts typing, not patched on after.

The first real proof of the new approach is WakaSign, an eIDAS-compliant electronic signature platform — the kind of product where “trust us, it's secure” isn't good enough; the compliance has to be real, auditable, and built in from day one.

Built in a single month, WakaSign is designed to compete directly with established players like Yousign and DocuSign, but with security-by-design driven by NIS2 requirements from the outset rather than retrofitted for a compliance audit later.

It's a small product with an outsized implication: if a company can go from zero to a compliant, production-grade e-signature platform in thirty days — in a space where trust is the product — the approach clearly generalizes beyond one green-field build. The question stopped being “can this work once?” and became “how far can this go?”

That's not a compliment we gave ourselves — it's a paraphrase of what early clients called us, in early 2025, when we told them a full application rewrite would take a month, and an ISO 27001 certification four weeks.

Skepticism was the rational response. Nobody delivers those timelines — not with traditional development, and, frankly, not with vibecoding either, once security and compliance enter the picture. So we let the results argue for us.

A run of projects followed that proved the timelines weren't a fluke: Biped, Vicamed, OTeam, and others, each rewritten or built on the WakaStart forge, each shipped in weeks rather than quarters, each carrying security-by-design from day one rather than as an afterthought.

By the time the skepticism faded, we had a track record — and a much bigger challenge waiting.

Every approach eventually meets the project that tests it properly. Ours was Vinci Group.

Vinci ran a set of legacy ERP systems built on Windev — proprietary software used to manage subsidiaries and remote sites across the group. The situation forcing their hand was blunt: the Windev vendor had been acquired by a Canadian group, which then multiplied its pricing roughly 200-fold. Staying on the legacy platform was no longer a viable option.

The catch: no source code was available. Only documentation remained. A rewrite in the traditional sense — read the code, understand it, reimplement it — was not on the table. The only path forward was reconstructing the system's behavior from documentation and domain knowledge alone.

The scope: 600-plus screens and 200 printable report formats, rewritten from the ground up into a single, cybersecured, NIS2-compliant SaaS platform, deployable instantly across every Vinci site worldwide.

One month in, the project moved into testing and pre-deployment, with production go-live planned before the end of the year. This is the project we opened our AI Summit Barcelona talk with — the clearest evidence that the forge, born from a weekend experiment with bolt.new a year earlier, could now credibly take on corporate-scale legacy modernization with no source code to start from.

But Vinci is a private, months-long engagement. For the audience in Barcelona, we wanted something they could watch happen in real time, against a clock, with nowhere to hide. That's the Wakathon.

To prove the forge under real time pressure, and in public, we ran a Wakathon — a developer contest where our Waka Masters use the WakaStart forge to fully rewrite an existing piece of software, this time under the clock and in direct competition with each other.

The target: Kanboard, a well-known open-source, PHP-based project-management platform, MIT-licensed and therefore free to fork, study and rewrite without restriction — a large application, roughly 150 screens in total.

The rules: three Waka Masters received the brief at 10am on day one — the legacy application, its GitHub repository, and its documentation — and were asked to deliver a fully rewritten, cybersecured version of the application by the following day.

• 10:00–12:00 — reverse-engineering with the AI: largely a question-and-answer process to lock in the final security architecture for the rewrite.
• 12:00–14:00 (lunch break) — mockup generation for all 150 screens of the existing application, so every screen of the legacy system had a corresponding target design before any code was written.
• 14:00–17:00 (roughly, varying by Waka Master) — completing the reverse-engineering study, making the architectural decisions for the rewrite, and assembling the PRD to be handed to the forge overnight.
• After 17:00 — the three competing PRDs go into the forge. Claude has a five-hour overnight window to code each entire application, unsupervised, from the specifications alone.

Day two, 9:00am — the Waka Masters return to see what Claude built overnight. Two of the three find an application that is nearly production-ready out of the box. The third has to run a second pass: their functional specification wasn't precise enough, and a handful of screens were missing as a result — a useful reminder that the quality of the specification is what determines the quality of the output.

Less than two hours later, all three Waka Masters have a fully functional, cybersecured rewrite of Kanboard — a little before noon on day two, roughly 48 hours after the brief was first handed out.

That's the application we opened live on stage in Barcelona: the original, unmistakably dated PHP interface, next to its rewritten counterpart — the same functionality, secured by design, built almost entirely by AI, from a specification three humans spent one working day producing.

The tool behind all of this is WakaNalytics — the analysis and specification engine of the WakaForge. Here's how a project actually moves through it, step by step.

1. Choose the output. What should the forge deliver at the end: a SaaS application, an iOS app, an Android app, a desktop executable for Windows, macOS or Linux — or some combination of all of these?
2. Choose the project type. A brand-new application built from a specification; taking over an existing legacy codebase (our Kanboard example); rewriting an application from functional documentation alone, typically the case for Windev-style legacy systems (our Vinci example); or extending an existing WakaStart project with new functionality. This choice matters more than it might seem — it directly determines which reverse-engineering, analysis, and specification prompts get selected next, since they depend on both the target output and the nature of the project.
3. Load the sources. Source files and available documentation are loaded into WakaNalytics.
4. Establish context. A first prompt defines the global context of the project — what it is, what it does, who it's for.
5. Analyze. Specific prompts compute the project's complexity, and from that, a rough budget and timeline — and, just as importantly, identify the security elements missing from the original build, so the gaps can be addressed by design rather than discovered later.
6. Specify and mock up. WakaNalytics generates between six and eighteen technical specifications, plus screen mockups for every single screen of the application. Every screen — 100% — is reviewed and validated by the project owner before anything moves forward.
7. Assemble the final PRD. Only once every prior step is complete does the forge assemble the document that Claude will actually build from — grounded in everything generated and discussed during the analysis phase, not improvised on the fly.

And Claude doesn't build it alone. On average, 29 specialized agents are deployed across the build — covering back-end, front-end, design, UX, security, and identity and access management — each working to ensure the final result stays aligned with the requirements captured in the PRD and with the secure infrastructure it will be deployed to.

Deployment, finally, is a single click. CI/CD automation, environment provisioning for development, staging, and production — all of it is already hard-coded into WakaStart's hosting layer. There's nothing left to build there. It's a complete, pre-integrated stack — not a Supabase-style backend bolted on after the fact, which is the pattern you'll typically see in pure vibecoding.

By now the picture should be clear enough to state plainly.

In practice, that means:

• Infrastructure decided before code. Hosting, secrets management, identity and access — chosen deliberately, not driven by whatever the front-end happens to need. WakaStart, for instance, runs on sovereign EU infrastructure, on Kubernetes, with Keycloak for identity.
• Code-infrastructure alignment. Specifications are written with the chosen infrastructure already in mind, so the two never drift apart.
• Secure-by-Design and Zero Trust, applied at every stage — not as a single audit at the end, but woven through each phase:
  1. Analysis — rights, user profiles, data sensitivity, and GDPR implications are mapped before anything else.
  2. Exhaustive functional specification, with HTML mockups pre-validated against a design system — Claude Code effectively replacing traditional design tools like Figma for this step.
  3. Database design, done once, holistically — not incrementally patched prompt by prompt.
  4. A single exhaustive specification file, often hundreds of pages, handed to the coding AI — so the model builds to a plan, rather than inventing its own rules mid-build.
  5. Secured CI/CD, with dependency and CVE scanning that blocks any build containing a known vulnerability.
  6. Systematic SAST/DAST testing and AI-driven penetration testing, on every release, not just at launch.
  7. Hosting on infrastructure built for this from the start — Kubernetes, Keycloak, an open-source secrets vault — a bank- and military-grade open-source stack, not a convenience layer.

The payoff of aligning every one of those stages end to end — design, development, deployment, and hosting — is that the resulting Information Security Management System can be ISO 27001 certified across the full lifecycle, once, rather than re-certified project by project. Every application built this way inherits ISO 27001 and NIS2 alignment natively, instead of needing to prove it from scratch each time.

That's the whole idea. Not “AI, but careful.” A different starting point entirely.

Everything above sounds abstract until you place it against where you're actually starting from. In practice, we see three.

Different starting points, different pain points. Same forge, same speed, same security-by-design, every time.

We opened this book with two castles — one built to look good from a distance, one built to last. The story in between is really just an account of how we learned, project by project, which one our clients actually needed, and built the tooling to deliver it at the speed AI made possible in the first place.

If any part of this resonated — whether you're launching something new, trying to get a growing platform's foundations under control, or sitting on legacy systems you'd like modernized without pulling your team off everything else — we'd like to hear from you.

As a thank-you to everyone who attended AI Summit Barcelona 2026, and who reads this book as a result, we're extending four offers, exclusive to AI Summit Barcelona attendees and valid until 30 September 2026:

Scan the code below, or visit wakastart.com and cybercoding.ai directly.

Thank you for reading. Now go build something that's still standing in a hundred years.

— Denis Schirra
CEO, WakaStart / Wakastellar

Vibecoding

Describing an application in natural language and letting an AI model generate (and often deploy) the code, steered by feel rather than a formal specification. Fast and excellent for prototypes and interfaces; unreliable for back-end logic, data architecture, and security once a project moves past prototype scale.

CyberCoding

AI-native development where infrastructure and security decisions are made deliberately by humans first, with AI generating code inside that structure rather than inventing it along the way. See Chapter 12 for the full methodology.

WakaForge / WakaNalytics

WakaStart's platform for reverse-engineering, specifying, and generating cybersecured applications. See Chapter 11 for a step-by-step walkthrough.

Wakathon

An internal developer contest used to stress-test the forge: rewriting an existing application from scratch, under time pressure, in public. See Chapter 10.

NIS2

The EU's revised Network and Information Security directive, raising baseline cybersecurity requirements for a wide range of companies operating in or serving the EU market. Increasingly a prerequisite for B2B software contracts from 2026 onward.

ISO 27001

The international standard for information security management systems. WakaStart's ISMS is certified across the full design-development-deployment-hosting lifecycle, extending native compliance to every application built on the forge.

• TopFlix Academy — the first AI-assisted rewrite proof point, Summer 2025 (Chapter 4).
• WakaSign — eIDAS-compliant e-signature platform, built in one month (Chapter 7).
• Kanboard — the open-source project-management platform rewritten during the Wakathon (Chapter 10).

Learn more, get the tools, or claim your AI Summit Barcelona offer (valid until 30 September 2026): wakastart.com · cybercoding.ai