DEV Community: Yashika Vijayvargiya

What Is Vibe Coding? Benefits, Risks, and Best Practices for AI-Assisted Development

Yashika Vijayvargiya — Fri, 21 Aug 2026 12:00:59 +0000

Introduction

AI has changed how developers write software.

Instead of writing every line of code manually, many developers now describe what they want in plain English and let AI generate the implementation.

This way of working has become popularly known as vibe coding.

Some developers see it as the future of software development, while others worry it encourages developers to rely too heavily on AI.

So, what exactly is vibe coding, and when should you use it?

Let's explore.

What Is Vibe Coding?

Definition

Vibe coding is an AI-assisted development approach where developers describe what they want to build instead of manually writing every line of code.

Rather than starting with an empty file, developers provide prompts such as:

Build a REST API for managing products with authentication and pagination.

The AI generates the initial implementation, which the developer reviews, modifies, and tests.

In simple words:

Instead of writing every line yourself, you guide AI to write the first draft of your code.

Traditional Coding vs. Vibe Coding

Traditional Development

Understand the problem
↓
Design the solution
↓
Write code
↓
Debug
↓
Test
↓
Deploy

The developer writes every implementation detail manually.

Vibe Coding

Understand the problem
↓
Describe it to AI
↓
AI generates code
↓
Review
↓
Test
↓
Improve
↓
Deploy

The developer focuses more on problem-solving and less on typing boilerplate code.

An Example

Imagine you want to build authentication in a Rails application.

Traditional approach

You would:

Generate models
Configure routes
Add controllers
Write validations
Implement sessions or JWT
Create tests

This might take hours.

Vibe coding approach

You ask:

Create JWT authentication for a Rails API with login, logout, refresh tokens, request specs, and proper error handling.

Within seconds, the AI generates the initial implementation.

Your job becomes reviewing, testing, and refining the code instead of writing everything from scratch.

Why Is Vibe Coding Becoming Popular?

Modern AI coding tools can:

Understand multiple files
Navigate large codebases
Generate tests
Refactor code
Explain existing code
Detect common bugs

This allows developers to move faster, especially when working on repetitive tasks.

Popular AI Coding Tools

Some of the most widely used AI coding assistants include:

Cursor
Claude Code
GitHub Copilot
Gemini Code Assist
Windsurf

These tools help developers write, refactor, and understand code more efficiently.

Benefits of Vibe Coding

Faster Development
Instead of spending time writing repetitive code, developers can focus on solving business problems.

Less Boilerplate

AI can generate:

CRUD operations
API endpoints
Tests
Configuration
Documentation

Easier Learning

Developers exploring a new language or framework can use AI to understand patterns and best practices more quickly.

Better Productivity

Many developers use AI for:

Writing tests
Explaining unfamiliar code
Refactoring methods
Generating documentation
Creating migration files

Risks of Vibe Coding

Despite its advantages, vibe coding has important limitations.

AI Can Produce Incorrect Code

AI-generated code isn't always correct.

It may:

Misuse libraries
Ignore edge cases
Introduce bugs
Generate outdated patterns
Always review the generated code.

Security Risks

AI might generate:

SQL injection vulnerabilities
Weak authentication
Insecure API implementations

Security-critical code should always be reviewed carefully.

Overengineering

Sometimes AI solves simple problems with unnecessarily complex code.

Good developers know when a simpler solution is better.

Reduced Understanding

If developers accept AI-generated code without understanding it, debugging and maintaining the application becomes much harder.

When Should You Use Vibe Coding?

Vibe coding works well for:

CRUD applications
API scaffolding
Unit tests
Documentation
Refactoring
Code explanations
Repetitive development tasks

When Should You Avoid It?

Be cautious when working on:

Payment systems
Authentication
Authorization
Financial calculations
Security-sensitive features
Distributed systems
Performance-critical code

These areas require careful design, testing, and review.

Best Practices

Use AI as a collaborator
Don't treat AI as a replacement for engineering judgment.

Review every generated change
Understand what the AI generated before merging it.

Write tests
AI-generated code should be validated with automated tests.

Keep prompts specific
Instead of asking:

Build an API.

Ask:

Build a Rails API using service objects, request specs, pagination, JWT authentication, and proper error handling.

Clear prompts generally produce better results.

Conclusion

Vibe coding is changing the software development workflow by allowing developers to express ideas in natural language and use AI to generate an initial implementation.

Used thoughtfully, it can improve productivity and reduce repetitive work.

However, AI-generated code is still software that needs to be reviewed, tested, and maintained.

The most effective developers aren't those who let AI write everything—they're the ones who know when to rely on AI and when to rely on their own expertise.

Hashnode AI

Hashnode AI is a Pro feature
Upgrade to Pro to refine your drafts, suggest edits, and brainstorm with the Writing Assistant.

Upgrade to Pro
Search Hashnode
Search posts, tags, users, and pages

The Rails Bug That Disappeared After a Server Restart — Until I Found the Mutation

Yashika Vijayvargiya — Mon, 17 Aug 2026 07:16:44 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories.

Project Overview

Some bugs are difficult because the code is complicated.

Others are difficult because the bug seems to have no rules.

This was the second kind.

A Rails application I was working on started rendering ActiveAdmin menus incorrectly.

Sometimes nested menu items appeared under the wrong level.

Sometimes everything looked completely normal.

And sometimes restarting the application made the problem disappear.

That last part was the most suspicious.

A restart shouldn't "fix" a deterministic piece of Ruby code.

So I started digging.

What I eventually found was a much more interesting problem:

An object was being modified somewhere I didn't expect it to be modified.

And the fix turned out to be one of the simplest Ruby changes I've made:

options = options.dup

But getting there took considerably more work.

Bug Fix or Performance Improvement

The application was using ActiveAdmin for its administrative interface.

The problem appeared in the navigation menu.

We had nested menu items, and occasionally they were rendered as top-level items instead of being nested under their intended parent.

Something like:

Expected:

Reports
  ├── Sales
  └── Revenue

Actual:

Reports
Sales
Revenue

The frustrating part was that the behavior wasn't consistently reproducible.

The same application could:

render the menu correctly
render it incorrectly
restart
start working again
continue working for some time
then fail again

This was not the kind of bug where I could simply open the relevant controller and find a typo.

It looked almost random.

The First Clue: Restarting the Server "Fixed" It

The most interesting observation was that restarting the server temporarily resolved the problem.

That immediately made me suspicious of state.

If restarting the process changes the behavior without changing the database or application code, something may be surviving longer than expected inside the process.

That led me away from asking:

"What condition makes the menu render incorrectly?"

and toward:

"What state is being mutated between requests?"

That was a much better question.

Following the Menu Construction

I started tracing how ActiveAdmin constructs its menus.

Eventually I reached the menu node implementation and the add method responsible for adding menu items.

The important part looked roughly like this:

def add(options)
  # menu item construction
end

At first, there was nothing obviously wrong.

The method received an options object and used it to construct the menu node.

But the more I followed the execution path, the more suspicious the object itself became.

The same options object was being passed through multiple parts of the menu-building process.

And something was changing it.

The Problem Wasn't the Value

This was the key realization.

The problem wasn't necessarily that the options contained the wrong value.

The problem was that the options object itself was mutable.

Imagine this simplified example:

options = {
  parent: "Reports",
  label: "Revenue"
}

You pass that object into another method:

