i'm a software engineer based in the philippines, driven by curiosity and whatever i find interesting. i learn fast with the caveat of goldfish memory (which i call my context lol) and i'm usually self-motivated that i forget to eat.
this is not like other portfolios. feel free to have a look around and explore what makes me, me.
drag empty cork to move around.
drag notes to rearrange them.
use +/− or pinch-wheel to zoom.
click any note to open it.
@schmayterling
open githubrecruiter?
(follow the red line) →the same circle, over and over.
for those who want something simpler
enter simple mode
i enjoy writing code.
if ai solves every problem,
what's left?892 commits. the personal AI agent i've been trying to build since 2023 is finally becoming something i'm proud of.
one question usually turns into three projects and too many open tabs.
typescript, python, rust, go, infrastructure, and agents.
in roughly five weeks
an earlier role handled 2,000+ requests a day at 99.3% uptime.
i update this board whenever my attention changes, so it never settles into a final form.
how WFDs work, when to write one, the states a document can be in, frontmatter format, and the markdown features available.
my desktop is scattered screenshots, dozens of windows, half-finished checklists, and constant switching.
whatever feels urgent or interesting gets the whole pile.
right now, only this website and my ai work count as current.
did i mention this board evolves over time? you might find new stuff here next time. suggestions? email me.
hey@ryanaque.com
i turned weeks of neuroscience papers into her memory system.
weave gives long-running agents memory, state tracking, and retrieval that can be inspected.
i watched a kdrama about a girl who forgets everything every morning and realized my AI agent has the same condition. so i built it a brain.
someone else is
on the other end.
i'm less interested in whether it's good.
ideally when something is coming up, whether it's work related or it's just a personal project of mine i usually let it run at the end because i need pressure to perform things.
diffusion models
i built an AI agent with persistent memory. now i need to figure out if it's remembering the truth or just what i wanted to hear.
AI makes me faster. It also might be making me dumber. I'm figuring out where the line is.
“A clean architecture and OOP enthusiast.”
— kaii.liiA user recorded a 4-hour meeting. Hit stop. Nothing showed up. IndexedDB silently deleted the session, and I still don't know why.
atlas maps symbols, calls, tests, and history so developers and agents can ask structural questions about a repository.
2,239-trial benchmark across 8 OSS repos: Atlas beats a text-search baseline by +0.223 deterministic, +0.127 LLM-judge, at 42% fewer tokens.
orchestrator lets a local model read and control a live chromium page through the devtools protocol.
opening note
wfd / Jul 10, 2025 / 2 min
Legacy This WFD was imported from old blog posts scattered across my files. It may still be relevant or it may not. Kept for the record.
A user on Android Chrome recorded a 4-hour meeting. Hit stop. Nothing showed up. No file, no recording session, just "Recording Not Found" errors everywhere.
I got woken up at 5am for this.
The weird part: the recording kept going even after the failure started. The failure only manifested at the very end.
| Time | Event |
|---|---|
| T+0m | Recording started, session created successfully |
| T+0m → T+xm | Recording running normally |
| T+xm | ??????? |
| T+240m | User hits done, nothing's there |
We save audio in 5-second chunks, tracked by a session record. We have checks on every chunk to verify the session exists. But something nuked the session at some point, and the recorder kept chugging along anyway.
I couldn't replicate it. Tried everything. Finally, I manually deleted the IndexedDB entry for that session.
Same issue, replicated successfully.
So something deleted our IndexedDB entry. We don't have code that deletes session entries. Either .put() failed silently, or the browser did something.
While debugging, I found a post by @pesterhazy called The Pain And Anguish Of Using IndexedDB. Turns out IndexedDB is notoriously unreliable across Firebase, PouchDB, Amplify—basically anyone who thought browser storage was a good idea.
The post documented:
.put() failing silently but resolving anywayOur situation:
- store.put succeeds at start
- Random deletion happens without QuotaExceeded or any error
- No stack traces, nothing
This wasn't a bug we could fix. We literally don't know what caused it.
Since we couldn't prevent this class of failure, we rewrote the recording flow to survive it:
IndexedDB will still do whatever it wants. But now when it breaks, the system screams instead of silently losing four hours of someone's work.
I don't trust any storage that resolves without verification. If a write says "done," I verify it actually wrote. If a session disappears, the system halts immediately. If storage breaks, recovery kicks in from another source.
Never trust blindly. Add redundancy even when you're sure it'll work. Because I don't want another 5am wake-up call because I trusted a "well-documented" browser API.