VibeSurgeon

Well, there’s your problem.

Get yourself a nice button/endpoint you can hit to trigger CI/CD that way instead

I just want affordable heat.

The monkey’s paw just curled. You’ve been granted a heat-wave, free of charge

The inverse is true as well for Kotlin being supported on iOS.

Naturally.

You should still probably not use dangerously-skip-permissions, though.

I’ve worked at several places where I’ve been able to access production databases.

No need to be so dramatic about it, really.

Dangerously-skip-permission is carte blanche for the model to do whatever it pleases with your system. If you happen to have access to a production database on your system, then the model also has access to it, should you use that option.

I think we’re meaning the same thing.

Don’t provide bailouts for neither your manager nor your colleague. Highlight as far up the chain as you can the damage their behavior is having on the business.

Case in point: AI models could be written to be more efficient in token use

They are being written to be more efficient in inference, but the gains are being offset by trying to wring more capabilities out of the models by ballooning token use.

Which is indeed a form of Jevon’s paradox

Under semantic versioning, you should really be ashamed of bumping the major number, since this means you went and broke backwards compatibility in some way.

Clearly in reference to

@Service
public class MyPublicService {}

The same as taking over any legacy project applies, really.

Start out with some expectation management - the current state of the solution prevents progress from going fast, and your stakeholders need to understand that.

Then get some tests going, such that you can try to defend whatever value the system has, if any.

Finally, start refactoring as much as you can get the space to do. Repeat until the system reaches your desired state.

Handed to review, handed to maintain, handed to extend?

I think we all know it actually stands for One Rich Asshole Called Larry Ellison

In all honesty, the protocols and structs-thing they talk about in Swift-land is the way to go. Interfaces and data classes in JVM-land

Why even use DI if you’re not planning on faking dependencies for unit testing purposes

I managed to organically create a StrategyFactory at work once.

It was a good design, but it felt extremely wrong

For anyone who opened this link in the GitHub mobile app and got confused, make sure to read from the very beginning of the comment thread - the mobile app only shows the very last comments, which cuts out the actual interesting part.