llm/5888b8dc-b96e-4444-9c3c-465dde409e92/topic-9-1b430169-7744-4f88-86a8-cdccfcdc0746-input.json
You are a comment summarizer. Given a topic and a list of comments tagged with that topic, write a single paragraph summarizing the key points and perspectives expressed in the comments. TOPIC: AI for boilerplate and scaffolding COMMENTS: 1. For me it all the build stuff and scaffolding I have to get in place before I can even start tinkering on a project. I never formally learned all the systems and tools and AI makes all of that 10x easier. When I hit something I cannot figure out instead of googling for 1/2 hour it is 10 minutes in AI. 2. I don't think I'll learn anything by yet again implementing authentication, password reset, forgotten password, etc. 3. What I really enjoy in programming is algorithms and bit-twiddling and stuff that might be in Knuth or HAKMEM or whatever. That’s fun. I like writing Lisp especially, and doing cool, elegant functional programs. I don’t enjoy boilerplate. I don’t necessarily enjoy all of the error checking and polishing and minutia in turning algorithms into shippable products. I find AI can be immensely helpful in making real things for people to use, but I still enjoy doing what I find fun by hand. 4. It's just fun in a different way now. I've long had dozens of ideas for things I wanted to build, and never enough time to really even build one of them. Over the last few months, I've been able to crank out several of these projects to satisfactory results. The code is not a beautiful work of art like I would prefer it to be, and the fun part is no longer the actual code and working in the code base like it used to be. The fun part now is being able to have an app or tool that gets the job I needed done. These are rarely important jobs, just things that I want as a personal user. Some of them have been good enough that I shipped them for other users, but the vast majority are just things I use personally. Just yesterday for example, I used AI to build a GTK app that has a bunch of sports team related sound effects built into them. I could have coded this by hand in 45 minutes, but it only took 10 minutes with AI. That's not the best part though. The best part is that I was able to use AI to get it building into an app image in a container so I can distribute it to myself as a single static file that I can execute on any system I want. Dicking with builds and distribution was always the painful part and something that I never enjoyed, but without it, usage is a pain. I've even gone back to projects I built a decade ago or more and got them building against modern libraries and distributed as RPMs or app images that I can trivially install on all of my systems. The joy is now in the results rather than the process, but it is joy nonetheless. 5. In practice, I find it depends on your work scale, topic and cadence. I started on the $20 plans for a bit of an experiment, needing to see about this whole AI thing. And for the first month or two that was enough to get the flavor. It let me see how to work. I was still copy/pasting mostly, thinking about what to do. As i got more confident i moved to the agents and the integrated editors. Then i realised i could open more than one editor or agent at a time while each AI instance was doing its work. I discovered that when I'm getting the AI agents to summarise, write reports, investigate issues, make plans, implement changes, run builds, organise git, etc, now I can alt-tab and drive anywhere between 2-6 projects at once, and I don't have to do any of the boring boiler plate or administrivia, because the AI does that, it's what its great for. What used to be unthinkable and annoying context switching now lets me focus in on different parts of the project that actually matter, firing off instructions, providing instructions to the next agent, ushering them out the door and then checking on the next intern in the queue. Give them feedback on their work, usher them on, next intern. The main task now is kind of managing the scope and context-window of each AI, and how to structure big projects to take advantage of that. Honestly though, i don't view it as too much more than functional decomposition. You've still got a big problem, now how do you break it down. At this rate I can sustain the $100 claude plan, but honestly I don't need to go further than that, and that's basically me working full time in parallel streams, although i might be using it at relatively cheap times, so it or the $200 plan seems about right for full time work. I can see how theoretically you could go even above that, going into full auto-pilot mode, but I feel i'm already at a place of diminishing marginal returns, i don't usually go over the $100 claude code plan, and the AIs can't do the complex work reliably enough to be left alone anyway. So at the moment if you're going full time i feel they're the sweet spot. The $20 plans are fine for getting a flavor for the first month or two, but once you come up to speed you'll breeze past their limitations quickly. 6. As I've gotten more experience I've tended to find more fun in tinkering with architectures than tinkering with code. I'm currently working on making a secure zero-trust bare metal kubernetes deployment that relies on an immutable UKI and TPM remote attestation. I'm making heavy use of LLMs for the different implementation details as I experiment with the architecture. As far as I know, to the extent I'm doing anything novel, it's because it's not a reasonable approach for engineering reasons even if it technically works, but I'm learning a lot about how TPMs work and the boot process and the kernel. I still enjoy writing code as well, but I see them as separate hobbies. LLMs can take my hand-optimized assembly drag racing or the joy of writing a well-crafted library from my cold dead hands, but that's not always what I'm trying to do and I'll gladly have an LLM write my OCI layout directory to CPIO helper or my Bazel rule for putting together a configuration file and building the kernel so that I can spend my time thinking about how the big pieces fit together and how I want to handle trust roots and cold starts. 7. This goes further into LLM usage than I prefer to go. I learn so much better when I do the research and make the plan myself that I wouldn’t let an LLM do that part even if I trusted the LLM to do a good job. I basically don’t outsource stuff to an LLM unless I know roughly what to expect the LLM output to look like and I’m just saving myself a bunch of typing. “Could you make me a Go module with an API similar to archive/tar.Writer that produces a CPIO archive in the newcx format?” was an example from this project. 8. Yeah, this is a lot of what I'm doing with LLM code generation these days: I've been there, I've done that, I vaguely know what the right code would look like when I see it. Rather than spend 30-60 minutes refreshing myself to swap the context back into my head, I prompt Claude to generate a thing that I know can be done. Much of the time, it generates basically what I would have written, but faster. Sometimes, better, because it has no concept of boredom or impatience while it produces exhaustive tests or fixes style problems. I review, test, demand refinements, and tweak a few things myself. By the end, I have a working thing and I've gotten a refresher on things anyway. 9. Something happened to me a few years ago. I used to write code professionally and contribute to open source a lot. I was freelancing on other people's projects and contributing to mature projects so I was doing hard work, mostly at a low level (I mean algorithms, performance fixes, small new features, rather than high level project architecture). I was working on an open source contribution for a few days. Something that I struggled with, but I enjoyed the challenge and learned a lot from it. As it happened someone else submitted a PR fixing the same issue around the same time. I wasn't bothered if mine got picked or not, it happens. But I remember looking at how similar both of our contributions were and feeling like we were using our brains as computers, just crunching algorithms and pumping in knowledge to create some technical code that was (at the time) impossible for a computer to create. This stayed with me for a while and I decided that doing this technical algorithm crunching wasn't the best use of my human brain. I was making myself interchangeable with all the other human (and now AI) code crunchers. I should move on to a higher level, either architectural or management. This was a big deal for me because I did love (and still do) deeply understanding algorithms and mathematics. I was extremely fortunate with timing as it was just around one year before AI coding became mainstream but early enough that it wasn't a factor in this shift. Now an AI could probably churn out a decent version of that algorithm in a few minutes. I did move on to open my own business with my partner and haven't written much code in a few years. And when I do now I appreciate that I can focus on the high level stuff and create something that my business needs in a few hours without exhausting myself on low level algorithm crunching. This isn't meant to put down the enjoyment of writing code for code's sake. I still do appreciate well written code and the craft that goes into it. I'm just documenting my personal shift and noting that enjoyment can be found on both sides. 10. For me it automates a lot of the boilerplate that usually bogs me down on side projects. I cal spin up all of the stuff I hate doing quickly and then fiddle with the interesting parts inside of a working scaffold of code. I recently did this with an elixir wrapper around some Erlang OTP code o wanted to use. Figuring out how to clue together all of the parts that touched the Erlang and tracing all of the arguments through old OTP code would have absolutely stopped me from bothering with this in the past. Instead I’m having fun playing with the interface of my tool in ways that matter for my use case. 11. Is the manual coding part of programming still fun or not? We have a lot of opinions on either side here. I think the classic division of problems being solved might, for most people, solve this seeming contradiction. For every problem, X% is solving the necessary complexity of the problem. Taming the original problem, in relation to what computers are capable of doing. With the potential of some relevant well implemented libraries or API’s helping to close that gap. Work in that scenario rarely feels like wasted time. But in reality, there is almost always another problem we have to solve, the Y%=(1-X) of the work required for an actual solution that involves wrangling with mismatches in available tools from the problem being solved. This can be relatively benign, just introducing some extra cute little puzzles, that make our brains feel smart as we successfully win wack-a-mole. A side game that can even be refreshing. Or, the stack of tools, and their quirks, that we need to use can be an unbounded (even compounding) generative system of pervasive mismatches and pernicious non-obvious, not immediately recognizable, trenches we must a 1000 little bridges, and maybe a few historic bridges, just to create a path back to the original problem. And it is often evident that all this work is an artifact of 1000 less than perfect choices by others. (No judgement, just a fact of tool creation having its own difficulties.) That stuff can become energy draining to say the list. I think high X problems are fun to solve. Most of our work goes into solving the original problem. Even finding out it was more complex than we thought feels like meaningful drama and increase the joy of resolving. High Y problems involve vast amounts of glue code, library wrappers with exception handling, the list in any code base can be significant. Even overwhelm the actual problem solving code. And all those mismatches often hold us back, to where our final solution inevitable has problems in situations we hope never happen, until we can come back for round N+1, for unbounded N. Any help from AI for the latter is a huge win. Those are not “real” problems. As tool stack change, nobody will port Y-type solutions forward. (I tell myself so I can sleep at night). So that’s it. We are all different. But what type of acceleration AI gives us on type-Y problems is most likely to feel great. Enabling. Letting us harder on things that are more important and lasting. And where AI is less of a boost, but still a potentially welcome one, as an assistant. 12. I think it just depends on the person or the type of project. If I'm learning something or building a hobby project, I'll usually just use an autocomplete agent and leave Claude Code at work. On the other hand, if I want to build something that I actually need, I may lean on AI assistants more because I'm more interested in the end product. There are certain tasks as well that I just don't need to do by hand, like typing an existing SQL schema into an ORM's DSL. 13. I do have productivity goals! I want to spend the half hour I have on the part I think is fun. Not on machine configuration, boilerplate, dependency resolution, 100 random errors with new frameworks that are maybe resolved with web searches. 14. What about the boring parts of fun hobby projects? 15. I enjoy noodling around with pointers and unsafe code in Rust. Claude wrote all the documentation, to Rust standards, with nice examples for every method. I decided to write an app in Rust with a React UI, and Claude wrote almost all the typescript for me. So I’ve used Claude at both ends of the spectrum. I had way more fun in every situation. AI is, fortunately, very bad at the things I find fun, at least for now, and very good at the things I find booooring (read in Scot Pilgrim voice). 16. It's a little shameful but I still struggle when centering divs on a page. Yes, I know about flexbox for more than a decade but always have to search to remember how it is done. So instead of refreshing that less used knowledge I just ask the AI to do it for me. The implications of this vs searching MDN Docs is another conversation to have. 17. Hah, centering divs with flexbox is one of my uses for this too! I can never remember the syntax off the top of my head, but if I say "center it with flexbox" it spits out exactly the right code every time. If I do this a few more times it might even stick in my head. 18. Try tailwind. Very amenable to LLM generation since it's effectively a micro language, and being colocated with the document elements, it doesn't need a big context to zip together. 19. This matches my experience. A recent anecdote: I took time during a holiday to write an Obsidian plugin 4 years ago to scratch a personal itch as it were. I promptly forgot most of the detail, the Obsidian plugin API and ecosystem have naturally changed since then, and Typescript isn't in my day-to-day lingo. I've been collecting ideas for new plugins since then while dreading the investment needed to get back up to speed on how to implement them. I took a couple hours over a recent winter holiday with Claude and cranked out two new plugins plus improvements to the 4 year old bit-rotting original. Claude handled much of the accidental complexity of ramping up that would have bogged me down in the past--suggesting appropriate API methods to use, writing idiomatic TS, addressing linter findings, ... 20. I'm finding that too. I have old stale projects that I'm hesitant to try and fix because I know it will involve hours of frustrating work figuring out how to upgrade core dependencies. Now I can genuinely point Claude Code at them and say "upgrade this to the latest versions" and it will do most of that tedious work for me. I can even have it fill in some missing tests and gaps in the documentation at the same time. 21. > AI assistance means you can get something useful done in half an hour, or even while you are doing other stuff. You don't need to carve out 2-4 hours to ramp up any more. That fits my experience with a chrome extension I created. Instead of having to read the docs, find example projects, etc, I was able to get a working version in less than a hour. 22. The good thing about AI is that it knows all the hundreds of little libraries that keep popping up every few days like a never-ending stream. No longer I need to worry about learning about this stuff, I can just ask the AI what libraries to use for something and it will bring up these dependencies and provide sample code to use them. I don't like AI for coding real algorithms, but I love the fact that I don't need to worry about the myriad of libraries that you had to keep up with until recently. 23. I'll sometimes ask Claude Sonnet 4.5 for JS and TS library recommendations. Not for "latest" or "most popular". For this case, it seems to love recommending promising-looking code from repos released two months ago with like 63 stars. 24. Depends on how you're using the LLMs. It can also be like having someone else around to chop the onions, wash the pans and find the ingredients when you need them. 25. The important difference is the reduction in boilerplate, which allows programs to be written with (often) significantly less code. Hence the time savings (and fun) spoken of in the original article. This isn't really a new phenomenon. Languages have been adding things like arrays and maps as builtins to reduce the boilerplate required around them. The modern languages of which we speak take that same idea to a whole new level, but such is the nature of evolution. 26. The only difference is that newer languages have figured out how to remove a lot of the boilerplate. 27. 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. I 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. 28. 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. Obviously you cannot generalize that to all software development though. 29. > That sounds reasonable to me. AI is best at generating super basic and common code I'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". 30. - Providing boilerplate/template code for common use cases - Explaining what code is doing and how it works - Refactoring/updating code when given specific requirements - Providing alternative ways of doing things that you might not have thought of yourself YMMV; every project is different so you might not have occasion to use all of these at the same time. 31. I think it depends what you are doing. I’ve had Claude right the front end of a rust/react app and it was 10x if not x (because I just wouldn’t have attempted it). I’ve also had it write the documentation for a low level crate - work that needs to be done for the crate to be used effectively - but which I would have half-arsed because who like writing documentation? Recently I’ve been using it to write some async rust and it just shits the bed. It regularly codes the select! drop issue or otherwise completely fails to handle waiting on multiple things. My prompts have gotten quite sweary lately. It is probably 1x or worse. However, I am going to try formulating a pattern with examples to stuff in its context and we’ll see. I view the situation as a problem to be overcome, not an insurmountable failure. There may be places where an AI just can’t get it right: I wouldn’t trust it to write the clever bit tricks I’m doing elsewhere. But even there, it writes (most of) the tests and the docs. On the whole, I’m having far more fun with AI, and I am at least 2x as productive, on average. Consider that you might be stuck in a local (very bad) maximum. They certainly exist, as I’ve discovered. Try some side projects, something that has lots of existing examples in the training set. If you wanted to start a Formula 1 team, you’re going to need to know how to design a car, but there’s also a shit ton of logistics - like getting the car to the track - that an AI could just handle for you. Find boring but vital work the AI can do because, in my experience, that’s 90% of the work. 32. Mmm, I do a lot of frontend work but I find writing the frontend code myself is faster. That seems to be mostly what everyone says it's good for. I find it useful for other stuff like writing mini scripts, figuring out arguments for command line tools, reviewing code, generating dumb boilerplate code, etc. Just not for actually writing code. 33. I’m better at it in the spaces where I deliver value. For me that’s the backend, and I’m building complex backends with simple frontends. Sounds like your expertise is the front end, so you’re gonna be doing stuff that’s beyond me, and beyond what the AI was trained on. I found ways to make the AI solve backend pain points (documentation, tests, boiler plate like integrations). There’s probably spaces where the AI can make your work more productive, or, like my move into the front end, do work that you didn’t do before. 34. > But I would steer away from starting them. I find just the opposite. Before, starting from nothing was a huge impediment. Now you can have a working prototype and start iterating right away. If you figur e out that you've gone down the wrong path, there's little remorse in tossing it out and starting over. 35. Yes! I've been having a great time prompting "vanilla JavaScript, no react" and building neat things that use browser APIs exclusively (including modern stuff like web audio APIs and Web Components and WASM) because I don't need to learn a bunch of boilerplate stuff first anymore. Feels like coding in the 200xs and I'm enjoying every minute of it. 36. In particular, and speaking as a backend engineer with zero web design skills, building things with charts/graphs is amazing nowadays! You can literally just operate at the level of "add another line representing the foo data", "add a scatterplot below it", "make them line up", "actually, make it a more reddish pink" etc. In the past I've had opinions about d3 and vega-lite and altair and matplotlib etc and learned how to use those ones at a superficial level at least. In my last personal UI with charts I didn't even ask it what framework it had chosen (chart.js is the answer) 37. To me, what sucks the most about programming is dealing with ecosystem issues. You want to write a little tool for personal use, but NPM starts acting out. Then you need to do something in java, which you don't use very often, and you get a giant maven error stack trace which you now need to try to understand. All of this frustration is gone since I use AI and I can focus solely on the thing I'm trying to accomplish. 38. This is exactly how I feel about it. The cognitive load of starting a new project is so small now. It's also made it very easy to switch between projects, something that took way too much headspace to do on a whim in the before times. 39. Been using GitHub Copilot to handle the tedious webpack/babel config files and it's a game changer for modern web dev. No more spending hours debugging build pipeline issues - it generates 90% correct configs that just need minor tweaks. 40. Meanwhile, I've been feeling the fun of development sucked away by LLMs. I recently started doing some coding problems where I intentionally turned off all LLM assistance, and THAT was fun. Although I'll be happy to use LLMs for nightmare stuff like dependency management. So I guess it's about figuring out which part of development you enjoy and which part drains you, and refusing to let it take the former from you. 41. I have this suspicion that the people who say they have 10x productivity gains from AI might largely see improvements from a workflow change which fixes their executive dysfunction. Back in the day I never had any issue just sitting down and coding something out for 4 hours straight. So I don’t think LLMs feel quite as big for me. But I can see the feeling of offloading effort to a computer when you have trouble getting started on a sub-task being a good trick to keep your brain engaged. I’ve personally seen LLMs be huge time savers on specific bugs, for writing tests, and writing boilerplate code. They’re huge for working in new frameworks that roughly map to one you already know. But for the nitty gritty that ends up being most of the work on a mature product where all of the easy stuff is already done they don’t provide as big of a multiplier. 42. AI has increased my productivity in dealing with side tasks in languages/frameworks I'm not familiar with. But it has not made development fun. To the contrary, I enjoy writing code, not reviewing code. 43. Really like using alpine with a classical JS server rendered stack too. Most crud apps don’t need a spa app and now you are working out of one code base again. Codex chews through this kind of code 44. Exactly. AI freed me from the boring character by character toiling 45. Couldn’t agree more. Changing anything in oUR react Bootstrap frontend was a visit to the dentist. But Llms really lowered the pain. 46. AI is doing the chores while we paint. 47. Yes, so what? That's what I basically do, i need a little framework with this and that and API, 15 minutes later I get exactly what I need and want. Not more, not less.as long as it's not Auth, crypto or something like that, I don't see an issue. 48. I’m just looking to make pizza not smelt the ore for the oven I’m going to cook it in. 49. On a meta level, seems this trajectory follows Alan Kay: first we made the complex things possible, now we make simple things simple. 50. I agree with this. I've been able to tackle projects I've been wanting to for ages with LLMs because they let me focus on abstractions first and get over the friction of starting the project. Once I get my footing, I can use them to generate more and more specialized code and ultimately get to a place where the code is good. Write a concise, engaging paragraph (3-5 sentences) that captures the main ideas, notable perspectives, and overall sentiment of these comments regarding the topic. Focus on the most interesting and representative viewpoints. Do not use bullet points or lists - write flowing prose.
AI for boilerplate and scaffolding
50