Myrmornis

The string "writ" only occurs once in an article about how to develop ones ideas on non-trivial subjects. Pretty telling.

Does anyone really sit there thinking and make much progress? You write.

Thanks. I've bought it and started using it; it looks great. I was previously using Hyprnote which did work well, but yours appears to fit my "I just want markdown" case better and to generally be more polished.

I'll be wanting to find a good workflow to get the markdown transcripts into a git repo with file names that define a suitable sort order and also indicate what the meeting was. So would welcome your suggestions there. Not blocked of course, yo umake it easy to copy from clipboard or from the disk location and rename, but might be nice to have more control about where and how the .md lands.

I might email the support address on the off-chance that you're happy to have support/feature conversations like this. Thanks!

I will be happy to spend £10 on this. One feature question though -- does it continue transcribing the meeting even if I've turned my volume down / muted it?

> AI-generated papers could overwhelm peer-review systems with low-quality work

That's not a problem unique to math, or even to academia. It's a problem in every context in human life where people communicate via written documents.

> The problem was the view didn't work after something else had been done.

In that situation you have two choices:

1. Tell claude to iterate until the tests for the new view and the old views are all passing.

2. git reset --hard back to the previous commit at which all tests are passing and tell claude to try again, making sure not to break any tests.

It's essential to use tests when vibecoding anything non trivial. Almost certainly in a TDD style.

> I typed :rs pods to switch back to the pods view. Nothing rendered. The table was empty... > now something was fundamentally broken and I couldn't just prompt my way out of it.

Hey I don't want to over simplify, I'm sure it was complicated, but did the author have functional tests for these broken views? As long as there are functional tests passing on the previous commit I'd have thought that claude could look at the end situation and work out how to get the desired feature without breaking the other stuff.

TUIs aren't an exception, it's still essential to have a way to end-to-end test each view.

On the one hand I'm not sure Dawkins has read/thought enough about how LLMs actually work. I'm getting the impression he doesn't fully appreciate or is somehow forgetting that it's a text completion algorithm with a vast number of parameters and that even if the patterns of learned parameter tunings are not really comprehendible, the architecture was very deliberately designed.

But on the other hand his thoughts at the end are interesting. Summary:

Maybe our "consciousness" is like an LLM's intelligence. But if not, then it raises the question of why do we even have this "extra" consciousness, since it appears that something like a humanoid LLM would be decent at surviving. His suggestions: maybe our extra thing is an evolutionary accident (and maybe there _are_ successful organisms out there with the LLM-style non-conscious intelligence), or maybe as evolved organisms it's necessary that we really feel things like pain, so that evolutionary mechanisms like pain (and desire for food, sex etc) had strong adaptive benefits.

I don't think you read carefully what he said. At the end he gave three quite interesting thoughts about what might be true assuming LLMs are less conscious than we are (i.e. assuming our consciousness is not a purely algorithmic phenomenon as we obviously know LLMs are).

Your notes look really interesting, thanks. I'm curious --from the prose style it's clear they were written by an LLM. For design notes like this do you sort of have a mental TODO to go back and write them up in your own words to make sure they really capture your own opinions?

The article is still missing the most important point about a "trust system" -- you have to explain what it is and convince me that I even care about the problem you're trying to solve. It's my machine, what is a "trusted" or "untrusted" file? If people just force security "solutions" on me without asking me whether I understand or agree with their problem diagnosis then I will immediately disable the protection if I can or blanket accept all prompts without thinking.

This is good, but it doesn't go far enough:

> ... the problem with security measures that cause too much friction is that users tend to disable them in order to get on with their work. To fulfill its security purposes, a good trust system needs to stay out of your way.

Take a look at https://d2lang.com/examples/dagre/ and https://d2lang.com/tour/intro/

The language is richer and all diagram types are implemented consistently in the same language in a way that can be composed, as opposed to being a collection of unrelated DSLs.

The improved visual appearance is clear from inspecting example diagrams, I believe.

https://d2lang.com/ is a nicer language than Mermaid with much nicer visual appearance. It would be great if it became more widely supported.

I read the first couple of posts in the series. The essay is full of criticism of LLMs, and in a couple of places the author distances himself, as if he himself isn't using them ("some people I respect tell me that...").

It's certainly worth discussing the fact that the entire industry is starting to outsource large amounts of our thinking and writing work to non-sentient statistical algorithms, but this discussion needs to honestly confront the extent to which they are successfully completing useful tasks today.