build_menu(options)

If build_menu modifies it:

options.delete(:parent)

the original object has now changed too.

There is no copy.

There is no isolation.

Both pieces of code are holding a reference to the same object.

So later:

options[:parent]

returns:

nil

even though the code that originally created the options never intentionally removed it.

That is exactly the kind of mutation that can create a bug that looks random.

Why It Looked Random

The menu wasn't necessarily broken every time.

The behavior depended on when and how the shared object was mutated.

That made the symptoms particularly confusing.

A simplified lifecycle looked like this:

Create menu options
        ↓
Pass options to ActiveAdmin
        ↓
ActiveAdmin modifies options
        ↓
Original object is now different
        ↓
Another menu operation uses it
        ↓
Parent information is missing/incorrect
        ↓
Nested item becomes top-level

And because the object lived inside the running Ruby process, restarting the server cleared that in-memory state.

That explained why a restart could appear to "fix" the bug.

It wasn't fixing anything.

It was simply giving us a fresh process with fresh objects.

Then I Found the GitHub Issue

After spending a significant amount of time debugging the behavior at the application and dependency level, I searched GitHub for similar ActiveAdmin problems.

That's when I found:

ActiveAdmin issue #8078 — "Nested menu items are rendered top-level."

The issue description was remarkably similar.

It reported that nested menus were sometimes rendered at the top level, and that restarting the server temporarily solved the problem. The issue was difficult to reproduce and had been observed in production.

That was the moment when the investigation changed direction.

I wasn't dealing with some mysterious Rails rendering bug.

There was already evidence that ActiveAdmin's menu construction could be modifying menu state.

The issue eventually led to ActiveAdmin PR #8132, titled:

"Make sure menu creation does not modify menu options."

The ActiveAdmin maintainer later reported that the patch had run in production for almost a month without the menu rendering problem recurring before merging it.

Now I had a much stronger hypothesis:

The options object was being mutated during menu construction.

The next question was:

How can I prevent that mutation from affecting the object my application is using?

Code

The Fix: Give `add` Its Own Copy

Instead of passing the original options object into the existing implementation, I created a duplicate first.

The patch was:

module MenuNode
  def add(options)
    options = options.dup
    super(options)
  end
end

ActiveAdmin::Menu.class_eval do
  include MenuNode
end

That's it.

The important line is:

options = options.dup

Before the fix:

Application
    │
    ▼
options ───────────────┐
                      │
                      ▼
                ActiveAdmin
                      │
                      ▼
                modifies object
                      │
                      ▼
            original options changed

After the fix:

Application
    │
    ▼
original options

    │
    │ dup
    ▼

copied options
    │
    ▼
ActiveAdmin
    │
    ▼
can modify its copy

The original object remains untouched.

Why `dup` Fixed It

Ruby objects are references.

Consider:

options = {
  parent: "Reports",
  label: "Revenue"
}

copy = options

copy isn't a new Hash.

Both variables point to the same object.

So:

copy.delete(:parent)

also changes:

options

because they're the same object.

But:

copy = options.dup

creates a separate Hash.

Now:

copy.delete(:parent)

doesn't remove the key from the original options.

That's exactly the isolation we needed.

Why I Used `super`

There was another important detail in the fix.

I didn't want to reimplement ActiveAdmin's add method.

That would have created another maintenance problem.

Instead, I wanted to change one thing:

Give the original method a safe copy of the options.

Then let ActiveAdmin continue doing everything else exactly as it already did.

That's why the implementation is:

def add(options)
  options = options.dup
  super(options)
end

The flow becomes:

Our wrapper
    ↓
duplicate options
    ↓
ActiveAdmin's original add
    ↓
existing behavior

This is a useful pattern when working with a third-party library:

Change the boundary, not the library's internal behavior.

My Improvements

The Debugging Lesson: Don't Trust "Random"

One of the biggest lessons from this bug was that "random" doesn't necessarily mean random.

When an application behaves differently after a restart, there is often state involved.

That state could live in:

class variables
global objects
memoized values
caches
singleton instances
mutable configuration
shared Hashes or Arrays
library objects that survive across requests

In Ruby, mutable objects make this especially important.

This:

options = original_options

and this:

options = original_options.dup

look similar.

But they create very different ownership semantics.

The Dependency Was Part of the Application

Another lesson was about debugging third-party libraries.

It is tempting to say:

"The bug is in ActiveAdmin."

But that doesn't help when you're responsible for the application.

The useful question is:

Where does the incorrect state enter my application?

That led me through:

Application behavior
       ↓
ActiveAdmin
       ↓
Menu construction
       ↓
MenuNode#add
       ↓
options object
       ↓
unexpected mutation

Once I could see the mutation boundary, the fix became straightforward.

The Fix Was Tiny. The Investigation Wasn't.

This is something I've noticed repeatedly when debugging production Rails applications.

The final patch often looks deceptively simple.

In this case:

options = options.dup

is almost trivial.

But the path to that line involved:

reproducing an intermittent problem
comparing behavior before and after a restart
tracing ActiveAdmin internals
inspecting how menu nodes were constructed
questioning object ownership
searching existing GitHub issues
finding a closely related ActiveAdmin issue
understanding why the existing implementation could mutate shared state
introducing a minimal wrapper
delegating back to the original implementation with super

The difficulty wasn't writing the fix.

The difficulty was finding the right layer to fix.

What This Taught Me About Ruby

Ruby makes it very easy to pass objects around.

That's one of its strengths.

But that convenience also means that mutable objects can cross boundaries without making ownership obvious.

Whenever I see a method receiving a Hash or Array, I now ask:

Who owns this object, and is this method allowed to modify it?

If the answer isn't clear, copying the object at the boundary can sometimes be the difference between stable behavior and an intermittent production bug.

Of course, dup isn't a universal solution.

It is a shallow copy, so nested mutable objects can still be shared:

options = {
  menu: {
    parent: "Reports"
  }
}

In that situation:

copy = options.dup

duplicates the outer Hash, but the nested :menu Hash is still shared.

So the correct solution depends on what the called code actually mutates.

In this case, duplicating the options object at the add boundary was enough.

The Bigger Lesson

When a bug looks random, don't immediately assume the framework is behaving unpredictably.

Look for state.

When restarting the server makes the bug disappear, don't celebrate.

Ask what state the restart destroyed.

When a dependency receives a mutable object, don't assume it will leave it untouched.

And when you finally identify the problem, resist the temptation to rewrite everything.

Sometimes the safest fix is simply:

options = options.dup
super(options)

A tiny boundary.

A separate object.

No accidental mutation.

And suddenly the "random" bug isn't random anymore.

Final Takeaway

The most valuable part of debugging isn't always the final code change.

Sometimes it's the moment when a confusing symptom finally becomes a predictable consequence of one small assumption.

In my case:

"Menus randomly render incorrectly"
              ↓
"Restarting fixes it"
              ↓
"There must be state"
              ↓
"ActiveAdmin is modifying menu options"
              ↓
"The same mutable object is being reused"
              ↓
"Give ActiveAdmin a copy"
              ↓
options.dup

The final fix was one line.

The investigation was the real engineering work.

And that's probably the part of this bug I'll remember.

When a String Assumption Broke Newsletter Tag Filtering in Ruby

Yashika Vijayvargiya — Fri, 14 Aug 2026 10:55:37 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

