Albert Fortin writes about his experience building a new feature using AI entirely implementing it with a new coding language and technology.

A few months ago I needed to build a new infrastructure for my SaaS, as the current PHP+MySQL combo was not fit for purpose anymore. I was excited about the opportunity to make the most of all the new LLMs I’d been playing with, so I set aside my SWE hat and I started acting as a product manager, chatting with Claude about best practices, doing some research on my own and then coming up with a plan, after many back and forths. I ended up choosing Go+Clickhouse.

When it was time to start coding, I asked Claude to give me a big and complicated markdown file outlining my existing infrastructure, my desired new infrastructure, what I’m trying to achieve, why I’m doing it, etc.

So I put it all inside Cursor Notepads and I start prompting away. Cursor writes code, I build it and test it. I’m quite happy with how things are going, the codebase isn’t the tidiest but things seems to work. I’m aiming for speed more than code cleanliness - my SaaS business customers told me they need specific data and this new infrastructure is the only way I can deliver it. I have a few more potential customers who are waiting for me to tell them this is ready so they can purchase a plan. Every day I don’t have this ready, I’m literally losing money.

This doesn’t end super well.

One morning, I decide to actually inspect closely what’s all this code that Cursor has been writing. It’s not like I was blindly prompting without looking at the end result, but I was optimizing for speed and I hadn’t actually sat down just to review the code. I was just building building building.

So I do a “coding review” session. And the horror ensues.

Two service files, in the same directory, with similar names, clearly doing a very similar thing. But the method names are different. The props are not consistent. One is called “WebAPIprovider”, the other one “webApi”. They represent the same exact parameter. The same method is redeclared multiple times across different files. The same config file is being called in different ways and retrieved with different methods.

No consistency, no overarching plan. It’s like I’d asked 10 junior-mid developers to work on this codebase, with no Git access, locking them in a room without seeing what the other 9 were doing.

On a spectrum of how much you trust AI to do the work of building your product, there’s not using it at all and there’s vibe coding. Like many things, the most optimum is somewhere in the middle where you lead it along, but maintain an understanding of what is being built.

The hardest part in all of this has been resisting the urge to use AI. I have this amazing tool available and it could write these 10 files in a minute. I’m wasting time by not using it! And that’s when it hit me. I’ve not been using my brain as much. I’m subconsciously defaulting to AI for all things coding.

I’ve been using pen and paper less. As soon as I need to plan a new feature, my first thought is asking o4-mini-high how to do it, instead of my neurons. I hate this. And I’m changing it.

So yes, I’m worried about the impact of AI, but I’m not worried about the jobs, I’m worried about losing my mental sharpness, my ability to plan out features and write tidy and functional code.

So I’m taking a big step back, really limiting how much AI I use. I’m defaulting to pen and paper, I’m defaulting to coding the first draft of that function on my own. And if I’m not sure I’ll use an LLM to check if that’s a good solution, if that’s a good naming convention, or how I can finish that last part.

But I’m not asking it to write new things from scratch, to come up with ideas or to write a whole new plan. I’m writing the plan. I’m the senior dev. The LLM is the assistant.

Treating software engineering as a craft means leveraging your intelligence, skillset, and expertise to build and scale products. Crafts people do this and also rely on tools for efficiency’s sake. LLMs are just another tool (but a sophisticated one) in our toolbox.

It’s good to see the other side of this sometimes.

🧇