DEV Community: Kartik Koul

Kiro for Ruby: Generating Rails Controllers and Models

Kartik Koul — Mon, 06 Jul 2026 10:32:02 +0000

You want to add a new resource to your Rails app. You know the drill — rails generate, tweak the migration, add validations, write the controller actions, set up strong parameters, configure routes. It's not hard, but it's fifteen minutes of mechanical work before you get to the interesting part.

Kiro handles that scaffolding for you. But unlike a basic generator, it understands Rails conventions — RESTful routing, ActiveRecord patterns, strong parameters — and produces code that follows them idiomatically. You describe what you want in natural language, and Kiro generates the model, migration, controller, and routes that a senior Rails dev would write by hand.

In this post, we'll walk through generating a complete Article resource with Kiro — a blog post with title, body, author, publication status, and a few metadata fields. Then we'll ask Kiro to layer on validations and scopes. The goal: show how Kiro respects Rails' convention-over-configuration philosophy rather than fighting it.

The Setup

Kiro supports Ruby as one of its officially listed programming languages. It's built on VS Code, so your existing Ruby and Rails extensions, themes, and keybindings carry over. Open your Rails project in Kiro and you're ready to go.

Kiro offers two session types: Vibe sessions for conversational coding, and Spec sessions for structured development (requirements, design, then implementation tasks). For generating a straightforward resource like this, a Vibe session works well. For a more complex feature — say, a full publishing workflow with drafts, scheduling, and notifications — you'd use a Spec session to plan before implementing.

Generating the Resource

In a Vibe session, you describe what you want:

Create an Article resource for a blog application. The article should have: title (string), body (text), author_name (string), published (boolean, default false), slug (string), view_count (integer, default 0), and published_at (datetime, nullable). Generate the model, migration, controller with full RESTful actions, and routes.

Kiro reads your existing project structure — your Gemfile, existing models, route file, controller patterns — and generates code that fits. It doesn't produce code in a vacuum; it matches the conventions already in your codebase.

The Migration

Kiro generates a migration that follows Rails naming conventions — timestamped filename, create_ prefix, plural table name:

# db/migrate/20260706120000_create_articles.rb
class CreateArticles < ActiveRecord::Migration[7.1]
  def change
    create_table :articles do |t|
      t.string :title, null: false
      t.text :body, null: false
      t.string :author_name, null: false
      t.boolean :published, default: false, null: false
      t.string :slug, null: false
      t.integer :view_count, default: 0, null: false
      t.datetime :published_at

      t.timestamps
    end

    add_index :articles, :slug, unique: true
    add_index :articles, :published
    add_index :articles, :published_at
  end
end

A few things to note:

