Developers, what is your favorite AI?

[Eric]

After developing several apps I've settled on Claude, I have had luck with ChatGPT but you end up doing a lot more troubleshooting in my experience. Loved Fable while I was able to use it but tokens are few and expensive so I've settled on Opus 5 (high) and it's been getting it done for me, not the fastest out there but it's thorough and that's what matters most.

Can we also take a moment to talk about what this technology has done for developers? It's not just the functionality of creating new code but the biggest benefit is troubleshooting, it can figure out in seconds what would take hours or days otherwise. You can see how this is putting people out of work, it still needs guidance but it's like having a seasoned junior developer and you can only see it improving from here.

 

[Nycturne]

As a developer with 20+ years in the industry at this point, I still hate it for the small stuff. Trying to replicate a run doesn’t work because it will ignore different parts of the instructions or skill on each run. Code it generates ranges from usable to unmaintainable, or it works for certain use cases but does it in the most inefficient way that kinda meets the requirements. It introduces more bugs than a good junior dev, and I’ve had it go down a rabbit hole repeatedly when asking it to troubleshoot the code it generated. And this was with Claude Code (which I admit has been more effective than Gemini, which is a total shit-show). I sometimes give it a task to try to see if it can take code I wrote and improve it, and generally I get things like “I saved you 10 lines of code” after it added 20. I hate to think of the quality of junior devs today if this is as good as they are, to be honest.

There are the times when it does manage to do what I want it to do, and fill in a bunch of boilerplate. Or it converts tests from XCTest to Swift Testing for me. Or it points out a couple of security holes that are easy to fix in an OSS service I maintain. And then I think “eh, maybe it’ll be useful with some work”, and then it turns around and faceplants on the very next task and eats up the time I saved on the previous task with it. It’s no replacement for a human with a working brain and good training. But after the skill atrophy I saw at my previous employer in even the senior devs that stopped being able to investigate bugs without it, and the clear drop in final quality for end-users… who knows. Maybe we’ll just accept that software is just expected to be half-functional garbage riddled with bugs after a couple of decades getting processes in place to avoid this very outcome.

I find it more useful as a rubber duck that will spout gibberish 25-30% of the time. Sometimes it spits out something that is a useful insight, and if it doesn’t, at least it isn’t creating work for me. But generally if I let it touch code, it needs to be in small chunks that I can review, and even then it gets stuff wrong ridiculously often. And unlike a junior dev, it is immediately my problem, rather than the junior dev’s to figure out and learn from.

But yes, there’s been some wins when i can throw an error into it and it’ll at least point me in the right direction, but just as often it’ll point me in the wrong direction, or hallucinate a solution that doesn’t exist, or tell me what I’m doing shouldn’t even work because it misses context. And I catch it precisely because of my years of experience.

And yes, I am jaded. I watched LLMs eat away at the skillset of a number of people I respected at my last job. I watched the quality of the output drop to a level lower than any point I can remember. So yeah, I’m not a fan of the stuff, but I keep it in my back pocket in the case that I’m wrong and LLMs do somehow reshape engineering for the better before I can retire. But people aren’t using LLMs to be engineers, they are using LLMs so they don’t have to be engineers. So much talk about upskilling, but its been more like deskilling.

That said, Codex or Claude is about as “good” as it gets right now.

 

[MEJHarrison]

I find it more useful as a rubber duck that will spout gibberish 25-30% of the time.

That is exactly how I see it. I don't trust it to write code. And when I do, I understand that code before I ever copy it. I won't paste something in I don't understand. I just treat it as a fellow developer. I've found it can be great to just talk to and ask advice. Sometimes it has good ideas. Sometimes I don't care for its ideas. Just like a real person.

 

[Eric]

That is exactly how I see it. I don't trust it to write code. And when I do, I understand that code before I ever copy it. I won't paste something in I don't understand. I just treat it as a fellow developer. I've found it can be great to just talk to and ask advice. Sometimes it has good ideas. Sometimes I don't care for its ideas. Just like a real person.

