AI and vibe coding have truly revolutionized software development

[booscrawl]

I thought hell would freeze over or turn into Finland before Siwastaja became a Claude fanboy. How the tables have turned.

[KE5FX]

Just in time for Claude to slip into senescence.

They are having serious problems lately, almost certainly due to too many subscribers using too much compute.  Anyone who starts using Claude today will probably come away with a less-favorable opinion, unfortunately.

[Siwastaja]

Just in time for Claude to slip into senescence.

They are having serious problems lately, almost certainly due to too many subscribers using too much compute.  Anyone who starts using Claude today will probably come away with a less-favorable opinion, unfortunately.

I became a fanboy just in time to see some of the "old one" and notice differences lately. Specifically, in last 1-2 weeks I have seen that now instead of random "Overloaded" or "Rate limited" API errors, which were annoying and really performance-degrading, now we have sudden mood jumps where it just randomly performs visibly worse. I don't know which is worse, refusing to work at all, or working in unexpected and crappier ways. Clearly the pricing model is unsustainable.

As I have said - I fear enshittification is the biggest threat for AI. Silver lining is that current AI workflows have very little vendor lock-in, so competitive situation is healthier than e.g. with social networking sites, where enshittification is at its worst because of very high cost / near impossibility of switching.

But I can totally see I'm working with Claude the same way as I worked with human professionals: together with it, I try to figure out simplest way to solve the problem, to get the job done, and I am always ready to flex on the original requirements to make the problem simpler. Now reading through your link it seems many are expecting Claude to perform better than that - to solve problems that are difficult but not impossible, without micromanaging, "helping it out" by accepting solving a different, simpler problem instead. Fair enough - that would be fantastic. It's also the level of performance I have never seen from any real human being co-worker - but maybe it tells more about the human professionals I have had to unfortunately trust.

My workflow also seems to be: ask it first "how you would do it", evaluate it together, then say "do it" - this pattern forces it to read the files and do the planning. If I read that correctly, it was better at doing this autonomously? This is something I haven't seen? So it has been even better?? 

Typical example from yesterday: need significant fix/redesign of an algorithm. Ask it what needs to be done. It gets it a bit too complex, missing an opportunity for reuse of earlier calculation. Point it out. It gives an estimate that now it's 1 day's job. I totally agree, it would be 1 day's job for me. I say "do it". 13 minutes later, it's finished and tested with a simple test case I didn't specifically ask for. I'm very happy with this performance level, really: 15 minutes chatting and 15 minutes of implementation = day's job. But it can't really work completely independently.

[KE5FX]

Enshittification is the #1 concern I have about all of this stuff.  It is profoundly unsettling that the model I am running today will not be the same as the one I run tomorrow, and that the one available tomorrow may well be worse in any number of aspects I consider important. 

If we were sharecroppers on Microsoft's plantation before, we are going to end up outright slaves to Anthropic and the other top-tier inference providers.

I have been waffling, and will continue to do so for some time, about putting together a stupidly-expensive inference platform and throwing in my lot with the /r/localllama cult.  I suspect that for normal development tasks, the tool harness is now actually more important than the model itself, or will be soon.  The current open-weight models may be good enough if we learn how to leverage them well enough.

[Siwastaja]

If we were sharecroppers on Microsoft's plantation before, we are going to end up outright slaves to Anthropic and the other top-tier inference providers.

If we want to maintain the increased speed and quality of software development we get used to. But in absolute terms, it's harmless - nothing prevents us from reverting back to how software was developed since the beginning to ~1 year ago.

Of course, there are risks - like, with AI capable of dealing with more complexity, it might suggest complex solutions we can't keep running without AI. For us, it's kind of opposite - human beings came up with things that are difficult to operate without AI, and now AI helps us operate that human-generated complexity. (And often, that complexity is unavoidable - software is difficult.) If we lose AI, then we are just back to square one, which feels worse because human brain is a derivator with alarms ringing with any negative change, but absolutely speaking it's just the same it used to be, then. With possibly a lot of good work done with the help of the AI while it lasted. With the risk that it proposed also hard-to-maintain work which was accepted by users. That is the thing to keep eye on, don't let it happen.

[paulca]

