521–530 of 532 posts
Earlier quoted context omitted.
Where are you living that your rent is $400?
Living in Paris, but I exaggerated rent is actually 600€ and it's like the best opportunity one can have. Still, even if I lived in a regular flat with 1000 euros rent, I don't see how 20% additional "rent" money is worth it for side fun projects
Earlier quoted context omitted.
What is untrue about this statement you quoted?
You can have software behave differently while passing the same tests. Idk man, this is pretty easy to demonstrate. Start with a trivial example: test is that input (2,2) -> 4. Function 1 does multiplication, function 2 does exponentiation. Both functions pass the test. Sure, simple example but illustrative examples should be simple. But add more complexity and I'll add more examples of functions where the outputs ar…
> Tests only pass if both implementations of your software behave the same way in the exact area being tested.
As I said in my comment above. Tests are a crappy second implementation. The test in your example isn’t even defined outside the input range of (2,2). Tests are a stochastic tool. Tests can prove the presence of a bug, not their absence. Completeness isn’t something tests alone can provide. But in the choice between yolo coding and yolo coding plus tests, you’re obviously going to get fewer bugs with tests.
The idea is to measure how much of the invariant string or byte structure a new version still covers.
In the context of agents that churn out code overnight, the review fatigue impacting human agents. One way to prioritize review effort is to treat the codebase's own history as a "corpus" and flag commits that deviate structurally from past patterns—like an injection test for code. If an agent adds 20k lines that are mostly boilerplate, the coverage of established code patterns might drop, signalling something worth a closer look. It's not a substitute for tests or semantic verification, but a cheap way to surface outliers.
We tested this on Alpine apk-tools across nine releases: the 3.23 rewrite dropped from 71‑80% string coverage to 40%, and from 23‑28% byte n‑gram coverage to 13.6%—detected automatically just from size distribution. Applied to code, you could imagine a dashboard where every PR gets a "historical coverage" score; when it drops, the human knows to zoom in.
It complements existing verification: a signature tells you who signed, not whether the artifact is consistent with its own version history. Same for AI‑generated PRs: tests may pass, but if the code looks nothing like what came before, that’s a useful signal.
Details here if anyone's curious: https://lf3.gitlab.io/blog/binary-string-mask/
Earlier quoted context omitted.
> I’m sticking with humans for the moment Haha totally get this statement. The HitL fine-tuning angle is exactly right. The labeled dataset you're building (good/bad/stylistically-wrong memory events) is probably worth more than the compaction itself. Coherence preferences are surprisingly personal — what reads as "not correct based on my style" is hard to spec without examples. The loop-pruning maps really cleanly t…
Semi-retroactively: my agent has a command to /compact and its then that I pop the interface. It gets opened automatically if the context is full, too, and then I've gone back and fed some recorded sessions into it as well days later too, to test things out. Still getting the hang of it, but I won't be surprised to see much bigger teams/companies do something similar (I assume they are already, really)
The retroactive feeding of recorded sessions is underrated. That's basically supervised compaction - you're labeling what mattered in hindsight, which is almost always cleaner signal than in-flight decisions.
I suspect the labs are doing something like this at scale but the hard part is that "what mattered" is user-specific. A generic compaction model trained on aggregate data probably smooths over the individual coherence preferences that make it actually useful.
We ended up open-sourcing the memory layer as an MCP server (engram-mcp) if youre interested at how we handled the certainty/recall side.
Interested in what your session recordings look like structurally or are they raw transcripts or do you extract structure before feeding them in?
Earlier quoted context omitted.
It's always the uber conservative and over principled people who laugh about using PHP that have an opinion on everything while not knowing how to get shit done. They're all just tools. You decide how to use them.
Sure but we can agree there's essentially two parallel industries in web development Engineer at tech firms and WebShops writing WordPress plugins for single clients where Squarespace doesn't cut it. Is AI another field of people or is it killing one or both of those. TBD
Earlier quoted context omitted.
Hmm, not so sure TDD is a failed paradigm. Maybe it isn't a pancea, but it is seems like it's changed how software development is done. Especially for backend software and also for tools, seems like automated tests can cover quite a lot of use cases a system encounters. Their coverage can become so good that they'll allow you to make major changes to the system, and as long as they pass the automated tests, you can f…
> But maybe you're separating automated testing and TDD as two separate concepts? I hope it's clear that I am given my content and how I stress I write tests. The existence of tests do not make development TDD. The first D in TDD stands for "driven". While my sibling comment explains the traditional paradigm it can also be seen in an iterative sense. Like just developing a new feature or even a bug. You start with de…
And just looked up TDD on wikipedia. Actually, the standard process is not to write all the tests first, then do the implementation. It's to do what a lot of devs already do, write some tests based on your requirements. Then, write the implementation for these tests. Then repeat, adding in more test for other paths through the system.
Didn't know this myself about TDD (I thought it was focus writing all the tests, then do the implementation). Yeah, TDD is actually a very practical approach and something I pretty much do in my own development. Instead of using a driver program to run your working code, just write unit tests to run it. And keep building your unit tests for every new feature or execution path you're working on. You'll miss a lot of them early on, but you fill out the rest at the end.
Now that I know, in my opinion, TDD was pretty amazing and changed our industry.
They crash. The interesting question isn't how to prevent that — it's how to make it not matter.
The gnarliest failure I hit: my agents share a knowledge graph through an MCP memory server. When multiple agents fire parallel tool calls (say, create_entities and create_relations in the same batch), you get a classic read-modify-write race. Both operations read the same JSONL state, both write back the full graph plus their additions. Second write obliterates the first. No error, no warning — data just vanishes. Sometimes the write gets interrupted mid-line and you end up with a half-written JSON line that breaks the parser on next load.
My fix was a local fork of the memory server with three things: an async mutex to serialize writes, atomic writes (write to .tmp then rename), and auto-repair on load that skips corrupt lines and deduplicates. But the meta-point is that on the BEAM, this entire class of bug doesn't exist. A GenServer processes messages sequentially from its mailbox — mutual exclusion is the execution model, not something you bolt on with a mutex. Supervision trees restart crashed processes in microseconds. Each process has its own heap, so one agent going haywire can't corrupt another's state.
Erlang/OTP solved this in 1986 for telecom switches that needed 99.999% uptime. The pattern maps almost perfectly to AI agents: many concurrent, stateful, failure-prone processes that need to communicate without taking each other down.
I wrote a detailed post about this with actual code and the full corruption story: https://dev.to/setas/why-erlangs-supervision-trees-are-the-m...
The hardest bug I hit was a shared JSONL memory store: two agents wrote at once, one update silently overwrote the other, and sometimes the file ended up partially corrupted. I fixed it with a mutex and atomic writes, but that mostly taught me I was working against my runtime.
The reason I keep ending up back at Erlang/OTP is that supervision and isolated processes are the default model, not a patch. If agents are going to run while you sleep, restart behavior matters more than clever prompts.