Sobre
Sobre mim
Sou Luiz Claudio Hogrefe, arquiteto de software em Colônia.
Publico como Luiz Hogrefe. Desenvolvo software desde 2008, primeiro no Brasil e, desde 2014, na Alemanha. A maior parte desses anos foi em projetos corporativos em que uma arquitetura precisa sobreviver a auditorias, sistemas legados e passagens de bastão, e não apenas a um primeiro release.
Hoje meu trabalho está onde a arquitetura de software encontra a IA governada, a interoperabilidade semântica e as evidências digitais rastreáveis. O que me importa não é tanto o que um sistema consegue fazer em uma demonstração, e sim o que ele se recusa a fazer, o que consegue provar depois e quem tem permissão para alterá-lo.
Como cheguei até aqui
Comecei em 2008 como programador na Edusoft, em Blumenau, trabalhando nas rotinas financeiras e acadêmicas de um sistema web de gestão acadêmica. Na FURB, a universidade regional, fui desenvolvedor de software e depois analista de sistemas, e ali concluí meu bacharelado em Ciência da Computação. Meu trabalho de conclusão aplicou ontologias ao desenvolvimento de sistemas de informação em um contexto de computação em nuvem, um tema que ainda atravessa meu trabalho com semântica.
Em 2014 me mudei para a Alemanha. Depois de um estágio em desenvolvimento Java em Berlim e de um cargo de desenvolvedor de software em um provedor de nuvem privada em Düsseldorf, trabalhei de forma independente em aplicações web e mobile.
De 2017 a 2022 fui consultor na Sopra Steria, em projetos para clientes dos setores de energia, bancário e automotivo. O trabalho foi do desenvolvimento de aplicações web à arquitetura e documentação de uma plataforma de orquestração e a conceitos de implantação. Depois de um ano no Brasil na gestão interina de uma empresa familiar, voltei à consultoria na msg, em Colônia, como desenvolvedor, Scrum Master e gerente de testes.
Em 2024 comecei uma pesquisa independente sobre interoperabilidade semântica, passaportes digitais de produto e as regras europeias que vão exigi-los. Em 2025 trabalhei na Accenture em engenharia de qualidade, como Scrum Master e testador em um programa corporativo. De agosto de 2025 a abril de 2026 fui responsável pela arquitetura e liderei o desenvolvimento do AnyImob, um assistente de IA para corretagem imobiliária. De maio a agosto de 2026 fui arquiteto de software na divisão de Normas da IW Consult, em Colônia, trabalhando com arquitetura e modelos de dados para passaportes digitais de produto e com o ECLASS como semântica para gêmeos digitais.
Desde setembro de 2026 desenvolvo minha pesquisa de forma independente por meio da AnyLAI, um projeto de P&D sem fins comerciais.
Como penso arquitetura
Para mim, arquitetura é o conjunto de decisões caras de reverter, registradas onde possam ser verificadas. Um diagrama ajuda. Uma fronteira que o pipeline de build faz valer ajuda mais.
Em ambientes regulados isso se torna concreto. Um requisito do ESPR, do EUDR ou do AI Act não é um rótulo a ser colado em um sistema depois. É uma entrada, como a latência ou o volume de dados, e precisa aparecer nos modelos de dados, nas interfaces, nas etapas de revisão e nas evidências que o sistema guarda.
Modelos de IA capazes mudam o lugar onde está o trabalho difícil. Quando a implementação fica mais barata, intenção, restrições e verificação ganham valor. É essa a tese em que trabalho agora.
Como trabalho
Cinco princípios que aplico ao meu próprio trabalho. São hábitos de engenharia, não leis da natureza.
- 01
Arquitetura acima de slogans
Um sistema se descreve pelas suas fronteiras, pelas suas interfaces e pelo que ele se recusa a fazer. Uma afirmação que não pode ser ligada a nada disso ainda não é arquitetura.
- 02
Fronteiras determinísticas em torno de sistemas probabilísticos
Modelos são úteis e falíveis. Eles fazem um trabalho delimitado atrás de regras que decidem, mantêm registro e podem ser reexecutadas, e nunca são a origem de uma permissão.
- 03
Evidências que outra pessoa pode verificar
Um resultado vale o que o leitor consegue verificar sem confiar no autor. Suas fontes, sua versão e a pessoa responsável por ele o acompanham.
- 04
Padrões sem aprisionamento
Primeiro os padrões públicos, como W3C Verifiable Credentials, UN/CEFACT e GS1, para que o que eu construo possa ser verificado, substituído ou passado adiante sem depender de mim.
- 05
Tornar a ambiguidade explícita antes de automatizá-la
A automação amplifica tudo o que recebe. Um requisito ambíguo vira um erro consistente; por isso, primeiro registro a ambiguidade por escrito e a resolvo com as pessoas responsáveis por ela.
Idiomas
Trabalho em quatro idiomas, e é também por isso que este site existe em quatro.
- Portuguêsnativo
- AlemãoC1
- InglêsC1
- Espanholproficiência profissional
Pesquisa atual
Minha pesquisa é desenvolvida e publicada por meio da AnyLAI, um projeto independente de P&D sem fins comerciais. Não é uma empresa, e nada do que publica é uma oferta.
Até agora, ela inclui o COADF, um framework publicado para construir software assistido por IA sob governança explícita; o ERQYO, uma arquitetura de execução para decisões governadas, com uma implementação de referência; e o AnyDPP, um ambiente de pesquisa para passaportes digitais de produto baseados em evidências.