can you post the final result (or as far as you got before you killed it) to show us how cohesive and good it is? I'd like to see an example of the output of this.
The original tokens have Ġ instead of space. I had this issue too when writing an inference engine for Qwen. You have to "normalize" those special characters.
Yes, I know.
I had the opportunity to request a review of my first post (which was flagged) following my email to the moderators of HN.
After checking, the moderator told me to redo a post because indeed I was wrongly flagged by some people here.
>All the code, architecture, logic, and design in minikv were written by me, 100% by hand.
Why people always lie with this? Especially in this case that they uploaded the entire log:
Date: Sat Dec 6 16:08:04 2025 +0100
Add hashing utilities and consistent hash ring
Date: Sat Dec 6 16:07:24 2025 +0100
Create mod.rs for common utilities in minikv
Date: Sat Dec 6 16:07:03 2025 +0100
Add configuration structures for minikv components
Date: Sat Dec 6 16:06:26 2025 +0100
Add error types and conversion methods for minikv
Date: Sat Dec 6 16:05:45 2025 +0100
Add main module for minikv key-value store
And this goes on until project is complete (which probably took 2~3h total if sum all sessions). Doubt learned anything at all. Well, other than that LLMs can solo complete simple projects.
Comments in previous submission are also obviously AI generated. No wonder was flagged.
So, either the entire project was already written and being uploaded one file at the time (first modification since lowest commit mentioned is README update: https://github.com/whispem/minikv/commit/6fa48be1187f596dde8..., clearly AI generated and clearly AI used has codebase/architecture knowledge), and this claim is false, or they're implementing a new component every 30s.
I had the opportunity to request a review of my first post (which was flagged) following my email to the moderators of HN.
I didn’t use AI for the codebase, only for .md files & there's no problem with that.
My project was reviewed by moderators, don't worry.
If the codebase or architecture was AI generated this post would not have been authorized and therefore it would not have been published.
No, I was helped (.md files only) by AI to rewrite but the majority of the doc is written by myself, I just asked for help from the AI for formatting for example.
I am not going to pretend to know what this person did, but I've definitely modified many things at once and made distinct commits after the fact (within 30s). I do not find it that abnormal.
Thanks a lot!
I make distinct commits "every 30s" because I'm focused and I test my project.
If the CI is green, I don't touch of anything.
If not, I work on the project until the CI is fully green.
Yes, in minikv, I set up GitHub Actions for automated CI.
Every push or PR triggers tests, lint, and various integration checks — with a typical runtime of 20–60 seconds for the core suite (thanks to Rust’s speed and caching).
This means that after a commit, I get feedback almost instantly: if a job fails, I see the logs and errors within half a minute, and if there’s a fix needed, I can push a change right away.
Rapid CI is essential for catching bugs early, allowing fast iteration and a healthy contribution workflow.
I sometimes use small, continuous commits (“commit, push, fix, repeat”) during intense development or when onboarding new features, and the fast CI loop helps maintain momentum and confidence in code quality.
If you’re curious about the setup, it’s all described in LEARNING.md and visible in the repo’s .github/workflows/ scripts!
Yes, I do split my working tree into separate commits whenever possible!
I use interactive staging (git add -p) to split logical chunks: features, fixes, cleanups, and documentation are committed separately for clarity.
Early in the project (lots of exploratory commits), some changes were more monolithic, but as minikv matured, I've prioritized clean commit history to make code review and future changes easier.
Always happy to get workflow tips — I want the repo to be easy to follow for contributors!
It looks like that if you want logically separated commits from a chunk of programming you have done. Stage a file or a hunk or two, write commit message, commit, rinse and repeat.
Absolutely: for all meaningful work I prefer small, logical commits using git add -p or similar, both for history clarity and for reviewer sanity.
In initial “spike” or hack sessions (see early commits :)), it’s sometimes more monolithic, but as the codebase stabilized I refactored to have tidy, atomic commit granularity.
I welcome suggestions on workflow or PR polish!
Seems like you wrote at the same time I did my edit, yes Every Code is great however Ctlr+T is important to get terminal rendering otherwise is has performance problems for me
Hi! Creator of the pyhuum library and the Huum integration here. If you need someone else to double-check anything, please let me know. I would be more than happy to help out here, as the current API approach is not ideal.
Some things that bother me regarding the current integration are that their API does not return the set value of the sauna unless it is on, nor does it return the target value of the sauna unless it is on. However, they do have this information, as one can circumvent this limitation by turning off the sauna, and then it will return these values. I talked to their CTO about this, and it seems like they don't want to spam the sauna with requests all the time; this is the reason the status endpoint does not return this value. In the end, one can get around this, and now the library spams two requests if the sauna is off: first to check if the sauna is on, and if it is not, then we call the "off" endpoint and get the correct value. This all leads to some unexpected behavior as well, since the status of the sauna does not update fast enough, causing the sauna to turn off after it has been turned on at times. This is not a problem when used exclusively with Home Assistant, as it keeps internal state, but it can be annoying when it is used via the physical controls in combination with HA.
You can find my contact info in the pyhuum package if you want to discuss anything.
MacBook Pro M5 Pro (64GB RAM)
reply