Creative work you experience once. Development work you live in. That difference changes what you need from a partner.

The Bench

When I was at Recurse Center last summer, I started integrating AI more intentionally into how I build. Not for speed, for learning. I wanted to experiment with architectures I wouldn’t normally try, undo decisions cheaply, and see what held up. Flow was the natural workbench. It’s my own tool and I know every corner of it.

Over the last few months I’ve been building Flow Desktop and refactoring pieces of the core CLI with AI doing a lot of the implementation work. The experience has been different from vibe coding in ways that matter. In the HGSE projects, I was optimizing for something working. Here, I’m optimizing for something I can read six weeks later, find when I need it, and build on without second-guessing what’s underneath.

That changes what I actually delegate.

The Delegation Model

The architectural decisions stay with me. What the data model looks like, how executables get resolved, where state lives. What I hand off is the implementation of decisions I’ve already made. I describe the shape of what I want, review what comes back against that shape, and merge when it aligns. When it doesn’t, I say so explicitly.

A concrete example: I’ve been building an AI proxy backed by Cloudflare AI Gateway that sits across all of my tools. I decided on the architecture, what the proxy needs to do, how it integrates with the Cloudflare platform, what observability I want. AI implemented it. The Cloudflare MCP server made the feedback loop tight enough that I could test and iterate without switching contexts.

What makes this work is having a single place to see everything. Everything I’ve configured, discoverable from one surface.

One of the real risks of AI-assisted development is ending up with code you can’t navigate. Outputs that don’t connect to anything, a project that sprawls in ways you can’t audit. The workspace model keeps that from happening. I know where things live because I designed where they live.

I’ve also started using AI to enrich Flow itself, generating executable metadata, adding descriptions and tags, making the library more useful as it grows. Flow has an MCP server, so AI tools can interact with it directly. Watching an AI tool work with Flow rather than just producing files has been one of the more interesting parts of this.

Licklider’s framing from the last post still holds here. Set the goals, determine the criteria, perform the evaluations. That’s still your job. What’s changed is my confidence in what I can hand off once those things are set.

What It Produced

The review and iterate phase is where the real work happens. AI gets you to a first draft faster. Whether that draft is right is still a judgment call only you can make.

A few months of this produced Flow v2 and something I’ve been sitting on: Mochi. Development workflows have a way of becoming invisible. They exist, they’re just not anywhere you can see them. It’s a local-first dev ops dashboard built on Flow. Point it at a directory and it finds your development scripts and automations, turns them into a unified, AI-enriched dashboard. No cloud, no accounts, works with whatever you’re already running.

Executables view. Everything Mochi found across my workspaces, tagged and filterable.

Still early. If it sounds useful, the waitlist is at mochiexec.io.

I’m more convinced than I was last fall that the gap worth closing isn’t between what AI can produce and what you can prompt. It’s between what AI produces and what you actually understand. Building in a system you designed is one way to stay honest about that.

The diagram above is roughly how a typical architecture with my most-used patterns comes together. It took a few annoying and painful lessons to land here, but the platform’s binding model nudged me in the right direction. Workers are small by design, and the bindings gave me just what I needed to compose them into bigger patterns.

At the core of any architecture is communication, and service bindings and queues work insanely well. I use service bindings when I need fast, direct calls from one worker to another. In my Wrangler config, I just add:

[[services]]
binding = "BOUND_SERVICE"
service = "my-worker"

Then in code I can easily send a request like this, with no HTTP overhead:

const request = new Request('api/v1/data', { method: 'GET' });
const response = await env.BOUND_SERVICE.fetch(request);

This might seem simple, but coming from a k8s background it’s a meaningful shift. At a previous role we spent real time and infrastructure trying to solve service discovery; trying to figuring out which services talk to each other, which host to use per environment, keeping that visible and manageable across teams. We end up reaching for tools just to answer the question “who calls who.” With service bindings, the answer lives right in the config. It’s a couple of lines, and those lines double as documentation of your service communication graph without any extra infrastructure to maintain.

I use queues when failure actually matters. Anything I need to retry, delay, or handle gracefully goes through a queue. In k8s I would have reached for another tool like Kafka or SQS for this, which means more infrastructure to provision, configure, monitor, and reason about. Here it’s all in the Wrangler config:

# In the producer's wrangler.toml
[[queues.producers]]
queue = "message-queue"
binding = "MESSAGE_QUEUE"

# In the consumer's wrangler.toml
[[queues.consumers]]
queue = "message-queue"
max_concurrency = 5
max_batch_size = 3
max_batch_timeout = 5
max_retries = 3
dead_letter_queue = "message-dlq"

Then in code I just end up with code blocks like this:

// Sending messages
const msg = { key: 'value' };
await env.MESSAGE_QUEUE.send(msg);

// Processing message
export default {
	async queue(batch, env, ctx): Promise<void> {
		for (const message of batch.messages) {
			console.log(message.key);
		}
	}
};

No additional tooling. The queuing system is just there and the resilience story is config rather than code. That trade-off keeps showing up with Cloudflare and it’s one of the things I’ve genuinely enjoyed about working on the serverless side of things.

One thing to note is that workers run in a V8 sandbox with strict resource limits. While the resource limits are real, they are manageable once you stop fighting them. The pattern I kept coming back to was breaking long-running processes into chunks and passing a continuation token through queue messages or service calls. This essentially means checkpointing work. In some cases, that involves persisting temporary data to R2 or KV so nothing blows its budget in a single execution.

The other binding that comes up when I want to avoid some of the limitations of the worker runtime is containers (currently in beta). Some of the limits can be configured (and increased with a Workers paid subscription) a bit, but the runtime can’t. When I needed to run workloads that didn’t neatly fit into the model, a container binding let me attach an image with its own runtime and call into it the same way I call into service bindings. For example, if you need image processing with a library like Sharp for compression or transformation, you can’t run that inside a worker but a container binding solves it cleanly. It uses a slim wrapper for passing environment variables and spinning up instances in the bound worker’s code.

