I built a very small personal extension for Pi [1] that gives me a /last command. It clears the entire session, only retaining the agent's last output message. This allows me to do manual "compaction". Basically I tell the agent something like "state the plan as discussed with references to files that should be edited", and call /last, then tell it to implement.
I find this a weird comment. Isn't this the same kind of out of touch? I could write:
> Kind of goes to show how out of touch and insular the Hackernews commenter sphere can be. Almost everyone I interact with in reality loves LLMs and their touted trajectory.
And it would hold mostly true for me. This goes to show we should all be aware of our respective bubbles.
I'm working on a toolkit for building "full-stack" libraries. I.e. libraries that bundle frontend hooks, backend routes, and a database schema into a single package.
On top of this I built a library for email that listens to Resend webhooks and stores the email (with thread information) directly in the user’s database. This is a more complete package than what Resend themselves could provide with their backend-only library.
I really hate the POST verb for RESTish APIs because it cannot be idempotent without implementing an idempotency layer. Other verbs are naturally idempotent. Has anyone tried foregoing POST routes entirely? Theoretically you can let the client generate an ID and have it request a PUT route to create new entities. This would give you a tiny amount of extra complexity on the client, but make the server simpler as a trade-off.
You could almost call the comparison between Clerk and Better Auth unfair. One is a service and one is a library, apples to oranges. Any third-party service integrated into a stack is a liability, libraries as well, but to a lesser degree. It’s about time for more services to be replaced by libraries. Better Auth really shows how to do that imo, it’s a library that integrates on the frontend, backend, and database. This is why it’s so good.
> Everyone learns many mathematical operations in school: fractions, roots, logarithms, and trigonometric functions (+, −, ×, /, sqrt, sin, cos, log, …), each with its own rules and a dedicated button on a scientific calculator. Higher mathematics reveals that many of these are redundant: for example, trigonometric ones reduce to the complex exponential. How far can this reduction go? We show that it goes all the way: a single operation, eml(x, y), replaces every one of them. A calculator with just two buttons, EML and the digit 1, can compute everything a full scientific calculator does. This is not a mere mathematical trick. Because one repeatable element suffices, mathematical expressions become uniform circuits, much like electronics built from identical transistors, opening new ways to encoding, evaluating, and discovering formulas across scientific computing.
Mounting S3 buckets seemed like a great way to make stateless applications stateful for a while, which sounds appealing, especially for agent-like workloads. Handling conflicts like this means you really have to approach the mounted bucket as separate stateful thing. Seems like a mismatch to me.
I've seen that agents can build real, working, Stripe integrations. But not necessarily correct ones. I've seen it do non-idempotent database operations in webhook handlers and also call Stripe APIs as a side-effect in synchronous flows.
Agents grind until the integration works in the happy path, but the devil is in the details as always.
I experimented with a command for atomic commits a while ago. It explicitly instructed the agent to review the diff and group related changes to produce a commit history where every HEAD state would work correctly. I tried to get it to use `git add -p`, but it never seemed to follow those instructions. Might be time for another go at this with a skill.
> You could take an editor session, a diff, or a pull request and automatically split it into a series of more focused commits that are easier for people to review. This is one of the cases where the AI can reduce human review labor
I feel this should be a bigger focus than it is. All the AI code review start up are mostly doing “hands off” code review. It’s just an agent reviewing everything.
Why not have an agent create a perfect “review plan” for human consumption? Split the review up in parts that can be individually (or independently) reviewed and then fixed by the coding agent. Have a proper ordering in files (GitHub shows files in a commit alphabetically, which is suboptimal), and hide boring details like function implementations that can be easily unit tested.
The DSL described in this post really resonates with me. I recently worked on a programming language that uses similar structures [0]. It lets the user define entities and their shape (Role, OrganisationalUnit, Person in this post) and entries for those entities. It contains a small scripting API that can be used to derive information from these "facts". Company as code could definitely be implemented on top of this.
I’ve recently started using a similar process to what you’re describing. It basically involves writing/speaking to AI in an unstructured manner, and having it extract entries for my knowledge base based on a certain schema. I built a tool to validate the entries to the schema, giving the AI a feedback loop so it can automatically fix/improve the entries. It also supports linking. I use agentic search in both entering and finding knowledge. Links, categories and metadata help the AI tremendously in finding relevant snippets. I go into more detail in this blog post [0].
In this context you could say that CST -> AST is a normalization process. A CST might contain whitespace and comments, an AST almost certainly won't.
An example: in a CST `1 + 0x1 ` might be represented differently than `1 + 1`, but they could be equivalent in the AST. The same could be true for syntax sugar: `let [x,y] = arr;` and `let x = arr[0]; let y = arr[1];` could be the same after AST normalization.
You can see why having just the AST might not be enough for syntax highlighting.
As a side project I've been working on a simple programming language, where I use tree-sitter for the CST, but first normalize it to an AST before I do semantic analysis such as verifying references.
To be honest, it’s probably the worst 6k monitor out there, but I’m still enjoying it. I got it basically before any reviews were out and I initially thought I had a defective model. The matte coating is pretty bad, and the screen being darker near the edges is also very noticeable when you look for it. It’s also 60hz which is pretty disappointing.
With all that said, I would still recommend it over anything not retina.
Totally agree. I’ve been using the Asus ProArt PA32QCV (6k monitor) for the past few months, and it has been great for coding. It’s about 220 PPI, or what Apple calls “retina”.
[1] https://pi.dev/