DEV Community: Ryan Swift

Mac-Only? Just Fork It

Ryan Swift — Wed, 06 May 2026 23:26:00 +0000

TLDR - A friend showed me a small macOS-only menu bar app that lists local dev ports. I'm one of the dozens of people who uses Linux (Fedora KDE in particular) as my primary operating system. I used OpenCode to fork and create a working KDE Plasma widget called Portmanteau.

I keep encountering the same problem: I see a cool, new AI or developer tool that I want to try, except they all seem to be macOS only. A few years ago that usually meant time to move on. Now I tend to think, "I can probably fork that."

This time the tool was Port Menu, a simple little macOS menu bar app for seeing local development servers. If you run a bunch of Vite, Rails, Django, Flask, Next.js, or whatever servers during the day, the basic idea is obvious: show me the ports, tell me which project owns them, and let me open or kill them without spelunking through terminal tabs.

But again, macOS-only, so I did what any enterprising vibe coder would do. I started an OpenCode session with a pretty low-stakes question:

This looks macOS only. how feasible would a port to linux be?

Asking More Questions

The first answer was optimistic in the way AI and agents often are. The port scanning idea is very portable. Linux has ss, lsof, /proc/<pid>/cwd, git, kill, and all the raw ingredients you need.

But the app itself was not going to be a normal port. The original is a SwiftUI/AppKit menu bar app. A KDE version wants to be a Plasma widget. That means QML, Plasma packaging, a panel representation, a popup, and a different set of desktop integration edges.

After some poking and additional questioning, the answer got less shiny and more useful. This was not really a port. It was a KDE reimplementation of the same idea:

The algorithm is portable.
The Swift UI is not worth trying to reuse.
A KDE Plasma widget is a good target for my actual desktop.
The scanner should be a small helper that emits JSON.
The widget should stay mostly UI-focused.

That became the shape of the project: a Linux scanner plus a Plasma 6 widget.

Planning Using Tickets (tk)

The next thing I asked for was a plan. And then captured it using ticket tk. I really dig ticket and recommend it if you're working with agents.

Can you plan out the steps/tickets that we need to create this? Let's use tk (ticket) to create epics/tasks/etc.

My agent proposed five epics:

Linux Scanner Core
KDE Plasma Widget MVP
User Actions and Safety
Packaging and Local Install
Polish, Reliability, and Release Readiness

The agent created 38 tickets as part of those epics, added dependencies, and tk ready gave us an implementation order. This is when a project crosses from "exploratory chat" to "work queue".

I then made the irresponsible request:

Can you work on implementing this? Ideally don't stop until all tickets are completed :)

And it mostly did.

What The Agent Built

The agent built the Linux version as a separate linux/ tree so the original macOS app stayed untouched. That feels like the right shape: keep the idea, do not pretend the SwiftUI app was coming with us.

The important pieces were a Python scanner, a JSON contract, and a Plasma widget. The scanner figures out what is listening locally and the widget turns that into a panel popup I can actually use.

It also added the first set of actions: open, copy URL, copy port, and kill. Some of those survived. Copy port did not.

The agent closed all its own tickets too. I do not think of "all tickets closed" as a quality signal, so I did a review pass. That caught real problems: packaging was too fragile, scanner timeouts could break the JSON contract, and Plasma had a few runtime quirks that only show up when you actually run the thing.

This is part of the loop. Ask a question. Plan. Implement. Review. Test.

User Testing

After some agent work, it was my time to test and complain about rough edges.

I had the agent install and activate the plugin. I realized I didn't have any local dev ports that were currently in use. But again, not a problem. We have agents. I just asked the agent to start a tiny Flask server to test detection. The scanner saw it:

{
  "port": 5000,
  "processName": "python",
  "cwd": "/tmp/opencode",
  "projectName": "opencode",
  "url": "http://localhost:5000"
}

That is the addictive part of agentic development. A random idea becomes a panel widget, then a test server shows up in it, and suddenly the thing is real enough to complain about.

One button was blank because the icon name did not exist in my Plasma theme. That button was supposed to mean "copy port." The second button already looked like copy. So I asked the obvious question.

why are there two copy-looking actions next to each other?

My agent simplified to:

Open
Copy URL
Kill

