There is a Figma-compatible design editor, a JavaScript runtime for the BEAM, a frontend build tool, an npm client, several static analyzers, coding-agent tools, a DuckDB adapter, session replay, deployment tooling, and many smaller libraries in between.

Judging by my feed, it probably looks like I wake up every few days with an unrelated idea, build it, publish it, and move on to the next one.

That is partly my fault. I have explained each project when I released it, promised to explain how they fit together, and never did.

TL;DR

I am building an end-to-end open-source platform for startup factories. By a startup factory I mean a venture studio: a small team, often one technical founder working with agents, that launches many products, keeps the ones that work, and kills the rest. The platform follows each product through its whole lifecycle, from references and design drafts through prototypes, code, deployment, and acquisition, to the evidence that decides what to build next.

The process starts in OpenPencil, a design editor where the founder works with an agent the way they would stand behind a product designer: describing what is in their head, watching drafts appear, and steering until the design on the canvas matches the idea. Selected designs become working Vue components. The product then moves into an Elixir environment that connects coding, deployment, and operation, so a coding agent can see the whole product. If a customer gets stuck, the system can trace where they came from, replay what they saw, re-rendered from the backend state, inspect the code path, and propose a next step with evidence.

My ambition is an open-source platform that can eventually compete with Figma, Lovable, and Replit on a technical founder’s terms: a commodity design format, and the work after deployment.

<.building_this_year_project_map />

The rest of this post walks through the map roughly one stage at a time.

Who I am

I am a programmer, but I have never stayed in one narrow part of the stack. I have done systems programming, contributed to open source in the Xfce and nginx ecosystems, done white-hat security research through Google Bug Hunters and Bugcrowd, built web applications, and occasionally worked as a designer. I tend to move to whichever layer contains the problem.

I have also spent a long time working in venture studios, and I have founded and run small companies with my own money.

Running products on my own money made the economics impossible to separate from the product. A percentage point of conversion decides whether a campaign is profitable, and the cost of operating a product decides when to stop. That lens is why the platform described here does not end at deployment.

The first part of that process I tried to improve was design.

It started with Figma

I created figma-use to automate repetitive work in Figma. I wanted to inspect layers, make bulk changes, generate component structures, and export assets without clicking through the interface every time.

Figma’s own MCP server at the time could only read: it exposed the canvas as something close to a node-tree dump, and the agent could not change anything.

Coding agents became useful when the harnesses around them, the tools that wrap a model in a loop, gave them an iterative process: inspect a repository, make a change, run the application, read the error, compare the result with what was expected, try again.

I wanted to give design agents the same kind of loop.

Good design is iterative too. A designer normally begins by collecting references, then draws several drafts, compares them, and chooses a direction. After that comes a longer loop: copy, tweak, compare, choose, and repeat. The first result is rarely the final one.

Most AI design tools ignore this process. They try to generate a finished screen in one shot. Even when the screenshot looks impressive, the structure underneath is often useless: unnamed nested frames, no components, no tokens, and no coherent system that another designer can continue working with.

With figma-use, an agent could work on the actual structure. It could create and modify nodes, use components and variants, describe a screen in JSX and render it as Figma layers, inspect the resulting tree, and continue from there. A .figma.tsx file defines components; the first render creates the master, the rest create instances:

import { defineComponent, Frame, Text } from 'figma-use/render'

const Card = defineComponent(
  'Card',
  <Frame style={{ p: 24, bg: '#FFF', rounded: 16, flex: 'col', gap: 12 }}>
    <Text style={{ size: 22, weight: 'bold' }}>Card / Header</Text>
    <Text style={{ size: 14, color: '#555' }}>Updated 2 min ago</Text>
    <Frame style={{ p: 10, bg: '#2563EB', rounded: 8 }}>
      <Text style={{ color: '#FFF' }}>Reply</Text>
    </Frame>
  </Frame>
)

export default () => <Card />

I added visual diffing so it could see what changed, and design linting so it could catch structural and accessibility problems. I also wanted design files in automated pipelines: linted in CI, compared between revisions, and exported without anybody opening Figma.

<.building_this_year_design_diff />

Then Figma released an update that blocked the debugging interface figma-use relied on.

I found workarounds and kept the tool working, but the larger lesson was obvious. I could not build this kind of infrastructure on access that a vendor could remove at any moment. If agents were going to treat design as a real programmable medium, the editor itself had to be open.

That is how OpenPencil began.

OpenPencil became a toolkit

OpenPencil initially gave me an independent environment for the work I had started with figma-use. It could open and write .fig files, render them without Figma, and let agents modify the actual document structure.

While refactoring the project, I realized that the editor itself should not be the only useful result. I split the monolith into packages: the file format parsers, the scene graph, the editor core, the CLI, the MCP server, and a headless Vue SDK. The OpenPencil application is now one consumer of them.

The Vue SDK lets developers construct a different editor shell around the same engine. They can embed an editing surface into their product, expose a restricted editor for a particular workflow, or add design tools to an IDE without forking the OpenPencil interface.

The engine does not require an editor UI at all. A script or CI job can query a .fig file, lint it, extract tokens, convert it, render it, compare it with another revision, or modify it through the same operations used by the application and its agents.

The application itself has moved quickly this year. It opens .fig and its own .pen files, imports and exports the formats designers and developers already use, from HTML and Tailwind to PPTX and Storybook, and collaborates peer to peer with no server. Agents reach it through MCP, WebMCP, ACP, and a companion runtime that runs Pi inside the app.

My goal is to make .fig a commodity. If independent software can parse, query, render, modify, and convert the format, it stops being something that can only be fully used inside Figma. It becomes input for other editors, IDEs, and automated pipelines.

This solves access to the design structure, but not the boundary between a design and the application eventually built from it.

From designs to real components

The next direction I started exploring is VuePencil: something like Figma, but for Vue components.

Many visual HTML builders have an abstraction problem. The editor is already an HTML application, and then it tries to build another HTML application inside itself. The layers gradually leak into each other. The tool either supports only a restricted subset of HTML and becomes brittle, or exposes more and more browser internals until it turns into a complicated version of developer tools.

