Seven months of AI later

🐻 with me. It's been a good while since I wrote a blog post here.

Since then, I have

• Moved from Odense (Denmark) to Paris
• Replaced my keyboard (this is now being typed on a Rainy 75 Pro—very nice)
• Used AI a lot
• Learned a lot
• Built my first complex features more or less entirely with the use of AI
• Observed an industry become increasingly AI-pilled
• • Observed a divide emerge between the "I don't read code" and "I still like to stay in the loop"

And I think this blog post will mostly revolve around the last bullet point.

I will, however, start with some AI positivity though. Because there are some truly cool usecases which I'm quite stoked about. I'm currently writing this blogpost in "Yet Another Browser". A browser I had never heard of before The Browser Company of New York decided it was time to sunset Arc (wtf), and I went looking for a new one. I tried, in no particular order: Dia, Helium, Aside, Chrome, Safari, Firefox, YAB, and probably some other ones I forgot about already. I ended up staying on YAB because they allowed me to bring my own AI subscriptions and rather reuse those, instead of forcing me to pay for another subscription.

I then connected up all my subscriptions, email accounts and what-not (let's ignore the security perspective here for a second—I know this is probably going to bite me in the ass someday), and decided to take it for a spin. I had it finish my checkin for my flight to London in a few days, check that my ETA was valid (it found the email and cross-checked the last four digits of my passport), reset the password to my blog (yes, this one) as I forgot it, and it had to go into TursoDB and get the reset token from PayloadCMS (or something like that), and some other random admin tasks I had been postponing for quite some time.

And this is a story I'm starting to hear more often; AI is getting really good at doing shitty admin tasks that you don't want to do anyways. Like I've been having it deal with the landlords and ladies of my old apartment as they're giving us a hard time, and it's been handling passive agressive assholes like some stoic demigod. For reference, they claimed that we had lost one of the keys to the apartment, and thus had to replace the whole lock, but we were certain that it had been put in the mailbox. After what felt like two million emails they ghost us, only for us to find out through another channel, that they did indeed find the last key. I would not have kept the cool that ChatGPT did in that situation. And while I'm a strong opponent of using AI to communicate with humans, I think for situations like this it's gold.

But this makes a good segue to my next point, which is that if you want to ask a favour of another person, or want to show them respect, then do so with your own words. Do not

1. Send them some six-hundred pager about whatever they asked about
2. Hey, my PR is ready for review. Could you take a look?
   Sent with Claude

For the first issue, instead, read the output yourself, understand it, and then respond with your understanding, or just tell them "I don't know!"

For some reason, it seems we've forgotten the value of not knowing. Leaving the task to someone who knows more about it, and learning from the solution that they came up with. And I don't mean Claude here. I know there are now two schools of thought which can be summarized as "Claude is smarter than me and when it makes mistakes it's the steering that's the problem" and "Claude is really good at executing, but lacks my domain expertise or holistic understanding."

Claude will, more or less no matter what, do what you told it to do. But where a human will infer a lot of implicit boundaries, expectations, and what I can only call common sense, the sycophantic chatbot will do anything to arrive at some interpretation of the task you gave it. This is also for me where "[...] when it makes mistakes it's the steering that's the problem" falls apart. Yes, it's the steering that's the problem. But how are you going to condense everything you've learned throughout your career into some .MD files? Maybe one day we'll get to the point where we can teach AI values, and then with RSI it can essentially walk the path we've taken to become the engineers we are, but for now I think you are smarter than the AI in some "dimensions". Not all, but some. Enough for there to be a real value to you still being involved in the process of development.

A lot of the problems I saw with the hands-off approach to development with AI seven months ago I still see today. It's definitely better, but the models still lack the, maybe human, maybe lazy, "urge" (lazy urge is a bit of a paradoxical statement) that made us simplify, deduplicate, and all the other things that we've come to associate with quality. I think this is because we know shit will hit the fan, and when it does, we want a system we can understand without a huge effort. For the AI, this is not taken into consideration in the same way as it lacks the feeling of fatigue when reading complex code and having to hold it in the context window known as your short term memory.

I'm now doing DevEx at the company I'm currently working for and I still see the same thing I saw before AI was a "big thing".

Note: these are my opinions and not those of my company.

Developers who write small PRs that are focused on one thing, and understand at least conceptually what the change does, and why it makes the trade-offs that it does, write systems that produce less problems: performance-, stability-, security, maintainability- and many other -wise.

That doesn't mean that you have to scrutinize every last line of code, but it does mean that you have to (in one way or another) look at it. Skim it. After all, the code is what will run in production. Not your fancy mermaid charts, videos, screenshots, /eli5, /bro or whatever. Why did you use PostgreSQL here and not Redis? Why did you do a row level lock instead of a mutex? These are questions you should be able to answer without having to consult the AI that wrote it.

Also amount of PRs merged is not a good metric. I thought we were past this? Nor is token spend, nor is commits, nor are any of those purely quantitative metrics. The value of an engineer should be the impact they make. And yes that is super vague and hard to measure. But try. What features did they roll out? Why did they make those features? One cool feature that the customers love is worth a lot more than some bikeshedding of AI tooling setup.

Anyways. I'm going to go out and touch some grass, and remember to do the same. I'll pay for a normal black coffee for the first person who goes out and touches grass after reading this. Email me proof (I will check your EXIF data;).