Then kill did not work from the widget, even though the helper worked directly. The confirmation dialog path was broken. We made the red X kill immediately, which matches what the icon implies anyway.

This is where I still feel involved in the loop. The agent can implement the feature, but it cannot feel that a tiny blank square in my panel is weird. It cannot be annoyed by two copy buttons. It cannot look at a red X that does not kill the thing and say, "no, that feels wrong."

Port Menu to Portmanteau

While my agent was busy working on the app, I had time for other important endeavors. Like renaming the project. Portmanteau sounds sorta like Port Menu and sorta is itself a portmanteau. Feels a little old timey to me. I thought it was clever. I'm not sure if you'll agree with me. I also had time to switch to a ship icon because I felt like that was clever too.

The Workflow is the Learning Here

This is not a full, traditional software project. It's a small piece of personal software. It was ~10 messages back and forth with an agent. But it's legitimately useful to me. The productive loop was small:

Ask if an idea is feasible.
Push back on the optimistic parts.
Fork or build off existing progress.
Plan and actually use the plan (I do this with ticket).
Let the agent chew through implementation.
Try it out on the real desktop.
Complain about the parts that feel wrong.
Get it into a usable shape.

That is an excellent agent task: small enough to steer, annoying enough that I would not have done it by hand, and concrete enough that I could tell when it worked.

Think about all the rough edges in your life that you can solve with 10 questions and an overeager intern.

I'm going to continue to find cool ideas that are macOS only. I'm gonna continue to fork them. Translating ideas or projects across operating systems no longer feels like a giant project. Sometimes it is just a conversation with an agent, a few questions, and a tiny ship icon in your system tray.

Portmanteau is a KDE Plasma widget for local development ports. It is still rough, but it works on my Fedora KDE setup. And that's all I need :)

Stop Using Your Clipboard to Share Context

Ryan Swift — Thu, 30 Apr 2026 16:27:59 +0000

We're all learning how to code with agents. If you're "in the bubble" it can feel like everyone is tokenmaxxing. Automating everything. Spinning up overnight agents to write full apps while they sleep. The reality I see with a lot of developers is much more normal:

They are copying and pasting code back and forth from VS Code and ChatGPT.

I am seeing slow adoption of built-in chat interfaces in IDEs like Copilot, Cursor, and Antigravity. CLI agents still feel relatively fringe among next-gen developers. I know this likely is not what you're hearing or seeing on Twitter.

Anyway, I've roasted plenty of developers for copying code back and forth from their IDEs into web chat interfaces. This week, I realized I have been doing the same thing, just with more terminal panes. A test fails in one terminal pane. An agent is working in another. I copy the error, paste it into the agent, wait, run another command, copy the next error, paste again.

My cool hacker-y CLI workflow suddenly felt... less cool.

The obvious fix is: let the agent read the terminal. The less obvious problem is: I do not want agents casually reading every terminal pane I have open.

The CLI Version Of Copy/Paste

I use Zellij as my terminal multiplexer. If you have used Tmux, it is the same general idea: panes, tabs, sessions, and a bunch of terminal state living in one place. I really like Zellij. I struggled with Tmux for whatever reason and never looked back. I seem to be in a minority here though.

I use a variety of CLI coding agents: OpenCode, Gemini CLI, Claude Code, Codex, and whatever else I am trying that week.

A normal tab looks like OpenCode on the left, and one or two panes on the right for running commands, observing tests, or watching a dev server.

But the panes are distinct. Agents do not automatically know what happened in the test pane. My test pane does not know what the agent is trying to debug. So I become the bridge, manually ferrying errors and logs back and forth. Copying and pasting.

Integrated agent shells help sometimes, but they are not the whole answer. Long-running commands eat up agent time. Many commands need elevated permissions. Plus, I already have a terminal layout and workflow I like.

I did not want to move everything into the agent. I wanted the agent to see what I see.

Everything Means Everything

The naive version of my project was easy: give the agent full access. Let it read the whole Zellij session. And call it a day.

Except... secrets and security are a thing. I already play it too fast and loose with my agents. I'm trying to be better about that. I needed selected-pane awareness, not full terminal visibility.

