llm/e6f7e516-f0a0-4424-8f8f-157aae85c74e/batch-2-9cad3fcd-fa13-400c-b4fb-6a9578248643-input.json
The following is content for you to classify. Do not respond to the comments—classify them.
<topics>
1. Reasoning vs. Pattern Matching
Related: Debates on whether LLMs truly think or merely predict tokens based on training data. Includes comparisons to human cognition, the definition of "reasoning" as argument production versus evaluation, and the argument that LLMs are "lobotomized" without external loops or formalization.
2. AI-Assisted Coding Reality
Related: Divergent experiences with tools like Claude Code and Codex. While some report massive productivity boosts and shipping entire features solo, others describe "lazy" AI, subtle logic bugs in generated tests (e.g., SQL query validation), and the danger of unverified code bloat.
3. The AI Economic Bubble
Related: Comparisons to the dot-com crash, with arguments that current valuation relies on "science fiction fantasies" and hype rather than revenue. Counter-arguments suggest the infrastructure (datacenters, GPUs) provides real value similar to the fiber build-out, even if a market correction is imminent.
4. Workforce Displacement and Automation
Related: Fears and anecdotes regarding job security, including a "Staff SWE" preferring AI to coworkers and contractors losing bids to smaller, AI-equipped teams. Discussions cover the automation of "bullshit jobs," the potential for a "winner take all" economy, and management incentives to cut labor costs.
5. Definition of Agentic Success
Related: Disagreement over whether AI "joined the workforce." Some argue failing to replace humans entirely (the "secretary" model) is a failure of 2025 predictions, while others claim deep integration as a tool (automating loops, drafting emails) constitutes a successful, albeit different, type of joining.
6. Verification and Hallucination Risks
Related: The critical need for external validation mechanisms. Commenters note that coding agents succeed because compilers/linters act as truth-checkers, whereas open-ended tasks (spreadsheets, emails) lack rigorous feedback loops, making hallucinations and "truthy" errors dangerous and hard to detect.
7. Impact on Skill and Learning
Related: Concerns about the long-term effects on human expertise. Topics include "skill atrophy" where juniors bypass learning fundamentals, the educational crisis evidenced by Chegg's collapse, and the difficulty of debugging AI code without deep institutional knowledge or "muscle memory" of the system.
8. Corporate Hype vs. Utility
Related: Cynicism toward executive predictions (Altman, Hinton) viewed as efforts to pump stock prices or attract investment. Users contrast "corporate puffery" and "vaporware" with the practical, often mundane utility of AI in specific B2B workflows like insurance claim processing or data extraction.
9. Integration into Legacy Systems
Related: The challenge of applying AI to real-world, messy environments versus greenfield demos. Discussion includes the difficulty of getting agents to work with proprietary codebases, expensive dependencies, lack of documentation for obscure vendor tools, and the failure of browser agents on standard web forms.
10. Formalization of Natural Language
Related: Theoretical discussions on overcoming LLM limitations by mapping natural language to formal logic or proof systems (like Lean). Skeptics argue human language is too "mushy" or context-dependent for this to be a silver bullet for AGI or perfect reasoning.
11. Medical and Specialized Fields
Related: Debates on AI in radiology and medicine. While some see potential in automated reporting and "second opinions" to catch errors, professionals argue that current models struggle with complex cases, over-report issues, and lack the nuance required for high-stakes diagnostics.
12. The Secretary vs. Replacement Model
Related: The shift in expectations from AI as an autonomous employee to AI as a productivity-enhancing assistant. Users describe workflows where humans act as orchestrators or managers of AI output rather than performing the rote work, effectively reviving the role of the personal secretary.
13. Software Engineering Evolution
Related: Predictions that the discipline is shifting from "writing code" to "managing entropy" and system design. Some view this as empowering "cowboy devs" to move fast, while others fear a future of unmaintainable "vibe coded" software that no human fully understands.
14. Productivity Metrics and Paradoxes
Related: Skepticism regarding "2x productivity" claims. Commenters argue that generating more code doesn't equal value, noting that debugging, communicating, and context-gathering are the real bottlenecks, and that AI might simply be increasing the volume of low-quality output or "slop."
0. Does not fit well in any category
</topics>
<comments_to_classify>
[
{
"id": "46511431",
"text": ">They still \"can't\" asses the quality of the output, after all. They can't just ask the model, as they can't know if the answer is not misleading.\n\nWasn't this a problem before AI? If I took a book or online tutorial and followed it, could I be sure it was teaching me the right thing? I would need to make sure I understood it, that it made sense, that it worked when I changed things around, and would need to combine multiple sources. That still needs to be done. You can ask the model, and you'll have the judge the answer, same as if you asked another human. You have to make sure you are in a realm where you are learning, but aren't so far out that you can easily be misled. You do need to test out explanations and seek multiple sources, of which AI is only one.\n\nAn AI can hallucinate and just make things up, but the chance it different sessions with different AIs lead to the same hallucinations that consistently build upon each other is unlikely enough to not be worth worrying about."
}
,
{
"id": "46511665",
"text": "> someone who’s shipped entire new frontend feature sets, while also managing a team. I’ve used LLM to prototype these features rapidly and tear down the barrier to entry on a lot of simple problems that are historically too big to be a single-dev item, and clear out the backlog of “nice to haves” that compete with the real meat and bread of my business. This prototyping and “good enough” development has been massively impactful in my small org\n\nHas any senior React dev code review your work? I would be very interested to see what do they have to say about the quality of your code. It's a bit like using LLMs to medically self diagnose yourself and claiming it works because you are healthy.\n\nIronically enough, it does seem that the only workforce AIs will be shrinking will be devs themselves. I guess in 2025, everyone can finally code"
}
,
{
"id": "46510339",
"text": "That's a solid answer, I like it, thanks!"
}
,
{
"id": "46511027",
"text": "I follow at least one GitHub repo (a well respected one that's made the HN front page), and where everything is now Claude coded. Things do move fast, but I'm seriously under impressed with the quality. I've raised a few concerns, some were taken in, others seem to have been shut down with an explanation Claude produced that IMO makes no sense, but which is taken at face value.\n\nThis matches my personal experience. I was asked to help with a large Swift iOS app without knowing Swift. Had access to a frontier agent. I was able to consistently knock a couple of tickets per week for about a month until the fire was out and the actual team could take over. Code review by the owners means the result isn't terrible, but it's not great either. I leave the experience none the wiser: gained very little knowledge of Swift, iOS development or the project. Management was happy with the productivity boost.\n\nI think it's fleeting and dread a time where most code is produced that way, with the humans accumulating very little institutional knowledge and not knowing enough to properly review things."
}
,
{
"id": "46511062",
"text": "Any reason not to link to the repo in question?"
}
,
{
"id": "46511289",
"text": "I'm just one data point. Me being unimpressed should not be used to judge their entire work. I feel like I have a pretty decent understanding of a few small corners of what they're doing, and find it a bad omen that they've brushed aside some of my concerns. But I'm definitely not knowledgeable enough about the rest of it all.\n\nWhat concerns me is, generally, if the experts (and I do consider them experts) can use frontier AI to look very productive, but upon close inspection of something you (in this case I) happen to be knowledgeable about, it's not that great (built on shaky foundations), what about all the vibe coded stuff built by non-experts?"
}
,
{
"id": "46509763",
"text": "Oh wow that's a great analogy. So many posts talking about how AI is a massive benefit for their work but no examples or further information."
}
,
{
"id": "46510033",
"text": "This project and its website were both originally working 1 shot prototypes:\n\nThe website https://pxehost.com - via codex CLI\n\nThe actual project itself (a pxe server written in go that works on macOS) - https://github.com/pxehost/pxehost - ChatGPT put the working v1 of this in 1 message.\n\nThere was much tweaking, testing, refactoring (often manually) before releasing it.\n\nWhere AI helps is the fact that it’s possible to try 10-20 different such prototypes per day.\n\nThe end result is 1) Much more handwritten code gets produced because when I get a working prototype I usually want to go over every detail personally; 2) I can write code across much more diverse technologies; 3) The code is better, because each of its components are the best of many attempts, since attempts are so cheap.\n\nI can give more if you like, but hope that is what you are looking for."
}
,
{
"id": "46510346",
"text": "I appreciate the effort and that's a nice looking project. That's similar to the gains I've gotten as well with Greenfield projects (I use codex too!). However not as grandiose as these the Canadian girlfriend post category."
}
,
{
"id": "46511364",
"text": "This looks awesome, well done.\n\nI find it remarkable there are people that look at useful, living projects like that and still manage to dismiss AI coding as a fad or gimmick."
}
,
{
"id": "46511736",
"text": "I was at a podiatrist yesterday who explained that what he's trying to do is to \"train\" an LLM agent on the articles and research papers he's published to create a chatbot that can provide answers to the most common questions more quickly than his reception team can.\n\nHe's also using it to speed up writing his reports to send to patients.\n\nLonger term, he was also quite optimistic on its ability to cut out roles like radiologists, instead having a software program interpret the images and write a report to send to a consultant. Since the consultant already checks the report against any images, the AI being more sensitive to potential issues is a positive thing: giving him the power to discard erroneous results rather than potentially miss something more malign."
}
,
{
"id": "46512566",
"text": "> Longer term, he was also quite optimistic on its ability to cut out roles like radiologists, instead having a software program interpret the images and write a report to send to a consultant.\n\nAs a medical imaging tech, I think this is a terrible idea. At least for the test I perform, a lot of redundancy and double-checking is necessary because results can easily be misleading without a diligent tech or critical-thinking on the part of the reading physician. For instance, imaging at slightly the wrong angle can make a normal image look like pathology, or vice versa.\n\nMaybe other tests are simpler than mine, but I doubt it. If you've ever asked an AI a question about your field of expertise and been amazed at the nonsense it spouts, why would you trust it to read your medical tests?\n\n> Since the consultant already checks the report against any images, the AI being more sensitive to potential issues is a positive thing: giving him the power to discard erroneous results rather than potentially miss something more malign.\n\nUnless they had the exact same schooling as the radiologist, I wouldn't trust the consultant to interpret my test, even if paired with an AI. There's a reason this is a whole specialized field -- because it's not as simple as interpreting an EKG."
}
,
{
"id": "46511388",
"text": "I had some .csproj files that only worked with msbuild/vsbuild that I wanted to make compatible with dotnet. Copilot does a pretty good job of updating these and identifying the ones more likely to break (say web projects compared to plain dlls). It isn't a simple fire and forget, but it did make it possible without me needing to do as much research into what was changing.\n\nIs that a net benefit? Without AI, if I really wanted to do that conversion, I would have had to become much more familiar with the inner workings of csproj files. That is a benefit I've lost, but it would've also taken longer to do so, so much time I might not have decided to do the conversion. My job doesn't really have a need for someone that deeply specialized in csproj, and it isn't a particular interest of mine, so letting AI handle it while being able to answer a few questions to sate my curiosity seemed a great compromise.\n\nA second example, it works great as a better option to a rubber duck. I noticed some messy programming where, basically, OOP had been abandoned in favor of one massive class doing far too much work. I needed to break it down, and talking with AI about it helped come up with some design patterns that worked well. AI wasn't good enough to do the refactoring in one go, but it helped talk through the pros and cons of a few design pattern and was able to create test examples so I could get a feel for what it would look like when done. Also, when I finished, I had AI review it and it caught a few typos that weren't compile errors before I even got to the point of testing it.\n\nNone of these were things AI could do on their own, and definitely aren't areas I would have just blindly trusted some vibe coded output, but overall it was productivity increase well worth the $20 or so cost.\n\n(Now, one may argue that is the subsidized cost, and the unsubsidized cost would not have been worthwhile. To that, I can only say I'm not versed enough on the costs to be sure, but the argument does seem like a possibility.)"
}
,
{
"id": "46508656",
"text": "Agreed. I've never seen a concrete answer with an outcome that can be explained in clear, simple terms."
}
,
{
"id": "46508806",
"text": "I work in insurance - regulated, human capital heavy, etc.\n\nThree examples for you:\n- our policy agent extracts all coverage limits and policy details into a data ontology. This saves 10-20 mins per policy. It is more accurate and consistent than our humans\n- our email drafting agent will pull all relevant context on an account whenever an email comes in. It will draft a reply or an email to someone else based on context and workflow. Over half of our emails are now sent without meaningfully modifying the draft, up from 20% two months ago. Hundreds of hours saved per week, now spent on more valuable work for clients.\n- our certificates agent will note when a certificate of insurance is requested over email and automatically handle the necessary checks and follow up options or resolution. Will likely save us around $500k this year.\n\nWe also now increasingly share prototypes as a way to discuss ideas. Because the cost to vibe code something illustrative is very low, an it’s often much higher fidelity to have the conversation with something visual than a written document"
}
,
{
"id": "46508902",
"text": "Thanks for that. It's a really interesting data point. My takeaway, which I've already felt and I feel like anyone dealing with insurance would anyway, is that the industry is wildly outdated. Which I guess offers a lot of low hanging fruit where AI could be useful. Other than the email drafting, it really seems like all of that should have been handled by just normal software decades ago."
}
,
{
"id": "46509080",
"text": "A big win for 'normal software' here is to have authentication as a multi-party/agent approval process. Have the client of the insurance company request the automated delivery of certified documents to some other company's email."
}
,
{
"id": "46511373",
"text": "I think we are the stage of the \"AI Bubble\" that is equivalent to saying it is 1997, 18% of U.S. households have internet access. Obviously, the internet is not working out or 90%+ of households would have internet access if it was going to be as big of deal as some claim.\n\nI work at a place that is doing nothing like this and it seems obvious to me we are going to get put out of business in the long run. This is just adding a power law on top of a power law. Winner winner take all. What I currently do will be done by software engineers and agents in 10 years or less. Gemini is already much smarter than I am. I am going to end up at a factory or Walmart if I can get in.\n\nThe \"AI bubble\" is a mass delusion of people in denial of this reality. There is no bubble. The market has just priced all this forward as it should. There is a domino effect of automation that hasn't happened yet because your company still has to interface with stupid companies like mine that are betting on the hand loom. Just have to wait for us to bleed out and then most people will never get hired for white collar work again.\n\nIt amuses me when someone says who is going to want the factory jobs in the US if we reshore production? Me and all the other very average people who get displaced out of white collar work and don't want to be homeless is who.\n\n\"More valuable\" work is just 2026 managerial class speak for \"place holder until the agent can take over the task\"."
}
,
{
"id": "46509106",
"text": "> our policy agent extracts all coverage limits and policy details into a data ontology.\n\nAre they using some software for this or was this built in-house?"
}
,
{
"id": "46509361",
"text": ">our policy agent extracts all coverage limits and policy details into a data ontology\n\nAren't you worried about the agent missing or hallucinating policy details?"
}
,
{
"id": "46509512",
"text": "Management has decreed that won't happen so it won't."
}
,
{
"id": "46509660",
"text": "What an uncharitable and nasty comment for something they clearly addressed in theirs:\n\n> It is more accurate and consistent than our humans.\n\nSo, errors can clearly happen, but they happen less often than they used to.\n\n> It will draft a reply or an email\n\n\"draft\" clearly implies a human will will double-check."
}
,
{
"id": "46511084",
"text": "> \"draft\" clearly implies a human will will double-check.\n\nThe wording does imply this, but since the whole point was to free the human from reading all the details and relevant context about the case, how would this double-checking actually happen in reality?"
}
,
{
"id": "46513642",
"text": "> the whole point was to free the human from reading all the details and relevant context about the case\n\nThat's your assumption.\n\nMy read of that comment is that it's much easier to verify and approve (or modify) the message than it is to write it from scratch. The second sentence does confirm a person then modifies it in half the cases, so there is some manual work remaining.\n\nIt doesn't need to be all or nothing."
}
,
{
"id": "46512430",
"text": "The “double checking” is a step to make sure there’s someone low-level to blame. Everyone knows the “double-checking” in most of these systems will be cursory at best, for most double-checkers. It’s a miserable job to do much of, and with AI, it’s a lot of what a person would be doing. It’ll be half-assed. People will go batshit crazy otherwise.\n\nOn the off chance it’s not for that reason, productivity requirements will be increased until you must half-ass it."
}
,
{
"id": "46512944",
"text": "I think it's a good comment, given that the best agents seem to hallucinate something like 10% on a simple task and more than 70% on complex ones."
}
,
{
"id": "46510915",
"text": ">So, errors can clearly happen, but they happen less often than they used to.\n\nIf you take the comment at face value. I'm sorry but I've been around this industry long enough to be sceptical of self serving statements like these.\n\n>\"draft\" clearly implies a human will will double-check.\n\nI'm even more sceptical of that working in practice."
}
,
{
"id": "46510639",
"text": "That sounds a lot like \"LLMs are finally powerful enough technology to overcome our paper/PDF-based business\". Solving problems that frankly had no business existing in 2020."
}
,
{
"id": "46509198",
"text": "Thanks for this answer! I appreciate the clarity, I can see the economic impact for your company. Very cool."
}
,
{
"id": "46509364",
"text": "Here's some anecdata from the B2B SaaS company I work at\n\n- Product team is generating some code with LLMs but everything has to go through human review and developers are expected to \"know\" what they committed - so it hasn't been a major time saver but we can spin up quicker and explore more edge cases before getting into the real work\n\n- Marketing team is using LLMs to generate initial outlines and drafts - but even low stakes/quick turn around content (like LinkedIn posts and paid ads) still need to be reviewed for accuracy, brand voice, etc. Projects get started quicker but still go through various human review before customers/the public sees it\n\n- Similarly the Sales team can generate outreach messaging slightly faster but they still have to review for accuracy, targeting, personalization, etc. Meeting/call summaries are pretty much 'magic' and accurate-enough when you need to analyze any transcripts. You can still fall back on the actual recording for clarification.\n\n- We're able to spin up demos much faster with 'synthetic' content/sites/visuals that are good-enough for a sales call but would never hold up in production\n\n---\n\nAll that being said - the value seems to be speeding up discovery of actual work, but someone still needs to actually do the work. We have customers, we built a brand, we're subject to SLAs and other regulatory frameworks so we can't just let some automated workflow do whatever it wants without a ton of guardrails. We're seeing similar feedback from our customers in regard to the LLM features (RAG) that we've added to the product if that helps."
}
,
{
"id": "46509929",
"text": "This makes a lot of sense and is consistent with the lens that LLMs are essentially better autocomplete"
}
,
{
"id": "46508734",
"text": "Lately, it seems like all the blogs have shifted away from talking about productivity and are now talking about how much they \"enjoy\" working with LLMs.\n\nIf firing up old coal plants and skyrocketing RAM prices and $5000 consumer GPUs and violating millions of developers' copyrights and occasionally coaxing someone into killing themselves is the cost of Brian From Middle Management getting to Enjoy Programming Again instead of having to blame his kids for not having any time on the weekends, I guess we have no choice but to oblige him his little treat."
}
,
{
"id": "46510565",
"text": "It’s the honeymoon period with crack all over again. Everyone feels great until their teeth start falling out."
}
,
{
"id": "46509905",
"text": "This kind of take I find genuinely baffling. I can't see how anybody working with current frontier models isn't finding them a massive performance boost. No they can't replace a competent developer yet, but they can easily at least double your productivity.\n\nCareful code review and a good pull request flow are important, just as they were before LLMs."
}
,
{
"id": "46511776",
"text": "> double your productivity\n\nChurning out 2x as much code is not doubling productivity. Can you perform at the same level as a dev who is considered 2x as productive as you? That's the real metric. Comparing quality to quantity of code ratios, bugs caused by your PRs, actual understanding of the code in your PR, ability to think slow, ability to deal with fires, ability to quickly deal with breaking changes accidentally caused by your changes.\n\nChurning out more more per day is not the goal. No point merging code that either doesn't fully work, is not properly tested, other humans (or you) cannot understand, etc."
}
,
{
"id": "46512380",
"text": "Why is that the real metric? If you can turn a 1x dev into a 2x dev that's a huge deal, especially if you can also turn the original 2x dev into a 4x dev.\n\nAnd far from \"churning out code\" my work is better with LLMs. Better tested, better documented, and better organized because now I can do refactors that just would have taken too much time before. And more performant too because I can explore more optimization paths than I had time to before.\n\nRefusing to use LLMs now is like refusing to use compilers 20 years ago. It might be justified in some specific cases but it's a bad default stance."
}
,
{
"id": "46512875",
"text": "> Why is that the real metric?\n\nThe answer to \"Can you perform at the same level as a dev who is considered 2x as productive as you?\" is self-explanatory. If your answer is negative, you are not 2x as productive"
}
,
{
"id": "46512664",
"text": "Seriously, I’m lucky if 10% of what I do in a week is writing code. I’m doubly lucky if, when I do, it doesn’t involve touching awful corporate horse-shit like low-code products that are allergic to LLM aid, plus multiple git repos, plus having knowledge from a bunch of “cloud” dashboard and SaaS product configs. By the time I prompt all that external crap in I could have just written what I wanted to write.\n\nWriting code is the easy and fast part already ."
}
,
{
"id": "46510536",
"text": "People thought they were doubling their productivity and then real, actual studies showed they were actually slower. These types of claims have to be taken with entire quarries of salt at this point."
}
,
{
"id": "46510547",
"text": "The denial on this topic is genuinely surreal. I've knocked out entire features in a single prompt that took me days in the past.\n\nI guess I should be happy that so many of my colleagues are willing to remove themselves from the competitive job pool with these kinds of attitudes."
}
,
{
"id": "46510709",
"text": "I'm going to go ahead and assume that we don't do the same type of work, we aren't likely in the same pool anyway."
}
,
{
"id": "46511383",
"text": "C, Swift, Typescript, audio dsp, robotics etc.\n\nPeople always want to claim what they’re doing is so complex and esoteric that AI can’t touch it. This is dangerous hubris."
}
,
{
"id": "46512427",
"text": "You discount the value of being intimately familiar with each line of code, the design decisions and tradeoffs because one wrote the bloody thing.\n\nIt is negative value for me to have a mediocre machine do that job for me, that I will still have to maintain, yet I will have learned absolutely nothing from the experience of building it."
}
,
{
"id": "46513753",
"text": "This to me seems like saying you can learn nothing from a book unless you yourself have written it. You can read the code the LLM writes the same as you can read the code your colleagues write. Moreover you have to pretty explicitly tell it what to write for it to be very useful. You're still designing what it's doing you just don't have to write every line."
}
,
{
"id": "46511754",
"text": "No, I wouldn't say it's super complex. I make custom 3D engines. It's just that you and I were probably never in any real competition anyway, because it's not super common to do what I do.\n\nI will add that LLMs are very mediocre, bordering on bad, at any challenging or interesting 3D engine stuff. They're pretty decent at answering questions about surface API stuff (though, inexplicably, they're really shit at OpenGL which is odd because it has way more code out there written in it than any other API) and a bit about the APIs' structure, though."
}
,
{
"id": "46512434",
"text": "I really don't know how effective LLMs are at that but also that puts you in an extremely narrow niche of development, so you should keep that in mind when making much more general claims about how useful they are."
}
,
{
"id": "46512496",
"text": "My bigger point was that not everyone who is skeptical about supposed productivity gains and their veracity is in competition with you. I think any inference you made beyond that is a mistake on your part.\n\n(I did do web development and distributed systems for quite some time, though, and I suspect while LLMs are probably good at tutorial-level stuff for those areas it falls apart quite fast once you leave the kiddy pool.)\n\nP.S.:\n\nI think it's very ironic that you say that you should be careful to not speak in general terms about things that might depend much more on context, when you clearly somehow were under the belief that all developers must see the same kind of (perceived) productivity gains you have."
}
,
{
"id": "46511368",
"text": "What kind of work do you do?"
}
,
{
"id": "46511745",
"text": "I make custom 3D engines and the things that run on them."
}
,
{
"id": "46511286",
"text": "I am going to be dead ass\n\nYour colleagues are leaving because people like you suck to be around. Have fun playing with your chat bots."
}
]
</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