Vue already has a suitable abstraction for this: the VNode tree, its in-memory description of what it renders. In VuePencil, that tree is the source of truth. Editor operations change the model, Vue renders it, and the editor reads the resulting geometry to position selections and handles. It does not directly rewrite the rendered DOM.

This also means that the things placed on the canvas can be real components. The current prototype supports Reka UI primitives, component parts, named slots, props, bindings, and VueUse composables. A switch on the canvas is the real component, and it works in preview mode:

<SwitchRoot v-model="enabled">
  <SwitchThumb />
</SwitchRoot>

The result can be serialized as a normal Vue SFC. Frames and canvas positions remain editor metadata. Slots become Vue slots, capabilities become composable calls, and bindings become ordinary Vue expressions.

This makes prototypes much more useful than links between static screens. A founder can continue the design process with working state and interactions, then take the resulting components into the coding environment. VuePencil is still an early experiment. It is the direction I want OpenPencil to grow in: a canvas of real components, past Figma compatibility.

Why Elixir?

Once the prototype becomes a real application, design is only one part of the problem. You need a backend, storage, background jobs, external APIs, deployment, analytics, and a way for agents to work with all of them. The question was which language all of that should speak.

For mathematics there is Lean. Every definition, theorem, and proof is written in one language and checked by one small, trusted kernel. A model trained on Lean does not spend capacity learning five notations for the same idea, and every step it takes gets a verdict. My bet is that this is why such models reason so densely.

<.building_this_year_lean_sample />

I want the same for the web stack: one language in which bundling, the JavaScript runtime, storage, the backend, deployment, and operations share the same kind of API, the same runtime, and the same checks, while JavaScript, Rust, and SQL keep doing their jobs underneath. Elixir is the closest thing I found, and the rest of this post is what it took to make that true. I first wrote about this intuition in “A language for humans and models”.

All of it in one session, the same one an agent works in:

# Build the frontend.
{:ok, build} = Volt.build()

# Run JavaScript inside the application, as a supervised process.
{:ok, html} = QuickBEAM.call(:renderer, "render", [%{page: "home"}])

# Search the code by structure.
ExAST.search("lib/", "Repo.transaction(_)", inside: "def _ do ... end")

# Build the dependence graph of a file.
graph = Reach.file_to_graph("lib/payments.ex")

# Call a model through one path, with quotas and accounting.
{:ok, reply} = LLMProxy.chat("Summarize this incident", model: "fast")

# Query the analytics store.
MyApp.AnalyticsRepo.all(MyApp.Analytics.category_latency())

# Fetch what one user saw.
recording = PhoenixReplay.Recordings.fetch!(id)

# Plan and apply the host.
{:ok, plan} = HostKit.plan(project, target: :prod)
HostKit.apply(plan, confirm: true)

# Ask the runtime itself.
Supervisor.which_children(MyApp.Supervisor)

I was skeptical when José Valim, the creator of Elixir, published “Why Elixir is the best language for AI”. A benchmark result like the AutoCodeBench score he cites says little on its own. One of his reasons stuck with me, though: the ecosystem has stayed stable, so a model has not learned five generations of conflicting APIs. After a few months of building Elixir with agents, I agreed.

Elixir is dynamic too, so this is not typed versus untyped. But data flow is explicit, pattern matching puts contracts in the code, conventions are consistent, and the compiler and the growing type system catch more with every release.

In JavaScript and Python projects I see the opposite. Strict types sit on top of those languages as optional layers, while their ecosystems contain many competing generations of tools and conventions. Agents mix ESM with CommonJS, use an old framework pattern beside a new one, hand-roll something the project already has, or create another implementation because they did not find the first one. Skills and prompts can reduce this, but they do not change the language underneath.

Then there is OTP, the framework of processes and supervisors that Elixir inherits from Erlang. User sessions, background jobs, external API calls, and agent runs can all be represented as isolated processes with explicit ownership and supervision. One process can fail without taking the rest of the application with it. The running system is also directly inspectable. The questions an engineer asks in a shell, an agent can ask too, one call each.

<.building_this_year_runtime_map />

José made the same argument from the tooling side in “The future of coding agents is vertical integration”: an agent works much better when it can connect source code to the browser, logs, database, and running application instead of asking the developer to translate between them.

Checking what agents write

Lean is only half notation. The other half is the kernel, which tells the model whether each step holds. Elixir's compiler, Dialyzer, and tests are a start, but the scale at which agents produce code created a problem none of them catch: keeping that code coherent over time.

Agents tend to focus on the immediate task. They often fail to notice that a similar implementation already exists elsewhere, so they create another one. The copies then evolve separately: a bug is fixed in one but not the other, their behavior gradually diverges, and later agents add another variation because they cannot tell which one is canonical. This is one of the classic ways a vibe-coded codebase turns into a mess.

I started turning the checks I was performing during reviews into tools.

ExAST is structural search and replacement for Elixir. Grit rewrites code with structural patterns and CodeQL queries it as a database, both across many languages through a neutral layer. ExAST is Elixir-native: a pattern is ordinary Elixir code, matched against the AST the compiler itself produces. Instead of grepping source text or inventing a regular expression, an agent searches for an Elixir syntax pattern and rewrites the matching nodes.

The questions a reviewer asks about generated code become queries over the tree:

import ExAST.Query

# Transactions that still have debug output inside them.
from("def _ do ... end")
|> where(contains("Repo.transaction(_)"))
|> where(contains("IO.inspect(...)"))

# Handlers for the two events the interface actually sends.
from("def handle_event(event, _, _) do ... end")
|> where(^event == :click or ^event == :keydown)

# Comparisons that are always true.
from("left == right") |> where(^left == ^right)

Rewrites are patterns on both sides, and the agent sees a plan of every replacement and conflict before anything is applied. The same engine diffs code structurally, so a function that moved is reported as a move. ExAST sees structure only, so a plan is a proposal; whether a rewrite is safe still takes judgment.

