DEV Community: Abhilash Veettil

Why Ruby on Rails Feels Built for the AI Coding Era

Abhilash Veettil — Fri, 03 Jul 2026 07:36:31 +0000

I've been writing a lot of code recently, of course with lot of help from Claude and Codex. I mostly write in Ruby on Rails and I am falling in love with RoR all over again.

I've never really felt the urge to switch from Ruby on Rails to JavaScript. Not because JavaScript is bad. But because Ruby has always felt natural to me.

It's simple. It's expressive. It lets me think about the product instead of the ceremony around building it.

And now, in the age of AI-assisted coding, Rails has become even more valuable to me.

The reason is simple: AI doesn't just write code. It makes decisions.

Every time an AI assistant generates a controller, a model, a service object, a migration, a view, an API endpoint, or a background job, it's making dozens of small architectural choices.

Where should this logic live? How should the data flow? What should the folder structure look like? How should validations be handled? What should be abstracted, and what should stay simple?

In a framework with weak conventions, AI has too much freedom. And too much freedom breeds inconsistency.

One file follows one pattern. The next follows another. A third introduces an unnecessary abstraction. Before long, the app still "works," but the codebase feels like it was assembled by a dozen developers who never spoke to each other.

That's where Rails shines. Rails gives AI a path to follow.

The framework already has opinions. Models go here. Controllers go here. Views go here. Migrations follow this pattern. Routes follow this structure. Validations belong in the model. Background jobs, mailers, and tests each have their place. Security defaults aren't an afterthought.

Caching, Active Record, naming, structure, conventions, integrations — all part of the same ecosystem.

This matters because AI performs better when the environment has strong patterns.

Rails isn't just a framework. It's a set of decisions made in advance. And that's powerful.

As DHH put it:

"Rails is opinionated software. It makes the assumption that there is a 'best' way to do things, and it's designed to encourage that way."
That opinionation used to be a convenience. In the AI era, it's an advantage.

For human developers, convention over configuration has always meant speed. For AI-assisted development, it means something even more important: reduced architectural drift.

When I ask AI to help me build in Rails, I'm not starting from a blank canvas. I'm handing it a well-marked road.

It still needs guidance. It still needs review. It still needs a developer who understands the product, the domain, and the trade-offs. But Rails reduces the number of unnecessary choices the AI has to make.

That makes the output easier to review. Easier to reason about. Easier to maintain.

And this is also why I love Ruby. Ruby doesn't feel like I'm fighting the language. It reads closer to how I think.

The simplicity of Ruby isn't just aesthetic. It changes the way I build. When the language is expressive and the framework is opinionated, I get to spend my time on the customer problem, the workflow, the data model, the business logic.

That's where real value is created. Not in arguing about folder structures. Not in wiring together ten libraries before the first feature works. Not in reinventing authentication, background jobs, form handling, routing, or deployment for every small product.

Of course, Rails isn't perfect. No framework is.

Large Rails apps can still turn messy without discipline. AI can still over-engineer. It can still misunderstand the domain. It can still produce something that looks correct but quietly creates technical debt.

AI doesn't remove the need for engineering judgment. It raises the penalty for not having it.

But that's exactly why I prefer Rails. It gives me leverage without removing responsibility. It gives me speed without forcing chaos. It gives AI enough structure to be useful, while leaving room for a good engineer to make the decisions that matter.

For me, the AI coding era hasn't made Rails less relevant. It's made Rails more relevant.

Because the future of software may not belong to the language with the most hype. It may belong to the ecosystem that gives both humans and AI the clearest path from idea to working product.

And for many products — SaaS apps, internal tools, business workflows, dashboards, automations, MVPs — Ruby on Rails still feels like one of the best paths available.

Simple. Opinionated. Productive. Human-friendly.

And now, surprisingly, AI-friendly too.

I built Formserve.IO using Ruby on Rails, check it out

I built a free CLI that catches the security holes your AI leaves behind

Abhilash Veettil — Tue, 30 Jun 2026 16:16:18 +0000

npx kavaca — a free, local, open-source pre-flight check that finds exposed secrets and open Supabase databases in your AI-built app, in about 10 seconds. Nothing leaves your machine.

The uneasy feeling

I build a lot of small apps with AI tools now — Claude Code, Cursor, the occasional Lovable or Bolt prototype. They're fast. Sometimes too fast: you go from idea to deployed app in an afternoon, and somewhere in that afternoon you stop reading every line the model writes.

And every time I got close to shipping one, I'd get this uneasy feeling:

Did it actually turn on row-level security for that Supabase table?
Is my Stripe key sitting in an env var, or did it get committed?
Would I even notice if a secret leaked into the client bundle?

I'm reasonably technical and I still couldn't answer those quickly. So I started checking by hand, every time. Then I got tired of checking by hand, and did what we all do — I scratched my own itch and wrote a script.

