Agents Are Your Mech Suit

I want to talk a bit about agents. Agent-based workloads are going to fundamentally change how we think about software development. Let me explain why.

Hold on… Software development… What about other areas? Surely agents aren’t just a thing for software engineers?

You’re right, but because I work in software, the opinion I present below is exclusively related to work in the tech space. Agents can be helpful in other domains too, but I will let more qualified people speak on those.

Now, when I say “agents will change our work,” I am not talking about some hyped-up version of “Ehrmagerd, agents are going to take our jobs and we’ll have to sell our MacBooks!” I am talking about an actual augmentation of everyone that works in tech in any capacity. When it comes to AI, and especially when it comes to software work, I see it as a tool that helps empower others. That’s right, took that right out of a marketing cliche booklet. But really, AI tools designed with developers at the center will help create more software and bring more ideas to life - faster.

The choice of words to describe this is very much intentional - I see emerging agent-based patterns mimicking what Rob Walling described in a recent episode of “Startups For The Rest Of Us,” a “mech suit.”

A mech suit doesn’t replace its owner. And it doesn’t really mean much on its own - it’s just a pile of metal. It needs someone to control it, but it can also do a lot of things at once that its owner wouldn’t be able to keep up with without one. That probably is the best analogy on where I think we’re headed with agents.

Everyone can be a 10X developer #

Hold your replies - I am not someone who actually believes in the myth of the genius 10X programmer that singlehandedly outperforms everyone on the team.

Creating high-quality software is all about collaboration and working together with many other folks across teams and disciplines. Linux is not made by one person (not anymore, anyway). ffmpeg, a beloved media CLI tool, is built by a massive community of open-source developers that work together daily. Building something that truly matters almost never happens in isolation.

That being said, it’s hard to argue with the fact that with the emergence of AI-based developer tools has enabled individuals to accomplish more with fewer resources. And this is especially applicable to individuals that already have domain expertise.

No, seriously. The surface-level talk about vibe coding is all about trivializing the work that is needed for writing production-grade software, as if your mom-and-pop flower shop will suddenly be using AI to write their accounting systems. It’s not that. For anything serious, you won’t vibe code your way to production without a degree domain expertise. You can’t vibe-code your way to a secure authorization library (despite popular perception, Cloudflare did use human experts to verify and nudge the AI). You also won’t vibe code a medical system or an insurance claim processor without understanding how the underlying systems without other systems work.

To me, this is all about about being able to bring an idea to life in record time.

Never before were we able to get from “I have an idea for a page that…” to “Here is what it looks like, hosted in a container, talking to an API” so quickly. Again - this is not about replacing expertise. Without expertise, you’ll vibe code yourself into a security vulnerability or get blocked on an obscure code path that requires someone’s battle-hardened eyes.

But if you do have expertise, using AI will take you much, much farther.

One of the demos that we did at Build was a web-based experience called Octopets. Arguably, current AI tooling is especially good at web experiences since there is so much source material to learn from, but that’s not the point.

The entire site was produced end-to-end with AI - from idea, to using a Product Requirements Document (PRD), to then polishing it up with a modern design based on a Figma mock, and of course, building a backend that can be deployed as a containerized application.

It turned out shockingly well.

You can see the end-to-end demo in the session from Amanda Silver (Head of Product, Developer Division, Microsoft) and Mario Rodriguez (Chief Product Officer, GitHub). I recommend watching it in full.

What the session showcased is what I think future developer workflows might look like:

1. Use a tool like GitHub Spark to quickly iterate on a prototype for an idea.
2. Use AI (e.g., Copilot or Claude) to go from idea to a formal Product Requirements Document.
3. Use the PRD as a starting point for AI tools to start building out the components of the product (spec-driven development is going to be a topic for another blog post).
4. Use AI integrated in developer infrastructure (e.g., inside GitHub) to automatically sequence and tackle the implementation of some components asynchronously.
5. Synchronously, leverage client-side tooling together with a rich ecosystem of Model Context Protocol (MCP)-based extensions to build out larger pieces.
6. Use autonomous agents to monitor and auto-resolve incidents, and where a human is needed in the loop - automatically connect to developer infrastructure.
7. Use agents to turn legacy code into modern, maintainable projects instead of spaghetti monoliths.

This is the approach I used to build my “remodeled” podcast website. I also did it with the Festivus page for easier discovery of timely, relevant tech industry memes. You could confidently assert that these aren’t “serious” projects, but the tools worked reasonably well on doing exactly what I had in mind - from idea to implementation. Yes, these are isolated examples, but I have a hunch that we will see more and more of these.

Unlike some of the more doom-oriented folks, I am not subscribing to all of the worries of AI removing the need for actual skills, just like a calculator did not remove the need to understand math. As I said above, AI agents are not a replacement for expertise. Anyone who has done any serious engineering knows that building a product, and especially a product that is designed for scale, is not just about slinging code and shoving it somewhere where it can get a URL.

