Rails World: What Did our Software Delivery Manager get out of it?

This year was special because a lot of our team was able to come together and attend the conference in person – many of us meeting for the first time in person.

But as a Software Delivery Manager, what did I get out of this conference? Do I know enough about Rails to even understand what's going on? (spoiler: sometimes!).

Excitement about AI meets caution

The general sentiment I picked up throughout the conference was: we're all using AI now in our daily work lives, our projects, our experiments. We're all trying to learn about it as fast as possible and adapt to how others are saying they use it… But are we all doing it right?

Many people said they were excited to learn about the different ways people were using Claude Code, Codex, or whatever, to expand their engineering toolset and make their lives as developers easier. But more often than not, people didn't know how to do it "right." It's still the Wild West. So conversations often started with things like Oh yeah, we've been using Claude Code to do like 95% of our tickets and PRs now. But then devolved a bit into some version of but I'm still not sure it's quality work.

And, whatever you may think about engineering in the new world, that's fair. A lot of people have "solutions" right now that are a little bit of a smokescreen. One talk, Shipping is your heartbeat: Rails in the agentic era by Ryan Sherlock, addressed this sentiment pretty directly. A lot of good trial and error! Not always the best results, but sometimes! Some regressions. Some success. What I liked most about this talk, and what I directed people to when this topic came up, was how Ryan was transparent about the areas they just hadn't figured out yet. That stood out in most of the AI-related talks I watched at the conference.

As a companion to this, Robby Russell (have you heard of him!?) shared thoughts in Day One Keynote: The Most Valuable Engineer Isn't Shipping Features, where he encourages engineers to approach their work with wonder and a tinkerer mindset. In a world where an agent can "figure out" a lot of things easily, this might help people feel more in tune with their work.

Give agents the data they need in the place they need it

One talk I attended stuck with me for a few days. I talked to a lot of people about it at the conference, and after. Agent-Proof Your Rails App: Your Codebase Is the Prompt by Kinsey Durham Grace goes deep into Kinsey's research at GitHub, specifically about the ways that AI coding agents read and track context in applications. This is a bit over my experience level, but here is the main point I took away from this talk:

Give Agents context at a feature level

In Rails, the convention lets us create controllers and models for specific features in plain language, so it's easier to abstract logic into a manageable space for developers (I think). So we need to do this for agents as well, give them the tools they need at the feature level to rein in the broad scope of reading/research they often need to get started on a ticket.

For example: if there is a payment feature for PayPal in the application, we should be building in context files for the AI agent at that level about how to boot the feature, steps a user would take, any considerations a developer should know before starting, and how to test the edge cases in the feature.

Adding this context directly where the feature code lives helps the agent stay within that context more reliably. It doesn't need to read the entire codebase (and potentially get confused) to find where the changes need to be made. In theory, this reduces regressions, time to start, and tokens because it is a direct path.

For transparency: we haven't tried this yet. I want to. But we're still getting back up to speed post-conference, and I feel like I would need to re-watch the talk and digest it a bit before making any changes.

Tools for tools

This may be speculation, but I got the sense that many B2B groups are trying hard to build tools that solve other tools' problems right now. It's become infinitely easier to create a shell that goes on top of another tool, thanks to AI development. Think: Cloud66 in the world before. A visual shell for AWS so you don't have to worry about interacting with AWS itself.

Admittedly, this speaks to my first point here: a lot of caution around AI tooling. Companies are making visual harnesses for running multiple agents in a more visually appealing way, which – fair enough! It can be a pain to manage so much work at once. Everyone works differently.

What concerns me about this approach, though, is that companies like Anthropic are changing so rapidly that they often build native tools to solve previous tool problems themselves. But who knows. I like to try new tools, so I took a lot of cards from vendors!

Where do Project Managers fit?

While most of my conversations were about Rails and new AI tooling, I did get to ask some folks about Project Management. Here are a few compressed points of view I made notes about.

Are Scrum Masters Gone?
Someone asked me this. As a certified Scrum Master myself, I take offense to this! Not actually… Planet Argon hasn't had Scrum Masters or Scrum meetings since I've been here. Sprints are managed by Project Managers; they work closely with the team and clients, and we do our best to update transparently between the teams. It saves us from meetings and unnecessary overhead costs.

Project Managers may need to learn more technical tools
The speed is just different now, to be honest. Integrating tools to make your workflow more efficient is paramount to surviving in a fast-moving team environment. Learn about APIs, learn about Python data analytics, stay curious about new tools the teams are using. One person at the conference told me that one of their project managers came from a design and UX background, which really helped to do things like mock up examples of features on the frontend for the more backend-focused team to work on.

Prioritization and Direction is still very important
As features and fixes turn around faster, the need for clear communication paths, task prioritization, and direction becomes even more important to keep on top of as a project manager. If you're a project manager, this is probably obvious to you. So treat this as a reminder! Someone still needs to direct some traffic and use those valuable soft skills to keep the clients happy.

Here's to another year in Rails

Returning from Austin, the team was excited to share what they heard at Rails World. It was great to be out in the community, talk about what we're doing at Planet Argon, and meet some of the names we see on computer screens all day. More than ever, we're excited to be helping people give their applications a second life.