I was already using AI to help with software development. It could work through code and help with individual tasks. The part that kept slowing me down was everything between those tasks.

I tried an early proof of concept while working on another personal software project. I liked how that approach was starting to feel, but I was still copying project context and instructions between conversations, deciding what came next, and keeping the bigger picture straight myself.

The work tracker helped me organize individual tasks. It didn’t remove the handoffs between planning, coding, review, and the next task. I often knew what I wanted to happen next; I just wanted to stop rebuilding the same context to make it happen.

Why AI coding handoffs kept losing context

The information I needed was spread between project files, tracker items, AI conversations, and my memory of what had already happened. A tracker item could describe the task, but the next AI conversation also needed the intended outcome, important constraints, what had already happened, and what should come next. I kept having to assemble that handoff myself.

That early experiment made the potential feel real, but it also made the remaining manual work harder to ignore.

The part I kept doing

Gather context from everywhere

  • Project files
  • Work tracker
  • AI conversations
  • My memory

The direction I wanted

Keep the handoff visible

  • Problem
  • Desired outcome
  • Constraints
  • Current stage and next step
The idea: keep the context for a piece of work together so I can see what comes next. This shows the direction, not a claim that every handoff is automated today.

That gave me a more specific direction for Dev Orchestrator. It’s a local tool I’m building around Projects and Work Items, so the problem, intended outcome, constraints, current stage, and next step have somewhere to live together. The larger idea is to make it easier to move between planning, implementation, and review without starting each handoff from scratch.

I’m not at the point of using it for my everyday development work yet. The proof of concept was encouraging, but it wasn’t the finished system. I think I’m getting close to being able to put more real work through Dev Orchestrator; I still need to find out how well the workflow holds up when I do.

I also want meaningful decisions to stay with me. Making a routine handoff easier is one thing. Quietly treating an AI’s output as permission to merge code is another. The goal is less copying and mental bookkeeping, not less visibility or control.

What Dev Orchestrator looks like today

The screenshot below shows a fictional “Workflow Lab” project and a sample Work Item made for this article. The example is about the same handoff problem that started all this, but the project and its data are made up.

Close-up of a fictional Dev Orchestrator Work Item, showing its problem, desired outcome, acceptance notes, and constraints.
The current local interface, showing fictional data. This close-up focuses on the Work Item details; view the complete screenshot for the rest of the control panel.

This is a look at how I’m trying to keep a piece of work’s context together. It isn’t a demonstration of a finished, automated workflow.

What I want to explore next

The next real test will be running development work through it instead of just building the tool itself. I want to see whether the current approach really makes handoffs easier, where I still end up reaching for the clipboard, and what needs changing once I’m using it for more than a proof of concept.

After that, I’m interested in trying different AI models and providers, including how they fit different kinds of development and review work. I’d like to compare what happens in my own projects and make better decisions about my time and usage limits. Those would be personal experiments, not universal benchmarks.

For now, those are plans. The tool is still in development, and the fictional project in the screenshot isn’t connected to an AI provider or external tracker.

Built for my own workflow

I’m making this for myself. It’s not something I’m ready to hand to other people, and I don’t know whether I’ll ever want to turn it into a public tool. The question I’m trying to answer first is simpler: can I leave a project, come back later, and get moving again without reconstructing everything from conversations and memory?

AI is also part of how I’m building Dev Orchestrator. I’m directing the project and working out the behavior I want, with AI helping implement it. I’d rather be clear about that than pretend I’ve hand-written every line.