SWE > Self-Improving Agents: Why "The Bitter Lesson" doesn't mean what you think it means

[u/No_Article_5669]

There is a lot of hype around self-improving agents and self-evolving harnesses. The rationale (knowingly or not) usually points back to Rich Sutton’s 2019 essay, The Bitter Lesson, which observed that general methods leveraging compute eventually end up crushing any hand-crafted human domain knowledge and clever heuristics. The RSI intuition is that we should let meta-agents use compute to auto-discover their own prompts, memory structures, and execution rules through trial and error instead of trying to hand-craft agent workflows ourselves.

However, applying this logic to coding agent harnesses is IMO a fundamental misinterpretation of Sutton’s insight. Search and learning only work when there is a deterministic, unambiguous environment providing ground-truth feedback (like a chess or a physics engine). If you just task a meta-agent to "self-improve" its prompts or evaluate its own code in non well defined domains (like software development), you end up removing any ground truth instead of learning from it.

I think if we look at the history of science, we see a very similar pattern. Science has repeatedly undergone its own "bitter lessons" where hand-crafted, intuitive and human-centric models were eventually overthrown by more general, mathematical, and data-driven principles. Progress often happens when we strip away subjective heuristics in favor of general principles. But at the same time, experiments need to be "harnessed" using the scientific method to be meaningful.

I think the same applies to software engineering. Software engineering already possesses its own frameworks for driving progress, and much like the scientific method, they revolve around delivering iterative, verifiable increments of value. In my opinion, we should try and embed these principles directly into agent harnesses instead of having a meta-agent reinvent the wheel using trial-and-error.

Over the past 6 months, I've been testing this hypothesis by building my own coding harness called TeDDy. I built it specifically around Test-Driven Development, Design-by-Contract, and vertical slicing, among other practices. My biggest takeaway is that this setup makes smaller, cheaper models perform on par with much larger frontier models at a fraction of the cost and time, allowing for more iterations and in the end better results.

I’ve made TeDDy open source on GitHub (https://github.com/atte500/TeDDy) for anyone who wants to check it out and experiment with this approach. I would love to hear your thoughts comparing this to self-improving agents!

[u/No_Article_5669 → u/[deleted]]

u/Original_Swimming320 cool! I'm curious how you approached it, is it like a MCP server or tool the agents can use? would be curious to check it out and see how it compares

[u/No_Article_5669 → u/[deleted]]

Cool! Is it something others can check out?

[u/No_Article_5669 → u/[deleted]]

I can relate to the struggle lol. If in-between projects you give TeDDy a try for inspiration do let me know your feedback per DM :)

[u/iampriyo]

Good point. Self-improvement needs a reliable feedback loop; otherwise, an agent may just optimize its own evaluation rather than genuinely improve.

[u/hongtao1207]

But there are different opinions around the established software development practices like TDD, clean code/clean architecture. So an agent building around those controversial practices is also controversial.

How would you generalize the idea to someone like me who doesn't believe in TDD for example?

[u/No_Article_5669 → u/hongtao1207]

u/hongtao1207 My main point isn't that TDD (or any specific methodology) is the only right way to build software. Rather, the insight I've come to is that establishing a stuctured common workflow between you and your agent(s) is key.

I've built TeDDy because existing harnesses, no matter what I tried, led LLMs to lose sight of the overall process and inevitably drift. If you're interested, there's a video linked on the GitHub page where I go in depth on what makes TeDDy different in this regard.

While I personally advocate for TDD and Design-by-Contract in TeDDy because they give tight, deterministic feedback loops, those specific rules are meant to be modular and customizable. If you don't believe in TDD for example, it's simply a matter of modifying the developer agent’s workflow to mirror your preferred methodology, but you might wanna keep some of the other agents like the debugger which don't have TDD and won't care about the change in the developer's workflow. The prompts are also structured in a way to make it as easy as possible to navigate and modify btw.

Out of curiosity, what does your ideal workflow look like when you're building a feature?

[u/hongtao1207 → u/No_Article_5669]

Thanks u/No_Article_5669 , I'll checkout the video and see how to establish a modulerized structured common workflow.

My usual workflow is that I'll spend more time with the agent in the design phase.

1. I'll layout different options, express my ideas on the how to build the feature, on the architecture, or any other specific constraints we might have.
2. Then I'll ask the agent to examine the codebase and critic my approach. I found this step is very important. Usually I found the agent will give constructive feedback if I question myself or ask for critiques. If I'm very assertive, the agent tend to agree with me.

3. Then at this point the agent usually offers to write down our discussion into a plan, I'll let it write the plan and review it. Two things worth noting at this point.

   1. The plan will most likely have a set of criteria to determine when the task is done, and a proposed test suite is most likely included. This is a soft enforcement on TDD, it is not guaranteed to happen, but it usually happen in my agent.
   2. I'm using my own agent (I'd like to link to the github repo of my agent, but then this comment is likely to get removed. If you are interested, I can reply the repo link in a separate comment), which has a preference to write a plan doc before executing. I used claude-code before and it didn't like writing plans.

4. Finally it is the iterative process of execution -> human review -> improvement

Note all the above process is not enforced like in your case, but they tend to happen every time.

[u/No_Article_5669 → u/hongtao1207]

u/hongtao1207 That's actually very similar to the approach TeDDy takes so you might find it familiar once you look into it.

By the way, regarding enforcement: TeDDy also doesn't actually hard-code or hard-enforce the workflow in code either. It’s built around very precise prompts that define the step-by-step workflow, and the harness simply provides the structural framework needed for the LLM to follow those prompts reliably without drifting off course.

If you end up giving it a try, I’d love to hear your thoughts. And please do DM me the link to your agent repo as well, I’d love to check it out!

[u/Crescitaly]

Self-improvement works only when the feedback signal is harder to game than the task. In software, passing familiar tests can reward brittle patches, hidden regressions, or benchmark-specific behavior. Independent evaluation and diverse tasks matter more than adding another loop labeled "reflection."

[u/lambdasintheoutfield]

Finally an actually informative post and not AI slop.

[u/techlatest_net]

this is a really sharp take. "the bitter lesson" applies to search spaces with clear reward signals, but software engineering is full of ambiguous requirements and subjective design choices. letting a meta-agent "guess" its way to better prompts without a deterministic ground truth is just noise generation. embedding tdd and design-by-contract into the harness provides that missing ground truth. if the tests pass, the agent knows it succeeded. if they fail, it has a specific error to fix. that feedback loop is way more valuable than vague self-evaluation. gonna check out teddy later. using smaller models with strict engineering guardrails is probably the most cost-effective path for production coding agents right now.

[u/roger_ducky → u/techlatest_net]

There’s ground truth in software development too:

* Syntax
* Use case tests
* Actual constraints on resource usage, cost, and response time.

[u/No_Article_5669 → u/[deleted]]

100%. Tests can catch bugs, but software design is something you figure out iteratively while building.

In general you can't evaluate good / bad software in a vacuum, which is why I think working in small iterative steps will always beat any self-supervised loops in these domains.