samuell

Seems they might have discoveref the language of G*d:

"[...] he has given a law to which they must conform."

- Psalms 148:6 (CJB)

:)

Now do the combinations of them.

I hope @jolaflow can chime in here eventually, but from a brief look, my impression, besides the fact that Epiq is based on git as opposed to beads where it is optional, is that Epiq seems to be much more optimized for interactive collaboration between the user and the agents.

The graph visualization in beads surely is a neat thing for showing things, but the replay feature in Epiq should provide a similar understanding of what happened.

But again, it seems to me Epiq is the tool that better allow the user to jump right in and collaborate with the agents on the board.

(Again, this is from a brief look, so I could be missing things).

Sorry, I might not have been clear, but the tool and blog is by @jolaflow (my brother) and I'm so far mostly involved as a reviewer and early adopter, but glad you like it. I might be biased, but I think the tool provides something really useful for agentic coding and hoping it can grow into a thriving open source project.

Yeah, I think as a general direction we need to allow a useful collaboration with the agents on the issue board.

This is btw why Epiq was developed, to keep the board as code, git-backed, distributed (via an event log mechanism), and with the ability to replay the board, to see what agents actually did:

https://ljtn.github.io/epiq

Indeed. A google/brave search on that founder generated nada.

Yea. A google on that founder generated zero results.

I read it, but OK, I misunderstood.

Let's not make this a Nordic conflict. We, the Nordic countries need to stay brothers and sisters with each other as we have done for centuries (not without sometimes serious squabbles, but still). Not even a European countries conflict. It is the EU as an institution that has started growing and reaching way beyond the will and welfare of the people.

I also stumbled upon this site, which on a first glance looks really thorough. Interested to hear if folks have comments on it though:

https://walkinglabs.github.io/learn-harness-engineering/en/

I have had a similar experience regarding tiling window managers. Been trying i3, but everything becomes just super complicated, and I learned I somehow actually appreciate having a feel for windows moving around, and having the freedom to open a small mini terminal above all the others for some quick tasks etc.

For me, XFCE (On Linux Mint currently) turned out to be the answer. Has configurable keyboard shortcuts for pretty much anything you need, like tiling to top/right/bottom/left, corners, moving or resizing windows etc.

To me, that is the best of both worlds - a normal window manager with keyboard shortcuts for tiling the windows when you want.

> Why not put issues alongside the codebase?

That's the idea of Epiq: https://ljtn.github.io/epiq/

> In my view, the main obstacle here is that without serious dedication, the user experience for humans would be a major downgrade. This isn’t insurmountable, but it would be a lot of work.

I think Epiq does a decent job of addressing this.

Take a look at the second animation on the page above. It even lets you "scrub" your way through the timeline to very quickly glance at what an agent (or junior developer) did to your code recently.

  "For with much wisdom comes much sorrow;
     the more knowledge, the more grief."

Ecclesiastes 1:18

I found it a bit curious that Mojo seems more readable, while at the same time less compact, than Rust.

At least according to my small experiment:

https://x.com/smllmp/status/2055602226240893043

I liked the connection of the central dogma of biology (DBA to RNA to Proteins) with Lisp programs.

I connected that to streaming flow-based programs though, as opposed to cell-to-cell signaling which shares many characteristics with, Erlang style, fire-and-forget message passing:

https://livingsystems.cc/posts/flowbased-vs-erlang-message-p...

Yea, I like the quiz feature a lot. It feel more efficient than both the podcast one (which mostly creates a very superficial high level talk on a level I typically already grasp), and the flashcard one in my experience.

A self-hosted git-based issue tracker like Epiq [1] seems more relevant by each day going forward.

[1] https://github.com/ljtn/epiq

Thank you for sharing!

Small off topic thing: I recommend removing the bit in the URL from ?si=... and forward, unless you want Google to track every user who clicks this link to your share.

For me as a follower, my interest is all about a compiled and fast language with little complexity (vs Rust), and a highly readable and fluent syntax (vs Go).

Yes, this kind of thing seems to happen quite often. Popular posts spurring further posts on a theme.

Garmin lets you connect your device as an USB storage device and manage everything manually though.

I do this to completely skip online uploading, and am keeping track of stats using a mashup of bash scripts and cli tools.

Glad to hear if it meets your needs!

Pardon the plug, but I thought I'd point out that I think SciCommander [1], or the ideas behind it, could be very relevant for this stack.

It does capture a provenance graph for any ad-hoc shell commands executed in the shell mode, or if prepended by `sci run`, by tracing all new files created from commands, and creating an accompanying json file for every output with metadata, which can later be assembled into a graph specific to any output file, using the `sci tohtml` or `sci toshell` commands (producing an HTML report with an SVG graph, or a reproducing shell script, respecively).

I'm quite bullish of the possibilities with this approach.

And, this was in fact also born out of the thinking to "rip apart" workflow tools, and build them up again using small, well-defined tools that do one thing well.

[1] https://github.com/samuell/scicommander

I don't know ... I actually think I'm quite aware of a lot of how complicated many things can be.

Perhaps it is because I was really curious as a kid about how things work, peeked into things, really tried to understand how it works, and figured it was far from easy.

I also tried to draw bikes, and figured you really have to think it through quite hard the first times, lol.

I think it is simply designed that way.

In my experience sparks are generally generated when quite small metal surfaces get in contact at high speeds, meaning they can generate a lot of friction in a very small point, and thus not have enough braking effect despite the local friction in one small point (think rail wheels squeeking in curves).

Brakes OTOH are designed to spread out the friction on a somewhat larger area, which allows more material to take up the friction and the heat, and spread it around.

I know brakes can get extremely hot too though, and after a really hard braking you might have to worry about deformed brakes sometimes.

Race cars tend to have really large breaks (and brake pads) for this reason.

I'll second the rec for Brave search. Been a happy user for at least 1-2 years now. Its AI summaries are great and, I have the feeling it works a little better than DuckDuckGo for some reason.

This was/is not a controlled scientific experiment. It is a blog post.

Well, I was referring to "value" here in a very pragmatic sense, in terms of the ability to come with "novel" thoughts and ideas.

And I argue that the notion of AI models having overtaken the human mind in practically all areas, is vastly inaccurate.

I could back it up with a number of references of course, but I think this is already quite well known and accepted by most people with some insight into the field.

While I understand this is a PR talk for a startup, I think the text itself contains a number of interesting observations.

Regarding the idea of distributed models communicating with each other, I have also been thinking (and writing [1]) along those lines, where I see that the data amounts needed to fully digitalize ourselves and our society requires far too much storage if just serialized (limited by bandwidth if nothing else), while smart, updateable models are actually a much better storage medium for such information, as it can communicate only the important bits (any new information) on a higher level, with each other.

The other observation here that rings bells for me is how I think lessons from trying to develop intelligent systems should upvalue the human mind rather than devalue it, as we start to treat it less like an ad-hoc thing, and more like the finely tuned machine it is, which also benefits greatly from optimizing what data we feed it with, the architecture of solution strategies etc. All of which is an area where humans and machines can do wonders together [2].

[1] https://livingsystems.substack.com/p/the-future-of-data-less...

[2] https://livingsystems.substack.com/p/ai-progress-should-upgr...

> Anthropic is actively campaigning to end software engineering

While this may be slightly overstated, my take on this is that AI progress should have us upgrade our view of the human brain rather than the opposite.

Wrote about it the other day:

https://livingsystems.substack.com/p/ai-progress-should-upgr...