Working on the loft blog

This is Jurjen Stellingwerff’s blog, in his voice. Read this before touching a post.

Whose words these are

  • The author gives the subject, the reasoning and the word use. A post says what he wants to say, argued the way he argues it, in words he would use speaking to someone.
  • An agent helps; it does not author. Welcome help: language corrections, ordering, tightening, suggesting content or an example that supports his point, checking that a fact is true. Not welcome: a new argument, a new thesis, or prose that replaces his voice.
  • Nothing is published until he has approved it — and possibly rewritten it into something he can see himself saying to others. A draft is a proposal, never a finished post.
  • Suggestions are offered, not applied. Propose a change with the reason for it; apply it only when asked. Corrections he asked for (spelling, grammar) may be applied directly.
  • Keep facts few. A post points readers at loft-lang/loft for the detail instead of carrying numbers that go stale.

What the blog is about

The project — loft, the games and the libraries built with it, and how they are made. A post is about the designs, the way of working and the goals, not about loft’s current state: where it stands today goes in at most as the direction it is moving (“not quicker than rustc yet, already quicker in some places”), never as a status report or a table of figures. AI is a big part of how it is made, so it runs through the posts, but general AI commentary is not why the blog exists: every post is about this project, and anything said about AI is shown through it.

Two convictions of the author’s run under the series, in his words:

  • Using AI is not about giving it a prompt and something magical will suddenly occur. It is a constant process, a struggle, to get where you want to go.
  • The quality of a project created by AI is directly related to the person behind the keyboard. There will be a project either way, but without a clear vision and skill it will be low quality — and that is not the fault of the AI.

A post shows them through what happened in the project; it does not lecture them.

How a post is made

The first post went this way, and it is the method:

  1. The author’s notes. He writes the subject and his reasoning as rough notes — what he wants to say, in his own terms, however unpolished.
  2. A proposal. The agent turns the notes into a draft that keeps his points, his order of thought and his framing, and may suggest examples or structure that support them.
  3. His corrections of substance. He says where the draft misses what he meant — for the first post, what “inexperienced” really means and what his own role is — and the draft follows his meaning, not the agent’s reading of it.
  4. His rewrite. He rewrites the draft into words he would say himself. From here on the text is his.
  5. A review, not an edit. The agent checks his version — spelling, grammar, a sentence that says something other than he means, a fact that is wrong — and lists each finding with a suggested fix. It changes nothing until he says which to apply.
  6. Approval, then publication. Only the version he approved is committed to _posts/.

Mechanics

  • At most two posts a month. Count the month’s posts in _posts/ before proposing a draft; when the month is full, gather the material for the next subject into the notes folder and write no draft until the author starts it.
  • A post is _posts/YYYY-MM-DD-title.md with layout: post and title: front matter; the README has the template. GitHub Pages builds the site from main.
  • Posts are CC BY 4.0 (LICENSE); code samples in posts are MIT.
  • Planned subjects and their sources are in the author’s private notes, outside any repository: blog/blog-subjects-and-ideas.md in the notes folder $LOFT_NOTES names. The author’s rough notes for a post and the agent’s notes on a draft (sources, fact checks) sit beside it there, never in this repository.
  • A draft post is _drafts/title.md (no date): Jekyll does not build it into the site, but the repository is public, so a committed draft is readable on GitHub. It moves to _posts/ only once the author has approved it.