GIGAPROTO: mobile UI from business requirements

At the Sber × PROSTO hackathon I worked in the multi-agent track on GIGAPROTO, a prototype platform that turns a business requirements document into a mobile interface. The task was to recognise requirements, create a prototype and executable code, check it against business goals and suggest improvements. Two banking scenarios were given for preparation, and an unknown third for evaluation, so a general approach mattered more than one hand-made screen.

Why JSON and not an image

I chose a GenUI approach: the agent returns a tree of components that can be rendered. The registry has 40 types: forms, buttons, navigation, cards, tables, transaction lists, filters and interface states. This makes the output inspectable: you can see its structure, check allowed components and re-render it.

Workspace: control schema example "Transaction history".

The agent process

1. Parser turns DOCX, PDF, TXT and Markdown into text, with a separate image branch through GigaChat Vision.
2. Analyst extracts goal, audience, screens, integrations and requirements with REQ-… identifiers.
3. Designer requests three variants, using design guideline context.
4. Validator returns a coverage score, missed requirements and structure and UX remarks.
5. Refiner fixes the schema when coverage is below 0.8, then validation repeats.
6. Recommender produces separate improvement suggestions.

Under the hood

The frontend uses React, TypeScript and Vite. Spring Boot is the API gateway; FastAPI runs parsing and agent stages. PostgreSQL stores documents, requirements, prototypes, checks and messages. Guideline search uses pgvector and falls back to text search. The code also validates JSON structure and filters dangerous strings.

Result and limits

I presented a prototype at Sber’s tech hub, combining parsers, agents, a renderer, chat, storage and an export path. The frontend builds, and the built-in schema passes structure validation.

The hackathon version still had unfinished joins between pipeline responses, frontend and gateway, and an export bug to fix. The source is in a private GitLab. The next step for such a system is one data contract and a test of the full path from uploaded task to a working exported project.