TeeWEE

Was using Reveal.js which worked well because it can use any HTML or any plugin.

Bento works with a predefined schema, so you cant use any HTML library (Such as Mermaid.js) if you need it in your presentation.

But then again, often you dont need it.

Just created a presentation with Bento... I do think Reveal.js gives you more raw power. But I like bentos single html page design, and you can easily edit it manually. You cant do that with Reveal.js

Basically it’s AI on top of AI for metadata extraction.

There are a lot of claims in the article but not a lot of hard data. In the end they still don’t know if the data is correct.

Good luck with your glutes allergy.

The weird thing for me is the prompt optimization loop? Why not fine tune the model instead of AI generating the prompt?

This is mostly a thin clintypescript wrapper around the prompts.

This could have been a SKILL

Git itself wasn't designed for that load, and bolting AI onto platforms not built for agents is the biggest mistake of this era. We're doing a generational rebuild of the underlying infrastructure to handle agent-rate work as the default. Git itself is being reengineered for machine scale. The monolith is giving way to modern, API-first, composable services

Two big red flags here.

First git itself is distributed and built for scale.

I guesss they mean “gitlab” instead of “git”. But such a huge mistake would never go unnoticed.

Are they going to rebuilt git??

Secondly: a big rebuilt of monolith to services. Firstly there is nothing wrong with a Modulith. Secondly “rebuilt” will cause a lot of busy work without immediate value for customers.

And first of all: this announcement is done due to the stock price not AI The productivity increase with AI is inflated because they want their stock price up.

Sell Gitlab stock while you can. The leadership team has no clue what they are doing.

Sadly non engineering leaders buy into this dogma. AI is very usefull but in my experience doesn’t 10x if you don’t YOLO it.

That’s indeed the trick. Spacex “invests” in Cursor, looks good on their balance sheet.

And xAI now gets 10B of more revenue on their income statement.

Perfect financial statement boosting for the IPO which in turn will pay back these costs.

At least that’s the bet.

There are two kid of specs, formal spec, and "Product requirements / technical designs"

Technical design docs are higher level than code, they are impricise but highlight an architectural direction. Blanks need to be filled in. AI Shines here.

Formal specs == code Some language shine in being very close to a formal spec. Yes functional languages.

But lets first discuss which kind of spec we talk about.

I think nanoclaw is architecturaly much better suited to solve this problem.

We make the creator of the PR responsible for the code. Meaning they must understand it.

Also, we only allow engineers to commit (agent generated) code. Designers just come up with suggestions, engineers take it and ensure it fits our architecture.

We do have a huge codebase. We are teaching Claude Code with CLAUDE.md's and now also <feature>.spec.md (often a summary of the implementation plan).

In the end, engineers are responsible.

If you work at OpenAI, leave now while you can.

My point is: Trust the work of AI just like the work of a contracter: Check and verify, but dont micromanage.

Do you trust your employees? Do you trust a contracter? Do you trust other people?

AI is similar to a person you dont know that does work for you. Probably AI is a bit more trustworthy than a random person.

But a company, needs to let employees take ownership of their work, and trust them. Allow them to make mistakes.

Isnt AI no different?

I hardly use Google anymore. I almost always use Claude. It can do the "higher level task" I often want to accomplish when I go to google.

Claude checks multiples websites, reads them all, and answers my question.

This is quite a bad idea. You need to control the size and quality of your context by giving it one file that is optimized.

You don’t want to be burning tokens and large files will give diminishing returns as is mentioned in the Claude Code blog.

Indeed seems like Vercel completely missed the point about agents.

In Claude Code you can invoke an agent when you want as a developer and it copies the file content as context in the prompt.

The BMW neue klasse is far superior to the latest Teslas.

Both in software hardware and handing.

https://youtu.be/P-H-GJaGiUg?si=eq8YWy8gyJ5YS99X

I think it even surpasses Chinese brands.

This is amazingly cool

Is open router used a lot? I just use claude code, so this is a misrepresentation of what is actually the most popular model right?

I dont like the "impure" label. But the guts of it is right. Most software solves a business problem. Even the "pure" ones could choose to deliver value sooner with tech debt.

The main thing that lacks in go is auto OpenAOI generation from a golang func. You at least need reflection. It can be done. But not as easy as in python

