>The reason we bump this major version is that we can get rid of design decisions made in the past that currently block us and then we want to change defaults to more sensible settings that will benefit a greater audience
I don't know how to read this sentence other than "there are breaking changes we want to make"
The migration guide does say there are breaking changes, but the interpretation I have is "this won't have new features but allows us to develop new features".
I wish I were joking that I literally haven't received a delivery of four GET endpoints I wrote requirements for six months ago. The problem is that nobody seems to understand why this is an issue. We are constantly advertising to our customers that we are moving to API-based integrations and that the future of our product is being able effectively use our product without a user interface, and yet the management team is okay with four GET endpoints not being shipped in six months.
The next set of API endpoints we have in our backlog are write operations based on the Strangler Fig design pattern [1] using our existing stored procedures with a thin API wrapper around them. I can only imagine that if four GET endpoints have taken over six months to ship, that this is going to take an order of magnitude longer time, especially since our development team hasn't had to deal with things like concurrency and idempotency before.
OP said in a comment that the devs are approaching retirement and their expertise is in COBOL and other really really legacy systems. I doubt they’re inclined at all to start using LLMs, or anything that changes how they work.
I have started to wonder to what degree programming discussion online is astroturfed. The financial incentive to flood programming discussion (any discussion related to work) with pro-AI messaging, and the simultaneous ease with which AI makes it to do so, makes it hard not to ponder what amount of seemingly organic pro-AI sentiment is not.
I'm sure there is some that is indeed genuine. It could even be most. But I'd be surprised if it is all.
The comment reads like flesh-generated language to me, but I might be fooled. The breadths of pro-AI sentiment is possibly astroturphed, but there's also an argument for an enthusiastic minority of people to write a lot more comments.
As the person above said, AI has significantly increased my ability to execute on ideas. I always liked computers, always liked building things, but was never that great at coding, and was never that good at going super deep into one topic. Instead, I have broad knowledge of a lot of things like product design, requirements engineering, devops, security.
I work with a fully agentic flow, but I would argue very seriously; My job has not gotten easier, I am doing at least as much hard thinking as before. From assisted RE over design (TDD focused Spec), implementation by agents, review by agents with partial human oversight, I have a speedup of maybe 50-100%.
More importantly, I can do things I couldn't do before. And when it comes to performance and defect-density, it is comparable to very senior people I couldn't touch before. I do agree that the code doesn't look like a human would write it - too abstracted, sometimes convoluted, often way too dense. But it isn't worse code, and if you accept that no one has to read that code ever again, then it is good. Agents are able to grok it just fine.
I'm not OK with it, but I have no choice besides maybe quitting my job.
I've also tried to understand the code that AI writes, but it's often insane and untangling it would slow me down so much that it would nullify the gains in speed that AI brings.
To me, either companies realize they're spending a lot more money to ship crappier code and AI becomes a niche, or we'll just stop looking at code. I don't think there's any other option because I don't see AI getting better at it. It seems to actually be getting worse and more annoying to use.
There is an in between here that developers seem to keep forgetting: Design the software architecture yourself — do some whiteboarding, figure out your abstractions and your UML, then write that in your prompt for the LLM to implement through a plan.
Velocity stays high. Cognitive overhead remains low. You know enough of your architecture from the “unit” level to see how the pieces work meaning you can still work fast and understand it without hating the quality it produces. This has worked wonders for my company; I’ve managed to personally write tools that are barely distinguishable from what I’d write by hand, and I’m confident enough to discuss its architecture from top to bottom. If the LLM ever produces a unit with a poor implementation, I just rewrite that unit.
Basically: do the “engineering” part of software engineering instead of throwing LLMs at the wall until code sticks. It doesn’t take much time to come up with a good design, compared to repeatedly iterating on a bad design and maintaining it for years to come.
LLMs suck at design, and that’s why they lead to this bad code. But if a human spends an hour to build nice SOLID abstractions, and tell the LLM each responsibility — they are pretty good at using and wiring these parts together.
My company recently had to cut back our usage to effectively nothing and I get to code by hand again. I'm going to appreciate it while I can. The AI just wasn't providing enough value for us
> I've also tried to understand the code that AI writes, but it's often insane and untangling it would slow me down
I hear that a lot, but it is very different from my experience using Claude Code every day. The code it generates is pretty much what I would have written myself. My colleagues have always said my code is easy to read and understand, so hopefully it is not just because my code is insane too :)
Ryan Air just introduced the super-annoying requirements of needing the app to download your boarding pass (which of course they could just provide from the website).
I think they do it to be able to send you notifications and sell you more flights, but I don't understand why they need to be so anti-user. I try to NOT fly Ryan Air unless there is no other airline available. I'd rather pay twice as much than support their poor and sometimes borderline-criminal business practices.
I have a non-negotiable rule to start responses with a TL;DR and omit any follow-ups, potential caveats, and "you should know that"s unless they can lead to destructive actions or loss of data.
I also forbid replying with anything besides "yes" or "no" to yes/no answers.
It works, Opus 5 is still super-annoying but this makes it bearable to use.
Yes, that's my preference too and nobody can convince me that an AWS setup is better unless you have millions of users.
I think that a lot of devs just think they _have_ to do it that way, or they over-optimize too early and build the ultimate system before they even know if anyone will use the app or site.
The biggest benefit to me as a developer at least in larger organizations that AWS gives is ownership of my stack and needs. I don’t need to file a purchase request for new servers to spin something up or deploy a new application. I don’t need to fight with other departments for the fixed CPU and memory capacities in our virtualization system.
But everything else would be so much simpler and better for most of the things I do if it could just be a normal box with normal software.
In theory I could build that experience with nothing but bare EC2 instances. But once you’re in AWS, they make using their managed things so tempting that convincing everyone else to not use them is an even bigger battle.
reply