The hidden cost of AI coding

> Some people love programming

> Other people see all that as an means to an end

I think it's worth pointing out that most people are both these things at different times.

There's things I care about and want a deep understanding of but there's plenty of tasks I want to just "go away". If I had an junior coder - I'd be delegating these. Instead I use AI when I can.

There's also tasks where I want a jump start. I prefer fixing/improving code over writing from scratch so often a bad AI attempt is still valuable to me.

Many have said that it's useful to delegate writing boilerplate code to an AI so that you can focus on the interesting bits that you do want to write yourself, for the sake of enjoying writing code.

I recognize that and I kind of agree, but I think I don't entirely. Writing the "boring" boilerplate gives me time to think about the hard stuff while still tinkering with something. I think the effect is similar to sleeping on it or taking a walk, but without interrupting the mental cruncing that's going in my brain during a good flow. I piece together something mundane that is as uninteresting as it is mandatory, but at the same time my subconscious is thinking about the real stuff. It's easier that way because the boilerplate does actually, besides being boring, still connect to the real stuff, ultimately.

So, you're kind of working on the same problem even if you're just letting your fingers keep typing something easy. That generates nice waves of intensity for my work. My experience regarding AI tends to break this sea of subconsciousness: you need to focus on getting the AI to do the right thing which, unlike typing it yourself, is ancillary to the original problem. Maybe it's just a matter of practise and at some point I can keep my mind on the domain in question eventhough I'm working an AI instead of typing boilerplate myself.

The first time you write the code to accomplish something you get your highs.

IMHO there's no joy in doing the same thing multiple times. DRY doesn't help with that, you end up doing a lot of menial work to adapt or integrate previous code.

Most of the for-profit coding is very boring.

> On the other hand, I know people that want to jump straight to the end result. They have some melody or idea in their head, and they just want to generate some song that revolves around that idea. I don't really look down on those people, even though the snobs might argue that they're not "real musicians". I don't understand them, but that's not really something I have to understand either.

So if someone generates their music with AI to get their idea to music you don’t look down on it?

Personally I do, if you don’t have the means to get to the end you shouldn’t get to the end and that goes double in a professional setting. If you are just generating for your own enjoyment go off I guess but if you are publishing or working for someone that’ll publish (aka a professional setting) you should be the means to the end, not AI.

I've always distilled this down to people who like the "craft" and those who like the "result".

Of course, everything is on a scale so it's not either/or.

But, like you, how I get there matters to me, not just the destination.

Outside the context of music, a project could be super successful but if the journey was littered with unnecessary stress due to preventable reasons, it will still leave a bad taste in my mouth.

Some writers like to write. Some like to have written.

The issue with programming is that it isn't like music or really any other skill where you get feedback right away and operate in a well understood environment. And a lot of patterns are not well designed as they are often based on what a single developer things the behavior ought to be instead of something more deterministic like the laws of physics that influence the cord patterns we use in music.

Nope, your code might look excellent. Why the hell isn't it running though? Three hours later you find you added a b when you closed your editor somewhere in the code in a way your linter didn't pick up and the traceback isn't clear about, maybe you broke some all important regex, it doesn't matter. One second, it's fixed, and you just want to throw the laptop out the window and never work on this project again. So god damned stupid.

And other things are frusterating too. Open a space deliminated python file, god forbid you add a tab without thinking. And what is crazy about that is if the linter is smart enough to say "hey you put a tab here instead of spaces for indent" then why does it even throw the error and not just accept both spaces and tabs? Just another frustration.

Really I would love to just go at it, write code, type, fly, be in the flow state, like one does building something with the hands or making music or doing anything in the physical world. But no. Constant whack a mole. Constantly hitting the brakes. Constant blockers. How long will this take to implement? I have no fucking idea man, could be 5 seconds or 5 weeks and you don't often know until you spend the 5 seconds and see that didn't do it yet.

I’m in group A and B. I do programming for the sake for it at home. I read tons of technical books for the love of it. At work, though, I do whatever the company wants or whatever they allow me… I just do it for the money.

Some people like to play a musical instrument, others to compose music. Those who play range from classicists, who have limited ability to improvise or interpret, to popular or jazz, or composition, where creativity and subtle expression is the life blood of the work.

Programming is similar to music. (A great many software innovators in the 70s and 80s had musical roots). But AI prunes away all the creativity and stylistic expression from the composition and the performance when designing and building software, reducing the enterprise to mere specification -- as if the libretto of the opera were merely an outline, and even that was based on Cliff Notes.

The case for using AI to code is driven strictly by economics and speed. Stylistically and creatively, AI is a no-brainer.

I think category A is too broad. I enjoy building systems, not typing code. You can still get that joy having an LLM do the coding. You don't need to let it do the systems design. Also, some of the building process is the system I care about it, and some of it is tooling for the system I care about. Those tools are means to an end and I am happy to defer the entire process to the LLM, and those are stand-alone usually which is right in it's wheelhouse.

