Forem: Rob MacDonald

AFK: A Laid-Back Way to Work with AI on Bigger Features

Rob MacDonald — Fri, 16 Jan 2026 19:25:20 +0000

[Originally posted on here. Sharing here for the Dev.to community.]

The speed at which AI coding tools are improving is impossible to ignore. Even Linus Torvalds is having a go! If the creator of Linux is experimenting with AI-assisted coding, if you're not already, it's time to pay attention.

I've been in the software industry for quite a while, and AI tooling has been a genuine game-changer for my productivity over the last couple of years. It's helped me branch out into different languages, ship side projects I'd been meaning to build for years, and explore ideas I wouldn't have tackled alone. My synth-tools project - a browser-based synthesiser - is a good example. Without AI assistance, that would still be on my "one day" list.

But when you start using these tools on larger features, an anti-pattern can emerge.

The Problem: Context Bloat

Long AI chat sessions get messy.

You're building something substantial - a new web app, a major feature, a multi-step refactor. You start prompting. The AI responds. You clarify. It revises, it's going well. You nudge the direction. It adjusts. Five or six exchanges in, the conversation is sprawling. Even with 200,000-token context windows, you can feel it struggling.

The model starts forgetting what you agreed earlier. It contradicts itself. It revisits decisions you already made. The output quality degrades, and you spend more time steering than thinking.

This is context exhaustion. The AI has filled its working memory with false starts, abandoned approaches, and conversational noise. It's become bloated and confused.

Discovering the Ralph Approach

That's when I came across something called the Ralph Wiggum approach - or just "Ralph" for short.

The concept was first articulated by Geoffrey Huntley in late 2025, and it's been gaining traction ever since. Matt Pocock covered it on AI Hero, Ibrahim Pima did a deep dive on DEV Community, and it's showing up in more and more developer conversations.

The idea is named after Ralph Wiggum from The Simpsons - a character who approaches each moment with fresh-eyed obliviousness, unburdened by what came before. In AI terms, that forgetfulness is the feature, not the bug.

Here's the core of it:

Fresh context every iteration - Start each task with a brand-new AI instance
One task at a time - Kanban-style: pick up a ticket, complete it, move on
Memory through files, not conversation - Progress persists via git commits and concisely captured learnings, not chat history.

No more dragging old context forward. No more rescuing the model mid-flight. Each task gets exactly the context it needs, and nothing more.

Two Pillars: Context and Focus

Having been in the industry long enough to see patterns repeat, I immediately saw parallels with good engineering practice.

1. Context Without Bloat

In the Ralph approach, context is something you prepare, not something you accumulate. You don't patch it mid-run. You don't layer requirement on top of requirement until the developer loses the plot - or walks out!

Each iteration starts clean. If the output is off, you adjust the inputs explicitly and run again. That makes failures useful - they tell you something was unclear in the context, not that the AI had a bad day after a long conversation.

2. Focus on One Thing at a Time

The other key is focus. Each task is clearly defined and narrow. Not "build the dashboard" but "design the data model". Not "add auth" but "define the auth flow and constraints".

This dramatically reduces hallucinations and off-topic behaviour. The model has less room to wander because the scope is tight.

If you've ever used Kanban properly, this will feel familiar. One card. One goal. Finish it. Move on. It's not an AI idea - it's a good engineering idea, applied to AI.

Why I Built afk

I read the articles. I tried the pattern manually with shell scripts. It worked well. But it was fiddly. I wanted something that made the Ralph approach enjoyable - a tool that encouraged people to give it a go.

That's why I built afk.

It's a small, tool-agnostic CLI that sits outside any specific AI app. It doesn't care if you're using Claude, Cursor, Codex, or something else... It just runs the pattern.

The workflow is simple:

Step 1: Write a PRD

This is the most important step. Take an hour or two. Write down what you actually want to build - the problem, the constraints, the expected outcomes. This becomes your source of truth. Work with an AI tool to build it. It should be a collaboration between product teams, engineering teams.

# Weather Dashboard

A simple web app showing current weather for a given city.

Users enter a city name and see temperature, conditions, and a 5-day forecast.
Use the OpenWeather API. UI should be clean and mobile-friendly.

Step 2: Import and Generate Tasks

afk import requirements.md

afk uses your AI CLI to analyse the PRD and break it into small, AI-sized tasks. The output goes to .afk/tasks.json.

Step 3: Review the Tasks

This step is critical. Run afk tasks and actually read what it generated. Are the tasks the right size? Do they make sense? Is anything missing or misunderstood?

If the tasks don't look right, you have two options: refine the PRD and re-import, or edit .afk/tasks.json directly. Either way, don't skip this step. The quality of the tasks determines the quality of the output. Garbage in, garbage out.

Step 4: Run the Loop

afk go        # Start the autonomous loop

