Reflections on 2025

As the year draws to a close, I find myself wanting to pause and look back. For me, the year felt like three parallel tracks. One was steady: maintaining open source tools, shipping small features, the quiet satisfaction of consistent work. Another was turbulent: I changed teams three times at work, each shift reshaping my context and the problems I was solving. And the third was a whirlwind: AI coding agents arrived, reshaping how I approach software engineering. This post is a reflection on navigating all three.

Building Developer Tools

Over the last few years, I’ve found a quiet joy in building and maintaining open source developer tools. 2025 saw a steady continuation of that. Here’s a visual summary of what that looked like.

Looking at the activity graph, I’m happy with the steady hum of progress it represents, across commits and pull requests. I don’t think of the numbers above as a scorecard, but they’re a useful reminder that small increments stack up.

Languages & Ecosystems

This year marked a shift in my toolbelt. While I continued to maintain existing tools written in Go, 2025 was the year I started building with Rust seriously. The strictness of Rust’s compiler and the richness of the ecosystem have been a pleasure to work with.

I also found myself dabbling with Gleam, primarily to add web interfaces to some of my existing tools. I’ve come to really appreciate the language; it’s friendly, pragmatic, and the community surrounding it is incredibly welcoming. It came as no surprise to see it rank second in the “Desired and Admired” section of Stack Overflow’s 2025 Developer Survey. For me, the tooling in all three of these ecosystems makes open source maintenance sustainable and, more importantly, enjoyable.

Old and New Tools

I built new tools and added features to old ones, learning from both. The scale varied too: from medium-sized projects to small, narrow utilities. Here are a few notable entries:

New

Updated

A Separate Devlog

Throughout the year, I often felt the urge to share smaller, more immediate learnings from building developer tools: snippets that felt too brief for a full-bodied blog post. To bridge this gap, I spun up a separate devlog.

I really enjoy this format. It allows me to share findings rapidly and tell the stories behind the software I’m building. I recently started a section called “Build Bytes” for brief, low-context updates on tool maintenance, which has been a great way to document the ongoing process of development.

Doing this at scale

At the time of writing, I’m maintaining around 30 tools. Keeping release pipelines healthy for all of them can become tedious, so out of necessity, I’ve built tooling to help manage maintenance itself (which I wrote about here). It feels like a natural evolution of being a long-term maintainer: eventually, you build tools to help you build tools.

Value and Impact

I strongly value “small, sharp tools.” I was reminded of the power of this philosophy when I recently came across kondo. It’s a simple tool for cleaning dependencies and build artifacts. The interface is straightforward, and I imagine the implementation is too. Freeing up space on my hard drive was something I’d been meaning to do for more than a year. Every now and then, MacOS would show me an alert for this, I’d clean up a few GBs to make the warning go away, and the cycle would repeat. kondo helped me reclaim about 100Gb of disk space in a matter of a few minutes. That kind of tangible impact is exactly what I strive for in the tools I build.

One of the best parts of maintaining open source software is the human feedback. Once in a while, I receive a kind email or message from someone who found a tool useful. These notes mean a lot to me.

A Renaissance of Command-Line Tooling

There’s a palpable shift happening in the space of command-line tooling. We’re seeing a wave of new CLIs, TUIs, and terminal-first workflows. Coding agents are finding a natural home in the terminal. Even new terminal emulators are popping up; I’ve been using Ghostty by Mitchell Hashimoto.

It’s an exciting time to be building for the terminal.

Shifting Context at Work

If open source was my steady track, my professional year was defined by change. I moved between teams three times within the same company: two moves already done, with a third coming at the start of the new year.

I started the year on a product team, but moved to a Platform team early on. Building for developers is the same impulse that drives my open source work, and I wanted to do more of it professionally. During my brief time in this team, I focused on setting up workflows that made other engineers’ lives easier, and even got to leverage some of my own tools in the process.

Mid-year, company restructuring shifted me to an AI platform team. The work was different from what I was used to: data pipelines, classification systems, the infrastructure that powers machine learning features. I spent time understanding how data flows through these systems, how models get trained and deployed, and how to keep it all running reliably.

Later in the year, the company restructured again, spinning up more teams focused on AI products. By then, I’d already been experimenting with AI agents, and when the opportunity presented itself, I chose to move to a new team that will build user-facing agentic workflows.

These moves have been a double-edged sword. On one hand, they kept me on my toes and exposed me to a wide variety of people, contexts, and problems. On the other, the constant shifting made it difficult to build momentum or settle into the kind of long-term ownership I usually enjoy.

Looking ahead, I’m excited to return to building a product again, and explore the space of AI agents in a professional context.

The Year of Coding Agents

There’s no doubt that 2025 was the year of AI coding agents. Before 2025, I dabbled with LLMs mostly via web interfaces like ChatGPT. This was useful, but a bit disconnected from how I actually write and ship code. 2025 was the year my usage of LLMs went up, primarily because the tooling finally caught up. The ability to invoke LLMs directly from the command line changed everything.

The first coding agent I tried was Claude Code. Watching it take a prompt, go off, and actually do work was a genuinely mind-blowing moment. Since then, I’ve experimented with many agents, but I intentionally stick to terminal-based ones.

I occasionally check in on AI-native IDEs like Cursor, Zed, VS Code, Antigravity, etc. While they are impressive, none of them provide enough value to pull me out of my terminal-based workflows. For me, the combination of neovim, tmux, and agents is a more productive setup (at least for now; who knows what the future will bring).

I’m also interested in understanding how these coding agents work. As such, I’ve begun work on building my own. The idea is to build a usable product for myself, and learn about the internals of the technology in the process.

I’ve also settled on a simple personal rule: I treat agents as assistants, not replacements. I don’t let an agent write code I couldn’t write myself. It serves as a guardrail, ensuring that I remain the driver of the logic and architecture, rather than a passive observer.

There are bigger questions here. The introduction of AI coding agents feels like a fundamental shift in how code is written. I find myself curious (and a bit anxious) about whether this becomes a net positive for the industry, how newcomers will learn, how patterns and intuitions for problem-solving will evolve.

It’s quite early for things to settle, but I am eager to see how the story unfolds.

Wrapping up

When I zoom out, 2025 looks like a year of steady building and steady adjustment: maintaining open source tools, navigating change at work, and keeping up with the latest advances in how software gets built.

I like that the field of software engineering is ever changing. The landscape might evolve, the workflows might shift, but for me, the joy of building remains steady.