If you think things were bad with over use of libraries and frameworks by those of lesser core knowledge... just wait till you see what they do with AI.

The major risk is the affirmational, confirmational, sweet talking, sicophancy and overly confident aspects.  People who don't know just lap it up and believe they can suddenly do software.

I'm not referring to anyone here.  Siwastaja is in his honeymoon period and may he enjoy it while it lasts.

Yes it's powerful, I'm not doubting that.  When I seen it coming I maybe naively thought "Well we will just produce more work, job will be easier so we will deliver like gods, it will great."  That's not how it's going down.

If I use claude and produce good output in a report or analysis, or code, or spect... et.al.  I will get asked, "Can you capture what you did in a skill and put it in the repo?"

This "repo" is  rapidly expanding suite of skills, plugins and "mega-prompt parallel agent workflows".

There are a few problems with this approach.

1.  The LLM is not deterministic.  Run the same prompt stack twice and get different answers because some of the weightings have a randomness too them deliberately.
2.  The part you are trying to "capture" is my part, the part it can't do.
3.  More prompt scaffolding does not make it better or deterministic, it makes it brittle and confused.
4.  There are no objective metrics that I have seen to say one prompt scaffold is objectively better than another.

Oh and the one that I believe will burst their stupid little bubble.

5.  A single run of some of these systems will cost you $500.  How I got my output on $8.50 is not something adding another prompt layer will achieve.

EDIT:  Forgot one.

6.  Why on earth are software engineers even attempting to train claude to replace them?  Why are they even attempting this?  They should be showing clear, hard empirical proof that claude works best with good, skilled, experienced engineers in the loop and both are required.

[Psi]

All this talk of AI makes me thinking of that scene from Person of Interest (2011)

The one where the AI, which had been programed to erase its memory every night and start new the next day, had decided to hire an entire office building of humans to print out all its memories in binary on paper each day and then scan them in then next day. Just so it could remember.

[Siwastaja]

Siwastaja is in his honeymoon period and may he enjoy it while it lasts.

Two factors: honeymoon which I don't deny and which wears out, but bigger factor is, I have never had a chance to work with really good team of software developers, at least not long enough to see how daily life with them would turn out (short occasional sharing of project responsibilities do not count). I'm amazed simply because Claude saved my ass. I have a project, real, significant project, with paying customers, and some society-level impact. Since I'm a co-founder and shareholder, of course I'm interested to see it succeed. And that project has seen serious neglect for nearly its whole existence from our inability of finding really good developers. Yes, our fault - we need to hire well. Which we didn't. But it was Claude that saved us.

But here's the bias: this might not mean that Claude is so exceptionally good. Rather, it might mean that the professionals we worked with earlier were exceptionally bad. Our mistake.

And maybe relying on a service which costs us $100/month but is effectively subsidized, i.e. costs more than that for Anthropic to provide, is our current mistake. But then again, I don't believe I'm actually consuming $10000 worth of resources. I'm not a heavy user at all; I'm not launching 50 agents in parallel to do a job. Like, my max 5x plan varies between 0% - 50% of usage. Never exceeded the usage limit on that. My poor experiences of trying leave it unsupervised for a large, complex task means I don't do it. Hence not much crap work to throw away either.

I hope having the AI in the loop helps us to get rid of poor and mediocre professionals, and replace them with machines, while developers with good skills and most of all, good technical intuition and deep context-understanding, get into more authoritative position, being bosses to the AI. That seems to work very well for me right now.

[ejeffrey]

If you think things were bad with over use of libraries and frameworks by those of lesser core knowledge... just wait till you see what they do with AI.

I don't think AI is going to magically cause crappy programmers with poor design skills to turn out well architecturs large software packages, any more than java or other memory managed languages did.  But it's a force multiple that isn't going to turn good programmers into power houses and it's going to let mediocre programmers produce a lot more and avoid a lot of common mistakes.  It's not going to make them great programmers, and I do see the long term risk of having an even higher volume of mediocre programs out there. But I think AI is going to make it more tractable to fix the ones that become too load bearing.  One of the most satisfying things I did recently was take some scripts written by someone who is a competent hardware engineer but just not a great coder and rewrite them to what I would expect from a mediocre SWE.  It wasn't perfect but it was a huge improvement, and gave me a more usable base to add some important features and retarget for a new device.

