Ways in which GenAI has changed the way I write code so far

-->

Sign in<br>Subscribe

TL;DR : Projects where I use AI had a massive influence on my workflow, and it changed my default stack, IDE, how I use git and more.<br>A few months ago, I wrote about the impact that GenAI had in my Tech life so far. This article is about how it impacted the way I write code.<br>First, a disclaimer : This articles describes about how I write code at home, and does not necessarily reflect my work environment.<br>What used to be ideas can now be pet projects<br>As pretty much all developers, I constantly have ideas of things to build. And just like many of you, most of those ideas are fun / good but they'd also simply be too long to implement. The flow of ideas is faster than the time I have to build them.<br>Because of how good models have become though this has massively changed : Those ideas actually can be implemented now, usually in a matter of hours. So my coding has turned into 2 types of work :<br>Manual coding, the old way, when I want control / have fun / learn stuff<br>Semi "vibe-coding", where I let Claude (after trying Junie) handle most of the implementation and I guide him instead. I will challenge it on architecture decisions and use a large set of tests as guardrail.<br>The Agent Orchestrator as a base layer<br>For the past year or so, I've been using Maestro as my main AI orchestration tool. I like Maestro a lot, because it gets a few things right that many other similar tools don't for me:<br>The main Maestro UIIt organizes everything in projects, which avoids having to constantly search which tab to open<br>It works using Auto-run docs, which is pretty much a light version of spec-driven development, but without all the framework hassle.You tell it what you want to do, and it will come back with a proposal of implementation in steps, as a set of markdown files with TODO lists.

You can either tell it to change the files, or modify them yourself.<br>All items are done in a fresh new context, to avoid context drift and pollution. No more restarting Claude Code sessions all the time.<br>But what I love most is that you can set a set of guardrails as Markdown files, and let it iterate over its plan as long as the guardrails aren't satisfied. It's pretty much a simplified Ralph Wiggum loop, without any fluff.<br>Because my projects tend to be very similar, I put those implementation files in a separate repository and share those guardrails across projects.<br>Setting up Maestro to do its thing, with my Kotlin light guardrails in place<br>Second AI as a reviewer<br>Because I tend to let AI generate the huge majority of my code, I use a second AI as reviewer of the created Pull Requests. I have been using Claude Code locally a lot, but I love the team behind Kilo.AI and they've been my tool of choice for pull requests reviewing. I like that I can select what sort of review I want, and how extensive.<br>The KiloAI Code ReviewerKilo helping me review Claude Code generated codeFrom Git branches, to Git worktrees<br>If you start using an agent orchestrator, you very quickly start telling it to work on several things at the same time. Maybe some UI cosmetics, an implementation of preview deployments and a new feature at the same time.<br>And git branches simply won't cut it any more, because you're pretty much constantly concurrently working on several branches at once. That's why I switched to git worktrees instead.<br>Said simply, git worktrees are branches but in local folders. This allows you to make concurrent changes as well as test on multiple branches at once. I like to keep things under control, so I usually don't work on more than 3/4 things at once, but that's still a whole lot of concurrent changes.<br>From Kotlin to Typescript<br>If you've read me before, you know I'm a huge Kotlin fan. Kotlin is a fun, powerful, consistent and pleasant language to work with. I'm also usually a minimalist, so my UIs are typically built in barebones web components and I like to avoid frameworks.<br>If you let AI handle most of your coding though, those taste become irrelevant and one thing is more important than everything else : How good can my agent work with my stack.<br>For this simple reason, all of my vibe coded projects are written in Typescript on the backend and usually React on the frontend. Not because I like those (I don't), but simply because of the absolute insane amount of training data available on this stack, making it easier for LLMs to write in.<br>Your stack doesn't matter. How good your LLM is with it does....<br>No more heavy IDEs<br>Just like with Kotlin, I've been a massive JetBrains fan for a very long time. The company itself, but also their IDEs. I spent years paying for subscriptions from my pocket simply to support the company because of how good their products are.<br>But in an environment where most of your code is written by someone else, where you constantly have 3/4 editors open in different worktrees and where you open and close editors 20 times a day, heavy IDEs just...