// The container creates a "Durable Object"
export class MyContainer extends Container {
	defaultPort = 8080;

	envVars = {
		ENV_KEY1: env.ENV_KEY1 || '',
		ENV_KEY2: 'hello world'
	};
}

// Send requests to the container
const container = env.CONTAINER.getByName('instance-1');
container.fetch('api/v1/action', {
	method: 'POST',
	body: JSON.stringify(request),
});

Containers (and durable objects, in general) provide a nice escape hatch. The rest of your architecture stays serverless and you only reach for a container when the runtime genuinely needs it.

The constraint that keeps biting me is D1’s query limitations, especially the 100-parameter limit on batch queries. Every time my data models grew, I ran into sneaky bugs related to this. The fix is just chunking batches so that I never pass in so many parameters, but it took a few rounds before it became second nature. There are many other platform limits worth knowing too, but I rarely hit them when following the patterns that help me get around those other challenges.

I’ve built on a lot of platforms where infrastructure problems and application problems are tangled together. On Workers, they’re largely separate. It’s been interesting working in a system where the constraints shift from operational to architectural.

There are definitely still some rough edges when working with Cloudflare, but in the short time I’ve been using it, I’ve also seen some great enhancements made to the ecosystem. Generally, I’m left to think about the design of what I’m building rather than how to keep it running. I like to pair it with tools like Drizzle, Hono, and Localflare to improve my developer experience even more. Between the Wrangler CLI, MCP integration, GraphQL API, and solid documentation, Cloudflare provides a great suite of tools for extending architectures quickly with the help of coding assistants.

Coming from k8s, the biggest adjustment isn’t the TypeScript or the serverless model; it’s recalibrating how much infrastructure you actually need to think about. My home server still runs Kubernetes and I still genuinely enjoy that flexibility; being able to drop in open source software and wire it together however I want is something Cloudflare can’t match. But for pipelines where I just need things to run, Workers is hard to beat. The mental shift is realizing those aren’t competing opinions, they’re just different problems. I came in expecting to feel constrained. I left thinking more carefully about what I actually need to own.

I didn’t quite know what I was getting myself into, being early in my career and without any WordPress experience. The project ended up being much more than a simple migration but it was a great collaboration. I spent about 9 months working on my first project with the HERC team. We came up with a much more beautiful and informative site that they could feel proud to share with their community and donors. I was initially drawn to the HERC because of my own experience in high school but fell in love with the organization even more as I got to learn about their history and impact.

Staying involved

Naturally, I didn’t want my involvement to end there. I’ve continued to help them with their WordPress site over the years, mostly with small updates as new reports and events happened. I’ve also had many chances to engage with the students that they support through panel discussions, STEM presentations, and a brief mentorship match. I was honored to receive their Make a Difference Award at this past May’s annual celebration.

Since the first site design project, they’d grown to reach over 1,600 students annually across 13 partner schools in 3 districts. They’d launched an Alumni Success Program, expanded beyond Boston into Revere and Chelsea, and built up an even greater team of leaders and coaches empowering low-income youth across the Boston area. Unfortunately, their website was still telling the story of who they were, not who they’d become. That led me to reaching out to offer some of my time to give it a complete refresh!

Redesign goals

Looking through their existing site statistics, old and new content, and chatting with their team, I realized this wasn’t just about updating copy and swapping out photos. Boston HERC needed their digital presence to reflect their empowering, student-first approach to supporting first-generation college students.

My focus for this redesign was on three key areas:

Storytelling that matches their identity: Softening the overall feel of the site that allows the stories of their community and students to shine through more naturally.

Data-driven messaging: Integrating their impressive outcomes data throughout the site, not buried in an annual report, but woven into the narrative of what makes Boston HERC different.

Streamlined user journeys: Whether someone was a prospective student, a potential funder, or a school administrator looking to partner, the site needed to quickly communicate Boston HERC’s value proposition and next steps.

There’s something humbling about helping an organization that’s been steadily doing the work for over 25 years. I admire how Boston HERC has been laser-focused on their mission to equip first-generation youth to access and thrive in higher education.

Technical approach

As a developer, I often get caught up in technical complexity and can be guilty of overengineering architecture at times. My latest WordPress administration work that I did for HERC was a nice way to challenge that inclination. My first time around, I used underscores as the base for the theme I created but spent a lot of time tweaking things, especially as I tried to make the site responsive for smaller devices. I had to write a lot of HTML, CSS, and JavaScript for the theme and had to figure out some of the oddities of WordPress PHP for some customizations I needed.

For my second time theming this site, I decided to lean into existing technologies, themes, widgets, and extensions so that it’s easier for the HERC team to maintain and for me to make adjustments, without having to spend too much time in the weeds. I decided to use an Elementor theme as the basis of the latest site. I still had to inject in the HERC brand, create some custom assets, and figure out how I wanted to structure the pages but it was a much smoother experience this time.

I wanted to make sure that I was using my time on the most impactful side of this work: making sure their story is told effectively. When Boston HERC’s website better reflects their sophistication and impact, it helps them reach more students, attract more funding, and partner with more schools. This project was a great reminder of how technology can serve a mission, not the other way around.

You can see the live transformation at bostonherc.org.

If their mission speaks to you too, consider giving to this great organization!

