DEV Community: Angel L. Valdés

I don't code alone: I lead a team of agents

Angel L. Valdés — Mon, 02 Nov 2026 00:09:35 +0000

At 12:25 on October 27, Netty was an idea.md file. By 22:58 the same day, the app and its landing page existed, with 38 commits in between. By the 30th it had launched.

Netty is a macOS menu bar app that tells you whether you're really online. The idea isn't original; similar apps already exist. What was interesting about those four days was something else: how I built it.

I didn't write every line by hand. I also didn't ask an AI to "make me an app" and go grab a coffee. I worked like a project manager with a development team. Each agent was an independent developer that wrote code and tested it; I reviewed it and decided what came next.

The best part was testing. The agent could use the Mac directly and run real integration tests while I watched. And when it came to the website, it could see what it was designing in a real browser. It had hands and eyes.

This post is that workflow, piece by piece.

The full picture

My stack has eight layers, each with one job:

Layer	Tool	Its job
Terminal	Ghostty	Where everything lives
Workspaces	herdr	Keeps the agents running in parallel in order
Version control	Git and GitHub	Gives each agent its own space
Agents	Gentle AI, Gentle Shell, and Engram	Define how the agent works and what it remembers
Browser	ego-browser	Gives the agent eyes and hands on the web
Voice	BetterWispr	Lets me talk to the agents instead of typing
Knowledge	Obsidian	My second brain, shared with the agents

The terminal: Ghostty

Almost everything happens in a terminal, so the terminal matters. I use Ghostty because it's fast and feels native on macOS, which is exactly what you want from the tool you keep open all day.

Netty was the test. For four days I had several agents working at once, and Ghostty never froze or crashed. The Mac stayed cool, and I kept working in other apps in the meantime.

All my configuration, for Ghostty and for every other tool in this post, lives in my alvaldes.dots repo.

The workspaces: herdr

One agent at a time falls short. While one writes the app, another can build its website. The problem is keeping track of them.

herdr is a workspace manager for AI agents in the terminal. Each workspace is a project with its tabs and panes, and herdr detects which agent runs in each one and what state it's in, so you know when one needs you. Sessions stay alive after you disconnect, like tmux, and you can connect to them from another machine.

I pair it with Git. For each agent I create a worktree: a copy of the repo in its own folder, on its own branch. Each agent works in its worktree without stepping on the others, and at the end I merge each branch and resolve the conflicts.

On Netty I worked with at least two: one for the app and one for the website. The app's agent sometimes split into more agents, one per feature or per independent unit of work.

Video in the original post.

The agent layer: Gentle AI, Gentle Shell, and Engram

An agent without rules is a new developer without onboarding: fast, eager, and able to break things with all the confidence in the world. This layer is the onboarding.

All three tools come from Gentleman Programming, Alan Buscaglia's project:

Gentle AI is a discipline layer for agents. It defines how the agent works: when it asks, when it plans before writing, when it delegates to subagents, which skills it loads, and when it asks for a review before calling something done.

Gentle Shell is the workspace built on Pi, a coding agent. It ships Pi with all of Gentle AI already loaded, plus agent orchestration, diff views, and usage monitoring.

Engram is the memory. An agent forgets everything when the session ends; Engram stores the decisions, the fixed bugs, and the conventions, and the agent gets them back next time.

Engram was key on Netty. I had built JUMP, another macOS app, before. When Netty started, the agent searched JUMP's memory for the mistakes it had made there and what it had learned, and didn't repeat them. One of those lessons: on JUMP, an unsigned build lost its Accessibility permission on every update. It didn't stop at the current project's context: it went looking in another one of my projects.

Gentle AI does a lot more than fits here. What matters is the idea: the agent doesn't improvise how it works in every session. It always works the same way, and it remembers what it already learned.

The browser: ego-browser

An agent that writes a web page without seeing it is working blind. It can write correct CSS that looks wrong.

ego-browser is a Chromium-based browser built for humans and agents alike. The agent drives it from the terminal: it opens pages, clicks, fills in forms, and takes screenshots. And since it's the same browser I use, it has my sessions signed in.

On Netty's website that changed the result. The agent designed, looked at the screenshot, saw what didn't work, and fixed it, without me having to describe every problem.

Video in the original post.

The voice: BetterWispr

I type less and talk more every day. With a team of agents, much of the work is explaining what I want and what's wrong. Talking, I explain it faster and in more detail than typing.

I use BetterWispr, which is open source and free. I dictate to the agent and the transcription comes out very well. macOS dictation already works, but adding the Parakeet Ultra model, about 730 MB, makes the result much better. It's absolutely worth it, and it barely uses any of the Mac's resources.

