Has anyone tried in organization to use self hosted llm models for agentic programming?

Im curious if it makes any sense. My organization spends fortune on tokens from us companies. I want to recommend something…

Nell’articolo precedente abbiamo visto come si possono mettere le note a piè di pagina in una pagina web. Ora vediamo, invece, come possiamo inserire un separatore.

Apriamo l’editor OneCompiler e dopo aver cancellato tutto, digitiamo: L’HTML è un linguaggio di markup che serve a creare ed abbellire una pagina web

Topics Covered:

Ratty 3D Terminal https://ratty-term.org/
TheyLive Adblocker https://github.com/davmlaw/they_live_adblocker
TerminalPhone https://gitlab.com/here_forawhile/terminalphone
Cuda Oxide https://nvlabs.github.io/cuda-oxide/index.html
Wario Synth https://www.wario.style/
Jmail & EpstienExposed https://epsteinexposed.com/
Wikipedia Doomscroller https://xikipedia.org/
Puter https://github.com/HeyPuter/puter
Honker https://github.com/russellromney/honker

Voiden is an offline-first, git-native API tool built on Markdown.

Instead of keeping API requests inside a cloud workspace, Voiden stores them as .void files that can live with your codebase, be versioned in Git, reviewed in PRs, and reused across a team.

We have now released the beta of @voiden/runner, a headless CLI for running those .void files outside the desktop app.

The runner executes the request, prints the result, and exits with a standard exit code that CI systems can use.

Important bits:

• runs on Node.js 18+
• works in terminal, CI/CD, Docker, and cron jobs
• supports REST, WebSocket, gRPC, and GraphQL
• supports JSON and CSV output
• supports request chaining through runtime variables
• works with core Voiden plugins like scripting, assertions, faker, - - advanced auth, and GraphQL

This is still beta, so APIs and flags may change.

The goal is to make .void files executable API workflows, not just files used inside the desktop app.

Github: https://github.com/VoidenHQ/voiden

Voiden CLI Runner : https://github.com/VoidenHQ/voiden/tree/beta/packages/voiden-runner

Visit Voiden here : https://voiden.md/

One of the tenets from a software-craft site I've been building. The idea is to keep state and dependencies as local as you can, and only promote something to a wider scope (module, shared, then global) once it's actually used widely enough to earn it. Most of the 'shared' code I've had to untangle started local and got hoisted up a tier too early.

Running Code in a Programming Language Nobody Knows

Last month, I ran code in a programming language that nobody knew.

I'm not the first to do a thing like that. Ben Olmstead created Malbolge in 1998. It's a deliberately incomprehensible programming language that's likely impossible for anyone to really know; it took a search algorithm to generate the first program for it. Finding examples of an old, obscure language with no surviving practitioners is another potential method I imagine has been done a few times.

Nobody had ever known Nucleus when its compiler bootstrapped. Since it's 2026, I imagine many readers have already guessed large language models were involved. I gave a sample program and output to an LLM tool and told it to write a compiler in C. I then told the tool to add features to the language until it could rewrite the Nucleus compiler in Nucleus, resulting in a language that I did not know. LLMs do not "know" things and aren't somebody, so at that point, nobody knew Nucleus, yet there were about 4000 lines of it running in the compiler, able to produce real binaries that run on real computers.

Someone I mentioned this to asked why I would want to design a programming language without designing a programming language. I don't actually want to do that, but just as the compiler needed an initial implementation in another language in order to bootstrap, I found it much easier to work from a minimal working language than a blank slate. I had the idea for Nucleus for a long time and have not yet read the Dragon Book and written a compiler from scratch like I told myself I was going to.

As for the language itself, the basic idea is a language for manipulating memory at a low level like C, but with Lisp-like syntax and structural macros providing compile-time abstractions and safety-enhancing constructs with no runtime overhead. By the time it hits 1.0, Nucleus should be usable as a drop-in replacement for C anywhere C is used. I'm not the first to do a thing like that either, but other implementations I've seen actually compile a Lisp-like language to C. Nucleus targets LLVM directly.

