Journal Entry For 2026-04-26
- [This was supposed to go out a long time ago now, but better late than never. I guess I need to find a better way of blogging these kinds of things. This is one of those posts that make me feel vulnerable because I am talking about my (professional) use of LLM coding tools.]
- I finally (2026-04-22) did it: I removed Mastodon and Discord from my phone! Social Media addiction is real and I especially got disenchanted when I realized how little time I spent creating vs. passively consuming social media. I am not planning to remove social media completely as I do enjoy posting and consuming it once in a while, but I want to get out of the rut of consuming social media all day long. So I removed the apps (Mona in the case for Mastodon) and Discord.
- I think this move may have been heavily influenced by Cal Newport, although I don't seem to find the video or article that has prompted me to do this, skimming what I had read/watched from him more recently... but it's a recurring topic in his stuff, for sure.
- I still have Youtube, which isn't really a social medium for me as I am not creating videos myself. And I do have social media on other devices (tablet, laptop), but we're getting there.
- (2026-04-25) Removing all social media from my phone means (so far) more time in my feed reader. And more time on other devices.[1]
- The process of moving things over to my NAS/homelab is long. And expensive! And headache inducing. So I'll take the slow approach. The beefy VPS is paid for this year and I need to explore a little what I want to run where and if this stuff should be available on the public internet or not and how the setup will look. There are lots of thorny issues pertaining to this public/private split, the forwarding process from my homelab setup and coolify wanting to own the public edge just as much as pangolin does.
- Related to this is the recent development that I am using my MacBook Air instead of my work computer for my own stuff. We are allowed to use the work machine for personal use (within reason), but I enjoy having my own machine for my own personal stuff as it turns out. That does mean though, that I am not done with hardware purchases. So I'm looking into getting an m series Mac Mini (refurbished or second hand) or mini pc (maybe more likely) as part of the newly established homelab of digital independence: the compute part would be the mini and the storage part would be the Synology.[2]
- (2026-04-26) The dogo has a mild case of kennel cough. She never had it before and so were slightly worried. Our insurance includes three free calls to an app called FirstVet which offers video calls with Veterinarians. Now Napu gets a little honey with her food and is taking steam baths with us while we're standing under the shower.
- Prompted (ha!) by recent developments at work - namely that I am one of the power users of AI in my company - I have looked into my token usage a little more - because honestly I was very surprised - and I realized a couple of things:
- Working with AI agents in big (some would call them legacy) code bases means input to output token ratio is skewed toward input: The agent has to read lots and lots of code, before any code can be generated, so new code is rather expensive because of the needed input, not because we generate lots of lines of code.
- I tend to prefer iterative approaches. I do know about "spec-driven- development" and so forth, but even so the process of creating a feature using an agent involves many "turns" which is to say there is lots of back-and-forth between me scrutinizing code, explanations, solutions and so on.[3] I think three things that stand out to me about that specifically:
- I tend to spend lots of turns specifying what needs to be done after a first draft plan is proposed.
- I tend to spend lots of turns in the testing phase, when the feature was generated but doesn't quite work as intended, yet.
- I tend to spend lots of turns in the sanity check/code review/refactoring/add tests phase right before handing the branch over for review (like, you know, in a merge request)
- We use OpenAI at work, meaning we use Codex and what I didn't take into account as much until now is the fact that even though most modern models have a pretty effective token caching feature making the above points not so so bad (as you spend only 0.50$ instead of 5$ per Million tokens if "context" can be reused) it still add's up if you go for a long time. Another reason long running threads can be expensive is the fact that GPT 5.4 is cheaper if you use less than 272K input tokens. Which in my experience is not a lot of context.
- So the calculation of when to split is slightly weird: Splitting before 272K tokens makes often not much sense in the environment I am working in because the projects tend to be complex and tangled. And restarting too early doesn't take advantage of the token cache, making frequent new threads sometimes more expensive than just continuing in a thread with already built-up context.
- Footnote: All my back of the envelope calculations use the API costs which my company doesn't actually pay. They pay subscriptions plus "credits" (the later only if needed), but I still think it can be helpful to take a look at those costs as it should translate pretty well to the usage quota it seems. The codex rate card seems to fit my assumptions pretty well also.
- I feel like it's important to say that I remain sceptic about this whole "AI" thing precisely because usage of LLMs coupled to real-world costs is economically unsustainable.[4] If we want to have acceptable quality, we need tests, refactoring, revisions, reviews and eye for architecture, mentoring... all that good stuff. Using a coding agent to generate part of a solution that has to be reworked multiple times because we discovered how things should work while doing so costs tokens (money, in the end) and I don't see any amount of minmaxing changing that. If generating acceptable quality using an agent becomes too expensive, we end up pushing towards one-shot/vibe-coding territory which almost certainly will end up becoming and unmaintainable mess. I see my use of LLMs for coding professionally as a "show, don't tell" approach of LLM criticism.
- Speaking of Cal Newport: He does a pretty interesting series called AI reality check (here's the most recent one titled Is AI About to Automate Every Office Job? (Not a Chance)) on YouTube which had such illustrious guests as Ed Zitron on recently (although most of them is just Newport talking). I think it does a good job of showing how to approach claims made in the "AI" industry. The tl;dr is: Most of it is untrustworthy and doesn't hold up to scrutiny.
It also means a little more attention left for other people and my dog. ↩︎
I wanted to use the air as the compute node, but if I use it as my personal machine, that won't work really... ↩︎
I mean... the code should at least not be bad, if we are supposed to use these things, right? So one-shoting things doesn't really make much sense. ↩︎
This is a slightly different argument than saying LLMs are unethical or LLMs are environmentally unsustainable. I do not necessarily disagree with those notions (how could I!), but I personally have decided that I want to understand this technology in practice, be one of the ones who can use it well as part of my professional work, feel that it is important that people with hearts do interact with these technologies (and I count myself as one of them) and generally disagree with critiques that claim abstinence is the best policy (for cognitive hazard reasons or because they are a tool of the opressor). I thought long and hard - and continue doing so - about the relative ethics at play here and feel like non-frivolous use of LLMs for use cases where they genuinely make sense, is ok. It's not super great. But on balance it ensures employability and doesn't abandon the idea of quality. I got to eat. We have a baby on the way. I need to make sure I stay attractive for the job market, even if I would like to work in an environment where the long term would be more important than the short term. ↩︎
-
← Previous
DailyDogo 1611 🐶 -
Next →
DailyDogo 1612 🐶