Notes & introduction

I'm Jakub Chaba. This site has been around for a while as a portfolio of side projects. I'm starting to write here too, because the side-project page doesn't represent the work that's defined the last year of my career, and writing is the one way I can talk about that work without getting into specifics I shouldn't get into. So: a short introduction to who I am, what I do, what I'm building on my own time, and what I think about while building any of it.

What I do for work

I'm a Senior Software Engineer at ServiceTrade. I architect and build the internal platform our AI features are built on — I've designed, implemented, and shipped it. It's the substrate where agents, tools, and the services they depend on (API clients, database access, and so on) are defined and run, together with the supporting infrastructure that production agents need: execution observability, behavioral guardrails, human-in-the-loop checkpoints, and authentication against our core product. The point of it is to make it possible to build new AI features rapidly without re-solving the same problems each time. Production agents have shipped on it.

What I'm working on personally

I run a personal AI infrastructure stack I call chababrain. It's a small distributed inference setup — currently mid-migration off a Raspberry Pi k3s cluster onto a home server that also acts as a NAS — with an inference gateway that routes requests through a NATS queue to registered compute nodes (my M4 Max laptop, my wife's M1 Pro). It exists so I can prototype agentic ideas without cloud costs or cloud availability between me and the experiment.

A few primitives sit on top of the inference layer: a research agent for grounding work in current sources, a voice design agent for generating custom TTS voices, and storage for reusable voice profiles. The first non-trivial system that composes these is an audiobook-generation pipeline — a multi-agent workflow that goes from topic → research → outline → draft → critique → revise → finalize, chunks the result into TTS-friendly segments, generates audio in a designed voice, and uses voice cloning to keep narration consistent across chunks. Output lands in a local MinIO bucket. The kind of project that wouldn't justify cloud spend but is genuinely fun to build locally.

I also contribute to oMLX. My first accepted OSS contribution enhanced oMLX's voice design support — exposing tunable generation parameters (temperature, top-k, top-p, repetition penalty), adding a test fixture for fake models, and a small refactor to use the model's own sample rate. I'm currently working on image generation via mflux before proposing it upstream.

What I think about, technically

A few things I've come to believe strongly enough to put in writing:

Observability is the substrate that makes evals cheap. Evals without observability are a from-scratch engineering project — you have to invent the dataset yourself. With a dedicated observability layer ingesting agent traces (Langfuse or equivalent), the dataset emerges as a byproduct of running the system: real user interactions become labeled examples of how the system should and shouldn't behave, and the eval suite grows in step with the product instead of lagging behind it. An agentic feature without this loop in place is a demo, not a feature. Vibes do not survive contact with production.

LangChain and LangGraph are not bloated. They are opinionated, and the opinions are correct. There's a persistent strain of online opinion that treats these frameworks as cargo cult. I don't see it. A modern LangGraph application is essentially a StateGraph of functions connected by edges, which is precisely the right abstraction for what an agent actually is. Teams that hand-roll Bedrock or OpenAI client calls inevitably reinvent retries, tool dispatch, and state management — badly, and without the benefit of an ecosystem that's stress-tested those patterns at scale.

Opinionated abstractions at the boundary; just-in-time abstraction in the middle. The previous opinion is not a license to abstract everything. Inside your own codebase, premature abstraction is one of the most reliable ways for a project to die. Some duplication is fine — necessary, even — until the shape of the problem becomes clear. The rule of thumb I've settled on is roughly the rule of three: by the time three places in the code are doing something similar, the abstraction is starting to earn itself. Doing it on two is almost always wrong, because the abstraction you build to fit two cases is the wrong shape for the third, and now you have to refactor an abstraction you committed to too early — which has a far larger blast radius than the duplication ever would have.

AI-accelerated development is a multiplier on engineering discipline, not a substitute for it. I use agentic IDEs heavily, and I have several specific learnings from doing so — enough that this is its own post, coming soon. The short version: the tooling makes producing code that looks fine and is quietly wrong trivially easy, and the mitigations have to be mechanical (test coverage requirements, linters, CI gates) rather than relying on human reviewers being more careful. The longer version, with the specific learnings, deserves its own treatment.

What's next here

I'm going to write more. Some of it will be technical writeups of architectural decisions I've made; some will be opinions of the kind you saw above, expanded with more reasoning; some will be notes on what I'm building at home and what I've learned the hard way. If any of it is useful to you, that's the point.

— Jakub