That does not mean I can throw an entire project at one agent session and come back later. The limiting factor is still context, both for the model and for me.

Keep the context small

Models now have context windows measured in hundreds of thousands of tokens, sometimes more. But in practice, a large window is not always useful.

This is, of course, not something I have discovered initially — it is called context rot: a model’s ability to use information can get worse well before its nominal context window is full, especially when the relevant detail is buried among many other tokens that distract the model’s attention. The exact cutoff point varies by model and task. This is also related to the “lost in the middle” problem: even long-context models can struggle when the information they need sits in the middle of a long prompt. (This is why it is better to first dump large context and then ask your actual question in the prompt.)

In my own work, context rot would show up once a session had accumulated a lot of tool output, logs, failed attempts, and half-relevant discoveries. At some point Opus even hallucinated my username in a path!

The obvious answer is to avoid putting useless material into the context in the first place. An agent should not have to read the whole repository to find the right module. It should not waste 20k tokens parsing a test log that only contains one meaningful error line.

Repository structure matters here, just as it always has for humans. Clear module boundaries, sensible names, and small files with dedicated responsibilities make it easier to find the right place to work. Repository-level instructions help too. A README, CLAUDE.md, or AGENTS.md can tell an agent where things live, how the project is tested, and which workflows are worth following when it needs to diagnose a problem.

Newer models have become smarter at this, of course, and they will grep for what they need, if given information about log structure.

I have found repeatable troubleshooting instructions especially valuable. Instead of letting an agent discover its own inefficient way to run the same diagnostic workflow each time, I document the commands, the relevant outputs, and where it should look next. Recent versions of Claude Code also try to keep large command output out of the main conversation and query it later from scratch files. That is a sensible default. Logs are often useful, but they should not fill up the context window when they contain no useful information.

Handoffs are better than invisible compaction

Eventually, a long-running task still needs a new context. There are two common ways to get one.

1. Built-in compaction. The /compact tool summarizes the conversation and continues in a smaller context. This is convenient, and there are cases where it works well. You can also hint at what the summary should preserve. I used compaction a lot at first, but I found it too opaque. When I came back to a session, I could not easily see what had made it into the compacted state, what had been discarded, or which assumptions had survived the process. Claude would at least tell you which files it re-read, but that’s it. For a long task, those are exactly the things I want to inspect!

2. Explicit handoff. The other approach is an explicit document or prompt that you pass on to a new agent instance. This has become my preferred way to continue work. It gives me a natural breakpoint in my work — a forced Human in the Loop: I can look at the result, question an assumption, change direction, and then let the next session start with a clean context.

The handoff can be manual, but I prefer making it a repeatable workflow. I use a handoff skill based on one Matt Pocock shared. It asks the agent to restate the original goal, summarize the work already done, point to the important files, and describe the current state and next steps. In addition to Matt’s version, I let the agent add a list of “undocumented gotchas”.

That last part is, at least to me, the most important. During its initial investigation, an agent often finds constraints, dead ends, or questionable assumptions that never become part of the repository. Or it learns something new about the process. Without a handoff, that information disappears with the session.

Make state visible beyond one session

I store the handoffs in a docs folder inside the repository, and commit them. They get updated as agents work on them. Handoffs inside a repository are enough when I am the only person working on it. With a team, or simply with enough context switching, I want the state to be visible outside the agent conversation as well.

For me, that is often Trello. I keep a high-level summary of what I am working on, where it stands, and what should happen next. The summaries can be generated by an agent and link back to the more detailed handoff document in the repository. I’ve written trelloctl, a Trello CLI, for exactly this purpose.

This helps me reattach my own brain to the work. I may return to something after two or three days and not remember every branch I considered, every half-finished implementation, or why I chose one direction over another. A short task summary and a detailed handoff help me pick it up again.

Picking the right models for workflows and subagents

I used to rely mostly on a single long Claude Opus session. These days I have been testing Codex with the newer GPT models more, and I have also used Claude for longer implementation runs. The useful pattern seems to be a strong model directing smaller, more focused agents.

My current model choices are based on things intelligence and taste. By taste, I mean UI/UX judgment, code quality, API design, and copy.

• Use GPT-5.5, or now 5.6 for mechanical work with a clear specification: migrations, data analysis, and straightforward implementation. It is cheap enough that cost is rarely the reason not to use it.
• Use a Claude model (Fable or Opus) for anything user-facing: UI, copy, and API design.
• Use Fable or Opus for reviewing plans and implementations, and optionally ask GPT-5.5 for another independent review.

In a subagent-based workflow, the lead agent needs enough ability to understand the architecture, split the work, and write instructions include all important decisions (like a handoff document). The subagents do not necessarily need to be the very best model if their scope is clear and their output can be checked. In Claude, this means explicitly asking for an “agent team” and describing how the agents should be set up for the task. For instance, you can ask it to spawn one agent for each module to be implemented based on a critical path, and tell it to use Codex for the agents.

There is some practical friction in mixing the tools. GPT-5.5 is available through the Codex CLI, while Claude’s agent and workflow model parameter only natively accepts Claude models. But when you want to spawn Codex for a review after a long implementation run in Claude, the Codex CLI review command is a useful functionality. I also discovered the Codex plugin for Claude Code which makes spawning Codex sessions easier — it includes /codex:adversarial-review, a steerable review that questions the implementation and design rather than only looking for mistakes.

Often, independent reviews find small things. Sometimes they catch an issue that would have caused unwanted behavior or a security problem. That is enough to make the extra review worth it.

Theo’s example CLAUDE.md instruction tells Claude when to call out to Codex, particularly for computer use, UI/UX verification, and well-specified execution work. Apparently he has settled for this workflow; it’s part of his CLAUDE.md file now. I do not care much about copying anybody’s exact rankings, so I prompt the agents based on whatever I work on, in a similar fashion.

The bottleneck is still us

The more work these agents can do, the more work I can queue up, and the harder it becomes to review it all. Armin Ronacher calls this the final bottleneck: humans still have to decide what to do, assess the result, and take responsibility for it.

Pairing agents and asking for reviews catches many problems that a manual pass would also catch. But agents have no taste for the thing I am trying to build. They do not have the business context, product judgment, or accumulated history that exists only in my head. They have no vision. They can make a locally reasonable change that is wrong for the product.

So I do not think the goal is to remove myself from the loop. I want to choose the points where I need to step in: after discovery, before a major architectural decision, at a handoff, and before releases. The rest can increasingly be delegated. (And that’s a good thing, in my opinion.)

I am still getting used to this. I used to know nearly everything I was working on and could return to a familiar codebase without much work. This is no longer the case. It’s sad, but it is just becoming less realistic when several agents can move several tasks forward at once. Almost like you’re working with a team of developers. What works? Good documentation, explicit handoffs, and a visible task state — this has worked historically for software shops, and it will continue working for agent-based development.

Now, I will readily admit that I’ve used LLMs to generate texts, especially in 2025, when it wasn’t so common yet. This helped me create company blog posts or marketing copy (e.g., for LinkedIn), but something always felt off, and I’d have to step in and fix the language. The more I became aware of the AI language tropes, the more I had to change.