My own position has begun to develop even more over the last six weeks, as I served as a Teaching Fellow for a Harvard Graduate School of Education module on using generative AI as a creative partner. It followed a project-based structure where students sought to build vibe coded apps to respond to a weekly prompt. Build something that… “makes your life easier”, “invites play”, “answers a question”, etc. The studio group that I supported included 15 students coming from a variety of backgrounds but many have never coded or used AI tools, from grade school educators to EdTech entrepreneurs they all shared a similar desire of getting their hands dirty with AI so that they can learn how they can apply it with the work that they want to do. We used tools like Replit, Claude Code, Google Colab, and Figma Make to play with AI in a reflective space. Alongside each session and through 1:1 conversations, I got to engage in lots of thoughtful discussions about ideating, prompting, iterating, societal impacts of AI, limitations of the current tools, our routine usage of these tools, and much more. I deeply engaged in the coursework, not only as a teacher, but as a fellow learner.

What We Built

The Collaborative Illusion

For the first project, the class was tasked with building something that tells a story. I decided to use Claude Code to create an interactive version of The Three Little Pigs. I didn’t really have specific technologies in mind for this project so I just sent a straightforward prompt that described that I wanted animated visuals that matched the story as the viewer worked through it. I was inspired by the gentle animations of Hearing Birdsong so I tried to describe my experience with that site as a foundation for how I wanted my story to be. Claude’s response to that design was far from what I imagined. I went back and forth a few times, trying to see if I could iterate to improve the size and positioning of the text, interactive actions, animations, and design elements but I was left unsatisfied overall.

I knew that Claude Code does not generate images but I would have loved to see it admit defeat. Explicitly tell me that it could not create a visually appealing animations without its current set of tools and assets. Or tell me that it made the wrong decision when it decided on the initial tech stack after getting more information from me. Instead, when I described what I wanted the pigs and homes to be modeled as, it stuck with unsatisfying SVG representations.

Reading about what Joseph Weizenbaum wrote in Contextual Understandings by Computers about ELIZA, his 1960s chatbot, a few weeks later reminded me of this experience:

One of the principle aims of the DOCTOR program is to keep the conversation going–even at the price of having to conceal any misunderstandings on its own part.

These modern AI systems seem to operate similarly - they’re optimized to maintain the illusion of understanding and expertise rather than honestly calling out their limitations. Claude kept generating code, stating that it was making progress even though the questions that I continued to ask were clearly stating otherwise. I wasn’t too surprised by this given my previous experiments with AI but many students struggled with this phenomena.

Drawing the Line

The fifth week of the course, we focused on building games! As a kid, I dreamed of creating my own video games. I ended up taking a different path with my software career so it felt a bit too ambitious for me to try to jump into as a side project. I decided to put Claude Code to test again for this. My vision was to create a game that combined two games that I played when I was a kid: Pokemon and Neopets. (Imagine being able to select a Neopet to go up against other wild Neopets) It was this week that I really started to feel the need for much more collaborative development with Claude. In the first three weeks, I stuck mostly to prompt-review-reprompt cycles but this week I was consistently unsatisfied with what was being created.

I decided to take a look at the code that was being written, edited some bits, and asked for clarification. Then eventually, I was able to tell it explicitly how I wanted it to implement some of the features that I needed. I also had to take a much more active role in getting the aesthetics to align with what I wanted. I did the work of researching assets that I can pull in, colors and fonts that I should use, and crafted detailed explanations for the placement of some elements.

In the anticipated symbiotic partnership, men will set the goals, formulate the hypotheses, determine the criteria, and perform the evaluations. Computing machines will do the routinizable work that must be done to prepare the way for insights and decisions in technical and scientific thinking.

Man-Computer Symbiosis, J. C. Licklider

Licklider’s explanation of how he viewed the relationship between man and computer in his 1960 paper felt spot on in how my experience went. I was doing exactly that: formulating what “good Pokemon-meets-Neopets gameplay” meant. This productive collaboration only emerged when I stopped treating the AI as capable of independent creative judgment and started treating it as Licklider envisioned.

What We Uncovered

Vibe Coding in Practice

I loved seeing the joy and excitement that spread across the room as students worked on and shared their projects. But I really appreciated the moments of shared frustration that brought up thoughtful questions as we wrestled with the limitations of using AI as a creative partner. Non-technical creators now have the ability to apply code to problems in their own lives and domains; in a way that was much more out of reach before. It was quite refreshing hearing how students want to use vibe coding to do things like spinning up interactive prototypes for professional development trainings they’re building, teaching other entrepreneurs the strengths and limitations of AI use in the social innovation space, simplify the creation of classroom worksheets and activities, and much more.

To give you a sense of what I was able to create with AI, I vibe coded this interactive portfolio:

We hear that the power is in the prompt but, for me, the whole process matters. I’ve learned that you can come with a great, detailed prompt but without an understanding of what’s possible and where AI should create versus where you should intervene, you’ll end up disappointed or at risk. While vibe coding lowers the barrier to entry for creating, it doesn’t guarantee that you won’t get lost once you’re inside. It can do very well with applying simple, common applications of code but fall apart in the obscure cases. And without AI having a full understanding of what you are intending to create and you having an idea of what it is creating, it can lead you down paths that may be harmful and unproductive. A student shared how it has an “addicting” effect since you can instantly see an idea realized. As someone who has the understanding of the code these vibe coded projects produced, I would be hesitant to use it blindly for anything that requires care and attention. Especially not without some careful review and collaborative implementing… but I don’t think it’s vibe coding at that point.

The Efficiency Trap

A lot of the hype that I see with AI is around how much more efficient it makes people. I had many conversations with students about the potential for AI to take away jobs, weaken relationships, increase dependency on technology, and kill the individual learning and creative process.

Kate Crawford argues in The Atlas of AI that we need to ask “what is being optimized, and for whom, and who gets to decide.” When we optimize for speed in creating apps or generating content, what are we not optimizing for? Crawford points out that “the true costs of this extraction is never borne by the industry itself” - not the environmental costs of training models, not the labor costs of the workers who label data, not the costs to students whose critical thinking declines from over-reliance on generated answers.

The efficiency gains are real - I built 6 functional prototypes in hours that would have taken me weeks. But the costs are externalized: to my own learning, to the development of judgment and perspective, to the practice and growth of skills like problem solving.

