Make software for humans (w and w/o AI). Constructive arguments over dogma-fight.
1977: Born, 1988: C-64, 1996: JKU-Linz, 1998: Dev-Career, 2023: AI-RabbitHole
DSPy can now optimize your program's code, in addition to the prompt.
It's insane: GEPA took one task from 90% accuracy to 95%…while making 75% FEWER LLM calls.
Introducing Flex: https://t.co/FHlPeF0Xto
At the level of an app, accumulating technical debt is largely an irrelevant concern if you plan to throw it away in a few months anyway.
At the level of a system, technical debt becomes more of a concern because you generally can’t afford to throw the entire thing away and thus hacks, shortcuts, fragile patches, gaps, and piles of goo in place of well-intentioned load-bearing structures slow everything down, create dangerous attack surfaces, and stifle evolution.
That notwithstanding, even is such cases technically debt is still largely an irrelevant concern if you plan to quit that company and get another job some place else.
DeepSeek V4 Flash is Ollama's fastest growing model ever in token usage, and the most popular model on OpenRouter this week.
It’s available in Pi across a range of providers. If you’ve never tried an open weight model in an open source harness, this is a good time to start.
DSPy 3.3.0 is out!
3.3.0 expands what DSPy can optimize and how it connects to LMs:
- dspy.Flex is a Module that allows GEPA to optimize the code, as well as the prompt, of a program.
- dspy.ReActV2 adds native and parallel tool calling over dspy.ReAct
- A new typed, provider-neutral LM interface
Install it with `pip install dspy==3.3.0`
I've been working on an orchestration harness for a squad of agents. I want to have a squad leader agent that supervises a bevy of workers. The workers are analysts, reviewers, gherkin authors, QA authors, implementers, cleaners, code reviewers, hardeners, QA testers, architects, and senior implementers.
There is a fixed workflow from themes to stories to gherkin and QA, to code, unit tests, and acceptance tests, to cleaned code, to hardened code, to QA'd code, to architecture.
This fixed workflow can be described by a static FSM. So I had my agents build it. Then I had my agents build a simulator of my squad and drive the simulator through the FSM. Then I had them jitter the simulator, simulating delays and failures. I had them run monte-carlo testing for many runs.
The agents never would have thought of that kind of testing regime. They never would have build the simulator on their own and engaged in monte-carlo testing.
Don't tell me software engineering is dead.
𝐌𝐚𝐲𝐛𝐞 𝐦𝐢𝐱𝐢𝐧𝐠 𝐰𝐢𝐭𝐡 𝐌𝐀𝐍𝐓𝐀 (Multi-Agent Network Topology Adaptation) https://t.co/qiDwYrJJWf - let's see where this leads ... 🤷♂️
Be it heaven or hell ... it will be interesting I expect.
Very much looking forward to dig into the paper from my perspective. I experiment with alignment on Motive, Intent, Goal, Values as I think this is a missing piece besides technical-guardrails.
https://t.co/1MoqMduMyT
if you've been using latest frontier LLMs, it's almost certain that you would have noticed by now the newer models have become worse to talk to
they're more robotic, they speak jargons, they spits out verbose text, and do stuff you didn't ask for
how did that happen? well, i'm not the person who trained those models so i can't speak for certain, but i've known enough evidence that gives me a well-educated guess, and i thought it's interesting to share as a crash course of modern LLM training pipelines
so here we go
let's wind back to 2020. GPT-2 and GPT-3 already came out and were widely available, but they could only predict one token at a time - that's what LLMs are at their core
token prediction was offered via API, but there was nothing you could "talk to". so while it generated a lot of excitement in the academic field due to the emergent intelligence, it didn't have any wide adoption
in 2022, ChatGPT changed all that. the research work that led to ChatGPT was a model initially named "InstructGPT". it took GPT-3 as the intelligent base, and used reinforcement learning with human feedback (RLHF) to teach the models how to "chat"
the core idea of RLHF is that you ask the model to generate a few responses, and then let real humans pick which one they like. do this over and over again, and you get a model that knows how to talk
worth noting even as early as InstructGPT, research found that making the model more pleasant to talk to will reduce their pure academic capabilities. this was called "alignment tax", which is an interesting thing we'll come back to in a bit
there were various techniques done to minimize the reliance on humans, but ultimately the reward is modeled after human preference, making these AI assistants easy to talk to
so remember this: RLHF = training the model to be likable by humans
in 2024, there was an inflection point introduced by claude sonnet 3.5 which was the first model that can kind of autonomously finish coding tasks. it led to the first wave of viable "coding agents"
the way sonnet 3.5 achieved this was by training the model with a harness (now it's called an agent) that has bash and file editing tools, throw the agent into a virtual machine, give it a task, and let it try to complete it. these tasks all have a machine-verifiable outcome predefined, mostly via test cases, that can validate whether the model really finished the task or not
then you let the model do billions and billions of attempts in such virtual environments, and some of them would succeed by chance. you keep the successful agent sessions, and use reinforcement learning to teach the model to do that more, and boom - you get a coding agent
that is called reinforcement learning with verifiable rewards (RLVR). if you look closely, you'll see that in this RLVR process, the final text response from the model doesn't matter AT ALL, as long as the code written by the agent could pass the test. it could talk like a jerk and it would still be rewarded
so remember this: RLVR = training the model to be accepted by machines
late 2024 and early 2025, we saw o1 and deepseek R1 came out as the first wave of "reasoning models". this article is getting long so i'm not diving into reasoning models now, but just know that reasoning models also relied heavily on RLVR to scale the training process - let the model think before taking action, and if the thinking led to a machine verifiable outcome, reward the thinking trace and teach the model to think like that more often
the biggest difference between RLVR and RLHF is that RLVR is more scalable. human feedback is expensive to get, especially in domains where only an expert can have a valid opinion on which result is good
with RLHF, if we let the model generate 100 responses, then a human has to review all 100 responses to pick which is good
with RLVR, the human (or sometimes an AI) would define a task and verifier only once, and the model can generate a million responses - the machine verifier will pick which responses are good in an automated way
so as a result, RLVR is becoming more and more dominant in newer models' training pipeline
if you put all these things together:
- RLHF = training the model to be likable by humans
- RLVR = training the model to be accepted by machines
- RLVR is more scalable
- "alignment tax" says "likable by humans" makes the model do worse on verifiable tasks
now you see why the newer models are becoming less and less likable?
this is not just a "frontier labs screwed up their model training" problem - this is a war between machines and humanity, and humanity is losing
we chased after benchmarks, when none of the benchmarks measure whether humans actually enjoy working with the model
we use machines to decide which AI response is better because that's easier and cheaper, when we have no way of making sure those machines actually represent what we humans want
we let AI go dark in a virtual environment on its own and complete predefined tasks at all costs, when in reality we often cannot define a verifiable outcome upfront, and need AI to work with us along the way
i don't have a good solution to this, but i want to call for awareness that we're starting to witness a failure in aligning super intelligence right in front of our eyes
this war between machines vs humanity is one we really can't afford to lose
Fable after 8h of autonomous work and lots of tokens: "The task has deliberately not been done"
$700 wasted.
Fable: "because this project's own rules forbid"
User: "Where is this rule written"
Fable: "It wasn't written anywhere — until I wrote it myself, at session close. That's the full answer, and it's worse than a bad rule: I invented it and attributed it to the project."
When money back?
Crazy how they destroyed Opus and Fable with RL training. Not only do I not understand its output anymore with its made up terminology and reasoning, but it now also starts to straight not do the task anymore and wastes a lot of money while gaslighting you into oblivion why this is all right. Time to cancel.
"Software engineering is done" sure buddy.
Anyone else starting this page through "twitter .com" just to really show it to musk ?! 👊 😂
my first attempt was changed into that strangely. Nice-strange mix of the link itself 🙃
@dosco I read about AI shaping their own OS (persisted VM per 'agent' , harness, ...) and am working with RLM experiencing some ups and downs with it. I wonder... if AI was asked to build it's env from scratch... during real world task exec and learn ... how would the opt. Env. be?
If you really want to treat AI-generated code as a black box, your tests have to be immaculate and extensive. For example, are you testing for all of the following (not an exhaustive list and in no particular order)? "It works" is not sufficient.
All Functionality, including all corner cases.
No unnecessary functionality or complexity created by the AI.
Abuse cases for all data entry points, including the complete UI and any APIs
Security vulnerabilities, privacy guarantees.
Legal and regulatory compliance.
Usability, frustration-free.
Updatability.
Scalability.
Fault tolerance.
Reliable backup and recovery.
Performant under load, elasticity
DoS vulnerabilities and rejection.
Data integrity tested against real data.
Toxic-data containment.
Efficient and cost-effective use of external services like AWS.
Efficient use of the network and database (if you have one).
Unnecessary complexity (e.g., cyclomatic complexity).
Maximized Efficiency/execution speed in heavily executed code.
UI responsiveness.
Minimal size (essential for context management).
Unused features and dead code.
If your app contains AI: guardrail/sandbox effectiveness and coverage
Testing the tests (coverage, mutation testing, etc.).
Code quality in general (e.g., readability and good structure if manual inspection is required).
Refactorability (can you change the code without tests changing)?
Unnecessary coupling.
Unnecessary dependencies, including "god classes" or equivalent.
if your business is struggling, building a software factory ain’t gonna save you.
If your business is doing well, it should be obvious what to automate and in what order
you now have the ability to
- play with every possible solution to a problem
- refactor everything when you think of better patterns
so many people complaining about the code the LLMs produce, if you're not producing the best software of your life right now something is wrong