Sunday, November 1, 2026

How I‘m using LLMs to write

I‘ve been using LLMs now in coding for many months, both for writing code and for writing commit messages. Overall it's tremendous, but there are things to remember.

The code it writes is much better at the function level, than the code I write by hand, because it has been trained on so much code that it can anticipate all the annoying syntax errors that typically can trip you up, but it also has a much better repertoire of the latests and greatest best practices, so it's always coming up with patterns that I would never have thought of. Now while it writes great code at a detailed level, I constantly find that it's not so great at putting those pieces together in a consistent way that makes sense.

Sure it's amazing at one-shoting things, but real code isn't all one-shotted. Real code, you built over time, you remove parts, you add parts, you refactor and re-structure. I've found that I am much better at that than the LLMs, who operate in a world where they have no real sense of the past of or the future, and to the extent that they do, as they run, their memory is constantly getting deleted and compacted.

The other way I use it in code is to write commit messages. In that area, I now use it almost exclusively. It is just so much better at summarizing the code changes I have made than I am. I can copy and paste a git diff of all the changes I have made in a particular feature branch, and it effortlessly returns a perfect commit message, describing the changes using the much better terms and descriptions than I would ever come up with. It does quite often miss things, or add in irrelevant stuff, so I do always have to read and review the messages carefully, but basically I hardly ever write complex commit messages now. There is just no point. The commit messages are much better than what I could have written, they communicate the information I want to get across to the reader much better. Do they sound like they are written by me? Probably not, but that is in my opinion not actually that important when it comes to code and commit messages.

So that's the background, how about with writing content for the blog? How am I using LLMs for that? For day to day posts, like for instance this one, I don't use them hardly at all. Maybe I lookup a few bits of information, but I write the post completely, it's just less tedious, but also I don't want the post to sound like it was written by an LLM.

What about other types of posts, like the latests content creation blog posts I am currently writing? Well honestly I'm just trying to figure that out as I write them. I have been planning them using the LLMs, coming up with an outline of the topics I want to talk about, and generating images. We discuss the various topics, the overall themes and the narrative structure. I often get it to read previous posts I have written on the subject and it accurately and effortlessly summarizes them, extracting the core points, which is enormously helpful. It then generates a rough skeleton of the post, and summaries and images and example code snippets. At some point I decide we have covered all I want to cover and I write the post.

Do the posts sound like I wrote them? I am writing them, but there are times, like with the commit message summaries, when the list of stuff it has extracted or generated based on our conversation, where it's version is just better than what I could come up with, and I have to make a judgement call, and sometimes I just use the exact words it came up with because, it gets across the idea I want to communicate better. And that's what is most important in these technical tutorial style blog posts. I could spend an hour re-writing the entire thing so I came up with every single word and the grammar and punctuation, but you know what, imho that's just not the best use of my time, something which I have very very little to spare.

So that's the current situation. I'm guessing over time I will come up with better ways to work with the LLMs, and iron out the creases, but at the minute I'm sort of in this in between place where I'm not using them as freely in my blogging as I do in my coding, but I am using them. All that to say that if things sometimes sound a little off, well that's probably why.

Review and approve workflows

PR Review Gates

I‘ve written before about how useful Pull Requests (PRs) are when it comes to content creation, so no need to go into too much detail here again. Basically you can use PRs as content quality gates, a place to house changes before incorporating them into production, work on them collaboratively whether that's with humans or LLMs, run automated processes on said content, and finally safely merge the content into the main production branch.

You want to make content creation as frictionless as possible, using draft branches as collaboration sandboxes, but have explicit control on what makes it into production, and PRs are a tried and tested way to do that. The PR is an explicit decision point where you can promote or reject content, ensuring you not only have complete control on what ends up in production, but that you also have an audit trail should you later want to remember what changes were made along the way.

By using Git branches as flexible sandboxes and PRs as intentional quality gates, content production becomes both frictionless and reliable. You get the freedom to draft rapidly, alongside human colleagues and AI agents, without sacrificing total editorial control over what hits production.

Modern git powered content creation workflows

The last few days I wrote a several blog posts about git powered content creation workflows. I wanted something that I could point to that pulled together some of the main concepts, so somebody that was wanting to build such a thing would have a quick way to get up to speed on the possibilities:

  • Files, folders, exports, aliases and functions: Explores how to leverage standard OS primitives, flat files and directories, as a resilient, long-lasting storage layer. It details how combining shell exports, shortcuts (aliases), and custom functions transforms the terminal into an efficient, personalized computing and content workspace.

  • Templates, Markdown, and Frontmatter: Breaks down how to achieve frictionless document creation. Templates automate structural consistency, Markdown offers a clean and portable text formatting layer with HTML pass-through, and Frontmatter adds structured metadata for easy querying, SEO, and AI integration.

  • Git branches and remotes: Discusses why version control isn't just for code. It explains how using a small subset of Git commands, relying on isolated branches as safe drafting sandboxes and remote repositories for backups and syndication, creates a stress-free environment for human and AI collaboration.

  • Review and approve workflows: Highlights the power of Pull Requests (PRs) as explicit content quality gates. It shows how PRs function as decision points to promote or reject changes collaboratively, combining rapid drafting freedom with total editorial control before hitting production.

Discussion about Iran, Middle East, Europe, and US that I thought was very level headed, well thought out, worth a listen imho. I'd like to hear a similar podcast from a non-western world viewpoint. podcastindex.org #

Some annoying layout issues on the blog this morning. I had changed the styloing for code blocks yesterday to make the latest content creation posts look nicer, but it broke the layout on small screens. I think I managed to fix the issue, so things should be back to normal. #

Showing the last 1 active days.

For more content, use the navigation tree in the sidebar to explore the full archives.