My "favorite" aspect of the Slack web app, which might have been fixed, as I haven't seen it recently, is if you typed up -> r (I believe it's r) to open the emoji picker, typed a few characters (e.g. "eyes") and pressed enter. Well, if the emojis hadn't loaded by then (and apparently they're loaded fresh every time), they would pop in and often, the a different emoji would be picked than the one that was visibly highlighted when I pressed enter.
"For AI agents". I understand why everything needs to be marketed in this way, but it's just ... an easy-to-generate language for expressing charts. That's impressive! That's useful.
This can’t be said enough. “Good for Agents” just means self-documenting, obvious ergonomics, save defaults, succinct (or controllable) output, programable interfaces, … all of which support human users too!
anything more than their own handpicked examples and you're better off using d3 or yfiles. layering, clustering, boundaries, rearranging are all basic needs for text to diagrams. None support it.
Both suck at being any good for rendering diagrams from readable structured text. There is a gap to be addressed.
yes and that led me to a more fundamental question : is it even possible for an easy way to do fine grained adjustments. The finer granularity brings complexity. that makes it unreadable (especially for the untrained) and hence set aside and forgotten. The other way is to narrow down and focus on a well defined subset of problems.
either way the number of people willing or compelled to learn it will be tiny. and it hence becomes a niche, perfect for a long-term side project but with no real return.
my conclusion was to stop looking and use D3 or custom code ( good looking charts for humans).
this project is trying to do the same, balance verbosity in text with granularity in the charts with a narrowish usecase : agent consumption.
That's the best option for now. But it can also be frustrating to ask AI to do small edits on D3 just to fix some idioms (like switching order etc) and they kept messing up with other stuff accidentally. Thus I still believe have a language with native representation for these diagram concepts would be helpful.
Good news is that AI do make new language a bit more accessible than before! If your agents can use it well and you can steer easily, it will naturally be good adoption.
Why can’t AIs generate for the “existing, mature ones?” Like the other commenter said, I’m not sure I get the “this is totally for AI” marketing. Why can’t AI use the existing ones and why can’t humans use this?
the design here has some constructs (i.e., semantic types) that AI can use better than human at generation time; and then the generated spec can be easy for user to edit since there is no need for hard-coded low-level parameters!
Thank you for summarizing it this way. All their flowery language (esp from OP) seems like long for "we figure out how the chart should look based on its data". From their page:
> Instead of requiring verbose low-level parameters such as scales, axes, spacing, and layout, the Flint compiler derives optimized chart settings from the data, semantic types, chart type, and encodings.
I work with someone who did a lot of work with this to improve our ability to generate awesome visualizations with little thinking. It's a very powerful language but needs guardrails and guidance, particularly if you want end users to be able to produce consistent and standardized visualizations without knowing anything about it.
I'll add another use case for letting an AI go ham: many small, atomic refactors where the name of the game is never breaking anything.
My personal OSS projects don't have the scale to necessarily make this worth it, but at work I run three pipelines using Barnum (https://barnum-circus.github.io/). First, one that ingests files, identifies refactors (from a pre-approved list), and places a precise description of the refactor to be done in a queue; second, one that reads from said queue, implements and creates PRs (there is a lot of "check that the PR is correct" here as well); and a third that babysits PRs until they land. I've landed hundreds of PRs in this way, with very little effort on my part.
It's amazing at reverse, see what they do on GTA San Andreas now, they started the reverse before AI existed, since AI is in their hands, reversed sped up so much that they can finally understand the game deeper, create bigger mods, added Vice City inside the game in an Arcade, they created specific tools made with AI to convert GTA 5 models to GTA SA. Pretty crazy and great.
Speculating here, but perhaps your coworker was too ambitious? In my opinion, you should start with AI-generated PRs that do small, linting refactors and then work up from there. In particular, if this is done in parts, one of the strategies you can employ is to:
- add tests
- break files up into smaller parts
- test the smaller parts
- then actually improve behavior
(Which is no different than what you would do as a human)
It's not worth bothering with unless the task is very difficult, long-context, long-running, or all of the above. But, when it's worth using, it genuinely increases success rates and appears to amplify model intelligence.
Pleading has worked for me. “My job depends on this, please help me” and ChatGPT would do a task it previously claimed it wasn’t able to (extract text from an image, it claimed it couldn’t make it out at first)
Asking LLMs to do things in different ways does sometimes get them to answer correctly when they didn't with a previous prompt that is effectively equivalent but people really go nuts anthropomorphizing this behavior.
ChatGPT has no empathy for you keeping your job, you just lucked into a more helpful predictive text chain based on some combination of the input and the random temperature.
Asking it to just 'try again, dummy' could have worked equally well (or not, its all just probabilities after all).
I did too, but then added something very similar to a prompt ("must be accurate") for an ai-backed feature out of frustration, and sure enough it fixed the issue. Lord have mercy
Real AI enthusiasts know that money will soon be superfluous, so they wouldn’t bother with such pettiness. So gauche. But if you must know how to really do that, just put “Correct answers only pls. Seriously, no hallucinating fr fr” in your system prompt and it feels so bad about the possibility of giving you misleading info that it gives you perfect responses.
One of the best things you can do is start by having it do unit test coverage for existing behavior. A refactor with no tests breaks things pretty much no matter who does it, because they don't know what the right behavior is.
While I could generally agree, in this specific instance if the AI were “thinking” correctly it should have found the mistake. I admit it was a difficult problem though (solving it required creativity).
To be more precise, the prompt actually pointed to where there could be issues, and the issue, which was exactly of the kind that was pointed at, was not found.
There are a lot of factors in "should have found" which my recommendation improves.
If you told it to write unit test coverage, you would have covered more of the codebase. That reduces the size of context necessary for the next mistake finding investigation - it'll see it's already covered a lot of the paths. Then you say "Go look for issues" (or whatever you asked it to do) and it'll be able to think more deeply about what's left over.
What specific model were you using, at what effort? How big was your context window?
My experience with Gemini and Sonnet are that refactors or TypeScript compilation errors can be solved by “have at it”, but with mixed results. Many TS issues go away with `as any/never`, and instructing the model to not do that doesn’t work very well.
Folks that are interested in a way of doing work locally that doesn't suck, but which integrates LLMs, may be interested in [Barnum](https://barnum-circus.github.io/). The TLDR is that it's a programming language whose frontend is a DSL in TypeScript that is well suited for managing async and parallel work, focused on control flow, from which it is easy to invoke LLMs, and which is easy for LLMs to write. I use it to autonomously ship a very large number of PRs.
That's exactly the tradeoff I made with Barnum (https://barnum-circus.github.io/). It's just not important to optimize the performance of the rust side for the reason you stated. So instead, all focus goes into making it easy for an LLM to build a reliable pipeline (from which LLMs are invoked).
Hey folks! This talk is about GraphQL in a world of fullstack, rich clients and about Isograph. The question it asks is: does GraphQL need to exist? Can we get its benefits without a GraphQL schema, without a GraphQL server, and without sending GraphQL over the wire?
It's my opinion that Isograph gives us the benefit of GraphQL, without many of its limitations. Which is to say, if you start from scratch, you can avoid mistakes.
This describes a future iteration of Isograph. Currently, much of what's described here is on the roadmap. But it's coming!
You may want to check out Barnum, which is a programming language/agent orchestration tool that makes it easy to build things like /loop, or Claude code routines. And you won't end up dependent on the specifics of how Claude code routines work!
You can lessen your dependence on the specific details of how /loop, code routines, etc. work by asking the LLM to do simpler tasks, and instead, having a proper workflow engine be in charge of the workflow aspects.
For example, this demo (https://github.com/barnum-circus/barnum/tree/master/demos/co...) converts a folder of files from JS to TS. It's something an LLM could (probably) do a decent job of, but 1. not necessarily reliably, and 2. you can write a much more complicated workflow (e.g. retry logic, timeout logic, adding additional checks like "don't use as casts", etc), 3. you can be much more token efficient, and 4. you can be LLM agnostic.
So, IMO, in the presence of tools like that, you shouldn't bother using /loop, code routines, etc.
One thing my team lead is working on is using Claude to 'generate' integration tests/add new tests to e2e runs.
Straight up asking Claude to run the tests, or to generate a test, could result in potential inconsistencies between runs or between tests, between models, and so on, so instead he created a tool which defines a test, inputs and outputs and some details. Now we have a system where we have a directory full of markdown files describing a test suite, parameters, test cases, error cases, etc., and Claude generates the usage of the tool instead.
This means that whatever variation Claude, or any other LLM, might have run-to-run or drift over time, it all still has to be funneled through a strictly defined filter to ensure we're doing the same things the same way over time.
I'm looking at implementing https://github.com/coleam00/Archon as a means to solve this. You can build arbitrary workflows custom to your codebase. Looks to bring a bit of much-needed determinism.
>You can lessen your dependence on the specific details of how /loop, code routines, etc. work by asking the LLM to do simpler tasks, and instead, having a proper workflow engine be in charge of the workflow aspects.
"You can lessen your dependence on a specific LLM implementation by not using LLMs" is certainly a take but it doesn't really address the root issue of models getting nerfed to save resources after they've gained wide adoption.
A simple task ("convert this file from JS to TS, here are the types of all imported things") is much more likely to continue to work with a nerfed model compared to a complicated task ("convert this repo to TS, make sure to run tsc afterward and fix all errors"). The former is a subtask of the latter!
Taking a moment to create a workflow where these steps are separated (or rather, having an LLM build this workflow) and the LLMs are asked to just do minor leaf tasks increases your resilience to nerfed models.
I'm as nerdy as they come (my current project is the fourth compiler I've worked on), and I absolutely love this new way of working. There's a lot more time spent in discussion with the agent (an extremely frustrating discussion, to be fair). All of a sudden, there's an extremely high payoff to investing in good fundamentals (namely, clarity of requirements, good tools, etc.), which are the things I want to invest in anyway! If you get these fundamentals right, you can let the agent rip and produce hundreds of PRs that are correct, or create workflows that are actually not slop or ship code that is, while not yet as high quality as if you wrote it manually, quite close, at easily five times the speed.
And throughout this, if I'm ever curious about how the ideas relate to some other topic, I can just ask the agent, "Are we designing XYZ right now? Categorically, is it this?" Lots of really cool discussions to be had.
I might be less enthusiastic if I was just shipping CSS changes and the like.