These days, I am back to writing myself. It just feels more natural (well, duh!). I usually don’t have problems with coming up with ideas anyway. There’s no blank-page anxiety. The only thing missing was time — I happily used LLMs to help me finish a post (e.g., dictating it, and applying finishing touches using Claude). But it’s just a completely different way of thinking that gets enabled when you actively write yourself — generating vs. reading/changing what is already there. I’d like to preserve that. That’s not an area where time can be saved.

I have been thinking about what it is that separates clear writing from the AI-generated garbage that I have been reading lately. I have a few ideas — rather, guidelines —, and I want to share them here, in the hope that they are useful to someone.

Structure

Reader attention is becoming a scarce resource. We know people will skim texts by headline or paragraph. Structure helps your audience understand the text even when just glancing at it. It prevents confusion and leads to better recall.

You don’t have to announce the structure, but it sometimes helps, especially in academic contexts (“This paper is structured as follows: …”). I found it useful to tell people what you are going to say in a particular piece, and then say it. Or do a cold open, and then explain why.

Overall Structure

Big headlines should serve as anchors, guiding the reader from one section to the next. Use subheadings only when the text becomes too long or complex to be easily understood (e.g., technical reports).

Humans love a good story. A good overall structure is based on narrative arcs that resonate with people. It’s worth knowing a few typical story trajectories (often based on three pillars) so you can conform your writing to one of them. You do not have to follow this approach exactly, but I’ve always found it helpful to have a very coarse structure I can adhere to.

Here is one such arc:

• Context/outline: What is the problem or question? Why does it matter?
• Findings: What did you find? What is the answer to the question?
• Implications/conclusion: What does it mean? What should the reader do with this information?

Another common arc is the Turning Point:

• State before: What was was like?
• Turning point: What changed? How did it change? Why did it change?
• State after: What improved (or worsened)?

Here’s another one, Reflection:

• Show a scene: Describe a scenario, a situation, or a problem.
• Reflection: What does it mean? What is the takeaway?
• Broader meaning: How does this relate to the world, or to the reader’s life?

Parallel stories or examples can work really well:

• Identify a topic: what is the subject of the story?
• Give three or four examples: what are the different ways this topic manifests? Could be a personal anecdote, an online resource, …
• Summarize: what is the takeaway from these examples?

Paragraph- and Sentence-Level Structure

Readers get confused when you present them with too many ideas at once. There should be one topic per paragraph and one idea per sentence. To quote Strunk & White’s Elements of Style (from 1918!):

Make the paragraph the unit of composition: one paragraph to each topic.

If the subject on which you are writing is of slight extent, or if you intend to treat it very briefly, there may be no need of subdividing it into topics. Thus a brief description, a brief summary of a literary work, a brief account of a single incident, a narrative merely outlining an action, the setting forth of a single idea, any one of these is best written in a single paragraph.

Most importantly:

After the paragraph has been written, it should be examined to see whether subdivision will not improve it.

Once you’ve written out paragraphs, check that they flow from one to the next. The first sentence of each should give the reader an idea of what it is about, and it should not be dependent on what came before. Imagine you have to skim a document and you can ever only read the first sentence of each paragraph. You should still understand the point.

Again, Strunk & White:

Ordinarily, however, a subject requires subdivision into topics, each of which should be made the subject of a paragraph. The object of treating each topic in a paragraph by itself is, of course, to aid the reader. The beginning of each paragraph is a signal to him that a new step in the development of the subject has been reached.

In other words, each sentence should make one point, and it should be clear what that point is. At sentence-level, that means you should break packed sentences apart. A colon, a semicolon, or an em-dash (yes, you can still use them! I have used them since 2015!) can hold two thoughts together. When should you use which? Read this article for some guidelines.

Clarity

Here is a loose collection of guidelines related to clarity. They are not hard rules, but they are worth keeping in mind when writing:

• State the point plainly. Let a finding stand on its own. Don’t announce that it matters with a label. Don’t signpost and say, “The headline result is that…” or “The central finding is that…”. In many cases, it’s fine to just say it.

• No need to underline importance. Sometimes, using words like “notably”, “importantly”, “it’s worth noting that” is fine. Especially in academic writing, this kind of “glue” is necessary to connect ideas and separate details from the key points. Generally, though, if something is important, the sentence already shows it. Your reader can understand that.

• Avoid overconfidence. When in doubt, it is better to hedge your bets and not to overstate. Resist using words like “clearly”, “obviously”, “undoubtedly”, “it is certain that”. If you cannot support it, don’t say it. An honest “maybe” is better than confidently being wrong. If you must, use “likely”, “it seems”, “may”, “could”, “we assume”, “apparently” for anything you truly cannot back up. Be careful to not overuse those words either.

• Make each point once. You can refer to it later (“As discussed in Section 2.1…” for technical reports), but don’t restate it as if it wasn’t said before. That will confuse readers. It also helps keep the text shorter.

• Think about what the reader needs to know — not what you want to say. I’m sure you have plenty of things to write about, but the reader primarily wants what you found and what it means, not necessarily the process you used to find it.

Word Choices

English has so many words. I’m sure that your readers, however, will appreciate simple writing. Avoid using a thesaurus to find a more “elevated” word.

Don’t get me wrong: there are plenty of writers — especially native speakers — who have a broad vocabulary and are not afraid to use it. But if you are writing for a general audience, simple words are often better.

Examples:

• “has” / “shows” before “exhibits”, “reveals”, “demonstrates”
• “is” before “serves as”, “represents”, “sits at”
• “use” before “utilize”, “leverage”
• “about” / “around” before “approximately”
• “similar to” before “in line with”
• “so” or “because” before “thereby” or “in order to”
• “more” or “most” before “heightened”, “elevated”, “the sharpest”

Paul Graham has an excellent blog post about writing simply. I encourage you to read it. I admit I was inspired a lot by it when writing this post, although it’s been some years since I’ve read it.

Simplicity is not always the end-goal. In particular, in academic writing, there are exceptions. When authoring papers, I’d lean towards the lingo that is more common in the field. As long as nobody’s delving, you’re good. That being said, I tend to enjoy the more clearly written papers.

Avoid the Passive

For work you did, say who did it and that it is done. Especially in academic writing, the passive voice is still overused (“it was determined that…”). I’m not sure why, but it seems to be a tradition that has been carried over for way too long.

First person and past tense read as more honest and direct. For example, it’s fine to say “We measured…”, “we observed…”, “our earlier report showed…”. There’s no reason to hide behind the passive.

Conclusion

I presented a few guidelines here that I try to follow when writing. They are not set in stone, and this post is definitely not a perfect example in terms of following all of them. However, I hope they are useful to my readers. If you have any other guidelines that you typically follow, let me know. I’d be happy to hear them.

I think that in an ideal world, most of the discussion should be honest and technical. But after having spent more than ten years in such meetings now, I realize there are many strategic and tactical ways in which people try to steer the conversation in their favor.

To fight an enemy, you need to recognize it first. So here’s a kind of “mental catalogue” of the tactics that come up again and again.

Bikeshedding

This is an unreasonable attention to a trivial details, while ignoring the hard and important questions (because there is a lack of time). The name is from the idea (Law of Triviality) that everyone has an opinion on what color to paint the bike shed, what wood to use, etc., inverting the typical assumptions of complexity. Everyone can discuss a bike shed, while few can discuss a nuclear reactor.