When a Single Type Assumption Broke Newsletter Tag Filtering in Ruby

A bug doesn't always need hundreds of lines of code to cause a real problem.

Sometimes, one assumption is enough.

In this case, the assumption was simple:

"Every tag is a String."

That assumption lived inside a Ruby filtering method in the open-source RubyEvents project.

It worked perfectly — until a tag wasn't a String.

That small mismatch was enough to turn a normal user interaction into an error.

This is the story of how the bug was investigated, what was actually going wrong, and how a small change made the filtering logic safer and clearer.

The Bug

The issue was reported as:

"Cannot Click tags on Newsletter"

The behavior was straightforward:

Open a newsletter.
Click one of its tags.
Instead of getting the filtered announcements, the application raises an error.

The issue was tracked as #1836.

At first glance, this sounds like it could be a routing or controller problem.

It wasn't.

The failure was deeper in the tag-filtering logic.

Finding the Assumption

The filtering logic lived in

Announcement::Collection#by_tag

The original implementation was:

def by_tag(tag)
  Collection.new(
    select { |a| a.tags.map(&:downcase).include?(tag.downcase) }
  )
end

The intent is easy to understand:

take all tags from an announcement
convert them to lowercase
compare them with the requested tag
return matching announcements

For normal String values, this works perfectly.

For example:

["Ruby", "Rails"].map(&:downcase)
=> ["ruby", "rails"]

But there is an important assumption hidden inside:

map(&:downcase)

Every element must respond to downcase.

That's not necessarily true.

Imagine the collection contains:

["Ruby", 123]

Calling:

["Ruby", 123].map(&:downcase)

eventually tries to execute:

123.downcase

And integers don't have a downcase method.

The result is a NoMethodError.

So the real problem wasn't the newsletter link itself.

The newsletter was simply the path that exposed an unsafe assumption in the tag-filtering code.

The Interesting Part: Fixing the Bug Without Changing the Behavior

There were several ways this could have been "fixed."

For example, we could have assumed that all tags should always be Strings and modified the data at the source.

But that would increase the scope of the change.

The filtering method already had a clear responsibility:

Find announcements whose tags match the requested tag, case-insensitively.

So instead of changing the data source, I wanted to make the comparison resilient to the values it actually received.

The implementation became:

def by_tag(tag)
  Collection.new(
    select { |a| a.tags.any? { |tag_value| tag_value.to_s.casecmp?(tag) } }
  )
end

There are two important changes here.

to_s Creates a Safe Comparison Boundary

Instead of assuming:

tag_value.downcase

we explicitly convert the value:

tag_value.to_s

Now a String remains a String:

"Ruby".to_s
# => "Ruby"

And a non-String value becomes safely comparable:

123.to_s
# => "123"

The filtering code no longer crashes simply because a tag value isn't already a String.

This is a small example of something I find important when working with Ruby:

Don't make an assumption about the type of an object if you don't actually need that assumption.

casecmp? Expresses the Actual Requirement

The original implementation lowercased both sides:

tag_value.downcase == tag.downcase

But the actual requirement isn't:

Convert everything to lowercase.

The requirement is:

Compare these values without considering case.

Ruby provides exactly that operation:

casecmp?

So the comparison becomes:

tag_value.to_s.casecmp?(tag)

This makes the intent clearer.

We're not transforming the data just to compare it.

We're performing a case-insensitive comparison.

Why any? Instead of map?

This was another small but meaningful improvement.

The old implementation transformed every tag:

a.tags.map(&:downcase).include?(tag.downcase)

But we don't actually need a new array.

We only need to answer one question:

Does at least one tag match?

That's exactly what any? communicates:

a.tags.any? { |tag_value| ... }

It also allows Ruby to stop checking once a match is found.

So the new implementation isn't simply more defensive.

It's also closer to the actual intent of the operation.

Before vs After

Before

def by_tag(tag)
  Collection.new(
    select { |a| a.tags.map(&:downcase).include?(tag.downcase) }
  )
end

The hidden assumption:

Every tag
   ↓
must respond to #downcase

If one doesn't:

NoMethodError
   ↓
request fails
   ↓
user cannot follow the newsletter tag

After

def by_tag(tag)
  Collection.new(
    select { |a| a.tags.any? { |tag_value| tag_value.to_s.casecmp?(tag) } }
  )
end

Now:

Tag value
   ↓
convert safely to String
   ↓
case-insensitive comparison
   ↓
match / no match

The existing filtering behavior remains intact while the unsafe type assumption is removed.

Why This Bug Was Easy to Miss

This is what I found most interesting about the issue.

The original code isn't obviously bad.

For a dataset containing only Strings, this is perfectly reasonable Ruby:

a.tags.map(&:downcase)

The problem only appears when the runtime data doesn't match the assumption made by the implementation.

That's a common class of bugs:

Code assumption
       ↓
"this value will always be a String"
       ↓
Works for normal data
       ↓
Unexpected value enters the system
       ↓
Runtime failure

The lesson isn't:

"Never use downcase."

It's:

Know where your assumptions about data types are coming from.

If a method operates on data that can contain different types, the boundary where those values are consumed should be resilient.

The Investigation

What made this issue useful as a debugging exercise was that the final code change was small.

The investigation was the interesting part.

Instead of only looking at the error message, I traced the behavior back to the collection filtering logic.

That led to a few questions:

What type can each tag actually contain?
Why does downcase fail?
Do we really need to transform every tag?
Can the comparison itself be made type-safe?
Can the existing behavior be preserved without changing the surrounding code?

Once those questions were answered, the fix became much simpler.

The problem wasn't complicated business logic.

It was an unsafe assumption about the data.

The Final Change

The actual change was intentionally small:

- Collection.new(select { |a| a.tags.map(&:downcase).include?(tag.downcase) })
+ Collection.new(select { |a| a.tags.any? { |tag_value| tag_value.to_s.casecmp?(tag) } })

One line changed.

But that one line removed the assumption that every tag value was already a String.

I also fixed a linting issue in a follow-up commit.

The pull request was reviewed by the RubyEvents maintainer, passed all checks, and was merged into the project's main branch.

Issue

1836 — Cannot Click tags on Newsletter

Pull Request

1847 — Fix tag filtering for non-string tags

What I'm Proud Of

The final diff is tiny.

That's actually what I like about this fix.

There was no need to rewrite the filtering system or introduce another abstraction.

The existing behavior was already correct for valid String values.

The problem was the assumption around those values.

So instead of changing the entire flow, the fix:

keeps the existing behavior
makes the comparison type-safe
avoids unnecessary array allocation
expresses the intent with any?
uses casecmp? for case-insensitive comparison
keeps the change isolated to the filtering method

Small change, focused responsibility.

What I Learned

Small bugs can expose bigger assumptions

The code wasn't complicated.

The assumption behind the code was the real problem.

Whenever I see code such as:

items.map(&:some_method)

I now ask myself:

Do I know for certain that every item responds to this method?

That question becomes particularly important at boundaries where data may come from different sources.

Fix the behavior, not just the exception

It would have been easy to focus only on preventing the NoMethodError.

But a good fix should do more:

preserve existing behavior
make the comparison safe
make the intent clearer
avoid unnecessary transformations

The final implementation does all four.

Express the question you're actually asking

Compare:

map(...).include?(...)

with:

any? { ... }

The second version tells the reader what we're actually asking.

We're not interested in producing another collection.

