But I’ve come full circle and have gone back to hand coding after a couple years of fighting LLMs. I’m tired of coaxing their style and fixing their bugs - some of which are just really dumb and some are devious.
around a third of senior developers with more than a decade of experience are using AI code-generation tools such as Copilot, Claude, and Gemini to produce over half of their finished software, compared to 13 percent for those devs who've only been on the job for up to two years.
A third? I would expect at least a majority based on the headline and tone of the article... Isn't this saying 66% are down on vibe coding?
Is "vibe coding" synonymous with using AI code-generation tools now?
I thought vibe coding meant very little direct interaction with the code, mostly telling the LLM what you want and iterating using the LLM. Which is fun and worth trying, but probably not a valid professional tool.
“AI” is great for coding in the small, it’s like having a powerful semantic code editor, or pairing with a junior developer who can lookup some info online quickly. The hardest part of the job was never typing or figuring out some API bullshit anyway.
But trying to use it like “please write this entire feature for me” (what vibe coding is supposed to mean) is the wrong way to handle the tool IMO. It turns into a specification problem.
I think they're being really loose with the term "vibe coding", and what they really mean is AI-assisted coding.
Older devs are not letting the AI do everything for them. Assuming they're like me, the planning is mostly done by a human, while the coding is largely done by the AI, but in small sections with the human giving specific instructions.
Then there's debugging, which I don't really trust the AI to do very well. Too many times I've seen it miss the real problem, then try to rewrite large sections of the code unnecessarily. I do most of the debugging myself, with some assistance from the AI.
I tried it - didn't like it. Had an LLM work on a backup script since I don't use Bash very often. Took a bunch of learning the quirks of bash to get the code working properly.
While I'll say it got me started, it wasn't a snap of the fingers and a quick debug to get something done. Took me quite a while to figure out why something worked but really it didn't (LLM using command line commands where Bash doesn't interpret the results the same).
If its something I know, probably wont use LLM (as it doesn't do my style). If it's something I don't know, might use it to get me started but I expect that's all I'll it for.
Apparently vibe coding now just means ai assisted coding beyond immediate code completion?
For me, success with LLM-assisted coding comes when I have a clear idea of what I want to accomplish and can express it clearly in a prompt. The relevant key business and technical concerns come into play, including complexities like balancing somewhat conflicting shorter and longer term concerns.
Juniors are probably all going to have to be learning this kind of stuff at an accelerated rate now (we don't need em cranking out REST endpoints or whatever anymore), but at this point this takes a senior perspective and senior skills.
Anyone can get an LLM and agentic tool to crank out code now. But you really need to have them crank out code to do something useful.
I've been at this for many years. If I want to implement a new feature that ties together various systems and delivers an expected output, I know the general steps that I need to take. About 80% of those steps are creating and stubbing out new files with the general methods and objects I know will be needed, and all the test cases. So... I could either spend the next 4 hours doing that, or spend 3 minutes filling out a CLAUDE.md with the specs and 5 minutes having Claude do it (and fairly well).
I feel no shame in doing the later. I've also learned enough about LLMs that I know how to write that CLAUDE.md so it sticks to best practices. YMMV.
I often use LLMs for method level implementation work. Anything beyond the scope of a single function call I have very little confidence in. This is OK though, since everything is a function and I can perfectly control the blast radius as long as I keep my hands on the steering wheel. I don't ever let the LLM define method signatures for me.
If I don't know how to structure functions around a problem, I will also use the LLM, but I am asking it to write zero code in this case. I am just having a conversation about what would be good paths to consider.
I wouldn't say I'm old, but I suddenly fell into the coding agent rabbit hole when I had to write some Python automations against Google APIs.
Found myself having 3-4 different sites open for documentation, context switching between 3 different libraries. It was a lot to take in.
So I said, why not give AI a whirl. It helped me a lot! And since then I have published at least 6 different projects with the help of AI.
It refactors stuff for me, it writes boilerplate for me, most importantly it's great at context switching between different topics. My work is pretty broadly around DevOps, automation, system integration, so the topics can be very wide range.
So no I don't mind it at all, but I'm not old. The most important lesson I learned is that you never trust the AI. I can't tell you how often it has hallucinated things for me. It makes up entire libraries or modules that don't even exist.
It's a very good tool if you already know the topic you have it work on.
But it also hit me that I might be training my replacement. Every time I correct its mistakes I "teach" the database how to become a better AI and eventually it won't even need me. Thankfully I'm very old and will have retired by then.
I think at this point it's whoever can get the most useful work out of AI which is actually really hard due to their 'incomplete' state. Finding uses which require very little user input is going to be the next big thing in my opinion since it seems that LLMs are currently at a wall where they require technical advancements before they can overcome it.
In terms of LOCs maybe, in terms of importance I think is much less. At least that's how I use LLMs.
While I understand that <Enter model here> might produce the meaty bits as well, I believe that having a truck factor of basically 0 (since no-one REALLY understands the code) is a recipe for a disaster and I dare say long term maintainability of a code base.
I feel that you need to have someone in any team that needs to have that level of understanding to fix non trivial issues.
However, by all means, I use the LLM to create all the scaffolding, test fixtures, ... because that is mental energy that I can use elsewhere.
Article did not say what kind languages/applications thosd 791 developers were working on. I work on a legacy Java code base (which looks more like C than Java, thankfully) and I cant imagine AI doing any of it. It can do small isolated, well formulated chunks (functions that do a very specific task) but even that will require very verbose explanation.
I just can't fathom shipping a big percentage of work using LLMs.
Disclaimer: not only am I a Fastly employee, I'm the Fastly employee quoted in the register article originally linked.
We'd argue our stance and focus are a bit different. Our stance is -- we help eng teams and the open web with whatever their preference for AI might be.
If you want to go all in and monetize AI traffic or sign an agreement with a foundation model for training, we have tools that can help you do that. If you want to go scorched-earth on AI bots that try to scrape your systems, we can help you do that too.
It's all about helping engineers tasked with tough problems get their jobs done, regardless of whether the flavor of the week is AI or something else.
This article goes completely against my experience so far.
I teach at an internship program and the main problem with interns since 2023 has been their over reliance on AI tools. I feel like I have to teach them to stop using AI for everything and think through the problem so that they don't get stuck.
Meanwhile many of the seniors around me are stuck in their ways, refusing to adopt interactive debuggers to replace their printf() debug habits, let alone AI tooling...
Seems about right for me (older developer at a big tech company). But we need to define what it means that the code is AI-generated. In my case, I typically know how I want the code to look like, and I'm writing a prompt to tell the agent to do it. The AI doesn't solve any problem, it just does the typing and helps with syntax. I'm not even sure I'm ultimately more productive.
87 comments
[ 2.7 ms ] story [ 77.2 ms ] threadBut I’ve come full circle and have gone back to hand coding after a couple years of fighting LLMs. I’m tired of coaxing their style and fixing their bugs - some of which are just really dumb and some are devious.
Artisanal hand craft for me!
If you find it is quicker not to use it then you might hate it, but I think it is probably better in some cases and worse in other cases.
A third? I would expect at least a majority based on the headline and tone of the article... Isn't this saying 66% are down on vibe coding?
I thought vibe coding meant very little direct interaction with the code, mostly telling the LLM what you want and iterating using the LLM. Which is fun and worth trying, but probably not a valid professional tool.
But trying to use it like “please write this entire feature for me” (what vibe coding is supposed to mean) is the wrong way to handle the tool IMO. It turns into a specification problem.
Older devs are not letting the AI do everything for them. Assuming they're like me, the planning is mostly done by a human, while the coding is largely done by the AI, but in small sections with the human giving specific instructions.
Then there's debugging, which I don't really trust the AI to do very well. Too many times I've seen it miss the real problem, then try to rewrite large sections of the code unnecessarily. I do most of the debugging myself, with some assistance from the AI.
While I'll say it got me started, it wasn't a snap of the fingers and a quick debug to get something done. Took me quite a while to figure out why something worked but really it didn't (LLM using command line commands where Bash doesn't interpret the results the same).
If its something I know, probably wont use LLM (as it doesn't do my style). If it's something I don't know, might use it to get me started but I expect that's all I'll it for.
For me, success with LLM-assisted coding comes when I have a clear idea of what I want to accomplish and can express it clearly in a prompt. The relevant key business and technical concerns come into play, including complexities like balancing somewhat conflicting shorter and longer term concerns.
Juniors are probably all going to have to be learning this kind of stuff at an accelerated rate now (we don't need em cranking out REST endpoints or whatever anymore), but at this point this takes a senior perspective and senior skills.
Anyone can get an LLM and agentic tool to crank out code now. But you really need to have them crank out code to do something useful.
I feel no shame in doing the later. I've also learned enough about LLMs that I know how to write that CLAUDE.md so it sticks to best practices. YMMV.
If I don't know how to structure functions around a problem, I will also use the LLM, but I am asking it to write zero code in this case. I am just having a conversation about what would be good paths to consider.
Found myself having 3-4 different sites open for documentation, context switching between 3 different libraries. It was a lot to take in.
So I said, why not give AI a whirl. It helped me a lot! And since then I have published at least 6 different projects with the help of AI.
It refactors stuff for me, it writes boilerplate for me, most importantly it's great at context switching between different topics. My work is pretty broadly around DevOps, automation, system integration, so the topics can be very wide range.
So no I don't mind it at all, but I'm not old. The most important lesson I learned is that you never trust the AI. I can't tell you how often it has hallucinated things for me. It makes up entire libraries or modules that don't even exist.
It's a very good tool if you already know the topic you have it work on.
But it also hit me that I might be training my replacement. Every time I correct its mistakes I "teach" the database how to become a better AI and eventually it won't even need me. Thankfully I'm very old and will have retired by then.
While I understand that <Enter model here> might produce the meaty bits as well, I believe that having a truck factor of basically 0 (since no-one REALLY understands the code) is a recipe for a disaster and I dare say long term maintainability of a code base.
I feel that you need to have someone in any team that needs to have that level of understanding to fix non trivial issues.
However, by all means, I use the LLM to create all the scaffolding, test fixtures, ... because that is mental energy that I can use elsewhere.
We have got to stop. In a universe of well over 25 million programmers a sample of 791 is not significant enough to justify such headlines.
We’ve got to do better than this, whatever this is.
I just can't fathom shipping a big percentage of work using LLMs.
https://www.fastly.com/products/ai
https://www.fastly.com/products/fastly-ai-bot-management
https://www.fastly.com/documentation/guides/compute/about-th...
We'd argue our stance and focus are a bit different. Our stance is -- we help eng teams and the open web with whatever their preference for AI might be.
If you want to go all in and monetize AI traffic or sign an agreement with a foundation model for training, we have tools that can help you do that. If you want to go scorched-earth on AI bots that try to scrape your systems, we can help you do that too.
It's all about helping engineers tasked with tough problems get their jobs done, regardless of whether the flavor of the week is AI or something else.
I teach at an internship program and the main problem with interns since 2023 has been their over reliance on AI tools. I feel like I have to teach them to stop using AI for everything and think through the problem so that they don't get stuck.
Meanwhile many of the seniors around me are stuck in their ways, refusing to adopt interactive debuggers to replace their printf() debug habits, let alone AI tooling...