I am not a professional. I have only ever had one job in this realm, it was contract, it was short. I learned that I have no sense of urgency, which I can see. So take what I say with a byte source code, but sometimes, most times, I find myself happy that I know what I do.

With the rise of all these wonderful AI tools available, creating what you want is now available to everyone, everywhere. You do not need to know anything about code or the language. You do not need to know all the technical aspects of front end, back end, servers, authentication, git or databases. You can simple ask for it, and you have it.

If I were to explain what a Vibe Coder is, that is the definition I would give. Some one who does not necessarily know the technical aspects, but loves the back and forth with the agent to create the product. A Vibe Engineer does know some of the technical side, but still loves the back and forth with the agent.

The rise of all these amazing tools has really stirred things up. They have allowed many of those talented people being laid off to quickly create their version of a fix to a problem they want to address. It has allowed those with no technical experience at all to do exactly the same thing. How do you put a value to that?

This article is not going to go into all that. I have no idea how to even get it all straight in my head. I would like to tell you of my experience in hopes that it helps you better understand the difference between a Vibe Coder and a Vibe Engineer.

The Feature

This morning while working on the portfolio, specifically the blog, I decided to go ahead and add the profile feature to the site. I have known this feature would be handy in various parts of the app like the author for the blog. Just seems smart. In preparing for this I thought this would be a good idea to test with AI. I initially started with Gem, because honestly I wondered just how it would approach this, but I need to wait for my usage rate to catch up. There has been a lot of back and forth in conversations about the studio.

That being the case I opened up vsCode, knowing that I had a bit to play with there, and here is what happened, which shocked me a little. The ask agent is using Claude sonnet-4 for this task. To set the stage, the project is open in the IDE and I am using Kilo Code. Great little tool that includes several different agents for different tasks. For this one I used the ask agent. So this was just a general inquiry on the process. It has access to the entire code base.

Question:
I need to add a milk admin profile. It would include info like first name, last name, bio, social urls and the avatar. What is that process.

Sonnet-4 Thinking:
The user is asking about adding a milk admin profile that would include info like first name, last name, bio, social URLs, and avatar. They want to know what the process is for this.

Looking at the file structure, I can see there's already a milk admin system in place:

app/models/milk_admin.rb
app/controllers/milk_admin_controller.rb
Various milk_admin views and controllers

I should examine the current milk_admin model and related files to understand what's already there and what needs to be added or modified to support the profile information they want.

This seems like a straightforward analysis task where I need to:

Look at the current MilkAdmin model
Check the existing controller and views
Analyze what's already there vs what needs to be added
Explain the process for adding the profile functionality

Let me start by reading the milk_admin model to see what fields already exist.

Kilo Said:
I'll help you understand the process for adding a milk admin profile with the fields you mentioned. Let me first examine the current milk admin implementation to see what's already in place.

Kilo Code does a search and reads the devise migration file for milk_admin and the milk_admin controller.

Kilo Response:
Based on my analysis of your Rails application, here's the complete process for adding a milk admin profile with first name, last name, bio, social URLs, and avatar:

Current State Analysis

Your MilkAdmin model currently only has basic Devise authentication fields. The database table was created with the standard Devise fields (email, encrypted_password, etc.) and doesn't include profile information.

Process to Add Milk Admin Profile

1. Database Migration

You'll need to create a migration to add the new profile fields:

# Generate migration
rails generate migration AddProfileFieldsToMilkAdmins first_name:string last_name:string bio:text social_urls:text

# The migration will look like:
class AddProfileFieldsToMilkAdmins < ActiveRecord::Migration[8.0]
  def change
    add_column :milk_admins, :first_name, :string
    add_column :milk_admins, :last_name, :string
    add_column :milk_admins, :bio, :text
    add_column :milk_admins, :social_urls, :text # JSON field for multiple social URLs
  end
end

2. Avatar Setup with Active Storage

Since Rails 8 includes Active Storage, you'll add avatar support:

# In app/models/milk_admin.rb
class MilkAdmin < ApplicationRecord
  devise :database_authenticatable, :recoverable, :rememberable, :validatable

  has_many :blogs
  has_one_attached :avatar

  # Validations
  validates :first_name, :last_name, presence: true, if: :profile_complete?
  validates :avatar, content_type: ['image/png', 'image/jpg', 'image/jpeg', 'image/gif']

  # Helper methods
  def full_name
    "#{first_name} #{last_name}".strip
  end

  def social_links
    return {} if social_urls.blank?
    JSON.parse(social_urls)
  rescue JSON::ParserError
    {}
  end

  private

  def profile_complete?
    # Define when profile validation should apply
    first_name.present? || last_name.present?
  end
end

3. Controller Updates

Update your MilkAdminController to handle profile management:

class MilkAdminController < ApplicationController
  before_action :authenticate_milk_admin!

  def dashboard
    @milk_admin = current_milk_admin
    @contacts = Contact.all
  end

  def profile
    @milk_admin = current_milk_admin
  end

  def update_profile
    @milk_admin = current_milk_admin

    if @milk_admin.update(profile_params)
      redirect_to milk_admin_profile_path, notice: 'Profile updated successfully.'
    else
      render :profile
    end
  end

  private

  def profile_params
    params.require(:milk_admin).permit(:first_name, :last_name, :bio, :social_urls, :avatar)
  end
end

4. Routes Configuration

Add routes for profile management in config/routes.rb:

# Add to existing milk_admin routes
get 'milk_admin/profile', to: 'milk_admin#profile'
patch 'milk_admin/profile', to: 'milk_admin#update_profile'

5. Profile Views

Create profile management views:

app/views/milk_admin/profile.html.erb:

<% content_for :title, "Admin Profile" %>

<div class="container mx-auto px-4 py-8">
  <h1 class="text-3xl font-bold mb-8">Admin Profile</h1>

  <%= form_with model: @milk_admin, url: milk_admin_profile_path, method: :patch, local: true do |form| %>
    <% if @milk_admin.errors.any? %>
      <div class="bg-red-100 border border-red-400 text-red-700 px-4 py-3 rounded mb-4">
        <ul>
          <% @milk_admin.errors.full_messages.each do |message| %>
            <li><%= message %></li>
          <% end %>
        </ul>
      </div>
    <% end %>

    <div class="grid grid-cols-1 md:grid-cols-2 gap-6">
      <div>
        <%= form.label :first_name, class: "block text-sm font-medium text-gray-700" %>
        <%= form.text_field :first_name, class: "mt-1 block w-full rounded-md border-gray-300 shadow-sm" %>
      </div>

      <div>
        <%= form.label :last_name, class: "block text-sm font-medium text-gray-700" %>
        <%= form.text_field :last_name, class: "mt-1 block w-full rounded-md border-gray-300 shadow-sm" %>
      </div>
    </div>

    <div class="mt-6">
      <%= form.label :bio, class: "block text-sm font-medium text-gray-700" %>
      <%= form.text_area :bio, rows: 4, class: "mt-1 block w-full rounded-md border-gray-300 shadow-sm" %>
    </div>

    <div class="mt-6">
      <%= form.label :social_urls, "Social URLs (JSON format)", class: "block text-sm font-medium text-gray-700" %>
      <%= form.text_area :social_urls, rows: 3, placeholder: '{"twitter": "https://twitter.com/username", "linkedin": "https://linkedin.com/in/username"}', class: "mt-1 block w-full rounded-md border-gray-300 shadow-sm" %>
    </div>

    <div class="mt-6">
      <%= form.label :avatar, class: "block text-sm font-medium text-gray-700" %>
      <%= form.file_field :avatar, class: "mt-1 block w-full" %>
      <% if @milk_admin.avatar.attached? %>
        <div class="mt-2">
          <%= image_tag @milk_admin.avatar, class: "h-20 w-20 rounded-full object-cover" %>
        </div>
      <% end %>
    </div>

    <div class="mt-8">
      <%= form.submit "Update Profile", class: "bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded" %>
    </div>
  <% end %>
</div>

6. Navigation Updates

Update your milk admin navigation to include the profile link in your layout or sidebar.

7. Migration Execution

Run the migration:

rails db:migrate

Process Summary

The implementation involves:

Creating a database migration for new profile fields
Updating the MilkAdmin model with avatar attachment and validations
Adding profile management actions to MilkAdminController
Creating routes for profile management
Building profile management views
Running the migration to apply database changes

This will give you a complete milk admin profile system with all the requested fields, proper file upload handling for avatars, and a user-friendly interface for managing profile information.

Following Up

Now there was a lot I liked about this. The helper actions in the model to create a full name and handle a empty social links object are pretty nice additions. In general I agreed with everything there. It is more or less how I would do it, except for modifying the devise model. I would rather keep that strictly authentication. Also, a few actions in the model are ok, this feels ok, but much more and I would consider another solution. A service or separate helpers. Knowing this, I asked a follow up.

Question:
You recommended adding to the devise model. Is that rails convention? I know there are various ways to handle this. What is "proper"?

Sonnet-4 Thinking:
The user is asking about Rails conventions for handling profile information with Devise models. They want to know if adding profile fields directly to the Devise model is "proper" or if there are better approaches. This is a great question about Rails architecture patterns.

Let me think about the different approaches:

Adding fields directly to the Devise model (what I suggested)
- Pros: Simple, straightforward
- Cons: Can bloat the authentication model, mixes concerns
Separate Profile model with associations
- Pros: Better separation of concerns, follows Single Responsibility Principle
- Cons: More complex queries, additional joins
STI (Single Table Inheritance) or polymorphic associations
- More complex patterns for specific use cases

The Rails community generally favors the separation of concerns approach, especially for larger applications. A separate Profile model is often considered more "proper" because it:

Keeps the authentication model focused on authentication concerns
Makes the profile information more flexible and extensible
Follows the Single Responsibility Principle
Makes testing easier
Allows for different types of profiles if needed in the future

I should provide a comprehensive answer covering the different approaches and their trade-offs, with emphasis on the separate model approach as the more conventional/proper Rails way

Kilo Response:
You're absolutely right to question this approach! Adding profile fields directly to the Devise model is not the Rails convention or considered "proper" architecture. Let me explain the better approaches:

Rails Conventions for Profile Data

1. Separate Profile Model (Recommended)

The Rails convention is to keep authentication models focused on authentication concerns and create a separate model for profile data:

# app/models/milk_admin_profile.rb
class MilkAdminProfile < ApplicationRecord
  belongs_to :milk_admin
  has_one_attached :avatar

  validates :first_name, :last_name, presence: true
  validates :avatar, content_type: ['image/png', 'image/jpg', 'image/jpeg', 'image/gif']

  def full_name
    "#{first_name} #{last_name}".strip
  end

  def social_links
    return {} if social_urls.blank?
    JSON.parse(social_urls)
  rescue JSON::ParserError
    {}
  end
end

# app/models/milk_admin.rb (keep clean)
class MilkAdmin < ApplicationRecord
  devise :database_authenticatable, :recoverable, :rememberable, :validatable

  has_many :blogs
  has_one :milk_admin_profile, dependent: :destroy

  # Delegate profile methods for convenience
  delegate :full_name, :avatar, :bio, :social_links, to: :milk_admin_profile, allow_nil: true

  def build_profile_if_needed
    build_milk_admin_profile unless milk_admin_profile
  end
end

Migration:

rails generate model MilkAdminProfile milk_admin:references first_name:string last_name:string bio:text social_urls:text

2. Alternative: Generic Profile with Polymorphic Association

For more flexibility if you might have other user types:

# app/models/profile.rb
class Profile < ApplicationRecord
  belongs_to :profileable, polymorphic: true
  has_one_attached :avatar
  # ... validations and methods
end

# app/models/milk_admin.rb
class MilkAdmin < ApplicationRecord
  devise :database_authenticatable, :recoverable, :rememberable, :validatable

  has_many :blogs
  has_one :profile, as: :profileable, dependent: :destroy

  delegate :full_name, :avatar, :bio, to: :profile, allow_nil: true
end

Why Separate Models Are "Proper"

Single Responsibility Principle

MilkAdmin handles authentication/authorization
MilkAdminProfile handles profile information

Maintainability

Easier to test each concern separately
Profile logic doesn't clutter the authentication model
Cleaner model files

Flexibility

Profile can be optional without affecting authentication
Easy to extend profile features without touching auth code
Better for different profile types in the future

Performance

Only load profile data when needed
Authentication queries stay lean

Updated Controller Approach

class MilkAdminController < ApplicationController
  before_action :authenticate_milk_admin!
  before_action :ensure_profile, only: [:profile, :update_profile]

  def profile
    @profile = current_milk_admin.milk_admin_profile
  end

  def update_profile
    @profile = current_milk_admin.milk_admin_profile

    if @profile.update(profile_params)
      redirect_to milk_admin_profile_path, notice: 'Profile updated successfully.'
    else
      render :profile
    end
  end

  private

  def ensure_profile
    current_milk_admin.build_profile_if_needed
  end

  def profile_params
    params.require(:milk_admin_profile).permit(:first_name, :last_name, :bio, :social_urls, :avatar)
  end
end

Rails Community Consensus

The separate model approach is widely considered best practice because:

DHH and Rails core team advocate for this pattern
Most popular gems (like public_activity, acts_as_commentable) use separate models
Rails guides demonstrate this pattern for user profiles
Major Rails applications (GitHub, Shopify, etc.) use this approach

The direct approach I initially suggested works but violates Rails conventions around separation of concerns and model responsibility boundaries.

Conclusion

This article includes examples of what simple prompting can provide. If I had taken the time to really layout what I needed, I would have gotten a different, better response than either of these, on the first go. What I got was not half bad though and very workable.

It also includes, and was the point for writing this article, evidence that AI is just a tool in your tool box. You are still the driver. You are still in control. You are the one to make decisions and implement those decisions.

Rogue Media Lab

Vibe Engineering

The Feature

Following Up

Conclusion