Be careful when transposing game-learned behaviors into real life.
HN user
syntex
yes I always thought it's an easy thing. but I changed my mind recently when I had to deal with it.
A lot little things you need to think of. For example.
Client sends a request. The database is temporarily down. The server catches the exception and records the key status as FAILED. The client retries the request (as they should for a 500 error). The server sees the key exists with status FAILED and returns the error again-forever. Effectively "burned" the key on a transient error.
others like:
- you may have Namespace Collisions for users... (data leaks) - when not using transactions only redis locking you have different set of problem - the client needs to be implmented correctly. Like client sees timout and generates a new key, and exactly once processing is broken - you may have race conditions with resource deletes - using UUID vs keys build from object attributes (different set of issues)
I mean the list can get very long with little details..
You've some wrong assumption. One is that you are wrong about Poland / Greece wages. In 2026 Polish worker actually earns more than a Greece worker for the same role. Something like 25% more in Poland
Also Polands power grid is quite old and hasn't kept pace with demand. The grid operator last year had to reject thousands of requests for new connections
Thanks! I wasn't aware of Jido or ReqLLM before. ReqLLM looks especially promising, and I will likely use it. At the moment, I'm only integrated with OpenRouter.
Its semi public, but I probably publish it soon once its less embarrassing.
Its an Elixir agent runtime with a thin Go TUI (bubble-tea). Im building it mostly to explore agent orchestration: planner/workers/finalizer flows, local file/code-edit tools, MCP tools, permission gates, run context, compaction, and eventually larger swarms. Erlang/Elixir is interesting for this because the actor/supervision model maps pretty naturally to lots of isolated agents and long-running supervised tasks.
As i said, The main lesson so far is that everything around contracts is much more fragile than I expected unless you use a very strong model. Planners return Markdown instead of JSON, tools get called with subtly wrong args, subagents repeat broken tool calls, finalizers lie about success after workers failed. And various permissions may be interpreted by agents in unexpexted way
I also started with too many modes too early instead of making agentic path extremely solid. That made me understand better why these codebases become huge: there are endless corner cases if you want a harness to work across models, providers, tools...
Stronger models hide a lot of harness weakness and weaker models expose. Making weaker models good enough requires a surprising amount of contract hardening. But that hardening tends to make the system better for stronger models too.
Also elixir http stack was causing a lot of problems (needed to use gun eventually)
Not sure you can replace Claude with DeepSeek V4 that easily and have same results.
From what I see while building my own agentic system in Elixir, the problem is in training for your specific harness/contracts. Claude/GPT-style models seem to be trained around very specific contracts used by the harness like tool call formats, planning structure, patching, reading files, recovering from errors, and knowing when to stop.
In practice, you either need a very strong general model that can infer and follow those contracts (expensive), or a weaker model that has been fine-tuned / trained specifically on your own agent contracts. Otherwise, the whole thing becomes flaky very quickly. And I suspect with Deepseek V4 you may get last options.
These benchmarks means very little. The real test is model + harness so agentic system that can fulfill given goals.
hallucinates in pretty much every answer
Yes, I did it as a joke inspired by the PRISM release. But unexpectedly, it makes a good point. And the funny part for was that the paper lists only LLMs as authors.
Also, in a world where AI output is abundant, we humans become the scarce resource the "tools" in the system that provide some connectivity to reality (grounding) for LLM
The Post-LLM World: Fighting Digital Garbage https://archive.org/details/paper_20260127/mode/2up
Mini paper: that future isn’t the AI replacing humans. its about humans drowning in cheap artifacts. New unit of measurement proposed: verification debt. Also introduces: Recursive Garbage → model collapse
a little joke on Prism)
I see that author decorating webiste for Christmas :)
I didn't downvote. T the problem with the paper is that it asks the model to output all moves for, say, 15 disks 2 ^ 15 - 1 = 32767
32767 moves in a single prompt. That's not testing reasoning. That’s testing whether the model can emit a huge structured output without error, under a context window limit.
The authors then treat failure to reproduce this entire sequence as evidence that the model can't reason. But that’s like saying a calculator is broken because its printer jammed halfway through printing all prime numbers under 10000.
For me o3 returning Python code isn’t a failure. It’s a smart shortcut. The failure is in the benchmark design. This benchmark just smells.
The illussion of reasoning was terrible paper. 2^n-1 how it could fit in context size. I tried o3 and he gave me python script saying that inserting all moves is to much for context window. completely different results.
The same for me. I only knew how to assign variables, use for loops, if->then, and use poke command. And from this specific point I started thinking about myself as programmer event that the only thing I wrote with C64 basic was a ball moving on the screen. :)
I think there were alignment programs for the Datasette. It played a constant tone or signal that would show whether the head was properly aligned. I think it was on on cartridge that I didn't have. And actually as a young kid I didn't know about this alignment thing. Learned years later after switching to Amiga 500.
I bought my C64 very late - around 1991/1992. It was in Poland where I bought a used one from my friend. Back then, Eastern Europe was a decade behind the Western side of Europe. Two years later, I purchased a used disk drive. So, for two years, I could only run cartridges like Boulder Dash (I managed to synchronize the tape drive properly only once and played "Winter Games"). But from that boredom, I started programming in BASIC, always dreaming about creating the perfect text based game ;p
cheaper hardware usually means more adoption of the software and then even more demand for hardware
I wonder why Poland is still buying F35 and other European countries.
What i can do with that?
just 2piR and then extra h change the result very little fraction. How is that counter-intuitive :)
Why does this have so many upvotes? Is this the current state of research nowadays?
You can play this game here free80sarcade.com/atari2600_VideoChess.php
Personally, I find the cost a bit steep. Truth be told, I don't frequently tinker with CSS, maybe only a couple of times annually. A lifetime license for $39.99, however, would definitely be a deal I'd gladly snap up, no more, no less.
And also it said:
With further development, SynthLingo could be used to create more natural and intuitive interfaces between humans and computers, especially in scenarios where context-driven vocabulary and emotion encoding might improve user experiences.
This is the basics of quantum physics :)
"Quantumix (C1:physics;C2:planck scale) emote-neutral. Subatomix (C1:particles;C2:quantum states;C3:fields) emote-explanation. WaveParticlix (C1:de Broglie;C2:wavelength;C3:momentum) emote-complex.
Schrodingerix (C1:wave equation;C2:probability density) emote-mathematical. Uncertainix (C1:Heisenberg;C2:position;C3:momentum;C4:energy;C5:time) emote-uncertainty. Superposix (C1:multiple states;C2:collapse;C3:observation;C4:cat thought experiment) emote-intriguing.
Entanglix (C1:correlation;C2:distance;C3:spooky action;C4:EPR paradox) emote-fascination. Quantumix (C1:applications;C2:computing;C3:cryptography;C4:teleportation;C5:quantum sensors) emote-potential."
I found this quite funny and interesting how chat gpt4 stripped out the language to essentials.
gpt4 seems to know the answer
Now, to address the question of how we've reached a point where software dependencies often seem unstable or difficult to manage, I believe there are several factors contributing to this situation:
Rapid pace of technology and innovation: The web and software development landscape has evolved rapidly over the years, with new tools, frameworks, and libraries being introduced constantly. This rapid pace of innovation sometimes leads to a lack of focus on long-term stability, as developers may prioritize adding new features or keeping up with trends over ensuring backward compatibility.
Increased complexity: The web has become increasingly complex, with new technologies and standards being introduced regularly. This has led to a more complex ecosystem of dependencies and interdependencies between packages, making it harder for developers to maintain and update them.
Fragmentation of the ecosystem: The JavaScript ecosystem, in particular, is highly fragmented, with many different libraries and frameworks available for similar tasks. This fragmentation can make it difficult for developers to select the most stable or well-maintained option, and it can also contribute to the "cascading effect" you mentioned when updating one package leads to the need to update many others.
Shorter project lifecycles: In the fast-paced world of software development, projects often have shorter lifecycles than in the past. This can lead to less emphasis on long-term stability and more focus on delivering features quickly, even if that means introducing breaking changes more frequently.
Open source community dynamics: Open source projects are often maintained by volunteers who may not have the time or resources to ensure long-term stability. Maintainers may also change over time, leading to different priorities or approaches to stability within the project.
Hey, I think that there is significant potential in developing small and specialized networks that can tackle specific tasks with higher accuracy. It could be also especially valuable for real-time or low-power applications. Additionally, there may be a market for selling well-trained assistants that are tailored to specific prompts or domains.
So you making only 1700 euros a month? Sorry I think you are getting ripped off, as a programmer in Poland/Warsaw you would make around 5k+ euros per month. Change you work you are worth much more.
edit: This is funny just after i wrote this I've seen so many references to Poland in this thread. But yeah it's interesting as working in UK as developer in small company I was earning 2500 pounds after taxes (Liverpool). And I thought that it's a dream job back then. But it was 10 years ago. And I think I am rather average developer just on level III on 6 level scale. So right now living in Poland my wage expectation is around 6k euro as Backend Java developer.
The power usage is a serious issue, I recently scrapped an old PC. It was perfectly fine and usable, but I found it draws with graphics card more than 200W. And taking into account how much electricity rose in Europe it's super expensive to run. And the new one it's 15 times less. So let's take care at least a bit about the environment.