And here I am again with another installment of this. I’ve dropped the “Article” from the post name since I’m now including more than just article links. I hope some of my readers.Length readers find it helpful!

But first, some of my own thoughts.

On my AI usage

I’ve been jumping in more with Copilot at work, and it’s working very well for me. Just today, it helped me compress what would have been days of quite tedious work into several pretty pleasant hours.

However, it’s fair to say that while I’m still learning (partly by making a conscious effort to do so), I’m not learning as much as I would have by implementing it manually. (A rhetorical question: In this brave new world, does that really matter as much as it might have previously?)

I’m still driving the development process, as it’s clear human engineer guidance is needed. And, in any case, the productivity boost has been great.

In my personal programming, I’m still sticking to limited AI usage, mainly using it for learning purposes (e.g., asking detailed questions, seeing how I can improve code I’ve written). While I’m happy to lean into AI at work, manual programming is still where I go for fun and some mental exercise in my off time. However, I’ve starting moving on learning more about AI itself as well. We’ll see how things develop over time.

On moving fast

Looking online, it seems some people (maybe mostly non-engineers, though I’m unsure) are obsessed with the speed benefits that AI offers and just want to generate as much code and ship as fast as possible. That viewpoint concerns me somewhat.

Yes, code is far simpler to generate now, but as I feel most engineers would attest, more code is not inherent better. Code itself is a liability: there’s a maintenance burden, a testing burden, and now I suppose also a LLM context burden.

More code doesn’t magically solve all your problems. Great care must be still be put into thinking about what to build and why, even if the how is less of an time sink than it used to be. To borrow a thought I’ve seen expressed by others: Writing code was never the bottleneck.

Articles

Disclaimer: Each link’s inclusion simply represents information that I felt was interesting or helpful at the time that I noted it and does not necessarily indicate agreement with its contents.

Discussions

Quotes

The problem is that it sounds like you’re trying to offload the cognitive work to AI. This is something I often see. People get on the hype train, abuse LLMs, burn out because code review is exhausting, reading code is harder (and less enjoyable) than writing it, and they’ve let AI take over the interesting bits of their job, and then get on the doom train.

The rule is moderation and targeted application. You never leave the drivers seat. AI is often better at analysis than generation, especially as things get more complex. Use it for adversarial brainstorming, organising thoughts, clarifying complex topics, ramping up on new tools and repos, setting up infra, porting code to a new stack or language, writing boilerplate or simple (but tedious) changes, doing code review. They can augment your thought process, but they cannot take over judgement for you. And you control how much you give up to LLMs. Don’t choose to give up the parts that make you interested or fulfilled. Additionally, I often see people making the mistake of asking AI to be both the author and reviewer. You absolutely should never do that, for the same reasons we never let PRs merge without code review from at least one other person, ideally two. You can also use deterministic validation as feedback for the LLM to keep it on the rails. The borrow checker is one of the reasons why LLMs work particularly well with Rust.

It’s absolutely possible to use AI responsibly and constructively. I’ve actually been having more fun since I started using them because I treat them like a collaborator who can also do the bits I hate, not the bits I love.

— permalink

<
Previous Post
Handling Unsupported Kanji in Shift-JIS (※日本語要約付き）
>
Blog Archive
Archive of all previous blog posts