0

software-periodic-table

worthwhile

A finite ontology of 115 software elements to replace wasteful regenerate-every-pass LLM coding with deterministic composition.

Source ↗
software-periodic-table iconsoftware-periodic-table social preview

What it is

A curated ontology of 115 reusable software 'elements' (objects, properties, actions, interfaces, AI primitives, rules) stored as JSON + TypeScript stubs, designed for LLM-based coding agents to retrieve and compose rather than regenerate from scratch on each prompt.

How it differs from vanilla Claude

A vanilla Claude, given 'build a task board', regenerates User, Task, Status, Create, Table, Kanban, Drag-and-drop logic from scratch every time — wasting tokens and introducing semantic drift. This repo hands the agent a typed library of those atoms so it only outputs a composition plan and wiring code. The ontology itself is a single retrieval (JSON) vs. LLM's internal 'memory'.

Skill, plugin, or workflow shift?

It is a workflow-shift: the ontology becomes a permanent reference in your agent's context or vector store, altering how you prompt (composition over generation). Not a plug-in; not a standalone app; a reusable knowledge base that reshapes the LLM's approach to coding.

Devil's advocate — is this just complexity?

A capable Claude already knows what a User, Task, Status, or CRUD operation is — it doesn't need a lookup table. The claim that 'regenerating elements wastes tokens' is true, but the token cost of redefining 'User' in a prompt is trivial (<200 tokens) compared to the actual logic. The ontology adds an extra retrieval step (load JSON, search, plan) that may cancel savings. Worse, it hardcodes a finite set: real projects inevitably need domain-specific elements that aren't in the table, forcing fallback to regeneration anyway. This is a prompt engineering optimization dressed in academic formalities — complexity for complexity's sake.

What would make it better

Ship real LLM-based evaluation results (tokens saved, drift reduced, correctness) vs. Claude generating from scratch across 10+ realistic scenarios. Provide a VS Code extension or MCP server that auto-loads the ontology into agent context without manual steps. Add a 'domain pack' generator that creates custom elements from a user's schema, making the ontology extensible without waiting for upstream acceptance.

The honest case for it

For teams building many CRUD-heavy apps with LLM agents, this reduces a painful recurring problem: every generation pass re-invents the wheel slightly differently. The ontology acts as a shared vocabulary that two agents or human+agent can agree on, improving consistency, verifiability, and collaboration. The evaluation harness, once real, could provide the first empirical evidence that 'compose > generate' for code agents.

Who it's for

Audience fit

Primarily forAI-first Engineer
AI-first Engineer88

Depth and leverage for a technical engineer who wants to understand it and level up their workflow — not just offload work.

Vibe Coder25

Value for someone who wants a more capable tool without the technical depth — accessible, does-it-for-you.

Engineers get leverage via a curated ontology that cuts token waste and drift in LLM codegen; vibe coders see no immediate plug-and-play value.