it does seem like the skepticism is fading. I do think engineers that outright refuse to use AI (typically on some odd moral principle) are in for a bad time
I would never have had a working LoongArch emulator in 2 weeks at the kind of quality that I desire without it. Not because it writes perfect code, but because it sets everything up according to my will, does some things badly, and then I can take over and do the rest. The first week I was just amending a single commit that set everything up right and got a few programs working. A week after that it runs on multiple platforms with JIT-compilation. I'm not sure what to say, really. I obviously understand the subject matter deeply in this case. I probably wouldn't have had this result if I ventured into the unknown.
Although, I also made it create Rust and Go bindings. Two languages I don't really know that well. Or, at least not well enough for that kind of start-to-finish result.
Another commenter wrote a really interesting question: How do you not degrade your abilities? I have to say that I still had to spend days figuring out really hard problems. Who knew that 64-bit MinGW has a different struct layout for gettimeofday than 64-bit Linux? It's not that it's not obvious in hindsight, but it took me a really long time to figure out that was the issue, when all I have to go on is something that looks like incorrect instruction emulation. I must have read the LoongArch manual up and down several times and gone through instructions one by one, disabling everything I could think of, before finally landing on the culprit just being a mis-emulated kind-of legacy system call that tells you the time. ... and if the LLM had found this issue for me, I would have been very happy about it.
There are still unknowns that LLMs cannot help with, like running Golang programs inside the emulator. Golang has a complex run-time that uses signal-based preemption (sysmon) and threads and many other things, which I do emulate, but there is still something missing to pass all the way through to main() even for a simple Hello World. Who knows if it's the ucontext that signals can pass or something with threads or per-state signal state. Progression will require reading the Go system libraries (which are plain source code), the assembly for the given architecture (LA64), and perhaps instrumenting it so that I can see what's going wrong. Another route could be implementing an RSP server for remote GDB via a simple TCP socket.
As a conclusion, I will say that I can only remember twice I ditched everything the LLM did and just did it myself from scratch. It's bound to happen, as programming is an opinionated art. But I've used it a lot just to see what it can dream up, and it has occasionally impressed. Other times I'm in disbelief as it mishandles simple things like preventing an extra masking operation by moving something signed into the top bits so that extracting it is a single shift, while sharing space with something else in the lower bits.
Overall, I feel like I've spent more time thinking about more high-level things (and occasionally low-level optimizations).
What worries me is how AI impacts neurodivergent programmers. I have ADHD and it simply doesn't work for me to constantly be switching context between the code I'm writing and the AI chat. I am terrified that I will be forced out of the industry if I can't keep up with people who are able to use AI.
> The engineers refusing to try aren’t protecting themselves; quite the opposite, they’re falling behind. The gap is widening between engineers who’ve integrated these tools and engineers who haven’t.
For me, however, there is one issue: how can I utilize AI without degenerating my own abilities? I use AI sparingly because, to be honest, every time I use AI, I feel like I'm getting a little dumber.
I fear that excessive use of AI will lead to the loss of important skills on the one hand and create dependencies on the other.
Who benefits if we end up with a generation of software developers who can no longer program without AI? Programming is not just writing code, but a process of organizing, understanding, and analyzing.
What I want above all is AI that helps me become better at my job and continue to build skills and knowledge, rather than making me dependent on it.
I know this is reductionist, and I believe that you are likely correct in your concerns, but this type of thing has been happening for thousands of years. Writing itself was controversial!
> They go on to discuss what is good or bad in writing. Socrates tells a brief legend, critically commenting on the gift of writing from the Egyptian god Theuth to King Thamus, who was to disperse Theuth's gifts to the people of Egypt. After Theuth remarks on his discovery of writing as a remedy for the memory, Thamus responds that its true effects are likely to be the opposite; it is a remedy for reminding, not remembering, he says, with the appearance but not the reality of wisdom. Future generations will hear much without being properly taught, and will appear wise but not be so, making them difficult to get along with.
"AI coding is so much better now that any skepticism from 6 months ago is invalid" has been the refrain for the last 3 years. After the first few cycles of checking it out and realizing that it's still not meeting your quality bar, it's pretty reasonable to dismiss the AI hype crowd.
It's gotten ok now. Just spent a day with Claude for the first time in a while. Demanded strict TDD and implemented one test at a time. Might have been faster, hard to say for sure. Result was good.
I work in crypto (L1 chain) as a DevOps engineer (LOTS of baremetal, LOTS of CI/CD etc) and it's been amazing to see what Claude can do in this space too.
e.g. had an issue with connecting to AWS S3, gave Claude some of the code to connect and it diagnosed a CREDENTIALS issue without seeing the credentials file nor seeing the error itself. It can even find issues like "oh, you have an extra space in front of the build parameter that the user passed into a Jenkins job". Something that a human might have found in 30+ minutes of grepping, checking etc it found in <30 seconds.
It also makes it trivial to do things like "hey, convert all of the print statements in this python script to log messages with ISO 8601 time format".
Folks talk about "but it adds bugs" but I'm going to make the opposite argument:
The excuse of "we don't have time to make this better" is effectively gone. Quality code that is well instrumented, has good metrics and easy to parse logs is only a few prompts away. Now, one could argue that was the case BEFORE we had AI/LLMs and it STILL didn't happen so I'm going to assume folks that can do clean up (SRE/DevOps/code refactor specialists) are still going to be around.
> "The engineers refusing to try aren’t protecting themselves; quite the opposite, they’re falling behind. The gap is widening between engineers who’ve integrated these tools and engineers who haven’t. The first group is shipping faster, taking on bigger challenges. The second group is… not."
Honest question for the engineers here. Have you seen this happening at your company? Are strong engineers falling behind when refusing to integrate AI into their workflow?
Maybe I've always been a terrible engineer but I'm humble enough to admit the way I code has always been exactly like the LLM. If it's something brand new I'm googling it and pattern matching how to write it. If it's based on existing functionality I'm doing ctrl + f and pattern matching based on that and how to insert the minimal code changes to accomplish the task
> if you haven’t tried modern AI coding tools recently, try one this week.
I don’t think I will. I am glad I have made the radical decision, for myself, to wilfully remain strict in my stance against generative AI, especially for coding. It doesn’t have to be rational, there is good in believing in something and taking it to its extreme. Some avoid proprietary software, others avoid eating sentient beings, I avoid generative AI on pure principle.
This way I don’t have to suffer from these articles that want to make you feel bad, and become almost pleading, “please use AI, it’s good now, I promise” which I find frankly pathetic. Why do people care so much about it to have to convince others in this sad routine? It honestly feels like some kind of inferiority complex, as if it is so unbearable that other people might dislike your favourite tool, that you desperately need them to reconsider.
Ha! I just saw one of these this morning on LinkedIn, an engineer complaining about AI / Vibecoding and thought exactly the same. I find these overreactions amusing.
I don’t know why this is so controversial it’s just a tool, you should learn to use it otherwise as the author of this post said you will get left behind but don’t cut yourself on the new tool (lots of people are doing this).
I personally love it because it allows me to create personal tools on the side that I just wouldn’t have had time for in the past. The quality doesn’t matter so much for my personal projects and I am so much more effective with the additional tools I’m able to create.
AI is a tool. As every other tool under the sun, it has strengths and weaknesses, it's our job, as software engineers to try it out and understand when/how to use it on our workflows, or if if fits our use cases at all.
If you disagree with the above statement, try replacing "AI" with "Docker", "Kubernetes", "Microservices architecture", "NoSQL", or any other tool/language/paradigm that was widely adopted in the software development industry until people realized it's awesome for some scenarios but not a be-all and end-all solution.
It's good to be skeptical of new ideas as long as you don't box yourself in with dogmatism. If you're young you do this by looking at the world with fresh eyes. If you are experienced you do it by identifying assumptions and testing them.
I wonder how many of us are like me: Just waiting for AI to get Good Enough (TM). The skill required to use AI is probably decreasing, and the AI getting better, so why not just wait? Time will tell.
Yeah it boggles my mind all the people on here constantly dismissing LLMs.
It's very clearly getting better and better rapidly. I don't think this train is stopping even if this bubble bursts.
The cold ass reality is: We're going to need a lot less software engineers moving forward. Just like agriculture now needs way less humans to do the same work than in the past.
I hate to be blunt but if you're in the bottom half of the developer skill bell curve, you're cooked.
We are moving up an abstraction layer. From the perspective of the business, my job is not to write code, my job is to ship products. The language you use to ship products is your tool of choice. Sure, it could be Python or Typescript, but my tool of choice is natural language.
If you don't see the limitations of vibe coding, I shudder on the idea of maintaining your code even pre-AI.
Do I use it? Yes, a lot, actually. But I also spend a lot of tunning prunning its overly verbose and bizantine code, my esc key is fading from the amount of times I've interrupted it to steer it towards a non-idiotic direction.
It is useful, but if you trust it too much, you're creating a mountain of technical debt.
You want to market to engineers, stick to provable statements. And address some of their concerns. With something other than "AI is evolving constantly, all your problems will be solved in 6 months, just keep paying us."
Oh by the way, what is the OP trying to sell with these FOMO tactics? Yet another ChatGPT frontend?
The fact that i hear this mantra over and over again:
"She wrote a thing in a day that would have taken me a month"
This scares me. A lot.
I never found the coding part to be a bottle neck, but the issues arise after the damn thing is in prod. If i work on something big (that will take me a month) thats going to be anywhere from (im winging these numbers) 10K LOC to 25K LOC).
If thats a bechmark for me the next guy using AI will spew out at a bare minimun double the amount of code, and in many cases 3x-4x.
The surface area for bugs are just vastly bigger, and fixing these bugs will eventually take more time than you "won" using AI in the first place.
Author doesn't consider the possibility that engineers dismiss AI after they constantly tried it. Not once, not twice, but consistently.
I am one of those dismissers. I am constantly trash talking AI. Also, I have tried more tools and more stress scenarios than a lot of enthusiasts. The high bars are not in my head, they are on my repositories.
Talk is cheap. Show me your AI generated code. Talk tech, not drama.
My reasons for initially dismissing it is because to me it felt like it was taking the fun part of the job. We have all these tasks, and writing the code is this creative act, designed to be read by other humans. Just like how I don’t want AI to write music for me.
But I see where things are going. I tried some of the newer tooling over the past few weeks. They’re too useful to ignore now. It feels like we’re entering into an industrial age for software.
80 comments
[ 95.0 ms ] story [ 330 ms ] threadit does seem like the skepticism is fading. I do think engineers that outright refuse to use AI (typically on some odd moral principle) are in for a bad time
Although, I also made it create Rust and Go bindings. Two languages I don't really know that well. Or, at least not well enough for that kind of start-to-finish result.
Another commenter wrote a really interesting question: How do you not degrade your abilities? I have to say that I still had to spend days figuring out really hard problems. Who knew that 64-bit MinGW has a different struct layout for gettimeofday than 64-bit Linux? It's not that it's not obvious in hindsight, but it took me a really long time to figure out that was the issue, when all I have to go on is something that looks like incorrect instruction emulation. I must have read the LoongArch manual up and down several times and gone through instructions one by one, disabling everything I could think of, before finally landing on the culprit just being a mis-emulated kind-of legacy system call that tells you the time. ... and if the LLM had found this issue for me, I would have been very happy about it.
There are still unknowns that LLMs cannot help with, like running Golang programs inside the emulator. Golang has a complex run-time that uses signal-based preemption (sysmon) and threads and many other things, which I do emulate, but there is still something missing to pass all the way through to main() even for a simple Hello World. Who knows if it's the ucontext that signals can pass or something with threads or per-state signal state. Progression will require reading the Go system libraries (which are plain source code), the assembly for the given architecture (LA64), and perhaps instrumenting it so that I can see what's going wrong. Another route could be implementing an RSP server for remote GDB via a simple TCP socket.
As a conclusion, I will say that I can only remember twice I ditched everything the LLM did and just did it myself from scratch. It's bound to happen, as programming is an opinionated art. But I've used it a lot just to see what it can dream up, and it has occasionally impressed. Other times I'm in disbelief as it mishandles simple things like preventing an extra masking operation by moving something signed into the top bits so that extracting it is a single shift, while sharing space with something else in the lower bits. Overall, I feel like I've spent more time thinking about more high-level things (and occasionally low-level optimizations).
For me, however, there is one issue: how can I utilize AI without degenerating my own abilities? I use AI sparingly because, to be honest, every time I use AI, I feel like I'm getting a little dumber. I fear that excessive use of AI will lead to the loss of important skills on the one hand and create dependencies on the other. Who benefits if we end up with a generation of software developers who can no longer program without AI? Programming is not just writing code, but a process of organizing, understanding, and analyzing. What I want above all is AI that helps me become better at my job and continue to build skills and knowledge, rather than making me dependent on it.
So what's my cut of something basically worthless? Doesn't seem lucrative in the long run.
> They go on to discuss what is good or bad in writing. Socrates tells a brief legend, critically commenting on the gift of writing from the Egyptian god Theuth to King Thamus, who was to disperse Theuth's gifts to the people of Egypt. After Theuth remarks on his discovery of writing as a remedy for the memory, Thamus responds that its true effects are likely to be the opposite; it is a remedy for reminding, not remembering, he says, with the appearance but not the reality of wisdom. Future generations will hear much without being properly taught, and will appear wise but not be so, making them difficult to get along with.
https://en.wikipedia.org/wiki/Phaedrus_(dialogue)
e.g. had an issue with connecting to AWS S3, gave Claude some of the code to connect and it diagnosed a CREDENTIALS issue without seeing the credentials file nor seeing the error itself. It can even find issues like "oh, you have an extra space in front of the build parameter that the user passed into a Jenkins job". Something that a human might have found in 30+ minutes of grepping, checking etc it found in <30 seconds.
It also makes it trivial to do things like "hey, convert all of the print statements in this python script to log messages with ISO 8601 time format".
Folks talk about "but it adds bugs" but I'm going to make the opposite argument:
The excuse of "we don't have time to make this better" is effectively gone. Quality code that is well instrumented, has good metrics and easy to parse logs is only a few prompts away. Now, one could argue that was the case BEFORE we had AI/LLMs and it STILL didn't happen so I'm going to assume folks that can do clean up (SRE/DevOps/code refactor specialists) are still going to be around.
Honest question for the engineers here. Have you seen this happening at your company? Are strong engineers falling behind when refusing to integrate AI into their workflow?
I don’t think I will. I am glad I have made the radical decision, for myself, to wilfully remain strict in my stance against generative AI, especially for coding. It doesn’t have to be rational, there is good in believing in something and taking it to its extreme. Some avoid proprietary software, others avoid eating sentient beings, I avoid generative AI on pure principle.
This way I don’t have to suffer from these articles that want to make you feel bad, and become almost pleading, “please use AI, it’s good now, I promise” which I find frankly pathetic. Why do people care so much about it to have to convince others in this sad routine? It honestly feels like some kind of inferiority complex, as if it is so unbearable that other people might dislike your favourite tool, that you desperately need them to reconsider.
I don’t know why this is so controversial it’s just a tool, you should learn to use it otherwise as the author of this post said you will get left behind but don’t cut yourself on the new tool (lots of people are doing this).
I personally love it because it allows me to create personal tools on the side that I just wouldn’t have had time for in the past. The quality doesn’t matter so much for my personal projects and I am so much more effective with the additional tools I’m able to create.
If you disagree with the above statement, try replacing "AI" with "Docker", "Kubernetes", "Microservices architecture", "NoSQL", or any other tool/language/paradigm that was widely adopted in the software development industry until people realized it's awesome for some scenarios but not a be-all and end-all solution.
It's very clearly getting better and better rapidly. I don't think this train is stopping even if this bubble bursts.
The cold ass reality is: We're going to need a lot less software engineers moving forward. Just like agriculture now needs way less humans to do the same work than in the past.
I hate to be blunt but if you're in the bottom half of the developer skill bell curve, you're cooked.
Do I use it? Yes, a lot, actually. But I also spend a lot of tunning prunning its overly verbose and bizantine code, my esc key is fading from the amount of times I've interrupted it to steer it towards a non-idiotic direction.
It is useful, but if you trust it too much, you're creating a mountain of technical debt.
They dismiss the religion like hype machine.
You want to market to engineers, stick to provable statements. And address some of their concerns. With something other than "AI is evolving constantly, all your problems will be solved in 6 months, just keep paying us."
Oh by the way, what is the OP trying to sell with these FOMO tactics? Yet another ChatGPT frontend?
"She wrote a thing in a day that would have taken me a month"
This scares me. A lot.
I never found the coding part to be a bottle neck, but the issues arise after the damn thing is in prod. If i work on something big (that will take me a month) thats going to be anywhere from (im winging these numbers) 10K LOC to 25K LOC).
If thats a bechmark for me the next guy using AI will spew out at a bare minimun double the amount of code, and in many cases 3x-4x.
The surface area for bugs are just vastly bigger, and fixing these bugs will eventually take more time than you "won" using AI in the first place.
I am one of those dismissers. I am constantly trash talking AI. Also, I have tried more tools and more stress scenarios than a lot of enthusiasts. The high bars are not in my head, they are on my repositories.
Talk is cheap. Show me your AI generated code. Talk tech, not drama.
But I see where things are going. I tried some of the newer tooling over the past few weeks. They’re too useful to ignore now. It feels like we’re entering into an industrial age for software.