I think I am somewhere between the two groups you mention

I don't really get any joy from the act of coding, but I also take a lot of pride in doing a good job.

Cutting corners and producing sloppy work is anathema to me, even when I don't really enjoy the work itself

Any work worth doing is worth doing a good job on, even if I don't enjoy the work itself

> Some people love programming, for the sake of programming itself.

And this is what is causing the friction against LLM's (which are quite useful for getting up to speed with a new concept / language ), the programming itself is the fun bit - I still want to do that bit!

Have you heard the saying there is too much performance in the practice room? It's the same with programming. Performance is the goal, and practice is how you get there. No one seems to be in danger of practicing too much though.

I think a closer analogy is:

- A singer might learn to play guitar to sing along to it. Guitar is a means to an end; it is simply a tool to them.

- A guitarist learns to play guitar due to love of the instrument.

Sounds a bit like the different subjects of "applied math" vs "math"

Some like proving and deriving, for others it's a tool to solve other problems

i mean how far are you willing to take that argument? every decade has just been a new abstraction, imagine people flipping switches or in raw assembly talking about how they don't "understand" you now with your no effort. or even those who don't "understand" why you use your autocomplete and fancy IDE, preferring a simple text editor.

i say this as someone who cut my teeth on this stuff growing up and seeing the evolution, it's both. and at some point it's honestly elitism and gatekeeping. i sort of cringe when it's called a "craft" because it's not like woodworking or something. the process is both full of joy but so is the end result, and the nature of our industry is that the process is ALWAYS changing.

you accumulate a depth of knowledge and watch as it washes away in a few years. that kind of change, and the big kind of change that AI brings scares people so they start clinging to it like it's some kind of centuries old trade lol.

> The rest is boiler plate, cargo-culted, Dockerfile, build system and bash environment variable passing circle of hell that I really could care less about.

Even more so, I remember making a Chrome extension and feeling intimidated. I knew that I'd be comfortable with most of it given that JS is used but I just didn't know how to start.

With an LLM it is way faster to spin up some default config and get going versus reading a tutorial. What I've noticed in that respect is that I just read what it does and then immediately reason why it's there. "Oh, there's a manifest.json file with permissions and a few other things, fair, makes sense. Oh, so you have the HTML/CSS/JS of the extension, you have the HTML/CSS/JS of the page you're injecting some code into and you have the JS of a background worker. Ah yea, I get that."

And then I just get immediately on coding.

So much this. The AI takes care of the tedious line by line what’s-the-name-of-that-stdlib-function parts (and most of the tedious test-writing parts) and lets me focus on the interesting bits like what it is I want to build and how the pieces should fit together. And debugging, which I find satisfying.

Sadly, I find it sorely lacking at dealing with build systems and that particular type of boilerplate, mostly because it seems to mix up different versions of things too much and gives you totally broken setups more often than not. I’d just as soon never deal with the he’ll that is front end build/lint/test config again.

I think the fear for those of us who love coding, stability and security, that we are going to be confronted with apples that are rotten on the inside and our work, our love, is going to turn (even more so) into pain. The challenge in computing is that the powers that decide have little overview over the actual quality and longevity of any endeavour.

I work as a consultant assessing other people's code and it's hard not to lose my religion, sort of speak.

They perhaps haven’t taken away your keyboard but anecdotally, a few friends work at places where their boss is requiring them to use the LLMs. So you may not have to code with them but some people are starting to be chained to them.

> The rest is boiler plate, cargo-culted, Dockerfile, build system and bash environment variable passing

I keep seeing people saying to use an LLM to write boilerplate, but like... do you not just copy that from another project where you already wrote it?

Like many others writing here, I enjoy coding (well, mostly anyway), especially the when it requires deep thought and patient experimentation to get anywhere. It's also great to preside over finally wiring together the routines (modules, libraries) that bind a project into a coherent whole.

Haven't much used AI to assist. After all, hard enough finding authentic humans capable and willing to voluntarily review/critique one's code. So far AI doesn't consistently provide that kind of help. OTOH seems almost certain over time AI systems will improve in terms of specific and comprehensive "insights" into the particular types of code one is writing.

I think an issue is that human creativity is hard to measure. Likely enough AI is even tougher to assess. Probably AI will increasingly be assigned tasks like constructing project skeletons, assuring parts can be joined together without undue strain, handling "boilerplate" and other routine chores. To be sure the landscape will look different in 50 years, I'm certain we'd be amazed were we able to see what future systems will be doing.

In any case, we shouldn't hesitate to use tools that genuinely boost our creativity. One badly needed role would be enabling development of higher reliability software. Still that's a far cry from the contributions emanating from the best of human originality, talent and motivation.

