resiros

Nope did not notice. Updating my comment

The video cuts to a new shot every couple of second instead of one continuous shot like all robotics research. This makes it hard to trust it. The robot probably failed a million team and they stitched the video from 100 experiments.

I think posthog is one of these businesses where the COSS model does not work well.

COSS works well when there is a large distribution advantage of being OSS. This could be bacuse a large portion of users (need to) self-host the solution. This is true for databases, people will always need to self-host dbs (e.g. as part of their docker compose in dev, etc...). These people are also hard core engineers that will 1) talk about the db and 2) contribute to the project. So an OSS db have a large network effects and distribution advantage.

Posthog had a distribution advantage from OSS in their beginnings -- their beachhead was the self-hosting oss community. Now, it does not add much value -- It's unlikely Github adds much for their distribution. So, it does not make sense for them to do much more than just maintain it lightly. In fact, they try to push you from self-hosting by having great free tiers and startup programs.

However, the point the article is making is that for different functions the same basic folds seem to be used again and again.

That's a basic fact in bio. Check the rossman fold page for example: https://en.wikipedia.org/wiki/Rossmann_fold it's a template used for many functions.

Evolution discovered a bunch of structural patterns at different layers (fragments, folds..) that are energetically favorable, versatile, easily foldable, robust to mutations and then kept reusing them. As a result it sampled more and more in these parts of the space. That's why the fold space is uneven.

Are there any folds and patterns that evolution evolution has not discovered that are also useful? I think Baker Group created a bunch of new folds. I'm not sure if they are as useful as the one discovered by Evolution. After all, Evolution had more compute power than us.

I agree. The only reason I use TUI is because GUI are very slow with electron.

The only software that is as fast as TUI is the Zed IDE. Apparently they use Rust + their own built GUI toolkit with GPU rendering.

And apparently it's tightly coupled with Zed.

I think you are underestimating both the value of both projects (autoresearch and personal wiki) just because they are simple. I see both POCs for continuous learning / optmization on the harness layer, which in my opinion is a very interesting direction.

I think Andrej has the experience (and now ressources) to productionize this research into something very interesting.

p.s. called it

Karpathy will help launch a new team focused on using Claude itself to accelerate pretraining research — an increasingly important frontier as AI companies race to automate parts of AI development. (https://www.axios.com/2026/05/19/anthropic-openai-karpathy-a...)

I don't think this is true. He strikes me as a person motivated by curiosity and interesting problems.

Going to Kabuki was one of the most amazing experiences we had when visiting Japan. Although I am not a theater person, and the whole thing was in Japanese ,and we did not have the auto-translate tablets, we enjoyed it a lot. It was very beautiful, and funny.

I recommend to anyone visiting that part of the world.

I think you gave someone an idea for a new RL environment :) Probably it will be able to fly it in the next iteration.

This seems like a hit job by a competitor. Really ruthless.

Two months ago, an email went out to a few hundred Delve clients informing them that Delve had leaked their audit reports, alongside other confidential information, through a Google spreadsheet that was publicly accessible.

Who leaked the audit reports? Who sent this email? Who is taking the time to write this analysis and kill the company?

In my opinion, the majority of the points in the article are no news. A compliance saas that offers templates for policies, all of them do. The AI is a chatbot, well who thought.

I think the main point is the collusion between delve and the auditors. Is the evidence for that clear?

Not sure I agree with the AI edited comments. Using AI to improve the readability and clarity is fine. Sometimes a well structured comment is much better than a braindump that reads like ramblings. And AI is quite good at it (and probably will get better). To make the point, here is how this comment would have looked if edited:

"I don't fully agree with banning AI-edited comments. Using AI to improve readability and clarity is a reasonable thing to do. A well-structured comment is often much better than a braindump that reads like rambling. AI is quite good at this, and it will probably get better. To illustrate the point, here is how this comment would have looked if edited"

I don't follow the need to write CLIs for the agent. Why not use simply the API and document it well? The token difference between using an API and CLI is not that much, and models are trained to use REST APIs and understand their patterns, compared to your random CLI.

I use netbird and can only recommend it

Netbird is very good for my use case. Simple to set up, and just works.

It might simply be that it was not trained enough in Elixir RL environments compared to Gemini and gpt. I use it for both ts and python and it's certainly better than Gemini. For Codex, it depends on the task.

I mean, no one is asking for artistic writing, just not some obvious AI slop. The fact that we all can now easily determine that some text has been written / edited by AI is already an issue. No amount of prompting can help.

I wonder why AI labs have not worked on improving the quality of the text outputs. Is this as the author claims a property of the LLMs themselves? Or is there simply not much incentive to create the best writing LLM?

Honestly, just use OpenCode. It works with Claude Code Max, and the TUI is 100x better. The only thing that sucks is Compaction.

This is quite nice but limited in that it is single-player. In my opinion, the next generation of AI agents will be multi-player. Ramp's background agent is a good example https://builders.ramp.com/post/why-we-built-our-background-a...

Making this multi-player + creating the right representation to collaborate with agents is in my opinion the next bottlenecks. I wrote a small article about my thoughts there https://x.com/mmabrouk_/status/2010803911486292154