That script became Kavaca.

Why AI-built apps share the same holes

This isn't a "the AI is dumb" post. The models are great at writing code that works. The problem is that working code and safe code aren't the same thing, and the gap is exactly the stuff a senior engineer does on instinct — and never says out loud, so the model never learns to do it unprompted.

The result is a handful of mistakes that show up again and again:

service_role keys or sk_live_… secrets committed into the repo or, worse, shipped to the browser.
Supabase tables created with no RLS — which means anyone with your public anon key can read (or delete) rows.
Secrets behind a public env prefix (NEXT_PUBLIC_, VITE_) that get inlined into the client bundle.

None of these are exotic. They're behind a huge share of the "my vibe-coded app got hacked" threads. They're also boringly detectable — which is the whole idea.

The tool

One command, no install, no account:

npx kavaca

It scans the current directory and prints a result in seconds. Point it somewhere specific or get machine-readable output:

npx kavaca ./my-app
npx kavaca --json        # for CI

Exit code is 0 when clean and 1 when it finds something, so it drops straight into a pipeline.

What it actually checks

Three deterministic, local detectors:

1. Exposed secrets. Committed live credentials — Stripe (sk_live_…, rk_live_…), OpenAI / Anthropic keys, AWS access key IDs, database URLs with embedded passwords, and Supabase service_role JWTs. The JWT check isn't just a pattern match — it base64-decodes the payload and only flags if "role": "service_role" is actually in there, which kills a lot of false positives.

2. Frontend exposure. Sensitive values sitting behind a public env prefix (NEXT_PUBLIC_*, VITE_*, REACT_APP_*, EXPO_PUBLIC_*), and service_role keys referenced from client-side code.

3. Open Supabase databases. When it detects Supabase, it parses your SQL migrations and flags every CREATE TABLE that never gets a matching ENABLE ROW LEVEL SECURITY.

It's deliberately quiet about false positives — .example files, process.env. references, and placeholders like your_key_here are ignored. A security tool that cries wolf gets uninstalled on the first run, so it biases hard toward precision.

Here's what a run looks like:

  ◎ Kavaca — pre-flight security check
  Scanning ./my-app  (local only — nothing leaves your machine)

  ✔ Secrets in code .............. 1 issue
  ✔ Frontend exposure ............ clear
  ✔ Supabase database ............ 1 issue

  ──────────────────────────────────────────────
  ⚠  2 issues found · score 50/100

  HIGH  Live Stripe key (lib/payments.ts:14)
        sk_live_••••••••1234 — visible to anyone with the repo

  HIGH  Supabase table "orders" has no RLS policy
        Anyone with your anon key may be able to read it

Evidence is always masked — it never prints (or uploads) a full secret.

Local-first, and I mean it

Here's the part that matters most for a security tool: the default run makes zero network requests. Your code, your file paths, your secrets — none of it leaves your machine. There's an optional --share-stats flag that sends anonymous aggregate counts only ({ toolVersion, issueCountsByCheck, totalFiles }), it's off by default, and the entire network surface is a single, clearly-gated function you can read in src/telemetry.ts.

That's also why it's open source (MIT). "Trust me, I'm a security tool" is a tough sell. "Read the code" is a better one.

Drop it into CI

name: Kavaca security check
on: [push, pull_request]
jobs:
  kavaca:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npx --yes kavaca . --json

Now every push gets a 10-second pre-flight check.

Being straight with you

This CLI checks 3 of 8 risk areas. It's the smoke alarm, not the full inspection. There's a hosted version at kavaca.io that adds auth, API, and dependency checks with plain-English fixes and paste-ready prompts — that's the thing I'm actually building a business around. But the CLI is genuinely free and standalone, and it'll catch the stuff that ends launches. Use just the CLI forever if you want; that's a completely valid choice.

I'd love your help

The detectors live in src/detectors/ and every regex is documented in src/patterns.ts. If you know a secret format I'm not catching, or you've hit a false positive, that's exactly the feedback I want — open an issue or send a PR with a fixture.

⭐ Repo: github.com/eabhvee/kavaca-cli
Try it: npx kavaca

If you've shipped something with AI that has real users, do me a favor and run it before you read the next post in your feed. Worst case, it takes ten seconds and tells you you're clean. Best case, it catches the thing you really didn't want a stranger to find first.

What patterns should it check next? Let me know in the comments 👇

Why Your AI-Generated Contact Form Is Not Working

Abhilash Veettil — Sun, 21 Jun 2026 07:36:04 +0000

Why Your AI-Generated Contact Form Is Not Working

AI can build a beautiful contact form in seconds.

Whether you're using Cursor, Bolt.new, v0, Claude Code, Lovable, or Replit, getting a polished form on the page is usually easy.

Getting submissions to actually reach someone is where things start to break.