ExDNA detects duplicated code structurally and says how to fix it. It finds exact copies and copies with renamed variables by default, and near-duplicates with changed literals when asked, then proposes the extraction: a function, a macro, or a behaviour. It runs as a compiler step, a Credo check, or a language server, so the same finding reaches CI and the editor. I use it with a zero-duplication budget in most of my projects.

ExSlop is a set of Credo checks for the other patterns generated code repeats: identity passthroughs, blanket rescues, queries inside Enum.map, and docs that narrate the code beneath them.

These tools mostly see local structure. A function can look reasonable in isolation while creating a bad dependency, bypassing an architectural boundary, or allowing untrusted input to reach a database, filesystem, or shell command.

Reach builds a program dependence graph for Elixir, Erlang, Gleam, JavaScript, and TypeScript: calls, control flow, data flow, effects, and OTP process relationships. It answers the questions that span files: what depends on this function, what a change might affect, and whether data can flow from a source to a dangerous effect. The last one is a command, here from request parameters to the database:

mix reach.trace --from conn.params --to Repo

The other questions have the same shape. Here they are asked of QuackDB:

$ mix reach.map --hotspots --top 3
  score combines branch count with caller impact
  QuackDB.Source.literal!/1  score=96  branches=4  callers=24
  QuackDB.SQL.literal/1      score=77  branches=7  callers=11
  QuackDB.SQL.literal!/1     score=31  branches=1  callers=31

$ mix reach.otp --concurrency
  Tasks        async      lib/quack_db/server.ex:423   1 async without matching await
  Monitors     trap_exit  lib/quack_db/server.ex:196
  Supervisors             lib/quack_db/application.ex:12

Reach also turns architecture into something agents can check. A project declares its layers and forbidden dependencies, and changes that cross them are rejected. Findings are advisory by default, and every suggested fix is labeled equivalent, conditional, or review-only, so an agent can tell a proven rewrite from a lead.

This site has such a policy. Three layers, and the lower ones may not reach up:

[
  layers: [
    site: "Blog.Site",
    plugins: ["Blog.SocialImages", "Blog.Markdown.*"],
    previews: "Blog.LinkPreview*"
  ],
  deps: [forbidden: [{:site, :plugins}, {:site, :previews}, {:plugins, :previews}]],
  calls: [forbidden: [{"Blog.LinkPreview", "Req.get/2"}]]
]

The last line is a trap I set for the example, and the check walks into it:

$ mix reach.check --arch
  1 violation(s)
  lib/blog/link_preview.ex:88 Blog.LinkPreview calls Req.get/2 (configured forbidden call)
** (Mix) Architecture policy failed

Smell findings carry the label in their JSON, the form an agent reads. Reach found these two in this site while I was writing the paragraph:

{"kind": "suboptimal", "location": "lib/blog/highlight.ex:33",
 "message": "Enum.map_join/3 defaults to empty separator; remove the \"\" argument",
 "remediation_safety": "equivalent"}
{"kind": "suboptimal", "location": "lib/blog/link_preview.ex:179",
 "message": "String.split/2 |> hd/1 splits the entire string; use String.split/3 with parts: 2",
 "remediation_safety": "review_only"}

The first is a proven rewrite. The second needs a look, because parts: 2 changes what the function returns when the string has more than one separator.

But adding more checks creates its own risk. A false positive is annoying for a human, but an agent may obey it and make the code worse just to silence the warning. A rule that looks convincing in a few hand-written examples may fail on perfectly reasonable code in a real project.

That is why I built Exograph: local CodeQL-style code search for Elixir, backed by DuckDB through QuackDB and ExAST. It indexes the entire public Hex package ecosystem and queries it by structure, similarity, and call graph. Running a proposed rule across that corpus is how I find false positives and decide whether it is reliable enough to keep.

As I was finishing this post, José Valim argued in “Evolving programming languages in the AI era” that agents need stronger guarantees and a program database with a query language more than an editor protocol built for humans. Reach and Exograph are my attempt at that database for Elixir: facts about calls, data flow, effects, and architecture that an agent can query.

The same tools are used to check themselves. My projects combine the compiler, tests, Dialyzer, ExDNA, ExSlop, Reach, and architecture rules. VibeKit installs that setup into a new or existing project with one command.

None of this makes blind vibe coding safe. It reduces some kinds of ambiguity, catches structural drift earlier, and gives agents more precise feedback when their work does not fit the rest of the system.

Frontend tooling in Elixir

Choosing Elixir did not remove the need for JavaScript. The npm ecosystem contains too much useful work, and Vue is a good abstraction for building interfaces. Rewriting all of it in Elixir would make no sense.

The problem was the separate operational world around it: Node processes, package managers, framework compilers, bundlers, and CSS tools, each with its own configuration and lifecycle. Calling JavaScript from Elixir is easy; start a Node process and exchange JSON. I wanted JavaScript execution to be observable and controllable as part of the same system.

That led to QuickBEAM.

In QuickBEAM, JavaScript runtimes and contexts behave like part of an OTP application. They have process ownership, participate in supervision trees, exchange messages with BEAM processes, and can be monitored, stopped, restarted, and inspected. JavaScript values map directly to BEAM terms.

Execution can also be constrained by memory and an instruction budget per call, in the spirit of BEAM reductions, so runaway JavaScript does not have unlimited control of the host application. Large numbers of lightweight contexts can share a small pool of runtime threads. Browser APIs such as workers, timers, storage, and networking are backed by OTP primitives, and runtimes can call each other across Erlang nodes.

In August it went a step further, with an interpreter that runs QuickJS bytecode as BEAM code. Each call gets a fresh heap, the scheduler can preempt it like any other process, and a failure is contained to one evaluation. I wrote about it in “JavaScript as BEAM code”.

JavaScript remains available where the ecosystem requires it, but it no longer disappears into an opaque Node sidecar.