The knowledge: Obsidian

The agents remember with Engram, but I need to remember too. Obsidian is my second brain: ideas, projects, and resources in one place.

I organize it with two of Tiago Forte's frameworks. PARA defines where everything goes: Projects, Areas, Resources, and Archive, plus an Inbox at the entrance. CODE defines the flow: capture, organize, distill, and express.

The agents work with it both ways: they read it and they write to it, so the second brain stays up to date without me copying everything over by hand.

Netty started there too, as one more note in the Inbox.

Netty, end to end

This is how all the pieces came together.

Video in the original post.

The context. I started by giving the agent references to similar apps that already existed, so it knew the ground we'd be working on. Then I handed it my idea.md, the file with all my notes on what I wanted to build.

The app. We went feature by feature. Whenever there was a result I could review, I reviewed it, corrected what was needed, and we moved on to the next one.

The design. I gave it references for the style I wanted. The agent opened them in ego-browser, studied them, and brought those styles into the app. I kept reviewing along the way.

The website. In its own worktree, another agent built the landing page element by element and published it on GitHub Pages.

The launch. I did all of it with launch-skills, my open-source skills for launching projects, and ego-browser. The agent prepared the kit, generated the images, filled in the directory forms, and drafted the posts for each network. Before each one went out, it stopped and showed me what it was about to send. The last click was always mine.

An extra: the team in your pocket

The stack works without this, but this takes it further.

Tailscale connects the Mac and the phone in a private network. As long as the Mac is on and online, I can reach herdr from my phone, anywhere, and keep talking to the agents without carrying the computer.

On the iPhone side I use Moshi, though other terminal clients such as Termius work too.

It happened to me many times with Netty. An agent got stuck, told me what was blocking it, and I unblocked it from my phone so it could keep working.

What changed, and what didn't

Netty went from a note in the Inbox to a published app in four days, and I barely wrote any of the code.

My job is different now. I decide what gets built and in what order. I give each agent the context it needs, from the references to what I learned on JUMP. I review every result before moving on and correct it when it isn't right. I'm a project manager with a team, not a developer with autocomplete.

What didn't change is that someone has to know whether the work is good. An agent is wrong with the same confidence it's right. The tools in this post don't remove that review: they organize it. Worktrees keep the agents from stepping on each other, and ego-browser lets me see every page before I approve it. The last word is still mine.

The agents execute. I direct.

If you want to build something similar, everything in this post is public: my configuration is in alvaldes.dots, each tool is linked in its section, and Netty is open source. And if you work differently, I'd like to hear about it: write to me and tell me about your stack.

Netty: is the internet really there?

Angel L. Valdés — Sat, 31 Oct 2026 19:57:55 +0000

The Wi-Fi icon in the menu bar answers one question: am I connected to a network? It doesn't tell you whether the internet actually answers. A hotel login page, a router that lost its uplink or a connection that crawls all look the same: full bars.

I wanted a dot that answers the question that matters. Am I really online? Is the connection good? How fast is it?

That's Netty.

What it does

Netty is a macOS menu bar app. Its icon is a dot that changes color with your connection:

Color	Status	When
Green	Online	The internet answers and the connection is good.
Yellow	Degraded	Latency, jitter or packet loss crosses a threshold.
Red	Offline	A few checks in a row failed.

Click the dot and a popover shows latency, jitter, loss, the last speed test and your network: Wi-Fi name, Ethernet or hotspot, whether a VPN carries your traffic, and your local and public IP. You get a notification when the connection drops and when it comes back, with how long you were offline.

Almost everything can be changed: the rules for yellow and red, which sections the popover shows and in what order, what each click does, and the icon itself, in color or black and white, with SF Symbols or your own image.

Why I built my own

There are good apps that do this, like Netbar and Netdot, and Online Check does the "real internet" part well. I used them as references. But I wanted one that was free, open source and designed with the same care as the rest of macOS. Netty ships under GPL-3.0, like JUMP.

How it works under the hood

Real internet, not just a network. Netty asks Apple's captive portal check, with Google's as a fallback, whether the internet answers. Wi-Fi without internet or a login page counts as offline.

Quality from a TCP handshake. Every 10 seconds Netty opens a TCP connection to 1.1.1.1 and 8.8.8.8 and times the handshake. Latency, jitter and loss come from those samples. It also checks right away when the network changes or when you click the icon, so a drop or a recovery is confirmed at once instead of waiting for the next interval.

Speed with the tool macOS already has. The speed test uses Apple's built-in networkQuality: download, upload and responsiveness. No servers of my own. It runs when you ask, or on a schedule that's off by default and skips metered networks.

