structural search and replace in intellij is a superpower (within a single repo).
for polyrepo setups, openrewrite is great. add in an orchestrator (simple enough to build one like sourcegraph's batch changes) and you can manage hundreds of repositories in a deterministic, testable way.
couldn't have said it better. all of the people clamoring on about eliminating the boilerplate they've been writing + enabling refactoring have had their heads in the sand for the past two decades. so yeah, i'm sure it does seem revolutionary to them!
There have been a handful of leaps - copilot was able to look at open files and stub out a new service in my custom framework, including adding tests. It’s not a multiplier but it certainly helps
most frameworks have CLIs / IDE plugins that do the same (plus models, database integration, etc.) deterministically. i've built many in house versions for internal frameworks over the years. if you were writing a ton of boilerplate prior to LLMs, that was on you
Habe they? I’ve used tools that mostly do it, but they require manually writing templates for the frameworks. In internal apps my experience has been these get left behind as the service implementations change, and it ends up with “copy your favourite service that you know works”.
> my experience has been these get left behind as the service implementations change
yeah i've definitely seen this, ultimately it comes down to your culture / ensuring time is invested in devex. an approach that helps avoid drift is generating directly from an _actual_ project instead of using something like yeoman, but that's quite involved
Sorry - I’m aware that rails/dotnet have these built into visual studio and co, but my point was about our custom internal things that are definitely not IDE integrated.
> it comes down to ensuring time is invested in devex
That’s actually my point - the orgs haven’t invested in devex buyt that didn’t matter because copilot could figure out what to do!
the best way is via CRaC (https://docs.azul.com/crac/) but only a few vendors support it and there’s a bit of process to get it setup.
in practice, for web applications exposing some sort of `WarmupTask` abstraction in your service chassis that devs can implement will get you quite far. just delay serving traffic on new deployments until all tasks complete. that way users will never hit a cold node
start time generally isn't a huge concern for web applications (outside of serverless) since you've got the existing deployment serving traffic until its ready. if you're utilizing kubernetes, the time to create the new pods, do your typical blue-green promotion w/analysis tests etc. is already a decent chunk of time regardless of the underlying application. if you get through it in 90 seconds instead of 60, does that really matter?
i’ve said this before, but the “left behind” narrative is FUD nonsense. as an llm avoider i’ve never felt further _ahead_ than now. all of my peers who never bothered to learn their tools (which gave tangible benefits) have opted into deskilling themselves further.
it’s readily apparent who has bought into the llm hype and who hasn’t
getting users to adopt a new tool with its own incantations is a tough sell. git supports specifying an external pager so folks can plug in alternatives (such as https://github.com/dandavison/delta) while still using the familiar git frontend
reply