I read one characterization which is that LLMs don't give new information (except to the user learning) but they reorganize old information.

> doesn't judge or sneer at you, or tell you to "RTFM". It's better than any human help, even if its not always right because its at least always more reliable and you don't have to bother some grey beard who probably hates you anyway.

That’s a lot of trauma you’re dealing with.

I think you're robbing yourself.

Of course, it all depends how you use the LLM. While the same can be true for StackOverflow, the LLMs just scale the issues up.

  > The rest is boiler plate, cargo-culted, Dockerfile, build system and bash environment variable passing circle of hell that I really could care less about.

Except you do care. It's why you're frustrated and annoyed. And good!!! That feeling is because what you're describing requires solving. If something is routine, automate it. But it's really not good to automate in a statistical way, especially when that statistical tool is optimized for human preference. Because remember that also means mistakes are optimized to be missed by humans.[0]

With expertise in anything, I'm sorry, but you also got to do the shit work. To be a great musician you gotta practice boring scales. It's true even if you just want to be a sub par one.

But a little grumpy is good. It drives you to fix things, and frankly, that's our job. The things that are annoying and creating friction don't need be repeated over and over, they need alternative solutions. The scripts you build are valuable. The "useless" knowledge you gain isn't so useless. Those little details add up without you knowing and make you better.

That undocumented code makes you frustrated and reminds you to document your own. You don't want to be a hypocrite. The author of the thing you're using probably thought the same thing: "No one is gonna use this garbage, I'm not going to waste my time documenting it". Yet here we are. Over and over again yet we don't learn the lesson.

I'm not gonna deny there's assholes. There are. But even assholes teach you. At worst, they teach you how not to act.

And some people are you telling you to RTM and not RTFM. Sure, it has lots of extra information in it that you don't need to get your specific job done, but have you also considered that it has lots of extra information in it? The person that wrote it clearly thought the context was important. Maybe it isn't. In that case, you learned a lesson in how not to write documentation!

What I'm getting at is that there's a lot of learning done all over the place. Trying to take out all the work and only have "the fun" is harming yourself and has a large potential to make less time for the fun stuff[0]. I'd be surprised if I'm alone in this, but a lot of stuff I enjoy now was stuff that originally frustrated me. IME this is pretty common! It's true for every person I know. Similarly, it's also true for things I learned that I thought I'd never use again. It always has a way of coming back.

I'm not going to pretend it's all fun and games. I'm explicitly saying it's not. But I'm confident in the long run it's better. Despite the lack of accuracy, I use LLMs (and Google, and even the TFM) like I would a solution guide the homework problems when I was in school. Try first, then consult. The struggle is an investment in your future. It sucks, but if all the best things in life were easy then we'd all have them. I'm just trying to convince you that it pays off.

I'm completely aware this is all context dependent. There's a time and place for everything. But given the percentages you mention (even taken as exaggeration), something sounds wrong. It's hard to suggest specific solutions without details but I'd be surprised if there weren't better and more rewarding solutions than having the LLM do it for you

[0] That's the big danger and what drives distrust in them. Because you need to work extra hard to find mistakes, increasing workload, not decreasing, because debugging is most of the job!

This.

Frankly I don't want to spend 2 hours reading documentation just to find out some arcane incantation that gets the computer to do what I want it to do.

The interesting part of programming to me is designing the logic. It's the 'this, then that, except when this' flow that I'm really interested in, not the search for some obscure library that has some function that will parse this csv.

Llms are great for that, and let me get away from the pointless grind and into the things that I enjoy and are actually providing value.

The pair programming is also a super good thing. I work best when I can spitball and throw out random ideas and get quick feedback. Llms let me do that without bothering others who have their own work to do.

Same as when higher-level languages replaced assembly for a lot of use cases. And btw, at least in places I've worked, better traditional tooling would replace a lot more headcount than AI would.

> Solving problems for real people. Isn't the answer here kind of obvious?

No. There are a thousand other ways of solving problems for real people, so that doesn't explain why some choose software development as their preferred method.

Presumably, the reason for choosing software development as the method of solving problems for people is because software development itself brings joy. Different people find joy in different aspects even of that, though.

For my part, the stuff that AI is promising to automate away is much of the stuff that I enjoy about software development. If I don't get to do that, that would turn my career into miserable drudgery.

Perhaps that's the future, though. I hope not, but if it is, then I need to face up to the truth that there is no role for me in the industry anymore. That would pretty much be a life crisis, as I'd have to find and train for something else.

> Solving problems for real people. Isn't the answer here kind of obvious?

Look at the majority of the tech sector for the last ten years or so and tell me this answer again.

Like I guess this is kind of true, if "problems for real people" equals "compensating for inefficiencies in our system for people with money" and "solutions" equals "making a poor person do it for them and paying them as little as legally possible."

