Andreas Gohr: Linkblog [splitbrain.org]

Ein KI-Agent, der Ihre Software von innen kennt

Wed, 30 Sep 2026 00:00:00 +0000

Ein KI-Agent, der Ihre Software von innen kennt

In der Softwareentwicklung arbeiten wir täglich mit KI-Agenten und wissen, wie nützlich diese Werkzeuge sein können. Doch auch in anderen Bereichen sind diese Systeme nützlich. Unser Wiki zum Beispiel hat einen eingebauten Agenten. Er beantwortet Fragen mit Wissen aus dem Wiki und mit Daten aus unserer übrigen internen Software. Für einen Kunden haben wir ein ähnliches System gebaut, das komplexe Auswertungen aus der Vertragsdatenbank erstellt.

Da lag die Idee nahe, einen solchen Agenten in jede Webanwendung einzubauen, die wir für unsere Kunden betreuen: ins TYPO3-CMS genauso wie in individuell entwickelte Fachanwendungen. Überall dort, wo Mitarbeitende im Backend Inhalte und Daten pflegen.

Das Ergebnis ist James - Ihr Butler fürs Backend.

Ein kurzes Video, das James vorstellt.

Was ist James?

Wir schreiben nicht nur Software für unsere Kunden, sondern unterstützen sie auch im laufenden Betrieb der Anwendung. Denn egal, wie gut die Software ist: Im Betrieb ergeben sich Fragen. Hier setzt James an. James ist ein Chat-Assistent, der direkt in die Anwendung eingebaut ist und dort hilft, wo gearbeitet wird: im Backend. Er ist für die Menschen gedacht, die sich in der Anwendung anmelden, um Inhalte und Daten zu pflegen, zum Beispiel den Redakteur:innen in einem CMS.

James ist also kein Chatbot für die Besucher:innen der Website. Wer die Seiten liest oder im Shop einkauft, bekommt ihn nie zu sehen. Er ist für die Menschen da, die mit der Anwendung arbeiten, nicht für die, die sie von außen nutzen.

James hat Werkzeuge, um den Quellcode der Applikation zu lesen, und kann in die Live-Datenbank schauen. Zudem kann er über den Browser der angemeldeten Nutzer:in “sehen”, was dargestellt wird. Zudem lassen sich weitere Informationen wie das Nutzerhandbuch oder Fachwissen hinzufügen. Damit hat James dieselben Werkzeuge zur Verfügung, die auch wir nutzen würden, um eine Anfrage zu beantworten.

Wichtig ist dabei, dass der Agent nichts “kaputt” machen kann. Er darf zwar den Quellcode und die Datenbank lesen, hat aber keine Werkzeuge, um Änderungen durchzuführen. Gegebenenfalls kann er natürlich erklären, wie eine Anpassung durch die Nutzer:in selbst vorgenommen werden kann.

Wofür ist das gut?

Das Tolle an Agentensystemen ist, wie flexibel sie mit nur einer Handvoll Werkzeugen einsetzbar sind. Für James ergeben sich einige Anwendungsfelder.

Direktes Hilfesystem

Fragen zur Bedienung und zum Zustand der Applikation sind die naheliegendsten Aufgaben.

“Wie lege ich eine neue Veranstaltung an, die nur für angemeldete Mitglieder sichtbar ist?”
“Warum erscheint mein Artikel von gestern nicht auf der Startseite?”
“Wie kann ich einer Kollegin Schreibrechte für den Pressebereich geben?”
“Warum hat Bestellung 4711 noch keine Rechnung bekommen?”

James bietet hier eine direkte Zeitersparnis. Statt sich auf der Suche nach der richtigen Stelle durch die Anwendung zu klicken oder am Ende sogar bei uns nachfragen zu müssen, kann James die Antwort direkt liefern.

Spontane Auswertungen

Oftmals möchte man etwas über die Daten in der eigenen Software wissen, das über die Oberfläche in dieser Form nicht ausgegeben wird.

“Welche Kunden haben im letzten Jahr mehr als dreimal bestellt, aber seit sechs Monaten nicht mehr?”
“Wie hat sich die Zahl der Neuanmeldungen pro Monat seit Januar entwickelt, getrennt nach Region?”
“Welche Seiten wurden seit über zwei Jahren nicht mehr bearbeitet und von wem stammen sie?”
“Wie viele Verträge laufen im nächsten Quartal aus und welchen Umsatz machen sie zusammen aus?”

