[tarruda]

This illustrates a fundamental truth of maintaining software with LLMs: While programmers can use LLMs to produce huge amounts of code in a short time, they still need to read and understand it. It is simply not possible to delegate understanding a huge codebase to an AI, at least not yet.

In my experience, the real "pain" of programming lies in forcing yourself to absorb a flood of information and connecting the dots. Writing code is, in many ways, like taking a walk: you engage in a cognitively light activity that lets ideas shuffle, settle, and mature in the background.

When LLMs write all the code for you, you lose that essential mental rest. The quiet moments where you internalize concepts, spot hidden bugs, and develop a mental map of the system.

[danbmil99]

Has anyone else had the experience of dreading a session with Claude, because his personality is often chirpy and annoying; he's always got positive things to say; and working with him as the main code author actually takes away one of the joys of being a programmer -- the ability to interact with a system that is _not_ like people -- it is rigid and deterministic, not all soft and mushy like human beings.

When I write piece of code that is elegant, efficient, and -- "right" -- I get a dopamine rush, like I finished a difficult crossword puzzle. Seems like that joy is going to go away, replaced by something more akin to developing a good relatioship with a slightly quirky colleague who happens to be real good (and fast) at some things -- especially things management likes, like N LOC per week -- but this colleague sucks up to everyone, always thinks they have the right answer, often seems to understand things on a superficial level, and oh -- works for $200 / month...

Shades of outsourcing to other continents...

[qudat]

As a staff swe I spend way more time reading, understanding code, and then QAing features.

Writing code is my favorite part of the job, why would I outsource it so I can spend even more time reading and QAing?

[h3lp]

That's a great insight---the problem with LLMs is that they write code and elegant prose for us, so we have more time to do chores. I want it the other way around!!!

[jmvldz]

100% yes. QA'ing a bunch of LLM generated code feels like a mental flood. Losing that mental rest is a great way to put it.

[CuriouslyC]

MCP up Playwright, have a detailed spec, and tell claude to generate a detailed test plan for every story in the spec, then keep iterating on a test -> fix -> ... loop until every single component has been fully tested. If you get claude to write all the components (usually by subfolder) out to todos, there's a good chance it'll go >1 hour before it tries to stop, and if you have an anti-stopping hook it can go quite a bit longer.

[samrus]

Youve got to be doing the most unoriginal work on the planet if this doesnt produce a bowl of disfunctional spaghetti

[CuriouslyC]

Every sentence you will ever write in your entire life will be made from a finite set of letters. The magic is in how you arrange them.

If you have a really detailed, well thought out spec, you do TDD and you have regular code review and refactor loops, agentic coding stays manageable.

[cruffle_duffle]

It takes an incredibly detailed spec to get an LLM to not go completely off the rails and even then. The amount of time writing that spec can take more time than just doing it by hand.

There is way too much babysitting with these things.

I’m sure somehow somebody makes it work but I’m incredibly skeptical that you can let an LLM run unsupervised and only review its output as a PR.

[andrekandre]

  > The amount of time writing that spec can take more time than just doing it by hand.

one thing about doing it by hand is you also notice holes/deficiencies in the spec and can go back and update it, make the product better, but just throwing it to an llm 'til its perfect-to-spec probably means its just going to be average quality at best...

tho tbh most software isn't really 'stunning' imo so maybe thats fine as far as most businesses are concerned... (sad face)

[cpursley]

Can you elaborate on what you mean by anti stopping hook? Sometime I take breaks, go on walks, etc and it would be cool of Claude tried different things and even branches etc that I could review when back.

[CuriouslyC]

Basically, all LLMs are "lazy" to some degree and are looking for ways to terminate responses early to conform to their training distribution. As a result, sometimes an agent will want to stop and phone home even if you have multiple rows of all caps saying DO NOT STOP UNTIL YOUR ENTIRE TODO LIST IS COMPLETE (seriously). Claude code has a hook for when the main agent and subagents try to stop, and you can reject their stop attempt with a message. They can still override that message and stop but the change of turn and the fresh "DO NOT STOP ..." that's at the front of context seem to keep it revving for a long time.

[rstuart4133]

Another way of saying thing is only an AI reviewer could cope with the flood of code an AI can produce.

But AI reviewers can do little beyond checking coding standards.

[imiric]

Programming and vibe coding are two entirely separate disciplines. The process of producing software, and the end result, is wildly different between them.

People who vibe code don't care about the code, but about producing something that delivers value, whatever that may be. Code is just an intermediate artifact to achieve that goal. ML tools are great for this.

People who program care about the code. They want to understand how it works, what it does, in addition to whether it achieves what they need. They may also care about its quality, efficiency, maintainability, and other criteria. ML tools can be helpful for programming, but they're not a panacea. There is no shortcut for building robust, high quality software. A human still needs to understand whatever the tool produces, and ensure that it meets their quality criteria. Maybe this will change, and future generations of this tech will produce high quality software without hand-holding, but frankly, I wouldn't bet on the current approaches to get us there.