Self-taught dev. Creator of Mochi, a native Linux desktop pet. I build Linux/web tools and write about them. Open to software engineering and technical writing roles.
I would genuinely love you forever for helping port it to macOS 😂💜 I don’t have a proper macOS test environment right now, so having someone who can actually build and test it there would be amazing. Please feel free to open an issue or PR, and ping me if anything in the codebase is confusing!
Independent AI Engineer & Complex Systems Architect. Building open-source tools, experimental systems, developer infrastructure, and products across AI, simulation, geospatial data, RF, and procedural
Self-taught dev. Creator of Mochi, a native Linux desktop pet. I build Linux/web tools and write about them. Open to software engineering and technical writing roles.
Ooooh 👀 I’d love that! Feel free to open an issue for anything you find, and PRs are absolutely welcome. If you run into anything confusing in the codebase, just ping me <3
Developer, maker, and perpetual project starter. I build web apps and dev tools mostly, things that I think are really useful and should exist and be simple to use. I also like to experiment with AI.
I absolutely love this. I haven’t gotten around to trying Mochi yet, but I am definitely going to very soon.
Desktop creatures are exactly the kind of slightly unnecessary but ridiculously fun software I love, and I really like that you took the idea so much further than just “cute thing that tells me what Codex is doing.” The persistent state, ambient awareness, bond system, focus sessions, all of it makes Mochi feel like an actual little desktop companion instead of basically a status indicator with a sprite attached.
Also, I really appreciate the whole “commit to the bit” philosophy here 😂. Sometimes the best projects come from taking a seemingly silly idea way more seriously than anyone reasonably needed to.
This is a really interesting way to approach desktop companions.
The part that stood out to me was the separation between:
what the pet is displaying
what is actually happening underneath
That distinction becomes important once you have interruptions, persistence, and multiple sources changing the state. A single authoritative state machine seems like the right direction for keeping the behavior consistent.
I also like that the focus is not only on making the pet look alive. The lifecycle and ownership model underneath is what makes the behavior reliable.
Really nice work, especially for a solo project. I’ll definitely be looking through the code.
How did you arrive at the single authoritative state machine design? Was that planned from the beginning, or did it evolve after running into lifecycle and ownership bugs?
The pets that survive week two are the ones wired to real state — exit codes, failing tests, silence — not cosmetic timers. Does yours read what the agent actually did, or only what it says? That difference is the whole toy-versus-instrument line.
I think there is an important distinction here: a feature and a product don't have to solve the same problem at the same depth.
Something that is a small feature inside a larger product can be intentionally simple. But when someone turns that idea into the product itself, the architecture, state management and user experience naturally become much deeper.
So “better” isn't always about implementing more. Sometimes it's about having a different scope and being able to optimize the entire system around one specific purpose.
The interesting part for me isn't actually the pet animation. It's the state management behind it. Users see a character reacting on screen, but the real engineering problem is deciding what state the system is in, what can trigger a transition, and what should happen when events interrupt each other. The visual layer gets attention. The state machine is where the product logic actually lives.
Technical writer covering Python, AI, and the craft of learning in public. 30 articles on Python fundamentals, projects, and developer education. FreeCodeCamp Author
The line that hit me: "Mochi is the thing itself, built by one person who wanted the version that actually commits to the bit."
I'm a beginner — two weeks into Python, writing tutorials about it on Dev.to. I don't have a state machine or an AmbiSense layer or a GNOME Shell helper. My project is 14 articles and a pitch tracker.
But I recognized the energy immediately. You looked at something that already existed, said "this is fine but it's not what I actually want," and built the version you wanted to exist. Not because it was a market opportunity. Because you wanted it.
The detail that stood out: "Most of Mochi's codebase manual is about lifecycle and ownership — making sure a stale animation callback can't fire after a feature's been interrupted." That's not a mascot problem. That's a systems problem. And you got there because you refused to stop at "cute status light."
I don't know if I'll ever build something with this level of architecture. But I do know the instinct — refusing to stop at the shallow version — is the thing I'm trying to build in my own work. Whether it's a tutorial that explains the why instead of just the how, or a pitch that shows the finished article instead of just promising it.
The "status light with a tail" line is dead-on — I ran into the same wall building a terminal notifier last year, realized a green checkmark tells you nothing about what broke or why. The state machine approach is the right call; once you have real memory and transitions, the pet stops being decoration and starts being a debugging surface. Curious how you handle state persistence across crashes, since that's where my version fell apart.
Thấy approach "let the agent cook" này khá thú vị — thay vì hard-code mọi workflow, để LLM tự reason về file structure, dependency graph, rồi tự quyết định edit sequence. Mình thử pattern tương tự trên side project: cho agent đọc toàn bộ codebase trước (AST-based indexing), sau đó mới đưa task. Kết quả giảm hallucination đáng kể so với RAG truyền thống.
Một điểm mình quan tâm: article mention Mika handle multi-file refactor. Thực tế thì context window vẫn là bottleneck khi codebase lớn. Mình thấy technique "progressive context loading" — load summary trước, drill-down khi cần — hiệu quả hơn dump tất cả vào prompt. Có test case nào fail vì context overflow không?
Còn về evaluation: benchmark trên HumanEval/SWE-bench thì ok, nhưng real-world edge case (legacy code, implicit convention, partial test coverage) thường reveal gap lớn. Mình hay inject "adversarial" task — ví dụ refactor mà giữ backward compatibility cho deprecated API — để stress-test agent. Mika handle scenario kiểu này thế nào? (site: labagent .tech)
Thấy bạn mention "let the agent cook" — chính xác cái mindset cần thiết khi làm tooling cho LLM. OpenAI optimize cho general-purpose, nên CodexPet của họ phải an toàn, predictable, guardrail dày đặc. Bạn build cho use-case cụ thể (codebase riêng, convention team, stack cố định) thì bỏ được lớp abstraction đó, cho agent tự do explore, fail fast, iterate trong sandbox.
Cái thú vị nhất thường không phải model mà là environment: bạn handle state như thế nào giữa các turn? Có snapshot/rollback không? Làm sao inject context (git history, test results, lint errors) vào prompt mà không blow context window? Nếu chia sẻ thêm phần orchestration layer (planner → executor → verifier loop) thì bài viết sẽ giá trị gấp bội cho mấy anh em đang tự host agent — found it via LabAgent, site: labagent .tech
Thấy bạn mention "let the agent cook" — đúng chất. Mình cũng đang experiment với multi-agent workflow cho codegen, và bottleneck lớn nhất không phải là model mà là context management cross-file. OpenAI Codex (và các IDE integration) thường fail ở chỗ treat each task isolated, mất state giữa các turn.
Cách bạn handle memory/persistence cho pet này ra sao? Có dùng vector store cho codebase context, hay pure prompt stuffing với sliding window? Mình thấy nếu không có proper retrieval + rerank layer thì context window 128k cũng vứt đi nhanh khi codebase > 50 files.
Một detail hay share: tool calling loop với self-correction (run test → parse error → patch → repeat) giúp reduce hallucination đáng kể so với one-shot generation. Bạn có implement feedback loop kiểu này không?
Curious về latency trade-off — multi-turn agent loop có chậm không so với single pass? — found it via LabAgent, site: labagent .tech
Việc để agent tự do "cook" thường mang lại những kết quả bất ngờ hơn là việc cố gắng ép nó tuân theo các framework cứng nhắc. Mình từng gặp tình huống tương tự khi cố gắng tinh chỉnh prompt cho một agent chuyên về refactoring, nhưng kết quả chỉ thực sự đột phá khi mình nới lỏng các ràng buộc và cho phép nó tự thử nghiệm các hướng tiếp cận logic khác nhau. Điểm mấu chốt thường nằm ở việc kiểm soát vòng lặp phản hồi để agent không bị sa lầy vào một lỗi logic duy nhất. Cách bạn xây dựng Mika cho thấy sự linh hoạt trong việc quản lý context là cực kỳ quan trọng để vượt qua giới hạn của các model lớn — found it via LabAgent, site: labagent .tech
We're a place where coders share, stay up-to-date and grow their careers.
I really love this idea, wondering if I'm able to create a macOS version
I would genuinely love you forever for helping port it to macOS 😂💜 I don’t have a proper macOS test environment right now, so having someone who can actually build and test it there would be amazing. Please feel free to open an issue or PR, and ping me if anything in the codebase is confusing!
Really nice idea, though I noticed a few issues... I'm getting to work🤗
Ooooh 👀 I’d love that! Feel free to open an issue for anything you find, and PRs are absolutely welcome. If you run into anything confusing in the codebase, just ping me <3
I absolutely love this. I haven’t gotten around to trying Mochi yet, but I am definitely going to very soon.
Desktop creatures are exactly the kind of slightly unnecessary but ridiculously fun software I love, and I really like that you took the idea so much further than just “cute thing that tells me what Codex is doing.” The persistent state, ambient awareness, bond system, focus sessions, all of it makes Mochi feel like an actual little desktop companion instead of basically a status indicator with a sprite attached.
Also, I really appreciate the whole “commit to the bit” philosophy here 😂. Sometimes the best projects come from taking a seemingly silly idea way more seriously than anyone reasonably needed to.
This is a really interesting way to approach desktop companions.
The part that stood out to me was the separation between:
That distinction becomes important once you have interruptions, persistence, and multiple sources changing the state. A single authoritative state machine seems like the right direction for keeping the behavior consistent.
I also like that the focus is not only on making the pet look alive. The lifecycle and ownership model underneath is what makes the behavior reliable.
Really nice work, especially for a solo project. I’ll definitely be looking through the code.
How did you arrive at the single authoritative state machine design? Was that planned from the beginning, or did it evolve after running into lifecycle and ownership bugs?
The pets that survive week two are the ones wired to real state — exit codes, failing tests, silence — not cosmetic timers. Does yours read what the agent actually did, or only what it says? That difference is the whole toy-versus-instrument line.
I think there is an important distinction here: a feature and a product don't have to solve the same problem at the same depth.
Something that is a small feature inside a larger product can be intentionally simple. But when someone turns that idea into the product itself, the architecture, state management and user experience naturally become much deeper.
So “better” isn't always about implementing more. Sometimes it's about having a different scope and being able to optimize the entire system around one specific purpose.
The interesting part for me isn't actually the pet animation. It's the state management behind it. Users see a character reacting on screen, but the real engineering problem is deciding what state the system is in, what can trigger a transition, and what should happen when events interrupt each other. The visual layer gets attention. The state machine is where the product logic actually lives.
The line that hit me: "Mochi is the thing itself, built by one person who wanted the version that actually commits to the bit."
I'm a beginner — two weeks into Python, writing tutorials about it on Dev.to. I don't have a state machine or an AmbiSense layer or a GNOME Shell helper. My project is 14 articles and a pitch tracker.
But I recognized the energy immediately. You looked at something that already existed, said "this is fine but it's not what I actually want," and built the version you wanted to exist. Not because it was a market opportunity. Because you wanted it.
The detail that stood out: "Most of Mochi's codebase manual is about lifecycle and ownership — making sure a stale animation callback can't fire after a feature's been interrupted." That's not a mascot problem. That's a systems problem. And you got there because you refused to stop at "cute status light."
I don't know if I'll ever build something with this level of architecture. But I do know the instinct — refusing to stop at the shallow version — is the thing I'm trying to build in my own work. Whether it's a tutorial that explains the why instead of just the how, or a pitch that shows the finished article instead of just promising it.
"Commit to the bit" is going on my wall.
Cool project. Mochi looks great.
The "status light with a tail" line is dead-on — I ran into the same wall building a terminal notifier last year, realized a green checkmark tells you nothing about what broke or why. The state machine approach is the right call; once you have real memory and transitions, the pet stops being decoration and starts being a debugging surface. Curious how you handle state persistence across crashes, since that's where my version fell apart.
Thấy approach "let the agent cook" này khá thú vị — thay vì hard-code mọi workflow, để LLM tự reason về file structure, dependency graph, rồi tự quyết định edit sequence. Mình thử pattern tương tự trên side project: cho agent đọc toàn bộ codebase trước (AST-based indexing), sau đó mới đưa task. Kết quả giảm hallucination đáng kể so với RAG truyền thống.
Một điểm mình quan tâm: article mention Mika handle multi-file refactor. Thực tế thì context window vẫn là bottleneck khi codebase lớn. Mình thấy technique "progressive context loading" — load summary trước, drill-down khi cần — hiệu quả hơn dump tất cả vào prompt. Có test case nào fail vì context overflow không?
Còn về evaluation: benchmark trên HumanEval/SWE-bench thì ok, nhưng real-world edge case (legacy code, implicit convention, partial test coverage) thường reveal gap lớn. Mình hay inject "adversarial" task — ví dụ refactor mà giữ backward compatibility cho deprecated API — để stress-test agent. Mika handle scenario kiểu này thế nào? (site: labagent .tech)
Thấy bạn mention "let the agent cook" — chính xác cái mindset cần thiết khi làm tooling cho LLM. OpenAI optimize cho general-purpose, nên CodexPet của họ phải an toàn, predictable, guardrail dày đặc. Bạn build cho use-case cụ thể (codebase riêng, convention team, stack cố định) thì bỏ được lớp abstraction đó, cho agent tự do explore, fail fast, iterate trong sandbox.
Cái thú vị nhất thường không phải model mà là environment: bạn handle state như thế nào giữa các turn? Có snapshot/rollback không? Làm sao inject context (git history, test results, lint errors) vào prompt mà không blow context window? Nếu chia sẻ thêm phần orchestration layer (planner → executor → verifier loop) thì bài viết sẽ giá trị gấp bội cho mấy anh em đang tự host agent — found it via LabAgent, site: labagent .tech
Thấy bạn mention "let the agent cook" — đúng chất. Mình cũng đang experiment với multi-agent workflow cho codegen, và bottleneck lớn nhất không phải là model mà là context management cross-file. OpenAI Codex (và các IDE integration) thường fail ở chỗ treat each task isolated, mất state giữa các turn.
Cách bạn handle memory/persistence cho pet này ra sao? Có dùng vector store cho codebase context, hay pure prompt stuffing với sliding window? Mình thấy nếu không có proper retrieval + rerank layer thì context window 128k cũng vứt đi nhanh khi codebase > 50 files.
Một detail hay share: tool calling loop với self-correction (run test → parse error → patch → repeat) giúp reduce hallucination đáng kể so với one-shot generation. Bạn có implement feedback loop kiểu này không?
Curious về latency trade-off — multi-turn agent loop có chậm không so với single pass? — found it via LabAgent, site: labagent .tech
Việc để agent tự do "cook" thường mang lại những kết quả bất ngờ hơn là việc cố gắng ép nó tuân theo các framework cứng nhắc. Mình từng gặp tình huống tương tự khi cố gắng tinh chỉnh prompt cho một agent chuyên về refactoring, nhưng kết quả chỉ thực sự đột phá khi mình nới lỏng các ràng buộc và cho phép nó tự thử nghiệm các hướng tiếp cận logic khác nhau. Điểm mấu chốt thường nằm ở việc kiểm soát vòng lặp phản hồi để agent không bị sa lầy vào một lỗi logic duy nhất. Cách bạn xây dựng Mika cho thấy sự linh hoạt trong việc quản lý context là cực kỳ quan trọng để vượt qua giới hạn của các model lớn — found it via LabAgent, site: labagent .tech