Inside Out

Who are we building for?

Wed, 25 Feb 2026 05:52:21 GMT

The news of agentic productivity is all over the place. There’s an explosion of side projects (1↗, 2↗), may be large enough to say creating something new has lost its unique value. There’s the other rumour that the perennial build-vs-buy software debate is now tilting in favor of build.

AI Agents have shortened the idea-to-product pipeline. Everyone and their dog↗ is on Claude Code, churning code, writing blogs and automating things on OpenClaw or its incarnations. This is a fact.

I’ve one humble addition. AI Agents have shortened the idea-to-consumer pipeline. They have automated the consumer of the apps!

There are probably a zillion apps which solve a problem. How do you choose? What differentiates?

Two things.

One, may be we will never choose the apps. Your AI agent is going to build one for itself. In this future, apps are the throwaway artefacts just like the python or shell scripts a few years ago.

Second, you will see only those apps which your agent decides to show you. It’s like you’re paying 5$ for a pair of smart glasses and you only see what is shown to you. Your agents are those glasses, blending into your daily life and create a bubble for you to live within. Who’s in control? That company you’ve hired for five bucks.

To my lizard brain there seems to be only one way out. We must understand these models better, so much so that we can rationally cut through the layers of filters. Call them sycophancy (a fancy word for a yes-man LLM that agrees with everything you say) or a narrative that’s controlled by a few corporations to force their discourse upon you.

If you’re the one building apps, tools, websites etc please ask for open standards or protocols like the three-four letter acronyms HTTP, TCP, or the recent ones like ActivityPub. Don’t stop there, build on top of these. Think how they must evolve for Agents. Use the open-weights models available to you. Learn how the inferencing works, and what can you do to control it.

Also, while we’re at it, let’s build for agents. They are the first class consumers now! We don’t understand what it means though. Do our accessibility, privacy, and performance standards apply to them? Or is our notion of time and space too slow for these bots? Some thoughts to ponder.

Now the Apps are of the agents, by the agents, for the agents! Let’s see beyond the “by the agents” narrative.

Editing Sanskrit text

Thu, 25 Dec 2025 08:49:24 GMT

Our studies require editing Sanskrit text in Devanāgarī (देवनागरी) and the IAST↗ scripts. Below is a cheatsheet to help with this.

Concepts

Conceptually there are two mechanisms to input text.

Use a keyboard layout. All of us are familiar with this. Default keyboard layout (US international or similar) corresponds to the keys in the physical keyboard. You could use a keyboard layout and map the physical keys into the Devanāgarī characters.
Or, you could use a Transliteration scheme where you type ASCII characters in your existing keyboard layout and a special software called Input Methods↗ framework transliterates that into Devanāgarī. E.g., with Harvard-Kyoto↗ transliteration scheme you type kha and you get ख.

We highly recommend the excellent Fcitx5↗ input method for Linux. It supports both keyboard layouts and rule based transliteration schemes. This tool effectively enables us to type IAST↗ and Devanāgarī in any text box. The m17n↗ project provides a database for Multilingualization (m17n) or transliteration schemes. You can point Fcitx5↗ to these with fcitx-m17n↗.

Configuring Fcitx5

As usual, the Archlinux wiki↗ provides a fantastic guide for setup. Also see https://fcitx-im.org/wiki/Setup_Fcitx_5↗. Use fcitx5-configtool↗ for a GUI based setup, screenshot below.

Typing in IAST can be done using a transliteration scheme or a keyboard layout. We recommend latter for fast typing response. Use the Keyboard - English (US) - English (intl., with AltGr dead keys) keyboard layout. This smart layout allows you to input ASCII text as usual, and leverages the dead keys↗ withRight Altmodifier to input special text likeāforआ.

Typing in Devanāgarī is achieved through the Harvard-Kyoto↗ transliteration scheme. You can pick any scheme supported by m17n↗.

Sanskrit editing configurations in fcitx5-configtool↗ app.

Key Shortcuts

US Intl with AltGr Dead Keys

Modified from https://dry.sailingissues.com/us-international-keyboard-layout.html↗ for AltGr Dead Keys keyboard layout.

Diacritic	Keyboard shortcut
ā	AltGr+Shift+3 + a
ś	AltGr+’ + s
ȧ	AltGr+. + a
ạ	AltGr+Shift+- + a
ã	AltGr+Shift+` + a

Below diacritics are not used in IAST, provided for completion.

Diacritic	Keyboard shortcut
à	AltGr+` + a
ä	AltGr+Shift+” + a
â	AltGr+6 + a
ă	AltGr+Shift+9 + a
ǎ	AltGr+Shift+. + a
ő	AltGr+Shift+2 + o
ą	AltGr+8 + a
å	AltGr+Shift+0 + a

