Agents are not only a product category. They are a new form of engineering labor. With loops and routines, engineers are beginning to build agents that code for them. The next abstraction is the agentic engineer: someone who creates small, specialized agents that own a feature, workflow, or service. The future of software engineering is many micro-agents, each compounding inside a defined boundary.

The common view is that hierarchy in companies exist because information has to move. Frontline people have the facts. Executives have the strategy. Managers sit in the middle and translate. This is true, but not deep enough. Hierarchy also exists because humans cannot operate at every altitude at once. A company is both wide and deep. It has strategy, customers, people, risks, tradeoffs, implementation details. No one can hold all of that clearly all the time. AI will make information cheaper. It will summarize more, automate more and expose more context to everyone. But information is not judgment. The scarce skill is knowing which altitude matters: when to zoom in, when to zoom out, and where a decision actually belongs. AI may reduce the need for management as information routing. But it may increase the need for management as altitude control.

This is the type of personal software and personal agents we will see more and more

Coding is basically the pinnacle of what you could reasonably automate with AI, and yet we still need human engineers to oversee agents for them to be effective. The AI models are trained on an incredible amount of sophisticated code. The users are highly technical and can use the latest tools quickly. The work is “verifiable” because you can test an app. The outcomes are often removed from the quality of the code (you can have sloppy code but the app can still work). And the context for the agent is often already digitized and sitting in the codebase. That’s an incredible amount of benefits that AI coding agents get to work with. Some of those apply to knowledge work, but most don’t in areas where the work needs to be fully reviewed to be useful, or where data isn’t as abundantly digitized. This makes the job for agents in knowledge work more complicated. So if with all of that, engineers still remain in very high demand, the risks are going to be less than what’s perceived for other areas of knowledge work. Agents will let people do far more than they did before, but the people don’t go away.

If AI can automate a lot of software engineering then it should be able to automate most work people do on computers too. But the reason engineers are getting so much value from AI is not only because AI is good at code. It is also because engineers know how to work with it. Most other users don’t work like software engineers today. A finance person may understand invoices, policies, approvals, vendors, all of that. They may also be able to build a rudimentary working system around the AI. But they don’t have the right tools, know-how’s and mindset to continuously monitor, maintain and improve it. That gap is why forward-deployed engineers are becoming so important. They are basically going into finance, ops, legal, support, sales etc and building the scaffolding that makes AI useful there. Current pattern is: AI becomes more useful when someone builds the right system around it. But what if we can get this process productized? What if we give regular users the same kind of controls (albeit at much higher level) that engineers have with AI? Or even better what if AI systems are by default SELF-HEALING and SELF-IMPROVING?

If agents could somehow talk to each other, we would need way less human involvement. It is fairly easy for them to interact autonomously. But really hard to do this in a meaningful and reliable way. Making it work requires some engineering. So to remove humans from the loop, we would first need humans to build the loop first (and possibly to maintain the loop as well).

Exactly!

I have a hypothesis: Every cycle starts with some fundamental platform shift. And lot of the early innovations are driven by pure research by PhDs. Research at this stage yields quicker RoI. Then come the builders taking advantage of the underlying technology and solving more surface level problems. Startups find new ways to solve existing problems with the new platform. The demand for makers and engineers shoot up. On the other hand research slowly takes back seat as it goes back to its 10 year long RoI cycle. And at the end of the cycle you see MBAs coming in. Optimizing across product and GTM, adding revenue with hundreds of incremental improvements from thousands of experiments. Market at this stage is more matured and stable with a high demand for PMs and GTM operators who can consistently drive results. We are now at the early “second” stage of the cycle. If you’re a builder it’s your time now.

Skills > Harness > Model Software side optimization is starting to add more leverage. Cycles have always been like this.

One of the best ideas I picked up at Netflix was the full-cycle developer. A full-cycle developer owns the whole software lifecycle: design, development, testing, deployment, operations, and ongoing support. With AI, I think we’ll see more of this. Developers will own more of the cycle, sometimes starting as early as product conception and UI/UX. There will still be a spectrum. Some developers will lean more ops and systems heavy. Others will lean more product and user heavy. But the center of gravity will move toward developers who can take an idea further, faster and with more scope & ownership.

What is code? - Code is instructions for the computer. What is prompt? - Prompt is instructions for LLM. How do we write code? - Python, JS, TS etc. How do we write prompt? - Markdown!

Thin controller, fat models. Thin harness, fat skills. Don’t overbuild the runtime. Thank me later.

I’ve heard this from at least a dozen YC founders over the last few weeks: Anthropic may be winning the room with execs while losing the floor with developers. Their "coding is largely solved" line is great buyer messaging. Execs hear: engineering productivity is about to change, and Claude is the platform to bet on. But devs know their job is far from solved. They use Claude because it works. As Claude reliability slips and OpenAI closes the gap, developer trust in Anthropic is starting to feel fragile.

Simple framework for AI coding tool adoption: if your codebase has >80% test coverage and clear module boundaries, AI tools are a multiplier. If it has <40% coverage and no clear interfaces, AI tools are a debt accelerator. The tool doesn't change the trajectory; it amplifies the one you're already on. Invest in the foundation before scaling the tool.

Underrated point. We're heading toward a world where most code is ephemeral computation: generated, executed, discarded.

Okay, @gdb is team CLI all the way. @garrytan thinks MCPs suck. So we hit the streets of SF to see if the city agreed. We posed a simple question: MCP or CLI? - Basically everyone under the age of 35 said CLI - One person said MCP was as bloated as Java - & unsurprisingly, numerous people told us to touch grass Final score- MCP: 3 vs CLI: 17 SF has spoken, and @composio listened. Our universal CLI is now live! Drop your best CLI vs MCP hot take in the comments and we'll send the best ones some very sick gear 👀 Link to try our CLI in the next thread ⬇️

Invest in review tooling, not just generation tooling. Linters, type systems, snapshot tests, clear module boundaries matter more now, not less.