What Happens to Your Ruby Tools With AI?

When we talk about building with AI, most of the attention goes to what’s new. Models, agent frameworks, protocols, and tools seem to appear every week, making it easy to assume that adopting AI means introducing an entirely new technology stack.

But Rails developers already have many of the building blocks needed to create useful AI-assisted workflows. Generators, Rake tasks, command-line interfaces, schemas, tests, and APIs were designed to make software easier to work with by providing structure and predictable behavior. Those same qualities make them well suited for AI coding tools.

In this context, an AI-assisted workflow doesn’t mean building an agent into a Rails application. It can be as simple as a developer using an AI coding tool to complete a task in an existing codebase, whether that’s adding a feature, running tests, analyzing technical debt, or helping with a Rails upgrade. As these tools become capable of taking more actions on a developer’s behalf, they need reliable ways to interact with the codebase and the tooling around it.

This article explores how existing Ruby and Rails tooling can become part of AI-assisted development, and why introducing AI doesn’t require starting from scratch.

Rails Already Knows How to Do a Lot

Rails developers have relied on generators for years. Whether you need a model, migration, controller, job, or scaffold, Rails provides a standard way to create it. Generators turn structured inputs into code that follows established Rails conventions, saving developers from having to reproduce the same setup manually.

That predictability is also valuable when an AI coding tool is working on a Rails application. Suppose a developer asks an AI coding tool: “Add subscriptions to the application. A subscription belongs to a user and has a plan, status, and renewal date.”

One approach is for the AI tool to generate the model, migration, test files, and supporting code itself. But Rails already knows how to create most of that structure. Instead, the tool could inspect the application and run:

$ bin/rails generate model Subscription \
  user:references \
  plan:string \
  status:string \
  renews_at:datetime

Rails now handles the mechanical work. It names the migration, creates the model, adds the association column and index, and generates the appropriate test or spec fixture files according to the application’s configuration.

The AI tool can then inspect the generated files and focus on application-specific decisions. It might add has_many :subscriptions to User, determine whether the project uses enums or constants for statuses, add validations that match existing patterns, write tests for the subscription lifecycle, and run the test suite:

$ bin/rails db:migrate
$ bin/rails test

If a test fails, the tool has another structured interface to work with: the test command’s output. It can use that feedback to make a targeted change and run the tests again.

In other words, the AI isn’t replacing Rails conventions. It’s orchestrating them. The generator provides a predictable way to create code, the schema provides a machine-readable description of the resulting data model, and the test suite provides a feedback loop for checking the work.

AI Can Orchestrate What We Already Have

The same idea extends beyond generators. Rake tasks, CLIs, and APIs all provide defined interfaces with predictable inputs and outputs and an AI coding tool benefits from that for the same reason a developer does: a clearly defined operation it can invoke is simpler than determining every individual step on its own. In Rake Beyond Rails: A Build Tool You Know opens a new window , we explored how Rake in particular can serve as a general-purpose build and automation tool. The structure that makes those tools reliable for developers is the same structure that makes them useful for AI coding tools.

The value becomes clearer when a workflow involves several specialized tools. AI doesn’t need to replace those tools to be useful. It can invoke them, interpret their output, and connect the results to the larger task a developer is trying to accomplish.

We’ve seen this with technical debt tooling. Ruby already has mature tools for measuring code quality, security vulnerabilities, dependency freshness, complexity, and other aspects of an application’s health. In Automate Tech Debt Audits with Claude Code opens a new window , we showed how a Claude Code skill can bring together tools like Skunk opens a new window , bundler-audit opens a new window , libyear-bundler opens a new window , and RubyCritic opens a new window . Rather than recreating what those tools already do, AI can run them, bring their results together, and help developers understand what to do next.

The same principle applies to Rails upgrades. At FastRuby.io, we’ve spent years developing and documenting a methodology for upgrading Rails applications. We’ve turned parts of that methodology into Claude Code skills opens a new window so developers can bring those established practices directly into an AI-assisted workflow. The knowledge doesn’t become irrelevant once AI enters the picture. Instead, it becomes part of the system the model can use, allowing it to work within a proven process rather than inventing a new one each time.

Putting these tools to work with AI doesn’t necessarily require a new integration layer. An AI coding tool working in a development environment may already be able to run a CLI command, invoke a Rake task, read a file, or execute the test suite. In other situations, a team might expose capabilities through an API or a protocol like Model Context Protocol (MCP). Which interface makes sense depends on the capability and where the AI tool is running, but it isn’t always a new one.

Good Interfaces Matter Even More With AI

For years, developer experience has focused on making tools easy for humans to understand and use. As AI coding tools become another way of interacting with those tools, the same interface decisions take on additional importance.

Clear inputs and predictable outputs help the model understand what a tool expects and what happened after it was called. Useful error messages provide information it can use to recover from a failure. Idempotent operations reduce the risk of unintended side effects when something is retried, while permissions and well defined boundaries limit what the tool is able to do in the first place.

None of these ideas are new. A well-designed command or API has always made software easier to work with. What’s different is that the interface may now have a new kind of caller. Developers can often compensate for ambiguity with experience and context, while an AI coding tool has to work with the information the interface provides. The qualities that make an interface predictable for developers therefore make it easier for AI coding tools to use reliably as well.

That means investments teams have already made in developer tooling may become more valuable as AI becomes part of the development workflow. And improving those tools may itself be a practical way to prepare a codebase for AI-assisted development. A well-designed CLI or API isn’t suddenly outdated because AI is involved. It may provide exactly the kind of structured interface these tools need.

Conclusion

AI development moves quickly, and that can make existing tools feel outdated almost overnight. But there’s a difference between old and obsolete. Rails generators, Rake tasks, CLIs, schemas, tests, and APIs represent years of thinking about how to make software behavior predictable, repeatable, and easier to work with.

Those properties don’t become less valuable when AI enters the picture. When a process can be handled reliably by an existing tool, the model doesn’t need to recreate that process from scratch. It can use the tool and focus its capabilities on the parts of the problem that actually require interpretation or reasoning.

As teams introduce AI coding tools into their development processes, the first question doesn’t always need to be, “What new AI tool should we build?” It may be more useful to look at the systems and workflows already in place and ask, “What do we already have that AI could use?”

Need help finding practical ways to introduce AI into your Ruby or Rails development workflow? We can help. opens a new window