solving real problems is the core of it, but for a lot of people the joy and meaning come from how they solve them too. the shift to AI tools might feel like outsourcing the interesting part, even if the outcome is still useful. side projects will stick around for sure, but i think it's fair to ask what the day-to-day feels like when more of it becomes reviewing and prompting rather than building.

I always wonder what kind of projects are we talking about. I am currently writing a compiler and simulation engine for differential-algebraic equations. I tried few models, hoping they would help me, but they could not provide any help with small details nor with bigger building blocks.

I guess if you code stuff that had been coded a lot in public repos, it is fine, otherwise AI does not help in any way. Actually, I think I wasted more time trying to make it produce the output I wish for than it took me to do this myself.

people seem to forget this type of argument from the article was used for stack overflow for years, calling it the destruction of programming. "How can you get into flow when you are just copying and pasting?". Those same people are now all sour grapes for AI assisted development. There will always be detractors saying that the documentation you are using is wrong, the tools that you are using are wrong, and the methodology you are using is wrong.

AI assisted development is no different from managing an engineering team. "How can you trust outsourced developers to do anything right? You won't understand the code when it breaks"... "How can you use an IDE, vim is the only correct tool" etc etc etc.

Nothing has changed besides the process. When people started jumping on object orientation they called procedures the devil itself, just as procedures were once called structured programming and came to banish away the considered harmful goto. Everything is considered harmful when theres something new around the corner that promises to either make development more productive or developers more interchangeable. These are institutional requirements and will never go away.

Embrace AIOP (AI oriented programming) to banish copy and paste google driven development which is now considered harmful.

I'm a classic engineer, so lots of experience with systems and breaking down problems, but probably <150 hours programming experience over 15 years. I know how computers work and "think", but I an awful at communicating with them. Anytime I have needed to program something I gotta crash course the language for a few days.

Having LLMs like 2.5 now are total game changers. I can basically flow chart a program and have Gemini manifest it. I can break up the program into modules and keep spinning up new instances when context gets too full.

The program I am currently working on is up to ~5500 LOC, probably across 10ish 2.5 instances. It's basically an inventory and BOM management program that takes in bloated excel BOMs and inventory, and puts it in an SQLite database, and has a nice GUI. Absolutely insane how much faster SQLite is for databases than excel, lol.

This is the way. I feel like a kid too again. It's way more fun actually. As a kid I got too frustrated for not being able to install my WAMP stack.

Added joy for me as well mostly by giving me the relevant API calls I need straight away, from publically available documentation, instead of having to read docs myself. "How do I do X in Y"

And if something's not obvious I can always fetch the specifics of any particular calls. But at least I didn't have to find the name of that call in the first place.

I’m right there with you on this.

Thanks for the comment. You articulated how I feel about this situation very well.

I love coding but I also love AI.

I don't know if I'm a minority but I'd like to think there are a lot of folks like me out there.

You can compare it to someone who is writing assembly code and now they've been introduced to C. They were happy writing assembly but now they're thrilled they can write things more quickly.

Sure, AI could lead us to write buggier code. Sure, AI could make us dumber because we just have AI write things we don't understand. But neither has to be the case.

With better tools, we'll be able to do more ambitious things.

Right, just how back in the day, people who loved writing assembly hated high level languages and people who found assembly too tedious loved compilers.

Cant one enjoy both? After all, coding with AI in practice is still coding, just with a far higher intensity.

What if I prefer to have a clone of me doing my coding, and then I throw my clone under the bus and start to (angrily) hyperfocus explore and change every piece to be beautiful? Does this mean I love coding or I hate coding?

It's definitely a personality thing, but that's so much more productive for me, than convincing myself to do all the work from scratch after I had a design.

I guess this means I hate coding, and I only love the dopamine from designing and polishing my work instead of making things work. I'm not sure though, this feels like the opposite of hate coding.

yeah i definitely enjoy the craft and love of writing boilerplate or manually correcting simple errors or looking up functions /s. i hate how it's even divided into "two camps", it's more like a big venn diagram.

I replaced "code" for "singing" to make a point.

> This comment section really shows the stark divide between people who love singing and thus hate AI-assisted singing, and people who hate singing and thus love AI-assisted singing.

> Honestly, I suspect the people who would prefer to have someone or something else do their singing, are probably the singers who are already outputting the worst singing right now.

The point is: just because you love something, doesn't mean you're good at it. It is of course positively correlated with it. I am in fact a better singer because I love to sing compared to if I never practiced. But I am not a good singer, I am mediocre at best (I chose this example for a reason, I love singing as well as coding! :-D)

And while it is easier to become good at coding than at singing - for professional purposes at least - I believe that the effect still holds.

