What Developers Actually Need to Know Right Now
For engineering teams, the most important shift is not whether AI can generate code, but how it fits into a governed delivery system. The practical question is where deterministic workflow steps end and where LLM-driven steps begin. That boundary affects traceability, rollback strategy, and how much behavior can be validated before changes reach production. In other words, agent adoption becomes an architecture decision, not just a developer preference.
Teams also need to treat agent orchestration as part of the application stack. If one agent plans, another calls tools, and a third modifies code, then the interfaces between them matter: prompts, policy files, MCP-style tool definitions, and review gates become operational dependencies. The more these components are standardized, the easier it is to preserve shared conventions across projects and reduce the risk that every team invents a different โAI workflowโ with different maintenance costs.
Code review and quality control need a new operating model. AI-generated pull requests can raise throughput while also increasing reviewer load and uncertainty. The useful distinction is not โAI codeโ versus โhuman code,โ but which changes are small, test-covered, and compartmentalized enough for lighter review, and which require full human scrutiny. That distinction should be explicit, documented, and tied to the teamโs reliability expectations.
Cost discipline matters too. Token usage is now part of engineering economics, so teams should measure the runtime and inference cost of common agent flows before scaling them broadly. The main opportunity is not just faster delivery, but a maintainable system that keeps velocity, reviewability, and spend in balance as agent use expands.
The following article includes clips from a recent Live with Tim OโReilly interview. You can watch the full version on the OโReilly Media learning platform.
Addy Osmani is one of my favorite people to talk with about the state of software engineering with AI. He spent 14 years leading Chromeโs developer experience team at Google, and recently moved to Google Cloud AI to focus on Gemini and agent development. Heโs also the author of numerous books for OโReilly, including The Effective Software Engineer (due out in March), and my cohost for OโReillyโs AI Codecon. Every time I talk with him I come away feeling like I have a better grip on whatโs real and whatโs noise. Our recent conversation on Live with Tim OโReilly was no exception.
Here are some of the things we talked about.
The hard problem is coordination, not generation
Addy pointed out that thereโs a spectrum in how people are working with AI agents right now. On one end you have solo founders running hundreds or thousands of agents, sometimes without even reviewing the code. On the other end you have enterprise teams with quality gates, reliability requirements, and long-term maintenance to think about.
Addyโs take is that for most businesses, โthe real frontier is not necessarily having hundreds of agents for a task just for its own sake. Itโs about orchestrating a modest set of agents that solve real problems while maintaining control and traceability.โ He pointed out that frameworks like Googleโs Agent Development Kit now support both deterministic workflow agents and dynamic LLM agents in the same system, so you get to choose when you need predictability and when you need flexibility.
The ecosystem is developing fast. A2A (the agent-to-agent protocol Google contributed to the Linux Foundation) handles agent-to-agent communication while MCP handles agent-to-tool calls. Together they start to look like the TCP/IP of the agent era. But Addy was clear-eyed about where things stand: โAlmost nobodyโs figured out how to make everything work together as smoothly as possible. Weโre getting as close to that as we can. And thatโs the actual hard problem here. Not generation, but coordination.โ
The โSomething Big Is Happeningโ debate
In response to one of the audience questions, we spent some time on Matt Shumerโs viral essay arguing that the current moment in AI is like just before the COVID-19 epidemic hit. Those in the know were sounding the alarm, but most people werenโt hearing it.
Addyโs take was that โit felt a little bit like somebody who hadnโt been following along, just finally getting around to trying out the latest models and tools and having an epiphany moment.โ He thinks the piece lacked grounding in data and didnโt do a great job distinguishing between what AI can do for prototypes and what it can do in production. As Addy put it, โYes, the models are getting better, the harnesses are getting better, the tools are getting better. I can do more with AI these days than I could a year ago. All of that is true. But to say that all kinds of technical work can now be done with near perfection, I wouldnโt personally agree with that statement.โ
I agree with Addy, but I also know how it feels when you see the future crashing in and no one is paying attention. At OโReilly, we started working with the web when there were only 200 websites. In 1993, we built GNN, the first web portal, and the webโs first advertising. In 1994, we did the first large-scale market research on the potential of advertising as the webโs future business model. We went around lobbying phone companies to adopt the web and (a few years later) for bookstores to pay attention to the rise of Amazon, and nobody listened. Iโm a big believer inย โsomething is happeningโ moments. But Iโm also very aware that it always takes longer than it appears.
Both things can be true. The direction and magnitude of this shift are real. The models keep getting better. The harnesses keep getting better. But we still have to figure out new kinds of businesses and new kinds of workflows. AI wonโt be a tsunami that wipes everything away overnight.
Addy and I will be cohosting the OโReilly AI Codecon: Software Craftsmanship in the Age of AI on March 26, where weโll go much deeper on orchestration, agent coordination, and the new skills developers need. Weโd love to see you there. Sign up for free here.
And if youโre interested in presenting at AI Codecon, our CFP is open through this Friday, February 20. Check out what weโre looking for and submit your proposal here.
Feeling productive vs. being productive
There was a great line from a post by Will Manidis called โTool Shaped Objectsโ that I shared during our conversation: โThe market for feeling productive is orders of magnitude larger than the market for being productive.โ The essay is about things that feel amazing to build and use but arenโt necessarily doing the work that needs to be done.
Addy picked up on this immediately. โThere is a difference between feeling busy and being productive,โ he said. โYou can have 100 agents working in the background and feel like youโre being productive. And then someone asks, What did you get built? How much money is it making you?โ
This isnโt to dismiss anyone whoโs genuinely productive running lots of agents. Some people are. But a healthy skepticism about your own productivity is worth maintaining, especially when the tools make it so easy to feel like youโre moving fast.
Planning is the new coding
Addy talked about how the balance of his time on a task has shifted significantly. โI might spend 30, 40% of the time a task takes just to actually write out what exactly is it that I want,โ he said. What are the constraints? What are the success criteria? Whatโs the architecture? What libraries and UI components should be used?
All of that work to get clarity before you start code generation leads to much-higher-quality outcomes from AI. As Addy put it, โLLMs are very good at grounding things in the lowest common denominator. If there are patterns in the training data that are popular, theyโre going to use those unless you tell them otherwise.โ If your team has established best practices, codify them in Markdown files or MCP tools so the agent can use them.
I connected the planning phase to something larger about taste. Think about Steve Jobs. He wasnโt a coder. He was a master of knowing what good looked like and driving those who worked with him to achieve it. In this new world, that skill matters enormously. Youโre going to be like Jobs telling his engineers โno, no, not thatโ and giving them a vision of whatโs beautiful and powerful. Except now some of those engineers are agents. So management skill, communication skill, and taste are becoming core technical competencies.
Code review is getting harder
One thing Addy flagged that doesnโt get enough attention: โIncreasingly teams feel like theyโre being thrashed with all of these PRs that are AI generated. People donโt necessarily understand everything thatโs in there. And you have to balance increased velocity expectations with โWhat is a quality bar?โ because someoneโs going to have to maintain this.โ
Knowing your quality bar matters. What are the cases where youโre comfortable merging an AI-generated change? Maybe itโs small and well-compartmentalized and has solid test coverage. And what are the cases where you absolutely need deep human review? Getting clear on that distinction is one of the most practical things a team can do right now.
Yes, young people should still go into software
We got a question about whether students should still pursue software engineering. Addyโs answer was emphatic: โThere has never been a better time to get into software engineering if you are someone that is comfortable with learning. You do not necessarily have the burden of decades of knowing how things have historically been built. You can approach this with a very fresh set of eyes.โ New entrants can go agent first. They can get deep into orchestration patterns and model trade-offs without having to unlearn old habits. And thatโs a real advantage when interviewing at companies that need people who already know how to work this way.
The more important point is that in the early days of a new technology, people basically try to make the old things over again. The really big opportunities come when we figure out what was previously impossible that we can now do. If AI is as powerful as it appears to be, the opportunity isnโt to make companies more efficient at the same old work. Itโs to solve entirely new problems and build entirely new kinds of products.
Iโm 71 years old and 45 years into this industry, and this is the most excited Iโve ever been. More than the early web, more than open source. The future is being reinvented, and the people who start using these tools now get to be part of inventing it.
The token cost question
Addy had a funny and honest admission: โThere were weeks when I would look at my bill for how much I was using in tokens and just be shocked. I donโt know that the productivity gains were actually worthwhile.โ
His advice: experiment. Get a sense of what your typical tasks cost with multiple agents. Extrapolate. Ask yourself whether youโd still find it valuable at that price. Some people spend hundreds or even thousands a month on tokens and feel itโs worthwhile because the alternative was hiring a contractor. Others are spending that much and mostly feeling busy. As Addy said, โDonโt feel like you have to be spending a huge amount of money to not miss out on productivity wins.โ
Iโd add that weโre in a period where these costs are massively subsidized. The model companies are covering inference costs to get you locked in. Take advantage of that while it lasts. But also recognize that a lot of efficiency work is yet to be done. Just as JavaScript frameworks replaced everyone hand-coding UIs, weโll get frameworks and tools that make agent workflows much more token-efficient than they are today.
2028 predictions are already here
One of the most striking things Addy shared was that a group in the AI coding community that he is part of had put together predictions for what software engineering would look like by 2028. โWe recently revisited that list, and I was kind of shocked to discover that almost everything on that list is already possible today,โ he said. โBut how quickly the rest of the ecosystem adopts these things is on a longer trajectory than what is possible.โ
That gap between capability and adoption is where most of the interesting work will happen over the next few years. The technology is running ahead of our ability to absorb it. Figuring out how to close that gap, in your team, your company, and your own practice, is the real job right now.
Agents writing code for agents
Near the end we answered another great audience question: Will agents eventually produce source code thatโs optimized for other agents to read, not humans? Addy said yes. There are already platform teams having conversations about whether to build for an agent-first world where human readability becomes a secondary concern.
I have a historical parallel for this. I wrote the manual for the first C compiler on the Mac, and I worked closely with the developer who was hand-tuning the compiler output at the machine code level. That was about 30 years ago. We stopped doing that. And Iโm quite confident there will be a similar moment with AI-generated code where humans mostly just let it go and trust the output. There will be special cases where people dive in for absolute performance or correctness. But theyโll be rare.
That transition wonโt happen overnight. But the direction seems pretty clear. You can help to invent the future now, or spend time later trying to catch up with those who do.
This conversation was part of my ongoing series of discussions with innovators, Live with Tim OโReilly. You can explore past episodes on the OโReilly learning platform.
Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.
