I have absolutely seen this, and love to read out it's quotes to my wife. Things like "You're right, but for a stronger reason than you said:" and crap like that.
Even if it's correct about that, if it were a human, I'd assume they were 1-upping me on purpose to make themselves look better.
> Things like "You're right, but for a stronger reason than you said:"
I also get this a lot, but almost always with "and for a stronger reason than you said", which makes it sound more like it's reinforcing me than one-upping me.
Looking through my recent transcripts, I found this pattern 12 times, with every time using "and" instead of "but".
Eg:
- "Confirmed, and it's worse than a pause quirk."
- "I think the ban is right, and it's a stronger idea than what I'd proposed."
I did find one instance with "but", but it was a genuine disagreement rather than 1-upping or presenting strengthening evidence: "I would cap it, but for a different reason than fairness."
It probably is "and", and I agree it sounds better than "but". That was probably just me misremembering because it was about the feeling and not the exact words.
But if it were a person, I'd still definitely think they were trying to show they were smarter than me.
While I mostly agree with you, this is the kind of thing that might not have been done if the AI couldn't do the heavy lifting.
They had previously chosen React Native because it was easier for programmers to keep it updated, since it was really just 1 codebase. With AI, those same programmers can do the more difficult version, keeping the native apps updated separately.
So did it kill a job, or did it make it possible for the existing programmers to do it better?
It's the kind of thing that is really hard to determine in general, but here, it really does sound like they only made the change because it became possible with existing resources. They would not have done it otherwise.
That's an example of AI growing the sector that can lead to more jobs. Because suddenly a lot of tasks that weren't economically viable are now going to be in demand. Custom software for small businesses, platform specific optimized code instead of cross platform software, etc...
In case of my company, the port was planned for this year, with a 9 month timeline and about 10 FTE team. It ended up being done in 3 months, with 2 engineers. (Sure, plus testers and internal bureaucracies, but that 2 FTE for 3 months vs. 10 FTE for 9 forecasted is apples-to-apples). Sure its eating up SWE jobs.
That was my experience with Claude when my vibe-coded project was small.
But now that I've been working on it a month and there's a lot of documentation, it's pretty clearly ignoring parts of the documentation and parts of the code. It will come up with some ridiculous statement about how something works, and I'll challenge it, and it'll admit I'm right.
It definitely reads more documentation than any programmer I've ever worked with (myself included) but because it doesn't have a memory other than the documentation, it still makes mistakes like that.
I haven't turned on "memory" or tried it with Codex, so I don't know how that'll change soon, though.
Yeah the biggest task these days that I do manually is curating the documentation. AGENTS.md in every major directory, and a variety of reference docs that are explicitly referenced in those files.
# See DOC-ITEM-NAME
DOC-ITEM-NAME.md
When referencing documents, always use the exact syntax See - this is enforced by a lint on precommit
And those doc items are basically all of the values, architectural, strategic, and tactical items. It's a poor man's in-repo RAG but it's shockingly effective, especially if you keep them small. I may migrate some/all of them to skills over time, but I usually update them biweekly, and I only allow agents to make small edits or propose new notes. And typically I go through and delete or curate any agent edits before merge.
Depending on language I've seen this scale past multiple millions of lines of code, as long as you pair it with all of the linting and tooling that you can possibly build.
It's new in that it's not really a hybrid. It isn't meant to take over when you run out of battery. It's meant as an emergency recharge for the battery to get you to the next charging station.
Hybrids can just run on gas and not have to worry about the distance to the next charging station.
That’s a bit of a stretch… most of the announced EREVs are using pretty conventional 4 or even 6-cylinder engines (like the 3.6L Pentastar V6 in the upcoming Jeep Wagoneer REEV). Even though it isn’t connected to the wheels, the engine is capable of keeping the car charged and running normally once the battery runs out. AFAIK, the intention is to be able to drive for hundreds of miles on the engine, not just limp along a dozen or so miles to get to a charger.
Probably 20TB here, 10.11.11, upgrade was smooth and quick. Maybe a few minutes of migration time?
I was actually just getting frustrated with Jellyfin performance and had just told my wife last night that I was switching back to Plex. I didn't realize it was a .11 thing. I just realized that it had gotten worse lately.
12 is working good in the browser so far, but I haven't really put it through the paces fully on Android.
I don't think it's generalizable. The kind of person who copy and pastes from the AI is the kind who did the same from StackOverflow before. It's more compelling, and we probably see more of them because of it, but it's the same general thing.
The kind of person who insists on understanding things and working through the problem has always been rarer. It's not "humble", it's "inquisitive" and "persistent".
I'm seeing people who _used to be_ like that losing that understanding without realizing it's happening - they have a superficial idea of what the code is doing, enough to feel like they understand it, but the change is apparent when watching them handle something unexpected.
That's certainly what I expect to happen. LLMs will ruin your software if you don't hand-hold them, but it'll take time for that to happen. And until that does happen, businesses hell bent on using them won't have anything to push them into realizing what a mistake it was to use them.
1. "Nonsense, if it was a code-quality issue from the AI stuff, we'd have seen problems sooner, like in the first few months or a year. Oh, sure, some engineers complained, but that was just an adjustment period because they stopped once we told them we didn't care and mandated that they up-skill into the new AI-centric workflow future."
2. "The bold new AI initiative I put into place can't possibly be wrong, this failure is on the engineers who were responsible for overseeing its operation. This is supremely disappointing because we made their jobs so easy, they no longer have to write code, just review several dozens of pages per day with unremitting paranoid vigilance and attention to detail."
This, plus anyone responsible dodging that as soon as possible via job hopping. Harder to do in the current job market but internal transfers are still available, most of the time.
I was pretty early in the LLM stuff and I got called out on using it back in the day, because I showed the exact symptoms we see now, but as soon as management jumped on the train all the coworkers did a 180 and I alt tabbed out into a different department thinking it would change something... well it didn't :'D
I guess it will take some years till we are sane again or not...
I revisit it to see if the promises are unbroken now from time to time with every other update and these days it doesn't look so good. It is non deterministic all the way down.
If I know where the error is (a script written by AI in powershell) and it's a logical one, it's ok to let the AI reason about it to get it fixed and move on.
If I have no clue about how this part of the system works, then it's worth reading closely what the error says, in order to understand it first, then have the agent check the assumption you have.
Reduce the friction by having the agent explain what happened and why the fix solved it. I know this might be an intellectual placebo, but sometimes you need to fix something fast to move on. Learning takes longer, and these days everyone expects you to be a 100x engineer with AI.
> I don't think it's generalizable. The kind of person who copy and pastes from the AI is the kind who did the same from StackOverflow before. It's more compelling, and we probably see more of them because of it, but it's the same general thing.
There's an infinity between someone who has to panel beat what they copied off SO and someone who just bangs their head repeatedly against an LLM.
In essence, you are correct. What I see with LLMs is how they will happily make up stuff, meanwhile you can pretty much exhaust SO, until you are forced to understand the problem you are having.
You don't have to be a certain person to fall into this trap, you just condition your brain to accept this workflow somewhere.
Pair this with day to day work stress like time and amount of tasks and you almost give in to a sort of addiction to deal with it all.
> The kind of person who copy and pastes from the AI is the kind who did the same from StackOverflow before. The kind of person who insists on understanding things and working through the problem has always been rarer.
Well, this is where I disagree. I have coworkers who used to insist on understanding and now are doing exactly as OP wrote - copy/pasting from the LLM to brute force error messages. I don't know if it's generalizable but this is what I see in working on a frontend team with mid to senior level engineers who I respect.
One example a few weeks ago, I was helping a coworker root cause a bug in a React codebase. Pair programming isn't necessarily common but sometimes you see someone banging their head at a problem and you get curious. It turned out there was an effect (a callback that's invoked whenever some state changes) that invokes an API and this effect caused an infinite render loop because the error handling wasn't written correctly. It was something silly like - Call this API if we have no data -> get error -> update state -> call API again because we have no data...
That was almost immediately what I suspected but my colleague was pulling out all the stops usually reserved for when you're desperate or need a sanity check, like logging to stdout after each line. Both my colleague and the LLM were convinced the problem lied in the pagination logic of the helper that invokes the API. He ended up rewriting that helper imperatively and functionally. To his credit, he rewrote it by hand and implemented the recursion correctly but he was baffled when the problem remained. Completely surprised Pikachu face.
I don't think my coworker changed or suddenly stopped caring. It seems much more likely this is a predictable outcome when you lean heavily into AI authoring code for a sustained period of time. I'd also say that in itself is a consequence of the extreme pressure being exerted across the entire company to ship more code and review more code, faster.
Even if it's correct about that, if it were a human, I'd assume they were 1-upping me on purpose to make themselves look better.