Package management came next. npm_ex resolves, fetches, caches, and links npm packages from Mix, with no Node on the machine. It started as a small library for inspecting package.json and dependency trees, then grew into most of a package manager: a PubGrub resolver, a reproducible lockfile, and a global cache. It is also stricter than npm by default. Lifecycle scripts never run on their own, transitive git and URL dependencies are blocked, and an audit checks packages against the OSV list of malicious releases.

I also created Elixir bindings for the Rust tools that already do much of the real work in modern frontend toolchains: OXC for JavaScript and TypeScript, Vize for Vue, and Tailwind’s Oxide scanner, which finds class names in source files. These projects did not need to be rewritten; they needed APIs the BEAM could call directly.

Volt assembles these pieces into one frontend toolchain that replaces esbuild, the Tailwind CLI, and Node.js: a development server with hot module replacement, linting, and production builds for TypeScript, Vue, React, Svelte, and Solid. JavaScript tests run inside mix test, and since September every error in the chain, from OXC through QuickBEAM and Volt to PhoenixVapor, has the same diagnostic shape with file, line, and column. The toolchain starts with the application and can be configured, observed, and extended from Elixir.

<.building_this_year_volt_tree />

This removes one boundary, but frontend and backend code can still describe two halves of the same behavior and quietly disagree.

PhoenixVapor explores a more direct bridge. It compiles Vue template syntax into native Phoenix LiveView rendering structures, so it uses the same diff protocol with no wrapper elements. It has four modes: Vue syntax with no client JavaScript, server-side reactivity through QuickBEAM, a full Vue runtime on the server that renders third-party component libraries without shipping them to the browser, and a hybrid where the server owns application data while the browser owns local interface state.

<.building_this_year_vapor_wire />

This connects back to VuePencil. A component created there can remain a real Vue component. It can become an ordinary client-side Vue application built by Volt, a Vue island embedded in a server-rendered Phoenix page, or a template compiled into LiveView.

The coding environment

I am a big fan of Pi, Mario Zechner’s coding agent. Its core is deliberately small, and extensions, skills, and prompt files let me adapt it to my workflow, so I first built pi-elixir as a Pi extension.

pi-elixir connects Pi to the BEAM through three tools: evaluate Elixir, and search and rewrite the AST with ExAST. Evaluation can target the project, the running application, or a remote node, and values persist between calls like an IEx or Livebook session. The target project needs no change to its mix file.

But the more I extended the harness, the less natural its underlying execution model felt for the direction I wanted to take.

A coding harness is a concurrent, long-running system: model streams, terminal input, tool execution, background work, cancellation, retries, persistence, and eventually other agents. Pi implements all of this carefully in JavaScript, but the work still travels through layers of promises, callbacks, and terminal redraws inside one process, with ownership and failure boundaries maintained by convention. OTP has a more direct model. A session is a process, a model request and each tool execution are supervised children, and terminal, browser, and remote clients observe the session without owning it. Processes can be monitored, cancelled, restarted, or allowed to fail independently, and the scheduler preempts them.

I built Vibe to explore this architecture without the constraints of an existing harness.

In Vibe, sessions, agents, subagents, commands, and interfaces are OTP processes. Agents can start other agents and communicate through messages. They can run on one node or communicate across machines through Erlang distribution and SSH. Closing a terminal does not have to stop the work, and a failing subagent does not have to destroy its parent session. A background server owns the sessions, like tmux, so several terminals or a LiveView console can attach to the same one, and memory and past transcripts are searchable. Vibe can also run its own checks, patch its own code, and hot-reload the result, which makes it a first step toward agents that modify and improve themselves.

<.building_this_year_vibe_tree />

OpenAI reached the same conclusion. The reference implementation of Symphony, its system for supervising long-running coding-agent work, is written in Elixir.

Vibe is useful, but it is also an experiment. I do not want to force users to replace a mature harness with my half-finished one just to test each hypothesis. When an idea works in Vibe, I can bring it back into pi-elixir and test it inside Pi. The newer pi-elixir combines Pi’s model support, interface, and extension system with more of the BEAM-native runtime and structural tooling explored in Vibe.

Tilde develops another part of this architecture: separating an agent session from any particular interface.

A Tilde session is a stream of semantic events: a message was added, a tool started, output arrived, a choice was requested, or an agent completed its work. The same session can be rendered in a terminal, in a browser with LiveView, over SSH, or as structured data. Sessions persist through QuackDB, so one can be resumed after a restart, searched, and served over LiveView and SSH at the same time.

Common storage and APIs

A platform for building several products should not require a separate collection of managed services for each one. I wanted the default setup to remain cheap, portable, and easy to run locally.

For storage, I settled on DuckDB.

DuckDB combines much of the SQL surface I expect from PostgreSQL with the portability of SQLite. A complete database can live in one file, but it still supports analytical queries, full-text search, geospatial operations, Parquet, and direct access to S3. For many small and medium products, it can handle both ordinary application data and serious analytics without requiring a separate analytical cluster.

-- A campaign funnel, straight from a month of Parquet files on S3.
SELECT utm_campaign,
       count(DISTINCT session_id)                                AS sessions,
       count(DISTINCT session_id) FILTER (WHERE name = 'signup') AS signups,
       count(DISTINCT session_id) FILTER (WHERE name = 'paid')   AS paid,
       round(100.0 * paid / sessions, 1)                         AS conversion
FROM read_parquet('s3://analytics/events/2026-09-*.parquet')
GROUP BY ALL
QUALIFY row_number() OVER (ORDER BY conversion DESC) <= 10;

QuackDB makes DuckDB usable as part of an Elixir application: an OTP-supervised DuckDB process, a DBConnection client, an Ecto adapter, native append and streaming, and a query DSL so most work never touches raw SQL.

from e in Source.parquet("s3://analytics/events/2026-09-*.parquet"),
  group_by: e.utm_campaign,
  select: %{
    campaign: e.utm_campaign,
    sessions: count(e.session_id, :distinct),
    signups: filter(count(e.session_id, :distinct), e.name == "signup"),
    paid: filter(count(e.session_id, :distinct), e.name == "paid")
  }

