In DHH’s recent Rails World keynote, he made the case that hand-writing code is over and we’ll let agents do most/all of the implementation. Developers get to become “makers” who produce more while utilizing languages/frameworks that used to require a huge time investment to learn (like Rust).

But a lot of the reactions I saw expressed frustration, anger, and even a sense of betrayal. If AI agents give us more freedom to build the things we want, why do many of us feel so negative or frustrated?

I want to share some potential explanations I observed as someone who works in an AI-first company (Shopify) and once felt lost too.

Growing by improving the way we work

In addition to building the company’s product itself, solving problems in our development process, tooling & infrastructure..etc. is also a major way we grow as engineers. As someone who works on a Ruby Developer Experience team and has contributed to many developer tools, this is even how I built my career.

“Back in the day”, when we saw a part of our development pipeline that needed improvement, we’d build solutions to address it, share them with other developers, and iterate until both we and the tools worked well enough to mitigate/solve the problem.

Doing this is not just to solve a problem. We also learn how the system behaves, make decisions about possible solutions, and work with other people on the team. And I’d argue that sometimes we gain more from this type of work because the solution is more open-ended than product work.

We gain experience and evidence that we can take on greater responsibility. This is how we find room to grow outside of the product roadmap.

Less control over the tools

But this has changed with the appearance of AI agents and how they’re built and controlled.

Consider an agent that repeatedly misses instructions in AGENTS.md or fails to load skills when working on a project.

There are many things that may contribute to this. It could be the harness we’re using, like how it builds up the context or its system prompt. It could be the model we use. Whatever it is, most of them are basically outside of our control.

This is where I see a major difference from what we had “back in the day”. There’s now a major component in our development process whose results we still need to take responsibility for, but we either don’t control how it works or have difficulty doing so.

Unequal learning opportunities

If our company only uses frontier labs’ harnesses like Claude Code/Codex via subscription, we may hit that learning wall rather soon. Yes, we can build plugins/skills/hooks/mods, but how do we measure the effectiveness of a skill? How do we know how often an instruction is followed across sessions?

If our chosen provider doesn’t give us these insights, we need to build additional tooling just to see what could be improved. That’s a risky investment from the company’s perspective as this field changes rapidly. Plus, most of us would need time and support to learn how to build eval infrastructure for this.

If our company has some form of a custom agent, like Stripe’s Kai Knowledge AI platform, and Shopify’s River, then we have more opportunities to learn how agents are built, how they work, and how to improve them. But even in this case, it still depends on our team’s roadmap, etc., as having a custom agent doesn’t mean we’re only building the agent.

A big chunk of learning opportunities now becomes harder to reach simply because of our company/team’s resources. And if we can’t build a system to improve the agent’s work, we may end up compensating with more manual intervention. Repeating the same corrections without being able to improve the process can add to the frustration.

The cost of learning outside work

Even if we’re blocked from developing our skills at work, we can still learn outside of work, right? Many developers keep learning outside of work through reading blog posts, taking a course, contributing to open source, or building side projects. Most of these options only require a computer and internet access, while the rest may have a small one-time cost or a small subscription fee.

But when we want to learn more about using AI agents, the cost can be much higher. For example, Claude’s Max plans cost US$100 or US$200 a month, depending on the tier. Another big player, Codex, is included in ChatGPT Pro, which starts at US$100 a month.

Sure, we can use cheaper models from providers like DeepSeek, or even free tools. But if those models can’t reliably handle the tasks or workflows our company or the industry expects us to handle, that limits how much those experiments can help our career growth.

The tools we use in our free time need to be close enough to what we use at work, or capable enough to help us develop the skills we need.

But now we’re expected to pay for that same level of tooling ourselves, just to keep learning outside work.

What this means for career growth

Combining the 2 main divides above, what I see is: developers can now be squeezed by 2 factors we don’t have control over:

  • How much we can learn at work now hugely depends on our company/team’s resources and the tools it chooses.
  • How much we can experiment outside work depends on our ability to afford a non-trivial monthly subscription cost.

In the past, I always thought: “As long as I keep improving my skills via my open source projects and catching up through publicly available resources and books, I should be somewhat competitive in the market”.

But now I’m no longer sure that’s enough. I already see myself having a lower career ceiling than frontier AI lab employees. And I could imagine myself feeling even more stressed if I were still at my previous companies where the opportunities/resources for AI are much more scarce.

Where this leaves me

I can see why DHH is excited about what we can build with agents. I feel the same excitement at times. But being able to build more doesn’t answer the questions I have about my career. And this change to career growth is just one of many potential frustrations that AI development brings to our industry and software developers.

I think we should have more discussions about this across the industry, in our communities, and even within our teams. Being explicit about our concerns can help us understand what we can improve ourselves, where we need support from our companies, and what we need from the people building these tools.