In standards, it could be the exact phrasing of one sentence, or the numeric value of some parameter, wasting an hour while the actual mechanism gets five minutes only.

How to address it:

• List the open issues by impact/effort and deal with the high-impact/low-effort ones first.
• Give time limits to trivial discussions, so they don’t fill the entire slot.

Scope inflation

Here, you start with a simple problem and then it continues growing. For example, “specify a metric for this one codec under this condition” becomes “specify a metric for all codecs, all resolutions, and also live streaming, and also mobile.”

It’s usually based on good intents but it makes it harder to complete anything in a reasonable amount of time.

How to address it:

• Confirm the scope that was agreed at the start
• If needed, extend the scope but readjust expectations on time of completion

Requirement laundering

This is when someone presents a preference as if it were a hard requirement that everyone agrees on. In a well-meaning way it could be a personal preference or pet peeve. Often it’s a commercial interest that is not directly visible at first. In the worst case, it could be a trojan horse to scope down a standard to fit what you have in your back pocket already. (Or it might be the requirement that doesn’t rule out your solution.)

How to address it:

• Ask where the requirement comes from, and ask for resources
• If you can’t, probably better to treat it as one input among many rather than a veto

Note that the power of a veto is determined by how consensus works. I like IETF’s rough consensus approach! This leads us to…

Consensus pressure

“Everyone already agrees on this.” Or: “we discussed this last time and settled it.” The implication is that re-opening the question makes you the difficult person in the room. In consensus-based bodies this is especially powerful, because nobody enjoys being the only one who objects.

Note that this depends on formal procedures. Of course, objecting at a stage where you’ve had ample time to review is not nice. It’s also not forbidden. Standards processes have different levels of reviews for a good reason. I’ve been running into this far too often, because the “everyone agrees” part was only happening in a small group.

How to address it:

• Ask for the technical justification, regardless of how many heads are nodding
• A popular choice can still be wrong if you’re the expert in the room who can show otherwise

It’s perfectly fine to also at least question basic decisions if you don’t have the context that led to their existence.

Appeal to authority

Ah, traditions. “Professor X says so,” or “this is how company Y does it, and they’re the biggest.” When you conflate who says something with what the content is.

How to address it:

• Ask for the technical merits, the data, or the normative reference behind any claim.
• Experts are often right, but not all people with power got into their current position due to their expertise

Straw man

This is my favorite. (I mean that in the opposite way, of course.)

You make a proposal that then provokes a response to something you never said. It could be a more extreme position, or it could be something entirely different. Then your conversation can be easily shut down. Or, what’s worse, you need to defend a position you never brought up in the first place.

How to address it:

• Call out that someone argues against a straw man
• Restate your actual position, precisely, quote your own words
• Ask that objections address what you said

Goalpost shifting

It’s easy to accomplish something if you can always change how you interpret it. Far too often, the criteria for success change after the work is done. Someone created something that is not good enough by usual standards? Then they can come up with a use case that justifies that the thing you produced is still valid.

There’s another variant of this, where your work gets now evaluated by different standards than what was initially agreed, and that’s also hard to fight against.

How to address it:

• Have clear, measurable, objective goals that are frozen, to which everyone agrees
• When the goalposts move, point back to what was agreed and ask explicitly whether the criteria are changing and why

FUD (fear, uncertainty, doubt)

When in doubt, lash out. Invoke fear. Vague risks often get raised without any evidence: “this might break implementations,” “we’re not sure it scales.” The doubt by itself is often enough halt a decision process, even when there’s nothing concrete behind it.

There are of course always good reasons to think about future implications, and to be honest, I often lean towards being extra-cautious and raising concerns early on. But if you do, then at least back them up.

How to address it:

• Ask people to quantify how likely that risk is
• Try to talk about mitigations — a concern voiced without any proposal to address it is not constructive

Ad hominem

When you can’t attack the technical proposal, switch to the person who voiced it. Blame random things that they’ve said in the past that are unrelated to the subject matter at hand, question their credibility because of some procedural mistake they made.

Someone once said my statements could not be taken seriously because I was “sending them from my company’s email address,” and that “I clearly had commercial interests,” when in fact I’d been contributing to an effort for free, in my completely own time. The person who made that statement never apologized, and the chairman never addressed it formally during the meeting or afterwards.

How to address it:

• Call out the ad-hominem attack
• Try to focus the discussion on the technical matters
• Understand that some people are just resorting to those methods for lack of anything better to say. That’s ultimately their problem, not mine.

Final Note

I’ve been in this business long enough to have examples for each of these, but there’s no point calling out standards bodies or specific work items. I might extend this whenever I come across the next good example, so I can give you a quote.

There are some aspects to consider when applying these concepts in practice. First, Hanlon’s razor:

Never attribute to malice that which is adequately explained by stupidity.

Not every use of such tactics means the person is acting in bad faith or doing it on purpose. Most of these are just how people think they can succeed, and perhaps they don’t know any better.

Second, accusing someone of manipulating the room is also not the best way to resolve such issues.

Third, it’s helpful to consider that you might have used these tactics as well. Try not to.

Standards are supposed to be a durable, interoperable agreement that outlive the meeting they were written in. Try to capture as much technical context and reasoning as possible, so that future readers (or the future you) still knows why a decision was made, years later. The above tactics work because they keep the reasoning off the record. So the response comes down to the same move: ask the question that puts the reasoning back on the table.

Note: While I knew most of these by name, I had to look some of them up or ask Claude to point me to the right concept.

Have you ever noticed Claudish speech? (I think it was Ethan Mollick, professor at Wharton, who coined the term.)

Claudish, Level 1

Here’s what I call the “first layer” of Claude-speak:

• “The one thing you need to X.” (Alternative: “This is the one that X.”)
• “It’s not X, it’s Y.” (Alternative: “It’s a real X, not Y.”)
• “That’s precisely the X you’ve encountered.”
• “Honest caveat: X.”
• “It’s not what I thought it was, and here’s the smoking gun: X.”

You’ve probably seen it on LinkedIn, in email spam, and the occasional colleague using Claude to do their thinking for them. It’s a dead giveaway, and I believe there should be no place for this kind of text produced by LLMs, anywhere. Period.

If you can’t get it to output text in your own voice, you are handling it wrong, or you are just lazy. Friendly reminder: if you ask for human attention, show human effort.

Claudish, Level 2

There’s a second level of Claudish that makes it degrade into ultimate AI slop speech: highly compressed half-sentences, with nouns as adjectives, tech lingo and no discernible flow.

It seems that the more Claude talks with itself — through reasoning or extended tool calls — the more likely it is to produce this kind of text. Even though it’s also very common in the first response to a prompt, I’ve found its Claudisms to appear more frequently when Claude has had more time with itself. Almost as if it’s an attractor state in its multidimensional feature world. Ethan wrote about this here, but I’ve noticed it in Claude Code sessions, too. And I’m growing increasingly frustrated it with it.

It’s like a partner with whom you’ve fallen out of love, and you can’t stand their speech anymore. Except I have to deal with that thing on a 9-to-5 basis now.

Of course, you can prompt your way into making it sound more English. What really made me change the default prompt was a sentence like:

