Mert

“You keep using that word. I do not think it means what you think it means.”
— Inigo Montoya, The Princess Bride (1987)

Two people using the same word while meaning completely different things has been a staple of comedy for centuries.

Lewis Carroll built an entire scene around it in 1871:

“When I use a word,” Humpty Dumpty tells Alice, “it means just what I choose it to mean – neither more nor less.”

Now imagine what happens if you give Humpty Dumpty a code editor and 1M tokens of context…

An AI coding agent is the most confident version of Humpty Dumpty you’ll ever encounter. It will interpret your vocabulary however it sees fit, and it will never tell you it’s confused. It won’t raise its hand and ask “wait, do you mean a purchase order or a delivery order?” It will pick one interpretation, generate plausible code, and move on. As confidently as ever.

How AI agents amplify vocabulary ambiguity

The problem isn’t new. Teams have always talked past each other. But in traditional development, ambiguity encounters friction: code reviews, pair programming, whiteboard sessions, the “wait, what exactly do you mean by ‘order’?” conversation over coffee. Misunderstandings cascade, but they mostly get caught eventually.

With AI agents, that friction disappears. The code compiles, the tests pass, and the semantic mismatch only surfaces when a downstream system interprets the same word differently. Or when the wrong action leads to a production incident.

In How Creating a Ubiquitous Language Ensures AI Builds What You Actually Want, Daniel Schleicher wrote: “LLMs are amplifiers. When we give an AI agent ambiguous instructions where ‘order’ could mean a dozen different things, it amplifies the chaos by generating code that reflects our confusion.”

The flip side is equally true: precise vocabulary gets amplified into correct class names, correct lifecycle states, and correct boundaries. The agent works with whatever you give it – if you give it ambiguity, then that’s what it amplifies.

Russ Miles tells a story about a finance agent that confused booking (revenue recognition in one bounded context) and reservation (risk allocation in another):

“The agent mashed them like a bad DJ, and began taking action that would’ve landed the CFO in handcuffs.”
— Russ Miles, Domain Driven Agent Design

Ambiguous words, different contexts, no clear definitions, and code that compiled just fine all the way to production.

Ubiquitous Language: DDD’s pattern for shared vocabulary

The good news is that Domain-Driven Design (DDD), a widely-adopted methodology, introduced by Eric Evans in 2003, provides both the vocabulary and the pattern for a solution. It’s called Ubiquitous Language:

Use the model as the backbone of a language. Commit the team to exercising that language relentlessly in all communication within the team and in the code.
— Eric Evans, Domain-Driven Design (2003)

Martin Fowler describes it as “the practice of building up a common, rigorous language between developers and users.”

And Vaughn Vernon sharpens it even more:

“[…] a shared language developed by the team – a team comprised of both domain experts and software developers”
— Vaughn Vernon, Implementing Domain-Driven Design (2013)

The important distinction here: It’s not a glossary imposed from above, not industry jargon adopted wholesale. It is a language the team builds together through use.

But note that – despite the name – the Ubiquitous Language is all but ubiquitous. In Vernon’s words: “There is one Ubiquitous Language per Bounded Context.”

What does “Customer” really mean?

The term “Customer” seems universal – it shows up in the codebase of virtually every single business application.

But look at how each subdomain actually refers to the same person: marketing calls them a lead, sales calls them a prospect, the warehouse calls them a consignee, finance calls them a debtor, and support calls them a claimant.

All these subdomains may refer to the same person, but the words they use aren’t synonyms. They carry different attributes, different lifecycle states, different invariants, and different behavior.

And nobody really “creates” or “deletes” anything: a lead is captured, a prospect is qualified, a purchase intent is confirmed, a shipment is dispatched. Each subdomain has its own language, refined over decades – or centuries – of practice.

Flattening all of this into a Customer class with a type field and CRUD operations may feel like it’s simplifying things. But it actually erases the precision and clarity each domain has built, and replaces it with generic ambiguity, which the code, the database schema, the team, and – more often than not – the users of the software have to work around.

When writing the original book, Evans described the Ubiquitous Language for teams of humans – developers, product managers, and domain experts – modelling a shared domain.

But now, we have a new participant: the coding agent. And when the agent reads your prompt, your system instructions, your project rules, it’s doing something analogous to a new developer onboarding onto the team.

Except it onboards every session, with no memory of last time’s disambiguation, and no instinct to ask when a term’s exact meaning is unclear. Tell it “delete the order” and it will. Generically, ambiguously, and very confidently.

Practitioners applying DDD’s Ubiquitous Language to AI agents

I’m not the only one seeing this. Across the industry, people are arriving at the same pattern from different directions.

Martin Fowler described at the Pragmatic Summit 2026 how a colleague is “developing a precise language to communicate about the domain with the agent… that’s basically the kind of model building, language building, domain-driven design stuff that we’re used to doing, but it makes him more efficient to talk to the agent.”

Matt Pocock built a glossary skill that scans the codebase, extracts terminology into markdown, and feeds it to the agent. Reading the agent’s thinking traces, he found it improved implementation alignment while even reducing verbosity – an unexpected benefit in terms of token use and cost.

Daniel Schleicher formalized it with the “Spec Ambiguity Resolver” pattern: a living glossary where AI flags ambiguous terms, proposes definitions, and waits for human approval. Once approved, consistency is enforced project-wide:

“The greatest leverage in modern software development with AI,” he writes, “lies not in accelerating typing, but in establishing semantic agreement before implementation begins.”
— Daniel Schleicher, How Creating a Ubiquitous Language …