DuckDB is becoming the common storage layer across the platform. Exograph’s index lives in it, pi-elixir mirrors its sessions into it, Tilde persists through it, LLMProxy’s standalone mode keeps usage in it, and the analytics fork is moving onto it. Vibe still keeps its sessions in SQLite.

I started QuackDB while DuckDB’s Quack client-server protocol was still experimental. It has since reached 1.0 in DuckDB 2.0, and with DuckLabs joining AWS while the project stays MIT-licensed under the independent DuckDB Foundation, I consider it a safe long-term bet.

Storage was one shared service. Model access is the other: not every product needs an LLM, but most now call one, and every product eventually depends on external APIs.

LLMProxy is one execution path for every model call, in the spirit of LiteLLM but Elixir-native: it runs inside the application, or standalone with OpenAI- and Anthropic-compatible endpoints. Callers ask for fast, smart, or cheap. Routing, fallbacks, quotas, and accounting happen behind those names, so a provider can change without touching a caller, and the founder sees where every token went.

I found the same pattern repeated with non-LLM services. A startup gradually accumulates APIs for email, advertising, payments, image generation, vectorization, search, and hosting. Each integration comes with its own authentication, retries, limits, credentials, errors, and accounting.

Egress is the next step, and it is still a design: an external service described once as a set of typed operations, such as creating a campaign or sending an email, that produce both an Elixir client and a proxy route through the same runtime path for authentication, retries, quotas, tracing, and accounting. An agent would call an operation with a contract and never see the URL or the provider’s authentication scheme. The repository stays private until the first operations run.

Deployment without another platform

Once the application is built, it still has to run somewhere.

For small products, deployment often introduces another large stack: container registries, orchestration, managed databases, queues, proxies, secret stores, and several dashboards. These tools can be justified at a certain scale, but I do not want every experiment to begin with them.

Elixir already has a good deployment unit: an OTP release containing the application, its dependencies, and the runtime it needs.

ReleaseKit turns a Mix release into a repeatable, deployment-neutral artifact. It produces an ordinary tarball and a small manifest describing how to run it, which environment it expects, and how to check its health. It deliberately knows nothing about servers, users, systemd, or reverse proxies.

HostKit handles the other half. It describes a Linux host in Elixir: packages, users, services, secrets, firewall rules, and Caddy reverse-proxy routes. It reads the current state, produces a plan, applies the reviewed plan locally or over SSH, and can bootstrap a bare machine with no Elixir on it. A host is ordinary Elixir:

use HostKit.DSL, providers: [HostKit.Providers.Caddy]

project :prod do
  host :app, at: "app.example.com" do
    ssh do
      user "root"
      identity_file Path.expand("~/.ssh/id_ed25519")
    end
  end

  service :api do
    daemon :api do
      exec argv("/opt/api/bin/server", opts: [port: 4000])

      isolate do
        memory_max "512M"
        network :loopback
      end

      listen :http, port: 4000
    end

    caddy_site "api.example.com" do
      reverse_proxy :http
    end
  end
end

The result is ordinary Linux: services under systemd with restart policies, resource limits, filesystem restrictions, and network isolation. Everything is a library call first, and the Mix tasks are wrappers. So the questions an agent asks the runtime have host-level answers too: which ports listen, which services failed, what a plan would change, and how to roll it back.

HostKit is still a beta, but it runs my own infrastructure. It makes deploying a small or medium product cheap and understandable, with infrastructure as observable as every other part of the platform.

Once the product is running, the more interesting question begins: what are users doing, where did they come from, what is breaking, and what should change next?

From analytics to the next decision

The answers are usually divided among unrelated systems. Advertising platforms know the campaign and its cost. Web analytics knows the landing page and conversion. Session-recording software knows what happened in the browser. Application monitoring has the errors and traces. The BEAM knows the live process state. An LLM provider knows how many tokens were spent. None of them has the complete context.

I started experimenting with this in a branch of my fork of Plausible Analytics. ClickHouse is gone from that branch: analytics storage, imports, exports, and the job queue run on DuckDB through QuackDB, while Plausible’s own PostgreSQL stays for now. The goal is to keep traffic, funnels, attribution, conversions, and other product analytics in the same portable data layer as the rest of the platform, without a ClickHouse cluster for every product.

Aggregate analytics still cannot explain what happened to one particular user. For that, I built PhoenixReplay.

In a Phoenix LiveView application, much of the interface state lives on the backend, and the browser displays updates produced from that state. So instead of recording clicks and DOM changes in the browser, PhoenixReplay records the server’s assigns, sanitizes them, and re-renders them later. The replay shows each screen as the server produced it, next to the state behind it. Because nothing runs in the browser, client-only JavaScript state is outside the recording.

The next step is to connect these sources rather than open them in separate dashboards.

Suppose a customer arrives through a paid campaign, begins registration, gets stuck, and leaves. I want to see where they came from and how much that acquisition cost, replay what they saw, screen by screen, from the backend state that produced it, inspect related errors and traces, and follow the relevant code path. If an LLM or another paid API participated in the request, its latency and cost should be visible too.

<.building_this_year_customer_path />

Incant is the common admin interface for this. Resources, dashboards, datasets, and actions are modules, and a service declares what its admin pages contain, and a standalone Incant host renders them. LLMProxy’s provider usage already lives there; replay sessions, telemetry, campaign performance, agent state, and infrastructure are meant to follow through the same Elixir APIs.

An agent can use the same data. A background agent could notice that conversion from a campaign dropped, identify the affected landing page, inspect recent sessions, find where users started abandoning the funnel, and propose a change with the evidence that led to it. Each one arrives as a suggestion with its evidence attached, and the founder approves it or not.

How this differs from Figma, Lovable, and Replit

Figma is a different case. Once .fig is a commodity, a design no longer belongs to the editor it was drawn in.

Going through Figma’s own MCP server is no safer today. Figma’s remote MCP server decides which agents may connect at all: sign-in works only for client names on its list, such as Claude Code or Codex. This week, when Mario Zechner tried to connect Pi, his open-source coding agent, Figma refused it because Pi identifies itself as pi.

