The Business is Changing

11 Oct 2026 artificial-intelligence · software-engineering

Now is the time to change the way I think about software engineering. LLMs have had a big impact on my day-to-day work. I used about $150 worth of tokens in September 2026. The value that this usage gave me was well above what my employer spent. I finished coding tasks faster than before. I spent more time on planning: thinking about the problems that my department was tackling, writing down proposals to fix those, contributing to more discussions than I could have earlier. What mattered more than getting code to work, was structuring it in a way that was logical, making it easy to review, and explaining how it satisfied our goals. No one knows what the future holds. I think the next 5 years of software engineering are going to be a time of intense change. We’ll see a new set of hiring practices, many more changes in day-to-day work. There will be an increase in the social part of the work: If generating code is fast, what matters for velocity is reviews; It will be on every IC to build relationships, to make your review request more appealing than everything else. Some projects had this dynamic even before LLMs: A small clique of contributors readily reviewed each others’ changes, but rarely review a pull request created by someone outside the clique. Everyone will try to grapple with the impact of a tool that produces correct code every single time.

My day-to-day habits at work have changed considerably since March 2026. I used to spend about half of my time at work inside Emacs, a text editor, reading or writing code by hand¹. The remaining half was split somewhat evenly between communication tools (GitHub, GitLab, E-mail, Slack) and the web browser. This has remained more-or-less unchanged for the past 8 years. Early in my career, I probably spent a bit more time writing code.

Today², I spend about 25% of my time at work inside an LLM-powered agent harness such as OpenCode. The remaining 75% is evenly split between the text editor, web browser, and communication tools. This is a huge shift, effected over the period of a few months. The amount of code that I write by hand has reduced drastically.

These changes affect other areas of work as well. The way that I do code review has changed a lot. The way that I treat code has changed even more. What used to be the final product of discussion, debate, and design, is now the starting point in most projects. Anyone can build anything in any codebase in a reasonable amount of time. This is a fact. AI skeptics stories about LLMs not working well with huge codebases seems like fiction, because irrespective of the size of the codebase, the way that OpenCode navigates a codebase is very similar to how a new engineer would: Decide a single code path, start from the entry point, figure out how it is implemented, figure out why using comments or Git history, and finally, decide how to update the code.

I have used LLM powered tools against large codebases of application code (Ruby on Rails. CI configuration in YAML. Terraform. Obscure languages such as Jsonnet³). The results have been uniformly great! I have used the same model since March 2026: Claude Sonnet 4.x. I have had bad results with Claude Haiku. I’ve never gotten results with Claude Opus that were better enough to justify the higher spend.

Everyone know about the many reasons and arguments to not use AI. These have been catalogued well by AI skeptics. The reasons range from the technical, political, to the moral. Some even talk about the second-order effects of AI on the economy: “Datacenters will push water and electricity prices up”, “AI hallucinates regularly”, “LLMs can’t work because they are auto-complete on steroids”, “LLMs take open source code and give nothing back”, “LLMs break the social contract of copyright, they are not fair use”, “LLMs plagiarize content without paying anything to its creators”. In our personal lives, these are reasons not to use AI.

However, for commercial software engineering work, LLMs do the job remarkably well and not using LLMs at work is not an option anymore.

LLMs don’t magically lift the guardrails that apply to all work: LLMs generate a lot more text than required. One must carefully reduce their response to the shortest amount of text that conveys the same content. LLM responses should be closely inspected to check the assumptions that were made before writing code. The code that is produced must be closely inspected. Sometimes things are missed repeatedly: Generating code that causes unit tests to fail and not fixing the tests is a common pattern. Generating CI configuration that uses fictitious options is not uncommon. AGENTS.md is a blunt tool; it has achieved little for me because the instructions get lost in the sea of context that modern codebases contain (README, documentation, code comments, code itself)