Tim Oleson named “Language Consistency – usage of ubiquitous language in agent communications” as a first-class domain alignment metric for agent systems.

Whether they came to it through practicing Domain-Driven Design or arrived at it independently, the pattern is the same. And it shows up in places you might not expect: every MCP tool name is a vocabulary decision the LLM reasons over. confirm_purchase_intent() and submit_order() produce different agent behavior even when the underlying operation is identical. Chris Hughes writes that the tools layer “protects your domain from the LLM’s interface requirements – translating between ‘strings the LLM can reason about’ and ‘rich domain objects your code works with.'”

Marc Brooker’s Specification Loop explains how this compounds over time: each resolved ambiguity becomes a stable term that enriches the shared vocabulary. The next conversation starts from a higher baseline and the loop gets cheaper over time as the vocabulary grows. “I believe that the trips around the loop are fundamental to the success of the whole enterprise. They’re what we’ve been doing all along.”

How to define domain vocabulary for your coding agent

The Ubiquitous Language isn’t a document you have to write upfront and rigidly apply. It’s a living artifact that evolves through use.

A common practice in teams: whenever someone realizes there’s an ambiguity – two people using the same word differently, or one word meaning two things – the team pauses, discusses, and agrees on a term. And this doesn’t have to be the academically “correct” term. What matters is that everyone on the team knows exactly what it means. Then you write it down, and use it consistently. In conversations, in code, and in the documentation.

This practice naturally extends to conversations with a coding agent. Whenever there’s a misunderstanding, missing clarity, or ambiguity in what the agent produces, spend a moment to establish a specific term for the concept. Define it. Add it to whatever artifact represents the current shared state of the vocabulary: your CLAUDE.md or AGENT.md, your cursor rules, or just a simple domain-terms.md, referenced as the canonical glossary of terms. The agent will start using it from that point forward, each disambiguation compounds, and every new conversation starts from a higher baseline.

But remember: each bounded context has its own vocabulary. If your application has a fulfillment module and a billing module, each gets its own language section in that module’s CLAUDE.md (or whatever file your agent reads when entering a directory). The terms in one context don’t need to match the terms in another – that’s the whole point.

Here’s what a modules/fulfillment/CLAUDE.md might contain:

## Fulfillment Domain Language

**Consignee**:
The person or entity receiving a shipment. Identified by delivery
address, contact phone, and access instructions. A consignee may
differ from the purchaser.
*Avoid*: Customer, Buyer, User

**Consignment**:
The full set of items to be delivered to a consignee. May be
fulfilled as one or more Shipments depending on stock location
and logistics.
*Avoid*: Order, Delivery (a delivery is one shipment arriving,
not the full set)

**Shipment**:
A physical package dispatched to a consignee via a carrier. Has
tracking number, weight, dimensions, and a declared value.
*Avoid*: Order, Package (ambiguous with code packages)

**Dispatch**:
The act of handing a shipment to a carrier. Irreversible - once
dispatched, the shipment is the carrier's responsibility.
*Avoid*: Send, Ship (verb), Process

And modules/billing/CLAUDE.md in the same application, even though it might refer to the same physical person or purchase event, is using terms native to its own domain:

## Billing Domain Language

**Debtor**:
The legal entity liable for payment. Identified by tax ID, billing
address, and agreed payment terms (net-30, net-60, etc.).
*Avoid*: Customer, Account, User

**Invoice**:
A legal demand for payment tied to one or more line items. Carries
a due date, VAT status, and regulatory classification. An invoice
is never deleted - it is reversed with a **Credit Note**.
*Avoid*: Order, Bill (ambiguous with infrastructure billing)

**Settlement**:
The act of a debtor satisfying an invoice in full or in part.
Records payment method, date, and reconciliation reference.
*Avoid*: Payment (ambiguous - is it the act or the money?),
Transaction

Both examples describe the same person making the same purchase. But the vocabularies are completely different, because the contexts model different responsibilities, different invariants, different behaviors, and different lifecycles.

Tell an agent “handle the customer’s order” without this, and you get a generic Customer class with a type field. Tell it within a defined context, and you get a Consignee with a delivery address or a Debtor with payment terms.

The vocabulary manifests in an architecture that captures the richness of the business domains it models. And – whichever context you’re in – the agent knows exactly what you mean.

And remember: You don’t need a formal glossary to start.

All you need is one line the next time something goes wrong: “In this project, order *means a confirmed purchase intent, not a request or a reservation.”*

Add it. Use it. Let it accumulate.

If you want to learn more about how Domain-Driven Design maps to the age of coding agents, I recently wrote about how engineers building MCP servers are reaching for DDD’s Bounded Contexts and Anti-Corruption Layers.

Hey

OpenSparrow v2.3 is out. Quick recap if you missed earlier posts — it’s an open-source admin panel framework built on PHP 8.1, PostgreSQL, and Vanilla JS. No npm, no Composer, no external libraries. You configure everything visually through /admin.

Live demo: demo.opensparrow.org

What’s new

• Schema Map (ERD) — visual diagram of your entire database with PNG export
• Many-to-Many support — dedicated Builder tab, chip renderer in grids
• Virtual computed columns — formula fields without touching the DB
• Custom Views — save filtered/sorted perspectives per table
• Record Ownership — track who handles what, full history
• Performance tab — index advisor, slow query analyzer, bloat detection
• Security hardening — 5 audit fixes, better session and input validation

Contributing

Looking for contributors — code, docs, or a short demo screencast.

opensparrow.org
github.com/wrobeltomasz/open-sparrow