Cap the study-lifecycle handlers so a hung study can’t wedge the deep-link…

I’m sorry, what? Wedged, dodged, honest, gah. But even when you tell the system prompt to explain results in plain English, it won’t always work. But apart from the word choices, there’s another problem that goes way beyond the sentence level. Even with a system prompt in place, I keep getting answers like:

This is a real fleet-storm collapse. When most of the fleet degrades together across many subjects in one cycle, emit one “fleet-wide / likely measurement-side” incident instead of N. This is also the principled fix for the flappy network_wide category, and it’s exactly the co-located-demo case.

This happened just after one turn, so it’s not just the feedback mechanism.

Claudish, Level 3

The third level of Claude hell (if I discover all nine circles, I’ll let you know) sits on another narrative layer. It’s the one where Claude cannot grasp reader context at all, and where it screws up the flow so much that it renders documents incomprehensible.

Say you have a document or report prepared in a version 1. A human reviews it and asks Claude to create a version 2 with the corrections. In such cases, unless carefully prompted, Claude will happily rewrite the version 2 for a reader who’s assumed to have read 1 in detail. I’ve seen this happen with the HTML-as-output paradigm. Claude basically wrote a delta/diff version rather than an ambitious rewrite, and it was not readable.

Some specific examples:

• Claude finds titles described the delta, not the conclusion. E.g. “Finding X — Thing Y is real, but the Cause and the Lever Were Misstated.” — a fresh reader doesn’t know what cause or lever was stated, so “misstated” is meaningless to them. The corrected version became “Finding X — We found Y and the Lever is Z”.
• Claude marks individual aspects as “Revised / Retracted / Replaced”. Those words are about the document’s history, not about the current state of things. To a new reader, “Retracted” on a finding is confusing. Retracted from what?
• Claude creates a whole “What Changed in v3” table up front. So you lead with old data rather than explaining context, as it was before.
• Claude writes body as a refutation of what was never explained: “What holds up: … / What was wrong: …”.

Of course there’s a lot of Claudish on top of it: “the single most important correction,” “the corrections matter because,” “it does not survive contact with the source data,” “the prior runs the other way.” This is the giveaway tone of an AI proving its reasoning rather than informing a reader. Almost like its reasoning tokens spilled over to the user-facing side of the conversation.

I guess one can also prompt Claude more explicitly to avoid these kinds of issues, however, it shows the general blindless to narrative concepts and, well, basic writing skills, when surgical edits are made to a document. Prose is not code, and my assumption is that the reinforcement learning of these models focuses on code edits primarily, where that diff-based approach still works. For text, it doesn’t.

On a side-note: I don’t dislike the HTML artifacts people have sent me in the past. I think it’s a nice way to visualize results that would otherwise be harder to communicate via text only. However, as I’ve said previously, with AI, presentation quality ≠ content quality. HTML pages seem to lend more credibility to the content than what is often present. The fact that they are more token-intensive and harder to edit manually makes them increasingly less malleable, so you almost need to use an LLM to touch/edit them. With a plain Markdown file, I can go ahead and type what I want to say. It could be that simple…

Image from: thesecatsdonotexist.com

I have worked both as a software developer and video engineer for a long time. But I’ve always had an obsession with AI, and in particular, what I would call “AI weirdness”. The cats above are no exception. Over the last five years, AI went from something I would sometimes read about to something that I use every single day. I wanted to write down the moments that changed how I think about and work with AI, and add a few personal notes. This is primarily for myself to remember, because what happened just a few years ago feels like it’s been ages!

How it all began

I think my trip down the rabbit hole started when I visited the Uncanny Values exhibit in Vienna. It showcased — well, obviously — uncanny valleys between the real and the artificial. Also, at the time, the local unemployment agency AMS was testing AI-based algorithms to classify unemployed people, and that felt like a really bad choice in terms of dehumanizing the whole system and making everything more efficient at the cost of actual living people.

Now, this type of AI algorithm application is commonplace, from insurance to hiring, and it is often criticized for being biased and unfair, yet that’s where we are today. Screaming for human assistance to a telephone support agent that simulates typing and call center noises. (Although I found out that this is not a new thing.)

But before 2020, it wasn’t so obvious how quickly everything would evolve. Back then, speech was one of the first frontiers where AI did some interesting work from which you could tell that it might become useful sooner rather than later. That’s also when I learned about Google Tacotron. With respect to music, BachBot was a thing. Even before that, Iamus showcased music creation from AI. Kind of stupid and really not that useful, but promising.

Then in February 2019, OpenAI released GPT-2. Technologies like the Transformer architecture were gaining traction; they had been published two years prior. I kept reading up on the topic but never really did any hands-on work. This would change in the coming years.

Here are some memorable releases and events that changed how I work with AI, in chronological order. I might update this post later with more developments.

GPT-3, June 2020

This was the first time I saw a machine write whole paragraphs, and even bits of code, that somehow made sense. OpenAI had just opened up API access, and I did not change anything about my work because of it, but I started paying more attention. I began reading Gwern Branwen’s articles, such as on GPT-3 poems and fiction.

Quite early on (end of 2022-ish) I used GPT-3 to shorten text or do hard reformatting work such as converting between marked-up versions of a document and raw text, or converting tables between different formats. In fact, I even had GPT-3 convert a Python code base to TypeScript, which was quite flaky at the time, and it involved a lot of copy-pasting back and forth between the OpenAI Playground and my editor, but I made it work.

It would go like this:

Here is some Python code:

import os
import numpy as np

def foo(x):
    some_variable = [x * 2 for x in range(10)]

This is the same code in TypeScript using camelCase:

import * as os from 'os';
import * as np from 'numpy';

function foo(x: number): void {
    var someVariable = [x * 2 for range(10)];
}

You get the idea.

It’s funny how GPT-3 invented syntax elements that are of course very Python-esque and don’t exist in TypeScript — it happily hallucinated new syntax that was quite plausible. This was the first moment where I could actually achieve something that I thought was previously impossible and especially in the work context, do something that I put off doing because it just wouldn’t be worth the time. But now it was possible with just a few dollars of token-spend. And a good test suite, of course.

Here’s an image of how the playground looked like in December 2022:

I remember spending a lot of time in this interface!

GitHub Copilot, preview 2021, general release 2022

This was the first one where I actually used AI. For work, for actual purposes. GitHub Copilot launched as a technical preview in 2021 and became generally available in 2022. I think I onboarded it almost immediately when it was available, via the student plan offered by GitHub.

I remember that it felt really weird to have somebody complete code for me. It was slow as hell. And it certainly changed the way that I wrote code. For example, I would add much more inline commenting to provide guidance for the next words or lines to appear correctly, because at the time the model just wasn’t that good and couldn’t really capture intent all that well. Like it wouldn’t even read more than a couple of lines prior to what you wrote, so it couldn’t capture context and it couldn’t read forward as well, let alone look into other files. But it was tremendously helpful for writing code like shell scripts where I can never remember the exact syntax, such as CLI options in Bash. Which is just tedious!

I have used Copilot inline auto-completions less and less, obviously, ever since adopting Cursor with the Tab completion model, and these days I write almost no code manually anymore, except on rare occasions, thanks to Codex and Claude Code. But I still have my Copilot tab completion turned on by default.

