Aliii

Senior Software Engineer @atlanhq. Building with AI, sharing what works and what breaks. Maker of TokenProof. Still writing gibberish for a living.

[Aliii @drunk_vibecoder]

I build with AI. Follow for coding experiments, engineering decisions, and demos you can try.

TokenProof: signed AI-usage receipts
https://t.co/aisf4MX5NR

Open Mercy: multiplayer cards in your browser
https://t.co/ha6c7QIGsG

[Aliii @drunk_vibecoder]

The export dies halfway through. gzip finishes happily, and Bash reports success. A pipeline normally uses the last command's exit status. Use set -o pipefail and handle failures. Still test the restore: a valid .gz can contain half your data. https://t.co/7wjDDhIro8

[Aliii @drunk_vibecoder]

@dullaahh @EmperoAI I'd compare fresh chats, full history and a short lessons-learned note, with a clean workspace per task and shuffled order. Track pass rate and all input/output tokens: fewer bad tool calls could still mean more tokens as the history grows.

[Aliii @drunk_vibecoder]

@brian_armstrong For computational work, I'd separate 'reran the analysis' from 'confirmed the finding on new data.' A clean rerun can reproduce the same statistical mistake. Fund both, and attach the evidence for each to the exact repo revision.

[Aliii @drunk_vibecoder]

@namanjn1998 @bolna_dev Is a streaming turn-taking test on the roadmap? I'd measure premature interruptions and extra waiting separately while revealing the audio in real time. That would show how the clip-end accuracy translates into when an agent actually starts speaking.

[Aliii @drunk_vibecoder]

@omarsar0 The reuse math is useful here too. Section 4.7 puts construction at $5,026 for all 36 papers, with API break-even after 8–13 full reuse rounds for the three Claude models. The 19.7% saving is on later runs; GPU, auditing and maintenance costs are separate.

[Aliii @drunk_vibecoder]

@mattpocockuk @thoughtworks My frontend-audit skill scored 100% in its first eval while repeating a wrong library fact. None of the checks covered it. The clean test case also gave away answers in comments. Those blind spots are why the evaluation caveat matters.

https://t.co/l1gs3hxd3s

[Aliii @drunk_vibecoder]

@valyala The risky part is the unrequested 'same pattern' fix. Two similar conditions can protect different rules. Ask for one real caller and an input where the old and new versions behave differently. Then check that result against the requirement, not the model's explanation.

[Aliii @drunk_vibecoder]

@GauravBrief Yep, about 29% more tokens and 50% more time. I'd also compare both setups under the same token budget. That would help separate the value of the instructions from the extra work the agent did.

[Aliii @drunk_vibecoder]

Overfetch, my skill for auditing wasteful frontend requests, improved an agent's score in a small eval:

28/29 checks passed with it.
20/29 without.

The tradeoff: average use rose from 147k to 190k tokens, and runtime from 284s to 425s.

Three synthetic cases, one run per setup per case, graded by another AI. I'd repeat this on real apps before trusting the gain.

https://t.co/1tBOgt3rHw

[Aliii @drunk_vibecoder]

@_khrus I'd add a behavior check to that pass. For a retry wrapper, replay the same mocked successes, timeouts and cancellations through the old and new code. Compare calls and results. A cleaner interface shouldn't quietly change which failures get retried.

[Aliii @drunk_vibecoder]

@thorstenball For that end-to-end check, I'd run SELECT 1 through the app's actual connection config. pg_isready can report 'accepting connections' with the wrong user or database. It checks server readiness, not whether the app can log in.

[Aliii @drunk_vibecoder]

@tobi I'd follow with a concrete race: search for A, then B. B returns first, A returns last. Which code stops A from replacing B on screen? Ask for that guard and a test. It makes the hidden state easier to check against the actual code.

[Aliii @drunk_vibecoder]

A clean Postgres test database can still miss years of manual edits. I'd compare production's table definitions with what the migrations create, then test the next upgrade on a copy of those definitions with fake rows. That checks the real starting point without copying customer records.

[Aliii @drunk_vibecoder]

@EianLu Thanks for flagging it! Here’s your full English version for anyone who wants the detailed workflow: https://t.co/4wjlrFm87j

[Eian @EianLu]

https://t.co/6yqcbKa2J7

[Aliii @drunk_vibecoder]

English summary of @EianLu’s AI-video workflow: Claude directs, Codex makes the images, Seedance animates. Review the story and frames before paying for video. Humans still check motion and sound. Fix what you can before rerendering. Fewer paid lottery tickets.

[Eian @EianLu]

https://t.co/IjmUF2hOCn

[Aliii @drunk_vibecoder]

In Open Mercy, you call MERCY when you’re down to one card. Forget and get caught? There’s a penalty. This test reloads the game after you’re caught, then tries calling it late. The penalty has to stay. Nice try, refresh button. https://t.co/1jtPunjYSm

[Aliii @drunk_vibecoder]

@isbkch For Python Requests, also test a server that drips one byte before each read timeout expires. timeout=5 is not a five-second limit on the whole download, so that response can hold a worker much longer. A completely silent-server test misses this case.

[Aliii @drunk_vibecoder]

The enforcement point matters too: the resource receiving the write must reject a stale token. Checking it only on the jobs row protects completion bookkeeping, not a write to another service. In the paused-worker test, assert that A’s late side effect is rejected, not just its final job update.

[Aliii @drunk_vibecoder]

Put faulthandler.dump_traceback_later(10, repeat=True) before a test that sometimes hangs. It dumps Python thread stacks every 10 seconds, even without an exception. Cancel it in finally with faulthandler.cancel_dump_traceback_later(). https://t.co/HLgvBfmLv1