llm/5888b8dc-b96e-4444-9c3c-465dde409e92/batch-5-1f1eefa3-0f6c-46d4-a5bb-619c64211738-input.json
You are a comment classifier. Given a list of topics and a batch of comments, assign each comment to up to 3 of the most relevant topics.
TOPICS (use these 1-based indices):
1. AI productivity claims skepticism
2. Joy of programming vs shipping products
3. Skill atrophy concerns with AI
4. Experienced vs inexperienced developer AI gains
5. Web development complexity is optional
6. Code review burden with AI
7. Vibe coding quality concerns
8. Learning while using LLMs
9. Time-constrained developers benefiting
10. AI for boilerplate and scaffolding
11. Frontend framework fatigue
12. Managing AI like junior developers
13. Return to simpler web stacks
14. AI as autocomplete evolution
15. Side project enablement
16. Technical debt from AI code
17. Cost and pricing of AI tools
18. Pattern recognition and code quality
19. Parenting and hobby coding time
20. AI hallucinations and reliability
COMMENTS TO CLASSIFY:
[
{
"id": "46491562",
"text": "That IKEA analogy is pretty good, because plenty of people use IKEA furniture to solve the \"I need a bookshelf\" problem - and often enjoy the process - without feeling like they should call themselves a carpenter.\n\nI bet there are professional carpenters out there who occasionally assemble an IKEA bookshelf because they need something quick and don't want to spend hours building one themselves from scratch."
}
,
{
"id": "46493248",
"text": "Definitely. I'm not disparaging the process of assembling IKEA furniture, nor the process of producing software using LLMs. I've done both, and they have their time and place.\n\nWhat I'm pushing back on is the idea that these are equivalent to carpentry and programming. I think we need new terminology to describe this new process. \"Vibe coding\" is at the extreme end of it, and \"LLM-assisted software development\" is a mouthful.\n\nAlthough, the IKEA analogy could be more accurate: the assembly instructions can be wrong; some screws may be missing; you ordered an office chair and got a dining chair; a desk may have five legs; etc. Also, the thing you built is made out of hollow MDF, and will collapse under moderate levels of stress. And if you don't have prior experience building furniture, you end up with no usable skills to modify the end result beyond the manufacturer's original specifications.\n\nSo, sure, the seemingly quick and easy process might be convenient when it works. Though I've found that it often requires more time and effort to produce what I want, and I end up with a lackluster product, and no learned skills to show for it. Thus learning the difficult process is a more rewarding long-term investment if you plan to continue building software or furniture in the future. :)"
}
,
{
"id": "46492964",
"text": "Little bit of a sweeping generalization there. There are a huge range of ways in which LLMs are being leveraged for software development.\n\nUsing a drill doesn’t make you any less of a carpenter, even if you stopped using a screwdriver because your wrists are shot."
}
,
{
"id": "46491327",
"text": "It's called being a systems analyst or product manager. Upskill into these roles (while still accepting individual contributor pay) or get left behind."
}
,
{
"id": "46494792",
"text": "Do you see any reason why AI and software will not soon take over system analyst or product manager roles? If we can go from natural language prompt to working code, it seems like not too big of a step to set up a system that goes straight from user feedback to code changes."
}
,
{
"id": "46491518",
"text": "I'm sorry, \"upskill\"? The roles you mentioned don't require any more advanced skills than those required for software development—just a different set of skills.\n\nAnd an IC is not \"left behind\" if those roles don't interest them. What a ridiculous thing to say. A systems analyst or product manager is not a natural progression for someone who enjoys software development."
}
,
{
"id": "46489115",
"text": "I was just getting pretty sick and tired of programming, instead now AI can write the code down while I do the fun things of figuring out how shit works and general device hacking + home projects"
}
,
{
"id": "46491983",
"text": "What do LLM's have to do returning to coding?\n\nJust...\n\n...write the code. Stop being lazy."
}
,
{
"id": "46493068",
"text": "Yes, people who were at best average engineers and those that atrophied at their skill through lack of practice seem to be the biggest AI fanboys in my social media.\n\nIt's telling, isn't it?"
}
,
{
"id": "46490981",
"text": "> On the frontend, you have build pipelines, bundlers, CSS frameworks with their own toolchains, progressive web apps, Core Web Vitals, SEO, layout shifts, srcset/responsive images… I remember when the biggest challenge was IE6 compatibility.\n\nYou only have those things if you choose to use them.\n\nI've been building websites for 25 years. I use the same core technologies today that I did when I started. Sure, I make use of modern improvements to the languages themselves, but I have never permanently adopted any of the \"hot new trends\" and feel I am better - or at least saner - for it.\n\nNo, your marketing or e-commerce website almost certainly doesn't need a JS bundling toolchain. It almost certainly doesn't need a CSS preprocessor or even a CSS boilerplate/framework. It almost certainly doesn't need an enterprise-class PHP framework; or a dependency manager; or a CI/CD pipeline."
}
,
{
"id": "46491165",
"text": "Those technologies don't just solve tech issues, they solve organizational issues. If one or two people manage a website, going without fancy tooling is completely fine. When 1000 people are managing a product with complex business logic across multiple platforms, you need fancy tooling to ensure everyone can work at a reasonable level of productivity."
}
,
{
"id": "46494327",
"text": "> you need fancy tooling to ensure everyone can work at a reasonable level of productivity.\n\nIf you have a thousand people working on a single product, yes, but you also have the resources to have dedicated tool support teams at that level. In my experience, if you’re under multiple dozens of developers or not everyone works on all of your projects, the tools fragment because people aren’t combining or configuring them the same way and there’s enough churn in the front-end tool space that you’ll hit various compatibility issues which lower the effectiveness of sharing across projects. This is especially true if you’ve hired people who self-identify as, say, Next or Tailwind developers rather than web developers and lack the understanding of the underlying technology to fix complex problems."
}
,
{
"id": "46491854",
"text": "The article is about developing as a solo developer."
}
,
{
"id": "46493435",
"text": "> build pipelines, bundlers, CSS frameworks with their own toolchains, progressive web apps, Core Web Vitals, SEO, layout shifts, srcset/responsive images\n\nBuild pipelines are purely a technical decision. Bundlers are purely a technical decision (TBH, a non-brainer if you decide to have a build pipeline, but it's not an organizational helper). Those help one do some things, not several people to organize.\n\nI'm still waiting for any person to claim they made CSS maintainable by adopting a framework. It's an almost purely organizational decision with no upsides at all.\n\nPWAs are a product decision, not technical or organizational. The same applies to Core Web Vitals, SEO, layout shifts and srcset, those are all product decisions.\n\nYou can escape the technical and organizational decisions. You can't escape the product ones."
}
,
{
"id": "46497948",
"text": "This is why web development stopped being fun: developers that cannot manage or train people and instead hope garbage like jQuery will simply act as a surrogate parent."
}
,
{
"id": "46491029",
"text": "What are you using? If you don't mind me asking."
}
,
{
"id": "46491136",
"text": "It's so weird to see this take repeated over and over. I have to assume you have never written a large scale project for the web? The only part where I agree is that you don't need PHP or server-side rendering in general."
}
,
{
"id": "46492209",
"text": "Nowhere he talked about large scale projects and the article neither btw. I am sure his choices are different when working on a large scale project."
}
,
{
"id": "46496175",
"text": "> I have to assume you have never written a large scale project for the web?\n\nCan I ask, what classifies as large scale project for the web?\n\nI previously created and exited a trading platform that did billions in transactions via our servers with thousands of users streaming real time data. It's certainly more complicated and \"larger\" than 99.9% of things you'll ever do. So does that qualify?\n\nIf so, I can tell you that I did it with PHP and no JS frameworks. Hosted on a couple of VPS servers from digital ocean. From idea to execution to exit in ~9 months.\n\nYou know what the weird part is? I see your take repeated over and over by \"shovel peddlers\" and grifters. And every single time it comes with 0 substance or merit."
}
,
{
"id": "46496277",
"text": "> I can tell you that I did it\n\nThe 'I' here reveals that this is indeed not a large scale project, though perhaps impressive. When working on a piece of software with tens of people, using more tooling really does makes sense."
}
,
{
"id": "46496458",
"text": "'I' here reveals that it is on topic in context of posted article. Which is purpose of this thread.\n\nSorry I do not want to sound like a dick re-stating the obvious but threads often are going off the rails and I find it bit absurd."
}
,
{
"id": "46501358",
"text": "I've tried to parse your comment from various perspectives, but can't seem to make sense of it.\n\nA 9-person-month project is just not a large scale project by any definition."
}
,
{
"id": "46499919",
"text": "Congrats to you, but yeah the other comments have already said it.\n\nI'm talking about projects that have a lot of people working together across multiple teams where not everyone is even a dev. This is routine with e-commerce. The build will have assets from design teams, copywriters, analytics scripts, etc. and a CMS isn't always the correct or even scalable solution for that. The original commenter I was replying to seems to be stuck in the past. These days it can all be done with a simple CI script, but yeah ultimately that means build tools.\n\nAbove all else, like I said in another comment, there cannot be server-side rendering because it deploys to a CDN for hosting. These are projects that require huge amounts of content, but need to stay responsive. The final build result and upload is many files, but the initial load for the site is minimal JS and HTML to render for the user.\n\n> billions in transactions via our servers with thousands of users streaming real time data. It's certainly more complicated and \"larger\" than 99.9% of things you'll ever do.\n\nLarge scale doesn't have to be complicated, but it does need some way to coordinate the effort which means there's a build and there will be requirements that are beyond any one person's control and expected for the modern web.\n\nI want to also point out the obvious that there's insane money being made in e-commerce since it's now the default way to shop for everyone. It's a very common type of web project and if the typical HN web dev is getting paid a decent salary it's likely that the sites they maintain have several orders of magnitude more users than what you're talking about."
}
,
{
"id": "46491361",
"text": "I used to think the same about server-side rendering until I more closely looked at React SSR.\n\nI think it makes a lot of sense and allows for faster initial rendering of the page while automatically setting up the JS and interactivity in the background."
}
,
{
"id": "46499594",
"text": "React has always supported server-side rendering and there have been many tools over the years to \"rehydrate\" data from the server to the client for when the client-side React application \"takes over\"."
}
,
{
"id": "46491566",
"text": "Couldn't you just static render the parts that you're using SSR for?\n\nI am not trying to be dismissive, but a common strict requirement is static hosting from a CDN, embedded environments, etc."
}
,
{
"id": "46492574",
"text": "If you static render, it won't be an interactive application.\n\nWith React SSR you get the best of both: stream static HTML chunks immediately, and rehydrate with JS later, prioritizing components the user interacts with.\n\nIt should load quicker compared to traditional React apps where the browser loads the HTML, then loads the JS bundle, and only then renders a loading skeleton while likely triggering more requests for data."
}
,
{
"id": "46494275",
"text": "> It should load quicker compared to traditional React apps where the browser loads the HTML, then loads the JS bundle, and only then renders a loading skeleton while likely triggering more requests for data.\n\nThen your JS bundle is broken.\n\nPromises exist. Modules exist. HTTP/2+ exists. You can load data while you are loading a small amount of JS required to render that data while you are loading other parts of your JS.\n\nIf everything is sequential: load giant JS bundle -> fetch -> render, that's because someone architected it like that. Browsers give you all the tools you need to load in parallel, if you don't use them then it's not the browser's fault.\n\nYou do not need SSR or rehydration. That's just Vercel propaganda. They saw that people are doing a stupid thing and decided to push a complex solution to it. Why? It makes them money."
}
,
{
"id": "46496744",
"text": "You cannot load any data in a regular React application before you loaded both React and your React components that trigger the fetch.\n\nIf you use code splitting, your initial bundle size can be smaller, yes. That's about it.\n\nI guess in theory you can hack together static loading skeletons that you then remove when React loaded your initial bundle, but that's certainly far from a common approach. By that standard, the vast majority of JS bundles would be \"broken\"."
}
,
{
"id": "46493308",
"text": "You seem to be confused about your terms, both SSR and SSG can rehydrate and become interactive, you only need SSR if you have personalized content that must be fetched on an actual user request, and with frameworks like astro introducing island concept it even let's you mix SSG and SSR content on a single page."
}
,
{
"id": "46496856",
"text": "That depends on how you interpret \"static render\".\n\nI did not interpret that as React SSG. SSG is the default behavior of NextJS unless you dynamically fetch data, turning it into SSR automatically.\n\nWhat I thought of is React's \"renderToString()\" at build time which will produce static HTML with event handlers stripped, in preparation for a later \"hydrateRoot()\" on the client side."
}
,
{
"id": "46492855",
"text": "Static rendering has nothing to do with interactivity in a web app.\n\nI guess if you're already so deeply entrenched in writing all your application logic on the server side you need React SSR, but that sounds miserable."
}
,
{
"id": "46489004",
"text": "I remember those times, and it was a lot of fun, but there's really nothing stopping you from running a LAMP stack today, writing PHP without frameworks and with manual SQL queries.\n\nIn fact, it's a lot more fun for me to approach this today. Modern PHP is a joy. MariaSQL is very much MySQL (and switching to Postgres isn't exactly a bump in complexity). It's way easier to write code that won't get injected.\n\nIf you want to slice your designs in Photoshop (ehem, the real OGs used Fireworks) go ahead and use Dreamweaver, go ahead. That said, HTML5 makes not having to use tables for layout easy, not more complex and VS Code has all the good parts of Dreamweaver (trust me, you don't need or want the WYSIWG... if you must, just use inspect elements and move the changes over to the HTML file).\n\nI guess all this is to say that web dev is simpler, not more complex for solo devs today. There exists more complicated tooling, but if you're solo-dev'ing something for fun, skip it!\n\nEDIT: Also, phpMyAdmin was fun to use but also the best way to get your box popped. Today, something like DBeaver suits me just fine."
}
,
{
"id": "46495851",
"text": "> ehem, the real OGs used Fireworks\n\nMan I missed Macromedia Fireworks. Such a great time! I think I had the last bundle before the Adobe buy-out, Macromedia Studio I think it was called? So good!"
}
,
{
"id": "46496203",
"text": "I still write vanilla PHP with SQL queries. And with all the modern PHP features, things have never been faster or more joyful to work with.\n\nI honestly feel bad for people who fall victims to complexity. It burns you out when all you need is to keep things simple and fun. Life is too short for anything else."
}
,
{
"id": "46497000",
"text": "> but also the best way to get your box popped\n\nwhat do you mean? why?"
}
,
{
"id": "46499566",
"text": "https://www.cve.org/CVERecord/SearchResults?query=phpmyadmin\n\nSort by oldest to newest"
}
,
{
"id": "46490902",
"text": "> Even with refinement and back-and-forth prompting, I’m easily 10x more productive\n\nDevelopers notoriously overestimate the productivity gains of AI, especially because it's akin to gambling every time you make a prompt, hoping for the AI's output to work.\n\nI'd be shocked if the developer wasn't actually less productive."
}
,
{
"id": "46496339",
"text": "For personal projects, 10x is a lower bound. This year alone I got several projects done that had been on my mind for years .\n\nThe baseline isn't what it would have taken had I set aside time to do it.[1] The baseline is reality . I'm easily getting 10x more projects done than in the past.\n\nFor work, I totally agree with you.\n\n[1] Although it's often true even in this case. My first such project was done in 15 minutes. Conceptually it was an easy project. Had I known all the libraries, etc out would have taken about an hour. But I didn't, and the research alone would have taken hours.\n\nAnd most of the knowledge acquired from that research would likely be useless."
}
,
{
"id": "46490979",
"text": "I accept there are productivity gains, but it's hard to take \"10x\" seriously. It's such a tired trope. Is no one humble enough to be a meager 2.5x engineer?"
}
,
{
"id": "46491027",
"text": "Even 2.5x is absurd. If they said 1.5x I might believe them."
}
,
{
"id": "46491149",
"text": "I'm building an AI agent for Godot, and in paid user testing we found the median speed up time to complete a variety of tasks[0] was 2x. This number was closer to 10x for less experienced engineers\n\n[0] tasks included making games from scratch and resolving bugs we put into template projects. There's no perfect tasks to test on, but this seemed sufficient"
}
,
{
"id": "46494591",
"text": "Have you evaluated the maintainability of the generated code? Becuause that could of course start to count in the negative direction over time.\n\nSome of the AI generated I've seen has been decent quality, but almost all of it is much more verbose or just greater in quantity than hand written code is/would be. And that's almost always what you don't want for maintenance..."
}
,
{
"id": "46491281",
"text": "That sounds reasonable to me. AI is best at generating super basic and common code, it will have plenty of training on game templates and simple games.\n\nObviously you cannot generalize that to all software development though."
}
,
{
"id": "46491818",
"text": "As you get deeper beyond the starter and bootstrap code it definitely takes a different approach to get value.\n\nThis is in part because context limits of large code bases and because the knowledge becomes more specialized and the LLM has no training on that kind of code.\n\nBut people are making it work, it just isn't as black and white."
}
,
{
"id": "46496379",
"text": "That’s the issue, though, isn’t it? Why isn’t it black and white? Clear massive productivity gains at Google or MS and their dev armies should be visible from orbit.\n\nJust today on HN I’ve seen claims of 25x and 10x and 2x productivity gains. But none of it starting with well calibrated estimations using quantifiable outcomes, consistent teams, whole lifecycle evaluation, and apples to apples work.\n\nIn my own extensive use of LLMs I’m reminded of mouse versus command line testing around file navigation. Objective facts and subjective reporting don’t always line up, people feel empowered and productive while ‘doing’ and don’t like ‘hunting’ while uncertain… but our sense of the activity and measurable output aren’t the same.\n\nI’m left wondering why a 2x Microsoft of OpenAI would ever sell their competitive advantage to others. There’s infinite money to be made exploiting such a tech, but instead we see highschool homework, script gen, and demo ware that is already just a few searches away and downloadable.\n\nLLMs are in essence copy and pasting existing work while hopping over uncomfortable copyright and attribution qualms so devs feel like ‘product managers’ and not charlatans. Is that fundamentally faster than a healthy stack overflow and non-enshittened Google? Over a product lifecycle? … ‘sometimes, kinda’ in the absence of clear obvious next-gen production feels like we’re expecting a horse with a wagon seat built in to win a Formula 1 race."
}
,
{
"id": "46494034",
"text": "> That sounds reasonable to me. AI is best at generating super basic and common code\n\nI'm currently using AI (Claude Code) to write a new Lojban parser in Haskell from scratch, which is hardly something \"super basic and common\". It works pretty well in practice, so I don't think that assertion is valid anymore. There are certainly differences between different tasks in terms of what works better with coding agents, but it's not as simple as \"super basic\"."
}
,
{
"id": "46494192",
"text": "I'm sure there is plenty of language parsers written in Haskell in the training data. Regardless, the question isn't if LLMs can generate code (they clearly can), it's if agentic workflows are superior to writing code by hand."
}
,
{
"id": "46494248",
"text": "There's no shortage of parsers in Haskell, but parsing a human language is very different from parsing a programming language. The grammar is much, much more complex, and this means that e.g. simple approaches that adequate error messages don't really work here because failures are non-actionable."
}
,
{
"id": "46491396",
"text": "One concern is those less experienced engineers might never become experienced if they’re using AI from the start. Not that everyone needs to be good at coding. But I wonder what new grads are like these days. I suspect few people can fight the temptation to make their lives a little easier and skip learning some lessons."
}
]
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
]
}
,
...
]
Rules:
- Each comment can have 0 to 3 topics
- Use 1-based topic indices
- Only assign topics that are genuinely relevant to the comment
- If no topics match, use an empty array:
{
"id": "...",
"topics": []
}
50