I started “coding” in 1986 in assembly on an Apple //e and by the time I graduated from college, I had experience with 4 different processor families - 65C02, 68K, PPC and x86. I spent the first 15 years of my career programming in C and C++ along with other languages.

Coding is just a means to an end - creating enough business value to convince the company I’m working for to give me money that I can exchange for food and shelter.

If AI can help me do that faster, I’m going to use it. Neither do I want to spend months procuring hardware and managing building out a server room (been there done that) when I can just submit some yaml/HCL and have it done for me in a few minutes.

I like solving problems but I hate coding. Wasting 20 minutes because you forgot a semicolon or something is not fun. AI let's me focus on the problem and not bother with the tedious coding bit.

I love coding and don't love questioning AI and checking responses.

But the simple fact is I'm much more productive with AI and I believe this is likely true for most programmers once they get adjusted.

So for production, what I love the most doesn't really matter, otherwise I'd be growing tomatoes and guiding river rafting expeditions. I'm resigned to the fact the age of manually writing "for loops" is largely over, at least in my case.

Every PR I have to review with an obviously LLM-generated title stuffed with adjectives, and a useless description containing an inaccurate summary of the code changes pushes me a little bit more into trying to make my side projects profitable in the hope that one takes off. It usually only gets worse from there.

Documentation needs to be by humans for humans, it's not a box that's there to be filled with slop.

See my reply to another comment - I don't think the divide is as stark as you claim.

(And I don't enjoy the value judgement)

If devs would learn how to document their work properly then there'd be much less use for AI and more people who enjoyed coding.

>Honestly, I suspect the people who would prefer to have someone or something else do their coding

Alright, please stop using SDK's, google, stackoverflow, any system libraries. You prefer to do it for yourself right?

> Honestly, I suspect the people who would prefer to have someone or something else do their coding

Have we forgotten that we advanced in software by building on the work of others?

I'm in the same boat. I've largely stopped using these tools other than asking questions about a language that I'm less familiar with or a complex type in typescript for which it can be helpful (sometimes). Otherwise, I felt like I was just wasting my time and becoming lazier/worse as a developer. I do wonder whether LLMs have hit a wall and we're in a hype cycle.

My employer gives me access to Jetbrains AI, I work on a Vue Frontend with a Kotlin Spring Boot backend.

The codebase is not too old and has grown without too much technical debt, with complex prompts I never had decent success. Its usefull for quick "what does this do" checks but any real functionality seems to be lacking.

Maybe I'm not refining my prompts good enough but doing so would take longer than implementing it myself.

Recently I tried Jetbrains Junie, which acts like Claude if I understand it correctly.

I had a really refined prompt, ran it three times with adjustments and fine tuning but the result was still lacking. So I tossed it and wrote it myself. But watching the machine nearly getting it right was still impressive.

You are just bad with prompting or working with very obscure language/framework or bad coding pattern or all of it. I had a talk with a seasoned engineer who has been coding for 50 years and has created many amazing things over lifetime about him having really bad results with AI tools I suggested for him. When I use AI for the same purposes in the same repo he's working on, it works nicely. When he does it, results are always not what he wants. It comes down to a combination of him not understanding how to guide the LLMs to correct direction and using a language/framework (he's not familiar with) he can't judge the LLMs output. It is really important to know what you want, be able to describe it in short points (but important points). Points that you know ai will mess up if you don't specify. And also be able to figure out which direction the ai is heading with the solution and correct it EARLY rather than later. Not overloading context/memory with unnecessary things. Focusing on key areas to improve and much more. I'm using AI to get solutions done that I can definitely do myself but it'll take a certain amount of time to hunt down all documentation, API/lib calls etc. With AI, 1/10th time is enough.

I've had massive success with java, js/TS, html css, go, rust, python, bitbucket pipelines/GitHub actions, cdk, docker compose, SQL, flutter/dart, swift etc.

Play with Cursor or Claude Code a bit and then make a decision. I am not on the this is going to replace Devs boat, but this has changed the way I code and approach things.

Copilot is just plain bad. The result is day and night compare with cursor + gemini 2.5 (of course with good prompting)

> Now, I wonder if I am just totally unable to write/refine good prompts for the LLM (as it works for smaller samples, I hope I am not too far off) or what could explain the huge discrepancy of experience.

Programming language / stack plays plays a big role, I presume.

Same here. We have a massive codebase with large classes and the LLMs are not very helpful. Frontend stuff is okay sometimes but the backend models are too complex at this point, I guess.

Tooling and available context size matters a lot. I'm having decent luck with Gemini 2.5 and Roo Code.

I see this "prompting is an art" stuff a lot. I gave Claude a list of 10 <Route> objects and asked it to make an adjustment to all of them. It gave me 9 back. When I asked it to try again it gave me 10 but one didn't work. What's "prompt engineering" there, telling it to try again until it gets it right? I'd rather just do it right the first time.

