llm/fa6df919-50f4-440a-804d-6a9d3e9721d8/topic-17-154780fa-c43c-414d-b1bc-5fa0f241a396-input.json
The following is content for you to summarize. Do not respond to the comments—summarize them. <topic> Boilerplate Liberation # Appreciation for AI handling tedious setup, configuration, documentation, and scaffolding while humans focus on interesting problems </topic> <comments_about_topic> 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. You can study the LLM output. In the “before times” I’d just clone a random git repo, use a template, or copy and paste stuff together to get the initial version working. 3. I don't want to waste time learning how to install and configure ephemeral tools that will be obsolete before I ever need to use them again. 4. Exactly, the whole point is it wouldn’t take 30 minutes (more like 3 hours) if the tooling didn’t change all the fucking time. And if the ecosystem wasn’t a house of cards 8 layers of json configuration tall. Instead you’d learn it, remember it, and it would be useful next time. But it’s not. 5. I don't think I'll learn anything by yet again implementing authentication, password reset, forgotten password, etc. 6. 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. 7. 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. 8. 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. 9. 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. 10. So much this. The act of having the agent create a research report first, a detailed plan second, then maybe implement it is itself fun and enjoyable. The implementation is the tedious part these days, the pie in the sky research and planning is the fun part and the agent is a font of knowledge especially when it comes to integrating 3 or 4 languages together. 11. 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. 12. I’ve got kids and so seldom find myself with the time or energy to work on something. Cursor has really helped in that regard. I have an extensive media collection of very large VR video files with very unhelpful names. I needed to figure out a good way to review which ones I wanted to keep and discard (over 30TB, almost 2000 files). It was fun sitting using Cursor with Claude to work on setting up a quick web UI, with calls out to ffmpeg to generate snapshots. It handled the “boring parts” with aplomb, getting me a html page with a little JavaScript to serve as my front end, and making a super simple API. All this was still like 1000 lines and would have taken me days, or I would have copied some boilerplate then modified it a little. The problems Claude couldn’t figure out were also similarly interesting, like its syntax to the ffmpeg calls were wrong and not skipping all the frames we didn’t want to generate, so it was taking 100x longer to generate than was necessary seeking through every file, then I made some optimizations in how I had it configured, then realizing I’d generated thumbnails for 3 hours only for them to not display well on the page as it was an 8x1 tile. At that point Claude wanted to regenerate all the thumbnails and I said “just display the image twice, with the first half displayed the first time and the second half displayed the second time, saving myself a few hours. Hacky, but for a personal project, the right solution. I still felt like I was tinkering in a way I haven’t in awhile, and a project that I’d never have gotten around to and instead have just probably bought another new hard drive, took me a couple hours, most of which was actually marking the files as keep or delete. I ended up deleting 12TB of stuff I didn’t want, which it felt cool to write myself a bespoke tool rather than search around on the off chance that such a thing already exists. It also gave me a mental framework of how to approach little products like this in the future, that often a web ui and a simple API backend like Node making external process calls is going to be easier than making a full fat windows UI. I have a similarly sized STL library from 3D printing and think I could apply mostly the same idea to that, in fact it’s 99% the same except for swapping out the ffmpeg call to something to generate a snapshot of the stl at a few different angles. 13. 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. 14. 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. 15. 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. 16. 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. 17. What about the boring parts of fun hobby projects? 18. 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). 19. Search “centre a div” in Google Wade through ads Skim a treatise on the history of centering content Skim over the “this question is off topic / duplicate” noise if Stack Overflow Find some code on the page Try to map how that code will work in the context of your other layout Realize it’s plain CSS and you’re looking for Tailwind Keep searching Try some stuff until it works Or… Ask LLM. Wait 20-30 seconds. Move on to the next thing. 20. 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, ... 21. 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. 22. I’ve noticed this too at work. If keep the change’s focused I can iterate far faster with ideas because it can type faster than I can. 23. 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. 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. Equally a good use for a legacy compiler that compiles a legacy language. Granted, you are going to have to write a lot more boilerplate to see it function (that being the difference, after all), but the outcome will be the same either way. It's all just 1s and 0s at the end of the day. 26. 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. 27. The only difference is that newer languages have figured out how to remove a lot of the boilerplate. 28. 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 29. 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. 30. As you get deeper beyond the starter and bootstrap code it definitely takes a different approach to get value. This 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. But people are making it work, it just isn't as black and white. 31. - 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. 32. 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. 33. 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. 34. 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. 35. theres a fun "K-shaped" optionality with LLMs: on one hand, its possible to deal with otherwise large API surfaces. but on the other hand, you can 'go oldschool' but with the hot new tools: install ubuntu, launch claude with yolo mode, and just tell it what you want as if it were a sysadmin from the early 2000s/late 90s. both roads very reasonable, but that the old way of doing things is new again is interesting. 36. > 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. 37. Setting up build system and prototyping sure. As a replacement for Figma it’s great. But I would throw away all the code and start from scratch if I wanted to be able to maintain the code in the long term. 38. 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) 39. Tackling layer of complexity often feels like this. I remember 2010 and my frustration of evergrowing complexity of networking backend programming (C++ mainly), and discovering Go. "Go made programming fun again" was a common phrase at the conferences back then. I feel similar with web-apps development too, except we're not solving complexity here – we just outsorcing it to "AI-developer". None of the deficiencies of web stack are solved here. The worst part is that this complexity of web stack is mainly _accidental_ – i.e. coming from the tooling, not from the problem domain. 40. 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. 41. I kinda feel the same way, don't get me wrong, I'm a developer at soul level, I absolutely love programming, but I love more getting shit done, automating things, taking the human out of the equation and putting the computer to do it, AI lets me do that. I work in cybersecurity as a WAF admin, my job is 100% that, but I'm also the only developer so anything that needs to be scripted or developed I get to do it. One week I created 4 different scripts with Gemini Canvas to automate some tedious work, it took my I don't know, 3 hours? Instead of 1 or 2 weeks? Yeah sign me in. 42. 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. 43. 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. 44. 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. 45. I personally don't find using LLMs "fun" but I do like this article for one simple reason. It points out that most contemporary frameworks for web are forms of slop and I don't think you should feel bad using an LLM to generate slop code and config to deal with it. 46. 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 47. Totally agree. I've been using blazor server + Claude for project and it just removes all the stupid complexity of having react + a rest API. 48. Exactly. AI freed me from the boring character by character toiling 49. I'm using it to build things. Here's an example from the other day. I've always been curious about writing custom Python C extensions but I've never been brave enough to really try and do it. I decided it would be interesting to dig into that by having Codex build a C extension for Python that exposed simple SQLite queries with a timeout. It wrote me this: https://github.com/simonw/research/blob/main/sqlite-time-lim... - here's the shared transcript: https://chatgpt.com/s/cd_6958a2f131a081918ed810832f7437a2 I read the code it produced and ran it on my computer to see it work. What did I learn? - Codex can write, compile and test C extensions for Python now - The sqlite3_progress_handler mechanism I've been hooking into for SQLite time limits in my Python code works in C too, and appears to be the recommended way to solve this - How to use PyTuple_New(size) in C and then populate that tuple - What the SQLite C API for running a query and then iterating though the results looks like, including the various SQLITE_INTEGER style constants for column types - The "goto cleanup;" pattern for cleaning up on errors, including releasing resources and calling DECREF for the Python reference counter - That a simple Python extension can be done with ~150 lines of readable and surprisingly non-threatening C - How to use a setup.py and pyproject.toml function together to configure a Python package that compiles an extension Would I have learned more if I had spent realistically a couple of days figuring out enough C and CPython and SQLite and setup.py trivia to do this without LLM help? Yes. But I don't have two days to spend on this flight of curiosity, so actually I would have learned nothing. The LLM project took me ~1 minutes to prompt and then 15 minutes to consume the lessons at the end. And I can do dozens of this kind of thing a day, in between my other work! 50. Couldn’t agree more. Changing anything in oUR react Bootstrap frontend was a visit to the dentist. But Llms really lowered the pain. 51. AI is doing the chores while we paint. 52. 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. 53. honestly, with LLMs, everything is fun again. embedded dev with a billion toolchains, GPU development with each vendors bespoke API, ffmpeg with its billion parameters - if anything, you could say LLMs bailed us out of the impending ultra-specialization. without LLMs, we might be facing a world where 30% of the workforce is in software dev. i am keeping my eyes peeled on vibe-coding PCB layouts and schematics. a lot of eyes in that direction already but its still early. 54. Like, fine, here's a personal example: I wanted to build a system that posts web links I share to a bot account on the fediverse. That seemed like a fun result to me. I wanted to self-host the links, so I installed Linkding. (I didn't write Linkding.) For the fediverse bot, I installed gotosocial as the service host (I didn't write gotosocial.) From there, a cronjob running a small program using Linkding and gotosocial APIs could do the trick. Decided to do it in golang, because the standalone binaries are easy to deploy. Writing that small program didn't seem like fun - I've already played with those APIs and golang. What I wanted, for my enjoyment, was the completed system. So, I took 10 minutes to write out a quick spec for the program and what I wanted it to do. I loaded that up as context for Claude Code along with some pointers for building CLI apps in golang. I let it rip and, in about 20 minutes, Claude produced a functional tool. It also wrote a decent README based on my original prose. I reviewed the code, did some testing, made some tweaks, called it done. My bookmarks are now regularly posted to a bot account on the fediverse. This is an enjoyable outcome for me - and I didn't have to type every line of code myself. For bonus points, I also had Claude Code gin up some GitHub Actions workflows to lint, test, build, and release multi-platform binaries for this tool. I've done these things before, but they're tedious. More enjoyable to have the resulting automations than to build them. And now I have them: I can make tweaks to this tool and get builds just through the GitHub web UI. I've since repeated this pattern with a handful of other small personal tools. In each case, I wanted the tool and the utility it offered. I didn't care about the process of writing the code. It's working pretty well for me. 55. Specialization is for insects, as Heinlein said. We are going back to the Renaissance Man ideal and I'm all for it. 56. “LLMs bailed us out of the impending ultra-specialization” - well said! </comments_about_topic> Write a concise, engaging paragraph (3-5 sentences) summarizing the key points and perspectives in these comments about the topic. Focus on the most interesting viewpoints. Do not use bullet points—write flowing prose.
Boilerplate Liberation # Appreciation for AI handling tedious setup, configuration, documentation, and scaffolding while humans focus on interesting problems
56