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.
@banterCZ In our company, this is a big topic right now. We’re aware that we need to develop software faster, and AI helps with that. However, it also results in a huge amount of code that is almost impossible for humans to reliably review in full.
One idea we’re currently experimenting with is letting AI review very large (sometimes massive) merge requests. A human would then review the AI’s review instead.
We’re experimenting and trying things out. We don’t yet have a clear answer about what the best approach will be. One thing we do know is that this will likely require a different approach than before, a different mindset.
Luboš Račanský
Jaroslav Holaň 🇨🇿🇪🇺🇺🇦
Zdenek Henek