> Let's stop pretending or denying it: most of us would delegate our work code to somebody else or something else if we could.

Hard disagree, I get to hyperfocus on making magical things that surprise and delight me every day.

> Let's stop pretending or denying it: most of us would delegate our work code to somebody else or something else if we could.

I don’t think this is the case, if anything the opposite is true. Most of us would like to do the work code but have realized, at some career point, that you’re paid more to abstract yourself away from that and get others to do it either in technical leadership or management.

>most of us would delegate our work code to somebody else or something else if we could.

Laughably narrow-minded projection of your own perspective on others.

I wouldn't, I got into software exactly because I enjoy solving problems and writing code. Verifying shitty, mindless, computer generated code is not something I would consider doing for all the money in the world.

> Still, prompting LLMs well requires eloquence and expressiveness that many programmers don't have

It requires magical incantations that may or may not work and where a missing comma in a prompt can break the output just as badly as the US waking up and draining compute resources.

Has nothing to do with eloquence

> most of us would delegate our work code to somebody else or something else if we could.

I saw your objections to other comments on the basis of them seemingly not having a disdainful attitude towards coding they do for work, specifically.

I absolutely do have tasks, coding included, that I don't want to do, and find no joy in. If I can have my manager assign the task to someone else, great! But using an LLM isn't that, so I'm still on the hook for ensuring all the most boring parts of that task (bugfixing, reworks, integration, tests, etc) get done.

My experience with LLMs is that they simply shift the division of time away from coding, and towards all the other bits.

And it can't possibly just be about prompting. How many hundreds of lines of prompting would you need to get an LLM to understand your coding conventions, security baselines, documentation reqs, logging, tests, allowed libraries, OSS license restrictions (i.e. disallowed libraries), etc? Or are you just refactoring for all that afterwards?

Maybe you work somewhere that doesn't require that level of rigor, but that doesn't strike me as a good thing to be entrenching in the industry by increasing coders' reliance on LLMs.

The act of coding preserves your skills for that all-important verification step. No coding and the whole system falls apart.

> most of us would delegate our work code to somebody else or something else if we could

Not me. I code because I love to code, and I get paid to do what I love. If that's not you…find a different profession?

> "verify it rigorously (which if you cannot do, you should absolutely never touch an LLM!)"

100% this.

> work on whatever code makes you happy without using an LLM?

This isn't how it works, psychologically. The whole time I'm manual coding, I'm wondering if it'd be "easier" to start prompting. I keep thinking about a passage from The Road To Wigan Pier where Orwell addresses this effect as it related to the industrial revolution:

>Mechanize the world as fully as it might be mechanized, and whichever way you turn there will be some machine cutting you off from the chance of working—that is, of living.

>At a first glance this might not seem to matter. Why should you not get on with your ‘creative work’ and disregard the machines that would do it for you? But it is not so simple as it sounds. Here am I, working eight hours a day in an insurance office; in my spare time I want to do something ‘creative’, so I choose to do a bit of carpentering—to make myself a table, for instance. Notice that from the very start there is a touch of artificiality about the whole business, for the factories can turn me out a far better table than I can make for myself. But even when I get to work on my table, it is not possible for me to feel towards it as the cabinet-maker of a hundred years ago felt towards his table, still less as Robinson Crusoe felt towards his. For before I start, most of the work has already been done for me by machinery. The tools I use demand the minimum of skill. I can get, for instance, planes which will cut out any moulding; the cabinet-maker of a hundred years ago would have had to do the work with chisel and gouge, which demanded real skill of eye and hand. The boards I buy are ready planed and the legs are ready turned by the lathe. I can even go to the wood-shop and buy all the parts of the table ready-made and only needing to be fitted together; my work being reduced to driving in a few pegs and using a piece of sandpaper. And if this is so at present, in the mechanized future it will be enormously more so. With the tools and materials available then, there will be no possibility of mistake, hence no room for skill. Making a table will be easier and duller than peeling a potato. In such circumstances it is nonsense to talk of ‘creative work’. In any case the arts of the hand (which have got to be transmitted by apprenticeship) would long since have disappeared. Some of them have disappeared already, under the competition of the machine. Look round any country churchyard and see whether you can find a decently-cut tombstone later than 1820. The art, or rather the craft, of stonework has died out so completely that it would take centuries to revive it.

