Gideon Code — The full development cycle, orchestrated
A system that walks the full development cycle: requirements, architecture, database, specification, implementation with tests, verification and archive. With 2,935 test cases.
Constraints
- Every phase of development loses context when it hands over, and what is lost is never recovered.
- An assistant with no limits writes a lot and verifies nothing; the work looks like it advances and it does not.
- Architecture decisions are not written down, and three months later nobody remembers why something was chosen.
- Some decisions cannot be made by a system alone: the stack, the data schema and the size of a change.
- Real work does not fit in one tool: there is a terminal, a team chat, code review and a panel.
The problem
The problem
Software development does not fail in the code. It fails in the meetings: the requirement is half understood, the architecture is decided in a chat, the data schema is improvised, and the specification lives in the head of someone who went on holiday.
When work moves from one phase to the next, the context is lost. And what is lost is never recovered: it is rebuilt from assumptions, and every assumption becomes debt.
Gideon Code is a system that walks that full cycle and forces every phase to leave something written before moving on.
The sixteen phases
- 01 Design · four phases Requirements with stories and acceptance criteria → architecture and domain model → stack recommendation with alternatives → data schema, relationships, migrations and diagram.
- 02 Specification · seven phases Proposal → specification in normative language → technical design → tasks with estimates → implementation with tests → verification against the specification → archive of the closed change.
- 03 Interface · five phases Reference and preference analysis → human confirmation of those preferences → automatic selection of images and icons → parallel component generation → integration.
From requirement to archive, with no skipped step
The three moments it stops
A system that asks all the time is a form. One that never asks is a hazard. Gideon Code pauses at exactly three points:
- The stack Proposes options with their trade-offs and waits. Changing stack later costs months.
- The data schema Shows the complete design before the first migration is written.
- The size of the change If it estimates a change is too large, it stops and asks for a delivery strategy.
Three expensive-to-reverse decisions · everything else runs on its own
Quality, counted
- 2,935 Test cases verifying the system.
- 16 Phases in cascade, each with its own artifacts.
- 53 Commands covering the cycle and daily operation.
- 4 Database engines supported in the design phase.
A system that orchestrates development has to be tested, or it contradicts itself
Nearly three thousand test cases are not a decorative figure: they are the only reason sixteen phases can change without breaking the ones that already worked. A system that demands tests in the phases it orchestrates, and does not test itself, is a contradiction.
It lives where the team already works
- Team chat Reports progress and receives commands from Telegram and Slack.
- Code review Reviews pull requests on GitHub without leaving the flow.
- Web panel State of the work, phases and decisions in one view.
- Decision memory Consultable knowledge graph: why each thing was chosen.
Same system to orchestrate the cycle and to run the day to day
And it organises what does not exist yet
Before building there is an ideation stage that does not live in a chat: variants of an idea are generated from different angles, registered as related entities, and two ideas can be merged into a new one. The result is a consultable tree that survives the conversation where it was born.
It sounds like a game and it is the opposite: most bad decisions are made because only one option was evaluated. This stage forces you to have five before choosing.
Why this also proves the development side
This system is not a product that gets sold and forgotten: it is the tool I work with every day. The full cycle of a senior developer is in there, made explicit and executable — from reading a requirement to archiving a verified change.
If anything proves I know how to build software, it is not saying it. It is having built the machine that forces it to be done right.
About the team
Gideon Code is mine: I founded it and lead it inside Alean. It is an internal team tool, not a public product, so it has no site or open repository. The architecture, the phases, the gates and the data model are my design; the implementation goes through pull-request review.
Decisions
- 01
The cascade is mandatory, not a suggestion
Every phase produces artifacts that feed the next, and none starts without what the previous one left. The requirement generates stories and acceptance criteria; those generate architecture and a domain model; that generates the data schema; the schema generates the specification; the specification generates the tasks; the tasks are implemented and verified against the original document.
RejectedChaining loose prompts. Each starts from zero, nobody remembers what was decided, and by the fourth phase the system is building something nobody asked for.
- 02
Three decisions stop to ask permission
The system pauses and asks at three points: before fixing the stack, before moving to data design, and when it estimates a change exceeds a reasonable size. Those are the three expensive-to-reverse decisions. Everything else runs on its own.
RejectedHuman approval at every step. It turns the system into a long form nobody reads, and the human starts approving without looking — which is worse than not asking at all.
- 03
Quality is counted, not declared
The system verifies itself with nearly three thousand test cases. It is not a decorative number: it is the only reason sixteen phases can change without breaking the ones that already worked. A system that orchestrates development and does not test itself is a contradiction.
- 04
The database is designed, not improvised
Data design is a phase with deliverables: schema, relationships, migrations and diagram. And it supports four different engines, because the engine choice belongs to the project, not to the tool.
- 05
The system lives where the team already works
It is not an isolated terminal. It reports to Telegram and Slack, reviews pull requests on GitHub, exposes a web panel with the state of the work and stores decisions in a knowledge graph so later phases can consult them. The same system that orchestrates the cycle handles the day to day.
- 06
It also organises what does not exist yet
Before building there is an ideation stage: variants of an idea are generated from different angles, registered as related entities, and two ideas can be merged into a new one. It is not a brainstorm in a chat; it leaves a consultable tree that survives the conversation.
Outcome
- Sixteen phases in cascade covering requirement to archive, with verifiable artifacts at each one.
- Three human gates on the expensive-to-reverse decisions — stack, data schema and change size.
- 2,935 test cases holding the system up while it evolves.
- Database design with deliverables and support for four different engines.
- Integration with Telegram, Slack, GitHub pull-request review, a web state panel and a decision knowledge graph.