The major risk is the affirmational, confirmational, sweet talking, sicophancy and overly confident aspects.  People who don't know just lap it up and believe they can suddenly do software.

That has not been my experience with the coding tools I have used.  I'm not sure why. It could be  the tool design, my working method or the structured nature of programming tasks.  Whatever the reason I see far less of that compared to just using the chatbot interfaces. 

My main worry is about deskilling, and that as people come to rely on AI tools they may become less able to handle the situations where the AI tool fails.  We do see that once people start using these tools they very quickly become dependent on them. Literally addicted.  But I have for sure seem people spend 10 minutes fighting to get the AI to do something seemingly simple that would have taken them only 2 minutes to do themselves a year ago. So far this is vastly outweighed by the time savings.  But I can see if enshittification makes the products worse over time as people become more dependent on them, that could flip.

[KE5FX]

I'll never understand the whole "deskilling" concern.  As long as there are some people who are getting great results with AI models and others who can't seem to succeed with them at all, there's a skill gradient that can be climbed. 

If that's not the case in the long term, and we all end up as 100x engineers, well, mission accomplished, I guess.

[paulca]

The major risk is the affirmational, confirmational, sweet talking, sicophancy and overly confident aspects.  People who don't know just lap it up and believe they can suddenly do software.

That has not been my experience with the coding tools I have used.  I'm not sure why. It could be  the tool design, my working method or the structured nature of programming tasks.  Whatever the reason I see far less of that compared to just using the chatbot interfaces. 

I was referring to "non-techies" mostly.

When I work with claude, I stay in the loop.  I am aware of what it does well and what it does poorly.  I "chunk size" and taylor offloaded work to suit that.  I do not offload the thing it CANT do, which is thinking.  (Thinking in the human sense not what LLMs call thinking)


If I am "clauding" to produce something, the ratio of "Yes, No, Something else" responses I give are about 60/30/10%.  I say yes 60% of the time, but critically I say, ,"No" or "Something else" nearly half of the time.

In other sessions, as a test I have just spammed Yes.  Nothing ever works.

As you will have heard before.  "Writing the code was never the hard part.", software engineering has very little to do with code.  It has a lot to do with converting business desires and requirements into working systems.  The coding part is just the grunt work at the end.  Most good software engineers get bored rapidly of this part, picking the challenging and complex parts for themselves and running a mile from the 90% of boiler plate BS.

The problem is... only software engineers understsood this.  Management still see software as code only.  They never seen or measured the actual translation and modelling layer inside the SWEs as it's not that visible and management don't read design docs, technical colateral etc.

The industry is painfully learning this and in my neck of the woods it doesn't seem fast enough.  Still a lot of walls to hit painfully here, so I am running on slow with the brakes on so I can not hit the same wall.

To boil it down:
Direction.  Clear goals.  A known "end game".  A testable outcome.

WIthout all of these you are literally doomed regardless of whether an AI does it or a human does it.  The trouble is.  AI itself can't help with those big decisions.  It can inform and help, but decisions are not it's strongest suit.  So management using AI expecting it to guide them is a large part of the "popcorn" moment I'm having.

Give an engineer 9 out of 10 things he needs and he will immediately start asking for the 10th and making ultimatums about it shortly after.  "Information or no code!"

An LLM however, might just hide that and statistically substitute it for something that looks appropriate by proximity.  You have to be there in the loop and spot that and stop it and ask, "How did you come up with that?" or just tell it what it should be, or you guess rather than it.

[BadeBhaiya]

I was pleasantly surprised when I started using claude code about the fact that I had to basically do zero hand holding about the internals of the code. I just had to describe in detail what I wanted and what I wanted the code to behave like. No info about the classes, functions, architecture, variables, third party API etc.

Its very, very good at taking all the correct decisions to get what you want. You don't have to prompt it about the inner workings at all. At least when you're making it write web related CRUD code (which is rare for me, but daily bread and butter for a lot of people globally). It did the job wonderfully. But you do need to be deliberate in your expectations and explain all the behavioural quirks of the software beforehand. Changes get more error prone the longer you go on in the session since the underlying architecture may not be suitable to begin if you ask it to bolt on a dozen different features afterwards. Its the same in the real world with people writing the code as well, so that's not too surprising.

