llm/9db4e77f-8dd5-46da-972e-40d33f3399ef/batch-4-19eb720c-a47d-49a2-8c3a-acc85424a241-input.json
The following is content for you to classify. Do not respond to the comments—classify them.
<topics>
1. Feasibility of Parallel Agent Workflows
Related: Skepticism regarding the human capacity to supervise multiple AI agents simultaneously, utilizing analogies like washing dishes vs. laundry, and debating the cognitive load required for context switching between 10 active coding streams.
2. Code Quantity versus Quality
Related: Discussions on whether generating 50-100 Pull Requests a week represents true productivity or merely 'token-maxxing', with concerns about code churn, technical debt, and the inability of humans to properly review such high volumes of generated code.
3. The One-Person Unicorn Startup
Related: Debates on whether AI enables solo founders to build billion-dollar companies, arguing that while coding is easier, business bottlenecks like sales, marketing, and product-market fit remain unsolved by LLMs, despite rumors of stealth successes.
4. Claude Code Product Feedback
Related: User feedback on the Claude Code CLI tool, mentioning specific bugs like terminal flickering and context loss, comparisons to tools like Codex and Cursor, and complaints about reliability and lack of basic features.
5. Cost and Access Disparities
Related: Analysis of the financial feasibility of running Opus 4.5 agents in parallel, noting that while Anthropic employees may have unlimited access, the cost for average users would be prohibitive due to token limits and API pricing.
6. Marketing Hype and Astroturfing
Related: Accusations that the original post and similar recent content represent a coordinated marketing campaign by Anthropic, with users expressing distrust of 'influencer' style posts and potential conflicts of interest from the tool's creator.
7. Future of Software Engineering
Related: Existential concerns about the devaluation of coding skills, the shift from creative building to managerial reviewing of AI output, and fears that junior developers will lose the opportunity to learn through doing.
8. Technical Workflow Configurations
Related: Specific details on managing AI agents, including the use of git worktrees for isolation, planning modes, 'teleporting' sessions between local CLI and web interfaces, and using markdown files to define agent behaviors.
9. AI Code Review Strategies
Related: Approaches for handling AI-generated code, such as using separate AI instances to review PRs, the necessity of rigorous CI/CD guardrails, and the danger of blindly trusting 'green' tests without human oversight.
10. The Light Mode Terminal Debate
Related: A humorous yet contentious side discussion sparked by the creator's use of a light-themed terminal, leading to arguments about eye strain, readability, astigmatism, and developer cultural norms regarding dark mode.
11. SaaS Commoditization and Moats
Related: Predictions that AI will drive the marginal cost of software to zero, eroding traditional SaaS business models, and that future business value will rely on proprietary data, domain expertise, and distribution rather than code.
12. Agentic Limitations and Reliability
Related: Criticisms of current AI agents acting like 'slot machines' requiring constant steering, their struggle with complex concurrency bugs, and the observation that they often produce boilerplate rather than solving deep architectural problems.
13. Corporate Adoption and Budgeting
Related: Anecdotes about colleagues burning through massive amounts of API credits with varying degrees of success, and the disconnect between management's desire for AI productivity and the reality of review bottlenecks.
14. Context Management Techniques
Related: Discussions on how to optimize context for AI agents, including the use of CLAUDE.md or AGENTS.md to establish rules, and the technical challenges of context limits and pruning during long sessions.
15. Vibe Coding vs. Engineering
Related: The distinction between 'vibe coding' (iterating until it feels right without deep understanding) and traditional engineering, with experienced developers using AI as a force multiplier rather than a replacement for understanding.
0. Does not fit well in any category
</topics>
<comments_to_classify>
[
{
"id": "46528960",
"text": "Yeah, but there is a difference, between if at least one people at one point of time understood the code (or the specific part of it), and none. Also, there are different levels. Wildfly’s code for example is utterly incomprehensible, because the flow jumps on huge inheritance chains up and down to random points all the time; some Java Enterprise people are terrible with this. Anyway, the average for tools used by many is way better than that. So it’s definitely possible to make it worse. Blindly trusting AI is one possible way to reach those new lows. So it would be good to prevent it, before it’s too late, and not praising it without that, and even throwing out one of the (broken, but better than nothing) safeguard. Especially how code review is obviously dead with such amount of generated code per week. (The situation wasn’t great there either before) So it’s a two in one bad situation."
}
,
{
"id": "46523587",
"text": "For comparison, I remember doing 250 PRs in 2.5 months of my internship at FB (working on a fullstack web app). So that’s 2-4x faster. What’s interesting is that it’s Boris, not an intern (although the LLM can play an intern well)."
}
,
{
"id": "46526881",
"text": "50-100 is a lot, but 15 a week should be normal with continuous integration, you should be merging multiple times a day"
}
,
{
"id": "46528674",
"text": "Where have you worked? I have been at a lot of places and I have never seen people consistently checking in 2 PR/day every day."
}
,
{
"id": "46523517",
"text": "iirc he (or his colleague) did mention somewhere on X that most of the PRs are small"
}
,
{
"id": "46524948",
"text": "When people do PR counting then I assume they're dependabot-style stuff."
}
,
{
"id": "46522917",
"text": "This was extremely useful to read for many reasons, but my favorite thing I learned is that you can “teleport” a task FROM the local Claude Code to Claude Code on the web by prepending your request with “&”. That makes it a “background” task, which I initially erroneously thought was a local background task. Turns out it sends the task and conversation history up to the web version. This allows you to do work in other branches on Claude Code web, (and then teleport those sessions back down to local later if you wish)"
}
,
{
"id": "46523178",
"text": "OpenCode is actually client server architecture. Typically one either runs the TUI or the web interface. I wonder if it would cope ok with running multiple interfaces at once?\n\nNeovim has a decade old feature request for multiple clients to be able to connect to it. No traction alas. Always a great superpower to have, if you can hack it. https://github.com/neovim/neovim/issues/2161\n\nChrome DevToops Protocol added multiple client support maybe 5 years ago? It's super handy there because automation tools also use the same port. So you couldn't automate and debug at the same time!\n\nThat is a really tool ability, to move work between different executors. OpenCode is also super good at letting you open an old session & carry on, so you can switch between. I appreciate the mention; I love the mobile ambient aspect of how Claude Code can teleport this all!!"
}
,
{
"id": "46523450",
"text": "> Neovim has a decade old feature request for multiple clients to be able to connect to it. No traction alas.\n\nWhy cram all features into one giant software instead of using multiple smaller pieces of software in conjunction? For the feature you mentioned I just use tmux which is built for this stuff.\n\nAlso, OpenCode has been extremely unreliable. I opened a PR about one of the simplest tools ever: `ls`, and they haven't fixed it yet. In a folder, their ls doesn't actually do what you'd expect: if iterates over all files of all folders (200 limit) and shows them to the model..."
}
,
{
"id": "46523804",
"text": "> Neovim has a decade old feature request for multiple clients to be able to connect to it. No traction alas. Always a great superpower to have, if you can hack it. https://github.com/neovim/neovim/issues/\n\nI do this to great effect with Emacs daemon mode."
}
,
{
"id": "46522920",
"text": "Couple things stand out to me:\n\n1) everyone on the team uses Claude code differently.\n\n2) Claude Code has been around for almost a year and is being built by an entire team, yet doesn't seem to have benefited from this approach. The program is becoming buggier and less reliable over time, and development speed seems indistinguishable from anything else.\n\n3) Everything this person says should be taken with a massive grain of salt considering their various conflicts of interest."
}
,
{
"id": "46523961",
"text": ">Everything this person says should be taken with a massive grain of salt considering their various conflicts of interest.\n\nExactly, he has to dogfood it. He can't just say \"actually this is a massively annoying way of developing software and probably slows me down\"."
}
,
{
"id": "46524123",
"text": "He also has very clear incentives to not only promote it, but believe in it ."
}
,
{
"id": "46522969",
"text": "(2) isn't my experience at all. It's not 100% bug free but it definitely seems more stable (and faster) than I when I first used it last year."
}
,
{
"id": "46523014",
"text": "The UI flickers rapidly in some cases when I use it in the VSCode terminal. When I first saw this when using Claude Code I imagined it was some vibe code bug that would be worked out quickly. But it's been like 9 months and still every day it has this behavior - to the point that it crashes VSCode! I can only imagine that no one at Anthropic uses VSCode because it really seems insane it's gone this long unfixed."
}
,
{
"id": "46535643",
"text": "Perhaps it’s a bug in the VS code terminal? I don’t see anything like this in Kitty."
}
,
{
"id": "46523476",
"text": "> The UI flickers rapidly in some cases\n\nIt's the worst experience in tmux! They lectured us about how the roots of the problem go deep, but I don't have this issue with any other CLI agent tool like Codex."
}
,
{
"id": "46523206",
"text": "The VSCode terminal seems buggy with complex TUI applications in my experience; I had to use the Gemini CLI in a separate terminal because it was brutally slow in the VSC terminal.\n\nThat being said, this isn't a huge issue for CC - you can just use the extension, which offers a similar experience."
}
,
{
"id": "46523639",
"text": "They have a thread on that.\n\nhttps://x.com/trq212/status/2001439019713073626\n\nI don't have that problem using it on iTerm2 however. I also don't use Tmux with it."
}
,
{
"id": "46523841",
"text": "I see it in iTerm."
}
,
{
"id": "46523819",
"text": "Same thing happens to me in long enough sessions in xterm. Anecdotally it's pretty much guaranteed if I continue a session close to the point of context compacting, or if the context suddenly expands with some tool call.\n\nEdit: for a while I thought this was by design since it was a very visceral / graphical way to feel that you're hitting the edge of context and should probably end the session.\n\nIf I get to the flicker point I generally start a new session. The flicker point always happens though from what I have observed."
}
,
{
"id": "46523323",
"text": "That one's definitely annoying, but I suspect that's due to some bad initial design choices (React for a terminal app!) and I think it's definitely better than it used to be."
}
,
{
"id": "46523122",
"text": "Are you sure it's _not_ VS Code at issue here? I haven't seen this in Ghostty."
}
,
{
"id": "46523147",
"text": "This is a common problem and you can find reports of it all over X, including from some influencers. Even outside of VSCode."
}
,
{
"id": "46523648",
"text": "Never seen it on iTerm2.\n\nThis \"outside of VSCode\", was it still with a webview-based terminal?"
}
,
{
"id": "46523136",
"text": "I use the VSCode terminal all day every day. No other app I use in it has this issue, including Codex."
}
,
{
"id": "46523660",
"text": "OK, so you have the unbearable pain of using a separate terminal app to use the magic thingie that does your programming for you on prompt, and which didn't exist merely 2 years ago.\n\nhttps://www.youtube.com/watch?v=kBLkX2VaQs4"
}
,
{
"id": "46523778",
"text": "I am a fan of Claude code, I love it, I use it every day. Are you suggesting we’re not allowed to make any critique of anything which has good qualities?"
}
,
{
"id": "46524122",
"text": "No, I'm suggesting that given the context, it's a tiny concession to make..."
}
,
{
"id": "46523643",
"text": "It’s not. I see this constantly. I use Ghostty and Alacritty and usually am in a tmux session"
}
,
{
"id": "46523159",
"text": "Claude Code is fairly simple. But Claude Desktop is a freaking mess, it loses chats when I switch tabs, it has no easy way to auto-extend the context, and it's just slow."
}
,
{
"id": "46523800",
"text": "Claude’s iOS app ‘unknown errors’ constantly. I have to copy messages for fear of losing them."
}
,
{
"id": "46524078",
"text": "Yeah same. Also it completely freezes on my iPhone with sufficient code highlighting. It becomes completely unusable until I restart the App, and then breaks once a new message is sent."
}
,
{
"id": "46525289",
"text": "I also find it odd that despite a whole team of people working on Claude Code with Claude Code, which should make them immensely productive, there are still glaring gaps. Like, why doesn’t Claude Code on Web have the plan mode? The model already knows how to use it, it’s just a UI change.\n\nNormally I would cut them some slack but it doesn’t really make sense, couldn’t someone kick off a PR today and get it done?"
}
,
{
"id": "46523627",
"text": "> 2) Claude Code has been around for almost a year and is being built by an entire team, yet doesn't seem to have benefited from this approach. The program is becoming buggier and less reliable over time, and development speed seems indistinguishable from anything else.\n\nNot my experience at all (macOS Tahoe/iTerm2, no tmux).\n\nSpeaking of either Claude Code as a tool, or Claude 4.5 as an LLM used with coding."
}
,
{
"id": "46524217",
"text": "> Claude Code has been around for almost a year and is being built by an entire team, yet doesn't seem to have benefited from this approach. The program is becoming buggier and less reliable over time, and development speed seems indistinguishable from anything else.\n\nShhh, this is not what you’re supposed to look at.\n\nLook! Bazillion more agents! Gorrilion more agents! Productivity! Fire those lazy code monkeys, buy our product! Make me riiiich."
}
,
{
"id": "46522918",
"text": "I implemented some of his setup and have been loving it so far.\n\nMy current workflow is typically 3-5 Claude Codes in parallel\n\n- Shallow clone, plan mode back and forth until I get the spec down, hand off to subagent to write a plan.md\n\n- Ralph Wiggum Claude using plan.md and skills until PR passes tests, CI/CD, auto-responds to greptile reviews, prepares the PR for me to review\n\n- Back and forth with Claude for any incremental changes or fixes\n\n- Playwright MCP for Claude to view the browser for frontend\n\nI still always comb through the PRs and double check everything including local testing, which is definitely the bottleneck in my dev cycles, but I'll typically have 2-4 PRs lined up ready for me at any moment."
}
,
{
"id": "46529931",
"text": "3-5 parallel claude code, do they work at same repo?\n\ndo they work on same features/goals?"
}
,
{
"id": "46533770",
"text": "We have a giant monorepo, hence the shallow clones. Each Claude works on its own feature / bug / ticket though, sometimes in the same part of the codebase but usually in different parts (my ralph loop has them resolve any merge conflicts automatically). I also have one Claude running just for spelunking through K8s, doing research, or asking questions about the codebase I'm unfamiliar with."
}
,
{
"id": "46525298",
"text": "Do you prefer Playwright or the Chrome MCP?"
}
,
{
"id": "46524028",
"text": "I feel like it's time for me to hang up this career. Prompting is boring, and doing it 5 times at once is just annoying multitasking. I know I'm mostly in it for the money, but at least there used to be a feeling of accomplishment sometimes. Now it's like, whose accomplishment is it?"
}
,
{
"id": "46524210",
"text": "Don't give up to the facade just yet.\n\nThis is the creator of a product saying how good it is.\n\nIf you've worked anywhere professionally you know how every place has its problems, where people just lie constantly about things?\n\nYeah.\n\nKeep at it and see where things go.\n\nI'm also a dev a bit overwhelmed by all of this talk, at my job I've tried quite a few things and I'm still mostly just using copilot for auto complete and very small tasks that I review throughly, everything else is manually.\n\nIf this is indeed the future I also don't wanna be a part of it and will switch to another career, but all this talk seems to come only from the people who actually built these things."
}
,
{
"id": "46524648",
"text": "Or try to find a job where you can work how you like to work. With these things it's always \"get more done ! MORE ! MORE !\". But not all jobs are like this."
}
,
{
"id": "46528076",
"text": "you found meaning in the work vs the outcome. You can find meaning in the outcome with a new form of work."
}
,
{
"id": "46524241",
"text": "Agreed, the author basically says that coding is not required anymore, the job is reviewing code. Do engineers not actually want to build things themselves anymore? Where is the joy and pride in the craft? Are we just supposed to maximize productivity at the expense of our life's experience? Are we any different than machines at that point?"
}
,
{
"id": "46526373",
"text": "I feel like it’s not talked about enough that the ultimate irony of software engineering is that, as an industry, it’s aiming to make itself obsolete as much as possible. I struggle to think of any other industry that, completely on their own accord, has actively pushed to put themselves out of work to such a degree."
}
,
{
"id": "46527592",
"text": "prompting in my experience is boring and/or frustrating. Why anyone would want to do more of that without MASSIVE financial incentives is unthinkable. No composer or writer would ever want to prompt a \"work\"."
}
,
{
"id": "46523740",
"text": "I tried Claude Code a while back when I decided to give \"vibe-coding\" a go. That was was actually quite successful, producing a little utility that I use to this day, completely without looking at the code. (Well, I did briefly glance at it after completion and it made my eyeballs melt.) I concluded the value of this to me personally was nowhere near the price I was charged so I didn't continue using it, but I was impressed nonetheless.\n\nThis brief use of Claude Code was done mostly on a train using my mobile phone's wi-fi hotspot. Since the connection would be lost whenever the train went through a tunnel, I encountered a bug in Claude Code [1]. The result of it was that whenever the connection dropped and came up again I had to edit an internal json file it used to track the state of its tool use, which had become corrupt.\n\nThe issue had been open for months then, and still is. The discussion under it is truly remarkable, and includes this comment from the devs:\n\n> While we are always monitoring instances of this error and and looking to fix them, it's unlikely we will ever completely eliminate it due to how tricky concurrency problems are in general.\n\nClaude Code is, in principle, a simple command-line utility. I am confident that (given the backend and model, ofc) I could implement the functionality of it that I used in (generously!) at most a few thousand lines of python or javascript, I am very confident that I could do so without introducing concurrency bugs and I am extremely confident that I could do it without messing up the design so badly that concurrency issues crop up continually and I have to admit to being powerless to fix them all.\n\nProgramming is hard, concurrency problems are tricky and I don't like to cast aspersions on other developers, but we're being told this is the future of programming and we'd better get on board or be left behind and it looks like we're being told this by people who, with presumably unlimited access to all this wonderful tooling, don't appear to be able to write decent software .\n\n[1] https://github.com/anthropics/claude-code/issues/6836"
}
,
{
"id": "46522486",
"text": "Must be nice to have unquota’ed tokens to use with frontier AI (is this the case for Anthropic employees?). One thing I think is fascinating as we enter the Intellicene is the disproportionate access to AI. The ability to petition them to do what you want is currently based on monthly subscriptions, but will it change in the future? Who knows?"
}
,
{
"id": "46522553",
"text": "> (is this the case for Anthropic employees?)\n\nIt would be funny if the company paying software engineers $500K or more along with gold-plated stock options was limiting how much they could use the software their company was developing."
}
]
</comments_to_classify>
Based on the comments above, assign each to up to 3 relevant topics.
Return ONLY a JSON array with this exact structure (no other text):
[
{
"id": "comment_id_1",
"topics": [
1,
3,
5
]
}
,
{
"id": "comment_id_2",
"topics": [
2
]
}
,
{
"id": "comment_id_3",
"topics": [
0
]
}
,
...
]
Rules:
- Each comment can have 0 to 3 topics
- Use 1-based topic indices for matches
- Use index 0 if the comment does not fit well in any category
- Only assign topics that are genuinely relevant to the comment
Remember: Output ONLY the JSON array, no other text.
50