Phos4
Make SQL feel like thinking, not typing.
A browser-based SQL IDE shipped with Mozart Data. I led three workstreams over the engagement: AI transformation for the team and the product, a frontend rebuild on a modern foundation with a deep theming engine, and the brand and web design Phos4 launched under.

How an AI training engagement widened into product, frontend, and brand.
Mozart Data was building Phos4 with an 11-person engineering team. They brought me in as an AI transformation consultant. The starting brief was to install agentic development as a discipline on the team.
Within the first few weeks the scope had to widen. The existing frontend wasn't built for what shipped on it: the SQL editor, the agent surfaces, the theming, the chart layer. The marketing site and brand were placeholder. The velocity needed to ship a product of this size was several multiples ahead of where the team was.
The engagement landed on three concurrent workstreams. I led all three.
Pair sessions, prompt patterns, review workflows, quality gates.
Mozart's engineers had AI tools available but no shared practice. Nobody on the team had used agentic development with discipline: no prompt patterns, no review conventions for AI-generated code, no quality gates, no shared mental model for when to drive the agent and when to take over. The work hadn't been compounding.
I embedded with the team. The work was concrete: pair sessions on real production tickets; a prompt architecture standardised across the team; review workflows that distinguish AI-authored from human-authored code; quality gates for AI-touched changes on critical paths; and shared templates, harnesses, and examples.
Commits per week
Weekly engineering output across an eleven-engineer team. The CEO learned the agentic practice alongside the team and moved from typical-engineer commit volume to roughly thirty percent of all commits.
Weekly commits climbed from about fifty to nearly a thousand.
The CEO learned the practice alongside the team. He moved from typical-engineer commit volume to producing about thirty percent of all commits, and held that lead by a wide margin. The chart above is the modeled view of that transition. A model projects 924 commits per full-rate week from sustained per-engineer throughput across the team. Weekly lines changed moved from 5K–10K to 30K–80K. The practice is still in place after I left.
Rebuilt the frontend: React 19, Vite, 285 components.
A SQL editor with dialect-aware intelligence, an agent surface, a chart engine, a schema browser, a profiler. All running concurrently, all sharing state, all driven by the same theming system. The existing codebase wasn't built for it.
I rebuilt the foundation. React 19 and TypeScript over Vite. 285 components organised across 33 feature categories. 66 reusable UI primitives built on Radix and shadcn/ui with Tailwind v4: 13 button variants and 5 input variants, every primitive documented in Storybook. Nine React Context providers for cross-cutting concerns (auth, file management, warehouse metadata, focus mode, user preferences). Ten Redux slices for domain logic (editor state, query execution, AG Grid configuration, formatting, profiler, schema browser, AI assistant). TanStack Query for fetching. AG Grid Enterprise for tabular data. Vitest for unit tests, Playwright for end-to-end, Storybook for visual regression.
Ten palettes flowing through every layer.
Engineers tune their environment all day, and the product had to absorb that without losing state, switching builds, or looking inconsistent across panels.
Phos4 ships ten palettes across light and dark, driven by a dynamic CSS-variable system and cached in localStorage so a switch is instant on the next reload. Every layer reads from the same tokens (chart primitives, editor decorations, Monaco themes, surface chrome), so a palette change flows through the whole product without anything looking grafted on. The viewer at the top of this page is the proof.
Four surfaces: the agents, the memory, the data, the editor.
Four surfaces run on the foundation: the routed agent system, the memory layer, the data surfaces around the editor, and the editor itself.
Three agents: write, review, pressure-test.
Alongside the coaching, I designed and built Phos4's first agentic AI surfaces inside the product. The architecture is a routed multi-agent system: one agent writes SQL, another reviews it, a third pressure-tests the data.
Under the hood: multiple LLM providers through OpenRouter. Streaming insights over server-sent events. A tool layer that dispatches to specialised handlers for dbt commands, git operations, schema lookups, and query analysis. Model selection so users can choose their provider.
Watch the routed system on a single SQL file. The agent surfaces the problem, drafts a reviewed fix, shows the diff, and benchmarks the output against the baseline. The engineer judges the work.
A working memory the agent earns through the session.
Conversation history carries context chips so users can pin specific tables, schemas, or prior queries to the conversation. Auto-analysis surfaces insight about query results inline. Findings accumulate across the session. The ones that hold up reaffirm, the ones that don't get invalidated, and what's left is a working memory of what the engineer has actually learned about the data.
Around the editor: pivot, profile, browse.
The editor is one panel; the rest of the tool is a working analytics surface. AG Grid Enterprise drives the result table. A custom column profiler reads distribution, density, and drift on every field. The schema browser, the pivot configuration, and the profiler share state with the editor through Redux slices, so a query, its results, and a pivoted view of those results are reading from the same ground truth.
Monaco that comprehends SQL.
Phos4's Monaco integration goes well past highlighting. 18 themes, semantic token mapping, CSS-variable integration. Dialect-aware behaviour for Snowflake, BigQuery, Databricks, and Redshift: CTE-aware code folding that follows the query's logical structure, a join profiler with predicate analysis and join-type detection, dialect-specific function autocomplete, Jinja templating for dbt workflows, and a baseline diff for comparing query versions. Focus Mode dims inactive panels; Zen Mode strips everything but the query and the result.
The team practice and the in-product agents were built side by side. Same scoping rules, same review conventions, same line between agent judgment and human judgment. That's why the team practice didn't unwind the day I left, and why the in-product AI rides the same review patterns the team uses.
Credit where it's due. The VP of Frontend Engineering built the DuckDB WASM integration that handles client-side SQL processing with Apache Arrow and Parquet, eliminating server round-trips for query execution. Other engineers built backend services, the profiler pipeline, and the warehouse connection layer. I owned the design, the frontend architecture, the theming engine, and the AI integration layer. The team built on top of it.
An Edison-bulb visual language for engineers close to the metal.
Phos4 had no mark, no typographic system, and no voice. The marketing site at phos4.ai was placeholder.
I designed the brand from scratch. Mark, palette, typography, motion. The visual language reaches back to the Edison-bulb and CRT-phosphor era of computing, when builders were tinkerers and the path from intent to result ran through equipment they could open up and adjust by hand. That era is the right reference for SQL because the work hasn't actually changed shape. Engineers still run real queries against real warehouses with real consequences, and the agentic layer compounds the parts that should compound without removing the engineer from the metal.
The marketing site at phos4.ai runs on the same tokens as the product, so an engineer arriving from a peer recommendation lands on the same surface they'll work inside all day. The hero on phos4.ai has a quiet trick: drag the cursor across the surface and the screen smudges along your trail like a finger across a CRT, exposing the code that's been there the whole time.
The web presence does its own work: positioning Phos4 against legacy SQL IDEs on one side and generic AI-wrapper products on the other; demoing the editor in motion; surfacing the agent's behaviour without making it the headline; converting the engineer who landed there from a peer recommendation.
What shipped.
Phos4 launched as a production SQL IDE at phos4.ai. The CEO is now the team's top contributor by a wide margin, the team is sustaining the new velocity, and a model projects a 924-commit full-rate week. The frontend ships 285 components on a foundation that carries the product. The brand and the marketing site put Phos4 in front of the engineers it's for.
Praise
Honestly, I don't think we'd have shipped on time without David. We had a broken front end, a team that hadn't really used AI in production, and no brand to put on the door. He worked all three at the same time, and we made it to our public beta.
Leon TchikindasCEO, Phos4LT





