Comment by ctoth

2 days ago

Let me share a problem I solved recently (well, a year ago god I'm getting old)!

I had to write this template loader for my space sim... reference resolution, type mapping, and YAML parsing. This isn't the code I wanted to write. The code I wanted to write was behavior trees for AI traders, I'm playing with an idea where successful traders can combine behavior trees yada yada, fun side project.

But before I could touch any of that, I had to solve this reference resolution problem. I had to figure out how to handle cross-references between YAML files, map string types to Python classes, recursively fix nested references. Is this "journey programming"? Sure, technically. Did I learn something? I guess. But what I really learned is that I'd already solved variations of this problem a dozen times before.

This is exactly where I'd use Claude Code or Aider + plan.md now - not because I'm lazy or don't care about the journey, but because THIS isn't my journey. My journey is watching AI merchants discover trade routes, seeing factions evolve new strategies, debugging why the economy collapsed when I introduced a new resource.

OP treats all implementation details as equally valuable parts of "the journey," but that's like saying a novelist should grind their own ink. Maybe some writers find that meaningful. Most just want to write. I don't want to be a "destination programmer" - I want to be on a different journey than the one through template parsing hell.

OP here, I whipped this up in like 10 minutes after modelling the problem from a new perspective (I want to be less of a perfectionist with my blogs) so there are definitely grey areas I didn't consider/cover.

I do think LLMs can be good for certain boilerplate code whilst still allowing you to enjoy the problems you care about, and as far as my binary definitions this is more of a grey area.

I guess for me, this has introduced a slippery slope where if the LLM can also code the "fun" stuff, I'll be more inclined to use it, which defeats the whole purpose for me. Perhaps being able to identify which type of project I am working on, it can help me avoid using LLMs to enjoy programming more again!

  • Maybe you could ask the LLMs to stub out whatever you consider fun leaving you with a LeetCode style problem to solve. I could see that being fun. I actually really like LeetCode in the same way some people like doing Sunday crossword puzzles.

> OP treats all implementation details as equally valuable parts of "the journey,"

Do they? That wasn’t my take away from the article.

My impression was that the author missed the enjoyment of problem solving because they overused AI. Not that they think all problems are equal.

For what it’s worth though, I do agree with your more general point about AI use. And in fact that’s how I’ve used AI code generation too. “Solve the tedious problem quickly so you can focus on the interesting one”.

I get your point, I think the difficult thing is that these tools are not delineated: preground-ink does not have the capability to write your stories for you, but with llms we constantly have to reasses which parts of the thing we are building merrit our attention.

If llms get better, will you have to decide whether you actually care about writing decision trees, or if instead you just want to, more generally, curate procedural interactions (or something)?

My point is: if these next few years every project becomes an exercise in soul-searching for which parts of my work actually interest me, it is maybe less work not to use these tools, or alternatively, find something fullfilling that doesn’t involve making something.