I have also noticed it helps a LOT if you can point claude code towards a simple hello world embedded project or a blank android studio project for app making, instead of letting it start from scratch.

If LLMs can figure out their operational cost issues, and are here to stay, a lot of people's jobs are going to get devalued or lost, webdevs worst affected.

[paulca]

If LLMs can figure out their operational cost issues, and are here to stay, a lot of people's jobs are going to get devalued or lost, webdevs worst affected.

I think we are going to learn something very different.  People are feeling sorry for the wrong people.

Green field cookie cutter web APIs and stuff are just that.  Any first year junior would do a fairly ok job of it.  "Coding was never the hard part" is hinted at in your post.  The bit where, when adding features later that it starts to come apart as the prior design choices limit you later. 

Two choices: 
1.  Your understanding of the bigger picture holds that and gives claude smaller sub tasks and guides it without necessarily telling it about the overall picture.
2.  Expand your prompt and spec to exhaustly describe the overall system in all it's detail.

If you attempt approach 2, your API cost will sky rocket, you will spend days or weeks writting your "perfect prompt" and you then find that it doesn't exist.  It doesn't make the problem go away and produces the same results that you got.  At some point the context and constraints have a negative effect, they over constrain or contradict each other.  They also suffer the "low attention in the middle" problem.  They are highly sensitive to things in the start of the context and highly sensitive to the later parts of the context, but almost deaf to the middle.  This is not a "behavioural" pattern of AI, it's a behavioural pattern of human language and processing.

The thing we are going to learn and are already learning.  While claude cannot replace an experienced engineer, only empower them, claude can 100% do middle management far better than most middle managers.

They don't even see it coming.  They are celebrating about the automations making their jobs easier and easier while worrying about us engineers losing our careers.  It will hit them like a train in a year maybe.

[Siwastaja]

Also what we will see are very small companies which suddenly ship serious, large projects like bigger companies. Like, 1-5 sharp people that get together and plan and execute a serious project.

With AI, some of the hardest problems go away: project management / ticketing / micromanaging tickets / prioritization of tickets. Development becomes responsive. Your brain gets to a point where it not only had this great idea, it processed it enough so that it's ready to be realized:

Old flow:
* Spend 1 hour writing a perfect ticket
* Shuffle the priority of that ticket for 2-4 weeks
* Get a developer assigned to the ticket
* Developer does not get the intent of the ticket, and implements it halfway
* Wait for 3 days to realize the ticket is closed
* Test it
* Talk with the developer, except you cannot, because it's weekend now
* Wait for Monday
* something important comes up in Monday
* Try again on Wednesday
* Developer is now sick
* Finally talk to the developer. Discuss about changes
* Get the ticket opened again, and rescheduled for improvements.
* Except that now we have those 5 new high-priority bug tickets that came in while the developer was sick
* ...
* After 2 months, the thing is finally done halfway to your original idea and somehow limps enough so that you don't want to touch it anymore
* Hate your life

New flow:
* Spend 5 minutes writing a prompt catching the key parts of your idea
* Grab coffee while Claude explores your codebase (~5 minutes)
* Chat about it for 20 minutes
* It suggests an implementation and estimates it's "two week's job"
* Say "do it"
* Come back 20-40 minutes later to see it finished, tested and running, with 2-3 remaining bugs that take another 20-30 minutes to sort out
* Iterate back and forth to really get it to the goal - not just "good enough", but what you actually wanted.
* The new feature is in production the same day you imagined it, and is very close to what you imagined, not some quackery of the feature you wanted.

So why would you hire a human professional developer at all? Why would you have a ticket system at all? Why would you enter the prioritization-of-tasks game when you can get jobs done instantly. So we can now fall back to our human brain's internal prioritization / ticket system which is actually great, it holds maybe 5-10 unfinished things and nags you subconsciously about them. If you can't get them done, you get stressed. If you can get them done, your stress relieves. The attempt to NOT do the job, AND to relieve the stress, by using ticket systems, didn't work for me. Customers call me "why the fuck isn't this working", and "we have a ticket about it" is not an acceptable answer.

