Software engineer · systems builder · AI tooling enthusiast

I build software systems, developer tools and infrastructure — with a growing focus on AI agents, local-first architectures and autonomous software development.

I've been working with computers, Linux and software systems since the '90s. Over the years I've moved across frontend, backend, databases, infrastructure and operations, which means I tend to look at software as a whole system rather than a collection of isolated components.

Today I'm especially interested in one question:

How do we turn LLMs from chat interfaces into reliable engineering systems?

A lot of my current work revolves around:

• autonomous and semi-autonomous software agents;
• structured long-term project memory;
• permission-aware tool execution;
• local-first architectures;
• agent coordination and orchestration;
• auditable execution;
• reusable knowledge across projects;
• LLM gateways and provider abstraction;
• cost and token accounting;
• human-in-the-loop development workflows.

I like systems where AI can act, but where actions remain inspectable, deterministic where possible, and constrained by explicit permissions.

AI Office is an experiment in building a local virtual software organization.

Instead of treating an AI agent as a stateless chat session, the project models software development as a persistent system with:

• projects;
• tasks and milestones;
• requirements;
• ADRs;
• agents and roles;
• execution runs;
• permissions and capabilities;
• audit events;
• budgets and costs;
• reusable memory.

The architecture is centered around a local daemon and SQLite-backed state.

CLI
↓
local daemon
↓
application services
↓
agents / orchestration / governance
↓
SQLite

Current stack:

Bun · TypeScript · SQLite · Zod · Vitest

The long-term idea is simple:

Give AI agents enough structure to work like an engineering team without giving up observability, control or ownership of the system.

TypeScript · JavaScript · SQL · Bun · Node.js

PostgreSQL · SQLite · Supabase · REST · GraphQL

React · Vite · Tailwind CSS

Linux · Docker · Nginx · Cloudflare · GitHub Actions

LLM APIs · agent orchestration · RAG · structured memory · tool execution · model routing · cost tracking

I tend to prefer software that is:

Simple enough to understand Complexity should earn its place.

Explicit rather than magical Especially around permissions, state and side effects.

Strongly typed Types are part of the architecture.

Database-backed when state matters Markdown and files are great interfaces, but poor substitutes for structured state once systems become complex.

Auditable If an agent changes something, the system should know what happened, why and under which authority.

Local-first when possible Your projects, memory and operational state should not necessarily depend on someone else's SaaS.

And, as usual:

DRY · KISS · YAGNI

I've worked across the entire software stack: frontend applications, backend services, databases, integrations, infrastructure and production systems.

Linux user since 1995.

Still curious.

Still breaking things to understand how they work.

Still building.

_{If something I've built helped you, you can buy me a coffee.}