Reddit Programming
212 subscribers
1.22K photos
125K links
I will send you newest post from subreddit /r/programming
Download Telegram
Anthropic: AI assisted coding doesn't show efficiency gains and impairs developers abilities.
https://www.reddit.com/r/programming/comments/1qqxvlw/anthropic_ai_assisted_coding_doesnt_show/

<!-- SC_OFF -->You sure have heard it, it has been repeated countless times in the last few weeks, even from some luminaries of the development world: "AI coding makes you 10x more productive and if you don't use it you will be left behind". Sounds ominous right? Well, one of the biggest promoters of AI assisted coding has just put a stop to the hype and FOMO. Anthropic has published a paper that concludes: * There is no significant speed up in development by using AI assisted coding. This is partly because composing prompts and giving context to the LLM takes a lot of time, sometimes comparable as writing the code manually. * AI assisted coding significantly lowers the comprehension of the codebase and impairs developers grow. Developers who rely more on AI perform worst at debugging, conceptual understanding and code reading. This seems to contradict the massive push that has occurred in the last weeks, were people are saying that AI speeds them up massively(some claiming a 100x boost), that there is no downsides to this. Some even claim that they don't read the generated code and that software engineering is dead. Other people advocating this type of AI assisted development says "You just have to review the generated code" but it appears that just reviewing the code gives you at best a "flimsy understanding" of the codebase, which significantly reduces your ability to debug any problem that arises in the future, and stunts your abilities as a developer and problem solver, without delivering significant efficiency gains. <!-- SC_ON --> submitted by /u/Gil_berth (https://www.reddit.com/user/Gil_berth)
[link] (https://arxiv.org/abs/2601.20245) [comments] (https://www.reddit.com/r/programming/comments/1qqxvlw/anthropic_ai_assisted_coding_doesnt_show/)
Schema registries solve runtime problems, not human ones
https://www.reddit.com/r/programming/comments/1qr02ju/schema_registries_solve_runtime_problems_not/

<!-- SC_OFF -->I’ve spent a lot of time working with event-driven systems, and I keep talking to people who are struggling with the same things I’ve struggled with. Schema registries are great at protecting production. They stop breaking changes, enforce contracts, and keep producers from accidentally breaking consumers. From a runtime point of view, they work really well. But they don’t help much when you are trying to understand the system as a human. When someone new joins the team, the questions are always the same: - Why does this event exist?
- Who owns it?
- What business flow does it belong to?
- What is supposed to happen after it is published?
- Is this still used or did it just never get cleaned up? In the past I tried fixing this with Confluence pages, architecture diagrams, and docs in repos. They were fine for general documentation, but they never really helped with this specific problem. They weren’t built for domain-driven design, software primitives, or events as first-class concepts. I could write things down, but it still didn’t help people understand how the system actually worked. So I built an open source tool to try and fix this. It focuses on documenting the human side of events. Ownership, intent, relationships, and flows live alongside schemas. It helped, but the longer I work in this space, the more convinced I am that we are still early in figuring this out... I’m curious to learn more, how other teams handle this? If you’ve felt this pain, what are you doing that actually works? <!-- SC_ON --> submitted by /u/boyneyy123 (https://www.reddit.com/user/boyneyy123)
[link] (https://github.com/event-catalog/eventcatalog) [comments] (https://www.reddit.com/r/programming/comments/1qr02ju/schema_registries_solve_runtime_problems_not/)
The Most Important Code Is The Code No One Owns
https://www.reddit.com/r/programming/comments/1qrpdkb/the_most_important_code_is_the_code_no_one_owns/

<!-- SC_OFF -->A detailed examination of orphaned dependencies, abandoned libraries, and volunteer maintainers, explaining how invisible ownership has become one of the most serious risks in the modern software supply chain. <!-- SC_ON --> submitted by /u/justok25 (https://www.reddit.com/user/justok25)
[link] (https://techyall.com/blog/the-most-important-code-is-the-code-no-one-owns) [comments] (https://www.reddit.com/r/programming/comments/1qrpdkb/the_most_important_code_is_the_code_no_one_owns/)
What breaks when you try to put tables, graphs, and vector search in one embedded engine?
https://www.reddit.com/r/programming/comments/1qsbj66/what_breaks_when_you_try_to_put_tables_graphs_and/

<!-- SC_OFF -->I’ve been working on an embedded database engine that runs in-process and supports multiple data models under one transactional system: relational tables, property graphs, and vector similarity search (HNSW-style). Trying to combine these in a single embedded engine surfaces some interesting programming and systems problems that don’t show up when each piece lives in its own service. A few of the more interesting challenges: 1) Transaction semantics vs ANN indexes
Approximate vector indexes like HNSW don’t naturally fit strict ACID semantics.
Per-transaction updates increase write amplification, rollbacks are awkward, and crash recovery becomes complicated. In practice, you have to decide how “transactional” these structures really are. 2) Storage layout tension
Tables want row or column locality.
Graphs want pointer-heavy adjacency structures.
Vectors want contiguous, cache-aligned numeric blocks. You can unify the abstraction layer, but at the physical level these models fight each other unless you introduce specialization, which erodes the “single engine” ideal. 3) Query planning across models
Cross-model queries sound elegant, but cost models don’t compose cleanly.
Graph traversals plus vector search quickly explode the planner search space, and most optimizers end up rule-based rather than cost-based. 4) Runtime embedding costs
Running a full DB engine inside a language runtime (instead of as a service) shifts problems: - startup time vs long-lived processes - memory ownership and GC interaction - crash behavior and isolation expectations Some problems get easier (latency, deployment); others get harder (debugging, failure isolation). The motivation for exploring this design is to avoid stitching together multiple storage systems for local or embedded workloads, but the complexity doesn’t disappear — it just moves. If you’ve worked on database engines, storage systems, or runtime embedding (JVM, CPython, Rust, etc.), I’d be curious: - where would you intentionally draw boundaries between models? - which parts would you relax consistency on first? - does embedded deployment change how you’d design these internals? For concrete implementation context, this exploration is being done using an embedded configuration of ArcadeDB via language bindings. I’m not benchmarking or claiming this is “the right” approach — mostly interested in the engineering trade-offs. <!-- SC_ON --> submitted by /u/Plastic_Director_480 (https://www.reddit.com/user/Plastic_Director_480)
[link] (https://github.com/humemai/arcadedb-embedded-python) [comments] (https://www.reddit.com/r/programming/comments/1qsbj66/what_breaks_when_you_try_to_put_tables_graphs_and/)
The Hardest Bugs Exist Only In Organizational Charts
https://www.reddit.com/r/programming/comments/1qscpr5/the_hardest_bugs_exist_only_in_organizational/

<!-- SC_OFF -->The Hardest Bugs Exist Only in Organizational Charts. Some of the most damaging failures in software systems are not technical bugs but organizational ones, rooted in team structure, ownership gaps, incentives, and communication breakdowns that quietly shape how code behaves. https://techyall.com/blog/the-hardest-bugs-exist-only-in-organizational-charts <!-- SC_ON --> submitted by /u/justok25 (https://www.reddit.com/user/justok25)
[link] (https://techyall.com/blog/the-hardest-bugs-exist-only-in-organizational-charts) [comments] (https://www.reddit.com/r/programming/comments/1qscpr5/the_hardest_bugs_exist_only_in_organizational/)
C3 Programming Language 0.7.9 - migrating away from generic modules
https://www.reddit.com/r/programming/comments/1qsexe1/c3_programming_language_079_migrating_away_from/

<!-- SC_OFF -->C3 is a C alternative for people who like C, see https://c3-lang.org (https://c3-lang.org/). In this release, C3 generics had a refresh. Previously based on the concept of generic modules (somewhat similar to ML generic modules), 0.7.9 presents a superset of that functionality which decouples generics from the module, which still retaining the benefits of being able to specify generic constraints in a single location. Other than this, the release has the usual fixes and improvements to the standard library. This is expected to be one of the last releases in the 0.7.x iteration, with 0.8.0 planned for April (current schedule is one 0.1 release per year, with 1.0 planned for 2028). While 0.8.0 and 0.9.0 all allows for breaking changes, the language is complete as is, and current work is largely about polishing syntax and semantics, as well as filling gaps in the standard library. <!-- SC_ON --> submitted by /u/Nuoji (https://www.reddit.com/user/Nuoji)
[link] (https://c3-lang.org/blog/c3-0-7-9-new-generics-and-new-optional-syntax/) [comments] (https://www.reddit.com/r/programming/comments/1qsexe1/c3_programming_language_079_migrating_away_from/)