>But it may be said, why not retain the machine and retain ‘creative work’? Why not cultivate anachronisms as a spare-time hobby? Many people have played with this idea; it seems to solve with such beautiful ease the problems set by the machine. The citizen of Utopia, we are told, coming home from his daily two hours of turning a handle in the tomato-canning factory, will deliberately revert to a more primitive way of life and solace his creative instincts with a bit of fretwork, pottery-glazing, or handloom-weaving. And why is this picture an absurdity—as it is, of course? Because of a principle that is not always recognized, though always acted upon: that so long as the machine is there, one is under an obligation to use it. No one draws water from the well when he can turn on the tap. One sees a good illustration of this in the matter of travel. Everyone who has travelled by primitive methods in an undeveloped country knows that the difference between that kind of travel and modern travel in trains, cars, etc., is the difference between life and death. The nomad who walks or rides, with his baggage stowed on a camel or an ox-cart, may suffer every kind of discomfort, but at least he is living while he is travelling; whereas for the passenger in an express train or a luxury liner his journey is an interregnum, a kind of temporary death. And yet so long as the railways exist, one has got to travel by train—or by car or aeroplane. Here am I, forty miles from London. When I want to go up to London why do I not pack my luggage on to a mule and set out on foot, making a two days of it? Because, with the Green Line buses whizzing past me every ten minutes, such a journey would be intolerably irksome. In order that one may enjoy primitive methods of travel, it is necessary that no other method should be available. No human being ever wants to do anything in a more cumbrous way than is necessary. Hence the absurdity of that picture of Utopians saving their souls with fretwork. In a world where everything could be done by machinery, everything would be done by machinery. Deliberately to revert to primitive methods to use archaic took, to put silly little difficulties in your own way, would be a piece of dilettantism, of pretty-pretty arty and craftiness. It would be like solemnly sitting down to eat your dinner with stone implements. Revert to handwork in a machine age, and you are back in Ye Olde Tea Shoppe or the Tudor villa with the sham beams tacked to the wall.

>The tendency of mechanical progress, then, is to frustrate the human need for effort and creation. It makes unnecessary and even impossible the activities of the eye and the hand. The apostle of ‘progress’ will sometimes declare that this does not matter, but you can usually drive him into a comer by pointing out the horrible lengths to which the process can be carried.

sorry it's so long

I'm guessing you're referencing KRAZAM? https://youtu.be/eDr6_cMtfdA

> LLMS are heavily biased to replicate the naive, slow, insecure code largely uninformed by experience

The one time i pasted LLM code without reviewing it it belonged on accidentally quadratic.

It was obvious at first read, but probably not for a beginner. The accidental complexity was hidden behind API calls that weren't wrong, just grossly inefficient.

Problem might be, if you lose the "joy" and the "flow" you'll stop caring about things like that. And software is bloated enough already.

The problem with FOSSland is that it is increasingly driven by commercial interests, not by volunteers.

I don't know the last time I encountered a used (not random hobby projects) FOSS project that wasn't funded and supported by a company (with exceptions maybe only in the GNU software suite, but even then lots of authors there are making submissions using company email addresses).

I think it's totally acceptable to not make open-source contributions to those projects unless someone is paying you to.

I've just finished a PhD in (specialised) topics around computer performance. And I have a similar feeling about the stagnant state of innovation in computer and software engineering over the last 15 years or so.

The vast majority of research is funded or incentivized in some way by the big internet companies. The big internet companies have a very narrow scope of problems that they are commercially interested in. They also have so much power and money that getting people to listen to diverse ideas and opinions is incredibly difficult, both commercially and academically because everyone somehow has to cater what they do to be in line with internet company practices.

And of course, the internet companies have found ways to industrialize their core competencies of data warehousing and analytics so that every year, fewer inputs (staff, hardware, software, data) are needed to achieve the same outputs.

I think that people are experiencing a loss of independence, and creative thinking. Not a loss of passion for the craft.

Don't get distracted by claims that AI agents "replace programmers". Those are pure hype.

I'm willing to bet that in a few years most of the developers you know will be using LLMs on a daily basis, and will be more productive because of it (having learned how to use it).

I have the same experience. It‘s basically a better StackOverflow, but just like with SO you have to be very careful about the replies, and also just like SO its utility diminishes as you get more proficient.

As an example, just today I was trying to debug some weird WebSocket behaviour. None of the AI tools could help, not Cursor, not plain old ChatGPT with lots of prompting and careful phrasing of the problem. In fact every LLM I tried (Claude 3.7, GPT o4-mini-high, GPT 4.5) introduced errors into my debugging code.

I’m not saying it will stay this way, just that it’s been my experience.

I still love these tools though. It’s just that I really don’t trust the output, but as inspiration they are phenomenal. Most of the time I just use vanilla ChatGPT though; never had that much luck with Cursor.

One of the ways these tools are most useful for me is in extremely complex codebases.

This is one of the biggest dangers imo. While I agree with the OP about the deflation of joy in experienced programmers, the related but more consequential effect seems to be dissuading people from learning. A generational threat to collective competence and a disservice to students and teachers everywhere

Does your course not have exams or in-lab assignments? Should sort itself out. Honestly, I'm all for homework fading away as professors can't figure out how to prevent people from using AI. It used to be the case that certain kids could get away with not doing much because they were popular enough to get people to let them copy their assignments (at least for certain subjects). Eventually the system will realize they can't detect AI and everything has to be in-person.