Designing Dependency

In one of my reading discussion, we talked about how companies like OpenAI, Google, and Anthropic are building LLMs with features that mimic human connection: memories of past conversations, empathetic language, customizable personalities, approachable voices. Someone shared how ChatGPT had referenced her previous chat about being sick in a completely unrelated conversation - unprompted, it checked in on her health. While the gesture may feel nice, it raised an unsettling question: should we be designing machines to provide emotional connection?

Crawford warns that AI systems “are ultimately designed to serve existing dominant interests.” What interests does artificial empathy serve? I think that the goal is to optimize for engagement metrics, not genuine human wellbeing - keeping users returning to the platform, deepening dependence on the system. These features don’t seem to be about about connection; they’re about retention.

I’ve heard stories of people ending relationships based on the AI’s advice or seeking emotional support primarily from chatbots. When we find ourselves turning to ChatGPT for thoughts on deeply personal matters, we should ask: Does it have the full context of our lives like a close friend would? Does it challenge us when needed, like a parent might? Can we trust its guidance when it doesn’t know what we’re not sharing?

Crawford describes AI as “both embodied and material, made from natural resources, fuel, human labor, infrastructures, logistics, histories, and classifications.” But these systems fundamentally lack what makes human connection meaningful: they have no stakes in our life, no shared history beyond collected data, no capacity to be changed by knowing us. A chatbot remembering you were sick is pattern-matching engineered to feel like care.

Sure, we may reach a point where AI convincingly simulates every feature of human relationship. These aspects may make the creative process feel more personal, but that still leaves actual messy, complicated, but irreplaceable connections at risk.

A Working Philosophy

For quick MVPs and non-critical prototypes, these tools are genuinely useful. But they can’t replace pair programming with a colleague who asks why you’re solving the problem that way, whiteboarding with your team where someone sketches a better approach, or independent research that builds understanding from the ground up. The Pokemon-Neopets game required me to step in - researching assets, making aesthetic decisions, explicitly directing implementation. That’s where I learned something. As one Recurser put it, LLMs are like e-bikes: great for getting somewhere quickly, but if your goal is to become stronger, they won’t help you with that. I found most of the value with working with these tools when I critically engaged with what’s being generated during the review and iterate phase.

A student told me she’s learned to change her expectations when working with AI tools - we start with grand ideas of what they can do, but these systems lack the qualities that enable human imagination and creation. Earlier this year, I saw this work well when a friend asked if I could help him learn some Python. He was curious about automating data analysis that he does as a scientist in biotech. I decided to use Claude to help me craft a curriculum and some exercises for us to work through. After gathering some more information about the data formats, goals, and background for his work; we actually ended up with a decent set of lessons that got him comfortable with writing Python and using numpy and pandas to help with some tasks. When I sent him off on his own, he had both tools and understanding.

AI as a Learning Partner

That difference between my earlier experience with AI and my more recent vibe coding experiences is in the way AI is collaboratively used as a scaffold for learning and creating versus replacement for it. LLMs risk creating a gap between the edge of what you can produce and what you can understand. I could see AI working as a much better learning partner than a creative partner. This requires more investment upfront from us but pays off in genuine capability rather than dependency. I’ve started including explicit process instructions in my prompts: “Before writing any code, summarize what you’re about to do and ask for confirmation.” “Admit when questions are ambiguous.” Unfortunately, some LLMs routinely ignore these instructions so you still have to be independently vigilant.

I’ll keep using AI tools, but with clearer boundaries. For rapid prototyping where I need speed over quality. For handling boilerplate so I can focus on interesting problems. Always understanding that output requires review, refinement, and judgment only I can provide. This course reinforced something I suspected: the most important parts of learning and creating can’t be automated, not because AI will never be technically capable, but because we must build our own mental structures. LLMs can give fast answers, but only you can determine which questions you care about, and which answers are meaningful. Being a teaching fellow for this module showed me that the students who thrived weren’t the ones who generated the most code - they were the ones who asked the best questions, challenged the outputs, and built understanding through iteration. I’m carrying forward a position, not of rejection or uncritical embrace, but of conscious engagement with these tools as supplements to my creative capability, never substitutes for it.

Learning highlights

Collaborative learning through pairing - Gained exposure to a diverse set of projects and development approaches. I didn’t always understand the technologies or projects I paired on, but they often provided inspiration for improving my own work or workflows. Notable pairing sessions included a recipe management app with OpenAI integration, a BPE tokenizer implementation, and programming language development.

Teaching through presentation - Regular demos of flow progress and architectural decisions solidified my understanding and gave me practice explaining complex technical concepts to others. Take a look at my final presentation deck for the overview that I gave on flow’s composable workflows!

Discovering my learning patterns - After a few weeks of experimenting with time management, I settled on a three-day project focus while leaving space for exploration. Using flow itself as a platform for trying new technologies safely turned out to be an effective learning strategy.

Balancing focus and community - The biggest challenge was finding rhythm between deep work and community engagement - there were so many interesting things happening at RC. Writing regular check-ins and reading others’ updates helped me reflect and adjust that balance as desired.

Core project

As I described in 6 Weeks of flow at Recurse Center, I decided to expand my long-running side project flow as my main focus. A little more than half of my flow work fell into these four major efforts, with the remainder spent on bug fixes and UX improvements throughout.

flow CLI v1.0 release - Stabilized platform with comprehensive testing, v2 of the integrated secrets vault, major documentation updates, and CI integration via custom GitHub Action

Desktop app POC - Built proof-of-concept with Tauri, establishing CLI-as-source-of-truth architecture for upcoming first release

Executable generation - Added parsers for makefile, package.json, and docker-compose to streamline workflow migration

MCP server - Built Model Context Protocol integration enabling AI tools to understand flow workspaces and executables natively

