Professor Langd0n

08/27/2026

Wrote about a distinction I think is going to matter more and more in serious AI systems.

A bigger context window helps one assistant hold more at once. It does not solve the harder problem, which is multiple systems needing the same durable truth about the user, the projects, and the work. That is where memory becomes infrastructure.

https://langd0n.com/blog/the-missing-layer-is-memory-substrate

08/25/2026

Wrote about the only thing that has really helped me ship more with AI in the loop.

It was not better prompting and not more self-discipline. It was deciding ahead of time how much editorial effort a piece is allowed to get, based on its attribution level, and then actually obeying that rule.

https://langd0n.com/blog/editorial-quality-gates

08/20/2026

Wrote about a framing that keeps clarifying agent workflows for me.

Instead of one all-purpose agent, think architect and coder: one role holds the plan and writes the contract, the other executes. The separation turns out to buy reviewability, portability, and much cleaner accountability.

https://langd0n.com/blog/architect-and-coder

08/18/2026

Wrote about the part of agentic coding that has changed my day the most.

It is not just that agents can write code. It is that they reintroduced enough waiting and enough parallel blocked work that the human ends up acting like a scheduler again.

https://langd0n.com/blog/ai-coding-compile-time-patterns

08/13/2026

I wrote up a reframing I've found useful in AI-assisted work.

People ask "who wrote this?" as if the hard part is settling authorship. Sometimes that is an interesting argument. But when you're looking at a commit later and need a real answer, the practical question is whether you logged what happened when it happened.

That is why I keep ending up back at attribution and auditability. Not because the philosophy is uninteresting, but because the operational version is the one you can build.

https://langd0n.com/blog/who-wrote-this

08/10/2026

I forgot to upload a batch of social posts and asked an AI session to fix it. That turned into a publisher covering Buffer, Bluesky, and Mastodon.

The same workflow then followed the work from code into writing. One agent reviewed another through tmux, and the drafting session crossed a model handoff before the post was done.

https://langd0n.com/blog/delegated-workflows-beyond-software?utm_source=facebook&utm_medium=social&utm_campaign=delegated-workflows-beyond-software&utm_content=facebook

08/09/2026

Wrote about a shift in how I think about prompts.

The useful move was not stuffing more into one master file. It was giving each job the instruction that belonged to that job, where the work actually happens, instead of making the model drag around a giant archive of mostly-irrelevant context.

https://langd0n.com/blog/jit-prompt-delivery

07/30/2026

Wrote about a debugging shift that feels more important every month:

when an agent-produced change comes back wrong, the bug is often not in the code at all. It is in the instruction. Keeping that instruction on the issue turns it into something you can inspect instead of just vaguely remember.

A bug in agent-written code is often not a bug in the code. Because the build prompt lives on the issue, you can debug the instruction the same way you debug the program.

07/28/2026

I wrote up a thing that sounds wrong until you sit with it for a minute: I use GitHub Issues as the message bus between my control plane and coding agents.

By the standards of distributed systems, that is a bad bus. It's slow, and it depends on a human actually reading the traffic.

But agentic work isn't machine-to-machine traffic at scale. It's slower and higher-stakes, and it's worth keeping a record of. The properties that make GitHub Issues a bad queue are the same ones that make it a good substrate for this job.

By every metric a distributed-systems engineer cares about, a GitHub issue tracker is a terrible message bus. The properties that make it terrible are exactly the ones agentic workflows need.

07/23/2026

My Calendly trial ended and the booking link on my site started 404ing on visitors. That part was annoying. The part that interested me was what happened next.

I moved to Cal.com in about 30 minutes. Not because switching scheduling tools suddenly became fun, but because the expensive part was never the website change. It was the re-creating of all the setup inside the tool, and that cost fell hard.

I wrote this up because I think a lot of software "lock-in" is really migration pain we've gotten used to treating as fixed.

My Calendly trial lapsed and the booking link on my site started 404ing on visitors. I was on Cal.com 30 minutes later. The interesting part isn't that the AI wrote code, it's what it did to the switching cost I'd stopped questioning.