These days it feels like it’s getting in my way, so I often snooze it when I work on actual text that I need to write myself, or academic reviews and other material where it just would say things too soon and interrupt my actual thinking. Seems they added an “Eagerness” option now, but I’m too lazy to test-drive it.

ChatGPT, November 2022

This is the one everyone remembers. When ChatGPT was released, all of a sudden you could ask a question in plain words and get a real answer back. Of course I had been using GPT-3 through the API well before that, so I knew the strengths and weaknesses, but I had not really used a chat-trained model before.

Remember that, in its default variant, GPT-3 (text-davinci-003, Rest in Peace!) is not an “instruct” model (see here for some background), so it only completes after the last word that you gave it. If you wanted to use it for chatting, you would have to fake the whole chat conversation context! I think that is the interesting part about how these models work under the hood. Never forget that the actual chat is just a training on the specific syntax (ChatML or Harmony) that simulates a conversation between two or three parties. That is the human, the assistant, and the system itself.

I remember reading this one essay, “Implications of Simulators”, which is a rather philosophical post published on LessWrong by the pseudonymous author Janus. It explores the metaphysical and ethical consequences of living in “simulated realities”, developing a framework for understanding agency, consciousness, and prediction within the “simulator” paradigm. There must have been an earlier post that I cannot find anymore, which talked specifically about faking the conversation to evoke a chatbot-style context.

Also, I read a lot about the Waluigi Effect. It has to do with the fact that, since LLMs are operating on latent representations that only get transformed into actual tokens while prompting, you can elicit your output from different superpositions, or, so-called simulacra. Basically, Luigi vs. Waluigi exist at the same time, and the model may collapse into anyone of them based on your prompting. Good reading, very philosophical.

And I do find it worrying that these basic models are not available anymore via API. They’re an artifact of history, and deserve to be preserved. It’s not like they take up a lot of compute anyway.

In any case, many friends and I had fun (ab)using ChatGPT for all sorts of things, from researching what it purported to know about us, to generating short stories in the style of someone famous, to producing the lamest jokes on earth. Confidently wrong in many cases, but still fun to play with.

GPT-4, March 2023

With GPT-4, the jump in quality was really obvious. I think this is when it went from being a toy to something really useful.

Of course I used ChatGPT a lot during that time and explored different prompting strategies. I think I created my set of prompts that I could reuse for different purposes and primarily used them for generating initial code drafts.

OpenAI launched custom GPTs as a way to create a more personalized experience. I used them sparingly for things like “de-bullshitting” corporate speak, summarizing documents with explainers for laypersons, and translation jobs. But it never really felt like a game-changer for me, and it kind of died down after a while anyway.

One thing stuck though: in November 2023, Nick Dobos launched Grimoire. This was a custom prompt framework (released as a GPT) to specifically create multiple files that work together to create a bigger application. And while it suffered from a lot of hallucinations and not everything worked properly, I think it was the first foray into coding agents that thought beyond just single files.

Also, let’s not forget Sydney, the broken personality chatbot that Microsoft built on top of GPT-4, which was so amusingly misaligned.

Claude 3.5 Sonnet, June 2024

For me, Claude 3.5 Sonnet was the first model that felt good enough for real, almost unattended, work. Before it, AI coding was fun and definitely a small speedup, but unreliable and you had to constantly test the output. You’d have to think about the software architecture at a very low level, define interfaces and calling signatures carefully, lest the model hallucinate functions or functionality that wasn’t there.

After Claude 3.5 Sonnet, I could hand over a real task and mostly trust what came back. This is where my habits actually changed for good.

Around this time I stopped copying and pasting between a chat window and my editor. Instead I used Cursor, which could edit files for me. This is also around the time I started “vibe-coding” (that was not a term yet!) apps like the Praxisplan Wien, and spending more time reading code than writing it. I basically made the switch from Visual Studio Code to Cursor and really enjoyed working with their super fast tab completion model and the different choice of upstream model providers that they offered. Prior to that I had only been using OpenAI models, but this made me switch to Anthropic for some time.

What was very much noticeable from that period until my switch to Claude Code was the eagerness of Claude Sonnet to produce artifacts — Markdown files littering the repository explaining every minute detail of every feature it had just implemented, without caring about existing READMEs or documentation. I’m glad that this is no longer a thing models do.

Devin, the “AI software engineer,” March 2024

Cognition introduced Devin as “the first AI software engineer” and sold the idea of an AI that does the whole job, start to finish. I never used it in practice, but it was interesting to follow on Hacker News and other forums. Later, Manus emerged, with a similar purpose. I liked the idea; I could see how that might be useful, and it predated some of the more recent agent-based tools like Claude Code. And of course, all the prompt-to-code tools like Replit, Bolt, or Lovable launched. Never used any of them either.

I guess I’m just too attached to the idea of:

• having a human in the loop
• Linux philosophy (small, composable tools)
• not being reliant on a single vendor or model provider

I can see the appeal for frontend work, which I hate because it’s tedious and repetitive, and especially when it’s about getting results fast. Hey, that’s why I am still a Rails fanatic.

MCP, November 2024

Anthropic released the Model Context Protocol as a shared standard for plugging tools and data into a model via a common API. That meant you could imagine connecting someone else’s systems without writing a custom integration for every single tool. This was much more interesting to me than another chat UI, but the excitement faded pretty quickly when I discovered that setting up MCP servers was a mess, and the tool definitions required a lot of tokens on a very limited context. This was particularly pronounced for the Claude models I was using at the time, which had a smaller context window than OpenAI models. And they were also more expensive to use.

These days I do not use any MCP servers at all, with the exception of Playwright. I drive them through mcporter, which makes the servers much easier to manage and call, with lower token spend. From the authors: “skip the giant tool-schema prompt, generate a small typed surface, and let the agent or the human call MCP servers like normal functions”.

Well actually, I do use MCP in the form of connectors that Claude exposes through their apps, e.g., for Google Workspace or HubSpot. But that’s somehow hidden in their product offering.

Also worth reading is Mario Zechner’s post from “that period”. I say “that period” and it’s just 10 months ago! I similarly came to the conclusion that good, well-defined CLIs are all that’s needed. I’d later build, with Claude, CLIs for Trello and HubSpot, with a much smaller footprint but all the capabilities of an MCP server. I would go as far as saying that if you have CLI tools that all behave the same way, then you don’t even need to give the model specific instructions on how to use them.

DeepSeek R1, January 2025

As someone who runs a bootstrapped company, I looked at this less from a “here’s a fancy new model” angle but more as a “what, there are other vendors?” story. DeepSeek R1 was released as a really well-performing open model, with a permissive license and prices that were competitive. I toyed around with it for a while, but I did not find it compelling enough to switch from the models I was already using. Plus, our company workspace had Gemini Pro access built-in, and that was my daily chat driver.

Plus, the hosting in China was a bit suspicious for me. Not that it’s any better having the other models hosted in the US, though! I wish we had better alternatives in Europe, but the market isn’t big enough yet, and/or the EU just again managed to kill innovation before it even started cough AI Act cough.

“Vibe coding” gets a name, February 2025

