{
    "archive_path": "archive/1790417197.944724",
    "base_url": "discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705",
    "basename": "14705",
    "bookmarked_date": "2026-09-26 10:06",
    "canonical": {
        "archive_org_path": "https://web.archive.org/web/discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705",
        "dom_path": "output.html",
        "favicon_path": "favicon.ico",
        "git_path": "git/",
        "google_favicon_path": "https://www.google.com/s2/favicons?domain=discourse.haskell.org",
        "headers_path": "headers.json",
        "htmltotext_path": "htmltotext.txt",
        "index_path": "index.html",
        "media_path": "media/",
        "mercury_path": "mercury/content.html",
        "pdf_path": "output.pdf",
        "readability_path": "readability/content.html",
        "screenshot_path": "screenshot.png",
        "singlefile_path": "singlefile.html",
        "warc_path": "warc/",
        "wget_path": "discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705.html"
    },
    "domain": "discourse.haskell.org",
    "extension": "",
    "hash": "1MWZYD5KGYQ2QPTD98H4",
    "history": {
        "archive_org": [],
        "dom": [],
        "favicon": [
            {
                "cmd": [
                    "curl",
                    "--silent",
                    "--location",
                    "--compressed",
                    "--max-time",
                    "120",
                    "--output",
                    "favicon.ico",
                    "--user-agent",
                    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)",
                    "https://www.google.com/s2/favicons?domain=discourse.haskell.org"
                ],
                "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)",
                "end_ts": "2026-09-26T13:39:13.512738+00:00",
                "index_texts": null,
                "output": "favicon.ico",
                "pwd": "/data/archive/1790417197.944724",
                "schema": "ArchiveResult",
                "start_ts": "2026-09-26T13:39:12.855815+00:00",
                "status": "succeeded"
            },
            {
                "cmd": [
                    "curl",
                    "--silent",
                    "--location",
                    "--compressed",
                    "--max-time",
                    "120",
                    "--output",
                    "favicon.ico",
                    "--user-agent",
                    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)",
                    "https://www.google.com/s2/favicons?domain=discourse.haskell.org"
                ],
                "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)",
                "end_ts": "2026-09-26T10:09:23.291683+00:00",
                "index_texts": null,
                "output": "favicon.ico",
                "pwd": "/data/archive/1790417197.944724",
                "schema": "ArchiveResult",
                "start_ts": "2026-09-26T10:09:22.667854+00:00",
                "status": "succeeded"
            },
            {
                "cmd": [
                    "curl",
                    "--silent",
                    "--location",
                    "--compressed",
                    "--max-time",
                    "120",
                    "--output",
                    "favicon.ico",
                    "--user-agent",
                    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)",
                    "https://www.google.com/s2/favicons?domain=discourse.haskell.org"
                ],
                "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)",
                "end_ts": "2026-09-26T16:29:45.963760+00:00",
                "index_texts": null,
                "output": "favicon.ico",
                "pwd": "/data/archive/1790417197.944724",
                "schema": "ArchiveResult",
                "start_ts": "2026-09-26T16:29:45.411066+00:00",
                "status": "succeeded"
            }
        ],
        "git": [],
        "headers": [
            {
                "cmd": [
                    "curl",
                    "--silent",
                    "--location",
                    "--compressed",
                    "--head",
                    "--max-time",
                    "120",
                    "--user-agent",
                    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)",
                    "https://discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705"
                ],
                "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)",
                "end_ts": "2026-09-26T13:39:14.025161+00:00",
                "index_texts": null,
                "output": "headers.json",
                "pwd": "/data/archive/1790417197.944724",
                "schema": "ArchiveResult",
                "start_ts": "2026-09-26T13:39:13.522632+00:00",
                "status": "succeeded"
            },
            {
                "cmd": [
                    "curl",
                    "--silent",
                    "--location",
                    "--compressed",
                    "--head",
                    "--max-time",
                    "120",
                    "--user-agent",
                    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)",
                    "https://discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705"
                ],
                "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)",
                "end_ts": "2026-09-26T10:09:23.800852+00:00",
                "index_texts": null,
                "output": "headers.json",
                "pwd": "/data/archive/1790417197.944724",
                "schema": "ArchiveResult",
                "start_ts": "2026-09-26T10:09:23.300721+00:00",
                "status": "succeeded"
            },
            {
                "cmd": [
                    "curl",
                    "--silent",
                    "--location",
                    "--compressed",
                    "--head",
                    "--max-time",
                    "120",
                    "--user-agent",
                    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)",
                    "https://discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705"
                ],
                "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)",
                "end_ts": "2026-09-26T16:29:46.589013+00:00",
                "index_texts": null,
                "output": "headers.json",
                "pwd": "/data/archive/1790417197.944724",
                "schema": "ArchiveResult",
                "start_ts": "2026-09-26T16:29:45.971112+00:00",
                "status": "succeeded"
            }
        ],
        "htmltotext": [],
        "media": [],
        "mercury": [
            {
                "cmd": [
                    "/app/node_modules/@postlight/parser/cli.js",
                    "https://discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705"
                ],
                "cmd_version": "1.0.0",
                "end_ts": "2026-09-26T13:39:25.402394+00:00",
                "index_texts": null,
                "output": "mercury",
                "pwd": "/data/archive/1790417197.944724",
                "schema": "ArchiveResult",
                "start_ts": "2026-09-26T13:39:20.904558+00:00",
                "status": "succeeded"
            },
            {
                "cmd": [
                    "/app/node_modules/@postlight/parser/cli.js",
                    "https://discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705"
                ],
                "cmd_version": "1.0.0",
                "end_ts": "2026-09-26T10:09:34.644841+00:00",
                "index_texts": null,
                "output": "mercury",
                "pwd": "/data/archive/1790417197.944724",
                "schema": "ArchiveResult",
                "start_ts": "2026-09-26T10:09:30.561069+00:00",
                "status": "succeeded"
            },
            {
                "cmd": [
                    "/app/node_modules/@postlight/parser/cli.js",
                    "https://discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705"
                ],
                "cmd_version": "1.0.0",
                "end_ts": "2026-09-26T16:29:57.565548+00:00",
                "index_texts": null,
                "output": "mercury",
                "pwd": "/data/archive/1790417197.944724",
                "schema": "ArchiveResult",
                "start_ts": "2026-09-26T16:29:53.246562+00:00",
                "status": "succeeded"
            }
        ],
        "pdf": [],
        "readability": [
            {
                "cmd": [
                    "/app/node_modules/readability-extractor/readability-extractor",
                    "/tmp/tmppfaxplt6",
                    "https://discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705"
                ],
                "cmd_version": "0.0.11",
                "end_ts": "2026-09-26T13:39:20.889830+00:00",
                "index_texts": [
                    "Are you steering towards AI burnout? Afraid of loosing your job to someone with little programming skills, no aspirations to quality, and a huge Claude account? Disappointed about the code quality in your projects, or worse in \u201cyour\u201d own code? This is for you.\nThere are significant and legitimate ethical concerns about frontier LLMs run by big tech companies, these have been discussed at length, I\u2019m aware and agree, this post is not about them. Please don\u2019t mistake me for a pro-LLM techbro.\nAlso: Since people have mistaken my texts for LLM-generated before, I\u2019ll tell you that it is 100% human written without any AI-assistance.\nSouls in the Great Machine\nThere is a great book of this title by Sean Mcmullen that I enjoyed reading as a teenager, and at the first glance it describes the opposite of our situation: A big computer where the individual components are human, and work together to form a calculating unit. On the other hand, LLMs are themselves running on actual computers and pretending to be (super-)humans. At a second glance, story and reality are not so far apart though: Our role in the process of producing software is being degraded slowly from being actors to cogs in a machine. The spec-driven-dystopia is that we just get handed down some spec, hammer it into the LLM, and weep when our tokens run out because a technofeudal lord decided to hand out fewer of them.\nAs a Haskell programmer, I enjoy writing Haskell. Yes, I like the product we make at work a lot, I like what you can do with my open source libraries, but I really enjoy just the process of expressing my thoughts in this language. I\u2019m assuming this to be true for most of you, and also it not to be true in many other languages, which explains to some amount why enthusiasts of different programming languages have different opinions on how bright or dark the LLM-assisted future is.\nWhen I generate code, a lot of that enjoyment is at risk. So, don\u2019t, maybe. I want to keep writing (at least the enjoyable parts of) Haskell programs, and not having to read and review (too much) generated code. At the same time, I want to put those tokens to some good use that doesn\u2019t slowly burn my brain away.\nI want to show you a way to keep enjoying programming, and at the same time becoming moderately more productive with LLM, instead of appearing to be much more productive and losing all the joy.\nIf you want to just be LLM-abstinent, that\u2019s great as well, and you already know what you\u2019re doing. But there might be reasons you don\u2019t want to be, e.g. you actually need to bring some real productiveness gain to the table, or you don\u2019t want to be left behind while the rest of your team, your company, your industry, is moving towards heavy LLM adoption.\nKeep writing code\nIf you want to keep owning your codebase, you need to keep writing some code. If you let it all be generated, it will turn into an LLM wasteland that only your coding agents can thrive on. So you should keep writing code, otherwise your codebase will eventually be lost.\nAnother reason to keep writing code is to keep being a good programmer. Skills can be lost by not practising, and here the risk is particularly high because there is a really low threshold to giving up your coding work and hand it to an agent. After just a few weeks of not coding and handing everything to agents you\u2019ll notice that you have a hard time returning to coding yourself.\nLLMs are way worse at producing good, human-readable code than advertised. They are somewhat ok at producing code they themselves later work on exclusively. But I\u2019m sure you\u2019ve already experienced the despair of looking at a completely generated file that must contain a bug somewhere, and your perceived inability as a human to find it yourself, because the landscape is just so alien.\nSo how to get to those productivity gains if not by letting agents do the coding? By making them do nearly everything else. Especially the boring work that is a nuisance to you. Ideally those tasks that are not too hard to get right, and easy to check.\nPlanning\nSince the earliest history of computers, they\u2019ve been always used as bookkeeping tool. Use LLMs that way. Amongst other things, it\u2019s a bookkeeping tool that you can address in natural language instead of a formal interface. Convert a huge written conversation between domain experts into actionable todos. Test something, write down the test results, let it organise them into a plan how to fix the defects.\nUse tools like a todo tool, or better even markdown files with frontmatter to make it track planning items properly. LLMs can have a huge context, but still if it is too full it can silently lose information.\nBut don\u2019t let it make any crucial decisions. Make it ask you. If you don\u2019t understand the question, it\u2019s the LLMs fault not to give you the relevant context (or you might be exhausted and need a break). If you return to the same issues again and again, take a step back from the screen and think about it yourself, and return when you have a clear picture of what you want.\nResearching\nWhen you give a researching task to an agent, it\u2019s tempting to watch it querying and \u201cthinking\u201d, to kick off some other agent in another project, or to make a coffee. Of these three, making the coffee is the best option. The one better option is: Research yourself in parallel using a good ol\u2019 search engine. At least roughly know everything the agent will know.\nDon\u2019t just let it research something, accept its results as facts and plan from there. This will lead to embarrassing technical dept.\nThe point of making an agent research is not for it to present all the relevant knowledge to you, or make a better decision than you could have made. The point is that you don\u2019t have to go \u201cLet Me Google That For You\u201d on it. You should understand the domain you\u2019re modelling as good as the agent does, ideally even better.\nMake your agents write down their research results somewhere, with links to their used resources. When it comes back to you later and presents you with a weird proposal, ask it about what the research says and which resource says so. 50% chance says it will discover its own mistake. In the other 50%, read it, now you\u2019re in a position to make a good decision yourself.\nYou are the coder\nThis is the game changer.\nThe typical coding harnesses lure you into \u201cplan first, then let the agent code\u201d. Refuse. Plan together, but then you code. Tell the LLM to research your code base, let it tell you the current todo and bring up all the places you need to edit, make it mention potential pitfalls, let it remind you of relevant background research.\nI work with this workflow, and it is a lot of fun. I\u2019m enjoying my work. Sometimes even more than before LLMs. I always have a clear todo, I don\u2019t need to worry about the overall plan, I can focus, I\u2019m done with the todo quickly because it is well-planned. It\u2019s like agile but without all the annoying processes.\nMake the agents group around your way to work, not the other way around. Maybe you\u2019re an experienced programmer who already knows how you work best. Let the agents do all the incidental work around you that you enjoy less.\nThere are multiple advantages to this workflow:\n\nYou keep doing what you enjoy. If you like programming, do it.\nYou always know what state your code base is in. Been surprised by some weird generated stuff coming from your own vibe coding sessions? Needed to rewrite LLM slop? Lost track of where you are in a session? This way you never have to again.\nYou discover a bad plan early. An agent coder might just go on forever with something that you\u2019ll recognize very quickly as a bad idea.\nYou keep honing your skills. Obviously. You\u2019ll stay a good programmer, or even go on improving.\n\nRare cases when a coding agent is useful\nIdeally for cleanup, small tasks, routine work, low-risk refactorings. You left FIXMEs in your code (maybe on purpose to save time and energy)? You wrote the 3 interesting cases and left the 7 similar boring ones? You have a module reorg in mind and want it benchmarked? Need to swap out an unmaintained library for a better one? Those are valid use cases. Designing something complicated from the ground up is probably not.\nSometimes you run out of time but want something finished, and maybe the rest of the todos in your plan are obvious low-risk tasks. It\u2019s ok to say \u201cI\u2019m afk, finish this\u201d to your supervisor agent, with a bit of luck you come back to a finished feature next morning. But it\u2019s important to do most of the coding work yourself.\nThere are some slight pitfalls here:\n\nSo you wrote those 3 interesting cases and tell the agent to finish the remaining 7 ones because they are just obvious adaptations of those you wrote. Chances are you should abstract instead. Maybe what you\u2019re really doing here is applying a lens or some other optic? Maybe this really is an instance to a popular type class like Traversable? LLMs are famously prone not to recognise this and instead copy huge swathes of code. You as a human are striving for better readable and reasonable code.\nSame goes for \u201cmake it mention potential pitfalls\u201d. Yes, LLMs may be really good at walking through the whole callchain and making sure that all places you should touch are listed in the todo you get handed. But instead of relying on it to find all these couplings you should consider whether your codebase is organised poorly, forcing you to use an LLM for code research in the first place.\n\nThe review cycle\nYou might remember how AI generated images suddenly became much more realistic with the advent of generative adversarial networks. In short, you have one model (the \u201cgenerator\u201d) that generates an image, and another (the \u201cdiscriminator\u201d) that tells it how well it has performed. These together can produce much better results than the generator alone. Applying the idea (which, in its generalized form, is not new at all) to LLM-assisted coding, you get an automated review cycle.\nDon\u2019t accept, don\u2019t even read any artefact produced by an LLM without an automated review cycle. This obviously applies directly to code (in those cases where you still let it be generated), but in particular to planning as well. When an agent codes something, the job is not done when it hands over, the job is done (i.e. fit for human eyes) when a reviewer agent has no more findings on it. The same goes for plans. It\u2019s really tiring to go through logical holes in a plan (refactoring a function in todo 2 that is planned to be written in todo 7) and spot them, so add a review agent that does that.\nI\u2019ve found it surprisingly helpful to have my own code reviewed. Sometimes it will just point out some nits, or insist on bloating up the Haddocks, but often enough it finds a genuine bug or an omission, and keeps me focussed on the actual todo. I recommend adding review cycles to your own work, but I absolutely understand if you don\u2019t want to read an LLMs review of your code. One way to get around this to tell it to fix the remaining findings itself if they\u2019re minor.\nThe frontier\n\nYou\u2019re completely underutilising what frontier models are capable of.\nSome vibe coder on the internet\n\nYes. That\u2019s a logical consequence of my point.\nBut there are multiple reasons why relying on frontier model features is a bad idea.\n\nEnvironmental cost. (Even though this post was not supposed to touch this topic.) Frontier models just use a huge amount of energy. Although this is a guess to some extent since LLM companies aren\u2019t very transparent on how their gadgets work.\nIt\u2019s hard to build up trust in something that pretends to be much cleverer than yourself. At the end, you\u2019re responsible for the code you produce. Not your machine. Blaming someone else for your code is something that bad managers and colleagues do with their employees and coworkers, it\u2019s ridiculous to do with a machine. So use LLMs in a way that you can take responsibility for the results. This only works if you make yourself an integral part of the process.\nThe fanciest models use the most tokens, so there is no telling whether you\u2019ll be able to complete your tasks with them in a given session. Everything that you can do with a smaller model is a safer bet.\nWhen your workflow doesn\u2019t need frontier models, you have a chance of eventually being able to replace them by open weight or open source models, and not be dependent on technofeudal lords at all anymore.\n\nIn the end, you\u2019re doing a complex job. In some aspects of it, LLMs may perform the same or maybe even a bit better. But that\u2019s by far not enough to bow down to them, because of all their downsides. LLMs would have to be many times better than a human developer, use less resources, be more reliable in complex real-world situations, be at least as well-aligned, and in some way accountable for their results, to replace human developers at their core activity.\nNo tokens left?\nMaybe you\u2019ve experienced your work coming to a standstill because you\u2019ve run out of tokens. It\u2019s annoying. Your workflow is now built around a tool that you suddenly have no access to any more. In the extreme case, you can\u2019t go on doing anything. Take this xkcd and imagine \u201cno tokens\u201d instead of \u201ccompiling\u201d for a healthy way to process that situation.\nIf this happens a few times, you might have had the feeling you\u2019ve been betrayed. And you\u2019re right. You have been. How many tokens you have in a given session on a particular plan is an intransparent number at the whim of some big techno feudal lord. It\u2019s not like a commodity you buy on a fair market and then use in a plannable way.\nYou need to stop perceiving the depletion of your tokens as \u201chaving bought too few\u201d, and start treating it as what it is: A service outage. Your LLM company has sold you the promise that you could use the LLM, and they don\u2019t keep it up. The number of maximum tokens in your session may change without you knowing or being able to influence it, so you can\u2019t really plan for it either.\nOf course saving on tokens is imperative. Re-evaluate your agent setups, your usage, your context sizes, your skills, and so on, to save on tokens. But even if you do, and even if you\u2019ve bought a larger seat, it may not be enough.\nAnd instead of seeing it as \u201cyour fault\u201d when you run out after you\u2019ve done everything to use tokens sparingly, see it as a technical fault that you need to be prepared for. When you\u2019ve ever have worked a lot on a train or plane, you know that you have to be prepared for not having internet all the time. Download and cache big assets beforehand. Always have some work to do that you can do offline.\nFor LLM assisted work, this means that you have to make it produce tangible artefacts for everything that you need to work on. Most importantly, if you adapt to the human coder workflow I\u2019ve outlined, make sure that you always have a planned list of todos you can work on. Have fun racing through them, and when your agent is back, tell them to do the cleaning.\nLLM gibberish\nLLM produced text is unlike human text. It gets bad in particular when the LLM actually doesn\u2019t really know what it\u2019s talking about. Treat LLM gibberish as potentially harmful for your psychic health. Don\u2019t consume to much of it. Keep talking to people about your code, especially about greater visions and interesting aspects. Only read LLM artefacts after automated review agents took the edges off.\nWhen your head is spinning, take a break. Yes, even if no agent is currently running in the background and \u201cproducing value\u201d. Your mental health is more important than your work output.\nYour fellow humans\nProgramming is, by large, a social endeavour. For example, in a company or an open source project, we send each other pull requests, write issues and commit messages. This is a form of communication. Even if you\u2019re the only one on your project, your past self writes issues, commit messages and PRs for you future self. Communication between humans is the pillar of software development.\nMake sure you always meet people human-first. Don\u2019t send a completely generated PR to someone. I\u2019ve done this by accident, the other end was rightfully fed up. I\u2019m making sure not to repeat this mistake.\nAgents will readily offer you to write a complete PR body in grammatically correct language, with all the details in there. This is not communication. It\u2019s a tool output. Treat such texts the same way like benchmarking numbers or debug traces: Append them to your handwritten PR body, possibly in a <details>, so people can decide themselves whether they want to read it or not. You\u2019ll find that more often they will not.\nMy journey\nWith all this, I\u2019m more productive than without LLM assistance. It\u2019s difficult to tell exactly, maybe twice as fast? This is less than many full vibe coders will boast with, but that\u2019s ok. I picture myself as a gardener adopting some gentle organic fertilisers, while vibe coders are more like drowning their fields in industrial chemicals. I believe that my way is the more sustainable for now.\nI love programming Haskell, and doing it for a living is my dream job. In the last month I was worried that this dream was now a thing of the past. But all what I wrote about here is what I learned in order to keep this activity enjoyable. It seems to work."
                ],
                "output": "readability",
                "pwd": "/data/archive/1790417197.944724",
                "schema": "ArchiveResult",
                "start_ts": "2026-09-26T13:39:18.909356+00:00",
                "status": "succeeded"
            },
            {
                "cmd": [
                    "/app/node_modules/readability-extractor/readability-extractor",
                    "/tmp/tmpco9aw1zv",
                    "https://discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705"
                ],
                "cmd_version": "0.0.11",
                "end_ts": "2026-09-26T10:09:30.551850+00:00",
                "index_texts": [
                    "Are you steering towards AI burnout? Afraid of loosing your job to someone with little programming skills, no aspirations to quality, and a huge Claude account? Disappointed about the code quality in your projects, or worse in \u201cyour\u201d own code? This is for you.\nThere are significant and legitimate ethical concerns about frontier LLMs run by big tech companies, these have been discussed at length, I\u2019m aware and agree, this post is not about them. Please don\u2019t mistake me for a pro-LLM techbro.\nAlso: Since people have mistaken my texts for LLM-generated before, I\u2019ll tell you that it is 100% human written without any AI-assistance.\nSouls in the Great Machine\nThere is a great book of this title by Sean Mcmullen that I enjoyed reading as a teenager, and at the first glance it describes the opposite of our situation: A big computer where the individual components are human, and work together to form a calculating unit. On the other hand, LLMs are themselves running on actual computers and pretending to be (super-)humans. At a second glance, story and reality are not so far apart though: Our role in the process of producing software is being degraded slowly from being actors to cogs in a machine. The spec-driven-dystopia is that we just get handed down some spec, hammer it into the LLM, and weep when our tokens run out because a technofeudal lord decided to hand out fewer of them.\nAs a Haskell programmer, I enjoy writing Haskell. Yes, I like the product we make at work a lot, I like what you can do with my open source libraries, but I really enjoy just the process of expressing my thoughts in this language. I\u2019m assuming this to be true for most of you, and also it not to be true in many other languages, which explains to some amount why enthusiasts of different programming languages have different opinions on how bright or dark the LLM-assisted future is.\nWhen I generate code, a lot of that enjoyment is at risk. So, don\u2019t, maybe. I want to keep writing (at least the enjoyable parts of) Haskell programs, and not having to read and review (too much) generated code. At the same time, I want to put those tokens to some good use that doesn\u2019t slowly burn my brain away.\nI want to show you a way to keep enjoying programming, and at the same time becoming moderately more productive with LLM, instead of appearing to be much more productive and losing all the joy.\nIf you want to just be LLM-abstinent, that\u2019s great as well, and you already know what you\u2019re doing. But there might be reasons you don\u2019t want to be, e.g. you actually need to bring some real productiveness gain to the table, or you don\u2019t want to be left behind while the rest of your team, your company, your industry, is moving towards heavy LLM adoption.\nKeep writing code\nIf you want to keep owning your codebase, you need to keep writing some code. If you let it all be generated, it will turn into an LLM wasteland that only your coding agents can thrive on. So you should keep writing code, otherwise your codebase will eventually be lost.\nAnother reason to keep writing code is to keep being a good programmer. Skills can be lost by not practising, and here the risk is particularly high because there is a really low threshold to giving up your coding work and hand it to an agent. After just a few weeks of not coding and handing everything to agents you\u2019ll notice that you have a hard time returning to coding yourself.\nLLMs are way worse at producing good, human-readable code than advertised. They are somewhat ok at producing code they themselves later work on exclusively. But I\u2019m sure you\u2019ve already experienced the despair of looking at a completely generated file that must contain a bug somewhere, and your perceived inability as a human to find it yourself, because the landscape is just so alien.\nSo how to get to those productivity gains if not by letting agents do the coding? By making them do nearly everything else. Especially the boring work that is a nuisance to you. Ideally those tasks that are not too hard to get right, and easy to check.\nPlanning\nSince the earliest history of computers, they\u2019ve been always used as bookkeeping tool. Use LLMs that way. Amongst other things, it\u2019s a bookkeeping tool that you can address in natural language instead of a formal interface. Convert a huge written conversation between domain experts into actionable todos. Test something, write down the test results, let it organise them into a plan how to fix the defects.\nUse tools like a todo tool, or better even markdown files with frontmatter to make it track planning items properly. LLMs can have a huge context, but still if it is too full it can silently lose information.\nBut don\u2019t let it make any crucial decisions. Make it ask you. If you don\u2019t understand the question, it\u2019s the LLMs fault not to give you the relevant context (or you might be exhausted and need a break). If you return to the same issues again and again, take a step back from the screen and think about it yourself, and return when you have a clear picture of what you want.\nResearching\nWhen you give a researching task to an agent, it\u2019s tempting to watch it querying and \u201cthinking\u201d, to kick off some other agent in another project, or to make a coffee. Of these three, making the coffee is the best option. The one better option is: Research yourself in parallel using a good ol\u2019 search engine. At least roughly know everything the agent will know.\nDon\u2019t just let it research something, accept its results as facts and plan from there. This will lead to embarrassing technical dept.\nThe point of making an agent research is not for it to present all the relevant knowledge to you, or make a better decision than you could have made. The point is that you don\u2019t have to go \u201cLet Me Google That For You\u201d on it. You should understand the domain you\u2019re modelling as good as the agent does, ideally even better.\nMake your agents write down their research results somewhere, with links to their used resources. When it comes back to you later and presents you with a weird proposal, ask it about what the research says and which resource says so. 50% chance says it will discover its own mistake. In the other 50%, read it, now you\u2019re in a position to make a good decision yourself.\nYou are the coder\nThis is the game changer.\nThe typical coding harnesses lure you into \u201cplan first, then let the agent code\u201d. Refuse. Plan together, but then you code. Tell the LLM to research your code base, let it tell you the current todo and bring up all the places you need to edit, make it mention potential pitfalls, let it remind you of relevant background research.\nI work with this workflow, and it is a lot of fun. I\u2019m enjoying my work. Sometimes even more than before LLMs. I always have a clear todo, I don\u2019t need to worry about the overall plan, I can focus, I\u2019m done with the todo quickly because it is well-planned. It\u2019s like agile but without all the annoying processes.\nMake the agents group around your way to work, not the other way around. Maybe you\u2019re an experienced programmer who already knows how you work best. Let the agents do all the incidental work around you that you enjoy less.\nThere are multiple advantages to this workflow:\n\nYou keep doing what you enjoy. If you like programming, do it.\nYou always know what state your code base is in. Been surprised by some weird generated stuff coming from your own vibe coding sessions? Needed to rewrite LLM slop? Lost track of where you are in a session? This way you never have to again.\nYou discover a bad plan early. An agent coder might just go on forever with something that you\u2019ll recognize very quickly as a bad idea.\nYou keep honing your skills. Obviously. You\u2019ll stay a good programmer, or even go on improving.\n\nRare cases when a coding agent is useful\nIdeally for cleanup, small tasks, routine work, low-risk refactorings. You left FIXMEs in your code (maybe on purpose to save time and energy)? You wrote the 3 interesting cases and left the 7 similar boring ones? You have a module reorg in mind and want it benchmarked? Need to swap out an unmaintained library for a better one? Those are valid use cases. Designing something complicated from the ground up is probably not.\nSometimes you run out of time but want something finished, and maybe the rest of the todos in your plan are obvious low-risk tasks. It\u2019s ok to say \u201cI\u2019m afk, finish this\u201d to your supervisor agent, with a bit of luck you come back to a finished feature next morning. But it\u2019s important to do most of the coding work yourself.\nThere are some slight pitfalls here:\n\nSo you wrote those 3 interesting cases and tell the agent to finish the remaining 7 ones because they are just obvious adaptations of those you wrote. Chances are you should abstract instead. Maybe what you\u2019re really doing here is applying a lens or some other optic? Maybe this really is an instance to a popular type class like Traversable? LLMs are famously prone not to recognise this and instead copy huge swathes of code. You as a human are striving for better readable and reasonable code.\nSame goes for \u201cmake it mention potential pitfalls\u201d. Yes, LLMs may be really good at walking through the whole callchain and making sure that all places you should touch are listed in the todo you get handed. But instead of relying on it to find all these couplings you should consider whether your codebase is organised poorly, forcing you to use an LLM for code research in the first place.\n\nThe review cycle\nYou might remember how AI generated images suddenly became much more realistic with the advent of generative adversarial networks. In short, you have one model (the \u201cgenerator\u201d) that generates an image, and another (the \u201cdiscriminator\u201d) that tells it how well it has performed. These together can produce much better results than the generator alone. Applying the idea (which, in its generalized form, is not new at all) to LLM-assisted coding, you get an automated review cycle.\nDon\u2019t accept, don\u2019t even read any artefact produced by an LLM without an automated review cycle. This obviously applies directly to code (in those cases where you still let it be generated), but in particular to planning as well. When an agent codes something, the job is not done when it hands over, the job is done (i.e. fit for human eyes) when a reviewer agent has no more findings on it. The same goes for plans. It\u2019s really tiring to go through logical holes in a plan (refactoring a function in todo 2 that is planned to be written in todo 7) and spot them, so add a review agent that does that.\nI\u2019ve found it surprisingly helpful to have my own code reviewed. Sometimes it will just point out some nits, or insist on bloating up the Haddocks, but often enough it finds a genuine bug or an omission, and keeps me focussed on the actual todo. I recommend adding review cycles to your own work, but I absolutely understand if you don\u2019t want to read an LLMs review of your code. One way to get around this to tell it to fix the remaining findings itself if they\u2019re minor.\nThe frontier\n\nYou\u2019re completely underutilising what frontier models are capable of.\nSome vibe coder on the internet\n\nYes. That\u2019s a logical consequence of my point.\nBut there are multiple reasons why relying on frontier model features is a bad idea.\n\nEnvironmental cost. (Even though this post was not supposed to touch this topic.) Frontier models just use a huge amount of energy. Although this is a guess to some extent since LLM companies aren\u2019t very transparent on how their gadgets work.\nIt\u2019s hard to build up trust in something that pretends to be much cleverer than yourself. At the end, you\u2019re responsible for the code you produce. Not your machine. Blaming someone else for your code is something that bad managers and colleagues do with their employees and coworkers, it\u2019s ridiculous to do with a machine. So use LLMs in a way that you can take responsibility for the results. This only works if you make yourself an integral part of the process.\nThe fanciest models use the most tokens, so there is no telling whether you\u2019ll be able to complete your tasks with them in a given session. Everything that you can do with a smaller model is a safer bet.\nWhen your workflow doesn\u2019t need frontier models, you have a chance of eventually being able to replace them by open weight or open source models, and not be dependent on technofeudal lords at all anymore.\n\nIn the end, you\u2019re doing a complex job. In some aspects of it, LLMs may perform the same or maybe even a bit better. But that\u2019s by far not enough to bow down to them, because of all their downsides. LLMs would have to be many times better than a human developer, use less resources, be more reliable in complex real-world situations, be at least as well-aligned, and in some way accountable for their results, to replace human developers at their core activity.\nNo tokens left?\nMaybe you\u2019ve experienced your work coming to a standstill because you\u2019ve run out of tokens. It\u2019s annoying. Your workflow is now built around a tool that you suddenly have no access to any more. In the extreme case, you can\u2019t go on doing anything. Take this xkcd and imagine \u201cno tokens\u201d instead of \u201ccompiling\u201d for a healthy way to process that situation.\nIf this happens a few times, you might have had the feeling you\u2019ve been betrayed. And you\u2019re right. You have been. How many tokens you have in a given session on a particular plan is an intransparent number at the whim of some big techno feudal lord. It\u2019s not like a commodity you buy on a fair market and then use in a plannable way.\nYou need to stop perceiving the depletion of your tokens as \u201chaving bought too few\u201d, and start treating it as what it is: A service outage. Your LLM company has sold you the promise that you could use the LLM, and they don\u2019t keep it up. The number of maximum tokens in your session may change without you knowing or being able to influence it, so you can\u2019t really plan for it either.\nOf course saving on tokens is imperative. Re-evaluate your agent setups, your usage, your context sizes, your skills, and so on, to save on tokens. But even if you do, and even if you\u2019ve bought a larger seat, it may not be enough.\nAnd instead of seeing it as \u201cyour fault\u201d when you run out after you\u2019ve done everything to use tokens sparingly, see it as a technical fault that you need to be prepared for. When you\u2019ve ever have worked a lot on a train or plane, you know that you have to be prepared for not having internet all the time. Download and cache big assets beforehand. Always have some work to do that you can do offline.\nFor LLM assisted work, this means that you have to make it produce tangible artefacts for everything that you need to work on. Most importantly, if you adapt to the human coder workflow I\u2019ve outlined, make sure that you always have a planned list of todos you can work on. Have fun racing through them, and when your agent is back, tell them to do the cleaning.\nLLM gibberish\nLLM produced text is unlike human text. It gets bad in particular when the LLM actually doesn\u2019t really know what it\u2019s talking about. Treat LLM gibberish as potentially harmful for your psychic health. Don\u2019t consume to much of it. Keep talking to people about your code, especially about greater visions and interesting aspects. Only read LLM artefacts after automated review agents took the edges off.\nWhen your head is spinning, take a break. Yes, even if no agent is currently running in the background and \u201cproducing value\u201d. Your mental health is more important than your work output.\nYour fellow humans\nProgramming is, by large, a social endeavour. For example, in a company or an open source project, we send each other pull requests, write issues and commit messages. This is a form of communication. Even if you\u2019re the only one on your project, your past self writes issues, commit messages and PRs for you future self. Communication between humans is the pillar of software development.\nMake sure you always meet people human-first. Don\u2019t send a completely generated PR to someone. I\u2019ve done this by accident, the other end was rightfully fed up. I\u2019m making sure not to repeat this mistake.\nAgents will readily offer you to write a complete PR body in grammatically correct language, with all the details in there. This is not communication. It\u2019s a tool output. Treat such texts the same way like benchmarking numbers or debug traces: Append them to your handwritten PR body, possibly in a <details>, so people can decide themselves whether they want to read it or not. You\u2019ll find that more often they will not.\nMy journey\nWith all this, I\u2019m more productive than without LLM assistance. It\u2019s difficult to tell exactly, maybe twice as fast? This is less than many full vibe coders will boast with, but that\u2019s ok. I picture myself as a gardener adopting some gentle organic fertilisers, while vibe coders are more like drowning their fields in industrial chemicals. I believe that my way is the more sustainable for now.\nI love programming Haskell, and doing it for a living is my dream job. In the last month I was worried that this dream was now a thing of the past. But all what I wrote about here is what I learned in order to keep this activity enjoyable. It seems to work."
                ],
                "output": "readability",
                "pwd": "/data/archive/1790417197.944724",
                "schema": "ArchiveResult",
                "start_ts": "2026-09-26T10:09:28.886775+00:00",
                "status": "succeeded"
            },
            {
                "cmd": [
                    "/app/node_modules/readability-extractor/readability-extractor",
                    "/tmp/tmp875lvd78",
                    "https://discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705"
                ],
                "cmd_version": "0.0.11",
                "end_ts": "2026-09-26T16:29:53.232217+00:00",
                "index_texts": [
                    "Are you steering towards AI burnout? Afraid of loosing your job to someone with little programming skills, no aspirations to quality, and a huge Claude account? Disappointed about the code quality in your projects, or worse in \u201cyour\u201d own code? This is for you.\nThere are significant and legitimate ethical concerns about frontier LLMs run by big tech companies, these have been discussed at length, I\u2019m aware and agree, this post is not about them. Please don\u2019t mistake me for a pro-LLM techbro.\nAlso: Since people have mistaken my texts for LLM-generated before, I\u2019ll tell you that it is 100% human written without any AI-assistance.\nSouls in the Great Machine\nThere is a great book of this title by Sean Mcmullen that I enjoyed reading as a teenager, and at the first glance it describes the opposite of our situation: A big computer where the individual components are human, and work together to form a calculating unit. On the other hand, LLMs are themselves running on actual computers and pretending to be (super-)humans. At a second glance, story and reality are not so far apart though: Our role in the process of producing software is being degraded slowly from being actors to cogs in a machine. The spec-driven-dystopia is that we just get handed down some spec, hammer it into the LLM, and weep when our tokens run out because a technofeudal lord decided to hand out fewer of them.\nAs a Haskell programmer, I enjoy writing Haskell. Yes, I like the product we make at work a lot, I like what you can do with my open source libraries, but I really enjoy just the process of expressing my thoughts in this language. I\u2019m assuming this to be true for most of you, and also it not to be true in many other languages, which explains to some amount why enthusiasts of different programming languages have different opinions on how bright or dark the LLM-assisted future is.\nWhen I generate code, a lot of that enjoyment is at risk. So, don\u2019t, maybe. I want to keep writing (at least the enjoyable parts of) Haskell programs, and not having to read and review (too much) generated code. At the same time, I want to put those tokens to some good use that doesn\u2019t slowly burn my brain away.\nI want to show you a way to keep enjoying programming, and at the same time becoming moderately more productive with LLM, instead of appearing to be much more productive and losing all the joy.\nIf you want to just be LLM-abstinent, that\u2019s great as well, and you already know what you\u2019re doing. But there might be reasons you don\u2019t want to be, e.g. you actually need to bring some real productiveness gain to the table, or you don\u2019t want to be left behind while the rest of your team, your company, your industry, is moving towards heavy LLM adoption.\nKeep writing code\nIf you want to keep owning your codebase, you need to keep writing some code. If you let it all be generated, it will turn into an LLM wasteland that only your coding agents can thrive on. So you should keep writing code, otherwise your codebase will eventually be lost.\nAnother reason to keep writing code is to keep being a good programmer. Skills can be lost by not practising, and here the risk is particularly high because there is a really low threshold to giving up your coding work and hand it to an agent. After just a few weeks of not coding and handing everything to agents you\u2019ll notice that you have a hard time returning to coding yourself.\nLLMs are way worse at producing good, human-readable code than advertised. They are somewhat ok at producing code they themselves later work on exclusively. But I\u2019m sure you\u2019ve already experienced the despair of looking at a completely generated file that must contain a bug somewhere, and your perceived inability as a human to find it yourself, because the landscape is just so alien.\nSo how to get to those productivity gains if not by letting agents do the coding? By making them do nearly everything else. Especially the boring work that is a nuisance to you. Ideally those tasks that are not too hard to get right, and easy to check.\nPlanning\nSince the earliest history of computers, they\u2019ve been always used as bookkeeping tool. Use LLMs that way. Amongst other things, it\u2019s a bookkeeping tool that you can address in natural language instead of a formal interface. Convert a huge written conversation between domain experts into actionable todos. Test something, write down the test results, let it organise them into a plan how to fix the defects.\nUse tools like a todo tool, or better even markdown files with frontmatter to make it track planning items properly. LLMs can have a huge context, but still if it is too full it can silently lose information.\nBut don\u2019t let it make any crucial decisions. Make it ask you. If you don\u2019t understand the question, it\u2019s the LLMs fault not to give you the relevant context (or you might be exhausted and need a break). If you return to the same issues again and again, take a step back from the screen and think about it yourself, and return when you have a clear picture of what you want.\nResearching\nWhen you give a researching task to an agent, it\u2019s tempting to watch it querying and \u201cthinking\u201d, to kick off some other agent in another project, or to make a coffee. Of these three, making the coffee is the best option. The one better option is: Research yourself in parallel using a good ol\u2019 search engine. At least roughly know everything the agent will know.\nDon\u2019t just let it research something, accept its results as facts and plan from there. This will lead to embarrassing technical dept.\nThe point of making an agent research is not for it to present all the relevant knowledge to you, or make a better decision than you could have made. The point is that you don\u2019t have to go \u201cLet Me Google That For You\u201d on it. You should understand the domain you\u2019re modelling as good as the agent does, ideally even better.\nMake your agents write down their research results somewhere, with links to their used resources. When it comes back to you later and presents you with a weird proposal, ask it about what the research says and which resource says so. 50% chance says it will discover its own mistake. In the other 50%, read it, now you\u2019re in a position to make a good decision yourself.\nYou are the coder\nThis is the game changer.\nThe typical coding harnesses lure you into \u201cplan first, then let the agent code\u201d. Refuse. Plan together, but then you code. Tell the LLM to research your code base, let it tell you the current todo and bring up all the places you need to edit, make it mention potential pitfalls, let it remind you of relevant background research.\nI work with this workflow, and it is a lot of fun. I\u2019m enjoying my work. Sometimes even more than before LLMs. I always have a clear todo, I don\u2019t need to worry about the overall plan, I can focus, I\u2019m done with the todo quickly because it is well-planned. It\u2019s like agile but without all the annoying processes.\nMake the agents group around your way to work, not the other way around. Maybe you\u2019re an experienced programmer who already knows how you work best. Let the agents do all the incidental work around you that you enjoy less.\nThere are multiple advantages to this workflow:\n\nYou keep doing what you enjoy. If you like programming, do it.\nYou always know what state your code base is in. Been surprised by some weird generated stuff coming from your own vibe coding sessions? Needed to rewrite LLM slop? Lost track of where you are in a session? This way you never have to again.\nYou discover a bad plan early. An agent coder might just go on forever with something that you\u2019ll recognize very quickly as a bad idea.\nYou keep honing your skills. Obviously. You\u2019ll stay a good programmer, or even go on improving.\n\nRare cases when a coding agent is useful\nIdeally for cleanup, small tasks, routine work, low-risk refactorings. You left FIXMEs in your code (maybe on purpose to save time and energy)? You wrote the 3 interesting cases and left the 7 similar boring ones? You have a module reorg in mind and want it benchmarked? Need to swap out an unmaintained library for a better one? Those are valid use cases. Designing something complicated from the ground up is probably not.\nSometimes you run out of time but want something finished, and maybe the rest of the todos in your plan are obvious low-risk tasks. It\u2019s ok to say \u201cI\u2019m afk, finish this\u201d to your supervisor agent, with a bit of luck you come back to a finished feature next morning. But it\u2019s important to do most of the coding work yourself.\nThere are some slight pitfalls here:\n\nSo you wrote those 3 interesting cases and tell the agent to finish the remaining 7 ones because they are just obvious adaptations of those you wrote. Chances are you should abstract instead. Maybe what you\u2019re really doing here is applying a lens or some other optic? Maybe this really is an instance to a popular type class like Traversable? LLMs are famously prone not to recognise this and instead copy huge swathes of code. You as a human are striving for better readable and reasonable code.\nSame goes for \u201cmake it mention potential pitfalls\u201d. Yes, LLMs may be really good at walking through the whole callchain and making sure that all places you should touch are listed in the todo you get handed. But instead of relying on it to find all these couplings you should consider whether your codebase is organised poorly, forcing you to use an LLM for code research in the first place.\n\nThe review cycle\nYou might remember how AI generated images suddenly became much more realistic with the advent of generative adversarial networks. In short, you have one model (the \u201cgenerator\u201d) that generates an image, and another (the \u201cdiscriminator\u201d) that tells it how well it has performed. These together can produce much better results than the generator alone. Applying the idea (which, in its generalized form, is not new at all) to LLM-assisted coding, you get an automated review cycle.\nDon\u2019t accept, don\u2019t even read any artefact produced by an LLM without an automated review cycle. This obviously applies directly to code (in those cases where you still let it be generated), but in particular to planning as well. When an agent codes something, the job is not done when it hands over, the job is done (i.e. fit for human eyes) when a reviewer agent has no more findings on it. The same goes for plans. It\u2019s really tiring to go through logical holes in a plan (refactoring a function in todo 2 that is planned to be written in todo 7) and spot them, so add a review agent that does that.\nI\u2019ve found it surprisingly helpful to have my own code reviewed. Sometimes it will just point out some nits, or insist on bloating up the Haddocks, but often enough it finds a genuine bug or an omission, and keeps me focussed on the actual todo. I recommend adding review cycles to your own work, but I absolutely understand if you don\u2019t want to read an LLMs review of your code. One way to get around this to tell it to fix the remaining findings itself if they\u2019re minor.\nThe frontier\n\nYou\u2019re completely underutilising what frontier models are capable of.\nSome vibe coder on the internet\n\nYes. That\u2019s a logical consequence of my point.\nBut there are multiple reasons why relying on frontier model features is a bad idea.\n\nEnvironmental cost. (Even though this post was not supposed to touch this topic.) Frontier models just use a huge amount of energy. Although this is a guess to some extent since LLM companies aren\u2019t very transparent on how their gadgets work.\nIt\u2019s hard to build up trust in something that pretends to be much cleverer than yourself. At the end, you\u2019re responsible for the code you produce. Not your machine. Blaming someone else for your code is something that bad managers and colleagues do with their employees and coworkers, it\u2019s ridiculous to do with a machine. So use LLMs in a way that you can take responsibility for the results. This only works if you make yourself an integral part of the process.\nThe fanciest models use the most tokens, so there is no telling whether you\u2019ll be able to complete your tasks with them in a given session. Everything that you can do with a smaller model is a safer bet.\nWhen your workflow doesn\u2019t need frontier models, you have a chance of eventually being able to replace them by open weight or open source models, and not be dependent on technofeudal lords at all anymore.\n\nIn the end, you\u2019re doing a complex job. In some aspects of it, LLMs may perform the same or maybe even a bit better. But that\u2019s by far not enough to bow down to them, because of all their downsides. LLMs would have to be many times better than a human developer, use less resources, be more reliable in complex real-world situations, be at least as well-aligned, and in some way accountable for their results, to replace human developers at their core activity.\nNo tokens left?\nMaybe you\u2019ve experienced your work coming to a standstill because you\u2019ve run out of tokens. It\u2019s annoying. Your workflow is now built around a tool that you suddenly have no access to any more. In the extreme case, you can\u2019t go on doing anything. Take this xkcd and imagine \u201cno tokens\u201d instead of \u201ccompiling\u201d for a healthy way to process that situation.\nIf this happens a few times, you might have had the feeling you\u2019ve been betrayed. And you\u2019re right. You have been. How many tokens you have in a given session on a particular plan is an intransparent number at the whim of some big techno feudal lord. It\u2019s not like a commodity you buy on a fair market and then use in a plannable way.\nYou need to stop perceiving the depletion of your tokens as \u201chaving bought too few\u201d, and start treating it as what it is: A service outage. Your LLM company has sold you the promise that you could use the LLM, and they don\u2019t keep it up. The number of maximum tokens in your session may change without you knowing or being able to influence it, so you can\u2019t really plan for it either.\nOf course saving on tokens is imperative. Re-evaluate your agent setups, your usage, your context sizes, your skills, and so on, to save on tokens. But even if you do, and even if you\u2019ve bought a larger seat, it may not be enough.\nAnd instead of seeing it as \u201cyour fault\u201d when you run out after you\u2019ve done everything to use tokens sparingly, see it as a technical fault that you need to be prepared for. When you\u2019ve ever have worked a lot on a train or plane, you know that you have to be prepared for not having internet all the time. Download and cache big assets beforehand. Always have some work to do that you can do offline.\nFor LLM assisted work, this means that you have to make it produce tangible artefacts for everything that you need to work on. Most importantly, if you adapt to the human coder workflow I\u2019ve outlined, make sure that you always have a planned list of todos you can work on. Have fun racing through them, and when your agent is back, tell them to do the cleaning.\nLLM gibberish\nLLM produced text is unlike human text. It gets bad in particular when the LLM actually doesn\u2019t really know what it\u2019s talking about. Treat LLM gibberish as potentially harmful for your psychic health. Don\u2019t consume to much of it. Keep talking to people about your code, especially about greater visions and interesting aspects. Only read LLM artefacts after automated review agents took the edges off.\nWhen your head is spinning, take a break. Yes, even if no agent is currently running in the background and \u201cproducing value\u201d. Your mental health is more important than your work output.\nYour fellow humans\nProgramming is, by large, a social endeavour. For example, in a company or an open source project, we send each other pull requests, write issues and commit messages. This is a form of communication. Even if you\u2019re the only one on your project, your past self writes issues, commit messages and PRs for you future self. Communication between humans is the pillar of software development.\nMake sure you always meet people human-first. Don\u2019t send a completely generated PR to someone. I\u2019ve done this by accident, the other end was rightfully fed up. I\u2019m making sure not to repeat this mistake.\nAgents will readily offer you to write a complete PR body in grammatically correct language, with all the details in there. This is not communication. It\u2019s a tool output. Treat such texts the same way like benchmarking numbers or debug traces: Append them to your handwritten PR body, possibly in a <details>, so people can decide themselves whether they want to read it or not. You\u2019ll find that more often they will not.\nMy journey\nWith all this, I\u2019m more productive than without LLM assistance. It\u2019s difficult to tell exactly, maybe twice as fast? This is less than many full vibe coders will boast with, but that\u2019s ok. I picture myself as a gardener adopting some gentle organic fertilisers, while vibe coders are more like drowning their fields in industrial chemicals. I believe that my way is the more sustainable for now.\nI love programming Haskell, and doing it for a living is my dream job. In the last month I was worried that this dream was now a thing of the past. But all what I wrote about here is what I learned in order to keep this activity enjoyable. It seems to work."
                ],
                "output": "readability",
                "pwd": "/data/archive/1790417197.944724",
                "schema": "ArchiveResult",
                "start_ts": "2026-09-26T16:29:51.365764+00:00",
                "status": "succeeded"
            }
        ],
        "screenshot": [],
        "singlefile": [],
        "title": [
            {
                "cmd": [
                    "curl",
                    "--silent",
                    "--location",
                    "--compressed",
                    "--max-time",
                    "120",
                    "--user-agent",
                    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)",
                    "https://discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705"
                ],
                "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)",
                "end_ts": "2026-09-26T13:39:18.902348+00:00",
                "index_texts": null,
                "output": "How to keep enjoying programming in a world of LLMs - Uncategorized - Haskell Community",
                "pwd": "/data/archive/1790417197.944724",
                "schema": "ArchiveResult",
                "start_ts": "2026-09-26T13:39:18.880888+00:00",
                "status": "succeeded"
            },
            {
                "cmd": [
                    "curl",
                    "--silent",
                    "--location",
                    "--compressed",
                    "--max-time",
                    "120",
                    "--user-agent",
                    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)",
                    "https://discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705"
                ],
                "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)",
                "end_ts": "2026-09-26T10:09:28.879809+00:00",
                "index_texts": null,
                "output": "How to keep enjoying programming in a world of LLMs - Uncategorized - Haskell Community",
                "pwd": "/data/archive/1790417197.944724",
                "schema": "ArchiveResult",
                "start_ts": "2026-09-26T10:09:28.859682+00:00",
                "status": "succeeded"
            },
            {
                "cmd": [
                    "curl",
                    "--silent",
                    "--location",
                    "--compressed",
                    "--max-time",
                    "120",
                    "--user-agent",
                    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)",
                    "https://discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705"
                ],
                "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)",
                "end_ts": "2026-09-26T16:29:51.358513+00:00",
                "index_texts": null,
                "output": "How to keep enjoying programming in a world of LLMs - Uncategorized - Haskell Community",
                "pwd": "/data/archive/1790417197.944724",
                "schema": "ArchiveResult",
                "start_ts": "2026-09-26T16:29:51.336608+00:00",
                "status": "succeeded"
            }
        ],
        "wget": [
            {
                "cmd": [
                    "wget",
                    "--no-verbose",
                    "--adjust-extension",
                    "--convert-links",
                    "--force-directories",
                    "--span-hosts",
                    "--no-parent",
                    "-e",
                    "robots=off",
                    "--reject=js,mjs,woff,woff2,ttf,otf,eot,mp4,m4v,mov,webm,ogv,mkv,avi,flv",
                    "--timeout=120",
                    "--restrict-file-names=windows",
                    "--page-requisites",
                    "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) wget/GNU Wget 1.21.3",
                    "--compression=auto",
                    "--timestamping",
                    "https://discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705"
                ],
                "cmd_version": "GNU Wget 1.21.3",
                "end_ts": "2026-09-26T13:39:18.871812+00:00",
                "index_texts": null,
                "output": "discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705.html",
                "pwd": "/data/archive/1790417197.944724",
                "schema": "ArchiveResult",
                "start_ts": "2026-09-26T13:39:14.034333+00:00",
                "status": "succeeded"
            },
            {
                "cmd": [
                    "wget",
                    "--no-verbose",
                    "--adjust-extension",
                    "--convert-links",
                    "--force-directories",
                    "--span-hosts",
                    "--no-parent",
                    "-e",
                    "robots=off",
                    "--reject=js,mjs,woff,woff2,ttf,otf,eot,mp4,m4v,mov,webm,ogv,mkv,avi,flv",
                    "--timeout=120",
                    "--restrict-file-names=windows",
                    "--page-requisites",
                    "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) wget/GNU Wget 1.21.3",
                    "--compression=auto",
                    "--timestamping",
                    "https://discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705"
                ],
                "cmd_version": "GNU Wget 1.21.3",
                "end_ts": "2026-09-26T10:09:28.847941+00:00",
                "index_texts": null,
                "output": "discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705.html",
                "pwd": "/data/archive/1790417197.944724",
                "schema": "ArchiveResult",
                "start_ts": "2026-09-26T10:09:23.811238+00:00",
                "status": "succeeded"
            },
            {
                "cmd": [
                    "wget",
                    "--no-verbose",
                    "--adjust-extension",
                    "--convert-links",
                    "--force-directories",
                    "--span-hosts",
                    "--no-parent",
                    "-e",
                    "robots=off",
                    "--reject=js,mjs,woff,woff2,ttf,otf,eot,mp4,m4v,mov,webm,ogv,mkv,avi,flv",
                    "--timeout=120",
                    "--restrict-file-names=windows",
                    "--page-requisites",
                    "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) wget/GNU Wget 1.21.3",
                    "--compression=auto",
                    "--timestamping",
                    "https://discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705"
                ],
                "cmd_version": "GNU Wget 1.21.3",
                "end_ts": "2026-09-26T16:29:51.326551+00:00",
                "index_texts": null,
                "output": "discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705.html",
                "pwd": "/data/archive/1790417197.944724",
                "schema": "ArchiveResult",
                "start_ts": "2026-09-26T16:29:46.599353+00:00",
                "status": "succeeded"
            }
        ]
    },
    "icons": null,
    "is_archived": true,
    "is_static": false,
    "latest": {
        "archive_org": null,
        "dom": null,
        "favicon": "favicon.ico",
        "git": null,
        "media": null,
        "pdf": null,
        "screenshot": null,
        "singlefile": null,
        "title": "How to keep enjoying programming in a world of LLMs - Uncategorized - Haskell Community",
        "warc": null,
        "wget": "discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705.html"
    },
    "link_dir": "/data/archive/1790417197.944724",
    "newest_archive_date": "2026-09-26T16:29:53.246562+00:00",
    "num_failures": 0,
    "num_outputs": 18,
    "oldest_archive_date": "2026-09-26T10:09:22.667854+00:00",
    "path": "/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705",
    "schema": "Link",
    "scheme": "https",
    "snapshot_id": "72e4ef3f-036b-4a0b-a33b-1b2818944232",
    "sources": [
        "/data/sources/1790417197-import.txt"
    ],
    "tags": ",war-wiki",
    "tags_str": "war-wiki",
    "timestamp": "1790417197.944724",
    "title": "How to keep enjoying programming in a world of LLMs - Uncategorized - Haskell Community",
    "updated": "2026-09-26T16:29:45.410871+00:00",
    "updated_date": "2026-09-26 16:29",
    "url": "https://discourse.haskell.org/t/how-to-keep-enjoying-programming-in-a-world-of-llms/14705"
}