Vowels (śvara) and Codas

Modified from Wikipedia pages of IAST↗ and Harvard-Kyoto↗. We’re using direct Unicode keyboard shortcut Ctrl+Shift+u on Linux for certain characters.

Devanāgarī	IAST	Harvard Kyoto	Key Shortcut
अ	a	a
आ	ā	A
इ	i	i
ई	ī	I	AltGr+Shift+3 + i
उ	u	u
ऊ	ū	U	AltGr+Shift+3 + u
ऋ	ṛ	R	AltGr+Shift+- + r
ॠ	ṝ	RR	Ctrl+Shift+u 1e5d
ऌ	ḷ	lR	AltGr+Shift+- + l
ॡ	ḹ	lRR	Ctrl+Shift+u 1e39
ए	e	e
ऐ	ai	ai
ओ	o	o
औ	au	au
`ं	ṁ	M	AltGr+. + m
ः	ḥ	H	AltGr+Shift+- + h
`ँ	m̐		Ctrl+Shift+u 0901
ऽ	’	.a	Ctrl+Shift+u 093d
।		\|	Ctrl+Shift+u 0964
॥		!	Ctrl+Shift+u 0965
ॐ		OM	Ctrl+Shift+u 0950

Consonants (vyañjana)

Map of Devanāgarī consonants with equivalent IAST↗ or Harvard-Kyoto↗. Note only the differing Harvard-Kyoto↗ keys are mentioned after the comma. This table is taken from the Wikipedia and enhanced with above.

velars	palatals	retroflexes	dentals	labials	Category
क k	च c	ट ṭ, T	त t	प p	tenuis stops
ख kh	छ ch	ठ ṭh, Th	थ th	फ ph	aspirated stops
ग g	ज j	ड ḍ, D	द d	ब b	voiced stops
घ gh	झ jh	ढ ḍh, Dh	ध dh	भ bh	breathy-voiced stops
ङ ṅ, G	ञ ñ, J	ण ṇ, N	न n	म m	nasal stops
ह h	य y	र r	ल l	व v	approximants
	श ś, z	ष ṣ, S	स s		sibilants
		ळ ḻ, L			approximants (Vedic)

Hope you enjoy this new Sanskrit editor setup 🕉️

On code agents

Wed, 08 Oct 2025 22:50:11 GMT

Coding agents are now a part of my daily workflow both at home and work. I’m beginning to see a trade-off between building a lot of features, shipping them faster, and the quality or craftsmanship. Let’s consider two scenarios.

At home, I recently purchased a developer subscription for an open-weights LLM. They provide Claude and OpenAI compatible API endpoints and nicely integrate with Claude Code etc. I was already running aider↗ with Openrouter and Gemini free plans, so the migration was straightforward. I primarily used this for Rust, C# and some Typescript hobby projects.

The work projects were much more challenging. We’re trying to migrate ~50 FluentUI↗ v8 controls to v9. They’re part of a UX platform used in multiple downstream monorepos. Given the wider use this code requires a higher quality standard.

Here’s what I learned.

Pick joy over quantity

I cancelled the developer subscription for home. Obvious advantages of shipping more features quickly were weighed down by the dryness of fixing AI slop.

The open-weights LLM plan actually punched well-above the price point and it was a joy to use Claude Code, one of the good CLI apps I’ve recently used. I’d happily consider them again.

In my scenario, I do these open-source hobby projects for fun and learning. By design they are privacy focused, I don’t track DAU, MAU, or manage OKRs.

Few things went wrong with the subscription.

Focus to maximize quantity: I noticed myself picking up the agent at every possible chance to churn some feature or other. If I pay for it, I’d rather use it all day. Heck I even tried to parallelize my study time with an agent running in background building something or other. Not healthy.
Too noisy: With more quantity of code produced, the quality took a toll. Even with all possible instruction tuning including focused planning and iterations, the agent will lose context and violate basic principles. End result most of my time went to review and ask the Agent fix the slop introduced. This is something I’d have avoided with active coding.
Zero learning: AI is a more knowledgeable dev than I am especially so in the areas new to me. With passive coding, the features got built, build, and test passed without any design as such. Yes, I do the planning/architect phase before I ask LLM to code. Still the nuances matter, getting involved matters.

The lesson: just like slow travel, I will embrace slow code. Nobody cares if I ship 30 features on a side project, I’d rather do it on my terms.

Decades ago I was introduced to Resharper↗ at work. Back then it was a linter on steroids with excellent suggestions including refactorings. I genuinely learned tons of best practices in C# and .NET from the linter warnings and errors than from the LLMs today.

Maybe today’s AI agent is more capable, runs without me, but I’d prefer its dumb counterpart where learning and joy matters.

Where quantity and speed matters