Renovate, auto-merge, and why a small team has no other option

Open npm outdated on any project older than six months. Run uv lock --check on the backend. Look at the base image tag in your Dockerfile.

You already know what you’ll find. Things behind. Things with CVEs. Things end-of-life next month. The migration guide for Vite 5 → 6 nobody wants to read.

Nobody schedules this work. Nobody enjoys it. On a small team, nobody has time for it. So it doesn’t happen — until the day a CVE forces it to, in a hurry, on a Friday afternoon.

That model doesn’t scale to a real project. Especially not a real project with two people on it.

So I stopped doing it manually.

Handle It End to End, or Don’t Handle It

There’s a design principle I keep coming back to: a problem should be handled end to end. Do it, and forget. If something fails, you’ll be notified.

That’s it. That’s the bar.

A small team can ship a real product only if every recurring chore is either automated end-to-end or deleted. There is no third option. Half-automated means “someone has to remember to check on it,” and someone, in a two-person team, always forgets.

Dependency updates are the textbook case. They’re recurring, mechanical, security-critical, and boring. You cannot afford to do them manually. You also cannot afford to skip them. So the only honest answer is: hand them to a system that does them every night, lets the good ones through, flags the rest, and emails you when something breaks.

That system, for me, is Renovate.

Enter Renovate

Renovate is a bot. You point it at your repo. It reads your manifests — package.json, pyproject.toml, Dockerfile, GitHub Actions workflows, GitLab CI files, Helm charts, basically anything pinned. It checks the registries. When a new version exists, it opens a pull request (or merge request, depending on your forge — I’ll say PR for the rest of the article and trust you to translate).

That’s the whole pitch.

Renovate works on GitHub, GitLab, Bitbucket, Gitea, Azure Repos, and a few others. Same config, same behavior. That portability matters more than it sounds — your dependency policy is now a renovate.json you can carry between projects regardless of where the code lives.

The trick is in the delegation. A bot opening PRs is not new. Dependabot has done that for years on GitHub. What makes Renovate the right tool is the configuration surface — you can describe, with reasonable precision, which updates you trust enough to auto-merge.

Patch from 1.6.2 to 1.6.3? Auto-merge if CI is green. I’d never review that diff anyway.

Major from 5.x to 6.x? Open the PR, slap a major-update label, leave it for me.

The whole thing runs on a schedule. Mine fires at 3 a.m. every night. I wake up to a dashboard that says “12 PRs merged, 2 waiting for you.” The 12 were patch and minor bumps with passing pipelines. The 2 are pgvector going from 0.7 to 0.8 and a Postgres major. Those, I read.

The Config, in Plain English

The whole config is under 50 lines. Here’s the load-bearing part:

{
  "extends": ["config:recommended", ":dependencyDashboard"],
  "baseBranches": ["dev"],
  "platformAutomerge": true,
  "packageRules": [
    {
      "matchUpdateTypes": ["patch", "minor", "pin", "digest"],
      "automerge": true
    },
    {
      "matchUpdateTypes": ["major"],
      "automerge": false,
      "addLabels": ["major-update"]
    }
  ],
  "lockFileMaintenance": {
    "enabled": true,
    "schedule": ["before 5am on monday"]
  },
  "vulnerabilityAlerts": { "enabled": true }
}

Five rules. That’s it.

• Target the development branch, not main. Bumps still flow through the normal development → pre-production → production (main) promotion, and they get tested again at every stage. The bot only opens the first door; everything downstream still has to pass.
• Auto-merge patch, minor, pin, and digest bumps. Block majors behind a label.
• Run lockfile maintenance every Monday, even when no direct deps changed — this catches transitive security fixes without anyone touching package.json.
• Surface security advisories with their own label so they jump the queue.

The :dependencyDashboard preset is the unsung hero. It opens a single issue in your repo that lists every pending update, every blocked one, and every checkbox you can tick to force an immediate retry. When something looks weird, you go to one place.

The Prerequisite: A Pipeline That Tells the Truth

Here’s the part most posts skip.

Auto-merging dependency bumps is not a Renovate feature. It’s a trust delegation. You’re telling the bot: “if the pipeline says green, that means it works.” Renovate is downstream of that. It is not what makes auto-merge safe. Your CI is.

If your pipeline doesn’t actually verify the code works, auto-merge is a foot-gun pointed at production. The bot will cheerfully merge a react minor bump that breaks SSR — because the only thing it checked was npm install.

This is the direct sequel to Programming by Coercion. The whole point of that article was to build a pipeline that physically cannot let bad code through. Lint, type-check, unit tests, integration tests, end-to-end tests, security scans — each stage a finish line the code has to cross.

The key idea worth pulling out: the tests verify behavior, not implementation. If a customer has to add an item to their cart and pay, the test does exactly that. It can be decomposed into steps — add to cart, open the checkout, fill in the payment form, see the confirmation page — but the thing being verified is the user-visible outcome. When the test passes, you can be confident the feature actually works, because there is no other way the test could pass. The test only goes green if the behavior is real.

That’s why auto-bumping a dependency is safe under this kind of pipeline. The PR isn’t asking “does the code still compile?” — it’s asking “can the customer still buy the thing?” If the answer is yes across every layer, the version bump is fine. If a transitive change broke the checkout, the e2e test fails, the merge is blocked, and you get an email. End to end.

So I won’t enable auto-merge on a project that doesn’t have, at a minimum:

• Linting and type-checking that fail the build.
• Unit and integration tests that actually exercise the upgraded dependency.
• End-to-end tests that hit the real code paths a user uses.
• Security scans on the result (Trivy, Bandit, gitleaks).

