| Stack Overflow | https://stackoverflow.com/users/57695/peter-lawrey |
| Blog | http://blog.vanillajava.blog/ |
Optimising your memory allocations in Java could make far more difference than your choice of Garbage Collector, and may even change which garbage collector is best. Chronicle FIX already persists each message; what if we use SLF4J/logback to write another copy?
https://blog.vanillajava.blog/2026/06/why-you-should-tun-code-before-your.html
I am all in on AI writing 20K LOC a day, but it is disposable, bug-filled crap. I use it for mock systems, quick prototypes, and sample use cases. It works well enough, but it's not worth reading, usually not worth adding as test cases, and certainly not worth using in production. If it's not worth reviewing, I wouldn't even add it as a test case. The value of this is what you learn from the process, and you can't say what you learned from doing this *the next day*; you probably learned nothing. To give you an idea, I use this prompt extensively: Critically review recent changes and look for 200+ findings to fix or improve the code and address them all. For a large number of lines, I will use, say, four agents, running concurrently and even with them finding 200+ each, there is very little overlap. I repeat this for each agent until that agent doesn't seem to be improving much; this is typically 2 to 5 iterations. For 10K LOC, I target around 10 repeats of this, or >> 2K findings that are trivial enough for an AI to easily find in bulk. That gives you some idea of the quality of this code. At least 20% of lines need a trivial fix, and about another 20% of lines don't even have words in them. Also, these days, if tests and docs aren't >70% of the words/lines added, you are probably doing something wrong. For me, the release code changes are still a small part of the work I do, and I still prefer to write that part manually, or feel that is what I would have written. Once you have a working example, extensive tests, and decent docs, writing it yourself from scratch is pretty easy. https://lnkd.in/eXPcdBzr
The problem isn't technical, using AI inefficiently is expensive. My team uses Claude and Codex nearly every day, I have generated ~1M LOC this year. Yet AI is ~1% of our cost, and I don't think spending much more would help. Though it probably has doubled in the last six months.
The biggest benefit of AI is that it serves as a rapid-learning tool to broaden your knowledge. It can help close gaps in your knowledge up to average levels with relatively little effort and, in doing so, give you a broader foundation. A quote from the video that really resonated with me is at 13:46. "This behaviour shows up in people who consistently get off performance plateaus. They are, whether implicitly or explicitly, in this constant cycle of; - What am I trying to do? - Here's an experiment. - I'm going to try to work on that. - Here's the way that I'm going to evaluate that experiment. - And then they use that to move to the next experiment. " This is exactly what AI is best for: rapid, *disposable* experiments to broaden your knowledge. As I have said before, >90% of software development is understanding the problem and exploring possible solutions. AI used correctly accelerates that part of the process, and writing the code used in production is better done yourself with AI assistance. Many people are making the mistake of accelerating execution and the cost of understanding. https://lnkd.in/ex25SvkP
TL;DR I don't just expect AI to fail regularly; if they don't, I make the problem harder. These days, software development is more about problem framing and intent definition, as humans still need to decide which problems are worth solving, what “good” means, which constraints matter, and which trade-offs are acceptable. However, I don't trust guardrails that let AI check itself. Instead, much of my focus is on creating linters that are tested and validated themselves and provide the guardrails; otherwise, the rules you specify in markdown files are far too easy to ignore or game. Put another way, if an AI reliably follows your instructions, you are probably not pushing it to its limit and seeing what it really can do. These are the sort of tasks that will be fully automated in the next year or so. What I look for are tasks or problems with a 20%-80% failure rate that require many checks to provide any confidence in the result. These are the sort of tasks where a human will still be needed for the foreseeable future. | 44 comments on LinkedIn
TLDR: The widespread use of AI has led to an increase in expectations for best-of-breed solutions well above the productivity gain, meaning major tasks can take much longer. I still find that AI isn't making tasks quicker. While it might be quicker to do the same thing as we did in 2022, expectations have shifted so much that requirements are much higher. What would have been an acceptable trade-off a few years ago looks like technical debt today, as AI can effectively address concerns that would have been parked to a later phase (if ever). The task: around once a year, we roll all the versions of our software, and all the breaking/significant changes are deferred for this roll to keep the release stable for a version. In the past, this has typically taken around a month and involved about 1K changes to our code base. However, the current roll cycle involves using AI to address issues that now look like tech debt. In particular, adding ~250 javadoc, checkstyle, spotbugs, PMD, and CPD rules (~15K changes), migrating to JUnit 5 (~10K changes) and 24 custom rules (~25K changes). In terms of time, what was a month's task is likely to take around 2.5 months, due to much higher expectations for what is needed. Almost 20K changes per month, a 20x increase in volume, but the overall task is taking significantly longer. With AI, if the goals were unchanged, it would be faster. However, our aim is be best of breed, and that has significantly raised requirements, resulting in more work for a major task.
