How we work: our playbook

What does a quality gate look like here? #

A merge requires: green build, green unit tests, green integration tests against genuinely started dependencies, green E2E tests of the affected paths and a passed static analysis. Plus a review by a second person. There is no exception and no fast lane - not even for hotfixes; there the scope gets smaller, not the gate.

Test-driven development #

Red/green/refactor is a binding team standard, not a recommendation. The practical effect is less about coverage than about design pressure: code that is hard to test is usually also hard to change. Writing the test first surfaces that before the refactoring rather than after.

How do we cut an arc42 document? #

Not all twelve chapters, but the ones that carry decisions:

1. Context - who talks to the system, through which interface.
2. Building block view - down to the level at which a new person can locate a change; no deeper.
3. Runtime view - only for the critical flows: error cases, recovery, the paths where state is created.
4. Cross-cutting concepts - error handling, logging, security, configuration.
5. Architectural decisions - with rationale and rejected alternatives. This part is the most valuable and the most frequently omitted.

Documentation is part of the product here. It is created with the code, not afterwards.

What may an agent do, and what not? #

Agent-assisted development runs inside defined guardrails:

• Agents work exclusively on issues with a Definition of Ready - requirement, acceptance criteria and scope exist before the first commit.
• Nothing bypasses the pipeline. The same gates as for hand-written code.
• A separate review agent checks every change before it goes to human review.
• Tool access via MCP rather than context in the prompt.
• Architecture, security and release stay with people. Always.

In detail in the article The guardrails we set for agents.

Collaboration #

Scrum or Kanban depending on the engagement, with close coordination with product owners and business departments and short feedback cycles. Remote, hybrid or on site, throughout Germany. Project languages German and English.

Knowledge transfer #

Coaching within the team and at the client, training at industrial clients, in-house apprenticeships since 2012. A project does not count as successful here if only we can keep it running.

Collaboration models #

• Project development - a scoped engagement with a defined outcome
• Expert profiles / team reinforcement - individual specialists inside your team
• Architecture and code reviews - targeted analysis with recommendations
• AI enablement - introducing agent-assisted development into existing teams
• Training & workshops - tailored to your team
• Maintenance & further development - long-term support, including for third-party systems