This is really cool! Is there an alternative way of thinking about it involving a hidden markov model, looking for a change in value of an unknown latent P(fail)? Or does your approach end up being similar to whatever the appropriate Bayesian approach to the HMM would be?

Doubtless the current LLMs aren't the last word. But this author sounds like they would get more out of the current LLMs if they put their energies into that rather than into criticism.

The rounded corners are nothing compared to the notch camera making part of the top of my applications invisible.

Alacritty shows a preview at the bottom by default (sounds similar to ghostty). Looked to me like WezTerm doesn't though.

This is interesting but don't you worry that you're competing with entire companies (e.g. Anthropic) and thus it's a losing battle? Since you're re-implementing a bunch of stuff they either do in their harness or have decided it was better not to do?

Yes, they do, but the premise in my comment (and this discussion) is that a TUI is being written today.

TUIs built today should be usable by AI agents. I'm not sure exactly what it looks like but I'm imagining that every UI view has an associated CLI command that can yield precisely that view. Maybe like formally structured breadcrumbs, or maybe like Emacs "keyboard macros".

Ah right, sorry, you were making a much more interesting point than my reply! I read "UI development" and jumped to the conclusion that the point was just about inference-time modify-test cycles. Yes, agreed, if they trained on images, or even better (?) on (code, image) or (code-delta, image-delta) pairs, they would surely be better at UI development.

Getting them to take screenshots with playwright/puppeteer and look at them as part of their development iteration cycle works well.

> Markdown is already beautiful. We don't render it. We don't preview it. You read it raw, the way it was meant to be.

I don't want to be inflammatory or shallowly dismissive of other people's opinions. But I find this puritanical view surprising when we're talking about presenting markdown for reading by humans.

Take markdown links for example. In a terminal those should surely be rendered as OSC8 hyperlinks where supported: that gives actual link functionality, as well as being much more readable.

Or take markdown code blocks; to me it seems clear that they should be rendered with syntax highlighting, probably in a box or against a slightly different background color to set them off from the rest of the document. Triple backticks are for machines, not humans, surely? I don't think they're beautiful.

I don't know the history / lore of what is common mark vs non-standard addons etc. But github supports things like <details> tags; clearly it's no good just rendering that in plain text. A browser renders it well; not sure how to in a terminal.

Similarly tables should surely at least have padding added so that each column has constant width as you look down the rows, but promising to output it raw wouldn't do that since markdown itself has no such requirement. Which gets at my overall point: markdown is a format for capturing richer document data while writing; this should be rendered for humans to read.

Yes. But are you letting your agent make the decision of when and how to call that CLI? And presumably you're invoking it via the Bash tool. In which case your agent is free to write ad-hoc bash orchestration around your CLI calls. And perhaps you don't just have one such CLI but rather N for N different services.

And so we've arrived at the world of ad-hoc on-the-fly bash scripting that teams writing backend agentic applications in more "traditional"/conservative companies are not going to want.

Don't get me wrong, it's great for claude-code-type local computer automation use cases -- I do the same as you there.

Most of what the article says is true regarding coding agents, but articles like this are making a big mistake: they're completely forgetting that agentic applications aren't all claude code.

We're entering an era where many organisations will have agentic loops running in their own backends. There's a spectrum of constraint that can be applied to these apps -- at one end claude code running unsandboxed on your laptop with all permissions off able to cook up anything it wants with bash and whatever CLIs and markdown skill documents are available, and at the other end an agentic loop running in the backend of a bank or other traditionally conservative "enterprise"/corporate organisation. Engineering teams working in that latter category are going to want to expose their own networked services to the agentic app, but they're going to want to do so in a controlled manner. And a JSON-RPC API with clearly defined single-purpose tool-calling endpoints is far, far closer to what they're looking for than the ability for the agent to do wtf it wants by using bash to script its own invocation of executables.

The main problem with many IT and security people at many tech companies is that they communicate in a way that betrays their belief that they are superior to their colleagues.

"unlock innovators" is a very mild example; perhaps you shouldn't be a jailor in your metaphors?

Away from applied math/stats, and physics etc, not that many scientists use LaTeX. I'm not saying it's not useful, just I don't think many scientists will feel like a product that's LaTeX based is intended for them.

> the worst case scenario for a rebase gone wrong is that you delete your local clone and start over. That’s it. Your remote fork still exists.

This is absolute nonsense. You commit your work, and make a "backup" branch pointing at the same commit as your branch. The worst case is you reset back to your backup.

The article focused on the local stdio MCP tools used by coding / computer automation agents like claude code and cursor, but missed the fact that we will need protocols for AI agents to call networked services, including async interactions with long-running operations.