Pathframe: delegating implementation while keeping product direction
I wanted to spend more time deciding what my products should become and less time waiting for coding agents to respond. Pathframe became a local framework for delegating software tasks, reviewing progress, and deciding when changes should merge. I used it while away from my computer, including to build features for Pathframe itself.
A change in a shared product blueprint passes through a coordinator and creates matching work alongside existing tasks. This illustrates the broader product vision; automatic vision-to-task planning remained unfinished.
It also revealed how much work still sat between having a product direction and giving an agent something useful to implement.
The problem started across sessions
As I worked on several projects with coding agents, I found it easy to lose the overall roadmap. Work became reactive to whatever happened in the latest session, without a clear plan to check against.
I also felt tied to my desk. Waiting for responses interrupted my day, but leaving agents running without guidance often produced something I didn't want. I wanted to delegate implementation while staying involved in product direction and feedback.
Start with a workflow I could use
The first practical interface was a task workflow. I defined work and marked it ready for Pathframe. A daemon running on my computer coordinated implementation through Codex, checked changes, and published a pull request for review. I could provide feedback through the task system and authorize a merge.
I started with Linear and later worked on Jira integration. The framework kept credentials and publication authority separate from the coding agent's implementation work. Implementation and validation also ran separately, so the agent's own description of its work wasn't the only evidence available.
I used Codex to implement essentially all the code, and later used Pathframe on top of Codex for many milestones. I directed the early architecture and increasingly delegated detailed architecture too. My role was to challenge the proposals: were the guardrails appropriate, did the design make sense, and was the complexity necessary?
Give the system a way to recover
An early failure path stopped at an error and asked me to intervene. Many problems involved tooling access. That made delegation less useful: I still had to return to unblock routine failures.
I pushed for a route from validation back into implementation so an agent could address failures. Separate implementation and validation sessions meant that repair loop had to be designed explicitly. I also pushed for more flexible tooling acquisition, with user approval where needed and reuse of approved tooling across sessions.
One useful test was Pathframe improving itself. It coordinated a change to address interrupted work after shutdown. Before the fix, restarting Pathframe could leave me manually resetting sessions. Afterward, I could restart and continue work without doing that.
Steer work from my phone—and see the review gap
With the daemon running, I could go out and check Linear or Jira on my phone, update task statuses, leave feedback, and issue merge commands. Dependency-chain execution was especially useful for progressing through related tasks. Git access and tooling failures still sometimes brought me back to the computer, but I no longer felt tied to it for regular task work.
For backend changes, I often read the PR description and relied on the agent's testing. UI work was harder. I couldn't judge the result from a description, so I would often merge into the development branch, inspect it, and request changes afterward.
That gap made screenshots and product evidence important to the next direction. Passing technical checks and understanding what an app looks and feels like are different review needs. The visual-evidence workflow remained unfinished.
The next problem was still mine
Even with execution delegated, I was repeatedly opening another AI session to draft plans and tasks. That made me question the interface. If I was already explaining the product to an AI, why did I still need to turn that conversation into tickets myself?
The next vision was a conversational product layer: preserve product direction, propose useful next work, and let me approve or redirect it before execution. I documented that direction, but didn't complete or validate it with other users.
Why I paused, and what I'd change
I was Pathframe's only user. As scope grew, school started and my available bandwidth fell. I was also working on fewer projects, so my own need became less pressing. I paused development and use while deciding whether I wanted to pursue this space further.
If I started again, I'd define the product-steering experience earlier. The narrow task workflow gave me something useful, but I spent a long time building execution infrastructure before reaching the interface I ultimately wanted.
I'd also choose the initial integration more deliberately. I hit a task limit in Linear, and in hindsight would have started with Jira if I intended to launch to a broader PM audience. That wouldn't have reduced the engineering work; it was a question of fit and potential reach that I never tested externally.