James kann die Daten dabei nicht nur zusammensuchen, sondern über eine eingebaute Bibliothek für Balken- und Liniendiagramme auch gleich grafisch darstellen.

James ist dabei für die schnelle Frage zwischendurch gedacht, nicht als Ersatz für ein richtiges Auswertungswerkzeug. Zeigt sich, dass eine Auswertung immer wieder gebraucht wird, ist es sinnvoller, die Anwendung entsprechend zu erweitern.

Der große Überblick

Eine eingebaute Bibliothek für Schaubilder (Mermaid) erlaubt es James, auch mal eben Datenflüsse oder Zusammenhänge grafisch zu visualisieren.

“Zeig mir, welche Schritte eine Bestellung vom Warenkorb bis zum Versand durchläuft.”
“Welche Rollen gibt es im System und wer darf was?”
“Wie hängen Produkte, Kategorien und Angebote zusammen?”
“Was passiert alles, wenn sich jemand für den Newsletter anmeldet?”

Fehlermeldungen und Änderungswünsche

Keine Software ist perfekt und manchmal stoßen unsere Kunden auf unvorhergesehene Probleme. James kann das Problem analysieren und einen technischen Bericht für CosmoCode erstellen - egal, ob es sich um einen Fehler oder eine fehlende Funktion handelt.

Wir sparen Zeit bei der Analyse des Problems und unsere Kunden Geld, weil die Fehlerbehebung schneller geht.

Software

James ist in Go geschrieben und enthält in einem einzigen Programm alles, was nötig ist: einen eigenen Webserver, das Backend, welches die Werkzeuge bereitstellt und mit dem Sprachmodell (LLM) spricht, sowie das Frontend für die Ausgabe. Dazu gehört eine Konfigurationsdatei, die festlegt, wo der Quellcode und andere Informationsquellen zu finden sind und wie die Datenbank anzusprechen ist.

Dieser Aufbau macht James unabhängig von der Programmiersprache und dem Framework der eigentlichen Anwendung, die es zu unterstützen gilt. Egal, ob ein PHP-basiertes TYPO3 oder eine individuelle Django-App: Am Ende muss nur ein kleiner JavaScript-Schnipsel integriert werden, und James steht allen authentifizierten Nutzer:innen zur Verfügung.

Die Konfiguration und Integration übernehmen wir natürlich.

Was noch kommt

Hat man James erst einmal im Einsatz, ergeben sich schnell neue Ideen. Mit weiteren Datenquellen könnte James zum Beispiel auch solche Fragen beantworten:

“Welche Seiten werden am häufigsten besucht, sind aber seit Jahren nicht aktualisiert worden?” (mit Daten aus Matomo oder Google Analytics)
“Bei welchen Suchbegriffen verlieren wir gerade Plätze bei Google?” (mit Daten aus der Google Search Console)
“Welche Kunden aus dem Shop haben ein offenes Ticket im Support-System?” (mit Anbindung an weitere Systeme)

Welche Erweiterungen wir zuerst umsetzen, entscheiden die Rückmeldungen unserer Kunden. Sie haben eine Idee oder möchten James in Ihrer Anwendung ausprobieren? Sprechen Sie uns an!

Jaw literally dropped. I ran the prompt from the "Made entirely with Opus 5. ...

Fri, 25 Sep 2026 06:03:47 +0000

My HTML Boilerplate

Fri, 11 Sep 2026 05:41:29 +0000

When HTML was first created, a document could be very simple indeed. A valid document could look like this:

<TITLE>HTML document</TITLE>
<H1>Heading</H1>

<P>This is a paragraph with a <A HREF="https://example.com/">link</A>.

It wasn’t until HTML 2.0 – the first formalised standard – that a proper document structure came into being. A DOCTYPE declaration to explain a document’s type and to handle compatibility became an expected inclusion, as did head and body sections:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<HEAD>
    <TITLE>HTML document</TITLE>
</HEAD>

<BODY>
    <H1>Heading</H1>
    <P>This is a document.
</BODY>

In the years since HTML 2.0’s 1995 debut, the web has changed massively. However, there is a saying in the web standards world: ‘Don’t Break The Web’. There are some exceptions, but on the whole a website developed at the web’s inception should work in a modern browser, regardless of how much time has passed. To keep this compatibility, however, risks making changes impossible for fret of breaking existing sites.