All that said slow crafts-focused coding is no longer a viable option at work.

There are OKRs everywhere to build and ship in days. Heck we measure the usage of AI and you may get a gentle note to embrace it more. I must admit that I’m in such a role pushing for AI dev productivity in my organization. Sorry for that, it’s either you embrace AI, fit in or you’re out.

When we started on the FluentUI↗ v8 to v9 migration, the prototype informed something like 80-90% code generated by AI is good along with awesome test coverage. We claimed to be done with entire migration using 3x less effort.

All of this was exciting until we tried a complex prototype! Suddenly the v9 code generated by AI appeared to be v8 like, missing the new features slots architecture↗, or style design tokens↗. Like an AI first developer, we added few MCPs including one that provided access to FluentUI v9 docs, threw in detailed prompts with meticulous examples of code snippets, and AI was able to generate decent code.

But with poor design choices. At this point we reset the expectation.

AI can do the migration of a simple control with poor design in a day or two. It will take 2x that time for the Human to align it with our design principles and improve the quality.

It is not delegate-and-forget.

Human must understand FluentUI v9 architecture and the design decisions to be able to guide the AI. This requires a learning curve and is a pre-requisite for AI driven migration.

This codified into the following heuristic.

Generate design docs for the UX component along with a v8-v9 migration note. Use AI if you will but the Human Developer must attest to the design choices and quality.
Develop a custom Github Copilot chat mode for migration with access to specific tools only.
Use the design doc and use AI to develop step-by-step. At each step ensure code is shippable similar to the red-green-refactor cycle. Keep building a mental model in your head as AI generates code.
Bar for PR reviews remain same as earlier: unit tests, storybooks, a11y testing and code that you’re proud of.
AI PR reviews is okay. But human PR review is required. Response to human reviewer comments must be by human PR author. We learned that AI response to human PR comments was too verbose and missed the point leading to unnecessary cycles.

The good part of this heuristic is our human developers are no longer flying blind. They are in control, their architectural skills grow because we have human design discussions on each PR, and code continues to ship fast enough.

Here’s my key takeaway.

I’m going to optimize for the craft of building software where I get a chance. This includes slow and mindful coding.

In an industry setting where the incentives are on faster delivery and quantity of features, I will not fly blind. I will focus on setting a process that works for the project, optimize to empower the human in loop, and improving the craft as much as I can.

I’d love to learn from your experience. Please do drop an email if you’d like to chat more on this!

Migrating from docker to podman

Sun, 14 Sep 2025 06:13:13 GMT

It was a week long journey to migrate my lab from Ubuntu 20.04 (end of life in May 2025) to Ubuntu 24.04 and run everything in Podman. Ubuntu upgrade was forced because Podman requires kernel 5.x.

This note is a summary of pain points and how I’d approach this today :)

Mental model

We run 12 selfhosted services on an Odroid M1 4GB model. There are three variations:

Two services require Host networking i.e., open up ports on the host. Adguard’s port 53 for DNS, and Traefik on port 80/443 for reverse proxy.
Two services used Docker volumes - Postgres and Nextcloud.
Other services are mostly self sufficient either running on sqlite or a host mounted volume for data.

Networking

These are the network flows.

DNS requests: machines in LAN -> 192.168.1.111:53 (selfhost box) -> Podman (pasta) network -> Adguard home (container). Uses pasta network.
HTTP requests: machines in LAN -> news.domain.com -> 192.168.1.111:443 (selfhost box) -> Traefik on 80/443 -> 10.89.0.3 (miniflux)
Internal requests: 10.89.0.3 (miniflux) -> postgres:5432 -> 10.89.0.2 (postgres). Uses a custom network.

Note that both (1) and (3) networks will listen on port 53 for DNS resolution. We’re using (1) for LAN wide DNS resolution. (3)‘s DNS uses Podman’s netavark for container-to-container communication using container names. We cannot have both DNS servers (netavark) and Adguard on the same network.

TL;DR - Docker to Podman

Let’s do a summary for the entire process.

You’ll need Linux Kernel 5.x. If you’re running Ubuntu, I’d recommend 24.04.
Install Podman. # apt install podman or equivalent.
Configure Podman
- Open port 53 onwards for rootless containers. How to: link↗. Run # sysctl --system after the config change.
- Add your registries to Podman. How to: link↗.
Enable podman.socket, auto update and $USER lingering to allow auto start of containers.
```
systemctl --user enable podman.socket
systemctl --user enable podman-auto-update
loginctl enable-linger $USER
```

Test if podman is working

podman run -dt -p 8080:80/tcp docker.io/library/httpd
podman ps # verify the container is running
curl http://localhost:8080