A lot of the time this is exactly what I'm doing, I'll just say something like "let's outline this idea before making any changes", especially with Claude because it'll just go to town and in the last two months has seemed to have gotten way smarter in its handling of things. But for general advice it's great, seems to want the right results.

As real developers I can see where both of you guys are coming from. Prior to my retiring a large part of my job was managing a team that included developers and I can say that while I wasn't as seasoned as they are I could now do what I couldn't do back then and would no longer need to rely on them.

When it comes to dealing with all the overhead of an employee, time zone differences, meetings, scheduling, etc. there's just no comparison. I hate saying that but it's the reality.

 

[Nycturne]

As real developers I can see where both of you guys are coming from. Prior to my retiring a large part of my job was managing a team that included developers and I can say that while I wasn't as seasoned as they are I could now do what I couldn't do back then and would no longer need to rely on them.

One of the issues I’m seeing in the wild is a sheer disconnect between management, overworked PMs, and the engineers tasked with delivering results. So you’ll forgive me if I say this doesn’t necessarily add credibility, IMO. I generally find myself having to manage up quite often to ensure my manager actually understands what the engineer is actually bringing to the table, and that’s been true my whole career. And sometimes even an engineer in management can get them underestimating the work that’s actually involved because they think they have all the context for a given problem when they don’t. Especially when software development has been notoriously hard to estimate effort required and requires understanding of the tech debt inherent in a given codebase to even begin to try.

If you think you can produce something of value with an idea and an LLM, what makes you think an engineer with an idea and LLM can’t push faster than you? And wouldn’t you then see the value in having engineers augmented by LLMs versus jettisoning them?

That said, in my experience, there is a huge space that software development has covered in the last 20ish years when everyone had to become, at least in part, a tech company. And that was borne out by the fact that I had job interviews offering anywhere between 35k to 100k/yr out of college for fundamentally the same job. And this is where low-code/no-code platforms have really flourished, by eating away at the low end of the software development market where a lot of LOB apps live and there’s not a lot of skill demand because these days it is all CRUD. I remember when MSFT was pushing .NET (especially VB.NET) as the way to make LOB apps cheaper. Now it’s PowerApps.

One thing I do see is that LLMs will continue to roll back the “everyone’s now a tech company” that low-code and various SaaS B2B platforms helped with, and I’d even argue that it will undermine some of this low-code space. The apps made here aren’t exactly high-quality stuff, they are made to budget to fill a particular internal need. So I can see LLMs commodifying the LOB space even more. But LLMs are not going to be what pushes the state of the art. Especially when it can only be trained on what already exists.

When it comes to dealing with all the overhead of an employee, time zone differences, meetings, scheduling, etc. there's just no comparison. I hate saying that but it's the reality.

The problem here is that the code itself isn’t the value. It’s what the product can do that is the value. The _engineering_ that happens is there to try to make sure that when the users start threatening to leave, services go down, or the direction needs to change, it’s actually possible to do that without going bankrupt in the process, because the code isn’t a complete mess. Not to vomit code. It’s never been that, despite some really dumb metrics like kLoCs used to measure productivity. Ballmer, for all his issues, understood this very well. His issue was poor direction, which LLMs won’t solve one bit.

In my experience, adding LLMs didn’t actually solve any of these other time sinks you list here. Because it’s not the production of code that engineering is ultimately about. The code is the artifact, yes, and in the long run, it is the liability. The irony is that engineers also complain about the overhead of management, meetings, etc from what they are expected to deliver. You see that developer as a burden and overhead, but they are also the ones trying to keep things on the rails for you.

So far, we haven’t actually seen companies claim success in cutting development teams in favor of LLMs. Just that they’ve been doing it, and some have reversed course after doing it.

