absolutely, back when I started coding very few network engineers knew how to do it properly, so those of us who took an interest were seen as trailblazers 
if you were a neteng who could write a few lines of Python to pull the OS version of the DC routers and switches to audit which ones needed an upgrade you were considered a genius. If you knew git and a bit of basic SQL you were a wizard, so yeah I’m also very lucky I got paid the time it took to get halfway decent at building and maintaining network automation tools
I’m happy to let LLMs do the work on things I’m not remotely interested in learning, like Python 
1 Like
That is a good path forward, who cares about writing good python after all 
This forum mocked me into deleting posts and leaving after talking positively about AI a year ago. The longer you bury your head in the sand, the more you lose. Notice that @kunitoki, one of the most impressive and prolific developers on the forum, is using them heavily. Me as well.
But you’ve got to babysit them constantly. Review literally every single line of code or you will constantly introduce problems. They are incredible powerful but are still very stupid and lazy in many cases. You can’t predict which you’ll get at any given point in time, so it’s best to micro-manage them.
I run 5 virtual desktops each with different projects and cycle through them. Often with another instance on a separate machine doing regression tests and other work. Can’t imagine sitting around writing every line of code right now. Foolishness.
3 Likes
Exactly, foolishness (but in some case i really still like writing something to not lose the feeling of writing, which is still a nice aspect of development). Thanks for the nice words, btw.
In the end, for me LLMs are just 2 things.
First, they are simply faster type writers than i am, no way i can type as fast, but what to write, and what to change, you need to still be a skilled engineer in the loop with good practices, mastering design principles, and a general attention to detail and criticism of each and every change that is being done by the agent/model (same as if it could be your colleague or a contributor in github). I never really vibe code (limited human verification after each change) unless they are throw away experiments or little scripts to automate or analyse stuff (“make a python script to plot data in file xyz …”). I’m more positive toward what someone in the Nim forum coined as “drone coding”, where you are still at the control panel, or as i prefer to say “puppet master coding”
Second, they are unswappable companions for summaries and research for learning purposes. In few seconds you can get a pretty accurate architectural analysis of any software or document (no way i can dig in a multi million lines of code project without having one LLM to extract me summaries of what and where to look at or actually give me out a graphviz of the main classes and how they interact), which would have taken you hours to learn by yourself just browsing files and documenting on the side.
Again, you don’t have to delegate everything to them, but you can still learn stuff and do manual coding on the fun and best parts of projects while they generate boilerplate in the background.
I would never let AI agents fully loose on my code bases or systems, but AI chatbots have been useful for more limited tasks. Like today I was able to get my code that I had been developing exclusively on Windows for many months running on Raspberry Pi. I feel like chatting with even the free Claude Sonnet 4.6 AI made that a lot easier and faster than trying to Google around for each cmake/compiler/linker/git error/problem I was getting.
I’m stupid to care about environmental impact of AI?
4 Likes
I’m stupid to care about environmental impact of AI?
It’s the same rhetoric as you’d use for datacenters, googling weather, etc.
And it can escalate very quickly into a philosophical discussion (firearm, recycling, flights, space exploration, etc).
The optimistic bits are:
- I think edge models will be a thing, it’s already quite impressive to see Apple silicon running reasonable models at the friction of watts used by GPUs.
- Google’s Tensor/TPUs are also aiming there.
At the end,
Current players know how much is their monthly electric bill and they do care.
No AI will touch my codebase. I like building things, coding, even doing repetitive tasks.
And I like being proud of the result, like an artist would be of a painting he carefully handle every aspect of.
I am not letting a bot spoil my fun 
6 Likes
This is how I feel too.
For many people, software is just a means to an end, something that lets them do the thing they actually want to do. For me, the software itself is the end.
Likewise, the source code isn’t just the means to making the software; the code itself matters to me. AI can write pretty good code, but it’s lifeless, just like the text it writes or the music it outputs.
4 Likes
Reposting only the on-topic part 
Review literally every single line of code or you will constantly introduce problems.
I totally agree but there is (has been) mounting pressure to ignore this premise (tech unsavy management pressing unrealistic deadlines) and also think it is extremely easy to become complacent about this. caustik do you really manage to review every single line of code and how they act together as deeply as if you had coded them?
1 Like
I think about this research quite often: AI coders think they’re 20% more efficient, but they’re actually 19% less efficient. I have had experiences which match this, i.e. feeling like I’m on rocket fuel, but regretting it in the long run.
For example, I recently needed to build a VS Code extension in Typescript, and I thought this would be a good project for Gemini to take the lead on. I gave it the specifications, wrote tests, and let it iterate on the design process. After a week or so, all tests were passing, and it felt amazing! But then a week later I needed to change something. I found that I didn’t understand the code well enough to do it myself, so I went back to Gemini, but it couldn’t get it right. After another week, I decided just to bite the bullet, learn the API myself, and re-write the whole thing from scratch. One month wasted!
For me, the issue is that I stop understanding what the code is doing, and this costs me heavily in the long run. It never starts like that–I tell myself that this time I’ll pay more attention and review every line of code it writes–but with each iteration there is more and more temptation to relax and just let it run. After a few days I stop understanding how the code works at all, and then when it breaks, I’m completely lost and end up having to rewrite the whole thing.
I’m not trying to fight anyone here–if it works for you then great. And I do use Gemini constantly to discuss the work I’m doing, but more as a consultant or a code reviewer than as an actual coder.
6 Likes
Exactly this. Even people who claim to be having success with AI don’t seem to be shipping more products faster or working fewer hours, they’ve just transformed the nature of their work from writing code to prompting a chatbot to write code. Then debugging broken spaghetti code they don’t fully understand.
IMHO, typing out lines of code is not the significant bottle neck in development time. I firmly believe that investing the time to properly define the problem, refine the requirements, create a mental model, then write good code that works is in reality faster than prompting an LLM to generate some lines of code that may or may not be a good design, and that you’ll have to make it fine tune later. If your mental model of the problem is good enough, then the most efficient way to actualize the code is to type it yourself, not to describe your mental model to a non-deterministic middleman!
2 Likes
If you’ve got a 25 year old codebase that you want to modernize/refactor, I’d say the most important thing you should do is get some tests in place before you start making changes. This may be difficult if the code is undocumented, as you need to intuit the intended behavior, including in edge cases.
I would not have a lot of confidence in simply feeding 100k lines into an LLM and saying “write unit tests for everything”. That is quite a shaky rock on which to build your church.
1 Like
Obviously not taking the side of AI, but isn’t this also the case whenever you handle parts of your development to other staff?
Yes, it’s important to hire good people who write good code & communicate well (or that you can figure out how to manage). But I think it’s much better to spend your money to hire an actual human, with a human brain’s power, to work X hours for you, rather than the same cost in compute tokens. $500 of spaghetti LLM output that doesn’t work isn’t worth anything, but 7 hours of a mid-level developer’s time to work on a small project should produce at least some value in code & progress on the design/requirements, even if the solution is still buggy/incomplete after 7 hours.
Of course, nowadays the equation is complicated by the fact that anyone you hire might just be blindly handing you LLM output and not doing 7 hours worth of active thinking.
2 Likes
I think about this research quite often: AI coders think they’re 20% more efficient, but they’re actually 19% less efficient. I have had experiences which match this, i.e. feeling like I’m on rocket fuel, but regretting it in the long run.
That study is from August 2025, they were using Cursor Pro and Claude 3.5 Sonnet.
In short, it’s hopelessly out of date and obsolete. Ignore it.
The fore-front AI coding tools are Anthropic’s Claude-Code and OpenAI’s Codex, using Claude Opus 4.7 and GPT 5.5 AI models respectively.
Both are astonishingly good at C++ (and most other languages, including bash, CMake) and know JUCE extremely well.
To get most out of them you’ll need the Pro/Max subscriptions. No need to use anything else that results in expensive build-up of API call token costs.
I’ve been a developer for 30 years and I’ve never seen any technology introduced that can accelerate product development or enable things that were too time-consuming, difficult or resource strapped to do in the way that it facilitates.
If you’re ending up with spaghetti code and AI ‘slop’, then you absolutely are not engaging with it in the best way. Engage with it using solid software engineering principles, PRD’s, TDD etc. Get it to double check its workings, simplify, optimise, comment well, follow prior project coding standards, compile without warnings, all unit tests must pass and so on.
Get it to create .md documentation when needed, including ascii or mermaid diagrams etc.
And the ability to quickly drum up Python tools or HTML pages to chart and test out DSP concepts is an incredible asset for an audio developer.
It’s not a magic wand, but it IS a power-tool.
2 Likes
Personally, I still enjoy the process of writing code myself, and I’ve been sceptical of LLMs for a long time. Recently, though, I can’t deny how impressive they’ve become particularly Claude, and especially the latest Sonnet models in my experience. Developers I deeply respect, many with decades of experience have also been convinced by these models in particular. I think it would be foolish to not utilise them in 2026, with a pro subscription it is not particularly expensive if you stay within your limits.
1 Like
The conclusions in the article cite adoption shortcomings, not tool related limitations, to explain the gap between perception and reality. The “next iteration will solve [problem X]” argument is as old as time. There’s always something that needs just one more release, one more optimisation and we’ll never have that problem again. For reals!
This is from 3 months ago, from one of the main stakeholders
We found that using AI assistance led to a statistically significant decrease in mastery. On a quiz that covered concepts they’d used just a few minutes before, participants in the AI group scored 17% lower than those who coded by hand, or the equivalent of nearly two letter grades. Using AI sped up the task slightly, but this didn’t reach the threshold of statistical significance.
And sure, they do conclude that the key difference is in how the service (it’s not a “tool”, it’s a service) is used so this is not fearmongering about AI
How someone used AI influenced how much information they retained. The participants who showed stronger mastery used AI assistance not just to produce code but to build comprehension while doing so
Although I personally don’t use AI at all, and don’t plan on starting until further notice, I’m not gonna light up a torch and polish my pitchfork to go after those who do. But please, let’s not be disingenuous in trying to paint the congnitive decline associated to AI as “yesteryear’s problem” as if the issues cited were banished. If Sam Altman wants to commoditise and sell “intelligence” it’s in his best interest to fabricate a need for it, and the way he’ll try to accomplish that is by luring users towards tools that will help fulfill that objective. AI can potentially be super helpful, I guess, but in the wise words of Stafford Beer, “The purpose of a system is what it does”.
PS: I’m not making this about Altman specifically, he’s just the most honest about what his business model is with regards to developing the user need for his service, and I don’t see any other major AI providers differing significantly.
1 Like
Although I personally don’t use AI at all, and don’t plan on starting until further notice, I’m not gonna light up a torch and polish my pitchfork to go after those who do. But please, let’s not be disingenuous in trying to paint the congnitive decline associated to AI as “yesteryear’s problem” as if the issues cited were banished.
The point is, the study highlighted differences in perceived productivity from actual productivity.
Anyone who actually uses these tools knows that there was a huge shift in Dec '25 / Jan '26 where the models became exceptionally better for coding purposes. And progress in the harnesses and models has been rapid from that point on.
The study could have come out just one month ago and it’d be obsolete now, at least with respect to any claims about misperception in productivity.
Nevertheless, my purpose here wasn’t to evangelise AI, just to point out how rapidly its progressing, how astonishingly good it is currently (and currently is as bad as it’ll ever be), and to offer some suggestions from the perspective of it being a power tool…an addition to a developers toolset, not a replacement for brain exercise or creativity.