Posted by Risse 5 hours ago
I haven't touched a line of code in over 6 months, didn't even look at it, but the work I do is faster and higher quality than ever.
Not sure how I feel about it
Yet I find myself using AI coding agents more and more. In this day and age, your choice is to either use them, or be stomped into the ground by programmers who do.
AI still can't write code at my level of quality, but it can do so at adequate quality now; and sadly, that is "good enough" for the real world.
I'd say that 90% of them are very excited about using LLMs for coding. They have nothing to prove to anyone and can easily steer AI to reach "godly" productivity (please note these guys were 10x programmers already).
I also know some weak programmers and most of them tend to be critical of AI and want to get rid of it.
Lastly, a couple of people I know are against AI for moral/ideological reasons without denying it can bring productivity increases.
This is purely anecdotal but I'm starting to notice this pattern everywhere I look.
Sure, LLM's are unreliable. So are juniors.
Sure, LLM's code quality is not always great. Well, so is the juniors code.
The benefit of LLM's is that they can work super fast and have a vast amount of knowledge. The benefit of juniors is that they actually learn from their mistakes and get better over time. LLM's stay at intern/junior level, even with the correct context.
So for me, I see each LLM session as a new intern coming in. You hand them the right context, give them the correct instruction, and off they go. Then they come back, and you will have to judge how detailed you want to review what they produced. Or in other words, can you get away with some bad code? And for the next session, it's a new intern that starts from 0.
But it is also highly dependent on the project you are working on. If it's a big complex codebase, LLM's will struggle, and they can only do simple tasks (however, they can help with testing a lot!)
So the teachable thing is unfortunately experience:
- Know where quality matters, and where it doesn't
- Know what kind of mistakes could be made and should be checked for
- Know which things can be duck-taped together, because they live at the edge, and which things need a proper foundation, because the rest builts on it.
So in the end, I think it all comes down to making the right trade-offs and the right decisions (which LLM's are terrible at, by the way). And unfortunately that is gained by the slow process of experience.
I think it's very tough for junior developers right now, because they either go fast by letting the LLM's do the work, but then they learn nothing. Or they go slow by asking the LLM's what's going on, and then do learn.
A senior developer never understood the full code-base, and never reviewed every line of code. That's just impossible. And now every developer needs to be a senior developer that is able to steer these new "interns".
And just like with juniors and interns, you have to put a lot of effort into it, and it's not always clear in the end if you gained or lost time :D.
To comment on the post you linked:
I agree that people can be thought. But on the other hand, I also had juniors that reached their limit pretty fast, which can also be frustrating. The best way to "teach" LLM's is the context, but I agree it has limits and is not really teaching anything, just steering them in the right direction every time (like a checklist).
Your comment basically states that running LLM's is a gamble, but according to my experience, most of the time it delivers what I ask. Maybe in a different way that how I would do it, but I want results, and am not interested in micro-managing.
Are you working on a project that requires high quality code? Or is it your preference to work in such a codebase? For me, I was always ok with "good enough" code. And sometimes "good enough" needs to be good, and other times you can get away with some really bad code.
The only danger is losing grasp of internal components of the system, but maybe there'll be a "management" layer eventually for humans.
I don't know what the future of programming will look like but I don't see us rolling back the clock to 2021..
FIFY.
I've found experienced devs with AI is a force multiplier, but AI in the hands of juniors however is my hovercraft is full of eels.
It seems most people are bad at evaluating the quality of their work, especially if they purchased it from Anthropic.
It could have also been a "use AI to test our product more", but I don't see that anywhere.
I hope you agree LLM's can actually help with quality, if used for that purpose?
And it's not just restricted to software. Everything I care about is getting worse.
Dribbling about how it could theoretically be better doesn't help undo the damage. "Imagine how much fun we could have playing baseball", says the man with the baseball bat, as he kneecaps you.
A phrase I've been toying with is eyes free vs hands free coding.
The distinction is important. While I too hardly write code these days, I do continue to make smaller changes and look at what's being done. This is as opposed to the group who has decided vibing mega commits is a good idea.
For these projects I make regular time to look through the code and do cleanup phases.
High quality code doesn't always lead to a high quality product.
And bad code doesn't always lead to a bad product.
We have more freedom than ever to build whatever we dream of, you still need a dreamer. And that’s why the profession of coding isn’t going away, you still need people to turn ideas into reality. I find AI soulless, it’s great at mimicking but is incapable of coming up with an original idea that wasn’t yours regurgitated.
This thread is full of 100x supercharged programmers, so why is it that I can't name a single useful feature added in the last 5 years in e.g. macOS, Windows, Firefox, Chrome, YouTube, VS Code, YouTube, Slack, Photoshop, Word or any of the other 5 programs currently on my taskbar?
What I have seen is that, with LLMs, an entire class of process brokenness disappeared in the in-house codebase. Before, there were many trivial tickets that, in the end, required a 5-line bugfix sitting in the queue for months. Now, such tickets are resolved instantly, and the backlog is shrinking.
Personally, I did see a lot of entry-level products having a lot higher quality and better UX. At the same time, most companies go for fast iterations and are profit-focused, do product quality is not really a target for many.
Since GPT4o, I have been convinced that most of the digital work would be done by AI and humans' job is to "move the chairs around to not block AI's way." It's a given to me. I'm just debating whether reading the code makes me a better chair-remover.
All tests pass, everything seemed to work. Would not have noticed of I didn't read through the code. Amount of other stupid shit I found is crazy.
My very first experience with OpenCode led to a `rm -rf /` within minutes, which I caught by chance watching the output stream in. Yet 99% of my code is currently written through an agent.
for me, if it's stupid, but it works, then it's a coincidence.
In essence, it is writing the code faster (great), but then also writing the code that was often previously never written due to budget/time limitations (comprehensive testing/validation).
So, how do you know the code is the highest quality ever? Because we have test result data that PROVES it to be the case. It isn't "trust but verify" it is "Don't trust. Verify."
Single data point, my Sentry notifications across more than a half dozen client projects when from 2-4 a month to basically 0. That's while shipping 20x _more_ code.
It said verbatim: "Don't trust. Verify."
pgrust thought this too, but then another human discovered claude had hardcoded benchmark query plans.
Now pgrust has a "test" [1] to make sure the Ai doesn't do this again (unless it decides this test is bad for the current goal)
I have a growing list of these, another notable one is OpenCode having a security regression [2] because the Ai redesigned configuration loading for v2.
Real verification seems beyond transformer capabilities.
[1] https://github.com/malisper/pgrust/blob/38634b408dea373f3944...
I used to work in Web agency for sizeable brands and not a single site I built lasted over a year because the companies changed concept regularly. The next agency would come in and tell them it was built wrong and couldn't be reused etc etc. We did the same, it was irrelevant how it was built and we didn't even look. This is the nature of most code. The problem is that very few people will ever be in a position to be writing verifiable important code, but every developer likes to cosplay that they are.
Most code is ultimately an, annoyance businesses need to meet a goal that will always be a cost. It's often worth treating it as such and writing things that are easy to spin up and teardown.
The people most vexed by AI dev appear to be the ones who think writing code is a pinnacle role, it's not even though over our lives the salaries would sometime suggest otherwise. That's ultimately going to be a short term blip in the landscape and most code will be one seen as the cost it is.
Well that doesn't make sense if you are writing code that is going to be used on critical infrastructure.
Imagine a disaster were to happen and you said to the auditors that "I don't know what I am doing nor did I look at the code" and you cost the company tens of millions of dollars.
Sure if your building toys, that's fine, otherwise, why take the risk in being liable for not looking at what the code does and then believing it is high quality?
Don't you see the contraction you just did there?
If there is a bug, it will be fixed quickly anyway, so only a few users might ever see it, or see it only for a brief time.
Even when manually coding, projects still have issues and bugs, I don't think much changes in that aspect now, if anything, there are fewer bugs now in most high quality apps than before, due to AI catching more issues. See all the vulnerabilities found in old core code and libraries nowadays, that humans didn't find.
>>Sure if your building toys, that's fine, otherwise, why take the risk in being liable for not looking at what the code does and then believing it is high quality?
>>Don't you see the contraction you just did there?
I wouldn't trust anyone who refuse to use LLMs for programming. Their code is worse, they test it less and it takes longer to write. For me "no LLMs" attitude is a sign of incompetence. Good for hobbyist trying to keep their brain active but that's about it.
That is even more so for critical infrastructure. Just look at the mess human coding is when it comes to security. LLMs are fixing it at the pace we couldn't even imagine a year or so ago.
So does that mean you should never look at its code?
If a fault in the software occurs even after testing and there was an investigation, will you admit in the postmortem report that you did not look at the code at all and blame the agent for the error?
> I wouldn't trust anyone who refuse to use LLMs for programming.
Did I say I refuse to use LLMs for programming? I am telling you to check the agent's work.
I would not trust anyone who DOES NOT check the changes of an agent's code when using them for programming in highly regulated industries or in critical systems. For most companies in the Fortune 500, it is irresponsible to not check.
> That is even more so for critical infrastructure. Just look at the mess human coding is when it comes to security. LLMs are fixing it at the pace we couldn't even imagine a year or so ago.
No-one argued against that and it does not mean that you do not check with the agent at all even if the agent believes that they "fixed it".
Wonder if he tells his boss to "I pushed critical code to production without even taking a look at it" or is it just for show on HN
There is no going back to writing code the old way. I don't see that happening in the industry, ever.
The grievances listed here are 100% real, but not fundamental - with some practice you can prompt an LLM to great effect without it taking the reins from you. If you let it write the code, it does become a management job more than an engineering job. That said, I do believe that there must be a way to structure your workflow such that the LLM becomes your read-only pair programmer/rubber duck while you yourself get to do the fun parts of coding.
> I know Machine Learning
Knowing a thing and knowing how to use the think well are not the same.
> Cognitive impact
This is probably the greatest concern and it requires vigilance or routines to counter it.
> The quality of the output is not that great > Maintainability is a nightmare
Neither are my first prototypes. Refactor them using AIs.
> I like writing code
I like designing a system before coding it and the AIs are pretty good idea bouncing partners.
I disagree. It remains an engineering job. Us software engineers got confused about what the engineering part always was. The engineering part of chemical engineering isn’t cutting piping, welding shit, or rolling metal. The engineering in civil engineering isn’t pouring the concrete, or grading the site.
Yet somehow it’s a prevailing idea that the engineering part of software engineering was typing on keys and naming variables.
We took advantage of the typing time to also think, and in many ways typing code served a similar purpose to drafting your thoughts on paper. With an LLM you still think a lot and those thoughts turn into specs, prompts, plans, or whatever workflow you prefer.
I would disagree that "the grievances" are not fundemantel. The _profession_ of the programmer is about to cease to exist, much like the human computer. Sure, you can still compute without a computer and perhaps enjoy it, but you will not find anyone to pay you to do it. Whatever you think "babysitting an LLM" is, it's not programming, even if presumably programmers are fairly well suited for it.
That is, unless you treat the agents as if they were people and thus the true engineers, of course. I think that's a fascinating philosophical topic despite ultimately disagreeing, but to say the least it's incredibly controversial to even consider the personhood of agents, much less endorse it.
This is all moot anyway, so apologies if I'm rude or overly dismissive of your comment that I agree with the general thrust of. No point starting fights over deck chairs...
LLMs feel like the same thing. They're spending billions of dollars on these machines that can flood the market with something once rare and valuable--human creativity. If they succeed, they'll just be ruining creativity and diminishing what humanity values.
I have a hard time believing this. The businesses employing us and the businesses competing with them will view handwritten code as an evasion of financial responsibility. That does not mean inevitability is positive or worth welcoming with open arms. But it is so inevitable at this point.
If this were true, then we wouldn't be seeing the correction to reasonable limits. While I generally agree not using LLMs is irresponsible and not viable any more, I have real doubts transformers will live up to the hype projections and the end of the profession. On the other side (with too much Ai coding), there are market penalties from the users (because of Ai mistakes).
When it comes to generative art, yes, that's a much more significant issue.
Programming never has had one right way to accomplish a task, and that is disappearing with agents. Why would pick Ruby for a project because it’s nice for the programmer, when the agent is the one coding? In fact, Why would anyone ask an LLM to write a new program in almost anything other than JavaScript and Rust?
Now I get the same feeling out of building an entire component library in an afternoon, running my code in a Nintendo Wii with twenty minutes of effort, hacking a LED display that I bought for €5, writing a tool to update my keyboard that only supported Windows, or building projects that would take a team of twenty engineers in the past.
We just got a power upgrade, the magic is still there.
in the end it's just sad.
Working in a commercial kitchen however is a different matter. But there again, nobody is forcing you to use LLMs. Cook however you want.
In the sense that I can quit my job at any time, sure. But my employer certainly requires LLM use, and even if I found another position that doesn't, I have no reason to believe that will last.
I am not denying the lack of freedom when working for someone else, or that it sucks when they impose rules on you. But that’s always been the way it goes.
The comment I replied to was about home projects and home cooking. Nothing there has to change.
Wait, no, a rice cooker doesn't seem to fit.
The point though, is that I don’t feel “sad” about not having controlled the temperature and time myself. It’s a tool.
setting aside the craft and mastery or satisfaction in goal accomplishment: to me the main thing is a sense of actualization, of the codebase or thing you were working on being better because you were there.
have you ever put up a shelf? did it feel good after?
This is not an issue.
Nobody cares about typing instructions. If someone can click instructions or voice them, it all the same.
Programming is about finding the right instructions. Not about typing.
What will be the purpose of a graphic designer when Google can generate you a logo, endless combinations. Devastating to me.
I've seen it first hand, it's pretty mind blowing and rather scary. You can't not feel that way after some time. The hype disappears.
Everyone can run a 5 minute mile now without training. I used to like training to be able to do that, but now that it's accepted everyone can do it for free (and people don't care if you did it the hard way) the joy has been sucked out of it a bit.
If you wish to make software engineering your job then it stops being a game where we ban things simply because they provide an “unfair” advantage.
If you wish to play at programming “the way it used to be done” then by all means go ahead. But mixing methapors between sports and work is not helpful.
To me, the effort part only feels pointless if you want to accept LLM-derived code as comparable. Any marathon run is pointless, you go in a loop and we have cars. The point is to do the run yourself unaided.
That a computer can play a virtual instrument better than me (and continuously better than anyone) has little bearing on whether or not I continue practicing on my piano.
People need to reflect and find themselves instead of relying to their own automaticity to get them through life, stop and smell the flowers a little.
We will soon trade that complexity barrier over to the agents and we won’t know how it is done, because the agents always did it for us.
The environmental aspects can be solved.
Quality is a measure of the person driving the process, models can write code better than the average engineer.
The impact on learning, seniority etc is the one big unknown - but I believe can/will also be solved.
I don't think that matters. What matters is that they ARE solved. Which is not the case today.
If you're not interested in "average", volume isn't going to make up for quality. I'm certainly not perfectly satisfied with LLM output quality, but even the best programmer in the world will undeniably be helped by LLM tooling, even if only for having it write tests, benchmarks, run experiments, create research summaries, and so on.
I’m sure the people dying to air pollution and high temperatures feel good knowing that it can hypothetically be solved.
As a hobbyist though, I find that LLMs are allowing me to tackle projects that I would not have tackled at all but for the existence of the LLM.
It's an important point to make (to me).
Many of these projects are rather tedious. (Other coders though might enjoy what this one-man calls "tedious".) I have found that liberating.
Do I write less and less code myself? Yes. Do I read less and less code? Maybe. Does it always matter? No. Sometimes, the agent writes code in a project or section of code that is sensitive and deserves a thorough review. Sometimes, it's in a tool that you would never have had the time to write if you didn't have an agent. Or it can be in a project that is so well covered by TDD that you can be confident that it won't break. There could be performance regressions or duplication / code creep, but once you realize it, you can ask an agent to simplify the code and find ways to prevent that from happening again.
There are cleanup / technical-debt-reduction tasks that I thought would never be done in my lifetime due to lack of time and other priorities. But now, I'm blasting through them with Claude. I cannot imagine the lack of productivity I would suffer if deprived from an agent.
That said, I agree with most points the author makes. It becomes harder to grok the code, just as it becomes hard to navigate without GPS navigation once you are used to it. It is maybe necessary to force oneself to do a development task once in a while without the help of an agent in order to stay sharp.
But stop using LLMs? that sounds counterproductive.
You can still manually type code, it can be a great hobby, but it is unlikely that someone will pay you a full time salary for doing it
In the early 20th century, Frederick Winslow Taylor came up with scientific management, a set of principles for determining the most efficient way to perform work tasks using systematic observation and measurement rather than tradition and "rule of thumb". The problem Taylor was trying to solve was that of soldiering, or as we call it more euphemistically today, "quiet quitting"—doing the bare minimum of work necessary to keep your job. If the best way of performing a particular task were known to management, soldiering workers could be held to account for not performing as much work as they could, effectively stealing from their employers. So since that time, business has had a vested interest in understanding the best way to perform all business tasks and making that the institutional standard.
You might think "But that doesn't apply to us in software engineering/IT. We use our smarts to solve problems." You couldn't be more wrong. Milt Bryce's insight was that the exact same management principles that applied to the manufacturing and construction industries applied to information systems as well, and treating a software shop like an industrial factory would save the company time, money, and effort.
Today, it is known that, when properly prompted, LLMs write better code than humans, much faster than humans can, and test it much more thoroughly as well. So yes, your employer absolutely cares whether you use an LLM or not. What rational person wouldn't, especially if they don't want to waste time or money? Furthermore, now that LLM use has been standardized as best practice because they are vastly more efficient, if you refuse to use LLMs on the job, you are stealing from your employer. Your boss has every right to fire you, and they'd be right to do so.
- Try to prove the concept early on. When you start spinning in circles, then it might be time for a different approach
- I’ve had a lot of success with projects that have not started out as LLM codebases. And adding features one by one and testing really carefully by hand
- UI generated by LLMs are overly verbose. The key lies in the iteration. What you can cut, move or approach differently. But you have to have taste.