That became the design constraint for zellij-agent-tools: agents should only read panes I explicitly approve, and that approval should be visible where the pane actually lives.

Zellij As The Consent Surface

The project is a Zellij plugin plus a local MCP sidecar.

The Zellij plugin is the human-facing part. It lists panes, asks for approval, marks watched panes, and lets me revoke access.

The sidecar is the agent-facing part. It exposes a small set of MCP tools so agents can list watched panes and read bounded output from the panes I approved.

I did not want consent hidden inside an agent chat. I can see the agent calling the tools in line, but I approve it in the Zellij plugin. I wanted separate surfaces. MCP is the agent interface. Zellij is the human interface.

That feels like the right boundary.

The v1 tool surface is intentionally boring. Just: ask to watch a pane, list watched panes, read a bounded snapshot, read output after a cursor, check status.

That is enough to stop me from copy/pasting every error by hand.

Not Security Itself

I'm not naive to the fact that agents can probably get around this. If an agent has unrestricted shell access as my user, it may be able to call the Zellij CLI directly or do other things I did not intend.

I am not trying to solve malicious local code here. I am trying to make my normal workflow less sloppy.

The goal is for the easy path to be the safer path: ask for the pane, show the user, read only what was approved, fail closed when state is stale or revoked.

That already feels better than copy/paste chaos or full terminal visibility.

More To Do

I still have plenty to do on this project. It's a very rough first pass. But the direction feels right and I think it solves a real problem that I imagine other folks have.

I'm gonna keep using it and iterating on it for my workflows. Feel free to check it out!

Forking Paseo: Mobile vibe coding for me

Ryan Swift — Wed, 29 Apr 2026 19:02:07 +0000

TLDR - I wanted to upgrade my coding-from-my-phone workflow. I found Paseo, forked it, and used AI agents to make the parts I cared about work better for me.

I'm spending a few weeks thinking about the process of coding with AI agents. Not just "which model is best" or "which harness performs best," but my actual mechanics. How I use these tools day-to-day. Where sessions live. How I know what an agent is doing when I am not staring at the same terminal.

On my laptop and desktop, I am slowly getting that into shape. The missing piece is my phone. I am admittedly obsessed with vibe coding, and lugging my laptop around everywhere is a bit of a social faux pas. Or at least I feel like it is.

I want to be able to check on agents, answer prompts, nudge a task forward, and occasionally kick off work when I do not have a computer in front of me.

The tool I wanted needed to match how I actually work:

Linux support
Android support
Local coding, not a cloud service or Saas
Support for the agents I already use, especially OpenCode
A way to continue or inspect sessions from my real dev environment

SSH on a phone technically exists, but that is not the workflow I wanted. I wanted a control plane, not a tiny, inconvenient terminal.

Paseo Mostly Worked

Paseo was the first thing I found that felt shaped like the problem I actually had.

There are other apps in this space. I also looked at Emdash, SoloTerm, and a handful of other projects. I suspect that Google, Anthropic, OpenAI, and other providers will continue to develop their own handoff to phone workflows. But I wanted one consistent layer across agents.

Paseo is a local-first app for monitoring and controlling coding agents remotely. A daemon runs on your machine. The mobile app talks to that. Your code does not need to move into a cloud workspace just so you can poke an agent from the couch. This was important. I did not want a separate mobile coding environment. I wanted a remote control for the environment I already have.

Paseo was also open source, which turned out to be the difference between "this is close" and "I can probably make this work."

Paseo already handled the working usable mobile app.

The Gaps Were My Gaps

Paseo was already thoughtfully designed and looked great on mobile. It supported the core agents I cared about, but my OpenCode workflow exposed some rough edges.

The biggest one was session handoff. I would start a session in terminal OpenCode, then later want to pick it up in Paseo. Not a new agent. Not a fresh chat. The same session, with the same context. The details matter here. Who owns the session right now? What happens if the terminal and Paseo both try to drive it?

There were smaller papercuts too. Slash command autocomplete did not quite feel like OpenCode. Typing /q should obviously mean quit, but the app's ranking and visual ordering could make that feel wrong. Workspace defaults mattered too. If OpenCode already knows the right model or mode for a project, Paseo should not casually override that with its own preferences.

