I've written a bit about AI recently, and thought about it quite a bit more, especially with regard to coding and software engineering at large. It's really incredible, it has given engineers and maintainers the ability to compress 12 months of work into a week and a half. Yes, such large scale projects are token hogs and are expensive, but smaller projects, formerly a month of developer time, might take an afternoon in the right circumstances now. Time, perhaps, is no longer the constraining factor for any project, but the complexity it introduces into the system at large. Complexity in this context isn't referring to BigO notation, nor is it cyclomatic complexity, but rather the complexity of the interactions within the project at large; this is what should be optimized for.
Older engineers might remember the days when IDEs were simple and might not have warned you about an omitted semicolon. This is when programs (often) were simpler, and the executing the plan was the bottleneck. Agentic coding has changed this, as a simple prompt can help or entirely mitigate the pain of migrating between cloud providers, or adding redundancy to databases, or even full codebase rewrites into disperate languages. Jarred Sumner said it well, "A year of zero user-facing impact was not an option we could consider." Complexity has always been a concern to some extent -- KISS is still a prevailing motto in many industries, after all. Often, however, in software engineering we over architect and over build to compensate for what might happen, precisely because making "artisinal hand made code" can be time consuming, and therefore expensive.
Reducing complexity, however, remains an important constraint. Complexity reduces both engineer and LLM effectiveness at once. Complex systems are harder to manage, harder to debug, and harder to make meaningful features for. When we build systems as engineers, we tend to still frame them in a "how long would this take my team to build" context. The fact is, although planning remains roughly the same, the execution of a plan is now comparatively instantaneous. In contrast, the ongoing maintenance and time to deliver every new feature grows with complexity.
It also, unfortunately, is something that large coding models such as Opus 5 or Codex have not quite internalized yet. They tend to suggest overly complicated solutions for simple issues with the same fervor of the engineers whose code they were trained on; plan for the future. With the speed at which changes can be made though, I would urge engineers to plan for the near term, architect for the long term. That is, don't throw all large scale plans by the wayside, but your simple web blog can run on a single shared cpu instance without being distributed across multiple AZs.