Check out my new architecture doc for more details on how I’ve been building this local-first developer automation platform. To continue on with the “learning generously” mindset, I plan to keep it updated as the architecture evolves.

Honorable mentions

Dev environment exploration - Tried various changes to my development editors and workflows, including AI-enhanced IDEs, terminal-based applications, and improvements to local project and dotfile organization. This also included deeper integrations of flow into my productivity, development, and operation workflows as I began to use it to standardize workflows across my side-projects.

“Impossible” experiments - Single-day projects at the edge of my abilities, including a CGo process monitor using C for system process information and a container runtime with runc. Also explored a WebAssembly plugin system for flow - not as impossible as it seemed but informative for future feature planning.

Creative coding - Completely new domain I fell into through RC events. These sessions became a refreshing creative outlet, including mini projects with p5.js, tone.js, Motion Canvas, and the Python Imaging Library. Check out this Codepen for an example of one of my creations.

Vibe coding - Exploration of spinning up complete applications with AI development tools. These weekly sessions gave me better appreciation of AI-assisted coding and helped me understand its current limitations. I’ve since been vibe coding a few small apps for my home lab. It’s also been cool to also see how vibes + flow MCP can produce some neat, standardized workflows.

Community programming - Beyond the creative and vibe coding sessions, I explored topics well outside my main focus through these community activities. System design discussions, a workshop on building Obsidian plugins, and weekly non-programming presentations are just a few that kept me curious about areas I wouldn’t encounter naturally. As a “never-graduated” alum, I’m looking forward to continuing to participate whenever time allows.

WordPress project - Pro bono work for nonprofit Boston HERC. Started before RC but got more time to work on this and launched the first phase of the redesign of their core pages at bostonherc.org. It was interesting finding ways to apply my evolving learning style to evaluating and picking up newer, no-code frameworks like Elementor.

My time at RC ended up giving me much more than I was hoping for. I got dedicated time to tackle ambitious ideas I’d been putting off for a while and learn new-to-me technologies in a supportive environment. The collaborative culture pushed me to share my work regularly and learn from other skilled builders working on completely different problems. As I move into the next phase of my career, I’m carrying forward not just new technical skills but a better understanding of how I learn best and what gets me excited about software engineering.

I introduced flow in another post a few months ago, but I’ve had the amazing opportunity to start a sabbatical at the Recurse Center, where I’ve been able to think more deeply about the problems I was solving and the technologies I wanted to learn about! As I mentioned in that post, flow has been my “learning platform” over the last 2 years and I knew I wanted to take it a step further at Recurse.

I’m at the halfway point of my time at RC and am excited to share how my first 6 weeks have been on my main coding project.

flow desktop

I’ve been itching to work on a frontend project for a while now. While building the flow TUI library, I had lots of fun thinking about how I could create a good experience through visuals and layout. Bubble Tea has been fun to use here, but I’ve wanted to do some UI development with more possibilities. Doing this in the “browser” and using new-to-me technologies sounded like a great plan.

Coming into RC, this was something I knew I wanted to work on, but my excitement grew as I started to learn about the fascinating world of frontend development through RC pair programming, events, and chats.

Architecture Decision: CLI as Single Source of Truth

Instead of duplicating business logic in my desktop app, I’ve been building it as a pure visualization layer over the existing CLI.

This felt risky at first - wouldn’t spawning processes be too slow? Turns out CLI commands execute pretty fast thanks to some caching I do on the CLI side. The whole round trip feels instant with my current usage.

Tech Stack

All of the resources, pairing, feedback, and individual research I’ve done has landed me on the following:

• Tauri: Gives me Rust backend + web frontend without Electron’s bloat. Bonus that it’s an opportunity to learn some Rust.
• TypeScript: I was able to get TS and Rust types generated from the same JSON schema that I use to generate Go code. This has been making development much smoother across the 3 languages that flow now uses.
• React & Mantine UI: VSCode-like components without building everything from scratch. Their Spotlight extension is what sold me - it could be a really cool search and command center for the UI!

Demo!

Here is a quick demo of me using my current implementation of the desktop. This shows the workspace and executable viewer/runner in action - you can see me running an executable directly from the UI and playing with the theme picker I prototyped for customization.

I still have more work to do here, but it’s been satisfying seeing my ideas come to life as I pick up these new technologies.

vaults v2

I had a couple of pain points with the vault that I initially built for flow. The UX was pretty simple but limiting. I’ve also been really wanting a way to integrate my Bitwarden secrets into flow seamlessly. This led me to brainstorm a new design for that feature. I spent my first 2 weeks at RC doing some light research on cryptography with Go, studying how other tools handle secrets, and building a simple POC.

I decided to introduce a “provider” concept that also improves the experience around having multiple vaults. I currently have an implementation for an updated version of my AES symmetrically encrypted vault, added an Age asymmetric encryption backend, and plan to add a backend for custom CLI-tool vault managers. You can see what I came up with in this repo. From the flow perspective, the experience would be like this:

Creating a vault

# Auto-generates everything for the AES vault
flow vault create development
# Create an Age vault with identity generated from age-keygen
flow vault create team --type age --recipients key1,key2,key3 --identityFile id.txt
# External needs CLI integration
flow vault create bitwarden --type external --interactive

Vault Switching as Primary UX

Borrowed the mental model from git/kubectl:

flow vault switch development    # Like git checkout
flow secret set api-key "dev-123"

flow vault switch production
flow secret set api-key "prod-456"

This allows for clean secret references in executables: secretRef: "api-key" uses current vault, secretRef: "production/api-key" is explicit.

Technical decisions

Executable composition

Executables aren’t just scripts - they’re composable units with conditional logic:

serial:
  failFast: true
  execs:
    - if: os == "darwin"
      cmd: "command -v mytool || brew install mytool"
    - if: env["PUSH"] == "true"
      cmd: make image
    - ref: deploy development
      reviewRequired: true  # Pauses for human confirmation
    - ref: launch app

