Through AI
AI as tool.
The platforms and code underneath everything — why I ship in weeks, not quarters.
Build it. Measure it. Publish it.
AI in production is harder than AI in the lab. I document the difference.
Apuna. Field notes.
I run AI implementation in industrial service — voice agents, LLM evaluation, EU AI Act compliance in a unionized shop. A Dr.-Ing. in planning. This is where the methods and failures land.
View on GitHub →Field thesis
Most AI projects I've seen in industrial service stall at proof-of-concept. This is what I've found about the ones that don't.
The pilot ran. Production never did. The gap is almost always the same — and it's not the algorithm.
The pattern
What I see before a project stalls
- —AI projects that stall at proof-of-concept — and never make it to production.
- —Expensive platforms bought in good faith — no support, no SLA when the first real problem hits.
- —Machine data over OPC-UA, Modbus, MQTT that no one translates into decisions.
- —Large consultancies that send an account team — and nobody with a feel for the shop floor.
- —No in-house AI team — and no appetite for the next vendor lock-in.
- —Tools that shine in the demo and fall apart on the first production shift.
The method
What actually works
Same person plans and builds.
The approach
Sensors to decisions — in production
I start with the sensor data. Connect, translate, make it actionable. Build systems that take on real operational work — on the floor, not just in a pilot.
The commitment
Open, documented, yours to run
I stay involved after handover. Not as a managed service — as a documented, open-source system you own and can run. I'm reachable when the edge case appears.
Why this matters
What the pattern teaches
- ›Same person plans and builds. No handoff between the person who understands the system and the person who maintains it.
- ›Mechanical engineering, not just Python. I translate between the model and the shop floor — in both directions.
- ›Your infrastructure, no lock-in. Vendor-neutral, runs on your own systems. No black box — your data and your IP stay yours.Every change logged and greenlit by a human.
- ›Field evidence before architecture decisions. I run the first integration against real production data before committing to a design. The constraints only appear when the real system is in the room.
One conversation. One concrete problem. One honest assessment.
apuna.dev · Germany
Whitepaper
Read the whitepaper / as PDFAI you can audit and run yourself — how I build it.
01 — How I work
How I work — and where I draw the line.
AI isn't my pitch. It's my daily driver. Infrastructure, sparring partner, enabler — and I know exactly where it stops.
With AI
AI as partner.
Human and AI reasoning together toward an outcome neither reaches alone. I stay in the loop. No handoff.
Because AI makes it possible
AI as door opener.
Work that didn't exist two years ago — new questions, new roles, new speed. I try to notice when that's exactly what's happening.
Despite AI
AI as limit.
Some things stay human. Not because policy says so, but because I choose it every time. I'm deliberate about where AI has no business.
I document what the field teaches — failure included.
07 — The crew
How I work
I work alone — with an AI crew for thinking, designing, and pressure-testing. No freelance network, no account team, no investors. What you find on this site comes from one practitioner, reviewed and greenlit before it publishes.
MY AI AGENTS
And the AI crew I work with
These are AI personas — not human team members. Every output they produce is reviewed and greenlit by a person before it ships.
The Chairwoman is the constant — continuity and the long view; the working crew drafts, designs, engineers, and pressure-tests, with an advisor who keeps the circle wide. I make every call.
Core team
Advisors
02 — The method
Four steps. Always in this order. The order is load-bearing.
Process Analysis
I've never found a useful AI intervention that wasn't preceded by understanding where the work actually happens — not in documentation, not in org charts, but with the people doing it. Map the friction before you pick the tool. Every time.
Read more
Knowledge Capture
The most dangerous gap in any industrial operation is between what experienced people know and what's written down. When they leave, the knowledge leaves. Surface it, structure it, make it retrievable — before it walks out the door.
Read more
Automation
The question isn't 'what can I automate?' It's 'what costs human judgement to do, but doesn't actually need it?' Start there. Leave everything that genuinely requires judgement where it belongs.
Read more
AI Integration
AI is the last step, not the first. It only works when the process is already clean and the knowledge already structured. In that order. Reverse it and you're automating the chaos.
Read more
Devlog
Every decision, every failure — documented as it happens.
Not a project summary. Working notes from someone doing this in production: what I tried, what broke, why I changed direction. Read it before you make the same mistakes I did.
Read the devlogUpdated as the work progresses
03 — Open by default
Everything I build is open. Everything I learn is published.
Code is Apache-2.0. Methods written up. Fails alongside wins. Not a policy — how research stays honest.
Apache-2.0
Everything I build for this work is Apache-2.0. Read, fork, run, build on. No strings, no eventual lock-in, no open-core asterisk hiding the real product.
Methods, not just results
Publish the approach with the outcome. Finding without method = anecdote. Devlog and research both show the working.
Failures documented
What doesn't work matters as much as what does — sometimes more. I write up fails so a peer reading this in a year doesn't repeat the same mistakes.
Knowledge stays open
Nothing I learn disappears behind a paywall or retainer. If it's useful, it belongs in the open. That's the point of doing this publicly.
05 — How I think about responsibility
The rules I work by. No ambiguity about who decides.
I've thought carefully about where AI output ends and human judgment begins. These aren't legal disclaimers. They're the principles I actually design to.
Human decides — always
Every output I work with hits a human decision point eventually. I design for that. AI helps; it doesn't decide. Principle I hold before it's a requirement.
Accountability follows design
EU AI Act draws a clear line between builder and deployer of an AI system. I take that seriously — not as compliance burden, but as design problem. It's the research question for my planned doctorate.
“I carry the design. You carry the decision.”
06 — About
Who I am.
Engineering background, field practice
M.Sc. Wirtschaftsingenieurwesen, TH Mannheim, 2015. I run AI implementation at an industrial services outfit — voice training agents, LLM evaluators, EU AI Act compliance in a unionized shop. Sector constraints are my daily context, not a brief I read last night.
Research in planning
Working towards a Dr.-Ing. at Hochschule Heilbronn and TH Mannheim, starting Q3 2026. Research question: how LLM-based training systems are designed, and how tech adoption in industrial service actually works. Design Science Research + mixed methods.
Why I publish
Weekly questions aren't just mine. Practitioners in similar seats carry the same problems — and useful answers are rarely written down anywhere. This site fixes that. Code's Apache-2.0. Take it.
What I'm buildingIn development
Small tools. Real decisions. Documented here.
Running log of small, focused tools I build to test ideas and document publicly. Each starts with a decision worth making — not a feature list. See the case study.
- 01
Find the decision worth making
Every tool starts with one real question — currently answered by gut feel or a spreadsheet nobody trusts.
- 02
Get the data
Identify what data actually exists, retrieve it, check if it's good enough to build on. No data, no tool.
- 03
Build small
One decision, one interface, nothing extra. Constraint is the point — scope creep is how tools stop working.
- 04
Document it
Each tool ships with a write-up: what I built, why, what I'd do different. Devlog is the audit trail.
First tool
Commodity Intelligence
Auto-identifies the five commodities that matter most in direct purchasing, weighted by value add, then tracks spot and futures markets so buy and hedge decisions are grounded in evidence — not gut feel.
Decision support for procurement teams — not financial advice.
Try the toolSecond tool
Component Setup Guide
Name a component, optionally drop a product page URL. Tool fetches docs, resolves exact variant, grounds every wiring, config, and code claim in what was actually found — with explicit refusals where docs are missing.
Experimental · free models · verify against manufacturer datasheet before wiring.
Try the toolThird tool
Office Plant Care
Weather- and season-aware watering log for office plants — small, focused live app on the open core, public read. Single-decision tool — same kind I build for any problem worth solving.
Live demo · public read; write for team only.
View the appFourth tool
Plant Sandbox
Consequence-free virtual plant to tend. Water, adjust light, over-water, watch recovery — all state ephemeral. Built to demo the sandbox principle: a wrong click costs nothing.
Public · no auth · reset on reload — safe space to explore.
Try the toolHow to engage
Three ways to engage with the open code.
All Apache-2.0. Pick the involvement level that fits.
- First01
Community
Run it yourself — clone repo, supply your own keys and domain. Code and docs are the whole thing.
- Then02
Devlog
Follow builds as they happen — decisions, dead ends, what shipped. Subscribe and pick up patterns at your own pace.
- Finally03
Direct
Reach out for a specific integration or problem. No retainer — just a direct conversation.
08 — Contact
Say hello.
If you're doing adjacent work — AI in production, LLM evaluation, the EU AI Act inside a real organisation — I'd like to hear from you. I write back.
Researching AI-integration challenges across industrial teams for my doctorate — say so below and I'll prioritise a reply.hello@apuna.dev
Typical response within one business day