I don't understand how random thoughts on X are front-page news on Hacker News.
If some tech CEO makes a major announcement on X, it's newsworthy and belongs here. Anything else that's actual news is also fair game ... but all other X posts do not belong here!
Karpathy is a notable researcher and broader AI leader. Among many, many other things, he invented the term "vibecoding". He also recently posted his autoresearcher project, which is using a swarm of agents to optimize the LLM training and recently produced a training process that is the fastest to achieve GPT-2-level performance using a very small model.
criteria for hitting HN frontpage is generally whether it is interesting to people. That thought is likely the same thought a bunch of us are having at the moment.
It easily reaches the front-page for people with a following. I don't think many votes are necessary to get to the front page. And when there's some critical insight or leak.
Aside from that I've seen few posts on X that didn't follow the pattern, and were short lived at the top.
> On-Topic: Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity.
You can just downvote anything you don't like and move along.
I appreciate Karpathy for thinking out loud like this. We all feel the shift toward orchestration... just haven't seen a UI that fits yet.
I love seeing people experiment with RTS game UIs as agent orchestration interfaces. Mostly demos so far, but there is a ton of creative potential for orchestration UIs.
The biggest challenge is as LLM costs drop dramatically each year, the number of agents able to be orchestrated grows orders of magnitude. So the UI needs to be able to compress this growing information into something meaningful for effective human steerability. A constant moving target.
What's interesting is that the tooling seems to be moving closer to the metal (CLI, APIs, infrastructure) rather than up toward better visual interfaces.
My bet is that the orchestration infrastructure underneath is more durable than any UI layer. I've been building an orchestration system focused on reusable workflows, observability, and feedback loops because I think it's more valuable right now.
That gives you a chatbox tacked onto an IDE, not exactly an agentic command center. Cursor gets close. But it’s hard to work on multiple things at once, or across multiple codebases.
IMO, the answer is remote container environments like Codespaces, Coder, DevPod, etc. (dev containers)
We are moving into Codespaces now and it basically gives us an isolated full runtime env with Docker-in-Docker running Postgres. Developers had been trying various things to script worktrees, dealing with jank related to copying files into worktrees, managing git commands to orchestrate all of this, and managing port assignments.
Now with dev containers, we get a full end-to-end stack that we start up using Aspire (https://aspire.dev) which is fantastic because it's programmable.
All the ports get automatically routed and proxied and we get a fully functioning, isolated environment per PR; no fiddling with worktrees, easy to share with product team, etc.
A 64GB developer machine can realistically run ~2 of our full stacks (Pg, Elastic, Redis, Hatchet, Temporal, bunch of other supporting services). Frontend repo is 1.5m+ lines of TS (will grind small machines to a halt on this alone). In Codespaces? A developer could realistically work on 10 streams of changes at once and let product teams preview each; no hardware restrictions. No juggling worktrees, branches, git repo state.
I can code from any browser, from my phone, from a MacBook Neo, from a Chromebook. Switching between workstreams? Just switch tabs. Fiddling around with local worktrees for small, toy projects seems fine. But for anything sizable, future seems to be in dev containers.
For now, there's simply no convention or established pattern for this yet. Given that, the speed of change, and the lower barrier of creation now, it's almost always better to create your own for this.
Using someone else’s software in the exploration phase is like chewing someone else’s gum.
I really feel this. Every implementation so far hasn't felt like it reduced the contextual load involved for dealing with multiple agents. Tmux/Cmux is great, but whoever figures this out will probably make it big.
To me this reads like trying to fit a solution we know to a problem we haven't yet defined.
The problem is more around ops / visibility / delegation / orchestration of agents, but the solution is being misslabelled as "IDE" which I feel like is the wrong analogy although the right "in-between" step towards what the next thing will be.
I've been working on something along those lines (multi-agent orchestration IDE) for the last few months as a personal project.
There are also a lot of projects out there approaching this from many different angles.
Curious what features people would like to see in an Agentic IDE? Would you like to instruct multiple agents in real time (like vibe coding on steroids) or dispatch autonomous agents to solve a long-running task? Something else?
Yeah I vibe coded a simple app that takes an org-mode file, renders it as a kanban board, and lets me spin up agents for each task with the prompt in the body in a named tmux session. The frontend gets updated via Claude code hooks when an agent is idle.
I think the key is to combine human and agent task tracking in one pane of glass.
I've been working on re-imagining the useful parts of Antigravity (Agent Manager) into an orchestrator that is tightly coupled with an LLM-optimized spec: https://thinkwright.ai/plexus
It works well enough for my use cases so I don't know what these folks are looking for. I have it configured to run everything in WSL sandbox so the blast radius is limited to the VM w/ the code.
I don't understand how random thoughts on X are front-page news on Hacker News.
If some tech CEO makes a major announcement on X, it's newsworthy and belongs here. Anything else that's actual news is also fair game ... but all other X posts do not belong here!
Karpathy is a notable researcher and broader AI leader. Among many, many other things, he invented the term "vibecoding". He also recently posted his autoresearcher project, which is using a swarm of agents to optimize the LLM training and recently produced a training process that is the fastest to achieve GPT-2-level performance using a very small model.
That's great, he sounds like a great guy ... when he say something newsworthy (on X or anywhere else), it might deserve to be here.
But his random thoughts on X do not.
criteria for hitting HN frontpage is generally whether it is interesting to people. That thought is likely the same thought a bunch of us are having at the moment.
It easily reaches the front-page for people with a following. I don't think many votes are necessary to get to the front page. And when there's some critical insight or leak.
Aside from that I've seen few posts on X that didn't follow the pattern, and were short lived at the top.
> On-Topic: Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity.
You can just downvote anything you don't like and move along.
I think Claude Code and Gemini CLI are pretty great as is for terminal usage.
Why are they great? Because it is simply text that I use to interact with them. That's really simple and powerful.
I don't understand why I can't levitate that simple interface into a web UI inside my phone browser?
It feels like this should be as simple as webmux (tmux on the web). But it feels surprisingly elusive.
I would really like something that is a tiny layer on top of the existing great text chat modes.
That way I could use opencode or Gemini or Claude or whatever is next. The less software the better.
I appreciate Karpathy for thinking out loud like this. We all feel the shift toward orchestration... just haven't seen a UI that fits yet.
I love seeing people experiment with RTS game UIs as agent orchestration interfaces. Mostly demos so far, but there is a ton of creative potential for orchestration UIs.
The biggest challenge is as LLM costs drop dramatically each year, the number of agents able to be orchestrated grows orders of magnitude. So the UI needs to be able to compress this growing information into something meaningful for effective human steerability. A constant moving target.
What's interesting is that the tooling seems to be moving closer to the metal (CLI, APIs, infrastructure) rather than up toward better visual interfaces.
My bet is that the orchestration infrastructure underneath is more durable than any UI layer. I've been building an orchestration system focused on reusable workflows, observability, and feedback loops because I think it's more valuable right now.
VSCode + any LLM plugin solves all the problems for me. Keep it simple.
That gives you a chatbox tacked onto an IDE, not exactly an agentic command center. Cursor gets close. But it’s hard to work on multiple things at once, or across multiple codebases.
IMO, the answer is remote container environments like Codespaces, Coder, DevPod, etc. (dev containers)
We are moving into Codespaces now and it basically gives us an isolated full runtime env with Docker-in-Docker running Postgres. Developers had been trying various things to script worktrees, dealing with jank related to copying files into worktrees, managing git commands to orchestrate all of this, and managing port assignments.
Now with dev containers, we get a full end-to-end stack that we start up using Aspire (https://aspire.dev) which is fantastic because it's programmable.
All the ports get automatically routed and proxied and we get a fully functioning, isolated environment per PR; no fiddling with worktrees, easy to share with product team, etc.
A 64GB developer machine can realistically run ~2 of our full stacks (Pg, Elastic, Redis, Hatchet, Temporal, bunch of other supporting services). Frontend repo is 1.5m+ lines of TS (will grind small machines to a halt on this alone). In Codespaces? A developer could realistically work on 10 streams of changes at once and let product teams preview each; no hardware restrictions. No juggling worktrees, branches, git repo state.
I can code from any browser, from my phone, from a MacBook Neo, from a Chromebook. Switching between workstreams? Just switch tabs. Fiddling around with local worktrees for small, toy projects seems fine. But for anything sizable, future seems to be in dev containers.
For now, there's simply no convention or established pattern for this yet. Given that, the speed of change, and the lower barrier of creation now, it's almost always better to create your own for this.
Using someone else’s software in the exploration phase is like chewing someone else’s gum.
I really feel this. Every implementation so far hasn't felt like it reduced the contextual load involved for dealing with multiple agents. Tmux/Cmux is great, but whoever figures this out will probably make it big.
To me this reads like trying to fit a solution we know to a problem we haven't yet defined.
The problem is more around ops / visibility / delegation / orchestration of agents, but the solution is being misslabelled as "IDE" which I feel like is the wrong analogy although the right "in-between" step towards what the next thing will be.
I've been working on something along those lines (multi-agent orchestration IDE) for the last few months as a personal project.
There are also a lot of projects out there approaching this from many different angles.
Curious what features people would like to see in an Agentic IDE? Would you like to instruct multiple agents in real time (like vibe coding on steroids) or dispatch autonomous agents to solve a long-running task? Something else?
Yeah I vibe coded a simple app that takes an org-mode file, renders it as a kanban board, and lets me spin up agents for each task with the prompt in the body in a named tmux session. The frontend gets updated via Claude code hooks when an agent is idle.
I think the key is to combine human and agent task tracking in one pane of glass.
I've been working on re-imagining the useful parts of Antigravity (Agent Manager) into an orchestrator that is tightly coupled with an LLM-optimized spec: https://thinkwright.ai/plexus
Early days and would appreciate any feedback
The VSCode forks all do too much, Nimbalyst is built from scratch to be a proper agent manager. https://nimbalyst.com/
Intent from augmentcode is trying to be this https://www.augmentcode.com/product/intent
who the hell made that demo video. i want to quickly see how it works not unskippable video of some person blabbering.
they had my attention. now they lost it.
I should probably try cmux+worktrunk again, but agent-of-empires works pretty good so far.
Antigravity is getting there
It works well enough for my use cases so I don't know what these folks are looking for. I have it configured to run everything in WSL sandbox so the blast radius is limited to the VM w/ the code.
maybe he can vibecode one himself. i know i did.