Honestly, I think Cory Doctrow makes a good argument around this here: https://pluralistic.net/2026/01/06/1000x-liability/#graceful-failure-modes

 

[Eric]

One of the issues I’m seeing in the wild is a sheer disconnect between management, overworked PMs, and the engineers tasked with delivering results.

Spoken like one who is genuinely in the business, I see this as the biggest deficit of any organization. They're trying to do too much with too little and if you show yourself as one who is capable and willing to work all the extra hours to get the job done you're rewarded with more work and less of a life. This is what burned me out hard and sent me into retirement early. Sorry for the sidebar but just wanted to add that.

In my case, getting developers onboard (mostly offshore) and everyone else involved on the project was like herding cats, pretty much what you've described here. However, if I wasn't overworked with the project side of things I would often develop my own solutions, some coding, some server config, etc. Had I had this ability apply AI to my workflow I would've been able to do far more myself without the need to rely on developers, mostly because it cuts the time needed for these tasks substantially.

I agree that it still needs to be in the right hands of one capable of understanding what it's doing under the hood but with that it's an excellent tool.

 

[rdrr]

My group has inherited a program written in Java. The developer has retired and there is little to no comments in the code. My plan is to replace it with modern code, but for step one, I just want Claud or some other AI to comment the crap out of it. My team has zero Java coding experience. What do you suggest is the best AI model to do this, and what would be a good prompt?

 

[Eric]

My group has inherited a program written in Java. The developer has retired and there is little to no comments in the code. My plan is to replace it with modern code, but for step one, I just want Claud or some other AI to comment the crap out of it. My team has zero Java coding experience. What do you suggest is the best AI model to do this, and what would be a good prompt?

I personally use Claude for all development now, it's known for being proficient for this purpose.

If you have the project files you can send it all to Claude and it will analyze it and then guide you through whatever changes you want to make. Having some development experience will help but if there aren't any major changes you'll likely get away with vibe coding it. I would just add the caveat that it should be reviewed by a professional but that's really your call.

 

[leman]

I use Anthropic models. They mostly do a good job, although sometimes it takes effort to keep them on track. Opus can be very opinionated and a real pain in the ass

I am very impressed by Fable by the way. First model that I would describe as intelligent. I use it as a feedback tool for research papers and it's almost scary how good the critique is. One big difference to previous models is how accurately Fable can track references. Opus would regularly confuse and hallucinate page and future numbers, for example, but Fable never fails to deliver something like "list point 3 on page 15 has this number, and figure 10 on page 43 legend has a different number for the same measurement". It's a bit scary even.

 

[Eric]

I use Anthropic models. They mostly do a good job, although sometimes it takes effort to keep them on track. Opus can be very opinionated and a real pain in the ass

I am very impressed by Fable by the way. First model that I would describe as intelligent. I use it as a feedback tool for research papers and it's almost scary how good the critique is. One big difference to previous models is how accurately Fable can track references. Opus would regularly confuse and hallucinate page and future numbers, for example, but Fable never fails to deliver something like "list point 3 on page 15 has this number, and figure 10 on page 43 legend has a different number for the same measurement". It's a bit scary even.

Also a huge fan of Fable, I just don't have the credits for everything I want to do, even on my paid plan so I've reverted back to Opus 5 (high) which does a pretty good job and only gets snooty with me when I start shaking my finger at it pretty hard.

 

[Nycturne]

Spoken like one who is genuinely in the business, I see this as the biggest deficit of any organization. They're trying to do too much with too little and if you show yourself as one who is capable and willing to work all the extra hours to get the job done you're rewarded with more work and less of a life. This is what burned me out hard and sent me into retirement early. Sorry for the sidebar but just wanted to add that.

