More and more of the people who run Gradle every day aren’t typing ./gradlew build themselves. They’re asking an agent to run a build, paste it the failure, then ask it to fix the thing that failed. The agent is now part of the build loop, whether the build tool invited it or not.
+1 A Gradle skill will be very useful, agents have a really hard time writing correct build files because so many things changed in Gradle over the last few years.
Feedback regarding your article style: It is unpleasant to read AI-generated blog posts. We interact with agents all day long, and for anything else we want to read text written by humans.
I updated the blog post today, because I agree, it got to be too “AI”.
The issue is that I write these blog posts, but then we go through many rounds of edits (which I usually do with Claude). Sometimes there are so many edits that the post loses my voice and turns into robot speech.
My experience is actually that the only thing that keeps me sane rewriting a mess of groovy files created over a six year period is that my AI companion can do the iterative testing to figure out what actually might work in groovy/gradle. It is hilarious reading claims like “obviously that, which the AI just suggested, does not work and you have to do it this completely different way instead”. But now I have the scaffolding to use buildSrc and eventually going from there to a fully reusable plugin architecture.
AI is basically googling stack overflow on steroids, it finds all the same things I would do (four out of five being obsolete and or wrong from the start) but it can go through the bad ones much faster.
Then I can learn the pattern that works and apply that in the rest of the transformation without risking AI rewriting everything just because the random function had a bad day.