Optional: At this step, you can try automated migration with https://github.com/Edu4rdSHL/fly-to-podman↗.
Migrate volumes: use rsync or similar to copy /var/lib/docker/volumes/<volume_name>/_data to ~/.local/share/containers/storage/volumes/<volume_name>/_data.
Setup networking: read the excellent podman networking docs↗ to learn all options. Here’s I did:
- Create an internal network for all containers except Adguard.
- Use pasta network for Adguard to expose port 53. Details in the note below.

Permissions for host mounted volumes require additional gymnastics.

# identify the USER:GROUP running the worker process in container
podman exec -it <container> sh
top # note the process user:group, run inside container

# or, check the permissions in directories _without_ mount
podman exec -it <container> sh -c 'ls -la /var/www/html'

# Now, we need to chown/chmod for the same user in host mounted directories
podman unshare chown -R 82:82 <host shared dir> # run on the host

Podman creates subuids for your user, e.g. above command will give 100082:100082 ownership to the directory, assuming 1000 is your uid.

Create the quadlets. https://github.com/containers/podlet↗ can help create the skeletal *.container files. I did three additional changes:
- Add AutoUpdate=true for the container images to be auto pulled from registry.
- Configure Traefik Label=traefik.enable=true and other labels.
- Add an environment file EnvironmentFile=%h/path/to/.env to load secrets inside the container.
Example quadlet is shared below.
You’re going to spend a good amount of time in starting/stopping systemd units.
- Get yourself familiar with https://github.com/rgwood/systemctl-tui↗
- Name your quadlets with a prefix (I used selfhost-<service name>.container) to help filter easily.
```
systemctl --user daemon-reload # load changes from container files
systemctl --user start <container>.service
journalctl --user -xeu <container> # see logs if something goes wrong
```
Or, use the systemctl-tui for all these commands.

Artifacts

Now, let’s look at the quadlets and related configurations that worked for me. I’ve annotated these with pointers wherever relevant.

Example: network quadlet

[Unit]
Description=selfhost network
After=network-online.target

# DNS ensures we hit the Adguard service with all queries from containers.
# Adguard is listening on 192.168.1.111:53
[Network]
NetworkName=selfhost
Subnet=10.89.0.0/24
Gateway=10.89.0.1
DNS=192.168.1.111
IPv6=false

[Install]
WantedBy=default.target

Example: container with custom network and traefik

[Unit]
Requires=selfhost-postgres.service
After=selfhost-postgres.service

[Container]
ContainerName=miniflux
Image=docker.io/miniflux/miniflux:latest
AutoUpdate=registry

Network=selfhost.network
HostName=miniflux
PublishPort=127.0.0.1:8080:8080
DNS=1.1.1.1
DNS=1.0.0.1

# %h = location to your $HOME in host. Store the credentials in this file.
# All env variables will be available inside the container.
EnvironmentFile=%h/containers/miniflux/miniflux.env

Environment=BASE_URL=https://domain.host.com/
Environment=RUN_MIGRATIONS=1
Environment=CLEANUP_ARCHIVE_UNREAD_DAYS=-1
Environment=CLEANUP_ARCHIVE_READ_DAYS=-1

# Remember to update the docker.network name to your custom network
Label=traefik.enable=true
Label=traefik.docker.network=selfhost
Label=traefik.http.routers.miniflux.rule=Host(`domain.host.com`)
Label=traefik.http.routers.miniflux.entrypoints=websecure
Label=traefik.http.routers.miniflux.tls.certresolver=letsencrypt

[Service]
Restart=always
TimeoutStartSec=300

[Install]
WantedBy=default.target

Example: Adguard quadlet using pasta network

[Unit]
Description=Adguard server

[Container]
ContainerName=adguardhome
Image=docker.io/adguard/adguardhome
AutoUpdate=registry

# Note the `pasta` network is critical. This ensures the container listens on
# port 53 on the host. Since it is outside the selfhost.network, we have added
# this to traefik-dynamic.yml. Other services are auto discovered from the
# docker socket.
# Port 53 can be opened by setting /etc/sysctl.conf
# net.ipv4.ip_unprivileged_port_start=53
# Run `sysctl --system` after the setting update.
Network=pasta
HostName=adguardhome
PublishPort=53:53/tcp
PublishPort=53:53/udp
PublishPort=3001:80/tcp

Volume=%h/containers/adguard/workdir:/opt/adguardhome/work
Volume=%h/containers/adguard/confdir:/opt/adguardhome/conf

Label=traefik.enable=true

[Service]
EnvironmentFile=%h/containers/.env
Restart=always
TimeoutStartSec=300

[Install]
WantedBy=default.target

Example: Traefik quadlet

Note how we’re exposing podman.socket as docker socket. This allows the traefik service to query for all Podman containers and automatically set the routers and services using the Label= values in the container.