Very interesting but the limitation on the libraries you can use is very strong.

I wonder if they plan to invest seriously into this?

It would be nice to have an open-source version that you can self-host. That would solve the abuse problem. Maybe with a service to create API keys.

That is really cool! Congrat on the launch!

I was surprised not to see a share and embed button. I would expect that could be huge for growth.

"TypeScript is now the most used language on GitHub. In August 2025, TypeScript overtook both Python and JavaScript. Its rise illustrates how developers are shifting toward typed languages that make agent-assisted coding more reliable in production. It doesn’t hurt that nearly every major frontend framework now scaffolds with TypeScript by default. Even still, Python remains dominant for AI and data science workloads, while the JavaScript/TypeScript ecosystem still accounts for more overall activity than Python alone."

I am not sure I agree with the conclusion "developers are shifting toward typed languages that make agent-assisted coding more reliable in production". I see it more with fullstack development being democratized.

I am originally Python/BE/ML engineer. But I've built in the last years many Frontend, simply because AI coding enables so much.

That was not an option previously.

Looks more of an aquisition for me. They are integrating the 50000 models into worker AI.

Author here. I wrote this blog post about our journey with COSS and the different models we experimented with.

If you're running (or have run) a commercial open-source company, we'd genuinely love to hear your experience.

The advice we got from other founders is to focus on adoption

TL;DR

I'll preface this by saying that neither of us has a lot of experience writing Python async code

I'm actually really interested in spending proper time in becoming more knowledgeable with Python async, but in our context you a) lose precious time that you need to use to ship as an early-stage startup and b) can shoot yourself in the foot very easily in the process.

The best advice for a start-up is to use the tools that you know best. And sometimes that's not the best tool for the job. Let's say you need to build a CLI. It's very likely that Go is the best tool for the job, but if you're a great Python programmer, then just do it in Python.

Here's a clearer case where the author was not very good with Python. Clearly, since they actually used Django instead of FastAPI, which should have been the right tool for the job. And then wrote a blog post about Python being bad, but actually it's about Django. So yeah, they should have started with Node from day one.

There is a major mistake in the article. The author argues that openinference is not otel compatible. That is false.

OpenInference was created specifically for AI applications. It has rich span types like LLM, tool, chain, embedding, agent, etc. You can easily query for "show me all the LLM calls" or "what were all the tool executions." But it's newer, has limited language support, and isn't as widely adopted.

The tragic part? OpenInference claims to be "OpenTelemetry compatible," but as Pranav discovered, that compatibility is shallow. You can send OpenTelemetry format data to Phoenix, but it doesn't recognize the AI-specific semantics and just shows everything as "unknown" spans.

What is written above is false. Openinference (or for the matter, Openllmetry, and the GenAI otel conventions) are just semantic conventions for otel. Semantic conventions specify how the span's attributes should be name. Nothing more or less. If you are instrumenting an LLM call, you need to specify the model used. Semantic conventions would tell you to save the model name under the attribute `llm_model`. That's it.

Saying OpenInference is not otel compatible does not make any sense.

Saying Phoenix (the vendor) is not otel compatible because it does not show random spans that does not follow its convention, is ... well unfair to say the least (saying this as a competitor in the space).

A vendor is Otel compliant if it has a backend that can ingest data in the otel format. That's it.

Different vendors are compatible with different semconvs. Generalist observability platforms like Signoz don't care about the semantic conventions. They show all spans the same way, as a JSON of attributes. A retrieval span, an LLM call, or a db transaction look all the same in Signoz. They don't render messages and tool calls any different.

LLM observability vendors (like Phoenix, mentioned in the article, or Agenta, the one I am maintaining and shamelessly plugging), care a lot about the semantic conventions. The UI in these vendors are designed for showing AI traces the best way. LLM messages, tool calls, prompt templates, retrieval results are all shown in user friendly ways. As a result the UI needs to understand where each attribute lives. Semantic conventions matter a lot to LLM Observability vendors. Now the point that the article is making is that Phoenix can only understand the Openinference semconvs. That's very different from saying that Phoenix is not Otel compatible.

I've recorded a video talking about OTel, Sem conv and LLM observability. Worth watching for those interested in the space: https://www.youtube.com/watch?v=crEyMDJ4Bp0

Great work. I was expecting to use the informal transliteration keyboard, using 3 for ع or using 2 for ء or 7 for ح

Having been from the other side of the table. You did not flunk anything again.

A job process is not an exam where if you do well you succeed.

Your "performance" plays a small role in whether you are accepted (maybe less than 30%). The rest is:

- The pipeline: that is who are your competitors, is there someone late in the process, is there someone a manager worked with / knows

- Your CV: obviously at the point of the interview, you can't change your history

- The position fit: basically who they're looking for. They might have a profile in mind (let's say someone extrovert to do lots of talks, or someone to devrel to enterprise) where you simply don't fit.

- The biases: And there is looot of these. For instance, some would open your blog and say it's unprofessional because of the UI. Not saying that is the case, it's simply their biases.

So, my advice, you reached hn front page twice in a couple of months. Most people, me included, never did. You clearly have something. Find work with people that see that.