- reading-time:
4-5 min
Document your thoughts (with gptel)
Many teams use AI to “type faster”, either by using tools that produce ghost code or by practicing vibe
coding. But “building sovereign software” isn’t like building a house—where high-speed brick-laying does
shorten takt time. Determining “what” the (embedded) system should do and “how” the (technically complex)
software should interact takes a significant amount of time.
As engineering is mostly reasoning, typing speed is futile.
To speed up engineering, the real question is: How to use CodeAI to “think faster”?
Reason by writing
Even AI knows: to reason, you have to write. By putting your thoughts on paper or a whiteboard, you quickly discover the real challenges. In this phase, it is not about that perfect drawing—a sketch will do. Besides, unlike reading, thinking isn’t linear; maybe you start with a hypothesis, analyze it, and find new assumptions. Perhaps you discover a perfect solution after a few quick iterations. Or, you will continue circling in a few sprints from now.
To speed up that cycle, you can nowadays chat with AI. That coworker is always available and never displeased when you
make the same typo again and again.
Chats are sometimes seen as scaffolding: a temporary assembly that falls away once the final code is complete. That
can be correct for simple, short, self-documenting code. However, our (embedded) systems, lasting forever, also demand
documentation.
Either you write out those design papers yourself, or we need to summarize our reasoning. As AI does, after the
reasoning phase, it tries to formulate a comprehensive, clean answer. Typically, that is what you read. You only study
the reasoning for details and to check that the obvious —but non-working— solution is considered.
That is how we build great software systems: Keep it simple, but document that it’s not stupid.
Clean Chats
Chatting with an LLM via an app or web tool is convenient, but reading it back is often troublesome. When spending so much time producing words, it would be wonderful if it delivered clean documentation, showing the line of thought. And maybe support the design, especially to display that alternatives are investigated.
Let me give you two personal examples of why the current interfaces fail in that aspect. More than once, the web
interface tricks me, and I accidentally press ‘send’ instead of ‘newline’. Even as I ignore the partial
query/reply-pair, it does pollute the reasoning. Moreover, as LLMs are sensitive to
positional bias, that distracting part can confuse the LLM in the next rounds.
Secondly, I tend to ask side-questions in the same chat—who doesn’t? Very useful at the moment, but again, it does
not lead to clean documentation.
Both are human errors—Or not? Perhaps the interface is just a poor fit for the way we think and design. Aside from
that, as this pollution is added as context —which costs tokens and resources— it dilutes the LLM.
Even a feature as simple as ‘delete a few lines’ would be more than helpful.
Refactor your chats
Every engineer knows: code will rot unless you refactor it. Once in a while, you delete dead code, split a file, and
work on the structure. Nothing will change but readability. Sound engineers handle documentation in the same way.
AI chats are new assets, and clean chats deliver value. Therefore, we should be able to “refactor” —edit— our
chats. And store them, so they can be reactivated later (maybe in the next sprint, by your coworker).
Or do we consider chats as temporary—as items without value? Even then, clean chats are cheaper, faster, and help
the LLM to focus.
gptel and friends
IMHO, the power of an editor is needed. As the main LLM interface is text, your favorite editor should do. We only
need a small bridge between your editor and the LLM.
gptel, an Emacs extension, provides that. And similar plugins exist for all major (open) editors—see the sidebar.
Ultimately, you work in a buffer: you edit, write words, and restructure. And chat: gptel will send the text to the
configured LLM and insert the answer. As it works asynchronously, you don’t even have to wait.
Basically, it’s a chat! One that you control, as it’s your editor.
Now you can delete that “stupid question” —as well as answers without value. Besides, as it’s structured text (like Markdown), you can fold sections to keep an overview. Irrelevant (side) questions can be deleted —or maybe you prefer to move them to another, new chat buffer. I hope I don’t have to explain how to save it, store it in your archive, and reopen it —gptel will save some metadata to facilitate this (and you can even edit that).
Basically, you have refactored a personal sketch into a team asset! Your team and the future you will be grateful!
In this way, we can blend proven gear with new machinery. You hardly have to spend time mastering new tools. And gradually become more
productive, while keeping control.
This meta-interface can be extended even more, as we will see in upcoming columns.
See you soon; keep using your own synapses too — ALbert