We're asking whether any tag matches.

That makes the code easier to reason about and maintain.

Open source debugging is different

One thing I enjoy about contributing to open source is that you get to work with code outside the assumptions of your own applications.

You don't necessarily know every historical decision behind a method.

You don't know every shape of data that has passed through it.

And you don't get to rewrite the whole system just because you find one imperfect assumption.

You have to understand the existing behavior, make the smallest responsible change, and verify that the fix doesn't break what was already working.

That's what made this issue interesting to me.

The final diff was tiny.

The reasoning behind it was not.

The Takeaway

A bug doesn't always announce itself with a complicated stack trace or a thousand-line fix.

Sometimes it's hidden inside a single assumption:

"Every tag is a String."
When that assumption stopped being true, clicking a newsletter tag stopped working.

The fix was to make the comparison type-safe, preserve case-insensitive matching, and express the filtering intent more directly.

One line changed. One user-facing failure removed. One more reminder that robust software is often about handling the values we didn't expect.

Related Code

Issue:
1836 — Cannot Click tags on Newsletter

Pull Request:
1847 — Fix tag filtering for non-string tags

What Is Ponytail? A Beginner’s Guide to the AI Coding Companion Everyone Is Talking About

Yashika Vijayvargiya — Wed, 05 Aug 2026 09:29:26 +0000

⚠️ Note: AI developer tools evolve incredibly fast. Installation steps, supported editors, AI models, and configuration options may change over time. This article is not intended to be official documentation . Instead, its goal is to help you understand what Ponytail is, why it exists, and when you might want to use it . Before installing or configuring Ponytail, always refer to its official documentation for the latest instructions.

Introduction

If you’ve recently spent time on X (Twitter), Reddit, or developer communities, you’ve probably seen people talking about Ponytail.

Some developers call it an AI coding assistant.

Others think it’s an alternative to Cursor.

Some believe it’s a replacement for Claude Code.

And many assume it’s another Large Language Model (LLM) like ChatGPT or Claude.

None of these descriptions are entirely accurate.

This confusion exists because Ponytail is different from most AI tools developers are familiar with.

In this article, we’ll break down exactly what Ponytail is, what it is not, how it fits into the AI coding ecosystem, and when it makes sense to use it.

The Biggest Misconception About Ponytail

The first thing to understand is this:

Ponytail is not an AI model.

It cannot answer questions by itself.

It cannot generate code by itself.

It cannot replace ChatGPT, Claude, Gemini, or any other language model.

Instead, Ponytail works alongside an AI coding agent.

Think of it as a layer that influences how the AI approaches programming tasks.

Understanding the AI Coding Ecosystem

Many developers mix together editors, AI models, and coding agents.

These are different pieces of the puzzle.

Imagine you’re building a Rails application.

You have:

VS Code
    ↓
AI Coding Agent
    ↓
LLM (Claude / GPT / Gemini)

Each layer has a different responsibility.

VS Code

VS Code is simply your editor.

It doesn’t understand your code or generate anything on its own.

AI Model

Claude

GPT

Gemini

These are language models.

They understand natural language and generate code.

However, by themselves they don’t know how to edit files inside your project or interact with your development environment.

AI Coding Agent

An AI coding agent connects your editor to an AI model.

It can:

Read project files
Edit code
Create new files
Run commands
Analyze your repository
Suggest refactoring
Generate tests

Examples include various AI-powered coding assistants and editor integrations.

Ponytail

Ponytail sits on top of this workflow.

Instead of replacing your AI, it attempts to improve how the AI behaves while writing code.

An Analogy

Imagine you’re hiring a software engineer.

Without guidance, they might:

create unnecessary abstractions
introduce extra classes
over-engineer a simple solution
use complex design patterns for small problems

Now imagine giving that engineer a document that says:

Keep things simple.
Don’t create classes unless necessary.
Prefer existing libraries.
Avoid unnecessary complexity.
Write code another developer can understand quickly.

The engineer hasn’t changed.

Their instructions have.

Ponytail plays a similar role for AI coding assistants.

What Problem Does Ponytail Solve?

As AI became better at writing code, developers noticed recurring issues.

The AI often:

creates more files than necessary
writes excessive boilerplate
introduces unnecessary abstractions
overuses design patterns
invents helper classes
makes small tasks more complicated than they need to be

Sometimes this is useful.

Often it isn’t.

Ponytail aims to steer the AI toward simpler, more maintainable solutions.

What Ponytail Is NOT

Ponytail is not :

another version of ChatGPT
another LLM
a replacement for Claude
a replacement for Cursor
an IDE
a code editor
a compiler

Understanding this distinction removes most of the confusion.

Can Ponytail Work Without an AI?

No.

If you only install Ponytail, nothing happens.

You still need an AI coding agent backed by an AI model.

Think of it like this:

VS Code
❌

VS Code + Ponytail
❌

VS Code + AI Agent
✅

VS Code + AI Agent + Ponytail
✅

Does Ponytail Replace Cursor?

No.

Cursor is a complete AI-powered editor.

Ponytail is not.

Cursor provides:

editor integration
AI chat
autocomplete
repository understanding

Ponytail focuses on influencing how an AI coding assistant approaches problems rather than replacing the editor itself.

Does Ponytail Replace Claude?

No.

Claude is the intelligence.

Ponytail provides guidance.

Without Claude (or another supported model), Ponytail has nothing to reason with.

Does Ponytail Reduce Token Usage?

This is one of the most common questions.

The answer is:

Not directly.

Ponytail does not magically reduce the number of tokens consumed.

However, by encouraging the AI to produce smaller, simpler solutions with fewer unnecessary edits, some workflows may naturally involve fewer generated tokens.

This depends on:

the AI model
the coding task
the prompts
the agent’s behavior

So any reduction is a side effect of simpler outputs, not a guaranteed feature.

Is Ponytail Free?

Ponytail itself has generally been made available as an open-source project.

However, remember:

Using Ponytail does not eliminate the need for an AI model.

If your coding assistant relies on a paid AI service or API, those costs still apply.

Think of Ponytail as improving the workflow rather than replacing the underlying AI.

When Should You Use Ponytail?

Ponytail can be valuable when:

working on large production codebases
contributing to open-source projects
maintaining mature Rails applications
reviewing AI-generated code
encouraging simpler implementations
reducing unnecessary abstractions

These are situations where readability and maintainability often matter more than generating the maximum amount of code.

When Should You Avoid It?

Ponytail may not add much value if you’re:

learning programming from scratch
writing small throwaway scripts
experimenting with new ideas
using AI only for quick code snippets

In these cases, a standard AI assistant may already be sufficient.

A Rails Example

Suppose you ask your AI:

“Optimize this ActiveRecord query.”

Without guidance, the AI might introduce several service objects, helper modules, and layers of abstraction.

With a “keep it simple” philosophy, the AI is more likely to suggest:

adding the correct index
using includes
avoiding N+1 queries
simplifying the ActiveRecord chain
making a small, focused improvement

This often aligns well with how experienced Rails developers prefer to evolve applications.

Frequently Asked Questions

Is Ponytail another AI?

No.

Can Ponytail write code?

Not by itself.

Does Ponytail work without Claude or another AI model?

No.

Does Ponytail replace Cursor?

No.

Does Ponytail replace VS Code?

No.

Is Ponytail a code editor?

No.

Does Ponytail guarantee better code?

