llm/0c6097e3-bc76-4fbe-ab4f-ceafa2484e5f/batch-5-faa74ef2-1bb3-43ca-9075-cf87c45ff9bd-input.json
The following is content for you to classify. Do not respond to the comments—classify them.
<topics>
1. AI Performance on Greenfield vs. Legacy
Related: Users debate whether agents excel primarily at starting new projects from scratch while struggling to maintain large, complex, or legacy codebases without breaking existing conventions.
2. Context Window Limitations and Management
Related: Discussions focus on token limits (200k), performance degradation as context fills, and strategies like compacting history, using sub-agents, or maintaining summary files to preserve long-term memory.
3. Vibe Coding and Code Quality
Related: The polarization around building apps without reading the code; critics warn of unmaintainable "slop" and technical debt, while proponents value the speed and ability to bypass syntax.
4. Claude Code and Tooling
Related: Specific praise and critique for the Claude Code CLI, its integration with VS Code and Cursor, the use of slash commands, and comparisons to GitHub Copilot's agent mode.
5. Economic Impact on Software Jobs
Related: Existential anxiety regarding the obsolescence of mid-level engineers, the potential "hollowing out" of the middle class, and the shift toward one-person unicorn teams.
6. Prompt Engineering and Configuration
Related: Strategies involving `CLAUDE.md`, `AGENTS.md`, and custom system prompts to teach the AI coding conventions, architecture, and specific skills for better output.
7. Specific Language Capabilities
Related: Anecdotal evidence regarding proficiency in React, Python, and Go versus struggles in C++, Rust, and mobile development (Swift/Kotlin), often tied to training data availability.
8. Engineering vs. Coding
Related: A recurring distinction between "coding" (boilerplate, standard patterns) which AI conquers, and "engineering" (novel logic, complex systems, 3D graphics) where AI supposedly still fails.
9. Security and Trust
Related: Concerns about deploying unaudited AI code, the introduction of vulnerabilities, the risks of giving agents shell access, and the difficulty of verifying AI output.
10. The Skill Issue Argument
Related: Proponents dismiss failures as "skill issues," suggesting frustration stems from poor prompting or adaptability, while skeptics argue the tools are genuinely inconsistent.
11. Cost of AI Development
Related: Analysis of the financial viability of AI coding, including hitting API rate limits, the high cost of Opus 4.5 tokens, and the potential unsustainability of VC-subsidized pricing.
12. Future of Software Products
Related: Predictions that software creation costs will drop to zero, leading to a flood of bespoke personal apps replacing commercial SaaS, but potentially creating a maintenance nightmare.
13. Human-in-the-Loop Workflows
Related: The consensus that AI requires constant human oversight, "tools in a loop," and code review to prevent hallucination loops and ensure functional software.
14. Opus 4.5 vs. Previous Models
Related: Users describe the specific model as a "step change" or "inflection point" compared to Sonnet 3.5 or GPT-4, citing better reasoning and autonomous behavior.
15. Documentation and Specification
Related: The shift from writing code to writing specs; users find that detailed markdown documentation or "plan mode" yields significantly better AI results than vague prompts.
16. AI Hallucinations and Errors
Related: Reports of AI inventing non-existent CLI tools, getting stuck in logical loops, failing at visual UI tasks, and making simple indexing errors.
17. Shift in Developer Role
Related: The idea that developers are evolving into "product managers" or "architects" who direct agents, requiring less syntax proficiency and more systems thinking.
18. Testing and Verification
Related: The reliance on test-driven development (TDD), linters, and compilers to constrain non-deterministic AI output, ensuring generated code actually runs and meets requirements.
19. Local Models vs. Cloud APIs
Related: Discussions on the viability of local models for privacy and cost savings versus the necessity of massive cloud models like Opus for complex reasoning tasks.
20. Societal Implications
Related: Broader philosophical concerns about wealth concentration, the "class war" of automation, environmental impact, and the future of work in a post-code world.
0. Does not fit well in any category
</topics>
<comments_to_classify>
[
{
"id": "46517106",
"text": "It will have to quintuple or more to make business sense for Anthropic. Sure, still cheaper than a full time developer, but don't expect it to stay at $200 for a long time. And then, when you explain to your boss how amazing it is, and can do all this work so easily and quickly, it's when your boss start asking the real question: what am I paying you for?"
}
,
{
"id": "46520640",
"text": "A programmer, if we use US standards is probably $8000 per month. If you can get 30% more value out of that programmer (trust me, its WAY more then 30%), you gained $2400 of value. If you pay $200, $500, $1000 for that, its still a net positive. Ignoring the salary range of a actual senior...\n\nLLMs do not result in bosses firing people, it results in more projects / faster completed projects, what in turn means more $$ for a company."
}
,
{
"id": "46519379",
"text": "More fundamentally: assume a 10 to 30% bump in actual productivity, find a niche (editing software, CRUD frameworks, SharePoint 2.0, stock trading, betting, whatever), and assume you had Anthropics billions or openAIs billions or Microsoft’s billions or Googles billions.\n\nWhy on earth would you be hunting $20 a month subscriptions from random assed people? Peanuts.\n\nLockheed-Martin could be, but isn’t, opening lemonade stands outside their offices… they don’t because of how buying a Ferrari works."
}
,
{
"id": "46533160",
"text": "> Why on earth would you be hunting $20 a month subscriptions from random assed people? Peanuts.\n\nFor the same reason Microsoft never has and never will chase people for pirating home Windows or Office licenses\n\nWhen they hit the workforce, or even better, start a company guess which OS and office suite they'll use? Hint: It's not Linux and Openoffice.\n\nSame with Claude's $20 package. It lets devs use it at home and then compare it to the Copilot shit their company is pushing on them. Maybe they either grumble enough to get a Claude license or they're in a position to make the call.\n\nCheap advertising pretty much.\n\nWorked for me too :) I've paid my own Claude license for over a year at home, grumbled at work and we got a Claude pilot going now - and everyone who's tried it so far isn't going back to Copilot + Sonnet 4.5/GPT5."
}
,
{
"id": "46521621",
"text": "They data farming your intelligence"
}
,
{
"id": "46523925",
"text": "Im not sure about this. What they really need is to get rid of the free tier and widespread adoption. Inference on the $200 plan seems to be profitable right now so they just need more users to amortize training costs."
}
,
{
"id": "46521802",
"text": "All the evidence suggests that inference is quite profitable actually."
}
,
{
"id": "46516553",
"text": "It's $150, not a huge difference but worth noting that it's not the same ast the 20x Max plan."
}
,
{
"id": "46516323",
"text": "Cheaper than hiring another developer, probably. My experience: for a few dollars I was able to extensively refactor a Python codebase in half a day. This otherwise would have taken multiple days of very tedious work."
}
,
{
"id": "46517075",
"text": "And that's what the C-suite wants to know. Prepare yourself to be replaced in the not so distant future. Hope you have a good \"nest\" to support yourself when you're inevitably fired."
}
,
{
"id": "46530181",
"text": "Homey, we're going to be replacing you devs that can't stand to use LLMs lol"
}
,
{
"id": "46520706",
"text": "> Prepare yourself to be replaced in the not so distant future.\n\nIgnoring that this same developer, now has access to a tool, that makes himself a team.\n\nGoing independent was always a issue because being a full stack dev, is hard. With LLMs, you have a entire team behind you for making graphics, code, documents, etc... YOU becomes the manager.\n\nWe will see probably a lot more smaller teams/single devs making bigger projects, until they grow.\n\nThe companies that think they can fire devs, are the same companies that are going to go too far, and burn bridges. Do not forget that a lot of companies are founded on devs leaving a company, and starting out on their own, taking clients with them!\n\nI did that years ago, and it worked for a while but eventually the math does not work out because one guy can only do so much. And when you start hiring, your costs balloon. But with LLMs ... Now your a one man team, ... hiring a second person is not hiring a person to make some graphics or doing more coding. Your hiring another team.\n\nThis is what people do not realize... they look too much upon this as the established order, ignoring what those fired devs now can do!"
}
,
{
"id": "46520851",
"text": "This sounds nice, except for the fact that almost everyone else can do this, too. Or at least try to, resulting in a fast race to the bottom.\n\nDo you really want to be a middle manager to a bunch of text boxes, churning out slop, while they drive up our power bills and slowly terraform the planet?"
}
,
{
"id": "46522240",
"text": "The same way that having motorized farming equipment was a race to the bottom for farmers? Perhaps. Turned out to be a good outcome for most involved.\n\nJust like farmers who couldn't cope with the additional leverage their equipment provided them, devs who can't leverage this technology will have to \"go to the cities\"."
}
,
{
"id": "46527259",
"text": "Please do read up on how farmers are doing with this race to the bottom (it hasn't been pretty). Mega farms are a thing because small farms simply can't compete. Small farmers have gone broke. The parent comment is trying to highlight this.\n\nIf LLM's turn out the way C-Suite hopes. Let me tell you, you will be in a world of pain. Most of you won't be using LLM's to create your own businesses."
}
,
{
"id": "46532322",
"text": "But modern tillage/petrol based farming is an unsustainable aberration. Maybe a good example for this discussion, but in the opposite direction if it is."
}
,
{
"id": "46530199",
"text": "LOL what an argument.\n\nSeeing the replies here it actually doesn't seem like everyone else can do this. Looks like a lot of people really suck at using LLMs to me."
}
,
{
"id": "46531119",
"text": "I'm not saying they can all do it now... but I don't think it's much of a stretch that they can learn it quickly and cheaply."
}
,
{
"id": "46521090",
"text": "> except for the fact that almost everyone else can do this, too. Or at least try to, resulting in a fast race to the bottom.\n\nIronically, that race to the bottom is no different then we already have. Have you already worked for a company before? A lot of software is developed, BADLY. I dare to say that a lot of software that Opus 4.5 generates, is often a higher quality then what i have seen in my 25 year carrier.\n\nThe amount of companies that cheapen out, hiring juniors fresh from school, to work as coding monkies is insane. Then projects have bugs / security issues, with tons of copy/pasted code, or people not knowing a darn thing.\n\nIs that any different then your feared future? I dare to say, that LLms like Opus are frankly better then most juniors. As a junior to do a code review for security issues. Opus literally creates extensive tests, points out issues that you expect from a mid or higher level dev. Of course, you need to know to ask! You are the manager.\n\n> Do you really want to be a middle manager to a bunch of text boxes, churning out slop, while they drive up our power bills and slowly terraform the planet?\n\nFrankly, yes ... If you are a real developer, do you still think development is fun after 10 years, 20 years? Doing the exact same boring work. Reimplementing the 1001 login page, the 101 contact form ... A ton of our work is in reality repeating the same crap over and over again. And if we try to bypass it, we end up tied to tied to those systems / frameworks that often become a block around our necks.\n\nOur industry has a lot of burnout because most tasks may start small but then grow beyond our scope. Todays its ruby on rails programming, then its angular, no wait, react, no wait, Vue, no wait, the new hotness is whatever again.\n\n> slowly terraform the planet?\n\nWell, i am actually making something.\n\nCan you say the same for all the power / gpu draw with bitcoin, Ethereum whatever crap mining. One is productive, a tool with insane potential and usage, the other is a virtual currency where only one is ever popular with limited usage. Yet, it burns just as much for a way more limited return of usability.\n\nThose LLMs that you are so against, make me a ton more productive. You wan to to try out something, but never really wanted to get committed because it was weeks of programming. Well, now you as manager, can get projects done fast. Learn from them way faster then your little fingers ever did."
}
,
{
"id": "46519621",
"text": "Well probably OP won't be affected because management is very pleased with him and his output, why would they fire him? Hire someone who can probably have better output than him for 10% more money or someone who might have the same output for 25% less pay?\n\nYou think any manager in their right mind would take risks like that?\n\nI think the real consequences are that they probably are so pleased with how productive the team is becoming that they will not hire new people or fire the ones who aren't keeping up with the times.\n\nIt's like saying \"wow, our factory just produced 50% more cars this year, time to shut down half the factory to reduce costs!\""
}
,
{
"id": "46520064",
"text": "> You think any manager in their right mind would take risks like that?\n\nYou really underestimate stupidity of your average manager. Two of our top performers left because they were underpaid and the manager (in charge of the comp) never even tried to retain them."
}
,
{
"id": "46521796",
"text": "I bet they weren't as valuable as you think. This is a common issue with certain high performing line delivery employees (particularly those with technical skills, programmers, lawyers, accountants, etc), they always think they are carrying the whole team/company on their shoulders. It almost never turns out to be the case. The machine will keep grinding."
}
,
{
"id": "46520897",
"text": "That's one kind of stupidity. Actually firing the golden goose is one step further"
}
,
{
"id": "46519067",
"text": "You say this like it's some kind of ominous revelation, but that's just how capitalism works? Yeah, prepare for the future. All things are impermanent."
}
,
{
"id": "46519272",
"text": "I suppose as long as either humans are always able to use new tools to create new jobs, or the wealth gets shared in a fully automated society, it won't be ominous. There are other scenarios."
}
,
{
"id": "46522035",
"text": "I think we might make new jobs, but maybe not enough. I'll be pleasantly surprised if we get good at sharing wealth over the next few years. Maybe something like UBI will become so obviously necessary that it becomes politically feasible, I don't know. I suspect we'll probably limp along for awhile in mediocrity. Then we'll die. Same as it ever was. The important thing is to have fun with it."
}
,
{
"id": "46520084",
"text": "> Yeah, prepare for the future.\n\nWell excuse the shit out of my goddamn French, but being comfy for years and suddenly facing literal doom of my profession in a year wasn't on my bingo card.\n\nAnd what do you even mean by \"prepare\"? Shit out a couple of mil out of my ass and invest asap?"
}
,
{
"id": "46522024",
"text": "Sharpen sticks, hoard water maybe? We were always going to die someday, I don't see how this changes things."
}
,
{
"id": "46520419",
"text": ">And what do you even mean by \"prepare\"?\n\nNot the person you're responding to but... if you think it's a horse -> car change (and, to stretch the metaphor, if you think you're in the business of building stables) then preparation means train in another profession.\n\nIf you think it's a hand tools -> power tools change, learn how to use the new tools so you don't get left behind.\n\nMy opinion is it's a hand -> power tools change, and that LLMs give me the power to solve more problems for clients, and do it faster and more predictably than a client trying to achieve the same with an LLM. I hope I'm right :-)"
}
,
{
"id": "46520468",
"text": "That's a good analogy. I'm on team hand tools to power tools too."
}
,
{
"id": "46521572",
"text": "Why do you suppose that these tools will conveniently stop improving at some point that increases your productivity but are still too much for your clients to use for themselves?"
}
,
{
"id": "46523233",
"text": "Because I've seen how difficult it is to get a client to explain to me what they need their software to do."
}
,
{
"id": "46530183",
"text": "And so the AI will develop the skills to interview the client and determine what they really need. There are textbooks written on how to do this, it's not going to be hard to incorporate into the training."
}
,
{
"id": "46521595",
"text": "Power tools give way to robotics though so it seems small minded to think so small? Have you been following the latest trends though? New models come out all the time so you can't have this tool brand mindset. Keep studying and you'll get there."
}
,
{
"id": "46516262",
"text": "i've never hit a limit with my $200 a month plan"
}
,
{
"id": "46524395",
"text": "Use Claude Code... to do what? There are multiple layers of people involved in the decision process and they only come up with a few ideas every now and then. Nothing I can't handle. AI helps but it doesn't have to be an agent.\n\nI'm not saying there aren't use cases for agents, just that it's normal that most software engineers are sleeping on it."
}
,
{
"id": "46520277",
"text": "> Most software engineers are seriously sleeping on how good LLM agents are right now, especially something like Claude Code.\n\nNobody is sleeping. I'm using LLMs daily to help me in simple coding tasks.\n\nBut really where is the hurry? At this point not a few weeks go by without the next best thing since sliced bread to come out. Why would I bother \"learning\" (and there's really nothing to learn here) some tool/workflow that is already outdated by the time it comes out?\n\n> 2026 is going to be a wake-up call\n\nDo you honestly think a developer not using AI won't be able to adapt to a LLM workflow in, say, 2028 or 2029? It has to be 2026 or... What exactly?\n\nThere is literally no hurry.\n\nYou're using the equivalent of the first portable CD-player in the 80s: it was huge, clunky, had hiccups, had a huge battery attached to it. It was shiny though, for those who find new things shiny. Others are waiting for a portable CD player that is slim, that buffers, that works fine. And you're saying that people won't be able to learn how to put a CD in a slim CD player because they didn't use a clunky one first."
}
,
{
"id": "46520371",
"text": "I think getting proficient at using coding agents effectively takes a few months of practice.\n\nIt's also a skill that compounds over time, so if you have two years of experience with them you'll be able to use them more effectively than someone with two months of experience.\n\nIn that respect, they're just normal technology. A Python programmer with two years of Python experience will be more effective than a programmer with two months of Python."
}
,
{
"id": "46521024",
"text": "\"But really where is the hurry?\" It just depends on why you're programming. For many of us not learning and using up to date products leads to a disadvantage relative to our competition. I personally would very much rather go back to a world without AI, but we're forced to adapt. I didn't like when pagers/cell phones came out either, but it became clear very quickly not having one put me at a disadvantage at work."
}
,
{
"id": "46522191",
"text": "Came across official anthropic repo on gh actions very relevant to what you mentioned. Your idea on scheduled doc updation using llm is brilliant, I’m stealing this idea.\nhttps://github.com/anthropics/claude-code-action"
}
,
{
"id": "46516238",
"text": "Agreed and skills are a huge unlock.\n\ncodex cli even has a skill to create skills; it's super easy to get up to speed with them\n\nhttps://github.com/openai/skills/blob/main/skills/.system/sk..."
}
,
{
"id": "46521437",
"text": "> we have another Claude Code agent that does a full PR review, following a detailed markdown checklist we’ve written for it.\n\n(if you know) how is that compared to coderabbit? i'm seriously looking for something better rn..."
}
,
{
"id": "46526765",
"text": "Never tried coderabbit, just because this is already good enough with Claude Code. It helped us to catch dozens of important issues we wouldn't have caught.\nWe gave some instructions in the CLAUDE.md doc in the repository - with including a nice personalized roast of the engineer that did the review in the intro and conclusion to make it fun! :)\nBasically, when you do a \"create PR\" from your Claude Code, it will help you getting your Linear ticket (or creating one if missing), ask you some important questions (like: what tests have you done?), create the PR on Github, request the reviewers, and post a \"Auto Review\" message with your credentials. It's not an actual review per se but this is enough for our small team."
}
,
{
"id": "46520608",
"text": "Also new haiku. Not as smart but lighting fast, I've it review code changes impact or if i need a wide but shallow change done I've it scan the files and create a change plan. Saves a lot of time waiting for claude or codex to get their bearing."
}
,
{
"id": "46517143",
"text": "If anyone is excited about, and has experience with this kind of stuff, please DM. I have a role open for setting up these kinds of tools and workflows."
}
,
{
"id": "46516373",
"text": "Is Claude \"Code\" anything special,or it's mostly the LLM and other CLIs (e.g. Copilot) also work?"
}
,
{
"id": "46516579",
"text": "I've tried most of the CLI coding tools with the Claude models and I keep coming back to Claude Code. It hits a sweet spot of simple and capable, and right now I'd say it's the best from an \"it just works\" perspective."
}
,
{
"id": "46530307",
"text": "In my experience the CLI tool is part of the secret sauce. I haven't tried switching models per each CLI tool though. I use claude exclusively at work and for personal projects I use claude, codex, gemini."
}
,
{
"id": "46519479",
"text": "It’s mostly the model, Copilot, Claude Code, OpenCode, snake oil like Oh My OpenCode, it’s not huge differences."
}
,
{
"id": "46534338",
"text": "Why do you call Oh My OpenCode snake oil?"
}
]
</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