Live data from Hacker News

Towards a harness that can do anything

eardatasci.github.io

101–110 of 121 posts

Re: Towards a harness that can do anything

#101
post #97

I spent 6 months frantically working fulltime on a harness, and when it was finished, I just stopped using it and went back to Codex CLI. I've also stopped using all the fancy features: subagents, planning mode. I've also stopped worrying about context, since I just let codex hit compaction. Somehow this doesn't seem to hurt much. Weird.

harnesses i suspect are better for noncoding tasks like wrapping claude code to be a personal assistant... but im still procrastinating on building mine... if only i had a personal assistant to tell me how much time i should spend on building a personal assistant wrapper for claude

Re: Towards a harness that can do anything

#102

I use AI all the time But I don't want the AI to summarize my email for me. I don't want the AI to summarize my calendar for me. I don't want the AI to summarize my Zoom call for me. Thanks

Exactly right. There are many different domains that AI can be helpful in, and I am frustrated by how it's used to process information in a lossy manner.

Re: Towards a harness that can do anything

#103

It’s interesting to me how many people articulate things like the “Preiminary Truths” section as if they are novel insights. Effective people managers (of whom I would not specifically consider myself) have known these tenets for as long as history. “Be concise”, “state your intent clearly”, funny how these are touted as novel “strategies” with which to expertly direct AI. I don’t agree that “everything is a file”. F…

> I don’t agree that “everything is a file”. Files are arrays of bytes. For an LLM, everything is a vector of tokens/embeddings. And yet, as of now, LLMs have a hammer (Bash / command line utilities) and every problem they have looks like a nail. If there are people around you who are non-techies that are using Claude Code or similar, you'll hear them ask "what the heck is cron?" and "why is it talking to me about Ba…

That is fair, I HAVE INDEED seen similar of those anecdotes. However, I still am skeptical of the file analogy.

LLMs are good at traversing traditional file systems because file/tree-like structures very likely encompass an overwhelming supermajority of their training set. By contrast, other approaches like graph-based vector/data discovery via sql queries seem equally or more promising (to me), not to mention the ability to run curl/http queries. Either way, it’s still all prompt engineering approaches to discover/manage context. In this way, files seem like a “local minimum” ie a medium that dually optimizes interpretability and accessibility for both LLMs AND humans.

Just riffing here, but this could even broadly be considered a discussion of memory-vs-storage (somewhat analogous to fluid vs crystallized memory in humans). In this way, one could imagine the models performing context compaction/backup by periodically dumping their context to files (or some other non-volatile storage) WITHOUT coming back to feature space.. just dump/load the tokens directly.

Personally, I am much more interested in even other approaches like VLMs (using visual tokens), architectures like auto encoders and its variations, jepa architectures and other approaches that emphasize operating primarily within the latent space.

To be fair, my particular interests have always been more in the computer vision area, and have been amused to watch the attention mechanism rise to prominence even over CNNs (given the contrast |similarity in their mechanics). Then again, I began my journey in the ML field when GANs were still the hotness, but I digress……

for LLMs, it’s tokens all the way down, and the name of the game is how discoverable and accessible can you make them?

Re: Towards a harness that can do anything

#104
post #93
post #78

Earlier quoted context omitted.

I am not sure if this is sarcasm - but just in case - https://github.com/sshwarts/skillscript does not offer a unified namespace for functions and prompts (agents) like https://github.com/zby/llm-do (currently in suspended development). There are now also the 'dynamic workflows' in Claude Code that are pretty interesting approach - they are like a compiled prompt in many aspects.

No sarcasm. In that thread we discussed recursive, interleaved application of code and prompt. No morphing, however. Thanks for dynamic workflow pointer. I don’t know if I like JavaScript for workflow definitions tho. IMHO sshwarts has the right idea on severely constrained workflow definition language. I plan to look closer into ADK2 workflows as well. I’m not saying anyone did what you are doing, I’m saying multipl…

Thanks!

Re: Towards a harness that can do anything

#105
post #62