To enable podman.socket, see docs↗.

systemctl --user enable podman.socket
loginctl enable-linger <USER>

Traefik quadlet is below.

[Unit]
Description=Traefik server

[Container]
ContainerName=traefik
Image=docker.io/traefik:v3.1
AutoUpdate=registry

EnvironmentFile=%h/containers/.env

Network=selfhost.network
HostName=traefik
PublishPort=80:80
PublishPort=443:443

# Note the dynamic config is required for services running outside the docker
# socket/selfhost network. E.g., adguardhome and traefik itself. Both are
# statically routed.
Volume=/run/user/1000/podman/podman.sock:/var/run/docker.sock:ro
Volume=%h/configs/traefik/dynamic:/etc/traefik/dynamic:ro
Volume=%h/configs/traefik/traefik.yml:/traefik.yml:ro
Volume=%h/configs/traefik/logs:/logs
Volume=%h/configs/traefik/acme.json:/acme.json

# Keep the SELinux label of the container runtime.
# Required to communicate with the socket.
SecurityLabelDisable=true

[Service]
Restart=always
TimeoutStartSec=300

[Install]
WantedBy=default.target

Traefik configurations

Traefik and Adguard are the only services which listen directly on the host ports 80/443 and 3001 respectively.

We setup Traefik to directly route to admin.domain.com for Traefik admin dashboard and adguard.domain.com for Adguard web portal.

# traefik-dynamic.yml
http:
    routers:
        adguard:
            entryPoints: ["web"]
            rule: "Host(`adguard.domain.com`)"
            middlewares: ["adguard_redirect"]
            service: "adguard-pasta"
        adguard_https:
            entryPoints: ["websecure"]
            rule: "Host(`adguard.domain.com`)"
            tls:
                certResolver: "letsencrypt"
            service: "adguard-pasta"
        traefik:
            entryPoints: ["websecure"]
            rule: "Host(`admin.domain.com`)"
            service: "api@internal"
            tls:
                certResolver: "letsencrypt"
                domains:
                    - main: "domain.com"
                      sans: ["*.domain.com"]

    middlewares:
        adguard_redirect:
            redirectScheme:
                scheme: "https"

    services:
        adguard-pasta:
            loadBalancer:
                servers:
                    - url: "http://192.168.1.111:3001"

For all the other services we use the docker provider.

# traefik.yml snippet
providers:
    docker:
        watch: true
        exposedByDefault: false
    file:
        directory: "/etc/traefik/dynamic"

Conclusion

This migration was spread over a week of learning and sometimes the agony of things not working as expected. Moving over to Podman and running the containers rootless was worth the effort.

Adios, until next time.

XMF released

Sun, 31 Aug 2025 17:11:27 GMT

We released xmf↗ today. xmf can track stocks and mutual fund portfolios using the command line terminal. As usual the tool is free, open source and completely private.

Summary of an example profile with three portfolios and USD currency.

A short list of features

Create multiple profiles, each profile can have multiple portfolios.
A portfolio can track stocks, mutual funds (India) and fixed deposits.
Data sourced from Yahoo Finance and the MF API by @captnemo↗.
Track summary, changes in the portfolios, returns (CAGR and rolling), mutual fund fees, and asset allocation.
Supports multiple currencies and auto-conversions for reporting.

The app is built with LLMs for the most part. It’s also my first rust app published on crates.io↗.

Any feedback is most welcome!

Pomodoro in Polybar and i3

Tue, 22 Jul 2025 16:50:58 GMT

A few weeks back I setup a pomodoro workflow on my primary desktop running i3↗, polybar↗ and Archlinux↗. The flow and scripts are built around the uair↗ pomodoro app.

The user controls pomodoro using hotkeys bound in i3wm config. Polybar uses a custom module to read the state. uair is the pomodoro timer CLI app.

We defined two types of sessions in uair config↗. Both are hooked to a shell script (see step 4 & 5).
User has configured hotkeys to toggle sessions (break or work) and start/stop them in i3 config↗.
Hotkeys run the uairctl command to instruct uair - change current session, or toggle its running state.
uairctl passes the instruction to uair.
On a session start, uair will invoke the configured shell scripts.
These scripts may store some state in a file, e.g., session count.

Polybar is configured↗ to read uair output via the pomo.sh↗ shell script. On start this script will run uair command.

I think this flow is a good example of composing tools that just do one thing well to build complex workflows. Hope our AI workflows will also be this simple and composable someday!

What problems to solve

Sun, 13 Jul 2025 06:22:23 GMT

Picking the most interesting problems is top of mind for many of us riding the AI hype cycle. I’ve quoted this correspondence between Richard Feynman and a former student (Koichi Mano) several times this week. Here are some additional notes to self.

