Platform
Een full-stack console voor serieuze AI-softwarelevering
Logs, database, netwerk en fouten — zichtbaar naast de chat, zodat je de app debugt met bewijs en de bevindingen direct in je volgende prompt zet.
De full-stack console is het diagnostische oppervlak binnen de Ciao Builder: logs, databasestatus, netwerkverzoeken en fouten, zichtbaar naast het gesprek. In tegenstelling tot AI-bouwers die je laten gokken wanneer iets breekt, toont de console wat er daadwerkelijk over de hele stack is gebeurd — zodat de volgende prompt bewijs draagt, geen speculatie, en fixes landen op de echte oorzaak.
Gepubliceerd 2026-07-03 · Laatst bijgewerkt 2026-07-03
Debuggen van een app die je niet zelf schreef
Wanneer een app die je met AI hebt gebouwd zich misdraagt, is de slechtste positie om in te zitten gokken. Zit de bug in de UI, de query, de API-aanroep, of de data zelf? Zonder zichtbaarheid wordt een fix van één regel een middag speculatief prompten — herformuleringen proberen tegen een black box en hopen dat er een landt.
De full-stack console geeft je de zichtbaarheid die engineers verwachten, binnen de Builder: server- en browserlogs, databasetabellen en -rijen, netwerkverzoeken en -reacties, en fouten met hun context — allemaal naast het gesprek. Je ziet wat daadwerkelijk gebeurde, en zet dan het bewijs in de volgende prompt.
Dit is geen niche-power-user-oppervlak. De hele belofte van software bouwen uit gewone taal stort in de eerste keer dat iets breekt en het platform je niet kan tonen waarom. Zichtbaarheid is wat de belofte eerlijk houdt.
Hoe de console werkt
Alles gebeurt naast het gesprek — het punt is bewijs en actie op dezelfde plek te houden.
1. Open het naast de chat
Geen aparte tools, geen contextwissel. De console zit naast het gesprek en de live preview.
2. Lees de logs
Server- en browseroutput van de draaiende app, zodat 'het werkte niet' een specifieke regel op een specifiek moment wordt.
3. Inspecteer de database
Bekijk de daadwerkelijke Supabase-tabellen en -rijen achter de app. Bevestig of het record werd geschreven, en met welke waarden.
4. Bekijk het netwerk
Verzoeken, reacties, statuscodes en timings — vooral waardevol wanneer integraties en externe API's in het spel zijn.
5. Zie fouten in context
Storingen verschijnen met de omringende activiteit die ze produceerde, niet als kale berichten ontdaan van hun verhaal.
6. Verander bewijs in de fix
Verwijs naar wat je vond in de volgende prompt. Voor live productieproblemen test Doctor — de read-only AI SRE — de app, DNS en CDN, diagnosticeert de grondoorzaak en stelt de fix op.
Waarom dit ertoe doet
Prompten met bewijs verslaat prompten met gevoel. 'De POST naar /api/orders geeft 400 terug en de rij verschijnt nooit in de orders-tabel' levert een correcte fix in één ronde op; 'het bestellingding is kapot' levert een herschrijving op van iets dat nooit het probleem was. De console maakt het eerste type prompt mogelijk voor iedereen, niet alleen engineers.
Dit is een groot deel van wat AI-assisted engineering onderscheidt van hoopvol chatten: het systeem toont zijn staat, de mens redeneert erover, en de fix is gegrond in wat de stack daadwerkelijk deed. Na verloop van tijd levert dat een rustigere codebase op — minder speculatieve herschrijvingen, kleinere diffs, en een team dat de app vertrouwt omdat het er altijd in kan kijken.
Het verandert ook wie een applicatie kan ondersteunen. Een bureau of operationeel team kan 'wat gebeurde er met die bestelling?' beantwoorden met data in plaats van escalatie, omdat de vraag inspecteerbaar is op dezelfde plek waar de app leeft.
Wie gebruikt de full-stack console
De console bedient iedereen die ooit de vraag 'wat gebeurde er daadwerkelijk?' moest beantwoorden.
- Technische founders — Diagnosticeer hun eigen apps in minuten in plaats van elke hik te escaleren of blind opnieuw te prompten.
- Bureaus — Ondersteun klantapps professioneel — reproduceer het probleem, lees het bewijs, lever de gereviewde fix.
- Ontwikkelaars — Verifieer door AI geschreven backendgedrag — queries, schrijfacties, API-aanroepen — voordat je het met productiedata vertrouwt.
- Operationele teams — Bevestig dat dataflows tussen de app en bestaande systemen doen wat de integratie beloofde.
Security- en governance-notities
Zichtbaarheid is krachtig, dus hij komt met controls:
- ✓ Workspacetoegang, inclusief de console, volgt rolgebaseerde toegangscontrole.
- ✓ Fixes gestuurd door bewijs uit de console doorlopen nog steeds Guardrails-review en QA-gates vóór publicatie.
- ✓ Security bevestigt kwetsbaarheden tegen de live app voordat ze worden gemarkeerd — bevindingen, geen ruis.
- ✓ Doctor werkt read-only: hij test, diagnosticeert en stelt fixes op, maar wijzigingen gaan uit via de governed loop.
- ✓ Prompts, merges en deploys rond elke fix komen in de append-only audit trail terecht.
Wat de console toont
Vier oppervlakken dekken de meeste onderzoeken end-to-end:
| Oppervlak | Wat je ziet | Wat het beantwoordt |
|---|---|---|
| Logs | Server- en browseroutput van de draaiende app | Wat werd uitgevoerd, en wat het rapporteerde |
| Database | Supabase-tabellen, rijen en waarden | Veranderde de data daadwerkelijk, en hoe |
| Netwerk | Verzoeken, reacties, statuscodes, timings | Wat de app en externe systemen tegen elkaar zeiden |
| Fouten | Storingen met omringende context | Waar het brak, en wat eraan voorafging |
Veelgestelde vragen
Heb ik externe tools nodig om een app gebouwd op Ciao te debuggen?
Voor dagelijks werk niet — logs, database, netwerk en fouten zijn inspecteerbaar van binnen de Builder. Omdat de app standaard React, TypeScript en Supabase is die je bezit, kunnen je engineers ook elke externe tooling koppelen die ze verkiezen.
Kan ik de daadwerkelijke database bekijken?
Ja. De console toont de Supabase-tabellen en -rijen achter je app, zodat je kunt bevestigen wat een flow daadwerkelijk schreef. Het is vaak de snelste manier om een UI-bug van een databug te onderscheiden.
Hoe verhoudt de console zich tot Doctor?
De console is jij die naar de stack kijkt; Doctor is een read-only AI SRE die voor je kijkt — de live app, DNS en CDN testend, de grondoorzaak diagnosticerend en de fix opstellend. Ze werken het beste samen: Doctor voor productie-incidenten, de console voor onderzoek tijdens het bouwen.
Wie in het team kan de console zien?
Toegang volgt rolgebaseerde toegangscontrole op de workspace, dus jij beslist wie logs en data kan inspecteren. Enterprise-plannen voegen SSO via SAML en OIDC en optionele MFA toe.
Omzeilt het gebruik van de console governance wanneer ik een fix lever?
Nee. De console informeert de fix; de fix mergt nog steeds onder Guardrails met vastgelegde menselijke review, doorstaat QA-smoke gates vóór publicatie, en wordt vastgelegd in de append-only audit trail.