Agentic Software Development: AI as a Sparring Partner — Insights from My HHU Lecture
Agentic software development in practice: how we at schnaq use AI as a sparring partner for analysis, plans and code — and why humans make the final call.
On Tuesday, 16 June 2026, I spent 90 minutes in front of computer science students at Heinrich Heine University Düsseldorf — as part of the lecture series "Software Development in Practice." My topic: agentic software development. That is, building software by directing agents and reviewing their results, rather than typing every line yourself.
There is one thing I made clear right at the start, and it matters here too: at schnaq we do not rely on AI blindly. The agent is a sparring partner — a code buddy that thinks along, does the legwork and takes over the tedious parts. The decision about what actually ships is one we humans make. It is exactly this division of labour I want to show in this post.
A shared vocabulary
Before any coding starts, a shared vocabulary pays off. These terms come up again and again — and once you keep them apart, you quickly understand what is happening under the hood.
| Term | In short |
|---|---|
| LLM | A large language model that predicts the next token — a statistical model, not an oracle. |
| Token | The unit of computation, roughly ¾ of a word. Input is usually cheaper than output. |
| Context | Everything the agent knows about the task. The more relevant context, the less it has to guess. |
| Markdown | A lightweight plain-text format — the favourite format for AI context and notes. |
The agentic part builds on top of that:
| Term | In short |
|---|---|
| Agent | An LLM that pursues goals on its own, decides and uses tools — instead of merely answering. |
| Tools | Concrete functions the agent calls: web search, reading files, sending email. |
| Workflows | Predefined sequences of steps in which agents orchestrate tools and connectors. |
| Routines | Time- or event-triggered workflows that run even when nobody is in the chat. |
And finally, how the agent connects to the world:
| Term | In short |
|---|---|
| Connector | The "connectable app" in the interface — Gmail, Notion, Calendar, GitHub, Drive. |
| MCP | An open protocol that connects models to external systems in a standardised way. |
| Skills | Reusable instructions the agent loads automatically when the right trigger appears. |
| CLAUDE.md | Project memory, read at every start — the agent starts like an onboarded colleague. |
The rule of thumb: a connector is what you click. MCP is how it speaks under the hood.
Our principle: analyse first, then decide
The most important point of the lecture was not a tool but an attitude. We use agents primarily for analysis, not as autopilots for implementation.
In practice that means: the agent reads our codebase, checks workflows, finds problems and proposes a plan. From that plan we derive clean tasks — as issues on GitHub or Linear. Only then do we humans step in and decide which of these points we actually tackle. For the analysis, the agent often dispatches several sub-agents in parallel, each illuminating one aspect and reporting back.
For this to work well, two levers decide between success and risk:
- Security. Give the agent only the permissions it genuinely needs. Full computer access means full control over everything — run it in a sandbox where possible. Reconsider for every access point where which permission ends up.
- Good context. Name the role and the task clearly, grant access to the right data and connectors, supply examples and the desired format. Whoever has to guess will hallucinate — context beats tricks.
Live at HHU: extending Shorty
For the hands-on part I brought along an old acquaintance: Shorty, a URL shortener that was built back in 2019 during a programming lab right here at HHU. It still runs today at link.cs.hhu.de on a stack of Java, Spring Boot and Redis — the code is openly available on GitHub. A grateful subject for showing live how a project like this can be extended with an agent.
The workflow we walked through together looked like this:
- Check out the repo —
git clone, the agent gets access to the code. - Analyse — the Claude CLI reads the codebase and understands the structure.
- Extract tasks — the findings go to Notion as a report and to GitHub as concrete issues.
- Commission the agent — an agent solves a selected issue on its own.
- Review the PR — we review the pull request and decide on the merge.
Every step is traceable, and at two points — choosing the issues and reviewing the pull request — control deliberately stays with us.
From practice: schnaq.com for Google and AI search
The second example came straight from our daily work: revamping our own website, schnaq.com. The goal was to bring the site up to current technical standards and make it discoverable both for Google and for AI search — that is, SEO and GEO (Generative Engine Optimization, i.e. visibility in ChatGPT, Perplexity, Google AI Overviews & co.).
It starts with an audit. Instead of going through it sequentially, we dispatch several specialised audit agents in parallel — one per dimension: metadata, structured data, GEO/LLM discoverability, performance, content & keywords, and technical SEO.
The result is not a vague gut feeling but a prioritised list: over 50 verified findings, each area rated as a scorecard, plus the biggest levers and quick wins you can ship fast.
The findings then turn into real issues. A meta-issue bundles the overall picture, the individual measures hang underneath as sub-issues — cleanly prioritised and traceable.
Only then does implementation begin — and here, too, agents work through the issues one after another, commit by commit, with a status update back after each solved point.
Capturing knowledge — a second memory
One detail that makes the difference in practice: insights must not get lost in the chat history. I capture decisions as Markdown right away — in Notion, connected as a connector and where the agent writes its reports directly, and in Obsidian as a local vault for private knowledge. The effect: next time, the agent starts with context instead of from scratch.
What stays
If I sum up the 90 minutes in four sentences:
- The work shifts from typing to directing and reviewing.
- Good context beats clever prompting.
- Tools get only the permissions they need.
- And you should capture what works — in memory, notes and skills.
Agentic software development takes a lot of routine work off our plate and helps us make well-founded decisions faster. But it does not replace judgement — it sharpens it.
Want to bring agentic work or privacy-compliant AI to your team? Get in touch for a free initial consultation — or take a first look at the full slides from the lecture.