AI fullstack engineer based in North Rhine-Westphalia, Germany. I work the whole distance, from the data model through the API to the last pixel - and most of it now gets built with agents: spec first, gates in between, evidence at the end. Language models are both the tool and a part I build with. What comes out has to be checkable, not just plausible.
Building software - especially at the rate it's now possible to build - still requires enormous skill, experience and depth of understanding.
These are the areas where I make decisions and own the outcome.
The area I'm going deep on right now: working with agents, building context deliberately instead of polishing prompts, and checking results before believing them. A repository an agent is meant to work in becomes the interface itself - its rules, skills and tools sit inside it as files. The next step is using language models as a building block of an application myself.
Component architecture that still makes sense after the tenth feature. Type safety from the API all the way into the template. Components arrive in the editor through an MCP server rather than being retyped - a design skill in the repo keeps tokens and states straight while they do.
REST APIs documented before anyone needs them - the docs are pulled out of the code by an agent and kept current, triggered by a hook rather than by my memory. Data models you can still migrate later. Auth that isn't hand-rolled.
The road from a merged branch to a running release: pipeline, tests, containers, and an artifact nobody assembles by hand. Before a human review an agent walks the diff - conventions, edge cases, and whatever the PR does not mention. It spares the review the points nobody wanted to argue about anyway.
I read Figma files instead of guessing at them, and flag early when a layout gets expensive to build. What "done" means sits in the repo as a skill - tokens instead of hex values, every state, contrast checked - so an agent holds to the same bar I do.
Three projects from where agents meet real systems: a checker for a protocol break, an MCP server over 995 German waste authorities, and a skill set for working unattended. Links go to the real instance, not a video.
A checker for the MCP break: skill, CLI, action, demo
The MCP 2026-07-28 revision makes the protocol stateless and breaks nearly every server built for the old one. One rule engine with four ways in: a web demo, an `npx` command, a GitHub Action, and an agent skill that does not stop at the diagnosis but works the migration rule by rule. The skill now installs as a Claude Code plugin served from the repository, so it cannot go stale against the rules it ships, and the CLI sits on npm as a package with an empty dependency tree. I pointed the same engine at 13,380 registered endpoints: 60.1% speak only the old protocol.
Collection dates from 995 authority portals, as an MCP server
Waste collection in Germany is organised municipally: roughly 400 authorities each run their own portal, and there is no nationwide API. The server takes an address, resolves the municipality through Nominatim, finds the responsible authority among 995 drawn from 150 source modules, and pulls the dates from that authority's portal. The work is not in the dates, it is in the step before: in Home Assistant a human clicks their authority together once by hand, and an MCP server has to manage it alone - or ask, when it cannot manage it with certainty.
34 skills so an agent can finish a ticket on its own
A set of 34 skills for Claude Code, built for enterprise codebases. The idea behind it: autonomy does not come from better implementation prompts, it comes from moving the human decision out of the middle and to the edges - spec and acceptance criteria before, review and an evidence package after, and a ledger instead of a question in between. Because a question raised mid-implementation has exactly two causes: missing context, or a spec that was already undecided. Four of the rules install as hooks, which makes them enforced rather than requested.
A month of working with agents in numbers, and the year on GitHub.
Four steps I keep the same, whether it's a feature, a prototype, or a side project in the evening. An agent works inside each of them now, which changes nothing about the order: surprises at the end cost more than questions at the start.
Who uses this, for what, and what happens if it doesn't exist? Before a line of code, I want to be able to answer that in one sentence. Then an agent takes the question apart looking for holes: the state nobody described, the case without permission, the list with ten thousand rows. Whatever stays open goes back to a person before it becomes a silent assumption in the code.
Data model and screens take shape together, not one after the other. Wherever the model is awkward, the interface will be too. That becomes a spec with acceptance criteria and a blast radius, meaning the files a run is allowed to touch. Leave out either one and the agent asks halfway through, which is exactly when it stops.
Small branches, type-safe from database to button. Most of it is typed by an agent that first reads the repository for how we solved the same thing before, because convention beats taste. Decisions it makes on its own get written down with the reasoning instead of stopping the run for a question. It stays deployable every single day.
Before a person looks, a pass runs that shows rather than claims: typecheck, tests and build green, screenshots of the states, and an agent walking the diff for conventions and edge cases. Whatever is still open after that sits in the PR, not in somebody's head. The launch is where operations start: monitoring, a status page, and a way back if something tips over.
A substantial share of the code I deal with every day is now written by agents, often several in parallel, each with its own task and its own context. That doesn't take the work away, it moves it from writing to checking - where more code gets produced, reading is what becomes expensive. So a run hands over more than a diff: gates green, screenshots of the states, and the decisions it took on its own along the way. Five things I've learned doing it.
An agent is only as good as what it is allowed to see. The real work is putting the right files, limits and examples in front of it, not phrasing the sentence more elegantly.
A plausible-looking result is not evidence. Build, types, tests, and when in doubt a measurement against the running system. What isn't checked doesn't count - and the proof belongs to the run, not to whoever reviews it. Otherwise every review starts from nothing.
Large changes in one sweep are as bad for agents as they are for people, just wrong faster. Small steps you can check one at a time can be undone without losing the day.
Running several agents in parallel only pays off when their tasks don't overlap. That moves the work upstream: cutting tasks so each one is checkable on its own and none of them walks into another's files.
Sometimes a wrong answer comes back with total confidence. Accepting it because it reads well costs days; asking one more question costs minutes.
Code is the part I get paid for. Here's the rest.
alpay - ai fullstack software entwickler, Halle (Westf.), DE I like the moment a system stops beinga pile of files and starts behavinglike a tool somebody can pick up. smarthome/ 3d-printing/ family/ travel/ The tinkering continues at home: sensors, automations, and the question of which ones anybody still uses two weeks later. And whatever I can't buy, I model and print myself: mounts, enclosures, spare parts.
The most important part of the day happens away from a screen. I love doing things with my family: getting out, being on the move, experiencing something together. The best reset I know.
I genuinely love travelling: new places, new food, regions you'd only ever seen on a map. It's also a good test of how quickly you find your way around something unfamiliar.
A technical question, a disagreement with something I wrote, or just a hello. Write to me. I read everything and reply as soon as the day allows.