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
The person defines the outcome.
A reviewable plan is frozen first.
Work happens in an isolated Git worktree.
Checks and independent review leave receipts.
Working pre-beta app · native Chat and Work proven · packet Work acceptance still open

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.
Ares freezes the approved plan, isolates each change, and requires independent review. Parallel work is allowed only for disjoint write sets, and every merge still belongs to the owner.
Versioned plans require approval, and Ares never chooses Merge for the owner.
A reviewed change can be re-gated after the base moves. One live merge succeeded, but its receipt still included unrelated history in the diff hash; that defect remains open.
The Episode writer is now built and tested to record each merged execution separately. Reusable patterns still need evidence from separate Objectives and owner approval.
Packet Chat was accepted. Five packet Work edits passed review and verification at a 15,087-token median, but the merge-rate comparison and Work acceptance remain open.
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.
Human in the loop means little if the system can approve its own outcome. Ares can propose, build, review, and verify, but only the owner can integrate the result. That boundary is now part of the real execution path.
Ares re-gated a one-line change after the base moved, and I merged it in the native app. The merge receipt still measured its diff from the old base, pulling unrelated changes into the hash. The merge worked; that evidence bug is still open.
Five real documentation and test edits passed verification and independent review on the first attempt. Median provider use was 15,087 tokens against a 25,000-token target. That meets the cost half of the study, not its full acceptance bar.
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.
System administration and support at the Ministry of Finance in Suriname, SoftTech, Change=, and igen placements at Sanquin and Rijkswaterstaat. I learned to diagnose clearly, communicate calmly, and improve systems after incidents.
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
Dutch and English · native proficiency / Italian · currently learning
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.