I mean, it’s partly why I’m on a sabbatical of sorts at the moment (can’t quite retire fully, but I can be picky about where I land and not in any rush), so it seems relevant. I brought it up because that deficit is leading to a disconnect between where to effectively apply LLMs, and how they have been mandated for use. Group A sees large wins in limited testing or specific scenarios, and so mandate that the org should be getting those wins across the board when it doesn’t work that way. The actual productivity net overall is quite low with what research has been done. So I’d much rather work in an org taking a reasoned approach to LLMs, finding the tasks/niches where we can get real wins, rather than just mandating that engineers offload to LLMs because we can output more LoC.

Over time, I’ve learned the real hazard of offshoring to a partner company or vendor company is that you are literally giving away your value. A company that hands off PCB design and BOM of their laptops to the factory isn’t really producing anything of value anymore, they’ve abdicated that to the factory, and then get all ‘shocked pikachu face’ when the factory figures out it can reap more of the profit margin themselves with an in house brand. And when the company realizes it is just a white label, it sells off the brand to those same companies that they gave the secret sauce to (I vaguely thinking of ThinkPad here). No wonder US brands have been hollowed out.

And one reason I bristle at FAANG-level engineering right now is that the same mentality is being applied to LLMs and engineering. Offshore your engineering to the bot, it’ll ‘save us money’ (only when token costs are heavily subsidized). Even though we start losing real ownership over our assets and liabilities in the process to a service we are now dependent on for our product. It seems like an insane business strategy to me.

In my case, getting developers onboard (mostly offshore) and everyone else involved on the project was like herding cats, pretty much what you've described here. However, if I wasn't overworked with the project side of things I would often develop my own solutions, some coding, some server config, etc. Had I had this ability apply AI to my workflow I would've been able to do far more myself without the need to rely on developers, mostly because it cuts the time needed for these tasks substantially.

Working with offshore folks is a whole thing for sure. We had teams in Paris, Redmond and Hyderabad all working in the same space. Timezone stuff is one thing, but cutting through the cultural differences is somehow even harder.

But yeah, I use LLMs for a lot of one-shot stuff, especially in the home lab. I don’t want to have to convert 40+ docker compose files to podman quadlets by hand (although that project is what showed me how repeatability is an issue in Opus-class models, since I chunked the work and reviewed/deployed each chunk). And a CI bot handles a lot of day-to-day upgrades that need to happen.

 

[leman]

Gonna love Opus. So today I was using it to build assignment instructions for my upcoming class. It did a nice job writing a detailed Typst file with details and a grading rubric, and then cheerfully explained to me "hey, I invented a new file that the assignment actually doesn't feature! might want to delete the part where I talk about it!"

 

[Eric]

Gonna love Opus. So today I was using it to build assignment instructions for my upcoming class. It did a nice job writing a detailed Typst file with details and a grading rubric, and then cheerfully explained to me "hey, I invented a new file that the assignment actually doesn't feature! might want to delete the part where I talk about it!"

Learning from all the other bots that forget to clean it up.

 

[Eric]

I have to say I am more than impressed with Claude Opus 5, it takes a bit more time but it's thoughtful and thorough. I've used it for two iPhone (and PWA) apps now, a lot of deep dive with both structure and code but it really handled it well, pushes back where it needs to, offers up sound suggestions and just gets it done.

 

[Andropov]

I find it more useful as a rubber duck that will spout gibberish 25-30% of the time.

I'm also using it this way, but I know I'm pretty much alone in that, at least in my company. It's just too tempting to copy the requirements, paste them into Codex/Claude/Gemini and if the result works, it works. So no one stops to think about architecture, maintainability...

It's sad because it's a genuinely useful technology that could allow developers to write much better code. It regularly catches important issues in my PRs before I share them with the rest of the team. But instead of that, it's mostly being used to ship faster, at a much lower quality.

But after the skill atrophy I saw at my previous employer in even the senior devs that stopped being able to investigate bugs without it, and the clear drop in final quality for end-users… who knows.