And then there were subagents. OpenCode can spawn subagents, but in Paseo those could look like generic long-running tool calls. From the phone, that read as "is this thing stuck?" even when the agent is doing exactly what it should be doing.

Gemini CLI support is also on my list, but that is probably a future rabbit hole.

Paseo doesn't currently richly support subagents for OpenCode.

I Can Probably Fix That

Turns out, if I can articulate a problem, agents can solve it. So I forked Paseo and used AI coding agents to improve Paseo's support for my needs.

Most of the work was not me sitting down with a perfect design doc and typing code by hand. It was me steering with human language:

"I want to resume an OpenCode session that started outside Paseo."
"This resumed session looks empty, but I know there is history."
"Make /q behave more like terminal OpenCode."
"Subagents look like mysterious hangs. What's going on?"

The agents investigated the codebase, made changes, wrote tests, and occasionally wandered into a wall like agents do. I still had to make decisions and review the results. I was less "implementing a feature" and more describing the workflow I wanted until the software caught up.

I fear professional developers will cringe at parts of my approach. But I also think I am part of an interesting archetype that software people should pay attention to: technical enough to prompt well, inspect results, and push through rough edges, but not necessarily approaching every problem like a traditional dev.

That is not a replacement for engineering discipline. It is a new on-ramp to shaping software.

What I Changed

I think my fork now has a much better OpenCode handoff story. But I really only focused on three areas where the "mobile gap" was most painful to me:

Zero-Friction Handoffs: The app now discovers active OpenCode sessions in any workspace. I can resume a session and immediately see a preview of recent history, making the jump from laptop to phone feel seamless rather than like a context-switch.
Muscular Defaults: We tuned the UX to respect OpenCode's workspace settings and ranked slash commands so that common intents like /q or /exit are always at the top. The mobile keyboard is enough of a hurdle; the software shouldn't add to it.
Subagent Transparency: Instead of opaque "tool calls," subagents now report their identity and current task status directly in the timeline. If I can't see what a subagent is doing, I'm inclined to assume it's stuck. Surfacing that intent turns a mysterious "hang" into a visible, productive task.

Better in-line support for OpenCode subagents.

Where This Is Going

I am really interested in personal software right now. I am contributing small changes back to Paseo's main branch when appropriate, but I would not be surprised if my fork keeps diverging. That is kind of the point. I am trying to make it work for me and my workflows.

Gemini CLI integration is probably next. I am also interested in usage tracking across providers. I want Paseo to become a sort of home base for my available usage, active projects, and the agents I can point at them. A control plane for my agents and projects.

Open source plus coding agents made the gap between "this tool is close" and "this tool fits me" much smaller. Open source software has always invited tinkering. AI agents make the tinkering cheaper.

And now, apparently, some of that tinkering can happen from my phone. Which is either very cool or a sign I should touch grass.

How are you managing git & gh access with Agents?

Ryan Swift — Sun, 26 Apr 2026 20:40:27 +0000

TLDR - I want to steal your Git workflows for agents. I talk about some of my config and setup recently, but I'm still not fully happy with where I'm at.

My setup was treating "AI Agent" and "Me" at the same level of trust. Local tools can push code, create PRs, and act as me on GitHub with almost no friction. That's starting to feel sketchy, and I don't want to waste maintainers' time with slop PRs.