No. It provides guidance, but you should always review AI-generated code before merging it into production.

Final Thoughts

AI-assisted development is evolving at an incredible pace. New models, editors, and coding agents appear regularly, and the surrounding ecosystem changes just as quickly.

Ponytail is best thought of as a way to influence how an AI coding assistant approaches software development , encouraging simpler, more maintainable solutions rather than acting as a new AI model or editor.

Whether Ponytail becomes part of your daily workflow depends on your projects, your preferred tools, and how much you value AI-generated code that favors clarity over complexity.

As with any AI tool, the most important skill isn’t learning a specific product — it’s understanding where that product fits into the broader development workflow.

If this article introduced you to Ponytail for the first time, take a few minutes to explore its latest documentation, experiment with it in a small project, and decide whether its philosophy aligns with the way you like to build software.

Part 3: Optimistic Locking in Rails – Preventing Lost Updates Without Blocking Users

Yashika Vijayvargiya — Fri, 31 Jul 2026 10:49:53 +0000

Introduction

In the previous article, we learned how Pessimistic Locking prevents concurrent modifications by locking database rows.

While this guarantees data consistency, it also means other users may have to wait until the lock is released.

But what if conflicts are rare?

Should we still lock every row?

Probably not.

This is where Optimistic Locking comes in.

Instead of preventing concurrent updates, Optimistic Locking allows multiple users to edit the same record and detects conflicts only when they try to save their changes.

It assumes that conflicts are unlikely, making it a great choice for many web applications.

What is Optimistic Locking?

Definition

Optimistic Locking is a concurrency control strategy that allows multiple transactions to read and modify the same record without acquiring database locks.

Before saving changes, Rails checks whether the record has been modified by another transaction.

If it has, Rails raises an exception instead of silently overwriting the newer data.

In simple words:

"I believe no one else will modify this record. But before saving, I'll verify that assumption."

Why Do We Need Optimistic Locking?

Imagine an admin panel.

Two administrators open the same product.

Current Product:

Title: iPhone 16
Price: ₹80,000

Admin A changes:

Price → ₹75,000

Admin B changes:

Title → iPhone 16 Pro

Without optimistic locking:

Admin A saves.

Database:

Title: iPhone 16
Price: ₹75,000

A few seconds later...

Admin B saves.

Database becomes:

Title: iPhone 16 Pro
Price: ₹80,000

Admin A's update is lost.

This is called a Lost Update.

How Rails Solves This

Rails provides built-in support for Optimistic Locking using a column named:

lock_version

Whenever a record is updated:

Rails increments lock_version
Rails verifies the previous version before updating
If the version has changed, Rails raises an exception

Enabling Optimistic Locking

Simply add a column:

class AddLockVersionToProducts < ActiveRecord::Migration[8.0]
  def change
    add_column :products,
               :lock_version,
               :integer,
               default: 0,
               null: false
  end
end

That's it.

Rails automatically enables optimistic locking.

No additional configuration is required.

Example

Current row:

Admin A loads:

lock_version = 0

Admin B also loads:

lock_version = 0

Admin A updates:

product.price = 75000
product.save!

Database:

Notice:

lock_version

became

Now Admin B tries:

product.title = "iPhone Pro"

product.save!

Rails generates SQL similar to:

UPDATE products SET title = 'iPhone Pro', lock_version = 2 WHERE id = 1 AND lock_version = 0;

But the database contains:

lock_version = 1

Therefore:

0 rows updated

Rails raises:

ActiveRecord::StaleObjectError

Timeline

Admin A

Read Product

Version = 0

↓

Edit

↓

Save

Version becomes 1

----------------------------

Admin B

Read Product

Version = 0

↓

Edit

↓

Try Save

↓

StaleObjectError

What Happens Internally?

Suppose current version:

lock_version = 3

Rails updates using:

UPDATE products
SET
price = 100,
lock_version = 4
WHERE
id = 1
AND lock_version = 3;

If another transaction already updated it:

lock_version = 4

The WHERE condition fails.

No row is updated.

Rails knows someone modified the record.

Handling the Exception

Typical implementation:

begin
  product.update!(product_params)

rescue ActiveRecord::StaleObjectError

  flash[:alert] =
    "This product was updated by another user. Please reload and try again."

  redirect_to edit_product_path(product)
end

Instead of silently overwriting data, the user is informed.

Real Production Example 1

CMS Article Editing

Two editors modify the same article.

Without optimistic locking:

One editor overwrites another's work.

With optimistic locking:

Second editor sees:

"This article has changed since you opened it."

Real Production Example 2

Admin Dashboard

Inventory manager changes:

Stock = 15

Manager B changes:

Price = ₹500

Instead of losing one update,

Rails detects the conflict.

Real Production Example 3

User Profile

Editing profile:

Name
Bio
Address

Conflicts are rare.

Blocking users would hurt UX.

Optimistic locking is a better fit.

Advantages

✅ No waiting

✅ Better scalability

✅ Better user experience

✅ No database locks

✅ Great for read-heavy applications

Disadvantages

❌ Save may fail

❌ Users must retry

❌ Not suitable for financial systems

❌ Doesn't prevent concurrent reads

Optimistic vs Pessimistic Locking

Understanding Database Locking in Ruby on Rails: Types, Examples, and Best Practices

Yashika Vijayvargiya — Wed, 15 Jul 2026 08:39:39 +0000

Goal of this article: Build a strong foundation before learning pessimistic locking, optimistic locking, deadlocks, and isolation levels.

When I started working with production Rails applications, I realized that most database problems were not caused by missing indexes but by concurrent requests modifying the same data. Understanding locking completely changed the way I design payment, inventory, and booking systems.

What is a lock?

A lock is a mechanism used by PostgreSQL to protect data from being modified incorrectly by multiple transactions at the same time.

In simple words:

A lock tells other transactions: “Someone is currently working with this data. Wait your turn.”

Imagine two people editing the same Google Doc at the same moment. Without coordination, one person’s changes could overwrite the other’s. Databases use locks to prevent similar problems.

Why do databases need locking?

Suppose an e-commerce application has only 1 item left in inventory.

Without locking, both requests may read:

Both transactions believe the product is available and both place an order.

Result:

This is called a race condition.

What is a race condition?

A race condition occurs when the final result depends on the timing of concurrent operations.

Example

If two requests execute this code simultaneously, both may read the same inventory value before either update occurs.

This is the fundamental problem locking is designed to solve.

Transactions: The Foundation of Locking

Locks exist inside database transactions.

A transaction guarantees that all operations inside the block either:

Succeed together (COMMIT)
Fail together (ROLLBACK)

Locks are typically acquired when the transaction begins modifying or explicitly locking rows.

How PostgreSQL Handles Concurrent Transactions

Consider two transactions.

PostgreSQL automatically prevents both transactions from modifying the same row simultaneously.

MVCC: Why SELECT Usually Doesn’t Block

One of PostgreSQL’s most important features is MVCC (Multi-Version Concurrency Control).

Instead of blocking readers, PostgreSQL creates multiple versions of rows.

Example

Transaction A updates a product but has not committed yet.

At the same time, Transaction B runs:

Transaction B usually does not wait. It reads the previous committed version of the row.

This is why PostgreSQL can handle many readers efficiently.

Common Concurrency Problems

1. Lost Update

Very common

Problem: Two users overwrite each other’s changes.

