Craft over prompts

I ran out of Claude Code tokens the other day. And froze. Eight years into my software engineering career, dozens of projects, thousands of lines shipped… And yet, for a few minutes, it felt like I had forgotten how to write code. That’s when I realized I needed to take a step back. A little late, I know.

Most software engineers I work with have been using AI coding tools for years. We have seen the models evolve from barely usable to genuinely impressive.

There have been skeptics all along, often experienced software engineers for whom this whole thing is 90% marketing and 10% reality. But in the past few weeks, I see more and more of the ones who had previously embraced AI coding now taking a break from it.

I started using ChatGPT “research preview” in 2022 and gradually adopted various models in my day-to-day work as the IDE integrations improved. It got really good, really fast. In just three years, we went from copying code back and forth with a browser-based chatbot, to having code autocompletion in the editor, to AI agents finally letting me drink my matcha latte in peace while doing all the work for me.

Why would anyone want to go back?

”Just build something”

Take a look at how the industry views our work. For business people, code is a black box sitting between ideation and product. It’s a highly complex, expensive step that they hope will enable sales. But it comes with many scary words they don’t really understand: technical debt, scaling issues, regressions. Believe me, if they could avoid code altogether, they would.

In fact, they have tried. Think about the rise of “no-code” tools. Sure, there is still code behind them, but you only see the GUI. And if there’s a bug, it is another company’s problem. Just like with serverless, servers haven’t gone anywhere; they’re just for someone else to scale and deploy to.

Meet the new kid in town: vibe-coding. Write a prompt with your idea, wait, nudge, repeat, ship, make money. That’s the dream products like Lovable, Bolt or v0 are selling. You don’t need to be a software engineer. You don’t need to see the code. “Just build something,” and they’ll do the rest. But when something goes wrong, whose problem is it?

Whether you like it or not, you are responsible for the code you ship to end-users. And having to fix code you did not write, let alone understand, is not a good place to be. Especially if your shiny new SaaS handles any kind of personal or sensitive data.

Software engineers are not immune to this. In fact, back in the day, we copy-pasted code from StackOverflow, sometimes bitterly regretting it. But the scale and speed at which these models take us is unprecedented. We started by offloading boring tasks: write tests, create dummy data, document code, rename symbols. As the models got better, we asked them to debug errors, create features. Then, we let them execute commands on our machines.

Let’s be honest, it sometimes feels like magic. And sometimes, it deletes the production database.

”You’re absolutely right!”

Here is the pattern that finally clicked for me: these models speak beautifully, but they forget quickly. They’re confident, but they hallucinate. They flatter you, but only because they’re optimized to please.

There is a disturbing dissonance between the honeymoon phase the industry is in and the growing red flags raised by the community. If you’ve ever watched a model confidently walk you down a path that doesn’t exist, invent facts, or do the opposite of what it’s saying… you know the feeling.

Big Tech executives love to declare that 25% to 30% of their code is now written by AI, treating it like a KPI. But they rarely mention how much time engineers spend reviewing AI-generated code and cleaning up the mess, and how frustrating that work actually is.

Work that didn’t spark joy

I kicked off a side project a little while ago. I wanted to try Svelte 5. After the initial scaffolding, I let Claude Code drive most of the basic features while I wrote the documentation and refined my prompts.

In just a few hours, I got the basic features to work. That sounds like a massive time saver, right? But after the initial prototype, most of my time was spent prompting it to remove all the over-engineered abstractions and break up the 500+ line files it spewed.

The tool that was supposed to give me superpowers had me waiting between each prompt, wondering if its non-deterministic neural network would produce anything good next.

Between the constant back-and-forth every time it failed to deliver working code and the hours spent compacting the context window and optimizing my prompts, this ended up putting a weird distance between me and the project. I became a middle manager instead of learning about Svelte 5. And I was not having much fun.

The indigo trend

There are endless ways to be creative. Mine is to start projects from zero, having to figure out the user experience, the code architecture, the right patterns. Finding good variable names. Experiment. Make mistakes. Going through libraries documentation. Refactor.

Have you heard of the indigo trend? AI-generated UIs almost always use the same color: indigo-500. Wes Bos interviewed Tailwind’s creator about it, and it turns out the reason is simple: it was Tailwind UI’s default color at a time when many models were in their training phase.

The funny part is that it’s only going to get worse, as future models are being trained on that growing sea of generic purple landing pages. These models are trained on existing code; they output existing patterns, sometimes verbatim. It is harmless enough with color palettes, but not when it regurgitates a security vulnerability.

At some point, the so-called efficiency gains aren’t worth the loss of craft. When the hype settles, I believe we should (and will) use LLMs like any other tool: for the small set of jobs they’re actually good at.

My AI-detox

Here is the plan. For now, I am going back to basics. No Artificial Intelligence. Just me, my laptop, and a trusty old matcha latte.

So far, so good. It feels slower to kick off a project, but writing code brings much more joy than vibe-coding my way into oblivion. And what’s more, it doesn’t even feel slower over a few days of work.

If you’re not taking an AI coding break like me, I’ve come up with a few rules for my future self, for when I will reintroduce these tools to my workflow.

Own what you ship

→ If you can’t fully explain each line, don’t merge it.

Disable AI in your IDE

→ Uninstall CLI agents, and use models only in the browser when necessary. Or in Raycast. But keep it away from your editor; it’s too tempting.

Learn the basics

→ By no means an exhaustive list, but here are some major concepts: transformers, tokens, context windows, why hallucinations happen.

Prefer local models

→ Mostly to stay in control instead of being at the mercy of your internet connection and every model update. I use LM Studio as it supports MLX for Apple Silicon.

As of November 2025, Qwen3-coder-30b has been solid for me. Local models are usually less capable than the big cloud ones running on thousands of GPUs, so I recommend breaking your requests into smaller, focused prompts to get the best results.

Use it to review your code

→ Especially on solo projects, it’s better than having no one review your code. Expect false positives, but at times you will catch a real issue or code smell. It’s easy to enable on GitHub and the free tier is generous.

Use it to learn

→ Ask questions, request comparisons, and come up with edge cases to your tests. Remember to always double-check sources, especially when it comes to dependencies, as these models quite often use outdated specs.