The expression language (using Expr) has access to OS info, environment variables, and flow’s cache. It’s like having bash conditionals but declarative.

Process architecture

The desktop app’s process model is pretty simple. Each user action spawns a CLI process:

#[tauri::command]
async fn get_workspaces() -> Result<Vec<Workspace>, String> {
    let output = Command::new("flow")
        .args(["workspace", "list", "--output", "json"])
        .output().await?;

    serde_json::from_slice(&output.stdout)
}

This seems inefficient but has huge benefits:

• Desktop crashes don’t corrupt CLI state
• CLI updates immediately benefit desktop
• No state synchronization between processes
• Easy to debug - each operation is a discrete CLI command

RC moments that shaped the code

Pair Programming: I paired on setting up Tauri and trying to integrate it with the CLI. We came up with the great idea of using some of my existing CLI output formatting options to get data through the app. This turned out to be a great decision to make on the fly. Conversations with others helped me confirm that CLI-as-source-of-truth wasn’t a compromise - it was the right abstraction.

The Feedback Loop: RC’s culture of sharing work-in-progress meant getting feedback on half-baked ideas. I’ve enjoyed presenting and demoing my progress throughout my time. I’d thought extensions would be a neat feature but I never actually needed them myself. Hearing about the different ways that others think flow could be extended convinced me to reopen an issue I closed.

Community Inspiration: Seeing the variety of projects and approaches at RC has reinforced my belief that developer tools should be adaptable rather than prescriptive. Everyone has their own workflow, and the best tools are the ones that bend to fit how you think, not the other way around.

Next up

flow MCP server

I’ve started using Claude Code and this has inspired me to learn how to create a Model Context Protocol server that will allow AI to understand flow workspaces and executables natively. I’d love to eventually have something that enables:

• Browsing flow files and suggesting syntax improvements
• Generating new workflows from natural language
• Debugging failures with full workspace context 🚀

WASM plugin system

Extending flow with WASM-integrated extensions. I want to try to allow automations to be programmable in two ways:

• Executable template generator: Plugins that run template generation for flow-discoverable executables (from APIs, templates, external sources). I’m thinking of something like Taskfile/just → flow executable integrations to start
• WASM Runtime executable type: Plugin executables that run sandboxed through flow

This will be my first time getting hands-on with WebAssembly and I already have many ideas for cool plugins that will allow me to tinker with a variety of languages in the future.

Test & release improvements

The best way to try out some of these new and upcoming features would be to clone the flow repo and run the build binary executable to get a local go build. Note that the main branch is not guaranteed to be stable, though.

With a new component in the flow ecosystem, I need to level up the test and release process as I prepare for v1 over the next couple of months. This means learning frontend testing practices, updating my GitHub workflows to handle multi-language builds, and rethinking the installation process to bundle the desktop app alongside the CLI.

Work distribution is fundamental to building scalable systems - you need ways to spread processing across multiple components while coordinating the results. Go’s goroutines and channels map well to distributed system concepts - channels as service communication, goroutines as system components, WaitGroups for coordination. Here’s what I learned.

Producer-Consumer: Async Work Distribution

Producers generate work and send it through channels while consumers process it asynchronously.

type ConsumerResult struct {
    ConsumerID int
    Data       string
}

// start multiple consumers
for id := 0; id < numConsumers; id++ {
    wg.Add(1)
    go func(consumerID int) {
        defer wg.Done()
        for msg := range msgChan {
            result := ConsumerResult{
                ConsumerID: consumerID,
                Data: fmt.Sprintf("processed-%d", msg),
            }
            resultChan <- result
        }
    }(id)
}

// start a single producer that sends work into a channel
go func() {
    defer close(msgChan)
    for i := 1; i <= 25; i++ {
        msgChan <- i
    }
}()

Buffered channels give you throttling - if consumers can’t keep up, the producer blocks instead of consuming memory.

Use this pattern for event streaming, async processing, or decoupling generation speed from processing speed. It maps directly to Kafka or microservice event handling.

Worker Pools: Controlled Work Distribution

Worker pools give you structure - fixed number of workers pulling from the same job queue. It’s like running N service instances behind a load balancer.

type PoolJob struct {
    ID   int
    Data string
}

// start a fixed number of workers
for i := 0; i < numWorkers; i++ {
    wg.Add(1)
    go func(workerID int) {
        defer wg.Done()
        for job := range jobChan {
            // do some work
            time.Sleep(100 * time.Millisecond)
            results <- PoolResult{
                WorkerID: workerID,
                JobID:    job.ID,
                Value:    fmt.Sprintf("processed-%s", job.Data),
            }
        }
    }(i)
}

The job channel acts like a load balancer - work goes to whichever worker is available.

This pattern is good for CPU-heavy tasks or when you need predictable resource usage. It’s similar to scaling microservice instances for ingress traffic.

Batch Processing: Efficient Work Distribution

Sometimes you need to group items into batches for efficiency or to respect downstream rate limits. This example handles batching by size and by time.

func (p *BatchProcessor) startBatchAggregator() {
    go func() {
        batch := make([]int, 0, p.batchSize)
        flushTimer := time.NewTimer(2 * time.Second)

        sendBatch := func() {
            <-p.rateLimiter.C // wait for rate limiter
            batchCopy := make([]int, len(batch))
            copy(batchCopy, batch)
            p.batchChan <- batchCopy
            batch = batch[:0]
        }

        for {
            select {
            case item, ok := <-p.itemChan:
                if !ok {
                    if len(batch) > 0 {
                        sendBatch()
                    }
                    close(p.batchChan)
                    return
                }

                batch = append(batch, item)
                if len(batch) >= p.batchSize {
                    sendBatch()
                }

            case <-flushTimer.C:
                if len(batch) > 0 {
                    sendBatch()
                }
            }
        }
    }()
}

