DevHQ

Developers need to manage multiple tasks in parallel now. The IDEs are not built to handle constant context switching. We need a single-pane-of-glass to supervise parallel work. We need DevHQ!

Comment

Inspiration

Development work is not linear, you jump from a heads-down task to help a colleague, to review a teammates code. This was manageable when coding moved slow. With AI agents, not only the work is moving a lot faster, you are expected to do more things in parallel. Net result is a lot of constant context switching. As I was struggling with keeping tabs on all the codex-cli sessions and git branches getting lost behind tmux sessions, or cmux sessions, I realized that the key is not to manage agents, but to manage work. Standardizing on git worktrees to manage open streams of work allowed me to easily table a pet project and come back to it a week or even a month later.

Even with git worktrees, it was still a struggle to see all my open work streams. Things were spread across terminals, IDEs, and web-based review systems. I wanted a single-pane-of-glass to see all my in-flight work at a glance and switch context seamlessly.

What it does

DevHQ aims to be that single-pane-of-glass for a Developer. A single place to visually see all your in-flight work: Git worktrees, active agent sessions, generated code etc. It allows you to organize your work with worktrees (local or remote), start sticky agents in them. Eventually, it will also allow you to provide local review feedback to your agents and pull in incoming code reviews from github/gitlab.

You bring your own agent CLIs with DevHQ not dictating your harness or the platform. The only requirement is that you need to have a terminal-based agent.

How we built it

This is the second implementation of DevHQ. I initially prototyped this on top of a minimalist IDE called Lite-XL. The concept worked really well, but the implementation was not as polished for a mass-market adoption. I have rebuilt the editor from scratch using codex-cli this week. Most of the work was done in a single long-running codex thread as the coordinator using subagents (https://github.com/mbhatia/codex-harness) with gpt-5.6-sol-high. The initial terminal implementation was done in a separate thread. libghostty was used to quickly bootstrap basic terminal support.

Most of the flow included either a typed paragraph or a generated Spec based on the previous implementation of DevHQ. Computer-use was used for longer running turns to validate application behavior for a few things. I would have used it more, but ran into token limits. :D

The initial implementation was started using Codex mobile over the weekend as I was traveling. It was very helpful to have Codex take a screenshot of the application as proof of completion to verify that the application was loading and rendering correctly.

Challenges we ran into

  • Getting a good terminal application working with the alternate screen support required a few iterations.
  • Computer-use ran into some issues where it would validate UI using Accessibility framework, instead of screenshots, leading to some errors where the agent would Pass an implementation when the layout drew UI elements out-of-bound.
  • Finding a good cross-platform UI framework that is not JS-based was a challenge. Eventually, I settled for Swift and MacOS only to get native look and feel. Will have to port this to something more universal to add support for Linux.

Accomplishments that we're proud of

I only found out about this build week on Friday, and started working on the application using Codex mobile on Saturday and Sunday while traveling. I had wanted to do this rewrite from scratch for a while and did not think I would be able to pull it off in a few days of part-time coding.

What we learned

  • Using screenshots and computer-use for verification can really push the agent to run autonomously for longer on more complicated tasks and still produce useful work.

What's next for DevHQ

  • Each developer has a unique way of working. I want to allow each dev full customization so they can personalize DevHQ to their liking. A more well-thought out Lua plugin framework will be next to make this a reality.
  • Support for code reviews.
  • Really polishing the UX.
  • Add LSP support.

Built With

Share this project:

Updates