Correct result should be: $30

Actual result: $50

2. Dirty Read

Usually prevented in PostgreSQL

Reading data that another transaction has modified but not committed.

PostgreSQL’s default isolation level (Read Committed) prevents this.

3. Non-repeatable Read

Possible in Read Committed

You read the same row twice and get different values because another transaction committed between the reads.

4. Phantom Read

Isolation-level issue

A query returns a different set of rows the second time it runs because another transaction inserted matching records.

Rails Example: Preventing Double Booking

Unsafe code:

Safe code using locking:

What changed?

generates:

This acquires a row-level lock so only one transaction can modify that event record at a time.

Visual Timeline

Important Insight: PostgreSQL Uses Multiple Lock Types

Many beginners think there is only one lock.

In reality PostgreSQL has:

We’ll explore these deeply in later parts of the series.

How to See Locks in Production

PostgreSQL exposes lock information through pg_locks.

A more useful query:

This helps identify which transaction is holding a lock and which transaction is waiting.

Key Takeaways

Locks prevent race conditions and data corruption.

Locks exist inside transactions.

PostgreSQL uses MVCC so readers usually do not block writers.

Row locks protect individual records.

Table locks protect entire tables.

FOR UPDATE is the foundation of pessimistic locking in Rails.

Most production concurrency bugs are caused by missing transactions or missing locks.

Interview Question

Why does PostgreSQL allow many SELECT queries to run without blocking each other?

Answer: PostgreSQL uses MVCC (Multi-Version Concurrency Control). Instead of blocking readers, it keeps multiple versions of rows so a SELECT query can read the last committed version while another transaction is updating the row. This greatly improves concurrency and is one of PostgreSQL’s biggest advantages.

Next Article in the Series

Pessimistic Locking in Rails

We will dive into lock, with_lock, FOR UPDATE, NOWAIT, SKIP LOCKED, and real production examples such as inventory reservation and payment processing.

Originally published at https://railswithyashika.hashnode.dev on July 13, 2026.

PostgreSQL Index Types Explained with Real Rails Examples

Yashika Vijayvargiya — Thu, 02 Jul 2026 08:00:26 +0000

Part-1 Understanding Indexes before learning Index Types

Now that we understand what indexes are and why they matter, let’s explore the different types of indexes available in PostgreSQL and when to use them in Rails applications.

1. Single Column Index

The simplest and most commonly used index.

Query

User.find_by(email: "john@example.com")

Migration

add_index :users, :email

SQL Generated

CREATE INDEX index_users_on_email ON users(email);

When to Use

Email lookups
SKU lookups
UUID searches
Foreign keys

Real Example

Product.find_by(sku: params[:sku])

Without an index, PostgreSQL scans the entire table.

With an index, PostgreSQL can jump directly to the matching row.

2. Unique Index

A unique index improves lookup performance while also preventing duplicate values.

Migration

add_index :users, :email, unique: true

What It Solves

Prevents:

john@example.com
john@example.com

Common Use Cases

Email addresses
Usernames
External IDs
API tokens

Rails Validation vs Database Constraint

Many developers write:

validates :email, uniqueness: true

This is not enough.

Always add a database unique index because validations can be bypassed during race conditions.

3. Composite (Multi-column) Index

Used when queries filter using multiple columns.

Query

Order.where(user_id: 1, status: "paid")

Migration

add_index :orders, [:user_id, :status]

Important Rule

Index order matters.

[:user_id, :status]

Works efficiently for:

WHERE user_id = 1

WHERE user_id = 1
AND status = 'paid'

But not for:

WHERE status = 'paid'

Real Example

In e-commerce:

Order.where(user_id: current_user.id, status: "completed")

4. Partial Index

Indexes only a subset of rows.

Migration

add_index :users, :email, where: "active = true"

Example Query

User.where(active: true)

Why Use It?

Suppose:

10 million users
9 million inactive 
1 million active

Creating an index only for active users makes the index:

Smaller
Faster
Less memory intensive

Common Uses

Soft deletes
Active records
Published content
Pending jobs

5. Index with Order

Optimizes sorting operations.

Query

Product.order(created_at: :desc)

Migration

add_index :products, :created_at, order: { created_at: :desc }

Benefits

Useful for:

Product.order(created_at: :desc).limit(20)

Common in:

News feeds
Activity logs
Product listings

6. GIN Index

GIN stands for Generalized Inverted Index.

Used for:

JSONB
Arrays
Full-text search

JSONB Example

add_index :users, :preferences, using: :gin

Query

WHERE preferences @> '{"theme":"dark"}'

Real Rails Example

User.where("preferences @> ?", { theme: "dark" }.to_json)

Without GIN indexes, JSONB searches become slow as data grows.

7. Full Text Search Index

PostgreSQL can act as a search engine.

Migration

add_index :articles, "to_tsvector('english', content)", using: :gin, name: "index_articles_on_content_search"

Query

SELECT * FROM articles WHERE to_tsvector('english', content) @@ plainto_tsquery('rails indexing');

Useful For

Blogs
Documentation sites
Product search
Knowledge bases

8. Concurrent Index

One of the most important production techniques.

Problem

Running:

add_index :users, :email

on a huge table can lock writes.

Solution

class AddIndexToUsersEmail < ActiveRecord::Migration[8.0] 
  disable_ddl_transaction!
  def change 
    add_index :users, :email, algorithm: :concurrently 
  end 
end

Benefits

No downtime
No table lock
Safe for production

Real World

Never add indexes to large production tables without considering concurrent creation.

9. Expression Index

Indexes a calculated value instead of a column.

Query

User.where("LOWER(email) = ?", email.downcase)

Migration

add_index :users, "LOWER(email)", name: "index_users_on_lower_email"

Benefits

Supports fast:

Case-insensitive searches
Date transformations
String manipulations

10. Covering Index (INCLUDE)

Introduced to reduce table lookups.

Migration

add_index :orders, :user_id, include: [:status, :total]

Why Useful?

Query:

Order.select(:status, :total) .where(user_id: current_user.id)

PostgreSQL can answer directly from the index.

This is called an Index Only Scan.

Benefits

Fewer disk reads
Faster queries

11. BRIN Index

BRIN stands for Block Range Index.

Designed for huge tables.

Migration

add_index :events, :created_at, using: :brin

Best For

Logs
Analytics data
Audit records
Time-series events

Why?

Instead of storing every value, BRIN stores summaries for ranges of pages.

Result:

Extremely small indexes
Very low maintenance overhead

Example

100 million events

A BRIN index may be only a few MBs compared to hundreds of MBs for a B-tree index.

12. Hash Index

Optimized for equality lookups.

Migration

add_index :users, :email, using: :hash

Query

WHERE email = 'john@example.com'

Limitation

Does not support:

<
>
BETWEEN
ORDER BY

Because B-tree indexes support more operations, Hash indexes are rarely used.

Which Index Should You Choose?

Final Thoughts

Indexes are not about adding them everywhere.

A good database engineer first identifies:

Slow queries
Query patterns
Filter columns
Sort columns
Join columns

Then chooses the index that matches the workload.

Always verify improvements using:

EXPLAIN ANALYZE

and remember that every index speeds up reads but adds overhead to writes. The best indexing strategy is the one that balances both.

Concurrent Indexes: https://railswithyashika.hashnode.dev/postgresql-concurrent-indexes-in-rails-avoiding-downtime-in-production