afk works through the tasks one by one. Each iteration spawns a fresh AI instance with clean context. It implements the task, runs quality gates (lint, test, typecheck), and auto-commits if everything passes. If something fails, it captures learnings and loops.

How Memory Persists

The Ralph approach isn't about starting from nothing each time. It's about starting with the right context. afk maintains memory through:

Git history - Commits from previous iterations
progress.json - Task status and per-task learnings (short-term memory)
AGENTS.md files - Project-wide patterns and conventions (long-term memory)

Crucially, this isn't about piling up endless learnings until they become a novel. It's about keeping AGENTS.md fresh and focused - capturing only the key insights that will help the next iteration succeed. The AI is explicitly instructed to curate, not accumulate.

A Different Kind of Away

The name "afk" isn't just cute - it's the point.

When you step away from keyboard, you're not abandoning the work. You're giving the AI space to operate without your interference. And you're giving yourself space to think strategically - to talk to product, understand the problem properly, or just take a walk.

That separation matters. When you come back, you read the output cold, like a code review. You're less attached to it. You spot gaps faster. Your judgement improves.

The Pace of Change

What's clear right now is that things are moving fast. AI coding tools are evolving by the month, sometimes by the week. What works today might look different tomorrow.

Even Linus Torvalds - not exactly known for jumping on hype trains - is experimenting with vibe coding. As he put it at the Open Source Summit Asia: it's fine for projects that don't really matter. For his guitar pedal visualiser, that's the sweet spot.

The Ralph approach sits somewhere in between pure vibe coding and the traditional interactive chat. It's structured enough for serious work, but hands-off enough to let AI do what it's good at.

Try It Out

afk is still early. I'm pleased with where it is now, but there will be rough edges. That's fine - I'm experimenting in the open and learning as I go.

If this sounds interesting, give it a try:

Install

# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/m0nkmaster/afk/main/scripts/install.sh | bash

# Windows (PowerShell)
irm https://raw.githubusercontent.com/m0nkmaster/afk/main/scripts/install.ps1 | iex

Get Started

Collaborate, speak to people, write a PRD you're happy with.

afk import requirements.md    # Parse your PRD into tasks
afk tasks                     # Review - refine PRD or edit tasks if needed
afk go                        # Start the autonomous loop

Pick something real. Preferably something sizeable. Write clear requirements. Review the tasks - don't skip this. Let it run. Step away.

That's where this approach starts to click.

To find out more and dive into the detail, take a look on GitHub.

Repo: github.com/m0nkmaster/afk

I'd love feedback - especially from people already feeling the limits of chat-based workflows. If something feels awkward, that's useful signal. If something clicks, I want to know why.

Contributions welcome. Stay curious. Embrace the tools.

Global collaboration in Software Engineering

Rob MacDonald — Fri, 14 Mar 2025 10:19:36 +0000

What open source and big tech can teach us

Let me introduce the Synthstrom Deluge - a 'groove box'. It lets musicians create complete electronic music tracks from scratch. Electronic music has become my latest hobby and I love the Deluge, but what makes this device fascinating isn't my obsession with it. Two years ago, Synthstrom made a bold move: they released the device firmware as open source.

Synthstrom Deluge - my new favourite toy

The Deluge’s open source firmware development processes are relaxed by corporate standards. No roadmaps, sprint planning, or formal hierarchies. Just a global group of musicians and programmers working across time zones. This isn't a simple project—it's sophisticated music hardware running complex C & C++ firmware handling audio processing to user interface design. Yet they're shipping features faster than many well-funded tech teams.

In the first year of being open source, there have been three high-quality releases introducing dozens of well-received new features.

This success story illustrates what I want to share about global software development.

Over 25 years, I've seen software development from several angles. From working in a four-person startup to heading up a team of 30+ at Amazon Prime Video. I've led teams across Poland, Slovakia, China, and the UK.

I've contributed to open source projects along the way, and what I've learnt is that the best practices in big-tech and open source are more similar than you think.

My thesis is simple: three fundamental principles drive the success of global collaborative working:

Asynchronous communication first
The importance of quality documentation
A clear customer focus.

These principles sound simple and obvious. But implementing them requires challenging deeply held assumptions about how good software teams work.

Seeing Both Sides

I recently contributed to the Deluge project; adding new features, reviewing pull requests and realised I’m collaborating with developers from New Zealand to New York building complex software at scale, without many of the processes that we expect in our day jobs. No daily stand-ups. No quarterly planning. No ‘management’. But it’s working really well. My GitHub activity shows I’ve collaborated with over ten developers across various time zones in two months.

Thinking back, Amazon's structured corporate processes and open source's volunteer-led approach share similarities in their operations.

Avoid Always-On Communication

Hi! Got a minute? 👋

