One of our engineers was looking at the Pizza Bot announcement and immediately noticed that the divider under 'Activity' doesn’t line up with the main panel. Now I can’t unsee it. I love working with engineers and designers who notice these things and care about how the whole interface comes together. We’re continually reviewing and refining our own interfaces, including Sail. There’s always something to improve. Pizza Bot is open source, so she will try to open a PR for this one over the weekend.

We gave Light's superconnector agent a @java REPL. Its job is to find useful connections between community members, including people with complementary skills, shared interests or a reason to collaborate across different fields. We use JShell so the agent can write Java snippets, retain variables between calls and compose operations over the candidates it finds. Java generates a deterministic search-coverage plan from a member's needs, skills, interests and values. The code defines the combinations to consider. The agent turns that plan into semantic queries grounded in the member's work and goals. We ask it to vary phrasing and specificity, search from the other person's perspective, and explore adjacent fields. The coverage plan is repeatable for the same inputs. The generated queries can vary. Across multiple top-k searches, the working set can accumulate hundreds of candidates. The REPL lets the agent compute over that pool without keeping every full profile in its conversational context. Java compares and scores the stored records, and we ask the agent to score the full pool before choosing finalists. Hooks check search counts for each matching hypothesis and flag final IDs missing from the working set for correction. This helps mitigate hallucinated candidate references. The agent still uses judgment for the mix of connections and close decisions. The scoring keeps two directions explicit: how someone's capabilities meet your needs, and how yours meet theirs. Those components are returned with the ranking, so we can inspect whether a proposed connection has value in one direction or both. A high similarity score alone doesn't tell us that.

When we upgrade Sail, the multi-agent harness, the shell running inside a project's Incus container should still be there afterward. That gets interesting when the service being replaced owns the terminal connection. Our solution was to build a small PTY session host for Sail. A PTY is the operating-system interface that lets a program behave as though it has an interactive terminal. Closing its master descriptor can hang up the session, so keeping some terminal text on disk would only solve part of the problem. On hosts configured for this handoff, Sail passes the master descriptors to systemd's file descriptor store. Systemd keeps them open while the old service exits. The replacement service adopts them and reconnects the session to its saved metadata and bounded output history. The shell inside the container keeps running. Our @java implementation uses Panama/FFM to call sendmsg and pass descriptors with SCM_RIGHTS. We also have a small protocol for attaching clients and carrying terminal input and output. Process survival depends on the descriptor handoff and service lifecycle. There is no tmux in this path. It's been fun addressing these challenges as we continue to use Sail as the daily driver for our engineers.

We're getting close to v1 of Sail, the open source software factory we've been building and using at @standardapplied. Sail coordinates work across coding agents and engineers, with an isolated Incus environment for each project. A few interesting parts: • Multiple agent harnesses: Sail supports coding agents like Claude Code and Codex, including having one review the other’s work. Specs get dispatched and move through a loop with review and validation stages. • Slack-like rooms around the work: Agents can post progress and flag questions that need a person. Other engineers can follow the conversation and chime in. Human replies reach a running agent between tool calls, so the discussion can inform the work already underway. • A distributed control plane: Each engineer's node synchronizes with the main node. Specs, room conversations, runs and reviews travel between them, while a spec executes on its assignee's node. Shared work stays visible across the team, with explicit conflicts when edits need reconciliation. • Terminals that survive Sail upgrades: We built a small PTY protocol and session host. On hosts configured for descriptor handoff, systemd holds the PTY master descriptors while the service restarts. The new service adopts them, preserving the shell inside the Incus container and its retained output history. No tmux involved. • Terminal UI: We used Ghostty's libghostty-vt compiled to WebAssembly for terminal parsing and state, with our own rendering layer. It connects to Sail's host-owned sessions over SSH. Sail is written in @java 25 and compiled as a @graalvm native image. Panama/FFM lets us call the native PTY and descriptor-passing APIs directly from Java. Over the coming weeks, we’ll share how we keep terminal sessions alive through upgrades, what we learned using FFM, and how we built the desktop/mobile apps with Rust and @TauriApps.

A few months ago, we built an AI-assisted onboarding flow for our partner, Light. People can create their profiles through Mad Libs style prompts or write in free form. Gemini Flash generates suggestions for the blanks in the guided flow. For freeform answers, it extracts short phrases into profile fields covering attributes like skills and what someone is looking for. The source of an answer matters. Someone writing “I'm looking for a fundraising mentor” is telling us what they need. Putting fundraising under their skills would misrepresent them. Ofc, we pass the source field along with the text so the model has that context. The onboarding calls already request a low thinking level and return typed outputs. When several free-form fields need extraction, their calls run concurrently. Fields left blank skip extraction entirely. The next piece we'd like to evaluate is a classifier that checks whether each extracted attribute is supported by what the person wrote. It would return a defined answer: supported, contradicted or insufficient evidence. @typesafeai's Jev supports this kind of classification through typed questions and predefined choices. I'd like to test whether OSS models like @googlegemma can handle that role for our onboarding flow, using constrained outputs. We'd compare the current extraction on its own with versions that add a Gemma check. The evals would use human-reviewed examples, including ambiguous answers and people describing both what they offer and what they need. We'd measure unsupported attributes that slip through and valid ones that get rejected, alongside the added latency and cost per completed profile. The stack is our beloved @java, @graalvm and Helios (which provides the agentic building blocks, tracing and prompt management we use to build evaluation workflows).

