gmccreight2

Over the past few months, I’ve gradually converged on a highly iterative style of agentic software development, shying away from the "dark software factory" approach. This post explains why I've made the move, how other agentic engineering practices fit into that model, and which of those practices I’ve personally found useful.

I'd be curious to hear others' experiences here. Anybody been really successful with the "dark software factory" approach? Any new practices I should be prioritizing over the others I mention being interested in, but that I haven't adopted yet?

The Gas Town announcement blog post is quite a read.

Partway through reading it I realized two things: First, it seemed very important. Second, it was really long and complex, and I would need a map to keep everything straight.

So I started building one.

Then I realized I didn't want to need to keep consulting the map for every little thing, so I slowed down. I started reading it incrementally and made spaced repetition prompts as I went along. I also tried to figure out what the motivating problems were, and how Gas Town addressed them, so that the nitty-gritty roles and naming became less confusing.

The result was basically a wiki with a densely-linked glossary and a bunch of spaced repetition prompts that align with each section of the blog post. It's somewhat similar to "Quantum Country", if you remember that amazing post from several years ago, but for the "Welcome to Gas Town" blog post.

I also included a "download the markdown notes" button, in case you want to pull some of the markdown notes into your own notes. If you use Obsidian, the spaced repetition prompts work with the popular Obsidian spaced repetition plugin.

Anyhow, I know the original Gas Town post is a couple months old at this point, but it took me a while to get this thing into reasonable shape where I think it could be helpful to others. I hope you like it!

Andy (the Orbit author) has his own very interesting Zettelkasten-like set of public notes. In this page, for example, he compares/contrasts his "Evergreen note" approach to a Zettles in a Zettlekasten: https://notes.andymatuschak.org/z4AX7pHAu5uUfmrq4K4zig9x8jmm...

Additionally, his system does have spaced repetition built-in, too:

"I’ve embedded a Spaced repetition memory system into my notes: The mnemonic medium can be extended to one’s personal notes. This has substantially changed the medium, but in ways I don’t yet understand very well."

I do not believe he has open-sourced his note taking system, but it is fun to browse around in; he presents a lot of interesting ideas, particularly if you're into this space.

In a more recent article Michael Nielsen and his co-author Andy Matuschak have adjusted their thinking somewhat: https://numinous.productions/ttft/

“One of us has previously asserted (Michael Nielsen, Augmenting Long-Term Memory (2018)) that in spaced-repetition memory systems, users need to make their own cards. The reasoning is informal: users often report dissatisfaction and poor results when working with cards made by others. The reason seems to be that making the cards is itself an important act of understanding, and helps with committing material to memory. When users work with cards made by others, they lose those benefits.

Quantum Country violates this principle, since users are not making the cards. This violation was a major concern when we began working on Quantum Country. However, preliminary user feedback suggests it has worked out adequately. A possible explanation is that, as noted above, making good cards is a difficult skill to master, and so what users lose by not making their own cards is made up by using what are likely to be much higher-quality cards than they could have made on their own. In future, it’s worth digging deeper into this issue, both to understand it beyond informal models, and to explore ways of getting the benefits of active card making.”

I suppose it depends what you're coding. For Objective-C I use xCode. For Android I use Android Studio. They provide many key affordances because they are tuned to their particular use cases.

However, if I'm writing in shell, Ruby, JavaScript, or any other oddball language without a purpose-built IDE, a well-tuned Vim setup, and extensive familiarity with how to use it, works wonders.

Thanks for the link, Jacob. I'll have to check out Practical Vim. I notice it says that it has more than 100 Vim tips. I guess I would take those tips and put them into my study deck so that I'd actually be able to remember all of them. ;)

Thanks Lou! Glad it'll help you.