The problem I wanted to solve
AI can change code quickly. That is not the same as knowing what changed, why it changed, whether it passed, and when a human should stop it.
Software developer and systems specialist building practical AI products.
Years in support taught me where work actually breaks. Now I turn that experience into practical AI products with clear plans, human approval, and proof that the system did what it said.
Amsterdam, NL · Open to AI and product engineering roles
Scroll to inspect the proofsystems → product → AI
One continuous chain of evidence
- Human intent
The person defines the outcome.
- Plan
A reviewable plan is frozen first.
- Build
Work happens in an isolated Git worktree.
- Verify
Checks and independent review leave receipts.
Ares is how I am learning to build AI responsibly.
Working pre-release product · private repository
So I made approval part of the workflow.
Ares freezes the plan before execution, isolates the work, records commands and diffs, routes an independent review, and fails closed when proof is missing.
Latest local evidence
- harness gates passing
- test methods
- test files
What the architecture protects
Human authority
Plans require approval before mutation.
Traceable work
Commands, file changes, checks, and review become receipts.
Model independence
Claude, Codex, Gemini, GitHub, and local Ollama adapters are routes, not the product.
Recovery
Interrupted work can be inspected and resumed instead of disappearing into chat history.
Notes from the workbench.
I learn by building. These are short records of what I tried, why I tried it, what failed, and what I am taking into the next iteration.
The approval step is part of the productAI agent engineeringOpen note
Calling a product human in the loop means little if approval sits outside the real execution path. In Ares, the plan becomes an immutable checkpoint. That constraint made the interface clearer and the engineering more honest.
Reliability lives in receipts, not confidenceEvaluation and verificationOpen note
A polished answer can still be wrong. I am learning to treat tests, diffs, command results, reviewer findings, and explicit failure states as product features, not backend trivia.
Tools should be routes, not magicOrchestrationOpen note
The most useful agent systems do not hide the work. They choose a capable route, expose the tradeoff, and give the human a clean way to intervene. That is the standard I am building toward.
Systems experience is my AI advantage.
I know the distance between a promising demo and a tool people can rely on. My background is support, administration, documentation, migrations, and translating between technical systems and the people using them.
- Identified blockers in process flows, proposed improvements, implemented changes, and kept documentation current.
- Led the migration upgrade from a discontinued Excel version to Microsoft 365.
- Contributed to the innovation team and led the creation of the game room.
- Acted as the first point of contact between business partner Trip.com and internal employees.
System administration and technical support across the Ministry of Finance in Suriname, SoftTech, freelance work, Change=, and igen placements at Sanquin and Rijkswaterstaat. I learned to diagnose clearly, communicate calmly, and improve the system around each incident.
Education
NATINMBO level 4 · ICT Application Development · completed 2018, diploma issued Feb 2019
Inholland University of Applied SciencesBusiness IT & Management coursework · 2022 to 2024 · no degree claimed
Languages
Dutch and English · native proficiency / Italian · currently learning
Bring me the complicated part.
I am looking for a team where I can combine systems thinking, product curiosity, and practical AI engineering, especially close to real users and real operational problems.