What Problems to Solve↗ - a letter by Richard Feynman, 1966.

Chasing the grand problems

More often than not we get into a creator’s block followed by self-doubt. I should probably be working on AI Agents? AGI or deep research? Wait, representation engineering and alignment research is the hottest field right now! Am I even solving the right problems?

Feyman’s advice may sound simple. Don’t bother, just show up and build.

The worthwhile problems are the ones you can really solve or help solve, the ones you can really contribute something to.

I would advise you to take even simpler, or as you say, humbler, problems until you find some you can really solve easily, no matter how trivial. […] You must not take away from yourself these pleasures because you have some erroneous idea of what is worthwhile.

The mirage of solving the grandest problems might rob us from the fundamental reasons that got us into our fields. For me it was the joy of creation, and solving problems with a computer. It was not data structures, algorithms, or the leetcode. It was also not the earlier hypes of WWW boom or the browser wars. I learned to code for the sake of it.

It may be the time to go back to the roots, tinker with AI, rip it apart and learn block by block. I’m sure the right challenges will show up.

Find your gig

There’s one big catch. We work on their problems instead of ours.

I accepted him as a student because he came to me with the problem he wanted to solve. With you I made a mistake, I gave you the problem instead of letting you find your own; and left you with a wrong idea of what is interesting or pleasant or important to work on (namely those problems you see you may do something about).

We’ve been handed over problems to work on through the formative years of our training - in school, colleges, and at work. Our employers decide the highest business priority and we dive deep to solve those. Is this second-hand problem also a priority for you to work on?

Just as the employers hire the best candidate for a job, we too hire our employers to give us the right problems to work on.

Let’s step back.

Shouldn’t we first pick a problem? And then hire an employer where we can push your chosen field further?

Things you love

What comes first - the problem? Or the fact that we can do something about it?

It may sound unintuitive how can you care about a problem even before you know it? Say we work through the principle above and strive to identify our own problems. Where do you think you will identify the problems?

You will find them in the areas you’re deeply passionate about. You must care about it more than anyone else. Call it the calling, the ikigai or whatever. Once we’re in our domain, problem solving is natural, and so is the state of flow. I don’t need the extrinsic motivations. I stay awake to find a solution just because I should.

No problem is too small or too trivial if we can really do something about it.

Why do I care whether the problem is grand or puny? Why does it matter if it is solved or otherwise? I can and I will work on it.

An agent for that

Sat, 05 Jul 2025 08:09:52 GMT

In the beginning there was a machine that could talk like most of us. Maybe not as smart yet coherent enough. We realized it needs to do more. As good computer scientists, we know Garbage In, Garbage Out; we need to feed this talking machine interesting context for it to be smarter.

RAG came up - we were able to push relevant data the machine could spew out in a coherent and convincing packing. There’s a challenge, not everything can be solved with search or information retrieval.

A good AI must be able to act, and maybe plan, or appear to do so.

We brought in the tools. Created functions, plugins, and recently MCP (model context protocol) and the A2A (agent to agent) protocol. I’ve never seen any other protocol get adopted as fast. A few years back, there used to be committees to think through and propose the correct™ specification.

Not any more.

Why you’d wonder?

The wrong problem

Our agents can build protocols, tools, software, artwork, and what have you. Just so that you can focus on the thing that matters.

WTF! A bunch of us oldies thought software programming is creativity. We even raised our art and called ourselves craftsmen. We’ve debated everything from choosing the right editor to the correct delineation (tab vs space). We know our craft.

Let our agents do that, so you can focus on the thing that matters.

The agent decides the protocol spec, it creates the reference servers and clients, all the way up. A change in protocol burns a few million tokens at the worst.

We don’t need a committee for this. Instead this committee can ask agents to churn tokens while they do more important things.

Stop working on the wrong problem, and do the thing that matters?

Grunt begets grunt

Before we find the important things™, let’s talk about our day right now.

It took 153 commits↗ to port arey↗, a simple ~18 file python commandline app to rust over several weeks. I’ll talk about the lessons in another post. The key challenge: who’s going to review this?

I asked AI to write tests. What if it writes wrong code and an equally wrong test accompanying it? Who’ll find the issue?

A key paradigm change is in order. While we used to swear by craftsmanship, quality, and the art of writing code, the present is about the art of reading and reviewing code.

All that said, I’m churning code much faster than ever with AI.

A part of my job is to review documents and proposals. Guess who’s writing all the docs these days? An AI. And who’s reviewing all of that?

Let our agents do that, so you can focus on the thing that matters.

This doesn’t sound any true right now when you’re bombarded with sloppy code to review, or the same monotonic proposals. I too will use agents to review.

But isn’t this a game of Monkey in the Middle. I am the monkey trying to catch the ball played by agents.