I am mostly pretty underwhelmed with LLMs' code, but this is a use-case that makes perfect sense to me, and seems like a net-positive: using them as a reference manual/ translator/ training aid.

I just wish I saw more people doing this, rather than asking them to 'draw 80% of the owl'.

To me THIS is the most stressful part of the whole thing.

I like programming but I have other hobbies I find fulfilling, and nothing stops me from programming with a pen and paper.

The bad vibes are not caused by lack of programming, they're caused by headsman sharpening his axe behind me.

A few lucky programmers will be elevated to God status and we're all fighting for those spots now.

Yeah I wonder how do the code look after such professional AI development. I tried ChatGPT 1o to ask it about simple C function - what errors are there. It answered only after I directly asked about the aspects I was expecting it to tell about. It means that if I didn't know that the LLM wouldn't tell me...

I will start by saying I don't have much experience with the latest AI coding tools.

From what I've seen using them would lead to more boredom. I like solving problems. I don't like doing code reviews. I wouldn't trust any AI generated code at this stage without reviewing it. If I could swap that around so I write code and AI gives me a reasonable code review and catches my mistakes I'd be much more interested.

I would argue that the vast majority of challenges I have had in my (very long) tech career were not technical challenges anyway, rather they were "people" problems (e.g., extracting the actual requirements and maintaining scope stability).

My professional career has mostly been in IT ops. I've worked for companies that do requirements analysis and design in-house, write up a huge spec, send the spec to an offshore development house, then simply acceptance test the software that is sent back.

Companies know that the quality of the software they get back might be lower than if they hired the bestest, smartest developers in the world. But it doesn't matter because keeping the production cost of the asset low means that they can maximize long term profits.

Writing good software is not the same as writing profitable software.

One trend I've been finding interesting over the past year is that a lot of engineers I know who moved into engineering management are writing code again - because LLMs mean they can get something productive done in a couple of hours where previously it would have taken them a full day.

Managers usually can't carve out a full day - but a couple of hours is manageable.

See also this quote from Gergely Orosz:

  Despite being rusty with coding (I don't code every day
  these days): since starting to use Windsurf / Cursor with
  the recent increasingly capable models: I am SO back to
  being as fast in coding as when I was coding every day
  "in the zone" [...]

  When you are driving with a firm grip on the steering
  wheel - because you know exactly where you are going, and
  when to steer hard or gently - it is just SUCH a big
  boost.

  I have a bunch of side projects and APIs that I operate -
  but usually don't like to touch it because it's (my)
  legacy code.

  Not any more.

  I'm making large changes, quickly. These tools really
  feel like a massive multiplier for experienced devs -
  those of us who have it in our head exactly what we want
  to do and now the LLM tooling can move nearly as fast as
  my thoughts!

From https://x.com/GergelyOrosz/status/1914863335457034422

Yeah I think flow is more about holding a lot of knowledge about the code and its control flow in your head at a time. I think there's an XKCD or something that illustrates that.

You still need to do that if you're using AI, otherwise how do you know if it's actually done a good job? Or are people really just vibe coding without even reading the code at all? That seems... unlikely to work.

That’s an interesting analogy but I do disagree with it.

I would say that programming without an AI is like riding a motorcycle. You’re in complete control and it’s down to your skill to get you we’re your going.

While using AI is like taking a train. You got to plan the route but you’re just along for the ride.

Which I think lines up to the article. If you want to get somewhere easily and fast, take a train. But that does take away the joy of the journey.

There was a time when "engineer" was a respected term reserved for a profession. Engineers were highly paid because they're brought onto projects that are high-complexity and high-value. Companies are hoping not to pay for engineering work more than once.

Some countries still treat the title "Engineer" as a protected title. Though I often now see it prefixed with professional or accredited or something so that people know they aren't an "engineer" they're an "Engineer".

I think most people who write software who think of the work they're doing as "real engineering" are like the draftsmen who draw up floor plans for local government approvals in civil engineering offices. If you're doing it over and over again, it's probably not engineering, it's probably just regular skilled Labor.

This is my experience as well.

> If you're a master mason crafting amazing brickwork, you're exactly the same as some amateur grabbing some bricks from home depot and slapping a wall together.

IDK, there's still a place in society for master masons to work on 100+ year old buildings built by other master masons.

Same with the robots. They can implement solutions but I'm not sure I've heard of any inventing an algorithmic solution to a problem.

I think you are right with the building analogy. Most stuff built in the last 25 years is crap quality! But importantly looks nice. Needs to look nice at first.

And which joy is that? Short sighted profits?

By then the price will have increased quite a bit; if you want me to fix your AI crap, you're going to pay until it hurts.