This is a bug bear of mine. We've replaced the in-person disruption of shoulder-tapping with the digital equivalent scaled x10 using Slack and Teams. The result? Engineers regularly context-switching, the stress of responding to "always-on" availability, and knowledge split across private messages and chat channels. This can work well with a close centrally located team, but it's a weakness at a global scale and during onboarding.

Open source takes a different approach. Most have a chat platform, but these are primarily used for chit-chat. Important communications happen in GitHub issues, discussions, and pull requests. Focused, single-threaded discussions that stay on topic and create a permanent record. No demand for an instant response.

While slower, this communication is more efficient, leading to faster progress. Without the ping-pong of chat messages and impromptu meetings, developers can maintain focus and manage their time. Important decisions get captured rather than buried in message threads. Teams across time zones can contribute equally, rather than being nudged into someone else's "standard" working hours. The playing field is levelled.

I recommend choosing minimal, integrated, async tools and sticking to them. Whether it’s GitHub, Jira, or something else, org-wide adoption and clear usage expectations matter. Amazon mostly uses internal tools - not the most feature-rich but adopted across the company from facilities, HR, to the teams owning the video streaming APIs, all teams use the same tools. And they are integrated into everything.

Knowledge accumulates naturally, becoming more refined and useful over time. Code repositories become not just a collection of code, but a living knowledge base that grows with the project.

This doesn't mean abandoning modern tools or returning to just emails. As leaders, it's about being intentional about team communication.

Intentional Documentation

"Writing is thinking" - this mantra is drilled into every Amazonian. With teams across London and Beijing, I saw its importance. For every significant decision, product or technical, we'd write a two to six-page narrative document. The process was simple but powerful: write a proposal, circulate it for comments, and collect feedback. While we often reviewed these documents in meetings (with the famous 20-minute silent reading starts), being distributed, my teams had little in-office overlap. Alternatively, we ensured every stakeholder provided their comments before the author revised the document. We included a check box for each person to confirm they'd reviewed the document and communicated through annotated comments. This approach means:

Engineers across time zones review proposals at their convenience.
Non-native English speakers have time to process and respond thoughtfully.
Knowledge accumulates into an evolving knowledge base.

It's fascinating how closely this mirrors successful open source projects. In the Deluge project, pull request checks enforce documentation updates. READMEs and Wikis are treated as code and product specifications, not afterthoughts. When I contributed a change recently, much of my PR’s discussion focused on improving documentation rather than implementation.

This documentation-first approach creates a self-sustaining cycle in corporate and open source environments. Knowledge becomes discoverable and persistent, unlike chat tool conversations.

PowerPoint isn't banned at Amazon, but I never wrote a presentation there. Presentations are synchronous and important information comes from discussions. Time is spent on making it look nice. A clear narrative forces precise thinking and a lasting record for revisiting.

Customer Focus is key

Great documentation and async communication are powerful tools. But what motivates people to create and read docs? What drives engineers to write detailed pull requests, hold others accountable, and improve documentation?

In open source, the answer is clear. Contributors join projects like Deluge because they believe in what they're building, and they're often users of the software. Everyone understands why they are there.

When people care about the outcome, traditional management structures become less critical. We see this in successful open source projects; good practices emerge naturally because contributors care.

The open source community has been customer-focused from the start. It’s not just about finding the right tools or processes. The most important thing is that when everyone knows what they are building, why, and for who, collaboration comes for free and location becomes irrelevant.

This understanding is at Amazon’s core and summed up in their most often quoted “Leadership Principle”:

Customer Obsession.

“Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. They obsess over customers.”

This is demonstrated in the PR FAQ (Press Release and Frequently Asked Questions) process, which is a key Amazon document that serves two main purposes: it validates that an idea solves a real customer need and captures the rationale for future reference.

Summing up

Here are my thoughts: whether you’re managing a distributed corporate team or contributing to an open source project, the fundamentals remain the same: prioritise asynchronous communication, insist on quality documentation, and maintain a focus on the customer.

These principles work because they address the core challenges of global collaboration: time zone differences, knowledge sharing, and team alignment. When implemented thoughtfully, they create an environment where location is a non-issue.

Next steps

Here are a few ideas to try out.

Make Async Default
- Keep key information out of chat and in persistent docs.
- Write complete questions instead of "Hi!" or "Got a minute?"
- Make it clear that out-of-hours responses are not expected.
Build a Documentation Culture
- Enforce document updates in pull requests and your definition of done.
- Try a document read meeting instead of a presentation.
- For remote teams, try async document reviews with checkboxes for stakeholders.
Start with the Customer
- Try writing a PR-FAQ document for your next feature.
- Run a “Walk the store” session - get your team using your product.

As leaders, we must model these approaches consistently and set clear expectations. Teams follow your example: if you respect people’s time, favour async communication, prioritise documentation, and demonstrate genuine customer focus, they will too.

Our behaviour shapes how global teams work together.