One way the web combats this is with certain elements that are expected in HTML documents. If the element is present, then it uses the new functionality. If not, it simply falls back to the old functionality. Pair that with what different integrations and systems across the web expect, and it means that there is rather a lot of ‘boilerplate’ – code that is repeated across almost every new or maintained site. HTML boilerplate commonly both opts in to modern functionality and also sets site preferences and details. Assorted things such as how the site should embed on social media, what styles should be loaded, how the browser should theme surrounding the site, and other such details.

Boilerplate

Much like I maintain my own CSS reset, which provides me a clean slate for my styles, I maintain my own boilerplate, which I use as a base structure and reference when creating HTML documents. Much like my CSS reset, it is very opinionated. Here it is in full:

<!doctype html>
<html lang="en">
	<head>
		<meta charset="UTF-8">
		<meta name="viewport" content="width=device-width">
		<meta name="text-scale" content="scale">
		<title>Name of Page | Name of Website</title>

		<link rel="stylesheet" href="/styles.css">

		<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

		<meta property="og:title" content="Name of Page">
		<meta name="description" content="Description of this page.">
		<meta property="og:description" content="Description of this page for embeds.">

		<link rel="icon" type="image/svg+xml" href="https://example.com/favicon.svg">

		<meta property="og:image" content="https://example.com/embed-image.webp">
		<meta property="og:image:alt" content="A picture of something.">
		<meta property="og:image:type" content="image/webp">
		<meta property="og:image:width" content="1200">
		<meta property="og:image:height" content="630">

		<link rel="canonical" href="https://example.com/page">
		<meta property="og:url" content="https://example.com/page">

		<meta property="og:site_name" content="Website Name">

		<meta name="author" content="A N Other">

		<meta name="color-scheme" content="light dark">
		<meta name="theme-color" content="red" media="(prefers-color-scheme: light)">
		<meta name="theme-color" content="green" media="(prefers-color-scheme: dark)">

		<link rel="alternate" type="application/rss+xml" title="RSS feed of posts on Website Name." href="/posts/feed.xml">
		<link rel="alternate" type="application/feed+json" title="JSON feed of posts on Website Name." href="/posts/feed.json">

		<link rel="search" type="application/opensearchdescription+xml" title="Website Search" href="https://example.com/opensearch.xml">
		<link rel="manifest" href="/app.webmanifest">
	</head>

	<body>
		<header><nav></nav></header>
		<main id="main"></main>
		<footer id="footer"></footer>
	</body>
</html>

Breakdown

It should be noted that there is order to my HTML boilerplate. The order of the document head in particular has great influence on performance. Capo.js is a brilliant tool for evaluating the order of elements in a document’s head from a performance perspective.

<!doctype html>

This is the document type declaration for the living HTML standard, as introduced in HTML 5. I always include it to avoid falling into quirks mode.

<html lang="en"></html>

Opens the html tag which wraps the document and defines the document language using an RFC 5646 compliant tag with the lang attribute. The language provided the default for the full page and can be overwritten on a per-element basis. Providing the language is important for automatic translation, typography such as hyphens, and for assistive technologies (especially screen readers).

<meta charset="UTF-8">

The first element I place in the head is always the charset meta tag with a value of UTF-8, which is the only valid encoding as of HTML 5. It is always top of the head, as it must occur within the first 1024 bytes of a document, and it should be before any elements liable to get mangled.

<meta name="viewport" content="width=device-width">

When the first iPhone launched in 2007, it rendered desktop sites with the expectation of the user to zoom in and pan around. Apple introduced the above meta tag for sites that were actually optimised for mobile, and it was eventually picked up more widely across browsers such that now it is supported widely to make a site responsive.

Many people will include initial-scale=1, however, after extensive testing and research, I’ve identified that it isn’t necessary to include any more. It can be included to change the page’s presentation if an element horizontally expands beyond the viewport width, but that should never be allowed to happen and I advise against it.

minimum-scale, maximum-scale, and user-scalable all greatly harm accessibility and should never¹ be used. They should generally be stripped from sites whenever noticed.

<meta name="text-scale" content="scale">

Makes text scale in accordance with the system setting. If this tag is present, then a page’s styles must expect it and be written accordingly. This is especially important to avoid accessibility pitfalls with content scaling.

<title>Name of Page | Name of Website</title>

The title of the page. It is a required value which is shown on many surfaces. It is used as the name of the page when bookmarked, the name of the tab in search engines, and anywhere else a name for the page is needed. I’ll generally show the page title followed by the site’s title.

<link rel="stylesheet" href="/styles.css">

Whatever styles must be imported can be imported here. Styles should generally be imported in the page head rather than using the @import CSS at-rule within a stylesheet to avoid a waterfall, where the stylesheet must first be fetched to then fetch additional stylesheets.

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

