First-principles breakdown
I try to strip problems down to base parts: inputs, outputs, constraints, state, feedback, and what actually changes when something works.
Jerry Mares • DeuceBucket • AI-assisted systems
I build small AI systems to test my own ideas.
I’m Jerry Mares. Online I usually build as DeuceBucket. I do not come from the traditional computer-science path. My ideas usually start from my own questions, hunches, or frustrations. I use AI as a thinking partner, challenger, and build assistant, then try to turn the useful pieces into something testable: a prototype, a workflow, a spec, a runbook, a failed experiment, or a better question.
Plain version
Not a traditional senior engineer. Not “just a prompt guy.”
My useful skill is somewhere in the middle: I start with my own idea, ask why it should or should not work, push against the default answer, shape the prompts and constraints, test where the system breaks, and document the parts that survive. Some repos are rough. Some are dead ends. I keep the trail because the trail shows how I think.
How I work
The pattern is simple: ask why, then test it.
AI as challenger
When an AI says “that cannot be done” or “do it this way,” my next question is usually why — or why not this other way?
Prototype archaeology
I keep failed starts, notes, tests, and docs because the path matters. The failures show what got ruled out.
Hugging Face
Model notes I’m learning from.
I do not claim I trained frontier models from scratch. Hugging Face is where I keep some public model experiments, GGUF notes, local inference attempts, benchmark notes, and model cards that other people can inspect.
Public model experiments
I publish some of my model work under the DeuceBucket handle so the files, notes, and usage instructions are visible instead of only talked about.
Cerebellum notes
The Cerebellum pages are where I document mixed-precision ideas, file-size tradeoffs, tensor choices, usage commands, and benchmark results as carefully as I can.
Readable artifacts
The goal is simple: leave enough notes that someone else can see what I tried, what worked, what is uncertain, and what still needs better testing.
Selected projects
Evidence from the repo trail.
These are not trophies. They are examples of what I keep circling back to: memory, feedback loops, self-hosting, testing, model behavior, and making AI systems easier to understand. Private work stays private; public front pages are linked where that makes more sense.
Agent staterepo ↗
Clanker Soul
Experiment in persistent AI-agent state: mood, memory pressure, feedback loops, trigger-driven behavior, and host integration rules.
- Explores state that survives across events instead of resetting every turn.
- Separates scoring, behavior, consequences, and host responsibility.
- Shows my interest in AI behavior that can be inspected and constrained.
AI product flowsite ↗
ScritHub
Writing and worldbuilding workflow with AI assist, suggestions, review, approval, and merge-style thinking.
Books + audiosite ↗
Skaldleita
Book metadata and audiobook-identification infrastructure with organic early usage through Library Manager, including audio-identification jobs that shaped matching, queueing, and reliability work.
Self-hosted AIrepo ↗
Library Manager
Library tooling and local-AI planning, including privacy-minded ideas like Ollama support.
AI languagerepo ↗
Clanker
Older experimental line around AI language, structured signals, scoring, and response behavior.
Modelsprofile ↗
Hugging Face notes
Public model files, local inference notes, model cards, benchmark notes, and community-facing experiments.
Resume angle
AI-assisted systems builder
I am looking for work where curiosity, documentation, testing, and AI workflow design matter more than pretending I followed the normal path. I am strongest when I can start from my own question, challenge the default answer, and turn the answer into something concrete enough to inspect.
Current focus
Turning AI-assisted experiments into clearer systems with boundaries, failure modes, docs, review loops, benchmark notes, and public artifacts.
Useful background
Residential youth-care work, practical problem solving, manufacturing reliability, ADHD/autism-informed pattern recognition, and a lot of learning by building.
Honest boundary
I am not selling myself as a conventional software engineer. I am selling the ability to reason with AI, challenge assumptions, structure messy ideas, and make prototypes legible.
Contact
Best place to start is the public trail.
If you want to understand how I think, look at the projects, docs, model cards, tests, and failed starts too. I am trying to get better in public without pretending the path was cleaner than it was.