RE: https://social.lansky.name/@hn50/116190098693366432
“Here’s an uncomfortable truth: if #AI makes every engineer even 50% more productive, the org doesn’t get 50% more output. It gets 50% more pull requests, 50% more documentation, 50% more design proposals — and someone has to review all of it.“
@banterCZ This brings me to a thought: If we look at it from the old mindset, an increase in pull requests becomes a problem because it forces us to do more reviews. Perhaps it’s time to think about it with a different mindset.
What do you think that new mindset could look like?
@banterCZ I'm not suggesting it, but it brings me to that idea. The fact that AI may flood us with many more pull requests and other review-type tasks can feel frustrating from today’s perspective, and it may even look like we’re becoming less productive.
Before sharing my own view, I was genuinely curious to hear how others think about it.
We have a new technology, and I believe that usually requires changes in how we work. That’s simply how evolution happens. There are multiple directions we could take. Right now it feels like we’re at a crossroads, and time will show which path turns out to make the most sense.
At this moment, I don’t think there’s a clearly “correct” answer. I do have some ideas and possible directions that might be worth exploring, but that’s probably a longer discussion for another time.
What I’m fairly convinced of, though, is that the old mindset probably doesn’t fit this situation anymore. We’ll likely need to find a new one.
I use claude code, Opus model with Intellij Idea MCP and Jira MCP
My task where LLM has good results (for me):
1. upgrade libraries in case the api changed
2. replacing deprecated function calls - usually in combination with open rewrite
3. code review - now I investigate using claude code skills (like the OWASP)
4. refactoring
5. web UI - usually scafolding before I ask somebody to help me :)
6. generating release notes
7. generating configuration files
I try keep the context very narrow (e.g. specify files to use in context) to avoid generating heap of code or solving something else.
4. refactoring - usually in non-trivial refactoring - it helps me understanding the code, doing partial refactoring, but still I do write some code
8. rewriting from one language to another -e.g. Gradle Groovy DSL to Gradle Kotlin DSL I get quickly working code as starting point and now I could refactor bit by bit.
I got task to convert old product from javaee to jakara last year.
First part I had to do manually as we did not use any LLM but in the second part I was able to use claude code. It was like switching to warp speed. Testing options was way quicker and throwing away all changes was much easier when I found better way.
I have tried vibe coding too
These two gradle plugins are done by Claude code I was more less navigator
https://github.com/zvrablik/forbiddenPackages
and https://github.com/zvrablik/downloadMaven2Repository/tree/development
These two plugins would never exist without LLM. I would hack it somehow to Gradle code.
drawback in such code generation is that I don't remember much of it in details. Ok for support tools but talking about generated code when something happened in production may be not fun.
Luboš Račanský
Jaroslav Holaň 🇨🇿🇪🇺🇺🇦
Zdenek Henek