Meryem Arik's predictions for 2030 land at a moment when the software engineering role is already being pulled in two directions. On one side, the demand for pure coding fluency is plateauing; on the other, the need for people who can coordinate systems, budgets, and business outcomes is climbing. Her point about token spend management is the one that deserves the most attention. We have spent years optimizing for model quality and inference speed, but the economics of every prompt, every agent call, and every parallel task is becoming a first-class engineering constraint. That is not a footnote. It is a new discipline, and most teams have not built the muscle for it yet.
The practical shift here is not about replacing engineers with non-technical builders. It is about changing what "technical" means. Arik's framing of non-technical builders reshaping IT aligns with what we have seen in the Navigating AI/ML Job Requirements: A Shift in Expected Skills piece, where job postings now expect a blend of software engineering, product sense, and model literacy. The engineer who only writes code is becoming a specialist in a narrow band. The engineer who can define a problem, pick the right agent architecture, and monitor token burn is becoming the generalist who ships. That is a harder sell to a hiring manager who still posts for "AI/ML engineer" and expects a single profile. But the writing is on the wall: the role is fragmenting, and the people who adapt will not be the ones who code the fastest. They will be the ones who decide when to code, when to let an agent do it, and when to say no to an unnecessary computation.
Arik's point about agent-driven vendor decisions is where this gets uncomfortable. If software agents are the ones evaluating and purchasing infrastructure, then the buyer is no longer a human with a budget meeting. It is a system that optimizes for latency, cost, and reliability. That changes marketing, sales, and support. It also changes the regulatory conversation. We have seen the early stirrings of this in Verify Your AI's Understanding: A Simple Check for Tax Season, where verification is framed as a practical, task-specific obligation rather than a theoretical principle. If agents are making decisions, who verifies their judgment? Who audits the audit? The regulatory hurdles Arik predicts are not abstract. They are the next logical step after we let software spend money and sign contracts without direct human approval. That is not a distant problem. That is a governance gap that will surface within a few product cycles, likely in the form of a compliance requirement that most teams are not prepared for.
What we would tell a reader who asks about this is simple: start treating token spend like memory usage. Profile it, cap it, and make it visible in every code review. The engineers who thrive in 2030 will not be the ones who master the next framework. They will be the ones who can coordinate multiple agents, manage their output quality, and translate technical trade-offs into business language. The Exploring Paragraph Structure: How LLMs Navigate Token Space piece hints at how token-level thinking changes how we reason about model behavior, and that mindset extends to system design. The question is not whether you can build an agent pipeline. It is whether you can run one without burning through your budget or losing control of the outcome. That is the skill to watch.