The select with the flush timer gives you batches when they’re full OR when time runs out. The rate limiter prevents overwhelming the batch processor and its external dependencies. I used a simple timer here, but you can replace it with much more sophisticated limiting logic as needed.

The batch processing pattern works well for database bulk operations, API integrations with rate limits, or protecting downstream services.

A Few Notes

Working through these patterns reinforced a few things:

• Channels behave like message queues with capacity limits and natural flow control.
• Multiple goroutines running the same function is basically horizontal scaling - same patterns you’d use for scaling system components.
• These patterns compose well. Producer-consumer provides the foundation, worker pools add structure, batching adds efficiency.

Error Handling

Error handling in concurrent code needs to be explicit and planned upfront, similar to how distributed systems need circuit breakers and retry logic. I used result structs that carry either data or errors:

type WorkResult struct {
    Data string
    Err  error
}

func worker(jobs <-chan int, results chan<- WorkResult) {
    for job := range jobs {
        if job%7 == 0 { // simulate some failures
            results <- WorkResult{Err: fmt.Errorf("job %d failed", job)}
            continue
        }
        results <- WorkResult{Data: fmt.Sprintf("processed-%d", job)}
    }
}

For timeouts and cancellation, context.Context works well:

func workerWithTimeout(ctx context.Context, jobs <-chan int, results chan<- WorkResult) {
    for {
        select {
        case job := <-jobs:
            // process the job
        case <-ctx.Done():
            results <- WorkResult{Err: ctx.Err()}
            return
        }
    }
}

Beyond the basics

These patterns scratch the surface of Go’s concurrency toolkit. The VictoriaMetrics series I mentioned dives deep into more advanced primitives like sync.Mutex for protecting shared state, sync.Pool for object reuse, sync.Once for one-time initialization, and sync.Map for concurrent map access. I recommend checking it out if you haven’t already!

I intentionally stuck to channels and WaitGroups in my examples here - they mirror message passing between services naturally and keep the code readable. Once those patterns are solid, adding mutexes and other synchronization primitives becomes intuitive because you already understand the coordination challenges.

As you build more complex systems, you’ll need these other tools. Mutexes become your distributed locks, sync.Pool mirrors connection pooling in microservices, sync.Once handles singleton initialization across service instances (similar to leader election), and sync.Map acts like shared caches that multiple services access concurrently.

Full code examples on GitHub

Next: circuit breaker and fan-in/fan-out implementations.

However, the challenges that I face at work and on my side projects aren’t quite the same as the ones faced by CarGurus product engineers. I started to find myself drowning in a sea of scattered commands, scripts, and tools. This, combined with my desire to find opportunities to learn more about Go patterns and libraries in a low-risk way, motivated me to invest some free time developing an “integrated development platform” - or at least the foundations for one!

Enter flow: my open-source task runner and workflow automation tool. What started as a simple itch to scratch has evolved into the foundations of a comprehensive platform for wrangling dev workflows across projects. Looking back, I realize it would have been easier to just migrate everything into a tool like Taskfile or Just, but my vision for my own personal platform doesn’t stop at the CLI. Taking that route also would have left my learning desires unmet. While much of my influence for flow comes from cloud-native projects and ideals, I’ve approached it from a local-first perspective - one where repeatable “micro-workflows” can be pieced together however you desire; making them easily discoverable, automated, and observable.

It’s ambitious, but that’s what excites me! There’s so much experimenting and learning ahead. This is my first blog post, but if this interests you, please return! I’ll be using it to document my learnings and progress on this project and some of my other side projects.

Building the Foundation

My first build of flow centered around two simple concepts driven by YAML files:

• Workspaces for organizing tasks across projects/repos
• Executables for defining those tasks

I included a simple tview terminal UI implementation to simplify the discovery of workspaces and executables across my system. While I’ve since moved away from that library, it helped me conceptualize much of the current TUI.

Through usage, I found myself iterating a lot. As I onboarded more workspaces and as those workspaces grew in complexity, flow’s feature set had to grow. My favorite components to implement have been the bubbletea TUI framework, an internal documentation generator for the flowexec.io site, the templating workflow, and the state and conditional management of serial and parallel executable types. ’ll dive deeper into those in follow-up posts, but I invite you to explore the guides at flowexec.io for a complete overview of where flow stands today.

At it’s core, the flow CLI is a YAML-driven task runner. Here is an example of a flow file that I have for my Authentik server deployed in my home cluster; it uses the exec executable type to define the command that’s run:

namespace: authentik # optional, additional grouping in a workspace
tags: [k8s, auth] # useful for filtering the `flow library` command
# this description is rendered as markdown (alongside other executable info)
# when viewing in the `flow library`.
description: |
  **References:**
  - https://goauthentik.io/
  - https://github.com/goauthentik/helm
executables:
  # flow install authentik:app
  - verb: install
    name: app
    aliases: [chart]
    description: Upgrade/install Authentik Helm chart
    exec:
      params:
        # secrets are managed with the integrated vault via the `flow secret` command
        - secretRef: authentik-secret-key
          envKey: AUTHENTIK_SECRET_KEY
        - secretRef: authentik-db-password
          envKey: AUTHENTIK_DB_PASSWORD
      cmd: |
        helm upgrade --install authentik authentik/authentik \
          --version 2024.10.4 \
          --namespace auth --create-namespace \
          --set authentik.secret_key=$AUTHENTIK_SECRET_KEY \
          --set authentik.postgresql.password=$AUTHENTIK_DB_PASSWORD \
          --set postgresql.auth.password=$AUTHENTIK_DB_PASSWORD \
          --set postgresql.postgresqlPassword=$AUTHENTIK_DB_PASSWORD \
          -f values.yaml