The pipeline is what makes auto-merge honest. Without it, you’re not automating — you’re just shipping faster. Renovate is downstream of the pipeline, not a replacement for it. If you don’t have those gates yet, Renovate isn’t your next problem — the pipeline is.

So What Do You Actually Get?

A bot on a cron and a config file under 50 lines. That’s the install. From there, the system runs itself and the pipeline catches what would otherwise reach you. Here’s the honest accounting — what you gain, what you give up, and what else you could have picked.

Pros

It’s invisible when it works. And it works most days. I have not manually bumped a patch version in weeks.

Lockfile maintenance is a free vulnerability scan. Even when none of your package.json versions change, the resolved tree underneath does. Monday-morning lockfile refresh catches transitive CVEs you would never see otherwise.

The dependency dashboard kills the “what should I update next” anxiety. It’s just a list. You go down the list. You stop.

It respects your branching model. Target the development branch, not main. Bumps still flow through pre-production and get tested again before they reach users. Renovate opens the first door — the rest of the promotion chain stays unchanged.

Major updates get human-flagged automatically. You don’t have to remember to be careful. The label tells you.

The configuration is declarative and reviewable. Your dependency policy is a file in the repo, in git, with diff history. New team member asks “why do we auto-merge minors?” — answer is in the commit log.

Cons

You add a bot to your supply chain. Renovate runs with a token that can merge code. If that token leaks, an attacker can merge to your default branch. The mitigation is the same as for any CI secret — masked, protected, repo-scoped — but it is a non-zero surface area.

The “scheduled job in CI” model is fragile. A failing pipeline silently stops Renovate. You need to actually watch the maintenance stage, or you’ll discover three months later it’s been red the whole time. Enable your forge’s pipeline-failure notifications (GitHub Actions notifications, GitLab “failed pipeline” emails — same idea, different UI).

It’s noisy at first. Day one, you get 30+ PRs. You have to either merge them in a sitting or rate-limit Renovate (prConcurrentLimit) until you catch up. There’s no way around the initial backlog.

Auto-merge is only as good as your CI. I said this above. Worth saying twice. If your tests don’t exercise the dependency, auto-merge is theater.

Major bumps still take human time. Renovate doesn’t magic away Vite 5 → 6. It just makes sure the PR exists. The actual work — reading the migration guide, fixing the breaking changes, running the manual smoke test — is still on you. The bot reduces frequency-of-decisions, not depth-of-decisions.

Configuration depth has a learning curve. The packageRules matching system is powerful and confusing. You will, at some point, write a rule that matches nothing and silently does nothing, and you’ll lose an afternoon to it.

License and limits

Renovate is open source under AGPL-3.0, maintained by Mend. The CLI you run yourself — in a CI job, a container, wherever — is free, and that’s what the config in this article describes. Mend also offers a hosted GitHub App (“Mend Renovate”) for free, and a commercial tier with extras like compliance reports, SLAs, and a UI on top.

For a small team self-hosting on any forge, the free CLI is more than enough. The AGPL only matters if you’re embedding Renovate into a product you ship to users — running it as a maintenance bot in your own pipeline doesn’t trigger anything. Reasonable hard limits to be aware of: very large monorepos (hundreds of manifests) can push past Renovate’s per-repo timeout in CI, and registries with aggressive rate limits sometimes need explicit hostRules entries.

What About the Alternatives?

Dependabot is the obvious one. Built into GitHub, zero setup, works fine. If you’re on GitHub and don’t need fine-grained grouping, custom schedules, or lockfile maintenance, just use Dependabot. The configuration is leaner, the defaults are reasonable. The trade-offs: less control over auto-merge rules, no monorepo grouping, no scheduled transitive-lockfile refresh, and — the one that matters most — it only exists on GitHub. Move repos to another forge and you start over. Renovate is the platform-agnostic answer: same renovate.json whether you’re on GitHub, GitLab, Bitbucket, or self-hosted.

Snyk, Mend, Socket. These are the commercial offerings. They go further than Renovate — security posture, license compliance, dashboards, SLAs. Worth it for a company; overkill for a side project.

npm-check-updates + a calendar reminder. This is what most people actually do. It works. It also requires the human to remember, which means it gets skipped any week the human is busy. Compound interest, wrong sign.

Doing nothing. Always an option. The honest one. If your project ships once and never again, doing nothing is correct. For anything you intend to keep running, doing nothing is just borrowing time at a punitive rate.

Automate the Maintenance. Build the Future.

Automate what you can. Do it properly — documented, tested, monitored, gated. Then leave it alone.

The point isn’t to write less code. The point is to free the only finite resource you have — your attention — for the work that actually moves the project forward. The next feature. The hard architectural call. The thing nobody else can do for you.

The maintenance still happens. CVEs get patched, lockfiles refresh, base images bump. None of that needs you in the loop. It just needs to be set up well once, then trusted to keep running.

A small team can run a real project — but only if every recurring chore is handled by something other than human attention. Automate the boring half properly, and you’ve bought yourself the time to build the interesting half.

The maintenance runs itself. The next thing is waiting for you.

There is this one moment after you have written the last line of code, optimized the last stylesheet, and finally uploaded the website to the server. You lean back, sip your coffee, and feel that childlike urge to type your own name into Google. Not because you don’t know who you are, but because you are looking for validation. In my case, the result was sobering. Nico Hartmann is not a rare name. There are Nico Hartmanns who play football, Nico Hartmanns who are active in local politics, and probably hundreds of Nico Hartmanns who simply exist without bothering the internet with their presence. But there I stood, somewhere on page five or six, buried under an avalanche of namesakes. In that moment it became clear to me that I had not just built a website, but a digital monument standing in the deepest forest where nobody sees it. The need to climb up the rankings was suddenly no longer just a logical next step, but a matter of honour.

