Imporved the site
This commit is contained in:
1 parent
888fb6289d
commit
db2bc7ab97
10 files changed
+78
-44
No files matched your search
+16
-16
@@ -29,7 +29,7 @@
|
||||
"PROFILE": "Profile photo of Andreas Dahm"
|
||||
},
|
||||
"HELLO": "Hello, I’m Andreas.",
|
||||
"LEAD": "Senior software developer and architect, 15+ years in the field. My work sits across two areas that rarely meet: real-time 3D simulation — cloth physics, collision detection, GPU shaders — and distributed cloud architecture for enterprise platforms. Along the way I have led a development team, planned the migration of a large legacy monolith to microservices, and shipped a game on Steam. More recently I have been working on the engineering side of AI-assisted development: the harnesses, guardrails and quality gates that make generated code reviewable. Outside work I build games and dig into algorithmic problems — most of which end up somewhere on this site.",
|
||||
"LEAD": "I have been working as a software developer since 2010. Most of that time went into two fairly different corners. One is real-time 3D simulation: cloth physics, collision detection, GPU shaders. The other is cloud architecture for larger enterprise platforms. I led a small backend team for a few years, planned the move of a big legacy monolith towards microservices, and released a game on Steam together with my brother. Lately a lot of my time goes into tooling around AI-assisted development, mostly into making the output reviewable instead of just fast. In my free time I build games and mess around with algorithms. Most of that ends up somewhere on this site.",
|
||||
"ROLE": "Senior Software Developer / Full-Stack Developer / Software Architect",
|
||||
"LOCATION": "Munich · Remote",
|
||||
"VIEW_PROJECTS": "View projects",
|
||||
@@ -187,12 +187,12 @@
|
||||
"PROJECT": {
|
||||
"CLAUDE_BOX": {
|
||||
"TITLE": "Claude-in-a-Box",
|
||||
"DESCRIPTION": "A containerised development environment that turns an AI coding agent into a reviewable part of the toolchain. Instead of prompting ad hoc, the box routes the agent through per-stack rules, per-repository architecture profiles and commit hooks that refuse to let a red build through.",
|
||||
"DESCRIPTION": "A development setup in a container where an AI coding agent works under fixed rules instead of ad hoc prompting. It picks up the rules for whatever stack it finds in the repository, and a git hook stops the commit if the build or the tests are red.",
|
||||
"LINK_INTERNAL": "Project details",
|
||||
"HIGHLIGHTS": {
|
||||
"P1": "Deterministic context routing: the agent loads the rules for the stack it actually detects in the repository.",
|
||||
"P2": "Commit gates that block on a failing build or test run, so generated code cannot bypass the quality bar.",
|
||||
"P3": "MCP integrations for code intelligence and read-only ticket access, plus subagents that review the diff."
|
||||
"P1": "The agent loads the rules for the stack it finds in the repo, so a Java service and a frontend get different ones.",
|
||||
"P2": "A commit hook runs the build and the tests and blocks the commit when they fail.",
|
||||
"P3": "MCP servers for code search and read-only Jira access, plus separate review agents that go over the diff."
|
||||
}
|
||||
},
|
||||
"P2": {
|
||||
@@ -364,17 +364,17 @@
|
||||
},
|
||||
"CLAUDE_BOX": {
|
||||
"TITLE": "Claude-in-a-Box",
|
||||
"SHORT_DESCRIPTION": "A containerised, rule-driven environment for working with an AI coding agent.",
|
||||
"INTRODUCTION": "Working with an AI coding agent is easy to start and hard to keep honest. The output looks plausible, so the expensive failures are the ones that pass review. Claude-in-a-Box is my answer to that: a Docker-based development environment where the agent operates under the same constraints a new colleague would — the architecture rules of the repository it is in, and a build that has to stay green before anything can be committed. The interesting engineering is not in the prompts; it is in the harness around them.",
|
||||
"BULLET_1": "Containerised workspace with pinned toolchains — SDKMAN-managed JDKs and Maven, Node, and a persistent home volume that survives a container rebuild.",
|
||||
"BULLET_2": "Context routing by detection: a repository with a pom.xml loads the Java/Spring rules, one with a package.json loads the TypeScript rules, and a repository with its own architecture profile loads that too.",
|
||||
"BULLET_3": "A commit hook that detects the stack itself, runs the matching build and test gate, and blocks the commit when it fails.",
|
||||
"BULLET_4": "MCP servers for code-graph queries and read-only ticket lookup, plus purpose-built review subagents that grill a finished diff before it is reported as done.",
|
||||
"CHALLENGE_1": "Keeping the rule set small enough to stay in context but specific enough to be binding — general advice gets ignored, so the rules had to be split into stack skills and repository profiles that load only when relevant.",
|
||||
"CHALLENGE_2": "Making the quality gate impossible to talk around. The check runs as a hook outside the agent, so a failing build blocks the commit regardless of what the agent believes about its own work.",
|
||||
"CHALLENGE_3": "Toolchain isolation in a container that has no root: builds, browsers and language runtimes all had to be installed into volumes owned by the development user.",
|
||||
"LEARNING_1": "The quality of AI-assisted work is mostly a function of the harness, not the prompt. Deterministic gates beat careful wording every time.",
|
||||
"LEARNING_2": "Treating the agent as an untrusted contributor — reviewed, gated, and given only the context it needs — turns out to be the same discipline that makes human code review work."
|
||||
"SHORT_DESCRIPTION": "A container setup for working with an AI coding agent under fixed rules.",
|
||||
"INTRODUCTION": "Getting an AI coding agent to produce something is easy. Getting it to produce something you would actually merge is a different problem, because the output usually looks fine at first glance. So I built a Docker setup where the agent works like any other contributor. It gets the architecture rules of the repository it is in, and the build has to be green before anything can be committed. Most of the work went into the setup around the agent rather than into the prompts.",
|
||||
"BULLET_1": "Container with fixed toolchains: JDKs and Maven through SDKMAN, Node, and a home volume that survives a rebuild.",
|
||||
"BULLET_2": "Rules are loaded by detection. A repo with a pom.xml gets the Java and Spring rules, one with a package.json gets the TypeScript rules, and repos with their own architecture notes get those on top.",
|
||||
"BULLET_3": "A commit hook works out the stack, runs the matching build and tests, and refuses the commit if they fail.",
|
||||
"BULLET_4": "MCP servers for code graph queries and read-only Jira lookups, plus review agents that check a finished diff before it counts as done.",
|
||||
"CHALLENGE_1": "Keeping the rules short enough to stay useful. Long general guidelines just get ignored, so they are split into per-stack and per-repo files that only load when they apply.",
|
||||
"CHALLENGE_2": "Making the quality gate something the agent cannot talk its way past. The check runs as a git hook outside the agent, so a failing build blocks the commit no matter what the agent believes about its own work.",
|
||||
"CHALLENGE_3": "Getting the toolchains installed in a container that has no root. Builds, browsers and language runtimes all had to go into volumes owned by the development user.",
|
||||
"LEARNING_1": "How well this works depends far more on the setup around the agent than on how the prompt is worded.",
|
||||
"LEARNING_2": "Reviewing and gating the agent's output the same way you would a new colleague's pull request turned out to be the most useful rule of the lot."
|
||||
}
|
||||
},
|
||||
"IMPRINT": {
|
||||
|
||||
Reference in new issue
Block a user