Skip to main content

Philosophy

Radish exists because modern software teams face a recurring problem: many applications are conceptually simple, but expensive to build repeatedly from scratch.

The rise of AI-assisted coding has made it easier to generate code quickly, but the resulting systems often suffer from the same weaknesses:

  • architecture is inconsistent
  • the system is difficult to regenerate
  • data models and services are implicit instead of explicit
  • the output is hard to inspect and maintain
  • teams still end up rebuilding the core structure manually

Radish takes a different approach.

Architecture First​

Radish focuses on generating architecture, not polished final applications. The durable value in software lies in its structure:

  • data models
  • validation rules
  • service boundaries
  • metadata
  • access control
  • relationships between parts of the system

By generating these layers deterministically, Radish creates a foundation that developers can trust.

Blueprints as the Source of Truth​

In Radish, the durable artifact is the blueprint.

Prompts are useful. Conversations are useful. AI-generated suggestions are useful. But the blueprint is what the compiler understands and what the system can regenerate from.

Radish is built around:

intent → structured blueprint → deterministic architecture

Deterministic Generation​

The same blueprint should produce the same generated architecture.

This allows:

  • reproducibility
  • regeneration
  • reviewable diffs
  • AI collaboration on top of stable structure
  • confidence that generated code is not arbitrary

Framework Agnosticism​

Blueprints describe what an application is — entities, fields, relationships, ownership, permissions — not how it's built. This separation is deliberate: the same blueprint compiles to different technology stacks without changing a single line of the application definition.

Today, Radish generates production code for Node/SvelteKit/MongoDB (the default) and Laravel/PHP. Python is in development. Database adapters are expanding from MongoDB to SQLite and localStorage for desktop and lightweight deployments.

This means a team can:

  • prototype on one stack and ship on another
  • maintain a single blueprint while generating for multiple deployment targets
  • change implementation technology without redesigning the application

Radish is opinionated about architecture and process — deterministic generation, layered access control, blueprint-driven design — but agnostic about the language and framework that implement it.

Transparency Over Magic​

Generated code should:

  • live in the repository
  • remain readable
  • remain debuggable
  • be version-controlled
  • be separable from handwritten application code

Radish is opinionated about architecture, but it is not designed to take ownership away from the development team.

AI as a Structured Assistant​

AI helps with:

  • drafting blueprints
  • proposing entities
  • suggesting later layers
  • refining structured descriptions
  • helping developers build above the generated layers

This allows AI to operate in a narrower, better-defined space.

This philosophy is concretely implemented: radish generate uses AI to produce blueprints from natural language descriptions, and every generated app includes a complete AI development environment (.claude/agents/ and .claude/commands/) with specialized agents, slash commands, and skills that teach Claude Code the rules of the project. See AI Context for details.