SEO is the magic word that gets hammered into you in every marketing blog. Search Engine Optimization. It sounds like an exact science, almost like alchemy, but in reality it is the only measure with which I can manipulate Google and the like. You try to outsmart a system that is smarter than yourself by feeding it exactly what it wants to hear. So I started equipping every single subpage with correct titles and descriptions. Every meta tag was polished, every headline was reconsidered three times. You feel a little like a fraudster trying to sneak into an exclusive party. The goal is clear: the search engines must like it. It is no longer about what the human reader thinks, but about what the algorithm spits out in its dark data centres.

The Capitulation of Language Before Statistics

The whole thing has a frightening similarity to LinkedIn. We all know this platform where people pat each other on the back and inflate their CVs until they almost burst. SEO is basically nothing other than digitally stroking one’s own ego. The only difference is the target audience. Instead of recruiters or potential business partners, I want to impress robots. I write texts for beings without consciousness that count words, calculate keyword densities, and measure loading times in milliseconds. It is a bizarre form of modern communication in which the human being only plays the role of the supplier, while the bot decides whether you are relevant or not. When the bot smiles, the ranking rises. When the bot frowns, you remain buried in digital insignificance.

In theory, SEO sounds quite simple. You take a few keywords, build them into the text, and wait for the world to discover you. But reality catches up with you faster than you can spell keyword research. It gets damn quickly very complex. This is mainly because different search engines have different requirements. What Google loves, Bing might ignore, and DuckDuckGo has its own rules anyway. Moreover, you have to accept that you cannot be found for everything. You cannot be the king of the internet if you have no army. So you have to find an appropriate niche. For me that was quickly clear: IT lecturer and software development. Those are the terms with which I earn my bread and under which I want to be found.

However, this is where the strategic dilemma begins. I am also a trainer, and I would actually have loved to include that word in the title as well. It describes part of my identity and my daily work. But the hard reality of search engine optimization says no. If I were to throw even more keywords into the ring, I would dilute my focus. Every additional word is a potential disruptive factor that diminishes the relevance of the main terms. It is a constant balancing act between what you actually want to say and what the search engine still considers focused enough. SEO forces you into reduction. You mutilate your own description just to not appear too complex in the eyes of an algorithm. It is the capitulation of language before statistics.

The Curse of Internationality

As if that were not already enough work, the problem of multilingualism came along on top of everything else. I made a conscious decision in favour of multilingualism in German and English. The thought behind it was simple and perhaps a little naive: I simply wanted to be able to repost my blog entries on English-language sites as well. Internationality also always sounds good in a portfolio. My plan was to generate backlinks with this, which in turn would push my search ranking upward. A backlink from a reputable English site is like a gold medal for your own domain. So far, so logical. But the implementation transformed my clean website concept into a bureaucratic monster made of links and language tags.

The surprise came when after some time I actually searched for Nico Hartmann IT lecturer. A small triumph germinated within me when I actually saw my name in first place. But the joy lasted only seconds. Google did indeed present me at the very top, but the description was in English. There you sit in Germany, searching for a German term, and you get served an English snippet. That is the moment when you would love to throw the keyboard out of the window. Google had understood that I am important, but not which language is appropriate for this specific context. The algorithm rolled the dice and I lost.

So it was: back to the drawing board. I had to set hreflang attributes. For the layperson this sounds like technical triviality, for the website operator it is the attempt to draw the search engine a map that it should please not ignore. You explicitly tell Google which page is intended for which region and which language. And then the great waiting begins. SEO is not a sprint, it is a marathon through mud. You wait one to two weeks until the merciful crawlers from Google finally deign to look at the website anew. You feel like a supplicant before the throne of a capricious king, hoping that your corrections will this time be graciously received.

This entire process is a lesson in humility and frustration. You invest hours in optimization, only to discover that you are dependent on the whims of a corporation that changes its algorithms faster than you can adjust your own description. It is a permanent fight against windmills, where the windmills consist of server farms and the lance is a text editor. You are not optimizing for the user, you are optimizing for the machine, in the hope that in the end a human being will still find their way to the page. It is an absurd theatre in which we all play our roles, just to grab a small piece of visibility in an ocean of information.

And while I sit here waiting for the next crawl, I ask myself whether all of this is really worth the effort. The answer is a frustrated yes, because in today’s world you do not exist if you are not on the first page. You submit to the dictate of the search engine, adapt your language, cross out words that you actually like, and set cryptic attributes in the header. All for that one moment when the search for your own name delivers exactly the result you have so laboriously purchased. It is a digital ego trip that costs you more nerves than any software development, but in the end vanity wins over reason.

The Anatomy of Keywords

When you dive deeper into this swamp, you quickly notice that keywords are like small pets. You have to care for them, feed them, and assign them exactly the right place. Choose the wrong ones and they bark at you or run away. In my case, the decision for IT lecturer and software development was a purely strategic choice. I could also have taken IT teacher or code coach, but who searches for those? You spend hours with tools that tell you how often a term is searched for, only to then discover that the competition for these terms is so gigantic that you as a lone fighter barely have a chance. So you search for the gap, for the golden middle ground between relevance and feasibility.

