DEV Community: Marvin Ahlgrimm

When AI Moved Into My Editor: Faster… and Weirdly Slower

Marvin Ahlgrimm — Fri, 03 Oct 2025 11:28:29 +0000

The first time I asked an AI to write a small snippet of code, I was flabbergasted. It worked—instantly. It saved me the usual search-and-compare detour, and that alone felt worth paying for.

This was back then when no Thinking models existed. But it was an immediate argument for a subscription for XYZ AI (no ad here 😬 just think of one of the many options).

From there, I went into a long phase of copy & paste: throw code at an LLM, ask it to analyze or rewrite, and stitch the result back in. It kind of worked. When reasoning models arrived, my confidence went up: wait a minute, wait three—freshly baked code appears. In Rails, that meant small adjustments and I was done. In Marten, I had to correct more, which made sense — newer framework, less model knowledge.

Then the next big thing happened: tools that could search the internet. (What kind of technological progress! The internet wasn't a trend that is going away anytime soon 🤯) I started asking the LLM to read Marten's docs first and then implement feature XYZ. Suddenly, I could use LLMs for Marten, too. Great! "No need for using my brain anymore," right? At least it felt like that — because the handler fixes took less time than before.

Except I still had to pour context into the model and explain compile errors or edge cases. It became a kind of pair programming where I asked for features and an inexperienced junior picked random things from the internet, threw them at me, and hoped it worked. Sometimes it did. Sometimes it didn't.

Next wave: MCP and CLI tools like Claude or Codex inside my editor. Now the LLM could read my files and pick up the context I’d been manually narrating. I could spin up the CLI, spell out a feature request, and it worked most of the time. When it didn't, I'd say what didn't work. And then again. And again. Also: I won't give an LLM permission to change my files without acknowledging its work first—so I kept the loop manual. That created a very familiar pattern: write the prompt → wait for results → correct the results → fine-tune. And yes, I sometimes forgot the CLI was sitting there waiting for my response, dragging on the cycle.

Recently it clicked that this can slow me down. The waiting, the corrections, the context coaching — it adds up. In Rails, this is fine for smaller features. In Marten, I still hit compile errors or subtle misuses that need careful guidance. And I don't want a bot silently editing my codebase while I lose track of what changed.

My trust issues mostly come from one experience: a bigger chunk of AI-generated code that "magically" worked — until I needed a behavior change. That request overstrained the model and it started producing incorrect fixes. Because I hadn't reviewed the initial output deeply, adapting it took longer than if I had either built it myself or reviewed it properly to make it adaptable from the start. That one was on me.

In my little delusion, I even thought AI could basically ship whole projects for me while I skimmed and sprinkled adjustments. Boy was I wrong. I kicked off a bunch of dear side ideas I didn’t have time for, assuming the model would carry them over the finish line. Instead I ended up with a constellation of half-baked repos — and a clear lesson: AI accelerates momentum you already have; it doesn't create it. It won't do the product thinking, the trade-offs, or the patient grind.

So I'm stepping on the brake a bit. AI is here to stay and it's impressive, but the "AI will take our jobs" hype is exaggerated. It can absolutely solve things — but it's not delivering the consistent quality of an experienced dev. What it does do well is guide you toward a correct path faster.

What I’m doing now (so it helps more than it hurts)

Start with a requirements doc. I write a short spec (goal, constraints, edge cases, acceptance criteria), manually refine it, and treat it as the single source of truth.
- If I have absolutily no idea what I'm dealing with I'm starting a deep research
Use AI for planning, code mostly by hand. From the spec, I ask the LLM “what’s next / risky / missing,” but I hand code most parts and only offload small snippets or algorithms.
Read the docs—with citations. With search enabled, I ask the LLM to analyze the documentation of some library/tool, read the answer and check the sources.
Scope it right. AI for scaffolding, glue, migrations, rote transforms; humans for domain logic and novel framework patterns.
Front-load constraints. State invariants, interfaces, and edge cases up front to avoid rework.
One prompt → one cohesive diff. Treat AI output like a junior’s PR; keep changes small and reviewable.
Tests first (or alongside). Have the model draft intent-revealing tests; they surface mismatches early.
Document the "why." Ask for a 5-line design rationale to stash next to the change.
Time-box retries. If the LLM had its third faulty try, I take over the tricky bit.
Never skip the review—even when it "just works." That’s where hidden debt sneaks in.

Conclusion

AI won’t take over anytime soon, but it will help to achieve our goals. Used well, it augments your knowledge and accelerates the momentum you already have.

Treat it like Little Helper to Gyro: exceptionally clever, creative, and efficient—but still a helper. Keep your guard up: review the final output, require citations when you rely on docs, and let tests plus a short requirements doc be the gatekeepers. That’s how AI helps more than it hurts.

Embrace the Default: Let HTML and CSS Do the Work

Marvin Ahlgrimm — Sat, 28 Jun 2025 10:55:42 +0000

We often reach for JavaScript too quickly.
But modern HTML and CSS can already do more than you think

Maybe you know the situation. You want to provide some intuitive user interface where the user has a nice UI with huge elements, like cards, that are easy to click on. You want to make sure that the user can easily see which element is currently selected. So you reach for JavaScript and add some event listeners to change the style of the element when it is clicked.

In my case the user had to select which payment type they wanted to use. So I had a list of payment types, each represented by a nice little card. The "cash" option should be selected by default and the user could click on a card to select it. The selected card should have a different background color to nicely indicate which payment type was selected and give the user a visual feedback. Because the cards don’t contribute to the form there has to be a way to tell the form which card was selected.

Being lazy my first thought was "I need to create another Stimulus Controller to handle the click and fill a hidden input with the selected payment type. Ugh..".

But then I thought about it for a second and realized that I could do this with just HTML and CSS.

The Solution: Radio Buttons

I don't know why, but radio buttons are not in my standard repertoire of UI elements. I always think of them as something old school, something that is used in the 90s. But they are actually a great way to implement the functionality I needed.

Radio buttons are a form element that allows the user to select one option from a set. They are perfect for this use case because they inherently support the concept of a "selected" state. When you click on a radio button, it automatically updates the state of the form, and you can style the selected button differently using CSS.

So I created a list of "hidden" radio buttons and labels that reference them via the for attribute. The labels are styled as cards, and when the user clicks on a card, the corresponding radio button is selected. The selected radio button can then be styled differently using CSS.

<div class="row">
    <% payment_methods = [
        [t('payment.cash'),        "cash",            "bi-cash"],
        [t('payment.creditCard'),  "credit_card",     "bi-credit-card"],
        [t('payment.online'),      "payment_pending", "bi-credit-card"],
        ] %>

    <% payment_methods.each do |label, value, icon| %>
        <div class="col-4">
            <%= f.radio_button :payment_kind,
                                value,
                                id: "payment_kind_#{value}",
                                class: "radio-card-input" %>

            <label for="payment_kind_<%= value %>"
                    class="card radio-card">
                <i class="bi <%= icon %>"></i><br>
                <strong><%= label %></strong>
            </label>
        </div>
    <% end %>
</div>

/* keep it in the DOM for a11y */
.radio-card-input {
  position: absolute;
  opacity: 0;                 
}

.radio-card {
  display: block;
  padding: 1rem;
  border: 1px solid var(--grey-200);
  border-radius: var(--radius);
  background: var(--white);
  text-align: center;
  cursor: pointer;
  transition: border-color .2s ease, box-shadow .2s ease;
}

.radio-card-input:checked + .radio-card {
  border-color: var(--primary);
  box-shadow: 0 0 0 4px rgba(var(--primary-rgb), .35);
}

.radio-card-input:focus + .radio-card {
  outline: 2px solid var(--primary);
  outline-offset: 2px;
}

.radio-card:hover {
  box-shadow: 0 2px 4px rgba(0,0,0,.06);
}

/* helper for nice icon sizing */
.radio-card i { font-size: 2rem; margin-bottom: .25rem; }

This allows the user to interact with the payment options in a very intuitive way and keep it accessible. The selected payment type is automatically stored in the form, and you can easily access it when the form is submitted.

But there is more!

Toggle Visibility with CSS

This is probably something you have seen before, but I want to show it again because it is so useful. You can use the :checked pseudo-class to toggle the visibility of elements based on the state of a radio button.

In my case I wanted to show a invoice form when the user selects the online payment option. I could have used JavaScript to show and hide the form, but instead I used CSS to toggle the visibility based on the state of the radio button.

Right underneath the radio button container I put another container <div class="invoice">. By default this container is hidden:

.row .invoice {
  display: none;
}

Then I use the :checked pseudo-class to show the container when the online payment option is selected:

.row:has(#payment_kind_payment_pending:checked) .invoice {
display: block;
}

How does that work?

:has() is the long-awaited parent selector: it lets you style a parent (here .row) if any child inside it matches a condition – in this case, the radio button with ID payment_kind_payment_pending is :checked. After decades of “CSS can’t look upwards,” :has() finally makes it possible 🤯. It’s a relational pseudo-class which ships in every evergreen browser.

Browser support & fallback

As of mid-2025, :has() enjoys ~93 % global support (Chrome 105+, Firefox 117+, Safari 15.4+, Edge 105+).

For the minority still on older engines, the invoice panel simply stays hidden. If you need to support these too JavaScript will probably solve this.

This way the invoice form is only visible when the user selects the online payment option. No JavaScript needed! And it’s accessible out of the box too!

Applying the Presenter Pattern in Marten

Marvin Ahlgrimm — Mon, 23 Jun 2025 14:54:22 +0000

I recently ran into a problem in one of my Marten projects. My Journey model — originally quite simple — ended up bloated with methods like travel_period, total_costs, sidebar data prep and more. Nearly every view needed these calculations, so my model was being polluted with logic that didn’t belong there.

Marten templates doesn't allow complex calculations, so I had to do these calculations in my models and access it in my template. But this made the model huge and hard to maintain. It felt wrong to mix UI logic with data persistence.

I wanted to keep my models clean and focused on their primary role: representing data in the database. But I also needed a way to prepare data for my templates without cluttering the model with view-specific logic.

To solve this, I borrowed a pattern from Rails and other ecosystems: the Presenter Pattern. Instead of stuffing the Journey model, I moved view-specific logic into a JourneyPresenter class. I then plugged that into my handlers so my templates could work cleanly with journey.

Here’s how I set it up.

Extracting a Presenter for my `Journey` model

My Journey model acts as a central wrapper — holding transports, accommodations, travelers, days, and so on. All my journey views show a sidebar with accumulated price, total traveler count, and other derived data. That made it a perfect candidate for moving presentation logic out of the model.

Initially I thought to use Object#delegate, but manually listing every method felt brittle.

Thankfully Crystal’s macro system allowed me to generate delegations compile-time. The result: a reusable Delegate module that forwards all public, zero-argument methods from the model and mixes in Marten::Template::Object::Auto, making them accessible in Marten templates.

module MartenPresenters::Delegate
  include Marten::Template::Object::Auto

  macro present(klass)
    {% ivar_name = klass.resolve.name.split("::").last.underscore.id %}

    {% unless @type.methods.any?(&.name.== :initialize) %}
      def initialize(@{{ivar_name}} : {{klass}}); end
    {% end %}

    getter {{ivar_name}} : {{klass}}

    {% for m in klass.resolve.methods %}
      {% if m.visibility == :public && m.args.empty? %}
        {% next if @type.methods.any?(&.name.== m.name) %}
        def {{m.name.id}}
          @{{ivar_name}}.{{m.name.id}}
        end
      {% end %}
    {% end %}
  end
end

This modules macro present takes a class, which is used to create a initializer that takes an instance of the class we want to present. It also creates delegation functions for all public methods that take no arguments (in assumption they are getters).

Sidenote: This could be extended to use a blacklist of methods to exclude.

The macro generates methods that delegate to the wrapped model, so I only need to call start_date! instead of journey.start_date!.

The present Journey call wraps up model attributes neatly and compile-time delegation avoids manual boilerplate.

Defining `JourneyPresenter`

class JourneyPresenter
  include MartenPresenters::Delegate

  macro finished
    present Journey
  end

  def end_time_formatted
    end_date!.to_s("%Y-%m-%d")
  end

  def total_costs
    total = Money.new(0, "EUR")
    days.each do |day|
      day.events.each { |e| total += e.price.not_nil! }
    end
    total.format(symbol_first: false)
  end

  def sorted_days
    days.order(:date)
  end

  def total_costs_per_traveler
    total = Money.new(0, "EUR")
    days.each { |d| d.events.each { |e| total += e.price.not_nil! } }
    (total / travelers.count).format(symbol_first: false)
  end

  def travel_period
    (end_date! - start_date!).days + 1
  end
end

Important note: I wrap present Journey inside a macro finished block. Without deferring it, the compiler wouldn’t have fully resolved Journey’s methods yet — so delegation wouldn’t include them all.

All Journey fields are directly accessible, e.g. #start_date! or #end_date!!

This presenter now handles formatting dates, accumulates prices and travelers, and provides ordered collections. Models stay lean, and templates stay expressive and focused.

Injecting the Journey Presenter into Handlers

I wanted a quick way to make journey available in my templates, so I built this mix-in:

module HasJourneyContext
  macro included
    before_render :set_journey_context
  end

  @journey : Journey?

  private def set_journey_context
    # Inject the presenter into the templates context
    context[:journey] = JourneyPresenter.new(journey)
  end

  private def journey
    @journey ||= Journey.get!(access_token: params["access_token"])
  rescue Marten::DB::Errors::RecordNotFound
    raise Marten::HTTP::Errors::NotFound.new("Journey not found")
  end
end

Using the Presenter in a Real Handler

Here’s an example handler that includes the mix-in:

class TravelerListHandler < Marten::Handlers::Template
  include HasJourneyContext # Include for simple usage of the presenter

  template_name "travelers/list.html"

  before_render :set_travelers

  private def set_travelers
    context[:travelers] = Traveler
      .filter(journey: journey)
      .order("-created_at")
  end
end

By including HasJourneyContext, this handler automatically injects a fully prepared JourneyPresenter into the templates context.

What This Achieves

Models stay focused on persistence — no mix of UI logic
Templates call {{ journey.travel_period }} or {{ journey.total_costs }} directly
Presenter class is testable in isolation
Handlers are lean and declarative
Macros generate safe, compile-time delegations
No global state, no hidden context—everything is explicit

Everything just works, and it’s easy to extend or test.