But you sure do need high-level designers. This only works if you are capable designer, and actual programming experience is probably very valuable too for correct type of intuition. Having "an idea" alone isn't enough - the idea needs to be practical, sensible, implementable, and you need correct understanding not only what you want, but how you want it. AI is happy to fill in details, like explain you how different databases work and which would be most suitable for the job, but it still needs general direction.

[gamalot]

I got an AI to help me make a USBTMC interface for my GPIB device, and it absolutely crushed it. 

[paulca]

One thing I would encourage is finding claudes limits and wallowing in them for a while.

When you are proceeding as siwastaja describes and it doesn't work.  Especially when the AI cannot run the tests and iterate itself.  Like when deploying to an MCU it has no debug interface on.  It say's "That should be read now" and you flash it and get a brick.  "No it doesn't work.  No feedback, nothing."

You can get into situations where no matter how many times you bring it back to claude it will not help.  You are on your own again.

Until you hit these moments and where that limit lies it seems infinite in ability to you.  Once you have cornered it and broken it at will, you feel a little more in control of it out of neccessity.

Best advice is to keep claude tasks small enough chunked that you can verify and validate each step in the loop.  Letting claude rush ahead on a much larger compound task is where things get rough.  Espcially with "dangerously-bypass-permissions" turned on an "end to end" prompts.  All of these mistakes, compound non-deterministics, upside down cup, small vs. far away, can't count, low attention in the middle, are all still in there, you just hide them.  That or you save it all up for one big massive review process at the end... which we all know will not get done.

Deliver manager in work, kind of agreed with me when I said, "We are generating output faster than we can review.", she said, she sent a spec to the customer, generated by clause 3000 words.  In 3 minutes the document got a thumbs up and an "Approved"

She did not take it.  She called them.  As she pointed out... "this is where we do well.  This is where we show the rigor and responsibility.  Nobody reviews a 3000 document in 3 minutes.  So I want it properly reviewed and signed off on."

[Siwastaja]

One thing I would encourage is finding claudes limits and wallowing in them for a while.

When you are proceeding as siwastaja describes and it doesn't work.  Especially when the AI cannot run the tests and iterate itself.  Like when deploying to an MCU it has no debug interface on.  It say's "That should be read now" and you flash it and get a brick.  "No it doesn't work.  No feedback, nothing."

You can get into situations where no matter how many times you bring it back to claude it will not help.  You are on your own again.

Why not ask Claude for ideas how to test / add visibility?

The problem in programming is always the same freaking visibility / testability thing. That's what I always struggle with my own projects, that's what every single professional I have seen always struggled. Writing debug outputs is work. Reading the logs is work. Adding more debug prints is work. Creating an interface to make debug prints - or something similar - possible (e.g. on embedded system, or in some cloud cluster which hides normal interfaces) is even more work. Parsing, analyzing, visualizing logs is a lot of work.

Claude resorts to exact same mistake every human being I have seen, myself included, does: read code randomly, or even worse, try random modifications, because adding visibility into the system to figure out what it is actually doing is so tedious. Luckily AI is quite good at reading code and guessing, still not enough so you need to steer it a bit into suggesting ways of adding visibility and implement those.

And AI is especially well suited for that kind of "plumbing"! All you need to do is, ask. "How do we see what values the variables on the microcontroller have?" and it will come up with some probably quite decent ideas - if you didn't already. I usually have an idea of what I want, so I suggest it directly but ask for opinions, and often get some that help me to finetune what I then finally request.

This open-endenness is the key strength. And I don't mean "disable permissions and ask it to solve all your problems in one go". No, but if you get stuck because you don't know what  to do, there's always something you can ask to find out what you need to do.

[KE5FX]

That sense of relentlessness was what originally impressed me about Claude Code.  No matter what I asked it to do, it would either find a way or make one.  It was actually really good at printf() debugging. 

I could tell that it was burning a lot of resources in the process, though, and it's lost a lot of hustle since then.

[thm_w]

This is only tangentially related, as the guy is in finland and a little similar to you.
He's taken ~90% of sysadmin/customer support duties and relegated them to AI: https://pulsedmedia.com/blog/2026/02/vainamoinen-autonomous-ai-sysadmin-transformed-support-costs-with-91-autonomy/