It is this constant balancing act between the ego and the algorithm. You might want to call yourself a “visionary for digital transformation,” but that is of little use if the market is simply demanding a “Python course.” This discrepancy forces one to break down their own identity into bite-sized morsels that can be easily digested by search engines.

In this context, keyword research is often less of an exact science and more of a psychological poker game against user intent. You analyze long-tail keywords and niche terms in the hope that the specific combination of expertise and location hits exactly the right nerve for those who won’t just click on the first mass-market offer they see. At the end of the day, the realization remains that visibility is not created by the loudest terms, but by the cleverest positioning in the shadow of giants.

The Curse of the Technology Behind the Language

The decision for multilingualism was, looking back, like the attempt to fly two aeroplanes simultaneously. You think you simply write everything twice and that is that. But Google sees it differently. For a search engine, duplicate content is a red flag. If you are unlucky, the algorithm penalizes you for trying to dance at two weddings at once. The solution is precisely those hreflang attributes I have already mentioned. These small code snippets are the diplomatic representatives of my website. They tell Google: Hey, this here is the German version for the Germans and that there is the English version for the rest of the world. Please do not throw them into one pot.

It is fascinating and alarming in equal measure how much time one spends on technical overhead that has absolutely nothing to do with the actual content. I want to write about software development, about didactics in IT, about modern technologies. Instead I spend my evenings validating XML sitemaps and checking whether my canonical tags are correctly set. You become the bureaucrat of your own creativity. Every new page, every new blog post drags a long tail of administrative tasks behind it. If you do not do this, the contribution remains a lone voice crying in the wilderness. You no longer write for the joy of writing, you write for the indexing.

The Arrogance of the Crawlers

There is hardly anything more frustrating than the waiting time for Google’s bots. These digital insects crawl through the net, index billions of pages, and decide over success or failure. You have no influence over when they come. You can invite them via the Search Console, essentially hold the door open for them and roll out a red carpet, but in the end they come when they want. This uncertainty is poison for anyone who wants to see fast results. You change a small thing that you are convinced will bring the breakthrough, and then you stare at an unchanged search bar for days.

During this time you begin to doubt yourself. Was the hreflang attribute really correct? Have I perhaps forgotten a quotation mark? Why is the English description still being displayed even though I have prioritized the German page? It is a psychological game. Google is the invisible referee who changes the rules during the game and never tells you exactly what you have done wrong. You receive only vague hints and have to figure out the rest through trial and error. It is a form of digital servitude into which we have voluntarily entered because we need visibility like the air we breathe.

I stand here with a website that is technically speaking flawless, but which is still fighting against the shadows of my namesakes. I have learned that IT lecturer is my anchor and that I must enjoy the English language with caution if I want to dominate the German market. It is a laborious path, characterized by technical trivialities and the constant concern for the goodwill of an algorithm. But ambition has been awakened. If Google wants to see me as an Englishman, I will prove to Google that I am the German IT expert it is looking for. The battle for Nico Hartmann has only just begun.

The Tyranny of Backlinks or Why Quality Alone Is Never Enough

After I had more or less navigated around the technical hurdles of multilingualism and metadata, I ran into the next great monster in the SEO ocean: authority. It is simply not enough for Google that I claim to be a competent IT lecturer. The search engine wants to see proof. In the digital age, this proof takes the form of backlinks. A backlink is basically a recommendation from another website. If a reputable IT site links to me, the Google algorithm thinks to itself that this Nico Hartmann is probably not a charlatan after all. So I began refining my strategy for reposting my blog entries on English-language platforms like Medium or Dev.to. The goal was clear: I wanted to use the reach of these giants to redirect a little of their digital shine onto my own small domain.

It is a strange form of digital prostitution. You write high-quality content, give it away practically for free to large platforms, and hope in return for a small, clickable link that leads the crawler back home. But here too complexity lurks. There are no-follow and do-follow links. The former are as useful for rankings as an alcohol-free beer at a hacker party, the latter are the digital gold. Of course, most large sites give out only the inferior links by default, in order not to dilute their own ranking. So you fight at the front line for recognition and are often thrown only crumbs. Nevertheless, this process is without alternative if you do not want to stand forever in the shadow of the other Nico Hartmanns of this world.

The Dilemma of Content Recycling

The reposting on English sites brought me to yet another painful realization. You cannot simply copy the same text one-to-one. Search engines are allergic to laziness. Whoever simply copies will be ignored. So I had to rewrite my own texts for the English platforms, adapt them, and give them a new spin. The whole thing was supposed to serve to underscore my expertise as a software developer, but in the end I spent more time rephrasing sentences than on actual programming. It is a paradoxical vicious circle: in order to be perceived as an expert in software development, you have to stop developing software and start becoming a full-time copywriter for yourself.

Particularly insidious is the psychological component. You observe the statistics. You see how many people have read the English article, and hope that at least a fraction of them will find their way to the original portfolio page. But most users remain in their ecosystem. They read on Medium, perhaps clap briefly, and move on. The search engine does register the connection, but the hoped-for massive rise in rankings often remains a quiet background noise. You feed the beast with ever more content, in the hope that it will be satisfied at some point and grant you your place in the sun. But the beast Google never clocks off.

The Waiting Time and the Grace of the Crawlers

When you have then scattered all backlinks and checked all hreflang attributes for the tenth time, the phase of absolute powerlessness begins. You can do nothing more but wait. The internet is a vast memory that unfortunately forgets very slowly and learns even more slowly. You check the Search Console daily. You look at the impressions, the clicks, the average position. It is like watching grass grow, except that the grass sometimes decides in the middle of the night to retreat back into the ground.