Wow Sam Altman is so full of himself... I would never want to work for this narcist. Just watch this video. https://x.com/sama/status/1925242282523103408

First flying bike. Startwars style

Correction: the MCP is a protocol for function calling and getting context into a model. It’s can run locally or over a network.

It does not specify how “agentic” systems interact with each other. Depending on what you mean there.

Was also looking at Langfuse.ai or braintrust.dev

Anybody with experience can give me a tip of the best way to - evaluate - manage prompts - trace calls

It depends. That’s the whole point.

I see a lot of people here saying one is better than the other. But it depends on your use case and company size.

GRPC is a lot more complex to start using and hides internals. However it has some major advantages too like speed, streaming, type safety, stub generation. Once you have it in place adding a function is super easy.

The same can be said of OpenAPI. It’s easier to understand. Builds upon basic REST tech. However JSON parsing is slow, no streaming and has immature stub generation.

From my experience a lot of users who use OpenAPI only use it to generate a spec from the handwritten endpoints and do manual serialization. This is the worst of the two worlds. - manual code in mapping json to your objects - manual code mapping function parameters to get params or json - often type mapping errors in clients

Those engineers often don’t understand that OpenAPI is capable of stub generation. Let alone understand GRPC.

GRPC saves a lot of work once in place. And is technical superior. However it comes at a cost.

I’ve seen OpenAPI generated from routes, with generated clients libs work really well. This requires some time to setup because you can hardly use OpenAPIGenerator out of the box. But once setup I think it hits a sweet spot: - simple: http and json - can be gradually introduced from hardcoded manual json serialization endpoint (client and server) - can be used as an external api - allows for client lib generation

But it really depends on your use case. But to dismiss GRPC so easily mainly shows you have never encountered a use case where you need it. Once you have it in place it is such a time saver. But the same holds for proper OpenAPI RPC use.

However my inner engineer hates how bad the tooling around OpenAPI is, the hardcoded endpoints often done instead of server stubs, and the amount of grunt work you still need todo to have proper client libs.

What do you mean with validating the bindings? GRPC is type safe. You don’t have to think about that part anymore.

But as the article mentions OpenAPI is also an RPC library with stub generation.

Manual parsing of the json is imho really Oldskool.

But it depends on your use case. That’s the whole point: it depends.

What tells you that your brain is not a probabilistic machine?

How can a rule book help fixing incidents. I mean I hope every incident is novel. Since you solve the root issue. So every time you need to dig in the code, or recently deployed code and correlate it with your production metrics.

Or is the rulebook a simple rollback?

This results in me trusting Tesla less.

If this was fake, how do we know the robovans were not remotely operated? They might as well be too to get the stock price up?

There is no way to know. I am really doubting Tesla now. It wouldn’t surprise me that, in order to prevent mishaps during the event, everything is remotely operated…

People will say: that’s not true. But where did Tesla clearly specify this upfront?

I saw the initial fullscreen disclaimer. But that might also apply to the robovans right?

This person doesn’t seem to know about table stream duality. Crud is just an immutable event stream. All crud systems use this in their journaling system.

Very nice!

However for our use case we want total control over the server database. And wanted to store it in normalized tables.

The solution we went for us is streaming the mutation stream (basically the WAL) from/to client and server. And use table stream duality to store them in a table.

Permissions are handled on a table level.

When a client writes it sends a mutation to the servers. Or queues it locally if offline. Writes never conflict: we employ a CRDT “last write wins” policy.

Queries are represented by objects and need to be implemented both in Postgres as wel as SQLLite (if you want offline querying, often we don’t). A query we implement for small tables is: “SELECT *”.

Note that the result set being queried is updated realtime for any mutation coming in.

It’s by default not enforcing relational constraints on the clientside so no rollbacks needed.

However you can set a table in different modes: - online synchronous writes only: allows us to have relational constraints. And to validate the creation against other server only business rules.

The tech stack is Kotlin on client (KMM) and server, websocket for streaming. Kafka for all mutations messaging. And vanilla Postgres for storing.

The nice thing is that we now have a Kafka topic that contains all mutations that we can listen to. For example to send emails or handle other use cases.

For every table you: - create a serializable Kotlin data class - create a Postgres table on the server - implement reading and writing that data, and custom queries

Done: the apps have offline support for reading a single entity and upserts. Querying require to be online if not implemented on the client.