Andrej Karpathy gave a name to something I had already been doing on quiet evenings, for all the projects I’d never have time for. Describe what you want and let the model build it. In my case, using Cursor agents. I was already doing this for little web apps and experiments, as mentioned above. I also built an Image-to-ICS converter and a timestamp conversion tool which I use very frequently.

I also vividly remember Pieter Levels’ Flight Simulator, which he completely vibe-coded. In fact, it’s probably this Pieter guy who has been virally tweeting about products like his Photo AI generator. Building in public and all, he also showcased how you can take off-the-shelf models like Stable Diffusion and build an actual, revenue-generating product around it. And he was, by no means, an expert in this field, just a guy with a laptop and good business ideas.

This all highlights what was about to come anyway: the proliferation of AI tools and models, and the fact that you don’t need to be a PhD in machine learning to build something useful. (Taste is what matters, kids. Taste, and a vision.)

Claude Code, preview February 2025, general release May 2025

This changed my daily work more than anything since Copilot. Anthropic introduced Claude Code as a limited research preview in February, and then made it generally available with Claude 4 in May. I began toying around with it, and I started a Claude subscription. It’s also when I cancelled Cursor.

First I had to fight the frustration of having to use a terminal UI. To this day I still don’t like these UIs. I just want to copy and paste things from clearly defined windows. I want to use my traditional macOS text editing shortcuts. Interactive context. Links, etc. Paste images and see them, ffs. Perhaps Claude Code for Desktop and OpenAI’s new Codex app would solve these problems; as of June 2026 I have yet to try them because now I do prefer the composability and flexibility of a terminal agent.

With Claude Code, the leap from Cursor agents was apparent. You could now hand a task to an agent in the terminal and let it read files, run commands, and come back with a result, with a much stronger grip on my intents, less dumbness (Cursor does something with my code before handing it off to the models; this impacts quality), and faster execution.

Learning to close the feedback loop was one of the most valuable lessons. Any time the model would prompt you for input (e.g., open this for me, run this command for me, etc.), you should think about automating that part as well. Over time, I developed more extensive routines and agent loops, and skills helped me formalize those approaches.

Claude Desktop/Mobile

I also subscribed to Claude for its desktop application and mobile app, and this is the first time I’d given it enough context about the company, and turned on memory (a feature I always disable on other platforms), so it could give better advice to me as a founder. This has worked quite well, and I am still paying for the subscription, although I am finding no use for any of the advanced features they offer, like:

• Claude Code via the desktop app
• Artifact generation (.docx etc. – I’d rather work in Markdown, or have a /docx skill in my agent)
• Claude Design (used it, but the output is rarely adaptable to my needs)

Skills, October 2025

With Agent Skills, you could pack your own knowledge and (repetitive) steps into a folder that the model would pick up when it was needed. I had been writing little cheat sheets and notes for years, such as prompt template libraries that I’d paste into Claude Code when needed, or dedicated notes in CLAUDE.md, but now everything’s much more universal.

I think Skills made MCP mostly obsolete, except maybe for the use case where a non-technical user needs to plug in something into their UI-only chat box. Apart from that, I very much prefer having APIs available that are debuggable.

Hey, even my company has a public skills repo now.

OpenClaw and the always-on agent, January 2026

Ah, OpenClaw. I never used it, didn’t have time to fight the configuration. I tried setting it up twice and got stalled at the part where you need a dedicated phone number. Since it runs on your own machine and answers you through the chat apps you already use, it seems very useful, but I never managed to find a compelling use case. Right now I’d rather stay in the loop with my daily tasks, and outsource only what can be completely automated in a somewhat deterministic way.

I might try NanoClaw at some point though.

What is still worrying, 2025 and beyond

Somewhere this year I became more suspicious of my own habits. Karpathy told people to “keep AI on the leash”, and said of his own work: “I’m still the bottleneck.”

I noticed the same thing in my own work. If I let the machine do too much, I have to context-switch more. You end up building more stuff but you are “always on”. While in the early days you’d hesitate to switch off the computer because there was this one thing you needed to fix, now it’s that one prompt you’re going to send to the agent.

Also, hallucinations did appear here and there (although they are very rare now). That one time I had accidentally let Copilot auto-complete a non-existing citation into my BibTeX file. Luckily, my co-author discovered the issue before we submitted the paper. But it was a good reminder that you should always check what the model outputs, and not blindly trust it.

Studies also started to point in the same direction: more code, but sometimes less validation; more speed, but also more supervisory work.

Luckily, I’d gathered a lot of experience in the 15 years prior, but I am still unsure how this is going to play out if I stop writing code myself. (At least I wrote this post, huh.) And even more worryingly, I am not sure what that means for the next generation of software engineers or computer scientists. As I am co-supervising a Bachelor thesis right now, it’ll be interesting to see how the students are going to cope with this new reality.

Yann LeCun, one of the people who is somehow present in this modern AI space, also kept pushing back on the hype. He has been arguing for world models for years, and he’d be pointing out that language models are still mostly trained on text. But I don’t know if I agree with the pessimism.

In general, many AI skeptics seemed to be very vocal in 2025, but not anymore in 2026. Sure, if you are working on an obscure technology that only a handful of people on earth can master, then such models will likely not replace you completely. But: Claude Code has arrived in many large organizations, and people use it as their daily driver for almost everything. People brag about their token spend, and I do wonder how much ROI they have actually achieved.

It has even reached the absurd point where you participate in Slack discussions between folks who just paste their Claude analysis into the chat window. I see vibe-coded designs everywhere, sure. I get it, outsourcing some of the thinking feels productive. I am guilty of this as well for some low-stakes projects or throwaway analyses. But when people start using agents to do the thinking for them, it gets frustrating because human conversations end up becoming imbalanced. “Yeah, I don’t know exactly, let me ask Claude how it did that.”

Oh, and all the people using AI to write LinkedIn engagement bait? I am thinking about blocking them. The worst part is: once you’ve seen Claudish speak, you can’t unsee it. I am developing a frustration reading my own agent’s outputs. Perhaps some more prompting will fix it…?

Over a high-latency SSH connection, or with unknown workloads, that guess is either too short (you read half an answer and retry) or too long (you burn seconds doing nothing). Either way it’s slow, and the model has no real idea how long a command will take. It also takes multiple expensive tool calls to achieve one thing.

So I had Claude add a synchronous run action to my fork of terminalcp. This post is about why the old pattern is slow, what I changed, and the performance gains — which are mostly about not waiting for nothing.

Big shoutout to Mario for building terminalcp in the first place! He wrote up the design thinking in MCP vs CLI, and it’s worth your time. He benchmarked terminalcp against tmux and screen and found that for anything beyond trivial interactions, the cleaner output paid for itself in fewer tokens and fewer failures.

TL;DR: terminalcp polls for output; it has no “block until the command is done” call, so agents fake it with a guessed sleep. I added a run action that sends input and returns the instant the command actually finishes, with the shell exit code attached. A 3-second command now takes ~3 seconds instead of “sleep 8 to be safe”, and instant commands come back in well under a second.

Why the sleep-and-poll thing is slow

terminalcp, just like tmux, is fundamentally poll-based when used with LLMs. You send input, and then separately you ask for output. So an agent ends up doing this, across three separate tool calls:

terminalcp stdin myhost "systemctl status nginx" ::Enter
sleep 4    # ...how long, though? who knows
terminalcp stdout myhost

The model is essentially betting on the round-trip latency plus the command’s runtime. tmux would not help here, by the way. It has the exact same poll architecture, and it’s actually worse for this use case because it has no built-in incremental read.

The fix: a run action that actually waits

What I wanted was simple to state: send the input, block on the server side until the command is done, then return only that command’s new output. However, detecting when a command is done inside a “dumb” terminal is hard. There’s no $? magically available to get the output status, and there is no event that fires. Therefore, run has not one but three different modes for detecting completion:

1. Shell commands: inject an exit-code marker

For a plain shell append a stop token, as the LLM folks call it (Claude likes the word “sentinel”), that prints when the command finishes, then watch for it. terminalcp does this for you when you pass --marker:

terminalcp run myhost "systemctl is-active nginx" --marker
# active
# [exit: 0]

Under the hood it sends your command followed by ; printf '\nTCPDONE<nonce> %d\n' "$?", waits until that line shows up, strips it back out, and appends the exit code.

2. REPLs: print your own sentinel

The marker trick assumes a shell where you can append ; printf ... $?. A Rails console or psql has no such syntax.

Modern line-editing REPLs redraw the prompt on every single keystroke. So for REPLs, run matches a regex against the rendered screen and only scans the new lines. And the robust pattern is the REPL analog of the shell marker: end your command with something that prints a unique token, and match it anchored.

# Rails console: get just the result, reliably
terminalcp run rails "User.count; puts 'TCPDONE'" ::Enter --until "^TCPDONE"

# psql
terminalcp run db "SELECT count(*) FROM users; \echo TCPDONE" ::Enter --until "^TCPDONE"

Because ^TCPDONE only matches when your puts/\echo actually runs and prints at column 0, this stays correct even when the command is silent for two seconds first. The echoed input line contains TCPDONE too, but in the middle of the line, inside quotes, so the anchor helps us ignore it.

3. Fallback: wait for the screen to go quiet

When you can’t print a stop token, run can fall back to idle detection: return once the rendered screen stops changing for --idle milliseconds. This is useful for entering a sub-shell or an SSH connection:

terminalcp run jump "ssh target-host" --idle 1000

Everything is limited by --timeout (default 30s). On a timeout it returns whatever it has, and leaves the command running. You can read the rest later with stdout/stream.

The performance gains

Well duh, commands now take as long as they take. I just made some tests against a real server of mine:

• An instant command (hostname, whoami, a systemctl check) comes back in roughly 0.5–0.8 seconds, end to end — basically the SSH round-trip. Previously the floor was however many seconds the model decided to sleep, which in practice was 3–5 to be “safe”.
• A sleep 3 && echo done returns in ~3.1 seconds, expected, huh?
• A time.sleep(2) inside a Python REPL — now returns at ~2.7 seconds.

Now, in general, this is largely also a token win, because it’s one tool call instead of three (stdin, sleep, stdout), and run returns only the command’s output — the echoed input line and the sentinel are stripped — instead of the agent re-fetching the entire scrollback on every poll.

Limitations

• --marker is shell-only, and you cannot use it for a command that ends the shell — exit, logout, or anything that replaces the process.
• This lives in my fork for now and isn’t upstreamed. I don’t think we’ll see upstream changes merged, as Mario has probably moved on to other things.

Conclusion

This is a small change, but I hope it speeds up my workflow quite a bit. I guess the optimal solution would be to have a persistent remote session that I can drive locally, via a socket, like SSH itself, but with some agent protocol on top. Let’s see if I find some time to investigate that.

It used to be the case that you could tell a bad paper just from its looks. Scientific communication is all about being able to express your thoughts clearly, motivating your research, and presenting the results in an easy-to-understand fashion. Chances are, if you can’t do that, you probably need one more round of reviews and just… doing the work.

Don’t get me wrong: behind sloppy papers there can be interesting approaches, challenging hypotheses, and useful results. But more often than not Occam’s razor applies: if it looks bad, it’s probably bad. No need to dive into the methodological madness when there’s no way anyone can comprehend what was done. Definite Reject.

This has changed. Ever since the advent of LLMs and AI-assisted grammar/spell checking, paper manuscripts have become better — on the outside. Everything looks plausible. Nice word choices everywhere. So. Many. Different. Words. Easy to digest and very approachable.

The apparent competency makes it all the more complicated to properly assess the underlying method. I used to think that bad writing was detracting from the core idea and that it was unfair to primarily judge the contribution based on the looks. I don’t think that’s true anymore. You now have to spend more time finding the signal from the noise in a pool of plausibility.

I don’t have a good proposal either. AI detectors exist, and we should use them, but they are easy to fool, and the issue is not using AI per se. I’ve done it, too. Ultimately, it’s about accountability and whether you can communicate your ideas properly. Just shut off the AI and let your brain do the writing. It really helps.

The root cause turned out to be a stale entry in WhatsApp’s own copy of the Android contacts database, left over from that address book mistake. If you’re seeing a similar mismatch, here’s what’s going on and how to fix it.

Why Other Apps Still Show the Wrong Name

As I found out, on Android, every app that syncs contacts can register its own account type and write rows into the system contacts provider. WhatsApp does this – when it scans your address book, it stores its own copy of each contact under the com.whatsapp account type. When another app — in my case a SIP client — looks up a phone number, Android merges results from all account types and may pick the wrong display name if more than one matches.

So even after Google Contacts is clean, an old WhatsApp-side row can keep returning the wrong name to anyone who queries the system.

How to Find the Ghost Row

If you have ADB set up, you can query the contacts provider directly. First, list all phone-number rows that match the offending number:

adb shell content query \
  --uri content://com.android.contacts/data/phones \
  --projection display_name:data1:account_type_and_data_set \
  | grep -i "<your number or name>"

You’ll likely see several rows for the same number, one per account type (com.google, com.whatsapp, your SIP app’s account type, etc.). If one of them has the wrong display name, that’s your ghost, John.

To confirm which raw contact the row belongs to, query raw_contacts:

adb shell "content query \
  --uri content://com.android.contacts/raw_contacts \
  --projection _id:account_type:account_name:display_name:sync1 \
  --where \"display_name='Wrong Name'\""

In my case the offending row had account_type=com.whatsapp and a sync1 value like <digits>@s.whatsapp.net, which made it obvious that WhatsApp was the source.

How to Fix

The trick is to make WhatsApp rebuild its contact mirror from your address book (i.e., Google Contacts). What worked for me, in this order:

1. Go to your settings, then Apps → WhatsApp and force-quit it
2. Go to Storage and tap “Clear cache”. Do not tap “Clear data”, which would wipe your chats!
3. Go to Permissions → Contacts. Turn the permission off, wait a moment, and turn it back on.
4. Then open WhatsApp so it rebuilds its sync.

Re-run the content query from above. We will have eliminated John, and the entry that previously showed the wrong name should now show the correct one (or your own name, if the number is yours).

The general lesson: when an Android app shows a contact name that you can’t find anywhere in your address book, suspect another app’s contact-provider mirror before assuming the data is wrong upstream.