You need to be able to understand the source of performance bottlenecks (knowing when to use an array versus a hashtable might not be as common of a requirement, but not every project is a silly podcast website that doesn’t care about half a second of extra load time). Ideally, you also understand what patterns will and will not cause security holes leading to data exposure (don’t return the expected two-factor code in the API request to authorize a user). Or, you know, have an idea of where to look for accessibility bugs. Of course, you will still need to know how to mitigate heisenbugs. Oh, and don’t forget about resource-constrained hardware. I haven’t even touched on implementing a well thought out, good design. Deep domain expertise is and will remain valuable.

The barrier of entry, however, for someone to bring their idea from a thought to a working repository, no matter how imperfect, is getting exponentially lower. We will see more projects going live with unexpected issues. There will be security vulnerabilities discovered that were caused by non-experts pushing code to production and there will be security vulnerabilities detected by AI. But such is arc of technological progress. Remember when Visual Basic came along? What do you think people thought about it?

VB is designed for lesser-skilled developers, and it meets their needs very well. RAD is great, and the syntax is easy.

Or this masterpiece in Salon, which wasn’t talking about Visual Basic specifically, but it did allude to a lot of the concepts introduced by it:

My programming tools have become like My Computer. The same impulse that went into the Windows 95 user interface -- the desire to encapsulate complexity behind a simplified set of visual representations, the desire to make me resist opening that capsule -- is now in the tools I use to write programs for the system. What started out as the annoying, cloying face of a consumer-oriented system for a naive user has somehow found its way into C++. Dumbing-down is trickling down. Not content with infantilizing the end user, the purveyors of point-and-click seem determined to infantilize the programmer as well.

It also had an entertaining follow-up:

Every visual programming tool, every wizard, says to the programmer: No need for you to know this. What reassures the programmer -- what lulls an otherwise intelligent, knowledge-seeking individual into giving up the desire to know -- is the suggestion that the wizard is only taking care of things that are repetitive or boring.

Back in the day, the broad language and engineering skill gatekeeping also led to this wonderful (satirical, by the way) write-up, that I keep in my backpocket just for the right occasion:

Real Programmers write self-modifying code, especially if it saves them 20 nanoseconds in the middle of a tight loop.

Yet, here we are, close to three decades later, and somehow not every programmer is the equivalent of the Stone Age Sponge Bob just smashing buttons and churning crap applications (there are plenty, yes, but you get my drift) because they got access to drag-and-drop window designers.

Whether you fully embrace the change or not, AI agents for developers are here and they’re here to stay.

I am convinced that we’re right at the edge of a fairly significant paradigm shift. A whole new layer of abstraction is being created over the software engineering process, and if you’re not using it to your advantage, it’s akin to deciding to write code in Notepad instead of using a modern IDE. Sure, you can do it, but you will be easily outmaneuvered by engineers who use a more modern stack.

It’s about tackling problems #

The introduction of Visual Basic did not remove the need for C and C++ developers, just like the introduction of drills didn’t remove the need for hammers. It did, however, allow more developers of all expertise ranges to not worry about pointers. And why should they, if all they need is to build a class scheduling tool? To the surprise of no one, Visual Basic also didn’t remove the need to write Assembly code - if you are a kernel developer or writing drivers for NVIDIA cards, that knowledge is still valuable and very much applicable today. But if you’re building client apps? There’s definitely better tools!

What we, at large, need to realize is that software, just like any other product, is designed to solve a problem. As much as us engineers like to pontificate about the importance of code style, best practices, linting, and code golfing our way to the smallest version of the database connection function, - customers do not care about any of it.

I use a SaaS service to record my podcast - it’s a great tool to have in my toolbox because it saves me the hassle of having guests install a bunch of things and then manage files and find ways to send them to me. Do I care that the engineer that put it together spent a weekend ensuring that the CSS is picture-perfect, or that they migrated to Webpack from their homegrown solution? No. I care about the SaaS solution working well and being available when I need it. How the engineering team arrived at their solution is completely irrelevant to me as a paying customer as long as the criteria I care about (performant, feature-rich, cross-platform) is met. They could’ve vibe-coded it over a lunch break. I literally do not care. This is a detail that the outside world rarely cares about outside some very niche cases (I still love reading the Netflix tech blog).

So, to me - AI agents in developer workflows are excellent tools that can strap a couple of nitrous tanks to my IDE and then boost me to where I want to be in minutes instead of hours.

Save your keystrokes, one prompt at a time #

Scott Hanselman once wrote a post about saving your keystrokes. I am all about that, because the biggest and most valuable resource to me is time.

The future where I get to plug agents and let them to do work is exciting to me because the sheer amount of time savings from tasks that I had to previously do manually, in sequence, that can now be automated almost end-to-end are very much material.