Originally published at https://railswithyashika.hashnode.dev on July 1, 2026.

Understanding Indexes Before Learning Index Types

Yashika Vijayvargiya — Wed, 01 Jul 2026 07:59:39 +0000

Before diving into different types of indexes, let’s understand why indexes are needed.

Imagine a library with 100,000 books.

If someone asks for a book named “Clean Code”, there are two ways to find it:

Without an Index

You start from the first shelf and check every book one by one until you find the required book.

This approach is similar to a Sequential Scan in PostgreSQL.

SELECT * FROM books
WHERE title = 'Clean Code';

PostgreSQL may need to scan every row in the table to find matching records.

As the table grows from thousands to millions of rows, query performance degrades significantly.

With an Index

Now imagine the library has a catalog that stores:

Clean Code → Shelf A12
The Pragmatic Programmer → Shelf B03
Refactoring → Shelf C08

Instead of checking every book, you first look at the catalog and immediately jump to the correct shelf.

This catalog is similar to a database index.

An index stores selected column values in a structure that allows PostgreSQL to locate rows much faster than scanning the entire table.

Why Not Index Every Column?

A common beginner question is:

If indexes make queries faster, why not create indexes everywhere?

Indexes improve read performance, but they come with a cost.

Whenever data changes, PostgreSQL must update both:

The table data
Every related index

For example:

User.create!(email: "john@example.com")

If the users table has 10 indexes, PostgreSQL must update all 10 indexes during the insert operation.

This means:

More storage usage
Slower INSERT operations
Slower UPDATE operations
Slower DELETE operations

Because of this trade-off, indexes should be added only for queries that are frequently executed and benefit from faster lookups.

How PostgreSQL Uses an Index

Suppose we have:

add_index :users, :email

And run:

SELECT *
FROM users
WHERE email = 'john@example.com';

Without an index:

Seq Scan on users

With an index:

Index Scan using index_users_on_email

The database can jump directly to matching records instead of examining every row.

A Simple Rule

Create an index when a column is frequently used in:

WHERE clauses
JOIN conditions
ORDER BY clauses
GROUP BY clauses

Examples:

User.find_by(email: email)

Order.where(user_id: current_user.id)

Product.order(created_at: :desc)

Lead.where(status: "active")

These are strong candidates for indexing.

How to Verify an Index Is Being Used

Never assume PostgreSQL is using your index.

Use:

EXPLAIN ANALYZE
SELECT *
FROM users
WHERE email = 'john@example.com';

Look for:

Index Scan

instead of:

Seq Scan

This confirms PostgreSQL is benefiting from the index.

Understanding these fundamentals makes it much easier to choose the right indexing strategy, whether it is a simple B-Tree index, a composite index, a GIN index for JSONB data, or a BRIN index for massive datasets.

PostgreSQL Concurrent Indexes in Rails: Avoiding Downtime in Production

Yashika Vijayvargiya — Thu, 18 Jun 2026 07:02:08 +0000

When working with large production databases, adding an index may seem like a simple migration.

However, on tables with millions of records, a regular index creation can lock writes and impact your application's availability.

In this article, we’ll explore what concurrent indexes are, why they matter, and how to safely create them in Ruby on Rails.

The Problem with Normal Index Creation

Suppose we have a large users table with millions of records.

A typical Rails migration might look like:

add_index :users, :email

Behind the scenes, PostgreSQL executes:

CREATE INDEX index_users_on_email ON users(email);

While PostgreSQL builds the index, it acquires locks on the table.

On large tables this can lead to:

Slower API responses
Blocked INSERT operations
Blocked UPDATE operations
Blocked DELETE operations
Potential downtime during deployment

For example:

users table = 50 million rows

Creating an index on such a table can take several minutes, and during that time write operations may be affected.

The Solution: Concurrent Indexes

PostgreSQL provides a safer alternative:

CREATE INDEX CONCURRENTLY

This allows PostgreSQL to build the index while minimizing disruption to ongoing database operations.

In Rails, this can be achieved using:

class AddIndexToUsersEmail < ActiveRecord::Migration[7.1] disable_ddl_transaction!
  def change
    add_index :users, :email, algorithm: :concurrently
  end 
end

How Concurrent Indexes Work

Normal Index Creation

Lock table
↓
Scan rows
↓
Build index
↓
Unlock table

Concurrent Index Creation

Scan table
↓
Build index in background
↓
Track ongoing changes
↓
Finalize index

The application continues to serve requests while the index is being created.

Why disable_ddl_transaction! Is Required

A common mistake is forgetting:

disable_ddl_transaction!

PostgreSQL does not allow:

CREATE INDEX CONCURRENTLY

inside a transaction.

Rails wraps migrations in a transaction by default, so we must disable it before creating concurrent indexes.

Without it, Rails raises an error during migration.

Complete Rails Example

class AddIndexToBookingsUserId < ActiveRecord::Migration[7.1] 
disable_ddl_transaction!

  def change

    add_index :bookings, :user_id, algorithm: :concurrently

  end

end

When Should You Use Concurrent Indexes?

Concurrent indexes are recommended when:

The table contains millions of rows
The application is live
Downtime is unacceptable
The database receives frequent writes

Typical examples include:

Users table
Orders table
Bookings table
Transactions table

When Is a Regular Index Fine?

For smaller tables and development environments:

add_index :users, :email

is usually sufficient.

Since concurrent index creation performs additional work, it is generally slower than normal index creation.

Real Production Scenario

Imagine a booking platform with:

bookings table = 100 million rows

A slow query is identified:

Booking.where(hotel_id: params[:hotel_id])

The obvious fix is:

add_index :bookings, :hotel_id

Running a normal index creation during business hours could affect booking APIs.

Instead, deploying:

add_index :bookings, :hotel_id, algorithm: :concurrently

allows the application to remain available while the index is built.

Checking Existing Indexes

To view indexes in PostgreSQL:

SELECT * FROM pg_indexes WHERE tablename = 'users';

You can also use:

\d users

from the PostgreSQL console.

Interview Question:

Why do we use concurrent indexes in Rails?

A good answer is:

Normal index creation can lock writes on large tables and impact application availability. PostgreSQL provides CREATE INDEX CONCURRENTLY to build indexes with minimal locking. In Rails, this is achieved using algorithm: :concurrently along with disable_ddl_transaction!. Although concurrent indexes take longer to build, they are much safer for production systems with large datasets and high traffic

Conclusion

Creating indexes is one of the easiest ways to improve query performance, but doing it incorrectly in production can introduce downtime.

Whenever you’re adding indexes to large, high-traffic tables, consider using concurrent indexes. The migration may take longer to complete, but your users won’t experience disruptions while it runs.

A few extra minutes during deployment are often worth avoiding minutes of downtime in production.

Rails Performance Optimization: Fixing N+1 Queries with includes, preload, and eager_load

Yashika Vijayvargiya — Wed, 10 Jun 2026 10:22:00 +0000

Originally published on Hashnode:
https://railswithyashika.hashnode.dev/rails-performance-n-plus-one-queries

When working with associations in Rails, it's easy to accidentally introduce performance issues. One of the most common problems is the N+1 Query Problem.

In this article, we'll understand what N+1 queries are, how they impact performance, and the differences between includes, preload, and eager_load.

What is an N+1 Query?

Suppose we have the following models:

class User < ApplicationRecord
  has_many :posts