Complex variable fonts can be rather large in size, even after subletting and other optimisations, so I preload fonts that I know will be used on the page. Even if a font is located on the same-origin, the crossorigin attribute is still necessary. I always serve fonts as WOFF2, as it is the most performant widely supported font format.

<meta property="og:title" content="Name of Page">

The og:title is used for embeds, such as those seen on social media. It is one of the many metadata values of the Open Graph protocol. While I’ll typically include the site name at the end of the <title> element, I leave it absent in the og:title. In the majority of cases embeds will show the domain or og:site_name next to the title, rendering it a duplicate.

<meta name="description" content="Description of this page.">

I mainly treat this meta description field as an exercise in search engine optimisation. Previously major search engines would expose the description to users on search pages, however they mostly fetch directly from the document itself now.

<meta property="og:description" content="Description of this page for embeds.">

The og:description is sometimes shown in embeds. If absent, embeds usually forgo a description or fall back to the meta description. I like to write short, often quippy content here that strikes intrigue and fits in social media or chat feeds.

<link rel="icon" type="image/svg+xml" href="https://example.com/favicon.svg">

A favicon is an important bit of branding for all websites – especially when it comes to identifying tabs when you have many open. I serve favicons as SVGs, as they’re well supported, can be made to dynamically adapt to light/dark mode, look good at all sizes, and remove the need for maintaining a set of raster favicons in different sizes.

<meta property="og:image" content="https://example.com/embed-image.webp">
<meta property="og:image:alt" content="A picture of something.">
<meta property="og:image:type" content="image/webp">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">

The image defined in the og:image is often shown in a site’s embed on the likes of social media or chat platforms. It is advantageous to include on almost every site, as it adds context and usually increases an embed’s size for better presence. Support for alt text on embedded images is middling, so it shouldn’t be relied upon. Some sites support it, some ignore it, and some support it in odd ways. I make the effort to include it but keep it brief. 1200px by 630px is a widely supported size, and WebP is the best supported of the modern image formats I’ve tested.

<link rel="canonical" href="https://example.com/page">
<meta property="og:url" content="https://example.com/page">

A canonical link to the authoritative version of the page is important for indicating what should be considered the source of truth. This is especially important if content is duplicated.

<meta property="og:site_name" content="Website Name">

The name of the website to be shown in embeds. As aforementioned, some embeds will show this name near the page’s title.

<meta name="author" content="A N Other">

The author tag obviously indicates the author of a page. It isn’t strictly necessary but is useful for developers to identify who is responsible for a page.

<meta name="color-scheme" content="light dark">

Setting the color-scheme meta tag with a content attribute value of light dark tells the browser that a site supports both light and dark modes. Having it defined in the head prevents a Flash of Unstyled Content (FOUC), such as a screen of bright white when the site and browser are set to dark mode.

<meta name="theme-color" content="red" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="green" media="(prefers-color-scheme: dark)">

Used for theming the browser chrome of sites installed as progressive web apps (PWAs) and for theming the browser chrome in Chrome for Android (but only in light mode). Some other browsers also interpret these values in various ways. I use the media attribute to set the colour independently for both light and dark modes.

<link rel="alternate" type="application/rss+xml" title="RSS feed of posts on Website Name." href="/posts/feed.xml">
<link rel="alternate" type="application/feed+json" title="JSON feed of posts on Website Name." href="/posts/feed.json">

If a site has syndication feeds, then including these in the head permits autodiscovery of them.

<link rel="search" type="application/opensearchdescription+xml" title="Website Search" href="https://example.com/opensearch.xml">

If a site has integrated search functionality, then establishing an opensearch.xml file and referencing it from your document head exposes it to browsers so they can provide a rich searching experience. The exact experience differs by browser, but in many cases it allows searching with a site via the browser’s own address bar and also provides a simple way to add a search engine.

<link rel="manifest" href="/app.webmanifest">

I’m a progressive web app evangelist. I love them, and many sites benefit from being PWAs, even if a site is not a typical ‘app’. I’ll define a manifest for most sites even if the only benefit is that the presentation is nicer if people add the site to their homescreen. This declaration helps browsers discover the manifest.

<header><nav></nav></header>
<main id="main"></main>
<footer id="footer"></footer>

This defines any site’s general body structure. The header holds a navigation element for general site navigation. The main holds the primary page content and has an id attribute to provide an anchor, which is important for ‘skip to’ links. The footer holds information about the current site and page. Like main, I give it an id for anchoring purposes. I don’t get any more detailed with my HTML body boilerplate, as there is so much variance depending on the site.

