This post was originally shared on LinkedIn. I’ve expanded it here with additional context.
2025 was the year LLMs changed software engineering for me in a concrete, measurable way. I found myself shipping code again without allocating meaningful time to it. This is what that looked like in practice.
The project
I built an internal SaaS tool to analyze the large, cryptic diagnostic logs from our Varjo Base software stack. The goal was to give customer support the ability to resolve issues faster and reduce the number of cases escalated to R&D.
Today the project is approximately 100k lines of code — roughly 50/50 between implementation and tests, with around 90% coverage — on a tech stack I had no prior experience with. I built the tool with LLMs, and I also built LLM-powered analysis into it. Within minutes of a customer sending logs, CS receives a Slack link with Opus 4.5-powered actionable diagnostics, with options to investigate further using interactive tools.
Measured impact
R&D escalations dropped 50% in H2 compared to H1. Support first-response time improved by 60%, and resolution time improved by 40%.
There are confounding variables. A significant R&D push to improve product quality ran through 2025, which likely reduced the volume and severity of some issue categories. On the other hand, resolving common failure modes in the product should have made the remaining tickets more complex on average, not less. The net direction of the effect is clear, even if the exact attribution is not.
What I observed about working this way
LLMs changed which parts of the work required my time. The activities that traditionally require long, uninterrupted focus — building a detailed mental model of the code, typing out implementations, iterating until they work — are exactly what the tools handle well. What remained for me was closer to product owner and architect work: exploring the problem space, setting objectives, and steering. That kind of work fits into limited and fragmented time slots in a way that hands-on coding does not.
Engineering discipline has compounding returns with agentic coding. High test coverage, automation, and documentation directly improve the velocity and complexity of tasks a coding agent can handle. These practices are equally valuable for human engineers, but the high baseline speed of LLM workflows makes their impact immediately visible. When tests are thorough, the agent can verify its own work. When documentation is clear, it produces better output on the first pass.
Maintaining high standards costs less than it used to. LLMs are effective at writing tests, tooling, and documentation — the work that is most often deprioritized under time pressure. When a project fully integrates LLM coding tools, the cost of maintaining high coverage and good documentation drops substantially. This improves the development experience for human engineers working on the same codebase.
Tool capability is improving at a rate that matters for adoption timing. Both the harnesses (e.g., Claude Code) and the underlying models handle notably more complex tasks today than they did a few months ago. Starting adoption now means accumulating experience and workflow adaptations while the tools continue to improve underneath. Since software engineering tasks are well-suited to reinforcement learning with verifiable rewards (RLVR), I expect the return on investment to continue increasing.