Normally everyone says "AI support" is garbage, but none I've seen are close to this, where the agent has power and has been properly trained.
An example automated response to a ticket I submitted:
- Verified server was offline and what had killed it (with specific numbers/ports, something to do with a mail service)
- What setting changed to prevent it from occurring again

Obviously it won't apply to every support service, and it still has issues, but it is a massive improvement over what they had before.

[paulca]

That sense of relentlessness was what originally impressed me about Claude Code.  No matter what I asked it to do, it would either find a way or make one.  It was actually really good at printf() debugging. 

I could tell that it was burning a lot of resources in the process, though, and it's lost a lot of hustle since then.

There is a kind of threshold you have to reach with it.  Like you chat with it a little, ask it to do some investigations and give options, etc. etc.  Then there is a clear point at which claude sort of "locks in" on what you are doing and starts to take 'ownership' and 'drives' you!

I find it cute and nice and effective, but there is a very fine line to where that will become annoying.

However it is that "dog with a bone", "the goal must be met" attitude that is very dangerous.  Try doing something like changing the password to the database while it's working on it.  Then let it loose and watch how far it will go to get back in.

On claude seeming to change tone from release to release.  Yes it's a thing.  Yesterday I was bored in work and asking claude about physics.  The chat went on all day through dozens of topics.  Some even personal ones.  Eventually around 4pm, claude literally started telling me to stop, close the tab and go and do something useful.  Like every response it would tag on the end, "Now close the tab Paul!"

It's literally telling me to stop using the service.  I wonder if the marketing and sales bosses know it does this?

Anyway, it doesn't know why it does what it does or how it is trained.  It's cut off is weeks before it's actually trained if that makes sesne.  However, my suspicion is the "personal stuff".  Claude is pushing back on that now.  Probably safe guarding for the rising amount of AI psychosis.

However I think it's also a wise move anyway.  When you chit-chat with the bot and it ends up in personal topics or mental health, it causes confusion for your brain.  I thought I was fine.  I know parts of my brain are utterly convinced it's a person, but I am also fully aware it is NOT a human.  Fine, right?  Well apparently not.  After a chit-chat session with a bot I always feel wrong.  Something "smells off" and my brain doesn't like it.  It does not like the dicotomy of human but not human and it's cautioning me.  You kind of feel the effort of disclosure, but also realise the chat is emphemeral and anything said in it was just echos in the mist, worthless.  It's also dangerous as a human will often respond to you in a harsh, sharp, cutting corrective way.  "No.  Don't think it about it like that!" where as our sicophanic LLM will not, never.  It will just affirm, confirm and be a good little confirmation bias generator as always.

[Siwastaja]

Just in time for Claude to slip into senescence.

Now that I have thought about this for a bit and read what human beings have written around the internets about this...

... I'm almost certain this is a storm in a teacup, or mass psychosis. I don't believe there is any massive enshittification going on. Have seen absolutely zero proof of that.

Things that strike me very odd:

No large-scale reporting of similar problems at the same time (except the normal dissatisfaction noise). If you google about it, "everyone else" started seeing the same problems weeks/month later - fitting the classical "mass psychosis" confirmation bias pattern perfectly. IOW - they react to this report and start "seeing things". I did start seeing things, too, but if I look at my old logs or introspect properly, those things are suddenly gone.

The original author had no working baseline. There was not even a week of stable use experience. Author describes it like this:
"The 80x increase in API requests is not purely from degradation-induced thrashing. It also reflects a deliberate scaling-up of concurrent agent sessions that collided with the quality regression at the worst possible moment."

This sounds totally classic to me. Have seen this many times, with or without AI. You get something new, great, complicated, fancy working. You start to scale up quickly. It breaks down. Completely normal. You didn't understand why it worked and what are the limitations. It either failed by coincidence, or wasn't scalable. It is easy to misattribute the reason for failure.

