↓ Skip to main content
Michael Hönnig
Michael Hönnig

Michael Hönnig

Senior software developer, backend focus
Java, Kotlin, Spring Boot, PostgreSQL, ReBAC, agentic-AI-assisted development

Software development and consulting
#

Until autumn 2027 I am only available for consulting engagements with a small number of hours – remote, in German and English.

My stack: Java / Kotlin / Spring Boot, PostgreSQL / pl/pgSQL, TypeScript / Angular. Current focus: ReBAC (relationship-based access control) and the use of agentic AI in software development – “vibe engineering”, i.e. AI-assisted software development with engineering discipline, as opposed to “vibe coding”.

How I work: It starts with a conversation to capture the domain, written down as BDD with Gherkin. Continuously gather fast feedback and incorporate it. During development XP / Kanban. Suitable tooling is built alongside to increase efficiency. Generated documentation is more correct and more current than hand-maintained documentation.

Get in touch Profile

Recent

Gray Software Factory: Autonomy by Risk, Not by Dogma

·7 mins
AI Software-Development
AI software factories come as light factories with a human in the loop and as dark factories without human reviews. A gray software factory works autonomously by default, but decides for every single change, based on an automated risk and quality classification, whether a human needs to be involved.

Warum Secrets-Manager wichtig sind – und was ich darüber gelernt habe

·5 mins
ISMS
Seitdem ich, vor langer Zeit, mit dem Konzept Secrets-Manager in Kontakt gekommen bin, hatte ich ehrlich gesagt immer nur eine vage Vorstellung davon, was für einen Vorteil diese eigentlich bieten, wo doch das System, welches ein Secret abfragen darf, sich dafür bereits authentifizieren muss. Wie genau autorisiert sich also z.B. ein Webserver gegenüber einem Secrets-Manager, um dort Datenbank-Zugangsdaten abzurufen, und …

This article is only available in German.

Exploring Lombok’s val: Advantages and Disadvantages

·6 mins
Java
This article examines Lombok’s val — how it uses annotation processing to infer local variable types and enforce finality—highlighting benefits like cleaner, more readable code, compile-time safety, immutability, pre–Java 10 support, and seamless Lombok integration, while weighing drawbacks such as redundancy with Java 10+ var, reduced flexibility due to final variables, reliance on compiler internals with potential compatibility risks, and possible lag in new JDK support; it recommends using val chiefly in Lombok-heavy, pre–Java 10, immutable contexts, but preferring native var in modern Java and planning a long-term shift toward Java-native features.

Topics