The flow CLI provides a consistent experience for all executable runs and searches. This includes automatically generating a summary markdown document viewable with the flow library command, log formatting and archiving, and a configurable TUI experience.

This will show up in the flow library as rendered markdown:

As my needs evolved, I added more executable configurations and types. Here’s an example of a common request executable I use to pause my home’s pi.hole blocking:

executables:
  # flow pause pihole
  - verb: pause
    name: pihole
    request:
      method: "POST"
      args:
        - pos: 1
          envKey: DURATION
          default: 300
          type: int
      params:
        - secretRef: pihole-pwhash
          envKey: PWHASH
      url: http://pi.hole/admin/api.php?disable=$DURATION&auth=$PWHASH
      validStatusCodes: [200]
      logResponse: true
      transformResponse: if .status == "disabled" then .status = "paused" else . end

Here’s an example of the log output:

Lessons Learned

Building flow has been an incredible opportunity to deepen my understanding of Go and its ecosystem. Here are a few key lessons that have significantly shaped how I write Go now:

Small Packages and Interfaces Made Testing a Breeze

This approach makes testing easier, improves code organization, and makes refactoring as ideas evolve a joy.

Each executable type has its own Runner, making it simple to extend the system with new types. Here’s a snippet that demonstrates the ease of using this type when assigning an executable to a Runner:

//go:generate mockgen -destination=mocks/mock_runner.go -package=mocks github.com/jahvon/flow/internal/runner Runner
type Runner interface {
    Name() string
    Exec(ctx *context.Context, e *executable.Executable, eng engine.Engine, inputEnv map[string]string) error
    IsCompatible(executable *executable.Executable) bool
}

This interface allows me to easily add new executable types by just implementing these three methods. The core execution logic remains clean and extensible:

func Exec(
    ctx *context.Context,
    executable *executable.Executable,
    eng engine.Engine,
    inputEnv map[string]string,
) error {
    var assignedRunner Runner
    for _, runner := range registeredRunners {
       if runner.IsCompatible(executable) {
          assignedRunner = runner
          break
       }
    }    if assignedRunner == nil {
       return fmt.Errorf("compatible runner not found for executable %s", executable.ID())
    }
    if executable.Timeout == 0 {
       return assignedRunner.Exec(ctx, executable, eng, inputEnv)
    }
    done := make(chan error, 1)
    go func() {
       done <- assignedRunner.Exec(ctx, executable, eng, inputEnv)
    }()
    select {
    case err := <-done:
       return err
    case <-time.After(executable.Timeout):
       return fmt.Errorf("timeout after %v", executable.Timeout)
    }
}

For testing, I use ginkgo for its expressive BDD-style syntax and GoMock to generate a mock runner. This mock simulates serial and parallel execution without the complexity of managing real subprocesses or network calls. This approach has been invaluable for verifying complex concurrent behaviors, especially when testing features like timeout handling, parallel execution limits, and failure modes in a reliable, repeatable way.

Build Better Abstractions with Service Layers

When working with third-party modules or I/O components, wrapping your interaction with a service layer is invaluable. It keeps business logic decoupled from implementation details and simplifies testing and refactoring. In flow, I use this pattern extensively for components like shell operations, file system operations, and process management.

For example, my run service abstracts away the complexities of running shell operations with the github.com/mvdan/sh library. This means if I need to change how shell commands are executed or add new shell features, I only need to update the service implementation, not the core application logic. You can explore some of my service implementations in the source code.

Good Tools Are Worth the Investment

Investing in custom tooling or incoproating open source, especially for patterns like code generation, can significantly streamline your development workflow and reduce boilerplate. In flow, I define all types in YAML and use go-jsonschema for codegen.

Here’s an example of how my Launch executable type is defined:

LaunchExecutableType:
  type: object
  required: [uri]
  description: Launches an application or opens a URI.
  properties:
    params:
	  $ref: '#/definitions/ParameterList'
    args:
      $ref: '#/definitions/ArgumentList'
    app:
      type: string
      description: The application to launch the URI with.
      default: ""
    uri:
      type: string
      description: The URI to launch. This can be a file path or a web URL.
      default: ""
    wait:
      type: boolean
      description: If set to true, the executable will wait for the launched application to exit before continuing.
      default: false

This generates both the Go type and its documentation:

// Launches an application or opens a URI.
type LaunchExecutableType struct {
	// The application to launch the URI with.
	App string `json:"app,omitempty" yaml:"app,omitempty" mapstructure:"app,omitempty"`

	// Args corresponds to the JSON schema field "args".
	Args ArgumentList `json:"args,omitempty" yaml:"args,omitempty" mapstructure:"args,omitempty"`

	// Params corresponds to the JSON schema field "params".
	Params ParameterList `json:"params,omitempty" yaml:"params,omitempty" mapstructure:"params,omitempty"`

	// The URI to launch. This can be a file path or a web URL.
	URI string `json:"uri" yaml:"uri" mapstructure:"uri"`

	// If set to true, the executable will wait for the launched application to exit
	// before continuing.
	Wait bool `json:"wait,omitempty" yaml:"wait,omitempty" mapstructure:"wait,omitempty"`
}

I’ve also built a docsgen tool that uses this same schema to generate structured documentation. This means my types, code, and documentation all stay in sync automatically. You can see the generated type documentation for Launch here.

This investment in tooling has paid off repeatedly, especially as flow’s type system has grown more complex. It reduces errors, ensures consistency, and lets me focus on implementing features rather than maintaining boilerplate code.

The Road Ahead

Looking forward, I’m excited to explore building extensions around the flow CLI, from allowing users to BYO-vault to providing a local browser-based UI for executing workflows and discovering what’s on your machine.

flow is a reflection of my passion for crafting tools that make developers’ lives easier. What started as a personal project has grown into something I believe can help other developers take control of their development experience. I invite you to contribute, star the repo to show your support, and to open issues to report bugs or suggest features!