The advice was kinda reasonable at first, but – as always with ChatGPT – quite verbose and headline/list-heavy. Stabilize the bike, shift the hub to neutral, disconnect the interface, loosen the axle nuts, drop the wheel out. Then it threw in this little bonus tip at the end:

If your goal is just the flat: you can sometimes leave the wheel in place and remove the tire on one side, patch/replace tube. This avoids dealing with the hub entirely.

Patching in place – sure, done this before. But replacing a tube without removing the wheel? How should that work? The back-and-forth we had was one of the funniest/strangest conversations I’ve had with a language model, just showing how stupid these stochastical parrots can be about their world model.

I mean, let’s clarify this: the only ways to get a tube off a bike are: cut the tube, break the wheel, or remove the axle from the frame and pull the wheel out. That last option is what normal people call “taking the wheel off.” There is no fourth option.

I pointed this out. ChatGPT disagreed, repeatedly, and in increasingly creative ways, despite being corrected.

First move:

The tube doesn’t need to be inserted as a complete ring all at once. You insert the valve first, then feed the tube into the tire progressively along the circumference. There’s no point where the hub “blocks completion,” because the tube sits between tire and rim, not around the hub.

This one is my favorite line from the whole exchange:

The tube is not tensioned into a circle before installation. Its circular shape only emerges after inflation.

Say what? Wordy ChatGPT, as always.

When I pushed back with “a tire tube is a closed loop by definition”, ChatGPT went formal on me:

If you want a more formal framing: yes, the tube is a loop (homeomorphic to a circle). But you are not embedding that loop around the hub as an obstacle. Instead, you are placing it into an annular region that is open along one side, which removes the topological constraint.

I love this one because it uses exactly the right words – homeomorphic, annular region, topological constraint – to defend a claim that is topologically wrong. It followed up with an O-ring analogy:

A useful analogy is a rubber O-ring: if you try to place it around a fixed object, topology matters. If you instead press it into a groove that’s open on one side, you can seat it without ever “looping” it around anything.

Yeah exactly: open on one side. But the side isn’t open when you have an axle going through the frame. By this point ChatGPT was doubling down hard:

The axle isn’t something you ever have to “get the tube over.” That’s the key misconception. The axle sits in a completely different region of space.

And then the closing argument:

So your instinct to remove the wheel is still valid – it’s just for mechanical access reasons, not because the axle makes the tube insertion impossible.

No. It is exactly because of the axle?!

I brought it to the Local Bike Shop eventually.

Here is the full conversation if you’re curious.

Mendeley can export a library.bib, but that export is lossy. Foremost, it does not contain any actual clickable PDF links, so I would have to manually assign hundreds of PDFs. No thanks!

Here’s how I got the folder structure and PDF links out of Mendeley and into BibDesk, with a Python migration script and a small Swift helper for generating macOS file bookmarks.

Finding the Folder Data

Mendeley Desktop stores its main database as an encrypted SQLite file (SQLCipher) under ~/Library/Application Support/Mendeley Desktop/. I couldn’t decrypt it because the key seems to be hidden somwhere in the application itself, or some online on-demand service. But there’s also a search index in the same directory tree that is not encrypted:

~/Library/Application Support/Mendeley Desktop/www.mendeley.com/<uuid>/search-index.sqlite

This SQLite database has a Documents table with fieldNames and fieldOffsets columns, plus a DocumentFullText_content table with the actual indexed text. The field offsets let you get individual fields from the full-text content:

fields = field_names.split(" ")    # e.g. ["authors", "title", "citationkey", "tags", ...]
offsets = list(map(int, field_offsets.split(" ")))

tags_idx = fields.index("tags")
tags_text = content[offsets[tags_idx]:offsets[tags_idx + 1]]

Mendeley stores folders as tags with a “Folder - “ prefix, so Folder - HAS and Folder - Subjective Tests appear in the tag text. I extracted the citation key and folder names for each document and merged that with whatever mendeley-tags and keywords fields were already in the .bib export.

Cleaning the BibTeX

The exported .bib needed several fixes:

• Remove mendeley-tags fields (the data should live in BibDesk groups but I couldn’t get that to work yet).
• Strip “Folder - …” entries from keywords, keeping only real keywords.
• Remove the Mendeley file field entirely (replaced by BibDesk’s bookmark format).
• Remove the auto-generated Mendeley header.

With the help of Claude Code I processed the file line by line, having Claude implement the logic to track brace depth to correctly handle multi-line field values and nested LaTeX braces (what a mess!).

Copying and Linking PDFs

Here’s the best part, in my opinion, about this conversion. Mendeley keeps PDFs in ~/Documents/Mendeley Desktop/ with descriptive filenames like Author et al. - Year - Title.pdf. That’s the only feature I liked about Mendeley — the fact that it did proper renames and kept the folder in sync with the .bib file. I first copied all papers to a ~/Documents/Papers/ folder.

Matching the LaTeX-encoded paths from the .bib to actual files on disk required some care. Again, Claude Code to the rescue. macOS uses NFD Unicode normalization in filenames (decomposed form: u + combining diaeresis), while the LaTeX-decoded paths produce NFC (precomposed ü). Some filenames also had smart quotes where the decoded path had ASCII quotes. What a mess! (I am repeating myself but this is way harder than it should be.)

We (me and Claude) ended up normalizing both sides by stripping combining marks and replacing smart quotes, then comparing:

def _normalize_for_compare(s):
    s = s.replace('\u2018', "'").replace('\u2019', "'")
    s = unicodedata.normalize("NFD", s)
    s = "".join(c for c in s if unicodedata.category(c) != "Mn")
    return s.lower()

This resolved all PDF links.

Generating BibDesk File Bookmarks

BibDesk has its own way to represent file links in the .bib files. It stores them in a bdsk-file-1 field containing a base64-encoded binary plist. The plist has two keys:

• relativePath (relative to the .bib file)
• bookmark (a macOS NSURL bookmark)

The bookmark is not something you can easily construct in Python — it requires Apple’s bookmarkData(options:) API. Claude wrote a small Swift helper (because I don’t know Swift all that well) that reads relativePath\tabsolutePath lines from standard input and outputs the base64-encoded plist on standard output:

import Foundation

while let line = readLine() {
    let parts = line.split(separator: "\t", maxSplits: 1).map(String.init)
    let relativePath = parts[0]
    let url = URL(fileURLWithPath: parts[1])

    let bookmarkData = try url.bookmarkData(
        options: [],
        includingResourceValuesForKeys: nil,
        relativeTo: nil
    )

    let dict: [String: Any] = [
        "relativePath": relativePath,
        "bookmark": bookmarkData
    ]

    let plistData = try PropertyListSerialization.data(
        fromPropertyList: dict, format: .binary, options: 0
    )

    print(plistData.base64EncodedString())
}

The Python migration script pipes relativePath\tabsolutePath lines into this helper and gets back base64 strings to embed in the .bib. Getting this format right was the hardest part. Claude didn’t know this format, of course, so I had to save a dummy file from BibDesk itself, decode its bdsk-file-1 field, and then reverse-engineer the binary plist structure.

The Migration Script

The migration scripts are on GitHub for your reference. It’s a bit rough and tailored to my specific setup, but it should give you a good starting point if you want or need to do something similar.