aszen

Can you elaborate on this?

I don't think so, model improvements far outweigh any harness or tooling.

Look at https://github.com/SWE-agent/mini-swe-agent for proof

A custom ERP solution won't work because of audits, you need standard solutions at large scale. That's why even Google uses oracles ERP

How about you try vibe coding a banking app or tax filing or pay roll app?

Most commercial software is nowadays integrated into the real world in ways that can't be replicated by code alone, software which isn't like this can be easily replaced yes, but that kind of software already had free alternatives.

That's useful for mail, but there's so many other google apps

Seems useful. But what I really want is a way to merge google accounts, over the course of history I created 3 of them and would really prefer just a single one

Some of the risk outlined here are real for SaaS businesses that rely on user licenses. Automation, APIs and AI are going to reduce the no of people needed which means businesses buying less licenses overall. That's why smarter SaaS solutions are moving towards pay per usage.

This is inevitable, you can't rely on user licenses as a growth metric

No its different, php already has a good package manager, this is about formatting, linting and type checking

I haven't read the full paper yet, but my intuition is that hallucinations are a byproduct of models having too much information that needs to be compressed for generalizing.

We already know that larger models hallucinate less since they can store more information, are there any smaller models which hallucinate less

Main point is that the url is store in browser history and is never private.

Yeah exactly we were using fpdf heavily but now switched to Typst since its faster to iterate complex documents on.

Not yet, but it's evolving nicely, the original team moved to meta and they are building interesting open source stuff

It doesn't replace vector db, it's more for storing agentic memory, think of information which you would like agents to remember across conversations with users just like humans

Interesting idea, I like the fact that it doesn't use embeddings, and going into historical memory is an extra step that doesn't impact the speed of resolving the current information

I'll give you one simple reason, APIs designed for machines are not suitable for LLMs to use consistently.

Llms need a carefully designed interface which exposes tools at the intent level, most APIs are too low level for llms to perform user actions in a single call.

I like the idea of a semantic Layer but don't think defining it in yaml is the right way to go about it.

Semantic Layer needs proper language and tooling support which Malloy provides.

No, it's more than that.

Semantic Layer is about decomposing views into dimensions and aggregates, then letting downstream apps/users compose their own views on top without having to redefine/re-calculate business level metrics.

This makes data analyis more flexible than sql views which are hardcoded on particular groupings.

Then that file is posted to the backend for persistence

From what I understood the html file itself is updated so it's updating forms, attributes and other tags to include the new changes

We are just starting to introduce AI and for now rely on simple evals as unit tests that Dev's run locally to fine tune prompts and context.

Your idea of simulating agent interactions is interesting, but I want to know how are you actually evaluating simulation runs?

One of the biggest problems with mixing client and server code like this together is coupling which is one of the reasons that client-server architecture was created to avoid.

I watched the video, and it didn't feel compelling honestly, backend frameworks like symfony have ways to compose client and server side code for years.

There are many ways to mix and match client(js) and server (php) in a composable way without react. Components can be created on the server side as well (mixing html+js+php). Only thing lacking is DX and type checking.

Lot of jargon and nothing new in terms of ideas. Again testing nothing but fakes and trivial interactions.

Here's my opinion test your code with all its side effects and infrastructure.

To do that fast and deterministically, switch to faster lighter weight versions of your production dependencies when running tests.

For example use SQLite or PgLite for databases, use in memory file system, use Mailpit for emailing etc.

Simulate your infrastructure dependencies, inject faults into them, test the real deal, SQL, file system semantics, protocols.

Don't leave the hard part of your testing to Q/A and users.

Traditional advice is to keep tests independent of each other, that's why the setup part gets repeated instead of being inherited from the parent tests. Independent tests can be run in parallel, dependent tests cannot be.

But I can see how this approach allows for parallelism as well, I especially like the fact that you only get one failure in case one of the steps fail

A similar open source column explorer is :

https://github.com/manzt/quak

See it's demo:

https://manzt.github.io/quak/?source=https://pub-2fc10ef6724...

I now use distrobox to run random binaries in a container. It's faster and convenient

No I'm referring to system level libs, that you need to install via your operating system package manager like `apt` for python packages that depend on them.

Everyone seems to praising uv in the comments, seems like no one read this article, it has its drawbacks, it can't install system level libraries and dependencies which many packages depend on.

Btw I'm also from kashmir, we should exchange contacts

Yes, see https://www.reportbro.com/