I've seen this too, and it's the most disheartening part of it all, at least for me. Some of the people I used to look up to appear to be brain dead now, flooding everything with poorly written code or walls of Slack text. There are exceptions, of course, but quite rare. Some engineers don't even understand the systems they built anymore.

 

[Nycturne]

It's sad because it's a genuinely useful technology that could allow developers to write much better code. It regularly catches important issues in my PRs before I share them with the rest of the team. But instead of that, it's mostly being used to ship faster, at a much lower quality.

To an extent, yes. The problem is that any level of reliance on it will tend to pull you towards something akin to a mean. The types of issues it will find without good practices setup ahead of time tend to be the sort of stuff that are a bit more common. Done the way you are using it, will tend to pull the floor up a bit, but where I worry is compressing the ceiling as well. Confidence that it's able to catch enough things means deeper analysis by people gets skipped, or the sort of brainstorming that happens when you are stuck on a problem won't lead to interesting solutions that can make an impact on the industry.

I've seen this too, and it's the most disheartening part of it all, at least for me. Some of the people I used to look up to appear to be brain dead now, flooding everything with poorly written code or walls of Slack text. There are exceptions, of course, but quite rare. Some engineers don't even understand the systems they built anymore.

I'll be honest, before I left my last role, there were some interesting discussions I had with some of the other senior devs in my org. But these were folks where we had our own private chats going into some of the "what the heck" moments we were seeing and sharing experiences with each other off the record. One seemed to be trying to figure out where his next gig was going to be as well.

But yeah, I really worry for the lack of good Fingerspitzengefühl from the next round of engineers. The sort of instinct you build through years of friction, failure, and success. Especially when existing engineers in the senior band seem to be shedding it faster than they gained it.

 

[cbum]

You need knowledge to use AI, but there will be less and less knowledge the more AI is used...

 

[Andropov]

Confidence that it's able to catch enough things means deeper analysis by people gets skipped, or the sort of brainstorming that happens when you are stuck on a problem won't lead to interesting solutions that can make an impact on the industry.

Yeah, I'm already seeing this. Most of the code reviews I get are AI-generated now, which has led to a completely different set of issues being caught. I know nowadays a PR won't get through with an off-by-one error or a call not wired up correctly, because the AI is good at finding those / tracing through long call stacks. Even complex stuff like low-level race conditions are often detected.

But on the other hand, now it's very likely that a PR gets through duplicating tens of thousands of lines of code instead of reusing an existing piece of the codebase, as no human reviewer is there to say "oh, you could just call X or Y". Same with LLMs adding a utility/helper method to do a common task (say, get the size of a folder in the filesystem) despite there being a thousand identical methods doing the same thing in the codebase. As long as the code is syntactically/semantically correct, the AI won't complain about duplication/architecture.

Another thing that's now getting under-reviewed are product decisions set in code (say, gating a feature to a specific set of users). The AI has no clue what the intended behavior is, and human reviewers don't review it, so it's a lot more likely that an issue there gets shipped. One artifact of this, which I find incredibly funny, is that sometimes I see tests "verifying" that a piece of code does something that's clearly *not* the intended behavior.

It's a tough problem, because in addition to all this, the incentives for reviewing PRs are now all wrong. I used to be very thorough in my PR reviews, but I'm getting easily 5-10 times more code to review on a daily basis, *and* the turnaround from long PR reviews to revised code has shortened from a few days to a few hours, as many people just feed the review comments to the AI. This sometimes goes to the extreme that I know I'm just prompting someone else's LLM with extra steps. Which I wouldn't mind, but then I'd basically spend all my time completing other people's tasks with no time for my own.

Personally I've given up on this, I now review only a fraction of the PRs I get requested. I can't review all of them, and using AI to "speed it up" makes zero sense because other devs are obviously able to ask an AI themselves.

But yeah, I really worry for the lack of good Fingerspitzengefühl from the next round of engineers. The sort of instinct you build through years of friction, failure, and success. Especially when existing engineers in the senior band seem to be shedding it faster than they gained it.