Once I suddenly appeared in first place for a completely irrelevant search term, simply because I had mentioned it once in a subordinate clause. That is the irony of SEO. You optimize like someone obsessed for IT lecturer and software development, and Google decides instead to rank you for a typo in a code example. You feel not understood by the artificial intelligence, but rather mocked. The crawlers are like civil servants in a dusty authority: they work according to rules that were established years ago, and have no interest in your personal urgency. If they decide that your English description is more important than your German one, then that is how it stays for now, until the file lands back on top of the pile a few weeks later.

The Niche as a Lifeline

In this chaos, concentration on the niche is the only way to not go mad. I have come to terms with the fact that I will never stand in first place for the word software development alone. Corporations with million-dollar budgets and whole armies of SEO specialists are fighting there. But for Nico Hartmann IT lecturer? That is my playing field. Here I can win if I remain persistent. The restriction here is not a weakness, but a necessary survival strategy. It is better to be the king of a small village than a beggar in a metropolis.

Nevertheless, this bitter aftertaste remains: that you are optimizing your digital presence not for people, but for a mathematical formula. Every time I leave out the word trainer just to not jeopardize the keyword density, it feels like a small betrayal of my actual work. We build websites for machines that pretend to decide for people. It is a simulation of relevance. When I write a text today, I no longer ask myself first whether it is useful for my students, but whether it offers enough semantic connections to satisfy Google’s semantic search. We adapt our thinking to the structure of the search engine.

The Outlook into Madness

What remains at the end of this rant? SEO is a necessary evil, a modern form of indulgence trading. We pay not with money, but with time, nerves, and our linguistic integrity. I will continue to set hreflang tags, hunt backlinks, and polish my metadata. Not because it is fun, but because the alternative is digital invisibility. And in an industry where online presence is the new business card, you simply cannot afford to be invisible.

Perhaps Google will come to its senses in a few weeks. Perhaps the crawler will recognize that the German page is actually the better choice for German search queries. Until then I will continue to cast hateful glances at my monitor when the English description appears at the very top again. SEO is a fight you never win entirely, you can only keep fighting it until you either end up on top or lose the inclination. And since I am a stubborn IT lecturer, I will probably keep going until Google finally spells my name the way I want it.

• SEO is the art of dressing up for robots so that people can find you.

• Multilingualism is a technical nightmare that has a preference for delivering the wrong search results.

• Backlinks are the currency of the internet, but the exchange rate is merciless.

• Your own identity must yield to the niche if you want to survive in the rankings.

Sometimes I ask myself whether the other Nico Hartmanns out there are fighting the same battle. Whether the footballer is also frustrated because my blog post about software development appears above his latest match report. If so, that is at least a small consolation. In the arena of search results there are no friends, only competitors for the attention of an algorithm that knows no mercy. At the end of the day I sit again in front of the computer, adjust the next description, and hope for the best. Because whoever does not optimize does not exist. And I would quite like to exist, at least on page one.

This is a submission for the Google I/O Writing Challenge.

I watched the Google I/O 2026 keynote twice.

First time, I got swept up in the shiny stuff. Gemini 3.5 Flash benchmarks. Veo 3 generating videos that look disturbingly real. Gemini Omni doing that multimodal physics thing. Cool. Expected. The usual I/O sugar rush that gets 50,000 retweets and fades by Thursday.

Second time through, I caught something different.

About 40 minutes into the developer keynote, sandwiched between the Jules GA announcement and a Stitch demo, there was maybe 90 seconds on something called the Managed Agents API. The presenter dropped one line that made me hit pause and rewind.

“Deploy an autonomous agent that reasons, writes code, browses the web, and executes in a secure sandbox. One API call.”

I closed every other tab. Pulled up the docs. Started writing code.

The 19-Day Problem

Here’s some context. If you’ve tried building anything with AI agents in the past year, you know the drill. And by “drill” I mean “weeks of suffering.”

Say you want an agent that takes a GitHub issue, reads the codebase, writes a fix, runs tests, and opens a PR. Sounds straightforward, right? In reality, you’re wiring up five services, spinning up sandboxed containers, managing auth, building tool-call routing, writing health checks, and setting up network policies so your agent doesn’t accidentally nuke production at 3am on a Saturday.

Last month I built an internal bot that triages support tickets. Took three weeks. The actual AI logic? One day. The other 19 days were pure infrastructure. Docker config. Sandbox isolation with gVisor. Network policies. Timeout handling. Health checks. Retry logic.

Nineteen days of plumbing. One day of thinking.

That ratio is broken. And this API just fixed it.

Three Weeks to Eleven Lines

I took that same support ticket bot and rewired it on the Managed Agents API. Not a demo version. The same bot. Same capabilities.

from google import genai

client = genai.Client()

interaction = client.interactions.create(
    agent="antigravity-preview-05-2026",
    environment="remote",
    input=(
        "You are a support ticket triage agent. "
        "Read the following ticket, classify its severity, "
        "identify the affected component from the codebase, "
        "and draft a response with a proposed fix.nn"
        f"Ticket: {ticket_text}"
    )
)

print(interaction.output_text)

Eleven lines. No Docker. No Kubernetes. No sandbox config.

The API spins up a fresh, isolated Linux environment, loads the agent runtime, runs your task, hands back the result, and destroys the sandbox. Done.

Here’s what that looked like in practice:

I stared at my screen for a solid minute when it worked. Not because the output was flawless (it wasn’t). Because I’d just thrown away three weeks of infrastructure code.

What Google Actually Built Under the Hood

When you hit interactions.create, four things happen:

Sandbox provisioning. Google fires up an isolated Linux VM. Fresh filesystem every time. No leftover state from previous runs. Network access is off by default, opt-in only. This alone used to cost me a week of Docker and gVisor wrestling.

Agent harness boots up. This is the exact same runtime that powers Jules and the Antigravity desktop app. Not a watered-down version. Same thing. Every improvement Google makes to Jules? Your managed agents get it too.

Reasoning loop. The agent reads your input, builds a plan, starts executing. Writing files. Running code. Hitting the web if you’ve turned that on. There’s a “critic” layer baked in that catches logic errors before returning output. Think of it like a built-in code reviewer that runs before every response.

Cleanup. Interaction finishes, sandbox gets nuked, you get the result plus any files the agent created. Thirty seconds to a few minutes total.

Where the Sandbox Breaks: The Preview Limitations

I’m not going to pretend this is ready for production. Two days of testing surfaced real problems.

Timeout wall. I pointed it at a 15,000-line codebase and asked it to refactor one module. Hit the 5-minute ceiling and died. Large, complex tasks choke.

Zero memory between calls. Each interaction gets a clean sandbox. Great for security. Terrible if you need your agent to remember context. You have to manage state yourself, passing the previous_interaction_id and relevant context back in on every subsequent call. Not hard, but not free either.

The “preview” tax. Pre-GA. Google says don’t feed it sensitive data. Side projects and internal tools? Go for it. Customer data in production? Wait.

Pricing is a black box. Free during preview. Nobody knows what this costs at scale. That’s a real problem for anyone planning production workloads.

Network access is half-baked. Your agent can browse the public web. But reaching internal APIs? You need an MCP server as a bridge, which brings back some of that infrastructure overhead. A bit ironic.

How It Stacks Up Against the Competition

Here’s what made me pay attention. Right now, if you want an autonomous agent that executes in a sandbox, your options are:

OpenAI Assistants API gives you code execution in a sandbox, but it’s tied to OpenAI models, the sandbox is limited (no arbitrary binary execution, no web browsing), and you’re paying per-token plus tool-call fees. It’s also not truly “deploy an agent” so much as “run a conversation with tools.”

Anthropic’s tool-use is powerful for single-turn tool calling, but there’s no managed sandbox. You bring your own execution environment. So you’re back to the Docker-and-gVisor dance.

LangGraph Cloud gets you agent orchestration, but again, you manage the infrastructure. The execution environment is your problem.

Google’s approach is different. They’re saying: give us the instructions, we’ll handle the sandbox, the execution, the security, the cleanup. You don’t think about infrastructure at all. That’s a genuinely new position in this space.

This is the first time a major cloud provider is treating autonomous agents as serverless compute, not just chat-with-tools.

The tradeoff? You’re locked into Google’s ecosystem. The agent runs on Gemini models. If you need Claude or GPT-4 for a specific task, this isn’t your tool. But for teams already in the Google stack, the friction drop is real.

The Feature That Actually Got Me: Saved Agents

One-shot interactions are cool. But agents.create is where things get interesting.

You define an agent with custom instructions, specific tools, MCP connections, and environment settings. Save that whole configuration. Then trigger it by ID from anywhere. Cron job. Webhook. GitHub Action. Another agent.

agent = client.agents.create(
    display_name="ticket-triage-v1",
    system_instruction=(
        "You are a senior support engineer. "
        "Classify tickets by severity. "
        "Always check error logs before suggesting a fix. "
        "Never suggest restarting the service as a first option."
    ),
    tools=["code_execution", "web_browse"],
    environment_config={
        "sandbox": "remote",
        "timeout_seconds": 300
    }
)

# Trigger from anywhere
result = client.interactions.create(
    agent=agent.id,
    input=f"New ticket: {ticket_text}"
)

I wired one to our Slack. Someone files a bug, the agent auto-triages, pulls relevant logs, posts analysis in the thread. Forty lines of Python and a webhook.

The Lambda Moment

Remember 2014? Before Lambda, running code in the cloud meant EC2 instances. Load balancers. Auto-scaling groups. The works.

Lambda said: give us the function, we handle the rest. People called it a toy. Then it ate the backend world.

I keep seeing the same pattern. Before this API, building an agent meant managing infrastructure. Now you hand over instructions and Google runs the thing in a sandboxed environment.

Maybe I’m wrong. Maybe this stays niche. But the parallel keeps nagging at me, and I haven’t been able to talk myself out of it.

What I Want to Build Next

A docs drift detector that points at a repo, reads the README, runs the code, and flags where documentation and behavior have diverged. Every project has this problem. Nobody fixes it manually.

A dependency changelog reader that actually reads changelogs for your deps, understands breaking changes, and tells you which updates are safe to auto-merge and which ones need human review.

A pre-review PR agent that reads changes before a human reviewer opens the PR, checks test coverage on modified files, identifies risky diffs, and writes review notes. Like a thorough junior dev who never sleeps.

All of these would’ve been multi-week projects before. Now they’re afternoon builds. That’s the shift. Not what agents can do. But how fast you can ship them.

So What Now

Google I/O 2026 had no shortage of headlines. Gemini 3.5 Flash is fast. Veo 3 is wild. Gemini Omni understanding physics makes you wonder what 2027 looks like.

But this quiet little API is the one that actually changed my Tuesday. It didn’t make me go “wow.” It made me delete code. And that’s usually how the important stuff starts.

Open the docs. Write eleven lines of Python. See what happens.

Found this useful? A reaction helps others find it too. Questions about the API or building with it? I’m in the comments.