Lovable and Replit turn a prompt into a deployed application. I am trying to cover the rest of the founder’s work as well: operating the product, acquiring users, understanding what they do, and feeding that evidence into the next decision.

The technical foundation is different too. Skills can improve an agent on a JavaScript or Python project, but they cannot change its execution model or the conflicting conventions it learned there. Mine uses Elixir and OTP as the common environment and adds the checks, the observable JavaScript, the shared storage, and the live product data.

Lovable and Replit grew out of venture-capital culture, where rapid user growth can take priority over margins and usage can be subsidized while a company searches for scale. I am building from the perspective of a technical founder spending his own money. Infrastructure cost, API usage, acquisition cost, conversion, and the work required to operate the product are part of the system from the beginning.

Where this stands

The system in this post is still being built; nothing installs it with one command yet. Most of the building blocks are public and useful on their own; the map near the top marks which are still alpha or beta.

The main missing piece is integration. These projects already use one another—Volt uses QuickBEAM, Exograph uses QuackDB and ExAST, HostKit consumes ReleaseKit artifacts, and my projects run the quality tools on themselves—but they do not yet form one founder-facing product. The next phase is connecting what exists.

The most immediate product is OpenPencil Cloud: optional workspaces, synchronization, sharing, comments, and team component libraries, self-hostable, with local files still first-class. I also want to turn reference collection, alternative drafts, comparison, and iterative work with agents acting as designers into one coherent OpenPencil workflow, backed by a service that provides common access to language and vision models, image generation, and vectorization, something like OpenRouter focused on design, while still supporting users’ own credentials.

The path through VuePencil, the coding environment, and the rest of the platform then has to become a product. That includes the conventional building blocks founders currently get from Supabase or libraries such as Better Auth: authentication, accounts, files, notifications, and billing. Most of it will come from existing projects behind coherent Elixir APIs and defaults. And Incant has to connect to the operational sources that already exist.

Some packages will merge, some abstractions will change after real use, and some experiments will fail. Publishing the pieces independently is how I find out which.

How to help

Agents let me cover a lot of ground alone, but they cannot provide the variety of real use that a community can. Publishing each building block separately puts it in front of files, operating systems, and workflows I never tested. Bug reports expose my assumptions, and contributions take the projects beyond my own needs. Open source is how I develop the platform as much as how I distribute it.

So the best way to help is to use the projects in situations I have not considered, report what breaks, and tell me which parts are useful outside your own workflow. Contributions are welcome too.

Funding the next phase

OpenPencil itself stays free and open source, and OpenPencil Cloud will be self-hostable. What I intend to build a company on is the services around it: hosted storage and collaboration, design references and other context for agents, illustration generation, and a design-API service, some of them in partnership with providers that already do this well.

Those services do not exist yet. Building them takes time, and most of the work runs on agents, so model tokens are a cost of their own. Until the services carry the work, I am looking for support.

<.article_callout>

After using it for a few days, I can conclude that while it is significant progress, there is still nothing paradigmatically new. It looks like we’ve plateaued across a whole set of cognitive abilities.

First, Astra, like other models, is still not critical enough of itself. It relies heavily on previous context compactions, doesn’t stop to take a bird’s-eye view of what has been done, and therefore isn’t capable of maintaining and updating a long-term vision.

This isn’t about having a checklist in a Markdown file. Sometimes you have to stop, reflect on the direction you’re going in, and make corrections with some degree of autonomous will.

Second, it still isn’t able to maintain strict boundaries within a conversation. I often ask models to prepare a draft of a reply to a PR, and they consistently fail either by leaking details from the internal conversation or by stepping out of my role and adding things like “X tests passed.”

This isn’t specific to Astra. All frontier models are still very bad at separating the conversational context from what should be retained in the code or shared with a third party, as well as what should remain private and what each party is already aware of. Zack noticed the same thing with Fable back in July: code comments that reference details from the chat and make little sense to anyone reading the codebase.

Of course, this can be tuned with a long prompt containing a set of example situations and appropriate replies, but that would still be imitation rather than understanding.

Third, long-tail sampling artifacts aren’t going anywhere either. Astra can still occasionally stop abruptly, mix up parts of words, or inject random fragments into otherwise coherent output. Once that happens, it won’t be able to recover on its own.

So it’s not AGI yet. Not even close.

Learning how to answer questions and learning how to code, no matter how complex the resulting code is, still doesn’t expose the model during training to the whole variety of behaviors that are natural for human beings.

So my approach is still valid: build environments where existing model capabilities, with some human guidance, can be used to collect enough data to train different behaviors. That’s how figma-use, and later OpenPencil, started.

JavaScript is compiled with QuickJS, verified, and can be pinned at startup. Each execution gets fresh state, preventing data from leaking between requests or jobs.

Because execution happens as BEAM code, Erlang can preempt and account for it like any other process. Under concurrent load, this should provide fairer scheduling and more predictable latency than work hidden behind a native runtime boundary.

Step, stack, memory, and wall-clock limits contain failures to a single evaluation.

This brings BEAM scheduling, isolation, and supervision to SSR, templates, user scripts, and small edge-style functions. For now, it supports a limited, tested JavaScript profile rather than the full browser or Node.js environment.

The original QuickBEAM runtime still runs each JavaScript runtime on its own OS thread; the interpreter is for work that should live under the BEAM scheduler instead.

Claude Code is vibecoded and full of spyware, it's possible Anthropic doesn't even know what's in there. After reading this report, we are banning it from our systems and strongly encourage other enterprises to do the same. It is an unacceptable security risk.

— the tiny corp (@__tinygrad__), 30 June 2026

Finally, somebody said it out loud. I’m not proud of OpenPencil’s code quality, but somehow a project maintained by a single developer is in better shape than what I saw in the leaked Claude Code source.

That’s also the primary reason I’m very skeptical about coding-agent swarms burning zillions of tokens. I don’t mean to insult anyone, but the last time I looked at OpenClaw’s code, it was in pretty bad shape.

There are three fundamental things you need to do constantly in your so-called loops if you want to keep a codebase healthy.