A year ago I thought this was going to be mostly a problem for new engineers, but yeah, existing ones are being heavily affected by this too, much more than I could have ever imagined.

I wonder how the job market is going to select for people that retained these abilities, though (for the positions that require it, for whatever reason). Experience and/or degrees don't mean nearly as much. I guess the interview will have to do, but...

 

[Eric]

First time I've used it for something other than coding was to review several gigabytes of data for drone logs/footage that was all scattered about on a hard drive. It took what would've taken days to sift through and broke it down into very simple terms, I was able to query it for some pretty involved questions and while I still reviewed manually it nailed everything I needed.

 

[Nycturne]

First time I've used it for something other than coding was to review several gigabytes of data for drone logs/footage that was all scattered about on a hard drive. It took what would've taken days to sift through and broke it down into very simple terms, I was able to query it for some pretty involved questions and while I still reviewed manually it nailed everything I needed.

I'm somewhat curious how you approached this. Did you have it try to attack the dataset directly, or did you have it piece together a process to run against the dataset to produce a distilation that either you or the LLM then looked at?

The general consensus I've seen on the engineering side is that you get more consistent/usable results doing the latter.

But on the other hand, now it's very likely that a PR gets through duplicating tens of thousands of lines of code instead of reusing an existing piece of the codebase, as no human reviewer is there to say "oh, you could just call X or Y". Same with LLMs adding a utility/helper method to do a common task (say, get the size of a folder in the filesystem) despite there being a thousand identical methods doing the same thing in the codebase. As long as the code is syntactically/semantically correct, the AI won't complain about duplication/architecture.

I do find this hilarious. For two specific reasons:

1. I'm not currently engaged with this problem anymore, but agree that it was constant. We had someone trying to generate documentation using AI, for the AI, and it would just copy/paste chunks of code rather than making references to files. It literally produced 10x the content it needed for the job, and in the process, made it less useful for a person who might want to understand the thinking behind the code. EDIT: And more expensive for an LLM to try to digest... so literally worst of both worlds.

2. My father never really swore much. Except when a computer wouldn't do what it's told. So far in my life, I managed to avoid that behavior. Except I find myself doing it to LLMs whenever it does stupid stuff that worsens the design/architecture of what I'm trying to build. This is one reason I tend to put it on a short leash. But they keep making Claude Code nag you to let it make edits when I just wanted it to find the flaw in an idea I had.

Another thing that's now getting under-reviewed are product decisions set in code (say, gating a feature to a specific set of users). The AI has no clue what the intended behavior is, and human reviewers don't review it, so it's a lot more likely that an issue there gets shipped. One artifact of this, which I find incredibly funny, is that sometimes I see tests "verifying" that a piece of code does something that's clearly *not* the intended behavior.

Yes. So much this. We had a manager a couple levels up start asking if we can add AI to skim the PRs and let it decide how many human approvals the code needs. His example range was 0-3. But we all knew he was fishing for us to assemble a mechanism that would allow the faster PR cadence to lead to faster movement of code to prod. Despite as you say, it leading to so much stuff just not getting reviewed.

But yeah, I've seen a lot more stuff slip through in the last 24 months than the entire decade leading up to that.

It's a tough problem, because in addition to all this, the incentives for reviewing PRs are now all wrong. I used to be very thorough in my PR reviews, but I'm getting easily 5-10 times more code to review on a daily basis, *and* the turnaround from long PR reviews to revised code has shortened from a few days to a few hours, as many people just feed the review comments to the AI. This sometimes goes to the extreme that I know I'm just prompting someone else's LLM with extra steps. Which I wouldn't mind, but then I'd basically spend all my time completing other people's tasks with no time for my own.

Again, same. I left my role in part because if I was going to go through all this pain, it wasn't going to be for a project that I had little to no interest in.

If we weren't on different continents, I'd offer to meet at a cafe sometime and share stories.