Nothing leaves your Mac. No analytics, no telemetry. The checks go to Apple, Google and Cloudflare, and the public IP is looked up only when you open the popover, at most every 5 minutes. Hide it and it's never looked up.

Engineering decisions

The core is its own package. The rules that turn probe samples into a status live in NettyKit, a Swift package that's tested without opening the app:

swift test --package-path Packages/NettyKit
NETTY_LIVE=1 swift test --package-path Packages/NettyKit

The second command also hits the real network and runs a speed test. Keeping it behind a flag means the normal suite is fast and doesn't depend on your connection.

Reviewing the UI without opening it. Debug builds can render the popover, every Settings pane and every icon to PNG files and quit. I check a change in light and dark, in each status, without clicking through the app. The screenshots in this post came out of that.

The Wi-Fi name needs Location. macOS only shares the network name with apps that have Location access. Netty asks for it with its reason, never reads your location, and still works if you say no: it just shows "Wi-Fi".

Try it

Netty needs macOS 26 or later. Download it from its website or from GitHub, or install it with Homebrew:

brew install --cask alvaldes/tap/netty

It isn't notarized by Apple yet, so macOS blocks it the first time. This guide walks you through opening it.

If something breaks, or you have an idea to make it better, open an issue in the repository.

Originally published on my blog.

JUMP: keyboard-first, even outside the browser

Angel L. Valdés — Wed, 28 Oct 2026 18:22:25 +0000

In the browser I barely touch the mouse. I use Surfingkeys, an extension that puts a label on every link and button: I type the label and that's the click. Over the years I built my whole setup around the keyboard, and Vim's h j k l keys are muscle memory by now.

The trouble started when I left the browser. To click a single button in Finder, System Settings or any other app, I had to let go of the keyboard, reach for the mouse and come back. A few milliseconds, sure. But it happens many times a day and it adds up, and I'm a productivity nerd: those milliseconds matter to me.

That's where JUMP came from.

What it does

JUMP is a macOS menu bar app. Press a shortcut and every clickable element in the focused window gets a short label. Type the label and JUMP clicks it.

Shortcut	Mode	What it does
⌘ ⇧ Space	Hints	Labels every clickable element. Type a label to click it.
⌘ ⇧ J	Scroll	Scrolls the window Vim-style: `h j k l`, `d u`, `gg G`.
⌘ ⇧ F	Search	Finds visible text, ignoring case and accents.

Hold a modifier while typing the label to pick the action: ⇧ right-clicks, ⌘ double-clicks and ⌥ only moves the pointer. All three shortcuts and the modifiers can be changed in Settings.

Why I didn't use something that already existed

The first thing I did was look around. I found two options:

Vimac, open source, but untouched since December 2022.
Homerow, its commercial successor: it works well, but it's paid and closed source.

Neither felt right, so I thought: why not build my own tool, the way I like it, free and open source? I'm an open-source fan. I like the community that grows around a project and the idea of sharing what you learn. JUMP starts from Vimac's code, which is GPL-3.0, modernizes it for macOS 26 and ships under the same license.

How it works under the hood

The Accessibility API. macOS exposes every app's interface as a tree of elements: buttons, fields, links. JUMP walks that tree in the focused window, keeps what can be acted on and draws the labels on top. That's why it needs the Accessibility permission.

OCR as a fallback. Some windows don't expose their text through Accessibility, like terminals or PDFs. For those, JUMP can recognize the text on screen with the Vision framework. It's off by default, asks for the Screen Recording permission only when you turn it on, and the captures never leave memory.

No Mac App Store. Store apps run in a sandbox, and an app that reads and drives other apps through Accessibility can't work from inside one. JUMP ships through GitHub Releases instead.

Engineering decisions

The core is its own package. The logic lives in JumpKit, a Swift package that's tested without opening the app:

swift test --package-path Packages/JumpKit

Testing something that depends on other windows and system permissions is hard. Keeping the core apart from the UI makes it testable.

The permission that vanished on every build. macOS ties the Accessibility permission to the app's code signature. With the default ad-hoc signature, the signature changes on every build and the permission is gone. The fix was signing with my own development certificate, and the release script refuses to publish an ad-hoc signed app: users would lose the permission on every update.

A release you can't get wrong. The same script also rejects uncommitted changes and untagged commits. I'd rather it fail than ship something I can't reproduce.

Try it

JUMP needs macOS 26 or later. Download it from its website or from GitHub.

It isn't notarized by Apple yet, so macOS blocks it the first time. The README walks you through opening it.

If you use it and something breaks, or you have an idea to make it better, open an issue in the repository. That's what open source is for.

Originally published on my blog.