I used AI to automate my grunt work, and here I’m reviewing the grunt created by AI.

The important thing™

The elephant in the room is AI creates, AI reviews, AI commits and thus I am out of a job. Or, a corollary, AI now does everything that mattered in my job.

I don’t think so.

I wish I could hold the AI and ding it for the Severity 2 incident it created last week. I can’t do that. I still put the accountability on the human.

So, our job to create value remains the same; with the unfortunate side effect of dealing with some chaos for now. It’s a phase like any other, well until, we build an AI on-call that we can hold accountable.

Note that phase by phase we’re transitioning a layer of the work from coding to monitoring and on-call.

Once this phase is done, all of us are CTOs with a bunch of agents to command.

Still, the value creation stays with us, just like the CXOs today steer a 200K employee organization to create value for stakeholders.

It’s you, not the AI

There’s the hype of what AI is capable of. This set is changing every day, literally. Models are powerful than ever before.

Then there’s us, the tool wielder. We’re trying hard to tame AI to our ways, and it is a struggle every day.

The good news is we’re used to this struggle. Do you think it would’ve been easy to rub stones to create fire? If you were a student who struggled to create fire, would your teacher blame the stones or you?

It’s you. It’s us.

Learn the tool. Or create one that just works™. And don’t forget to sit back and enjoy the evolution live show.

Year in review - 2024

Wed, 01 Jan 2025 10:31:52 GMT

This is our yearly review for 2024. Previous editions: 2023, 2022.

Scorecard

Here is a snapshot of the last year. Lessons are in the next section.

Reading: a handful of papers, 9 books (goal: 24 books)
Writing: 8 posts (goal: 24 posts)
Work
- Like last year, the focus this year was on AI. Shipped two AI productivity projects for enterprises.
- Six prototypes. 5 for AI and one for a large engineering refactoring. Did some LLM finetuning without much luck.
- Authored a few guidance documents, one got picked by office of the CTO.
- Short-circuited and closed few experiments early. Similarly, happily said no to several projects where I believed impact is not proportional to the effort.
- Decided against shifting to an ML engineering role. An architect creates and ships more 🚀
- Balanced work and life well this year. We now run a different and more holistic race ☯️
Home
- Lab and projects
  - Multiple releases this year: spekt test loggers↗, noted↗, arey↗ and habito↗.
  - I had big plans for arey↗ but couldn’t do much because of other pursuits.
  - Adopted AI for my vim setup with code companion and minuet.
  - Moved out of Google search in favor of self-hosted SearXNG.
  - Decided against pursuing Philosophy for an MA degree. Curriculum was awesome, but we have to go beyond intellectual pleasure.
- Body and mind
  - 3 trips this year: beaches, mountains and 8 days road trip through some of the offbeat places in a neighboring state.
  - With experience, the goals and priorities are clearer this year. Our identity happily grew beyond the little bubble of work.
  - Good progress on patience and non-violence virtues.
  - Philosophy practice went well with lectures and books.
  - Ran some Ayurveda experiments on self. Changes are slow but positive. Will continue this.
  - Spent a week on the bed due to an ailment. Its aftereffects are continuing for months now. This is a timely reminder that I’m nothing if this body fails, and I dug this hole for myself.

Lessons learned

Large refactoring projects never work without a customer.
How do you know something’s never going to ship? Too high a bar, no clarity on the scope and lot of bike shedding to find the right thing.
A lot of projects ship just around the time for appraisals. Guess the reason?
We create solutions which create more problems, and we set out to solve them. Is this is a virtuous or a vicious cycle?
Saying no is a necessity. And you will inevitably disappoint a few people. Know the impact and go for it.
Disillusionment is healthy. But don’t be a pessimist.
Inertia of action is better than inertia of rest.
Time is extremely limited.
Open LLM models have won. Gap is small within the models in a given param range. We have seen open win the cloud, and now it is a repeat.
Artha (remember the purusharthas) provides a sense of security. Money is one means. Good health and relationships maybe the others.
Segregation of reading by a topic allows diving deeper and framing a concrete opinion. We did this for Philosophy, Ayurveda and Biology this year.
What you read fuels what you think and eventually your future actions.
A little practice in philosophy goes a long way. Don’t go by the quantity. The small exposure fills our mind with inquiries that last for days at a time, even while all the mundane activities are running.
We need a teacher to help go beyond the words and appreciate the truth. Self-study can complement but not replace.

Year ahead

Reading: 24 books. Papers is not an explicit goal this time.
Writing: 24 posts.
Work: 5 experiments, ship at least 2.
Home
- Lab and projects
  - At least 2 releases for every active project
- Body and mind
  - Journal: daily with weekly reviews.
  - Exercise: 3/week.
  - Philosophy: practice daily.