end

class Post < ApplicationRecord
  belongs_to :user
end

We fetch all posts:

@posts = Post.all

And display the author's name:

<% @posts.each do |post| %>
  <%= post.title %>
  <%= post.user.name %>
<% end %>

Queries Generated
Rails first loads all posts:

SELECT "posts".*
FROM "posts";

Then for each post:


- SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT
1; 
- SELECT "users".* FROM "users" WHERE "users"."id" = 2 LIMIT 1; 
- SELECT "users".* FROM "users" WHERE "users"."id" = 3 LIMIT 1;

If there are 100 posts, Rails executes:

1 query for posts
100 queries for users

Total: 101 queries

This is called the N+1 query problem.

Why is it a Problem?

As the amount of data grows:

Database load increases
Response times become slower
More memory and CPU are consumed
Application scalability decreases A page that works fine with 10 records can become painfully slow with 1,000 records.

Fixing N+1 Queries with includes

The simplest solution is:

@posts = Post.includes(:user)

Rails executes:

SELECT "posts".*
FROM "posts";

Then:

SELECT "users".*
FROM "users"
WHERE "users"."id" IN (1, 2, 3, 4, 5);

Only 2 queries are executed regardless of how many posts exist.

Understanding includes

Most Rails developers use includes, but many don't know how it actually works.

Example

Post.includes(:user)

Generated Queries

SELECT "posts".*
FROM "posts";

SELECT "users".*
FROM "users"
WHERE "users"."id" IN (1,2,3,4,5);

Rails loads records using separate queries and associates them in memory.

When Rails Converts includes into JOIN

Consider:

Post.includes(:user)
    .where(users: { active: true })

Now Rails generates:

SELECT
  posts.id,
  posts.title,
  users.id,
  users.name
FROM posts
LEFT OUTER JOIN users
ON users.id = posts.user_id
WHERE users.active = true;

Because the query references the users table, Rails automatically switches to a JOIN strategy.

Understanding preload

preload always loads associations using separate queries.

Example

Post.preload(:user)

Queries Generated

SELECT "posts".*
FROM "posts";

SELECT "users".*
FROM "users"
WHERE "users"."id" IN (1,2,3,4,5);

Notice that the generated SQL is similar to includes.
Key Difference
Unlike includes, preload never converts into a JOIN.
This will fail:

Post.preload(:user)
    .where(users: { active: true })

Error:

missing FROM-clause entry for table "users"

Since no JOIN is generated, Rails cannot reference columns from the users table.

When to Use preload

Use preload when:

You know separate queries are preferred.
You only want to avoid N+1 queries.
You don't need conditions on associated tables.

Understanding eager_load

eager_load always uses a LEFT OUTER JOIN.

Example

Post.eager_load(:user)

Query Generated

SELECT
  posts.id,
  posts.title,
  posts.user_id,
  users.id,
  users.name
FROM posts
LEFT OUTER JOIN users
ON users.id = posts.user_id;

Everything is fetched in a single query.

Filtering on Associated Tables

Post.eager_load(:user)
    .where(users: { active: true })

Generated SQL:

SELECT
  "posts".*,
  "users".*
FROM "posts"
LEFT OUTER JOIN "users"
ON "users"."id" = "posts"."user_id"
WHERE "users"."active" = TRUE;

This works because the users table is already joined.

includes vs preload vs eager_load

Method	Queries	Uses JOIN	Can Filter Associated Table
includes	Usually 2	Sometimes	Yes
preload	2	No	No
eager_load	1	Always	Yes

Which One Should You Use?

*Use includes
*
Post.includes(:user)

Default choice for most cases.

Use preload

Post.preload(:user)

When you explicitly want separate queries and no JOIN.

Use eager_load

Post.eager_load(:user)

When filtering, ordering, or searching on associated tables.

Detecting N+1 Queries

A few ways to identify N+1 problems:

Check Development Logs

Look for repeated queries being executed inside loops.

Use Bullet Gem

Add:

gem 'bullet'

Bullet will notify you whenever an N+1 query is detected.

Use Monitoring Tools

Scout APM
New Relic
Datadog

These tools help identify slow database queries in production.

Conclusion

N+1 queries are one of the most common performance issues in Rails applications.

Understanding the differences between includes, preload, and eager_load can help you write more efficient database queries and build scalable applications.

As a rule of thumb:

Start with includes
Use preload when you want guaranteed separate queries
Use eager_load when you need JOIN-based filtering

A few minutes spent analyzing your SQL queries can save hours of performance troubleshooting later.

DEV Community: Yashika Vijayvargiya

What Is Vibe Coding? Benefits, Risks, and Best Practices for AI-Assisted Development

Introduction

What Is Vibe Coding?

Traditional Coding vs. Vibe Coding

Vibe Coding

An Example

Why Is Vibe Coding Becoming Popular?

Conclusion

The Rails Bug That Disappeared After a Server Restart — Until I Found the Mutation

Project Overview

Bug Fix or Performance Improvement

The First Clue: Restarting the Server "Fixed" It

Following the Menu Construction

The Problem Wasn't the Value

Why It Looked Random

Then I Found the GitHub Issue

Code

The Fix: Give add Its Own Copy

Why dup Fixed It

Why I Used super

My Improvements

The Debugging Lesson: Don't Trust "Random"

The Dependency Was Part of the Application

The Fix Was Tiny. The Investigation Wasn't.

What This Taught Me About Ruby

The Bigger Lesson

Final Takeaway

When a String Assumption Broke Newsletter Tag Filtering in Ruby

When a Single Type Assumption Broke Newsletter Tag Filtering in Ruby

"Cannot Click tags on Newsletter"

What Is Ponytail? A Beginner’s Guide to the AI Coding Companion Everyone Is Talking About

Introduction

The Biggest Misconception About Ponytail

Understanding the AI Coding Ecosystem

VS Code

AI Model

AI Coding Agent

Ponytail

An Analogy

What Problem Does Ponytail Solve?

What Ponytail Is NOT

Can Ponytail Work Without an AI?

Does Ponytail Replace Cursor?

Does Ponytail Replace Claude?

Does Ponytail Reduce Token Usage?

Is Ponytail Free?

When Should You Use Ponytail?

When Should You Avoid It?

A Rails Example

Frequently Asked Questions

Is Ponytail another AI?

Can Ponytail write code?

Does Ponytail work without Claude or another AI model?

Does Ponytail replace Cursor?

Does Ponytail replace VS Code?

Is Ponytail a code editor?

Does Ponytail guarantee better code?

Final Thoughts

Part 3: Optimistic Locking in Rails – Preventing Lost Updates Without Blocking Users

Introduction

Why Do We Need Optimistic Locking?

Understanding Database Locking in Ruby on Rails: Types, Examples, and Best Practices

What is a lock?

Why do databases need locking?

What is a race condition?

Example

Transactions: The Foundation of Locking

How PostgreSQL Handles Concurrent Transactions

MVCC: Why SELECT Usually Doesn’t Block

Example

Common Concurrency Problems

1. Lost Update

2. Dirty Read

3. Non-repeatable Read

4. Phantom Read

Rails Example: Preventing Double Booking

Visual Timeline

Important Insight: PostgreSQL Uses Multiple Lock Types

How to See Locks in Production

The Fix: Give `add` Its Own Copy

Why `dup` Fixed It

Why I Used `super`