The problem is that most AI tools are excellent at generating frontend code, but forms require more than a frontend.

A contact form is only useful if it can reliably deliver leads.

The Hidden Problem

Open any AI-generated website and inspect the contact form.

It often looks complete:

Name field
Email field
Message box
Submit button
Nice styling

But ask a simple question:

Where does the form submission actually go?

In many cases, the answer is:

Nowhere
A placeholder endpoint
A local development server
A backend that does not exist anymore

The UI is finished.

The workflow is not.

The Five Most Common Issues

1. No Real Action URL

A form needs a destination.

Without a valid backend endpoint to collect and save data, clicking Submit does nothing useful.

Example:

<form>

<form action="#">

The browser has no meaningful place to send the data.

2. Wrong HTTP Method

Many AI-generated examples use GET by default.

Contact forms should almost always use POST.

<form action="/contact" method="POST">

Using the wrong method can break integrations and expose data unnecessarily.

3. Missing Name Attributes

This is surprisingly common.

Developers focus on placeholders and labels but forget that the backend receives field names, not visual labels.

Broken:

<input type="email" />

Working:

<input type="email" name="email" />

Without the name attribute, the field value is never submitted.

4. No Spam Protection

The moment a public form goes live, bots will find it.

Without protection you will eventually receive:

Spam submissions
Phishing attempts
Garbage leads
Automated attacks

A simple honeypot field helps.

Better solutions include rate limiting, bot detection, and filtering.

5. No Submission Visibility

Even if the form works today, what happens tomorrow?

Questions worth asking:

Did the submission arrive?
Did the email fail?
Did Slack receive the notification?
Can the business owner review old submissions?

Many AI-generated solutions stop after the first successful test.

Production systems need visibility.

The Quick Fix

The good news is that you usually do not need to rebuild the frontend.

Most AI-generated forms can be fixed in minutes.

Check the following:

Use a real endpoint
Set method="POST"
Add name attributes to every field
Include spam protection
Display success and error states
Store submissions somewhere accessible

The frontend is rarely the problem.

The submission pipeline is.

The Production Checklist

Before launching any AI-generated form, verify:

✅ Submissions reach a real endpoint

✅ Failed deliveries are visible

✅ Spam is filtered

✅ Form data is stored

✅ Business owners can review submissions later

✅ Notifications are delivered reliably

If any of these are missing, the form is not truly finished.

The New Reality of AI Website Development

AI has dramatically reduced the effort required to build websites.

What used to take days now takes minutes.

But the backend responsibilities have not disappeared.

A contact form is more than a collection of inputs.

It is a workflow.

The frontend captures the lead.

The backend makes sure the lead is not lost.

And that is still where most AI-generated forms fail.

Don't build an entire backend to get your contact form working

If you are building websites with AI tools such as Cursor, Bolt.new, v0, Claude Code, Lovable, or Replit, you don't have to build a backend from scratch to get your form working. Instead, you can connect your forms to a managed backend service like Formserve to handle:

Submission storage
Spam protection
Email notifications
Slack notifications
Webhooks
Integrations with tools such as Notion, Airtable, HubSpot, and Google Sheets

This lets you keep the AI-generated frontend while adding a production-ready submission workflow behind it.

A personal story about how AI is leveling the playing field.

Abhilash Veettil — Sat, 20 Jun 2026 14:39:50 +0000

My daughter has been behind me to create a YouTube channel for her for the last 6 months. This week, I finally sat down and made her one, Aloha’s Kingdom.

Then she wanted me to make a video for her. She didn’t want just a video.

She wanted a story, one that mixed real footage, animation, music, visual effects, voiceovers, and a little bit of magic. I accepted the challenge.

A few years ago, creating something like this I would have required to hire a small team:

• A videographer

• An editor

• An animator

• A scriptwriter

• A designer

• A voice artist

Today, I could do all of it with AI, just in a couple of hours. What is fascinating is not the technology itself but what the technology demanded from me.

To create the episode, I had to switch constantly between roles:

📸 Photographer

🎬 Video editor

✍️ Storyteller

🎨 Designer

🤖 Prompt engineer

🎵 Creative director

I am not limited by my talent any more, I am only limited by my imagination, judgment, and the ability to connect different skills together 😆

That’s how AI is leveling the playing field, not because everyone now has the same tools but because individuals can now execute ideas that previously required entire teams.

And another thought which I crossed my minds was that generalists may have an unfair advantage in the AI era. When AI can help with execution, the people who can combine multiple disciplines become incredibly powerful.

The future may belong less to those who know one thing deeply, and more to those who can connect many things meaningfully.

My daughter got her episode.

I got a reminder that we’re living through one of the most interesting times in human history.

Here is the link to the final video

The article was originally published here

AI #Creativity #DigitalTransformation #FutureOfWork #GenerativeAI #ContentCreation #Learning