Thanks for reading this far. Wish you a great year ahead!

Release please

Sat, 12 Oct 2024 16:24:59 GMT

A usual release of the spekt/testlogger↗ project involves going through all the commits and meticulously crafting the CHANGELOG↗. It takes about half an hour and is boring enough to keep postponing the releases 🤭 We set out to automate this one.

Fortunately, Google’s release-please↗ automates generating changelogs, creating release tags and GitHub releases. It’s supposed to be just adding a step to your GitHub action workflow; except I could not make sense of the state transitions 😕 Thus was born test-release-please↗ experiments.

Lets deep dive into the state transitions to clarify the usage of this tool. And also talk a bit about releasing dotnet projects.

Release please

Release please action works in two phases. In the phase 1 (blue), the action runs as part of a GitHub workflow and ensures a “release PR” reflects the set of changes for next release. And in phase 2 (green), the user merges the “release PR” and a GitHub release is created automatically by the action.

First things first, you need to add a single release-please action somewhere in your workflow. It must run on every push to the main branch. This action is stateful, so you don’t want concurrent workflows/jobs with same action.

Here are the steps along with examples:

Setup release-please action in a GitHub workflow. See example↗. Now, keep making changes to the code as usual.
The GitHub workflow will compute the changes↗ since last release and will create a PR like this↗. Note that the action parses conventional commit messages↗ and GitHub tags to find the next semver↗ release.
The PR↗ will be auto updated with every workflow run. E.g., a patch release will be upgraded to a minor release if you have any commits with feat: xyz message. Note the PR has a label autorelease: pending.
Now you decide to release by merging the release PR.
PR is merged and a workflow run is triggered.
On this workflow run, the PR’s state changes to autorelease: tagged, the commit is tagged, and a release gets created.
See an example previous release PR↗ and the corresponding release↗.

How this magic works?

In three keywords: GitHub actions, events, and labels/tags managing the state.

Blue phase: continuous commits result in changelog updates by parsing the conventional commit messages. A PR is created and stays up to date. It also serves like a mini dashboard of the release payload for next version.

Green phase: release-please tool learns that you’ve merged a PR with autorelease: pending label. It will cut a release and update the label in the PR post that. Next run of the tool will happen in blue phase.

Dotnet releases

The release-please↗ action knows which files to keep up-to-date in the coding phase, e.g. CHANGELOG.md and pyproject.toml for python projects.

Now dotnet is not supported as a first class language. Fortunately, the tool supports a generic strategy called simple which can update the changelog and a version.txt file in the repo to depict current release version.

The workflow in spekt/testlogger↗ had two requirements:

We need the pre-release NuGet packages to be uploaded to a specific feed (MyGet).
Release versions are uploaded to both MyGet and NuGet feeds.
Version is managed in the workflow through a MSBUILD property. We must determine the next version dynamically inside the GitHub workflow.

You can see the solution in testlogger ci↗ workflow.

We refactored the workflow into two jobs.

The version job runs a bash script to find the next semver given the previous release in version.txt. See the example code below. Further, if release-please task detects we have a release cut, we force the build version to be the tagged version.

version:
    runs-on: ubuntu-latest
    steps:
        - uses: actions/checkout@v4
        - uses: googleapis/release-please-action@v4
          id: release
          if: github.ref == 'refs/heads/master'
          with:
              token: ${{ secrets.GITHUB_TOKEN }}
              release-type: simple
        - name: Set default build number
          run: |
              # https://stackoverflow.com/questions/8653126/how-to-increment-version-number-in-a-shell-script
              BUILD_VERSION=$(cat version.txt | awk -F. -v OFS=. '{$NF=$NF+1;print}')-pre.${{ github.run_number }}
              echo "APP_BUILD_VERSION=${BUILD_VERSION}" >> $GITHUB_ENV
        - name: Update build number
          if: ${{ steps.release.outputs.release_created }}
          run: |
              RELEASE_VERSION=${{ steps.release.outputs.tag_name }}
              echo "APP_BUILD_VERSION=${RELEASE_VERSION#v}" >> $GITHUB_ENV
        - name: Final build version
          run: |
              echo ${{ env.APP_BUILD_VERSION }}
    outputs:
        build_version: ${{ env.APP_BUILD_VERSION }}
  build:
    needs: [version]
    env:
      APP_BUILD_VERSION: ${{ needs.version.outputs.build_version }}
    # rest of the steps use APP_BUILD_VERSION env variable.

The build job uses the output of version job to set the package version. Now with every commit, the release PR will stay up to date and pre-release packages will use x.y.z-pre.n versions. Once you merge the release PR, a package version is generated with x.y.z.

That’s all for this experiment. Thanks for reading!