Null constraints on required fields. Rails developers know that database-level constraints complement model validations. Kiro adds null: false where it makes sense — title, body, author_name shouldn't be blank at the database level.
Defaults for boolean and integer fields. A published column without a default creates a three-state boolean (true, false, nil), which causes headaches with ActiveRecord's where(published: false) queries. Setting default: false avoids that.
Indexes on query-heavy columns. The slug gets a unique index (since you'll look up articles by slug). published and published_at get indexes because you'll filter and sort on them.
published_at is nullable. A draft has no publication date. Kiro infers this from the presence of the published boolean — if there's a separate "is published?" flag, the timestamp should be optional.

This is the kind of migration a developer with a few years of Rails experience would write. Not the bare minimum, but not over-engineered either.

The Model

# app/models/article.rb
class Article < ApplicationRecord
  # Validations
  validates :title, presence: true, length: { maximum: 255 }
  validates :body, presence: true
  validates :author_name, presence: true, length: { maximum: 100 }
  validates :slug, presence: true, uniqueness: true, format: { with: /\A[a-z0-9\-]+\z/ }
  validates :view_count, numericality: { only_integer: true, greater_than_or_equal_to: 0 }

  # Callbacks
  before_validation :generate_slug, on: :create

  private

  def generate_slug
    self.slug = title.parameterize if title.present? && slug.blank?
  end
end

This model demonstrates several ActiveRecord conventions:

Validations mirror the database constraints. The presence: true validations on title, body, and author_name match the null: false in the migration. Belt and suspenders — the database constraint catches anything that slips past the model layer.

Length limits are explicit. Without length: { maximum: 255 }, a user could submit a 10,000-character title. The string column type in most databases truncates at 255 characters anyway, so the validation makes the limit visible in Ruby.

The slug format uses a regex. The /\A[a-z0-9\-]+\z/ pattern ensures slugs are URL-safe: lowercase letters, numbers, and hyphens only. \A and \z anchor to the actual string boundaries (not line boundaries like ^ and $).

The callback generates the slug from the title. String#parameterize is a Rails method that converts "My First Blog Post" into "my-first-blog-post". The callback only fires on create, and only if slug is blank — so you can still set a custom slug if you want.

The Controller

# app/controllers/articles_controller.rb
class ArticlesController < ApplicationController
  before_action :set_article, only: %i[show edit update destroy]

  def index
    @articles = Article.all.order(created_at: :desc)
  end

  def show
  end

  def new
    @article = Article.new
  end

  def create
    @article = Article.new(article_params)

    if @article.save
      redirect_to @article, notice: "Article was successfully created."
    else
      render :new, status: :unprocessable_entity
    end
  end

  def edit
  end

  def update
    if @article.update(article_params)
      redirect_to @article, notice: "Article was successfully updated."
    else
      render :edit, status: :unprocessable_entity
    end
  end

  def destroy
    @article.destroy
    redirect_to articles_url, notice: "Article was successfully destroyed."
  end

  private

  def set_article
    @article = Article.find(params[:id])
  end

  def article_params
    params.require(:article).permit(:title, :body, :author_name, :slug, :published, :published_at)
  end
end

Let's break down what Rails conventions are at work here:

RESTful Routing

The controller has exactly seven actions: index, show, new, create, edit, update, destroy. These map to the standard HTTP verbs and URL patterns that resources :articles generates in Rails:

Action	HTTP Verb	Path	Purpose
index	GET	/articles	List all articles
show	GET	/articles/:id	Show one article
new	GET	/articles/new	Render create form
create	POST	/articles	Save new article
edit	GET	/articles/:id/edit	Render edit form
update	PATCH/PUT	/articles/:id	Update article
destroy	DELETE	/articles/:id	Delete article

No custom actions, no non-RESTful routes. This is Rails' convention-over-configuration in its purest form.

Strong Parameters

The article_params method uses params.require(:article).permit(...) to whitelist exactly which attributes can be mass-assigned. This is Rails' defense against mass-assignment vulnerabilities. Notice that view_count is deliberately excluded — it shouldn't be user-settable through a form submission. Only title, body, author_name, slug, published, and published_at are permitted.

before_action and DRY

The set_article callback runs before show, edit, update, and destroy — the four actions that operate on an existing record. This avoids repeating @article = Article.find(params[:id]) in each action.

Status Codes on Render

The render :new, status: :unprocessable_entity on validation failure returns HTTP 422. This is important for Turbo (Hotwire) in Rails 7+ — Turbo expects a 422 status to know that it should replace the form with the re-rendered version showing validation errors.

The Routes

# config/routes.rb (addition)
resources :articles

One line. That's it. resources :articles generates all seven RESTful routes mapping to the seven controller actions. This is the convention-over-configuration payoff — because the controller follows the naming convention (ArticlesController with standard action names), and the model follows its convention (Article mapping to the articles table), one line of routing config wires everything together.

Adding Validations

Now let's ask Kiro to add more business logic. In the same Vibe session:

Add a validation that ensures published_at is set when published is true. Also add a validation that the title is unique within the scope of the author_name.

Kiro updates the model:

# app/models/article.rb
class Article < ApplicationRecord
  # Validations
  validates :title, presence: true, length: { maximum: 255 }
  validates :title, uniqueness: { scope: :author_name,
                                   message: "has already been used by this author" }
  validates :body, presence: true
  validates :author_name, presence: true, length: { maximum: 100 }
  validates :slug, presence: true, uniqueness: true, format: { with: /\A[a-z0-9\-]+\z/ }
  validates :view_count, numericality: { only_integer: true, greater_than_or_equal_to: 0 }
  validate :published_at_required_when_published

  # Callbacks
  before_validation :generate_slug, on: :create

  private

  def generate_slug
    self.slug = title.parameterize if title.present? && slug.blank?
  end

  def published_at_required_when_published
    if published? && published_at.blank?
      errors.add(:published_at, "must be set when article is published")
    end
  end
end

Two things to highlight:

Scoped uniqueness. uniqueness: { scope: :author_name } means two different authors can both have an article titled "Getting Started," but the same author can't. The scope creates a compound uniqueness check.

Custom validation method. The published_at_required_when_published method uses validate (no s) instead of validates — that's the Rails API for custom validation logic. It calls errors.add to attach an error message to a specific field. The published? method is automatically generated by ActiveRecord for boolean columns.

Adding Scopes

Next request:

Add scopes to the Article model: published (where published is true, ordered by published_at descending), drafts (where published is false), and by_author(author_name) that filters by author.

Kiro adds the scopes:

# app/models/article.rb
class Article < ApplicationRecord
  # Scopes
  scope :published, -> { where(published: true).order(published_at: :desc) }
  scope :drafts, -> { where(published: false) }
  scope :by_author, ->(name) { where(author_name: name) }

  # Validations
  validates :title, presence: true, length: { maximum: 255 }
  validates :title, uniqueness: { scope: :author_name,
                                   message: "has already been used by this author" }
  validates :body, presence: true
  validates :author_name, presence: true, length: { maximum: 100 }
  validates :slug, presence: true, uniqueness: true, format: { with: /\A[a-z0-9\-]+\z/ }
  validates :view_count, numericality: { only_integer: true, greater_than_or_equal_to: 0 }
  validate :published_at_required_when_published

  # Callbacks
  before_validation :generate_slug, on: :create

  private

  def generate_slug
    self.slug = title.parameterize if title.present? && slug.blank?
  end

  def published_at_required_when_published
    if published? && published_at.blank?
      errors.add(:published_at, "must be set when article is published")
    end
  end
end

Scopes in Rails are class-level methods that return ActiveRecord::Relation objects. Because they return relations, they're chainable:

# Find published articles by a specific author
Article.published.by_author("Jane Smith")

# Find draft articles, most recent first
Article.drafts.order(created_at: :desc)

# Count published articles
Article.published.count

Kiro uses the lambda syntax (-> { ... }) which is standard Rails practice for scopes. The by_author scope takes an argument, so its lambda accepts a parameter. All three scopes produce SQL that hits the indexes we defined in the migration (published and published_at).

What Kiro Understands About Rails Conventions

Through this example, Kiro demonstrated awareness of several Rails conventions:

Naming conventions. Model name Article (singular, CamelCase) maps to table articles (plural, snake_case), controller ArticlesController (plural), and route resources :articles. Kiro doesn't need you to specify these mappings — it infers them.

File placement. Models go in app/models/, controllers in app/controllers/, migrations in db/migrate/. The migration filename includes a timestamp. These are non-negotiable in Rails, and Kiro follows them.

RESTful design. Seven standard actions, no custom routes for basic CRUD. If you need non-RESTful behavior, you'd ask for it — but the default is the conventional seven.

Strong parameters. Whitelisting at the controller level, excluding fields that shouldn't be mass-assigned (view_count, id, timestamps).

Database-level safety. Null constraints, defaults, and indexes in the migration complement the model validations. Kiro treats the database schema as a contract, not just a storage mechanism.

Validation API. Using validates for declarative validations, validate for custom methods, uniqueness: { scope: ... } for compound uniqueness, and format: { with: ... } for regex patterns.

Using Steering for Team Conventions

If your team has specific Rails conventions — say you always use UUIDs as primary keys, or you prefer frozen_string_literal comments at the top of every file, or you use pundit for authorization — you can codify those in a Kiro steering file.

Create a file at .kiro/steering/rails-conventions.md:

# Rails Conventions

- Use UUID primary keys for all new models (`id: :uuid`)
- Add `# frozen_string_literal: true` to the top of every Ruby file
- Controllers that require authentication should include `before_action :authenticate_user!`
- Use `pundit` for authorization: include `authorize @resource` in show, edit, update, destroy
- Prefer `find_by!` over `find` when looking up by slug
- Always add database indexes for foreign keys and columns used in `where` clauses

With this steering file in place, Kiro will follow these conventions in every session without you repeating them. The next time you ask it to generate a resource, it'll use UUIDs, add the frozen string literal pragma, and include Pundit authorization checks.

Using Hooks for Automatic Quality Checks

Kiro's hooks let you automate checks that run when specific events occur. For a Rails project, you might set up a hook that runs RuboCop after any file save in app/:

{
  "version": "v1",
  "hooks": [{
    "name": "RuboCop on Save",
    "trigger": "PostFileSave",
    "matcher": "app/.*\\.rb$",
    "action": { "type": "command", "command": "bundle exec rubocop --format simple" }
  }]
}

Or a hook that reminds the agent to add model specs when creating a new model:

{
  "version": "v1",
  "hooks": [{
    "name": "Remind model specs",
    "trigger": "PostFileCreate",
    "matcher": "app/models/.*\\.rb$",
    "action": { "type": "agent", "prompt": "A new model was created. Ensure a corresponding RSpec model spec exists in spec/models/ with tests for validations and scopes." }
  }]
}

These hooks act like a team lead reviewing your work in real-time — catching things that slip through when you're focused on the feature logic.

When to Use Spec Mode

For this blog post example, a Vibe session was plenty. But for larger features — think a full commenting system with nested replies, moderation, and notifications — Kiro's Spec workflow is more appropriate. It would:

Generate requirements — Define what the commenting system should do (EARS notation): "When a user submits a comment, the system shall associate it with the parent article and notify the article author."
Produce a design — Map out the Comment model, its associations (belongs_to :article, belongs_to :user, self-referential has_many :replies), the controller actions, and the notification mechanism.
Break into tasks — Create ordered implementation steps: migration first, then model with associations, then controller, then notification job, then views.

Each task is implemented and verified before moving to the next. This prevents the "generate everything at once and debug for an hour" problem that happens with complex features.

Key Takeaways

Kiro generates idiomatic Rails code. It follows naming conventions, file placement, RESTful design, and the ActiveRecord API without being told to.
It understands the relationship between layers. Database constraints complement model validations. Indexes match query patterns. Strong parameters exclude sensitive fields.
Iterative refinement works naturally. Generate the base resource, then ask for validations, scopes, callbacks, or associations. Each addition builds on what's already there.
Steering files codify team standards. Your UUID preference, your authorization library, your testing conventions — write them once and Kiro follows them in every session.
Hooks automate quality gates. Run RuboCop on save, prompt for specs on new models, lint migrations before committing. The tooling works with your existing Ruby ecosystem.
Convention over configuration cuts both ways. Rails gives you conventions. Kiro respects them. The result is less time configuring and more time building the parts of your application that are actually unique.

Rails developers already benefit from a framework that makes decisions for them. Kiro extends that philosophy into the development workflow itself — you describe what you need, and it generates code that follows the conventions you'd follow by hand, just faster.

Why Python 3.14 Is Worth the Upgrade (and How AWS Transform Custom Does the Heavy Lifting)

Kartik Koul — Fri, 05 Jun 2026 15:52:38 +0000

Python 3.14 landed on October 7, 2025, and it's the rare release that's both a quiet quality-of-life upgrade and a genuine peek at where the language is heading. The catch, as always, is the upgrade itself. Bumping one script is easy. Bumping forty repositories that nobody has touched since a developer who left two years ago wrote them? That's the part people quietly avoid until a runtime deprecation notice forces their hand.

This post does two things. First, it walks through a few Python 3.14 benefits that actually justify the move. Second, it shows how AWS Transform custom (ATX) can carry the tedious parts of the upgrade so you can do it early instead of in a panic. There's a bit of humor along the way, because version upgrades are dry enough without it.

A quick honesty note up front: everything here is checked against the official AWS Transform custom documentation and the Python 3.14 release notes. Where the docs and the marketing dream diverge, I'll tell you. That happens once, and it's important, so stick around for it.

First, a Genuinely Silly Detail

Before the serious benefits, the Python core team hid a tiny joke in 3.14. When you create a virtual environment on Unix, you get a bonus alias: 𝜋thon. Yes, the actual Greek letter. It's a one-release-only tribute to π, whose rounded value 3.14 we all memorized in school and promptly forgot everything after.

(venv) $ 𝜋thon
Python 3.14.0 (main, Oct  7 2025, 17:32:06) [GCC 14.2.0] on linux
>>>

It does nothing useful. It is exclusive to 3.14. It is the most on-brand thing a group of mathematically-minded engineers has ever shipped. Moving on.

The Benefits Worth Upgrading For

A REPL That Finally Feels Modern

Python 3.13 adopted a new REPL based on PyREPL. Python 3.14 builds on it with real-time syntax highlighting and autocompletion for import statements. Type import dat, hit Tab, and it'll narrow to dataclasses and datetime instead of leaving you to remember the exact module name. The color even reaches standard-library tools: argparse help, the calendar module, json pretty-printing, and unittest failure output all gained color.

It won't change how your code runs, but it makes the interactive shell feel like a tool from this decade rather than a relic you tolerate.

Error Messages That Stop Playing Hard to Get

Python has spent several releases making error messages friendlier, and 3.14 continues the streak. A typo in a keyword now gets a suggestion instead of a shrug:

>>> forr i in range(5):
  File "<python-input-0>", line 1
    forr i in range(5):
    ^^^^
SyntaxError: invalid syntax. Did you mean 'for'?

Compare that to 3.13, which pointed at the variable i and said "invalid syntax" like an unhelpful colleague who's technically correct and zero help. The 3.14 interpreter also explains unterminated strings, incompatible string prefixes, and elif blocks that wandered in after an else. Beginners benefit most, but so does anyone debugging at 5pm on a Friday.

Template Strings (T-Strings)

This is the headline syntax addition. T-strings look almost exactly like f-strings but use a t prefix, and instead of immediately producing a string, they evaluate to a Template object you can inspect and process before anything is rendered.

>>> from string.templatelib import Template
>>> def find_users_query(name: str) -> Template:
...     return t"SELECT * FROM users WHERE name = '{name}'"

The point is safety. Because the values are intercepted before they're merged into the final string, you get a real opportunity to sanitize or parameterize them — the kind of thing that turns an SQL injection into a harmless quoted literal. One quirky catch worth knowing: Python now ships two unrelated classes both named Template (the old string.Template from Python 2.4 and the new string.templatelib.Template), so naming a variable template and importing the wrong one is a fresh way to confuse yourself. Also, as of 3.14 you have to write your own template processor — the standard library defines the syntax but doesn't yet include consumers. Bring your own logic for now.

Type Hints That Stop Tripping Over Forward References

Python 3.14 adopts PEP 649: deferred evaluation of annotations. The classic problem — a class that references another class defined further down the file, raising NameError — just goes away. Annotations are now evaluated lazily, only when something actually asks for them, and then cached.

@dataclass
class LinkedList:
    head: Node          # No NameError, even though Node is defined below

@dataclass
class Node:
    value: Any
    next: Optional[Node] = None

No more wrapping types in string quotes to dodge the import order. Faster startup, fewer circular-import headaches, and a cleaner mental model. This is the one most existing codebases will quietly appreciate without noticing why everything got easier.

Concurrency Grows Up

Two big items here. Parallel subinterpreters are now usable from pure Python through InterpreterPoolExecutor in concurrent.futures, giving you a middle ground between threads (cheap, but GIL-bound) and processes (true parallelism, but heavy). And free-threaded Python — the GIL-free build — reached officially supported status under PEP 779.

The honest tradeoff, straight from the release notes: free-threaded builds carry roughly a 10–15% single-thread performance penalty and up to about 20% more memory use, and the GIL is still enabled by default. So this is a foundation for the future, not a free speed boost you flip on today. Worth experimenting with, not worth betting production on this afternoon.

Smaller Things That Add Up

Safer live debugging (PEP 768): attach pdb to a running process with python -m pdb -p <PID>. Both processes need to be on 3.14.
Exceptions without parentheses (PEP 758): except ValueError, TypeError: is now valid when you're not binding with as.
Warnings in try…finally (PEP 765): a return, break, or continue inside a finally block now triggers a SyntaxWarning, because silently swallowing exceptions was a footgun for years.
Incremental garbage collector: cycle collection is spread across smaller steps, so latency-sensitive code sees shorter pauses.

The Part Everyone Dreads: Actually Upgrading

Here's where AWS Transform custom comes in. ATX uses agentic AI to perform large-scale code modernization — language version upgrades, SDK migrations, framework transitions, and more. The thing that sets it apart from pointing a generic AI assistant at each repo is continual learning: each execution captures patterns, fixes, and edge cases as reusable knowledge items, so the transformation gets more reliable the more you run it.

For Python version bumps, there's an AWS-managed transformation called AWS/python-version-upgrade. You run it through the atx CLI:

atx custom def exec \
  -n AWS/python-version-upgrade \
  -p ./my-python-repo \
  -c "pytest" \
  -g "additionalPlanContext='Upgrade this project to the latest supported Python version'" \
  -x -t

The flags, per the command reference: -p is the repo path, -c is your build or validation command, -n names the transformation, -x runs it non-interactively, and -t trusts all tool executions so you aren't prompted. You can wrap that in a shell loop across dozens of repos, which is exactly the "forty untouched repositories" scenario from the intro.

The Fact-Check You Were Promised

Here's the honest bit. The official docs for AWS/python-version-upgrade say it migrates Python projects from 3.8/3.9 to 3.11/3.12/3.13. As written, Python 3.14 is not listed as a validated target.

So what does "early upgrade to 3.14" actually mean in practice? Two real, documented options:

Get current first. Using ATX to move legacy 3.8/3.9 code up to a modern 3.13 baseline is the fully-supported step that gets you most of the way and removes the scariest deprecation risk. The docs state the managed transformation ensures "compatibility with the latest Python features, security updates, and runtime while maintaining functionality and performance." The last hop to 3.14 from a clean, well-tested 3.13 codebase is small.
Guide it with additionalPlanContext. The docs explicitly state you can specify your desired target Python version either through interactive chat with the agent or by passing additionalPlanContext. That's the supported mechanism for steering the target. Give it a solid validation command like pytest, review the diff, and let continual learning absorb whatever it learns. Just go in knowing 3.14 is ahead of the documented validated range, so the validation command isn't optional — it's your safety net.

That's the difference between encouraging an early upgrade and overselling one. ATX makes the journey to a modern Python dramatically cheaper; it doesn't magically certify a target the docs haven't certified yet.

A Couple of ATX Quirks Worth a Smile

Windows users, brace yourselves. The getting-started docs note that AWS Transform custom detects a native Windows environment and exits with an error message. The official remedy is to install WSL. The tool would simply rather not.
It learns from you, unless you tell it not to. There's a -d (--do-not-learn) flag to opt a run out of knowledge extraction. Most of the time you want learning on — that's the whole value — but it's there for the repos you'd rather keep to yourself.
It tracks agent minutes. You can check the accumulated agent minutes for the current session with /usage, and cap a run with --limit, which sets an Agent Minutes budget limit. Think of it as a parking meter for your tech debt.

A Sensible Rollout

The Python core team's own advice is measured: if you're on 3.13, moving to 3.14 is an easy win for daily development, but you don't need to rush, especially if you lean on C extensions or compiled wheels that need time to catch up. Many large shops wait for the first maintenance release (3.14.1) before a fleet-wide rollout.

That maps cleanly onto how ATX is meant to be used — the docs describe a four-phase workflow: define the transformation, run a pilot on a sample repo, scale execution across many repos via the CLI, then monitor and approve the knowledge items it learned. So a reasonable plan looks like:

Pilot AWS/python-version-upgrade on one representative repo with a real test command.
Review the diff and the proposed changes like you would any pull request.
Scale across the rest once the pilot looks clean.
Approve the knowledge items so the next batch goes smoother.

Wrapping Up

Python 3.14 is a quietly strong release: a friendlier REPL, error messages that actually help, t-strings for safer interpolation, lazy annotations that fix a decade-old papercut, and a maturing concurrency story. None of that matters if your code is stuck three versions back. AWS Transform custom is built precisely for that gap — and its continual learning means the upgrade gets cheaper every time you run it.

Be honest about the target: ATX's managed Python transformation officially validates up to 3.13, with additionalPlanContext to steer further. Use it to get current now, ride the supported path to a clean 3.13 baseline, and the final step to 3.14 stops being a project and becomes a Tuesday.

And if you do upgrade, run 𝜋thon once in a fresh venv. You've earned the dumb little joke.