First, you need to force the agent to read the existing code to understand your style implicitly. Agents are tuned to read less and more selectively to save space in the context window. This is especially bad in JS codebases, where historically there have been too many coding styles across the ecosystem. Unless you show the agent examples of your style, expect a dice roll every time.

Second, you need to remind the agent to look around. It should be able to inspect the surrounding architectural slice to learn what entities already exist, how they relate to each other, and how the source tree is organized. Otherwise it will tend to satisfy the “business need” by taking the shortest path, like the laziest junior developer. It will likely introduce duplicate entities and multiple implementations of the same concepts, then evolve them independently, making the situation worse over time. It will reimplement functionality that already exists in the standard library or the ecosystem, create ad hoc test files, favor loosely connected internal abstractions, and later spend a lot of effort “normalizing” data between them. Over time, the codebase will gradually drift away from the architecture you originally built.

Third, if you don’t want to waste your time babysitting the agent and repeatedly enforcing best practices, you need to give it the tools. Prompts, skills, or whatever you want to call them, will never fully override the model’s innate behavioral patterns. You need an automated oracle that continuously checks the output for style, code duplication, antipatterns, and architectural drift.

A simple linter setup won’t help much, because most linters are still designed to catch human mistakes. Agents make those mistakes too, but they also introduce an entirely new class of problems on top of them.

None of this is really the agent’s fault. These are failures of the environment, not the model itself. Give it the right hints, the right context, and the right tools, and it can avoid most of these problems and write the code properly. The real problem isn’t the models anymore. They’re already pretty strong. The real problem is the setup around them.

Given that barely any of this has been seriously addressed by the coding harnesses from the major AI labs, I have the feeling that very few of them actually care about what it takes to build and maintain high-quality software.

Claude Code itself is proof of that.

You should basically never use Fable for coding, but instead use it as a planner/orchestrator.

Most of today's advanced models can implement a spec perfectly, and once done you can send the work to Fable to review.

This has been my most powerful flow so far.

— Pietro Schirano (@skirano), 11 June 2026

For me, the ultimate intelligence benchmark is still text writing. Which is kind of ironic, because models that were initially created to generate text are still often that bad at it.

If you write professionally, you quickly notice that it’s usually easier to write the text yourself than to edit whatever the model generated. Today, only the largest models can be genuinely helpful with that. That’s GPT-5.5 Pro — which, judging by its behavior, feels to me like a successor to the sunsetted 4.1 large model — and, as of today, Fable too.

My benchmark is pretty simple: I take large portions of fiction books by no-name authors, including me, and ask the model to continue them. Only the larger models are really able to capture the voice, the barely noticeable nuances of vocabulary, and the author’s biases. Smaller models quickly fall back into default, flavorless narration, with a few bits of pretentiousness sprinkled in.

On the matter of loops, I give you my 12 months old slop blog post. Let's call it a "proto-loop". We were much more innocent back then.

https://mariozechner.at/posts/2025-06-02-prompts-are-code/

— Mario Zechner (@badlogicgames), 9 June 2026

I discovered that I’m (unsurprisingly) a very predictable person over longer periods of time.

So I pretend I don’t know what to do next and ask the agent every time. It updates the plan, and I mostly make small adjustments along the way.

Of course, sometimes I have to stop and write a lot of profanity. But most of the time it works surprisingly well and even suggests ideas I wouldn’t have arrived at as quickly myself.

The funny part is that models like GPT-5.5 are already good enough at understanding my habits that I can communicate in increasingly caveman-like language. I have prompt-template shortcuts for many common interactions, and I keep making them shorter and more cryptic. These days I often type just a few letters and let the rest unfold from there.

I’m gradually formalizing the process and will probably write about it soon.

Postgres is still the obvious default for highly concurrent OLTP systems, but many small and medium products are read-heavy, append-heavy, analytical, or operated by a small team. For those workloads, DuckDB’s columnar execution model, vectorized engine, rich SQL surface, and embedded/local-first deployment model can be a much better fit.

I intend to use DuckDB as the primary storage layer for the platform I’m building, so QuackDB focuses on the parts I need in a real Elixir app: supervision, connection pooling, Ecto, fast append paths, dataframes, telemetry, and helpers for DuckDB’s analytical SQL.

QuackDB 0.5 focuses on making the Ecto and analytical side much more complete:

• append through Ecto with defaults and returning
• using an Ecto repo directly with QuackDB native query/append APIs
• advanced join patterns, including semi/anti and ASOF-style queries
• DuckDB star/COLUMNS expressions in SQL and Ecto
• broader LIST/MAP/STRUCT helpers
• PIVOT, UNPIVOT, GROUPING SETS, ROLLUP, and CUBE builders
• LIST lambdas in Ecto with fn syntax and case_when
• better nullable/schema type handling for append-heavy workloads

QuackDB also continues to cover the broader integration surface: supervised DuckDB, DBConnection/Ecto, native append, Explorer dataframes, Table.Reader results, Geo/WKB, telemetry, managed DuckDB binaries, and DuckDB-specific SQL helpers.

Update, August 2026

DuckLabs is joining AWS, with DuckDB and the rest of the Duck Stack staying MIT-licensed under the DuckDB Foundation. I’m now pretty confident that DuckDB is the right bet as the primary storage engine for the platform I’m building.

QuackDB, the Ecto adapter for DuckDB’s Quack protocol, is in good shape. I’ve spent a lot of effort polishing the DSL and internals for scenarios like bulk inserts, and I’m already using it in production across several projects.

I do my best to respond quickly and help with adoption. I’ve done my best to extract signal even from the worst PRs. But my capacity is limited, so here is how I handle pull requests in these dark times.

If a PR is well-written overall but I only have a few nitpicks, I often merge it and make a follow-up commit myself. The review back-and-forth is often more expensive, and it’s harder to keep track of many conversations.

If a PR isn’t in great shape and I’m not willing to merge it, I treat it as an open issue instead. If it contains good ideas or useful hints on how to fix things, I do a “vibe-merge”: I implement the code myself but add the original author as a co-author to give proper credit.