This is just boilerplate. It is a template for what I’ll include on roughly every site, with some light alterations. Every site is sure to deviate from this depending on its requirements, but this is a reasonable foundation.

If a page is expected to be cited academically, then you’d consider including Google Scholar’s citation_* meta tags and Dublin Core’s dc meta tags. If a page represents an article, then you’d include the tags from the Open Graph Protocol’s article namespace and perhaps tags pertaining to a publishing system. A video, audio, book, or other content type would similarly be marked up differently. Many sites will also benefit from JSON-LD structured data. It all depends on the particular page and what is needed.

For a larger boilerplate that outlines some more optional inclusions, I recommend Manuel Matuzović’s brilliant article, My HTML boilerplate in 2026.

There are cases where they can be used, but you’ll know those extremely rare cases when you come to them. Take great and extreme care. ↩

Index of Aesthetics

Sat, 22 Aug 2026 21:45:24 +0000

Search and filter by...

Keyword

Earliest Known Example

and

End of Popularity

and

Relevant Decade

On the frustration of agreeing with everyone about AI

Fri, 21 Aug 2026 08:47:03 +0000

Conversations about AI are febrile and have been for a while now. Everyone has different views.

It’s frustrating for me because not only do I empathise with all of you, in some ways I have every major position in my mind.

I find myself impossible, messed up. Niller-nally, retwixt, fragmented.

I agree with the accelerationists

I briefly used an open source agentic programming tool with 1000 tokens/second of a top Chinese model. It was like a drug pumped straight into my veins. I worked on artificial life 27 years ago - we were trying to do the same at CyberLife, just much earlier. Creation can be beautiful, and helpful, warm and purposeful. There’s diseases to cure, climate models to optimise, software to make perfect for each person.

I agree with the artists

Our work has all been stolen, and remixed into a bland slop of the world’s cultural heritage. I’m more radical here than nearly anyone - I think model weights are a derived work of every bit of content they’re trained on. Power is winning, not rules. Because power wins. We can’t keep human emotion in art without a relentless disavowal of AI-generated art. Every single nuance needs editing, curating. I care about human emotion in art.

I agree with the nationalists

I watched the US administration suddenly declare that a powerful new model is available only to US citizens. It turned my stomach. My empathy runs high when the European Commission responds that Europe needs “technological sovereignty” in AI. It’s a race.

I agree with the doomers

I look at PauseAI and think… Yep, this technology can cause harm. Existential harm - if not with with current architectures as they scale, then at some point in the next decade or next century with another technology. It is necessary to regulate it, to sign international treaties. It’s nukes but accelerated not only by Government dominance, but also by business value.

I agree with the openness freaks

I’ve loved open source software since 1997. So when I see an argument that open models level the playing field, I’ve already watched it play out with software, and despite the problems, I agree. As the models work better and better, it is worse and worse that we’re locked into a limited set of providers, that power accumulates with the few.

(I guess I don’t really agree with people opposed to data centres because of water or power use - as that seems solvable with the right infrastructure. And the other issues dominate those proximate questions, however much of an environmentalist I am. There are stronger reasons to oppose data centres.)

… breathe …

Yes that all contradicts. It fragments. Open models is the worst for doom, AI sovereignty is the opposite of a pause, protecting artists’ works blocks acceleration. Nothing functions.

Why am I this splinter of contradictions?

Because all the arguments are right, but which is right the most depends on what happens.

If we’re at the top of the S-curve and AI capability stalls with a few more 10% improvements that cost 2x the amount… Then yes let’s roll it out, let’s make it open for everyone, and regulate the mundane risks, remove all the problems, gain all the benefits. Can’t stop capitalism, can get it right.
If AI gets vastly more capable, but somehow without its own “will to power”, then I want to be in a large empire which controls its use for my benefit. The consequences for defense are mind-collapsing, unthinkable. The military acceleration unbearable. But what happens if instead you opt out? It’s bad.
If AI not only gets more powerful, but we lose control, these alien minds start acting at scale and in a way we lose collective and individual control of. It spreads, either an inert cancer growing through our civilisation eating it up, or a willful Cthulhu monster carelessly and deliberately breaking everything apart.

And nobody knows what is going to happen.

I’m kind of tired, agreeing and disagreeing simultaneously with every post on the topic.

Frozen.

I guess I’ll email my MP about holding AI developers liable for severe harm. That seems a good next step.