I've had pretty persistent imposter syndrome as a developer. At work I've managed our internal ERP (Zoho Creator if you're curious) for years, which has tens of thousands of lines of code at this point. But I've never quite felt like I do 'real' dev work.

I've helped thousands of next-gen devs with their projects at hackathons. I am pretty good at fixing folks' Git issues in the wild. Historically though, Git was not a tool I needed heavily day to day. That's been changing recently with AI coding agents.

Recently, I embarrassed myself with a few slop PRs opened without human review. I didn't realize what my agents were doing with my GitHub identity, which is the actual problem. Nothing catastrophic, but I don't want a reputation and I don't want to bug maintainers.

Ambient Authority

Most AI agents just "ambiently" inherit your authority. They use your SSH agent, your gh tokens, and your Git identity/config.

For local edits and personal projects, that's great. For open source and published repos, it's dangerous. Agents had the same level of access that I had as a human user.

I had one too many slop PRs out there in my name, and wanted to update my workflow.

Current Setup

Action Split: I forced all pushes to a passphrase-protected SSH key while keeping other actions like fetches on HTTPS. This means pulls are silent and low-friction, but pushes should hit both a human confirmation step and the passphrase-protected SSH key.
SSH Passphrase: I created a dedicated key for GitHub and told SSH not to use my running SSH agent for that key (IdentityAgent none). It's intentionally inconvenient; every push requires a passphrase.
Read-Only CLI: I swapped my main gh CLI auth for a Fine-Grained Token that is strictly read-only. Agents can see PR status, but gh pr create now fails server-side.
A Pre-Push Hook: More on this below since it's the piece I'm most chuffed with!

The Read-Only CLI is suddenly the most inconvenient part of my workflow right now. If anyone has advice on better controlling gh CLI, I'd love to hear about it.

What I really want is a way to let agents inspect issues, PRs, checks, and reviews, while requiring human confirmation for anything that writes to GitHub.

Pre-Push Hook

I wrote a global Git hook that intercepts pushes, checks for a graphical session, and gets explicit approval from the user.

Instead of a generic passphrase prompt, I get a popup that shows me a summary of what is being pushed and where. If an agent tries to push in the background, it hits both the confirmation dialog and the SSH passphrase prompt.

If you're on Linux (KDE), you can use this. If you're on GNOME, just swap kdialog for zenity. I would still read the hook first unless you trust my agents.

The Hook (~/.config/git/hooks/pre-push):

#!/usr/bin/env bash
set -euo pipefail

remote_name=${1:-unknown}
remote_url=${2:-unknown}
repo_path=$(git rev-parse --show-toplevel 2>/dev/null || pwd)
branch=$(git branch --show-current 2>/dev/null || true)
zero=0000000000000000000000000000000000000000

# Capture the refs being pushed
updates_file=$(mktemp)
trap 'rm -f "$updates_file"' EXIT
cat >"$updates_file"

# Generate a short summary of the ref updates and new commits
summary=$(while read -r local_ref local_oid remote_ref remote_oid; do
  if [ "$local_oid" = "$zero" ]; then
    printf -- '- Delete %s\n' "$remote_ref"
  elif [ "${remote_oid:-}" = "$zero" ]; then
    printf -- '- Create %s\n' "$remote_ref"
    git log --format='  - %s' -n 5 "$local_oid" 2>/dev/null || true
  else
    printf -- '- Update %s\n' "$remote_ref"
    git log --format='  - %s' -n 5 "$remote_oid..$local_oid" 2>/dev/null || true
  fi
done <"$updates_file" | awk '!seen[$0]++')

message=$(cat <<EOF
Git push requested from $repo_path

Branch: ${branch:-detached HEAD}
Remote: $remote_name ($remote_url)

Summary of push:
${summary:-No ref updates found}

Allow this push?
EOF
)

# 1. Try KDE Popup
if [ -n "${WAYLAND_DISPLAY:-}${DISPLAY:-}" ] && command -v kdialog >/dev/null 2>&1; then
  if kdialog --title "Git Push Confirmation" --warningcontinuecancel "$message"; then
    exit 0
  fi
  exit 1
fi

# 2. Fallback to Terminal
if [ -r /dev/tty ] && [ -w /dev/tty ]; then
  printf '%s\n\nType '\''push'\'' to continue: ' "$message" >/dev/tty
  read -r answer </dev/tty
  [ "$answer" = "push" ] && exit 0
fi

# 3. Fail closed if non-interactive
echo "Push blocked: No human confirmation available." >&2
exit 1

To make this work across every project on your machine, just run:

git config --global core.hooksPath ~/.config/git/hooks

This is not a security boundary. A process running as me can bypass hooks with --no-verify or modify my Git config. I'm treating this as a safety check: it catches accidental or low-effort agent actions during normal pushes, but I still rely on GitHub permissions and branch protection for anything important.

How are you handling Git access and authorship?

I'm spending a couple of cycles thinking about the "process" of coding right now. I am trying to build a more robust setup for my own projects. This Git hangup is part of that, but it still doesn't feel solved. Do you have a better setup? Let me steal it please!

Taming MCPs, Skills, and Agent Chaos with ToolHive

Ryan Swift — Sat, 25 Apr 2026 21:01:12 +0000

I use a lot of AI coding tools: OpenCode, Antigravity, Claude Code, Codex, Gemini CLI, Pi, Zed, GitHub Copilot, and probably others too. I'm having a ton of fun vibe coding and learning each of these systems. But ultimately, I need to understand these tools because my job is helping developers make sense of this stuff.

I'm lucky to have a (reasonably) unlimited AI budget. But managing what feels like 30 different tools has become a pain. Every tool wants its own config, MCP setup, skills folder, auth, etc.

Trying every AI dev tool has stopped feeling like product research and started feeling like I'm torturing a tiny fleet of confused robots.

A dream of consistency

I am painfully organized at times. My sprawling collection of agents feels out of hand. It is not strictly difficult to reconfigure an MCP server or drop in a skill I need, but I find myself wanting a more consistent experience across every tool.

If I (read: my agents) create a skill, I do not want to copy it into six different folders. This has been the real pain point for me:

AI tool sprawl is the new dotfile hell.

What I tried (today)

I've bumped into the Stacklok/ToolHive folks at a couple of conferences and finally had time to try out their project today. Initial thoughts are pretty positive.

I ended up using their CLI and desktop app, ToolHive Studio. My hope was that ToolHive could become the control plane for running MCPs, storing auth, and distributing skills. Most importantly, I wanted one command that could register an MCP or skill across all of my coding agents.

It mostly worked!

There was still plenty of configuration and testing to do, but I am pretty happy with where I landed. I have the start of a governable setup that works across my agents.

I ran into a Podman configuration issue with their official package. Skills are still a beta/alpha feature and needed to be enabled to be used inside Studio. Their built-in playground worked well for testing.

Takeaways

If you're using one AI coding tool, config is an annoying chore. The agent can probably configure itself.

When you're using ten coding tools, config is a nightmare.

ToolHive made my system governable and solved a real problem for me right now. I needed a control plane. Not perfect, but useful in exactly the way I needed: one place to make the growing pile of AI tools behave like an environment instead of a junk drawer.

3 Takeaways from All Things AI: 80/20 Rule, Non-Deterministic Humans, and Why We're Still Early

Ryan Swift — Wed, 01 Apr 2026 12:44:00 +0000

Last week, I attended All Things AI in Durham, NC. The event was geared toward technical AI practitioners with workshops on Day 1 and standard conference talks on Day 2. A few takeaways from the conference are below for y'all!

MLH AI Roadshow

On Day 1, I helped Major League Hacking (MLH) run an AI Roadshow. We're hosting about one of these a month right now. Some are standalone events. Others have been at partner conferences. I think you'll see us again at All Things Open in the fall.

At the AI Roadshow, we run ~6 practical, hands-on-keyboard activities. You walk up and use a ready-to-go laptop to learn a new skill or technique with AI. We typically have snacks, drinks, and networking throughout the events. If you want to keep an eye on the next stop, check out our Luma.

The 80/20 Rule in Practice

(Inspired by Justin Jeffress: Vibe Coding in Action)

I enjoyed Justin's whole talk, but he had a specific slide on the 80/20 rule that is still sticking with me. AI feels really good at getting you 80% of the way there on most problems.

What do you do with that remaining 20%, though? Justin's advice was to simply repeat. Send the "remaining" 20% back to your AI tool of choice.

I've been doing this myself for a while with coding agents, but this talk has me thinking again about the effectiveness of simple loops and repetition. I imagine this advice hasn't penetrated to folks who mostly use AI through chat applications. It might also not work as well for outcomes that can't be tested. But the framing really resonated with me.

Humans Are Also Non-Deterministic

(Inspired by Calvin Hendryx-Parker: Orchestrate Agentic AI)

Through my work at MLH, I'm constantly talking to software developers. The last ~18 months have been even more intense, driven by all the AI development.

A common concern I haven't felt ready to address is that AI tools are non-deterministic. I get it. When you're writing code, you're building for specific outcomes. I think devs like the certainty.

Calvin made a small comment during his talk, reminding the audience that humans are also non-deterministic. The observation really hit home. I knew this. I'm sure you know it, too. But it was a good reframe. Process-driven thinking and guardrails feel suddenly important.

We're Still So So Early

(Just a personal reflection)

Like many of you, I've been following AI heavily recently. It's been important for the work I'm doing at MLH. It's so easy to get caught up in the fad-of-the-week on Twitter. But the reality is that most people still aren't leveraging AI tools. Especially not to their maximum capabilities.

Even at a conference for AI practitioners, I met people who hadn't used a coding agent. There were jokes about OpenClaw and Mac Minis, but not everyone was "in the know".

We're still so damn early in this wave of change. No time like the present to roll up your sleeves and give something a try yourself. I still think learning by doing is the right methodology with AI tools.

Happy hacking!

SaaS Companies Fear Me: Cloning* Granola for Linux

Ryan Swift — Tue, 03 Mar 2026 21:23:35 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

I've been spending a lot of time on Twitter recently because it seems to be one of the best places to get AI news. A really common refrain I see on Twitter is about how the "end" of SaaS (Software as a Service) companies is approaching now that vibe coding enables folks to just build their own customized SaaS tools. I don't know that I fully agree with that take, but I suppose I am the hypothetical person in those tweets. There was a SaaS tool I loved that I couldn't use on Linux, so I just built my own (albeit notably worse) version of it.

I, unfortunately, find myself in back-to-back meetings most days. I've played around with a few different note-taking tools. About half a year ago, I discovered Granola. I really really really liked it. It did transcriptions. It enhanced your existing notes. I could run it without inviting another note taker to the meeting. It had a nice little chat interface where I could ask questions about my meetings. 10/10 would (and still do) recommend.

A month or so after discovering Granola, I decided I wanted to switch back to using Linux as my primary OS though. Windows was an uphill battle with CLI coding tools like Gemini CLI, OpenCode, and Claude Code (at least in my experience at the time).

Unfortunately, Granola didn't support Linux and didn't have plans on adding support for it (I did ask).

So, I built Quinoa. A note-taking tool for me.

What I Learned

I think it's very important to call out again this is a tool for me. While I do have the code up on GitHub, I regularly tell my coding agents that they're building for me. My systems. My configs. My preferences. I've had a few design choices where a coding agent raises a concern that might impact other users, but I have very intentionally been designing this tool for myself. This has been a big learning for me in this project.

Coding agents allow us to will software into existence in a way we couldn't a few years ago. It feels like it's okay to be a bit less intentional about certain things. It's okay to build stuff just for you and just for your friends. Not every project needs to be perfectly engineered. If you hit a bug, you can just ask an agent to resolve it.

I made Quinoa almost exclusively using Gemini CLI and OpenCode (using Google, Anthropic, OpenAI, and a bunch of other models). I'm sure some folks will cringe at this, but I try not to write any code myself for this project. That does absolutely lead to some mistakes, but it's been a great way to learn how to harness and direct coding agents. Most of my code review is fully agent-driven as well.

What I Built with Google Gemini

Quinoa itself fully uses Google Gemini models under the hood. I deliberately used it as a project to experiment with new Gemini releases.

The Gemini API handles all of the following.

Meeting transcription. Gemini handles identifying folks' names and labeling them for the transcript. Audio understanding docs are here.

Meeting summaries. Two- to three-sentence summaries of what happened and action item extractions.

Notes enhancement. Takes my notes from the app and then enhances them with additional context and information from the audio recording and transcript.

RAG notes search. This was a huge time saver for me. Google literally has RAG as a service. Allows me to search notes and cites where it's pulling information from. Drop-in API that did exactly what I needed to do. File search docs are here.

I also used Nano Banana to make my project's icon too :)

Demo

My note-taker is a local application, so I can't embed a demo for y'all. Here's a sample screenshot of the app though. I'm clearly not a designer.

Google Gemini Feedback

The biggest issue across all coding agents currently seems to be getting the right context, especially if you're building tools that use new libraries. Google Gemini struggles to implement itself sometimes. I heavily recommend using the Gemini API Dev skill if you haven't tried it out yet.

Just wanted to quickly mention that I'm not entering this contest to win. I am pretty sure I'm ineligible since I work for MLH, but wanted to share something I've been working on!