Otherwise, I close it with a polite AI-generated reply.

Many people are saying that OpenPencil has one of the most generous pull request policies anywhere in the world. Frankly, they’re probably right. So pull requests that don’t follow CONTRIBUTING.md are now rejected automatically.

The next step requires proper abstractions for bidirectional design-to-code mapping.

And all the vibe-coding platforms like Replit and Lovable are already hitting the limits of project scale because they generate unmanaged and unmaintainable AI-slop backends.

That’s why I feel comfortable building a competitor to all of them, solo and in the open.

Vibe combines the vibe-coding tools I’ve been building into an Elixir-focused coding agent. But it is not only about coding: the goal is to support background tasks, long-running agent workflows, and access through Telegram and other gateways.

Some highlights:

• Elixir eval is the primary tool interface. This makes it possible to unify many actions behind one composable interface, in a Unix-like way, without constant serialization churn.
• Sessions are stateful. Similar to Livebook, the agent can store and reference intermediate results naturally.
• It is built on OTP. Unlike most agent harnesses, Vibe can deeply introspect and supervise its own internal state.
• Agents can launch other agents. Subagents are supervised OTP processes with their own sessions, which enables more sophisticated long-running and parallel workflows.
• Agents can reach other machines. Vibe supports remote access over SSH and Erlang distribution, so agents can connect to remote nodes and communicate across machines.
• The agent can work on itself. It can inspect, patch, verify, and hot-reload parts of Vibe, while tools like Reach help keep boundaries clean.

Around that, there is a TUI, a LiveView web interface, persistent sessions, SQLite-backed storage, semantic events, plugins, skills, gateways, and local telemetry.

This is still an early research preview. Use it at your own risk, expect rough edges, and be careful.

Today we reduced headcount by 22%. The business is the strongest it's ever been. So I think it's important to be direct about what I'm seeing and why.

First, I made this decision and I own it. I did it because the way to operate at the highest level of productivity is changing, and to win the future, ClickUp needs to change with it. …

— Zeb Evans (@DJ_CURFEW), 21 May 2026

ClickUp just cut 22% of its staff while saying the business has never been stronger. Honestly, this feels like a moment of truth for the industry.

Software development, originally an engineering discipline, has recently been flooded with impostors lacking both skills and education. At its peak, companies started hiring people after just a few months of online courses. Many of them learned only how to imitate competence by repeating corporate jargon and trendy buzzwords.

I’ve personally interviewed dozens of so-called frontend developers who had no idea how computers actually work. I’ve also interviewed so-called DevOps engineers who couldn’t even explain the OSI model. And over time we were gradually gaslighted into believing that this is simply the “new division of labor”. Once the AI wave started, it became even worse — people began cheating on interviews like crazy.

Poor leadership turned programming into something closer to management consulting, filled with endless meetings and rituals.

Today feels like the beginning of a cleanup cycle.

Plain text isn’t enough. You can see hints of this in models like Nano Banana, where users discovered that well-structured JSON produces far more deterministic and higher-quality results.

Coding agents, which mostly express their intent through compact and concise Bash commands, are also a step in that direction.

My intuition is that Elixir, with its expressive syntax and first-class metaprogramming, is the next step.

The general knowledge they absorbed from sources like Common Crawl isn’t intelligence, not even a real approximation of it. We started seeing early signs of intelligence when we placed models in constrained environments like coding harnesses and made them act: change a file, run the tests, read the error, try again.

That loop is what I keep building for other domains. figma-use gives a design agent the cycle a coding agent already has: it edits the actual document, sees a visual diff of what changed, and runs a design linter before deciding what to do next. Reach turns an architecture into rules an agent can check, so a change that crosses a boundary fails instead of slipping through review.

A harness like this does two things. It makes today’s models more useful, and it produces data no crawl contains: what an agent tried in a specialized environment, what the environment answered, and what a human expert accepted. That kind of data can’t be collected from static sources, which is how harnesses help break through the limits model producers face.

So the scarce resource is high-quality feedback on actions. When I build tools for vibe-coding, I also think of them as a way to validate synthetic datasets for future models. If a harness can reliably tell a better action from a worse one, the better actions can be kept and learned from, and some of what we now get from the harness can become part of the model itself.

Every JS runtime is a GenServer with its own OS thread. No JSON anywhere — JS objects map to BEAM terms natively through a lock-free queue.

What makes it different from running Node/Deno/Bun alongside Elixir:

• JS runtimes live in supervision trees. They crash, restart, recover state — standard OTP
• fetch() goes through :httpc. WebSocket through :gun. crypto.subtle through :crypto. BroadcastChannel through :pg — works across a cluster
• The DOM is lexbor (C library). JS renders into it, Elixir reads it directly — no serialization, no re-parsing
• Workers are BEAM processes. They get preemptive scheduling for free
• TypeScript toolchain (OXC) and npm client built in — no Node.js on the machine at all

Full control over the JS layer: parse ASTs, bundle imports, transform TypeScript, minify — all from Elixir via OXC NIFs.

Use cases:

• SSR with Preact/React into native DOM, Elixir reads the tree
• Sandboxed user-defined business rules with memory limits, timeouts, and a controlled API surface
• Parallel Workers that compute and broadcast via distributed process groups
• Evaluating or bundling TypeScript without any external toolchain
• Running npm packages inside the BEAM

Still a research project in early beta. Covered with tests including Web Platform Tests ports, but expect rough edges.

<.article_link_card href="https://github.com/elixir-volt/quickbeam" title="elixir-volt/quickbeam" description="JavaScript runtime for the BEAM: Web APIs backed by OTP, native DOM, no Node.js." />

So I spent the weekend recreating Figma from scratch.

OpenPencil: reads and writes .fig files, AI chat with full design tools, P2P collaboration with zero servers, ~7 MB app. No account, no subscription.

Three days, one developer, MIT license.

<.article_link_card href="https://openpencil.dev" title="OpenPencil" description="A free, open-source design editor that reads and writes .fig files. Desktop and web." />