Have an agent spin up a Deep Research task on a topic, while I use another agent to go and kickstart a whole new web frontend, while another is iterating on a backend MVP, while I have a bunch of others that are working through the grunt work for some podcast summarization, while yet another agent is monitoring my website and automatically scales it if things go wrong, and another that automatically creates PRs for opened bugs. How can you not get excited about this future?

Dispatching automated “code-bots” to go do things for you while you focus on other, more important (for me - creative) things - that’s quite literally the dream. We have a long way to go before this is ubiquitous and highly reliable, but as a start, I am already seeing hundreds of hours saved and I haven’t even applied the approach to most things I want to yet.

Thomas Ptacek quoted a piece in his recent write-up that I found salient:

“I’m sipping rocket fuel right now,” a friend tells me. “The folks on my team who aren’t embracing AI? It’s like they’re standing still.” He’s not bullshitting me. He doesn’t work in SFBA. He’s got no reason to lie.

Merits of sipping rocket fuel aside (don’t do it), this sentiment represents how I feel today. I consider myself to be a rational skeptic, but even I see the chasm between the things I am able to get done now compared to a year ago. The delta is getting increasingly larger by the day. And things are only speeding up from here. Yes, the baby will not weigh 7.5 trillion pounds by age 10, but even with the current capabilities the speed-up is immense.

Setting yourself apart #

All of this then begs the question - if agents and AI-based developer workflows significantly reduce the gap between idea and an actual implementation, and anyone can use them to bring their crazy project to some semblance of production (even if not quite up to the standard we might want) with minimal experience, what is the key future differentiator for a technical specialist, like an engineer, product manager, designer, or data scientist?

What’s the moat they can build to not only survive the wave of AI but also ride it to a better career?

I will assert that deep expertise will remain a key differentiator. If you are a game engine developer, I predict (hah, bold move) your understanding of trigonometry and physics as applied to 3D graphics is going to remain valuable. If you are a web developer, an in-depth understanding of the end-to-end pipeline (how browsers render pages, interpret CSS, and act on JavaScript) is going to set you apart from hundreds of thousands of vibe coders that only know how to prompt a LLM.

However, deep expertise is only a piece of the puzzle. There are a few more items that I suspect will be even more valuable if combined with knowledge:

• Being capable of iterating on ideas fast. The tools we have today already allow us to move very fast when it comes to kickstarting ideas and bringing them into decent enough shape as a foundational piece. You will need to get comfortable with very quickly moving around ideas and tweaking them with a broad variety of tools, because everyone else will be doing it too. Yes, not quite a differentiator per-se, but you must get comfortable with fast iteration on minimum viable ideas (MVIs, anyone).
• Having high agency. Cliche term, but behind it is a very good message. John Lam and I had one too many conversations on this topic and it’s burned into my mind at this point, but the idea is ridiculously simple - you have to have bias for action, curiosity, be creative, and have the willingness to push and explore. This sounds easy in theory, but in practice few people recognize when they are falling into a “low agency” trap. “It’s impossible” - sure, but have you tried a different approach? How have you iterated on the problem? Just because you have a hammer doesn’t mean that the only thing you can do with it is drive nails into a wall.
• Being T-shaped. Deep in a specific domain, broad knowledge of many other domains. Basic skills will be commoditized. Being able to create MVP landing pages for startups is not going to be a lasting moat. What kind of expertise do you know have that is hard to replicate? Someone working in fiber optic networking infrastructure is going to be successful in finding the next job because their skills are so unique, but they will be even more successful if they combine that with a deep understanding of physics and terrain geography. What’s your combination of depth and breadth?
• Being able to learn quickly. I don’t see AI as something that will “dumb down” engineers the same way I don’t see IntelliSense doing the same. As you use AI and agents to do more work for you, it’s still important to build an understanding of how and why things are built the way they are. This is where the ability to absorb and synthesize information quickly will set you apart. LLM, whether standalone or integrated through some agent-based experience, do expose a myriad of indirect opinions - implementation details in the code you get, quirks in specific algorithms, or choices when it comes to APIs. Question them and build a base that can help you become well-versed in the underlying platforms and toolchains.
• Having taste. AI, no matter how advanced, is not a replacement for the ability to distinguish something that looks like hot garbage from something that is appealing for the user. I don’t want an AI-designed app UI. I want someone who is opinionated, grounded in first principles, and deeply caring about the experience to put it together (even if they use AI in the process to bring it to fruition).

At this point in time, it’s hard to predict the extent of the changes we’re going to experience. For all of the words written above, I would encourage you to take my writing with a boulder of salt and exhibit high agency (see what I did there) - think through ways in which you can leverage the tools you have and will have access to ideate, iterate, learn, and then ship, ship, and then ship again.