I kind of have a different idea of agents. I totally believe in a deterministic scaffold but I really think that an agent should be as deterministic as possible - the more code, the better. Think of a typical loop we may ask of Claude Code today (assume we are not using TDD): run some test suite with fail fast mode, diagnose if the failure is due to recent feature changes (pass reference to backend/frontend, github i…

What you are describing is precisely my goal with my agent framework. One of the meta-processes designed in is pushing automated processes, both defined and discovered, down as far as possible. "Down" here means as far towards the metal as reasonable. So automate the automatable stuff, and leave the LLMs to do stuff LLMs are actually good at. A trivial example is 'handle this bugfix ticket'. Many actions in a bugfix…

Yes, this is how I am building my agent as well. A chain of mostly deterministic steps for every incoming prompt. Run as many tools without help of LLMs, gather errors - feed to LLMs, then go back to deterministic steps as soon as possible.

Re: Towards a harness that can do anything

#106
post #97

I spent 6 months frantically working fulltime on a harness, and when it was finished, I just stopped using it and went back to Codex CLI. I've also stopped using all the fancy features: subagents, planning mode. I've also stopped worrying about context, since I just let codex hit compaction. Somehow this doesn't seem to hurt much. Weird.

You adapted to how your tool works rather than try to shape it into what it isn't. So far all the nondeterministic (prompt based) workflows I have tried have been meh in an "I can't tell if it's any better but it sure is more complicated and less portable" way.

Current tools. Opencode and whatever cli i can't avoid (like claude code for my first month which I don't thinking I'll renew) usually accessed using Paseo for it's excellen mobile client.

Re: Towards a harness that can do anything

#107
post #4

Why are we not just using Claude Code or Codex on our machine and using this thing? Real question...

i think the point is less about what agent you should or should not do and more about what is the natural harness for an agent to succeed in. And agents are often autonomously doing things right now, why would you want claude code doing such stuff for you?

[flagged]

Re: Towards a harness that can do anything

#108
post #66

I kind of have a different idea of agents. I totally believe in a deterministic scaffold but I really think that an agent should be as deterministic as possible - the more code, the better. Think of a typical loop we may ask of Claude Code today (assume we are not using TDD): run some test suite with fail fast mode, diagnose if the failure is due to recent feature changes (pass reference to backend/frontend, github i…

I believe there should be easy ways to move logic between prompts and code in a smooth ways. Moving from prompts to code is for getting deterministic, fast, well defined and cheap execution - the other way is when you want to quickly extend your system or when you want to relax a pre-condition (which is extending if you look into it deeply). There are some inroads into this vision - but I haven't seen anything build…

It is all binary, all the way down. Code is text that passes the compiler's checks. Human language is text that has a really ambiguous compiler. And all text is still binary in the computer.

If you think about it, the transformers architecture was created to solve language translation. It works well for human language to code and other way around, already!

What we need is better tooling for this translation on either side. I started working on https://github.com/brainless/nocodo/blob/feature/praxis_agen... for this reason - how can we go from human language to code representing it.

Re: Towards a harness that can do anything

#109
post #77
post #74

Earlier quoted context omitted.

I was unsuccessful in area of automation because of different issue. By trade I am a .Net software developer so as a lot of people would imagine — I was not able to accept a script that wouldn’t be reusable and flexible, basically over engineered. I do quite some devops so I finally had to accept the fact that I can write simple script with hardcoded values that will live on a server (where I can copy paste and chang…

There is an idea I have been enjoying called WET, Write Everything Twice. Basic idea is you should only make things more general and parameterized if you need to write it a third time. The upshot of this is you actually have a much better understanding of the different way your script needs to work if you're adapting it for a third use instance.

I would suggest that if you have two similar copies of sufficiently complex logic, it's fair to combine them after they have been stable for a long time. My gut feeling is that the threshold should be a function of complexity times stability in hours worked (on that part of the code), because the expected maintenance cost of duplicated code scales with its complexity.

Re: Towards a harness that can do anything

#110

I kind of have a different idea of agents. I totally believe in a deterministic scaffold but I really think that an agent should be as deterministic as possible - the more code, the better. Think of a typical loop we may ask of Claude Code today (assume we are not using TDD): run some test suite with fail fast mode, diagnose if the failure is due to recent feature changes (pass reference to backend/frontend, github i…

I think AI usage is going to fall into exactly this pattern the same way the frontend + API has become the "obvious" approach. We mostly operate with known workflows and just need a touch of LLM magic to determine when to do what.

Right now we mostly YOLO prompts with some docs/skills in the mix but I think it will start to look more like internal MCPs, with tools the LLM can string together. I think the reality will be most tasks end up serviceable by Haiku-level LLM, not Fable.

Post reply on HN