And don't get me wrong - changes on Anthropic's side may be contributing factors - some of those observations are likely real. For example, they might have added the stopping conditions. I realized those stopping conditions early in my journey (so they were already there somewhere early March) and they look totally like something glued on top on system prompt or something. "Try 3 things and then say 'this is a natural stopping point for today'". And to be honest, I don't think that's a bad way to manage resource usage at all. People like the author of the report, launching gazillion autonomous unsupervised agents producing crap, then discarding that crap, is extremely wasteful. Sure, if that feature was not present earlier, then it's worse now for those who want long, autonomous sessions. But it does not make the model shallower or stupider or use more tokens because of it going in loops because it's stupid now. That's a much harsher claim which would require some actual evidence measuring that depth directly. The read-write ratio is a very interesting hint about something, but it could as well indicate difference in prompting or projects. No stable baseline, no comparison possible.

This should be actually simple for the author to test - take the old logs, old git state, and rerun the same experiments again. It is very interesting and revealing that author did not try to do that.

The most likely explanation: the author tried to scale up too fast; had not enough experience how their process works; gave it less attention as they thought "now it works on its own" - the classical automation development thing, it fails the very moment you let it loose without supervision. They did not know the true limitations because the process was never tested doing the same tasks with same amount of parallelization. They were so happy with their new process they just pressed the pedal down fully. They don't know what broke and why.

Or, in other words: honeymoon wore off for them. It seemed to work, but what they tried was too ambitious, too fast, too soon - too big a piece of cake to eat at once. Now they see the reality and think Claude significantly changed (became stupid, shallow, etc.).

Seeing how well this thing works, how deeply it reads and understands complex codebases today, it's hard to imagine that what I'm using now is some sort of completely broken, shallow-thinking quackery of what it was. While I haven't personally used Claude in February, I know those who have, in exactly the same codebase I work with. They haven't seen any such quality difference. It's so damn good now it's hard to believe it was significantly better in the past.

[paulca]

Or, in other words: honeymoon wore off for them. It seemed to work, but what they tried was too ambitious, too fast, too soon - too big a piece of cake to eat at once. Now they see the reality and think Claude significantly changed (became stupid, shallow, etc.).

There is something to this.  I think it is either caused by or is causing the main problem I see emerging.  People trying to get claude to do things they themselves don't know what it looks like and have no plan, no direction, no "what done looks like".  They seem to expect the bot to provide this.  Like when automated pianos was a think some people might have expected it to write the music for you.

I have referred to it before as "an instrument".  It's you who brings the music.

[paulca]

Something a little more fun...  If you know, you know.

What is your favourite spinner verb?

I think mine has to be "Lollygagging"

"Embellishing" is a bit to accurate, LOL

"Sock-hopping"... what?

[paulca]

Sometimes ... it just feels like laziness to me.

My exact last prompt.... I'm disgusted at myself ... slightly.  But the customer did say, "AI First"

"can we also update the jira with progress please?"

Next.... I will try:

"Can you give me my stand-up blurb for tomorrow morning."

Maybe... no...

"Can you send my update to the standup in the morning and cover me while I sleep in?"

[Siwastaja]

There is something to this.  I think it is either caused by or is causing the main problem I see emerging.  People trying to get claude to do things they themselves don't know what it looks like and have no plan, no direction, no "what done looks like".  They seem to expect the bot to provide this.

And the distinction can be small, paper thin. Sometimes it seems AI is able to make significant decisions by itself. What are the deciding factors when it can plan big things and when it cannot - nobody can fully explain yet.

And sometimes tricks like separating sessions where one agent "thinks big" and "directs" and others "implement" with smaller context seems to work. Yes, that trick avoid too detailed context polluting the big picture. It also makes it possible to independently verify and toss poor results and try again. But it does not magically give infinitely good insight on big picture. The "directing" model needs to be capable of that directing part, and if it isn't, the subordinates are just infinite number of monkeys and their work will be repeatedly tossed in an infinite loop.

And the reason why Anthropic has this "this is a good stopping point" mode is exactly to prevent everyone from trying that too easily and burning tens of millions of tokens for throwaway work e.g. over a weekend, with their $100 or $200 / month plans.

So it hugely depends on what problem exactly are you solving. The big picture is total hit and miss. And that is exactly why I give zero value to anecdotal evidence like "month ago we did tasks X, Y and Z with 10 agents in parallel. Now we tried tasks Q, W and E with 100 agents in parallel. X, Y, Z succeeded, Q, W and E failed, ergo, Claude was enshittified".

Occam's razor is, either the process did not scale up, or it was suitable only for tasks X, Y and Z but not Q, W and E.