Back in March 2025, I added llms.txt and llms-full.txt support to this blog.
The goal was to give Large Language Models a structured index of all my articles, plus a single consolidated file (llms-full.txt) that I could drop into Gemini’s large context window to ask questions across everything I had ever written.
Since then, the way developers and AI tools interact with web content has evolved quite a bit.
Instead of manually uploading a 700k-token file into a chat prompt, we now rely on autonomous coding agents (like Antigravity, Claude Code, GitHub Copilot, Cursor, or OpenCode) that browse the web and fetch individual documentation pages or blog posts on the fly.
Today, I took another step to make this blog friendlier to those agents: every article now has a clean Markdown twin (.md), linked from the HTML header and from llms.txt.
With Devoxx Belgium 2026 just around the corner (October 5–9 at Kinepolis Antwerp), I started looking through the schedule to decide which sessions to attend.
With more than 200 talks spread across 5 days, multiple session formats (Deep Dives, Hands-on Labs, Conference sessions, Tools-in-Action, and BOFs), and up to 8 parallel tracks running at any given time, putting together a cohesive, conflict-free agenda by hand takes quite a bit of clicking back and forth.
Most of our conversations around Large Language Models focus on generative chat: you give the model a prompt, and it outputs a sequence of tokens autoregressively.
Recently, Typesafe AI introduced a different paradigm called System 1 models, embodied by Jev. Rather than generating free-form prose token by token, a Jev-style model acts as a high-speed, deterministic decision maker. Given an input state and a series of discrete questions, it runs in a single forward pass and outputs calibrated probability distributions for each question:
In this post, I will explain what these models offer, what was added to the SDK, and show you a complete, practical example of how to design a custom voice and synthesize speech with it.
A few months ago, I introduced the unofficial Antigravity SDK for Java.
My goal was simple: enable enterprise Java developers to build and run autonomous AI agents in Java, backed by the same engine that powers Google Antigravity.
The ability to run models locally on-device without cloud API dependencies, and without paying token costs for high-frequency tasks, sounded very appealing, right? 😃
I rely on Obsidian daily to capture ideas, interesting links & articles, and research clippings.
Because I alternate between different machines (my work computer and my personal laptop) I need my vault synchronized everywhere.
Instead of third-party cloud folders or paying for cloud sync tiers, I back my vault with a private Git repository (hosted on GitHub) and use the community obsidian-git plugin.
Git gives you full ownership, complete version history, granular diffs, and zero vendor lock-in. But if you simply git init your vault and call it a day, you will quickly run into some issues:
Since that release, I have continued using the visualizer to inspect complex agent runs, debug failed tool invocations, and review multi-agent orchestrations.
Over the last few days, I rolled out a series of incremental updates culminating in the v0.6.0 release,
with pre-built binaries available on the GitHub release page.
When Google initially introduced the Interactions API, there was no Java support in the official SDK. Because I wanted Java developers to be able to build with interactions, managed agents, and remote sandboxes right away, I created an unofficial, purpose-built library: the Gemini Interactions API Java SDK.
Now that official support is available under com.google.genai, developers have two ways to interact with this API from Java. In this post, I want to take a technical look at how both SDKs approach the same API, compare their ergonomics, and discuss when you might choose one over the other.
Before heading for well-deserved vacations, I wanted to share something I’ve been cooking on and off for the past few weeks:
an unofficial Java SDK for Antigravity.
If you’re familiar with Antigravity, you’ll know it’s available across different surfaces:
Antigravity 2.0: an agent manager for the Antigravity harness, where you can work across multiple projects and sessions from a rich UI,
Antigravity CLI: a CLI coding agent, where you can interleave running terminal commands, with active agent coding actions,
Antigravity IDE: a VSCode fork, with an integrated Antigravity chat assistant, when you want to be deep into the code,
Antigravity SDK: which is actually a toolkit you can integrate and manage yourself, to create your own Antigravity harness.
