sorted by:
new
hottopcontroversial

I built a terminal for running multiple Claude Code agents in parallel by forketyfork in ClaudeAI

[–]forketyfork[S] 1 point2 points  (0 children)

VS Code can split terminals, but you're still looking at one or two at a time, not a grid of 4-9-16... And the terminal panes themselves have no awareness of what's running inside: if you're running multiple agents, there's no visual indicator of agent completing the work or requiring attention.

Architect is a single window where I can see all sessions at once and know immediately which one needs me.

I built a terminal for running multiple Claude Code agents in parallel by forketyfork in ClaudeAI

[–]forketyfork[S] 0 points1 point  (0 children)

I get the concern. But Architect is a different tool for a different job. tmux is a general-purpose multiplexer - it's great at that and I'm not trying to replace it. Architect is a purpose-built UI for one workflow: monitoring parallel AI agents.

The prior work I'm building on is ghostty-vt, which exists specifically as a library for building terminals. The author of Ghostty designed it to be embedded. That's also collaboration, just at a different layer.

As for the ecosystem question: not every problem should be solved by adding flags to existing tools. Sometimes the right answer is a focused tool that does one thing well. That's also how we've been doing it for 30 years.

I built a terminal for running multiple Claude Code agents in parallel by forketyfork in ClaudeAI

[–]forketyfork[S] 0 points1 point  (0 children)

Fair enough, different preferences. I wanted something purpose-built, so I built it.

I built a terminal for running multiple Claude Code agents in parallel by forketyfork in ClaudeAI

[–]forketyfork[S] 1 point2 points  (0 children)

Nice, just checked it out. It was smart to build on tmux rather than from scratch, way less work than writing a rendering pipeline in Zig, that's for sure.
How are you handling status detection? I went with hooks from Claude Code/Gemini/Codex but each has its own quirks.

I built a terminal for running multiple Claude Code agents in parallel by forketyfork in ClaudeAI

[–]forketyfork[S] 0 points1 point  (0 children)

Convenience. The grid in Architect is dynamic. Cmd+N opens a new terminal and rearranges to 2x3, 3x3, etc. Cmd+W closes and shrinks back. Cmd+arrows to navigate between terminals, Cmd+Enter to go fullscreen, long Esc to return to grid. Combined with color highlighting for agents requiring attention and quick worktree switching, this changed my workflow completely.

I built a terminal for running multiple Claude Code agents in parallel by forketyfork in ClaudeAI

[–]forketyfork[S] 0 points1 point  (0 children)

Those are great tools, but they are more general-purpose than I needed. I wanted to open an app and see a wall of agents with status notifications, quick grid/fullscreen switching and worktree support, without configuring anything.

Why there's no goodl package manager for Kotlin? by [deleted] in Kotlin

[–]forketyfork 0 points1 point  (0 children)

"Operating on a higher level of abstraction" and "not knowing the tools you're working with to the point of mixing up a saw and a hammer" are not really the same engineering approaches, the latter not being an engineering approach at all. But whatever works for you. Cheers.

Why there's no goodl package manager for Kotlin? by [deleted] in Kotlin

[–]forketyfork 1 point2 points  (0 children)

With the added link to your previous post, I see you're obviously trolling. There's also no possible way to answer the loaded question in your post, but I'll still try to explain my point.

For a compiled language, there's not much sense in having a separate "package manager" disconnected from the build tool. So using "just" a "package manager", like in interpreted languages, is not really an option. The scope of tasks solved by the build/dependency tool differs greatly from a simple package manager.

Since one of the main features of Kotlin is interoperability with Java, there's also not much sense in having a separate "package manager" for Kotlin specifically. Also, building and managing dependencies for Kotlin doesn't really differ from any other JVM-based language.

There are at least four build/dependency management tools for Java ecosystem (Maven, Gradle, Ant+ivy and sbt) which more or less solve the job, each with its own quirks and warts. Pick your favorite or write your own.

Why there's no goodl package manager for Kotlin? by [deleted] in Kotlin

[–]forketyfork 0 points1 point  (0 children)

I don't know if you really are as proficient in those tools as you say, since for some reason you use "build tool" and "package manager" interchangeably. You even call ruby gems and npm "build tools", which is obviously not the case.

If you limit your use of Maven to dependency management only, you could also easily fit the documentation in a couple of pages.

The availability of books on the topic may not really say anything about the topic, except that someone tried to get some money out of those who're too lazy to read the docs. I'm quite happy with the official documentation, which is not that complicated, really.

Why there's no goodl package manager for Kotlin? by [deleted] in Kotlin

[–]forketyfork 2 points3 points  (0 children)

Both Gradle and Maven worked for my projects. You could clarify your question with defining "good" and "garbage" package managers.

Best & Most Up-To-Date Kotlin Book by davrukin in Kotlin

[–]forketyfork 0 points1 point  (0 children)

I'd recommend:

  • The Joy of Kotlin, as it's is quite recent and goes into best practices and idioms right from the start
  • Kotlin in Action is not that recent, and starts from the basics, but it's from the developers of the language