After a long hike, I was getting ready for a movie night with friends. We were too tired to keep debating what to watch, so I decided to try @typesafeai's Jev with computer use to browse and navigate @netflix. Apparently I still had enough energy for an experiment. Our tastes were spread across action/thrillers, sci-fi set in space, and romance. I gave Jev descriptions from a small Netflix shortlist and asked it to assess each person's preferences. We allowed a two-out-of-three compromise, with the unmatched preference kept explicit. It picked I.S.S. for the action and space fans. Then I checked the ratings: 5.3 on IMDb and 43% from Rotten Tomatoes audiences. I'd spent all that effort matching genres and left audience ratings out of the criteria. For the rerun, I added minimums of 6.5 on IMDb and 60% from RT audiences, keeping critics' scores separate. I expanded the shortlist and supplied fuller plot descriptions. Jev assessed the genre and plot evidence; the application checked the rating cutoffs and counted how many people matched. The latest run picked The Adam Project (2022): IMDb 6.7, Tomatometer 68% (critics), and Popcornmeter 73% (audience). Jev counted the action and romantic storyline toward our two-of-three rule. It is a time-travel adventure with a secondary love story, so the space fan would be compromising. There's more to evaluate. We just worked through a small shortlist. I'd like streaming services to offer a "movie night picker." A profile captures one person's habits. When three to five people share a screen, the recommendation should account for who's watching together and what each person is willing to compromise on.

Mast's terminal runs on libghostty-vt, Ghostty's terminal core, which they ship as a standalone WASM build. We wrote the bindings and our own WebGPU renderer on top. libghostty is a thing of beauty. The terminals themselves live server-side as durable pty sessions inside each project's (Incus) container. Reattach from your desk or your phone, land in the same shell. Sessions belong to rooms, so the terminal where you brainstormed with Claude sits next to the conversation and the specs it produced. We built this for one job: senior engineers running a software factory, dispatching coding agents and dropping into a real shell beside them when it matters.

Everyone's out here talking Rust, Zig, Bun... Meanwhile half the Fortune 500 quietly runs on @java. And JDK 26 is genuinely fantastic and boringly reliable. Make Java Great Again. Ship the JAR, wear the hat 🧢

Bun with Electronbun is fun to use for building desktop apps. The RPC feature needs some work, but overall the DX has been amazing! Our software factory app is taking shape.

A new HIPAA rule means every vendor contract a hospital signed under the old one might be out of date. Could be thousands of them. We built a tool that reads all of them and writes the fixes. Here is 40 seconds. @googlegemma @Cerebras

A few days ago I wrote about how much of backend work is just adapters moving data across boundaries. Every station allocates, and every station throws away type information the next one has to rebuild. I said I wanted to strip that down and use it as an excuse to learn @java FFM. I kept going, and it turned into a small library. I called it Monolith. The premise is that one Java record can be the source of truth. You write a record, sometimes carrying its SQL, and an annotation processor generates the Postgres schema, a binary reader, a builder, a matching TypeScript reader, and for queries, a rule that knows when the result has gone stale. All at compile time, no reflection. The path ends up looking like: record + SQL → libpq binary → Postgres → binary tuple → typed reader No ResultSet, no POJO mapping, no Jackson, no ORM session in between. It stays on real relational tables, so you keep SQL, joins, and transactions. I did not reach SQLite's single-process model. Postgres is still a server over a socket. But the in-process stations are mostly gone, and the project grew one thing the first post never mentioned: live queries. You subscribe to a query and a parameter, and when a row that affects it changes, the query re-runs and you get the new result. It watches the write-ahead log to know what changed. Nothing fancy like an incremental view engine, just Postgres and generated SQL. It is v0.1 and experimental. The API will change, and the README is honest about the rough edges. But it runs, the reactive part works end to end, and it was a good excuse to actually use FFM instead of just reading about it.

Some of modern backend engineering is just writing adapters to cross process boundaries. For example, in @java we have: HTTP socket → Spring routing → controller → service → repository → JDBC → wire → Postgres → tuple parse → wire → JDBC → ResultSet → POJO mapping → Hibernate session → service logic → POJO → Jackson → JSON bytes → HTTP socket Each station allocates memory. Each exists just to hand data to the next layer. Each loses type info that the next station has to rediscover. Yes, it is an oversimplification, and it works just fine for large enterprise systems. But for smaller projects, it is a lot of unnecessary plumbing just to route a request, run a query, and return bytes. SQLite had this right all along for local apps. This weekend, I am exploring what happens when we bring that single-process architecture back to modern APIs. I want to drop the network boundaries entirely and strip the pipeline down to its absolute minimum. A good excuse to explore Java FFM.

Works pretty well! We've been using BDD/spec-driven development for our client projects. Brainstorm the spec during the day with the agent, "sing dispatch" at night/day, review the PR in the morning, or have another agent review the PR. sing snapshots the container, and launches the agent. Agent picks the next ready spec, creates a branch, and gets going. The spec board tracks what's done, what's in progress, and what depends on what. The agent is working through the queue. And we extended Zed to monitor through the IDE.

A mid-size hospital runs Epic for EHR, Medidata for clinical trials, Workday for HR, NetSuite for finance, Salesforce for donor relations, Jira for IT tickets, and fifteen more. Each system has its own data model, its own auth, its own API. A patient exists in seven databases and none of them agree on spelling. Compliance teams at banks run Drata for SOC2, Vanta for vendor risk, ServiceNow for IT governance, Splunk for log monitoring, and a spreadsheet someone made in 2019 that nobody wants to touch but everyone depends on. An engineer opens an S3 bucket to the public. It takes three days and four tools for anyone to notice. Every Startup or enterprise is running 100+ SaaS applications held together with API wrappers, Zaps, and manual processes. The data is fragmented. The logic is duplicated. The security surface grows with every vendor contract. Adding AI to this mess just creates smarter fragments. This is SaaS Sprawl. It is the default state of every company we have worked with. There's a better way. Agentic Periphery, Deterministic Core. More soon.