@programming

@programming@programming.dev

#lisp #LanguageDesign #compilers

I proposed this project to improve on Radicle's p2p model by using Tor for universal, straightforward seeding of git repos.

Original discussion thread - https://bounties.monero.social/posts/207/

One of the project's git repos linked in that thread - https://radicle.network/nodes/iris.radicle.network/rad:z2ydYmUCJvDfNFTVTpEbQmm55EPt1/history

Project website - https://cradicle.xyz/

The dev who took the project also expanded it into a project to reimplement Radicle in C.

Since I'm not a coder and I don't have any git repos of my own, I can only test from the viewpoint of an average layman using the GUI app to seed repos.

It's impossible for me to properly gauge how the project is progressing without engagement from coders who try using it for their git repos.

If the project doesn't currently interest you, your suggestions on how to start getting users on board would also be welcome.

Edit - bear in mind that because decentralized discussion platforms like this are currently quite broken, there are comments showing up in the thread when I'm not signed in that don't show up for me when I'm signed in. Here's a screenshot of all the comments showing up for me right now where I'm signed in and able to reply, as of UNIX time 1779670288

I'd encourage discussion of this project moreso on nostr (equally broken but my preferred platform) or the discussion thread linked above (seemingly more functional)

A lot of work in this release was related to porting to other platforms. We did a large number of refactorings to put ELF-specific behaviour behind traits. We've also started work on porting to Mach-O and WebAssembly. These aren't yet ready for use, but if you'd like to help out with porting, get in touch.

Wild now supports the linker plugin API that was originally part of the Gold linker, but which is also supported by GNU ld and Mold. This lets us do linker-plugin LTO (link time optimisation). There are still a few known issues, but it's already working on a good range of programs. Pure Rust projects generally don't use linker plugins, since Rust can do LTO within the compiler, so this is mostly helpful for C, C++ or mixed language projects. Note that when using a linker plugin, link times will be very slow.

Lots more linker-script features were implemented during this release.

[...]

TL;DR

• Pull requests were designed for open source contributions from untrusted strangers. Applying them to trusted teams is a category error.
• Peer-reviewed research shows code review’s primary value is knowledge transfer, not bug detection. Less than 15% of review comments relate to actual bugs.
• Async PR workflows mean your code spends 86-99% of its lead time waiting. One organisation spent 130,000 hours in a single year waiting on PRs that received zero comments.
• DORA research across 36,000+ professionals shows trunk-based development correlates with dramatically higher software delivery performance, and faster code reviews alone improve performance by 50%.
• The alternative is T*D: Test-Driven Development (build quality in), Trunk-Based Development (integrate continuously), and Team-focused Development (review during creation, not after).
• The transition is gradual: optimise PRs first, adopt Ship/Show/Ask, then move to pairing and trunk-based development as trust and automation mature.-

In April 2000, Stack Overflow founder Joel Spolsky published an essay titled “Things You Should Never Do, Part I”. The occasion was Netscape's decision to rewrite the code of its then-browser from scratch instead of further developing the existing disciplin

Spolsky's thesis: This decision was the worst strategic mistake a software company could make. It was based on a fundamental misunderstanding of what programming work actually is. Programmers prefer to rewrite because reading foreign code is tedious and writing feels productive. But this impression is deceptive. The temptation to start over is one of the most expensive temptations in the industry.

More than 25 years later, this text has lost none of its relevance. On the contrary. With the advent of Large Language Models (LLM), the asymmetry between writing and reading has shifted to such an extent that the question becomes acute whether we are systematically underestimating the true senior discipline of software development. Typing is not what will keep teams breathless in the coming years. Reading is. In this article, I want to show why this is the case, where the asymmetry comes from, how it is exacerbated by generative AI, and how a casual accompanying skill must become an independent discipline.