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.
Top comments (0)