Comment by CookieCrisp
21 hours ago
I highly recommend to anyone that uses them a lot - try to clone your own. I’ve got mine fully formed into how I want it, with features I haven’t seen anywhere else yet and with integration into everything I work with. We’ve lived in a world where every app had to fit enough people well enough - but now we live in a world where an app can be molded to be absolutely perfect for just you!
Most people don’t want to play product manager and just want to pay someone to make the decisions for them.
We used to have a time where every small business had its own custom accounting software, and discovered that these businesses aren’t actually special snowflakes and are better off just using the generic software and conforming to whatever it does
They were better off because the discomfort of shoehorning was less than the discomfort of in-house software development. The latter has changed radically so the conclusion may no longer hold. SWEs would do well to have at least one side project to calibrate their intuition about the cost of delivering and maintaining a greenfield project so that they can spot the niches which have begun to appear even as others live on borrowed time.
Out of curiosity, what are your favourite features that are unique to your implementation?
Not parent, but favorite feature of my own harness I haven't seen somewhere else, is the ability for the agent to execute code on different hosts in a transparent and easy way. Fairly simple and probably could prompt the agent + set things up with ssh, but was doing other stuff related to a server<>client model, so figured why not add it as a couple of tools. Now the agent can build cross-platform applications while I'm mostly on Linux and actually verify it works, without me manually switching between three OSes.
When I tell Claude or open code using Kimi or codex to fix something on my raspberry pi, they all go to ssh right away.
I found that most things that are “features” in harnesses and tools that don’t relate to UI and UX in those harnesses themselves can be done through skills or just prompts.
A nice features of Claude’s is the remote control through the mobile app. That isn’t just a skill.
This is the way. Guess what am I working right now? My own “Work” app that will be better than anything else available today!
Same here! https://github.com/rush86999/atom
Looks like the thing I am building but of course mine will be slightly different. It would be great if we could all meet to show off and discuss our AI stuff.
How did you build your own coding agent? What language/framework did you use?
This comment is a great example of how large and strange the skills gap in AI is right now.
Curious why your first impulse is not simply to point your favorite agent at a few examples and start brainstorming/planning from there?
Multiple times I’ve built a purpose specific bespoke tool starting this way. In fact, it’s a great way to learn how specialized tools are built.
The problem of the sota models clamping down on third party harnesses should be stated upfront. Getting a SOTA model in a custom harness requires API pricing or risking an account ban, correct?
This preliminary change in cost may not make it worth it for people depending on which is their "favorite agent". Especially as the default harnesses for said agents continue to improve...
2 replies →
Presumably people want to hear the opinions of other people and still believe that they might learn more from the their experience than by exclusively interacting with AI models?
The alternative of that first impulse should be what exactly? Telling AI to research Medium AI drivel articles (since nobody seems to be posting long/medium form content anywhere else these days) to figure out what’s the best approach to building an AI harness?
BTW just my personal observation but I generally find AI notoriously bad at building any AI applications compared to standard software (which is not surprising given the scarcity of high quality training data)
1 reply →
Not the parent commenter, but most of it is surprisingly simple. You basically start with a "chat app" where you have a list of messages, send the whole conversation to an LLM and it replies back, which also gets added to the same list.
And you add a small twist, that instead of a 1-to-1 back and forth, you instead put it into a loop, where the LLM reply can itself "have a turn", e.g. a tool invocation, where your system is the one that replies (e.g. with the tool invocation's result). That's pretty much it, you have a 1 to potentially many "chat".
The harder part is getting all the "soft" parts right, like how to have well-behaving tool calls, timeouts, prevent huge cycles eating up tokens, but there are no one way to solve these, it's a fundamentally heuristic-heavy area.
It's pretty simple nowadays if you know conceptually how they work. Running the LLM calls in a loop with tools is an agent. You only need 10 or so basic tools to accomplish nearly anything, and you can build a dynamic skill system from that. Look at https://github.com/patw/pengy, ignore the app look at the spec.md file, feed that to your current agent of choice and make your own version. Use whatever tech stack or UI you're comfortable with. Change some of the choices in how it works, so it fits what you want to work.
Implementing your own agent is very easy. Here is a minimal agent in 60 lines of Python without dependencies:
https://github.com/99991/MinimalAgent
You only need a single tool to start with. All recent LLMs know how to use bash for reading/writing/editing/executing.
Why would the language matter? Just use your favorite.
Look at pi coding agent.
It would have been much easier to clone six months ago but today Codex/Claude desktop apps are so feature packed it seems it wouldn’t be worth it.
For example, the mobile/remote control feature I find very useful but not sure it would be worth cloning. If you aren’t replicating every feature you aren’t exactly “cloning” it, you’ll just end up with a crappier version with a fraction of the features of the real thing.