phil-martin

I don’t think it’s about what Anthropic does or doesn’t want us to use their tools for. They are in the business of selling compute via AI, the more people that use it the better.

This is about stopping future issues (real or perceived) that could lead to legislation curtailing usage of their tools.

I wasn't talking about latent space, I was talking about the literal text a person types into the text box in their favourite AI tool.

If the prompt is sufficiently short and often repeated, it just makes me wonder - what is cheaper for a provider over a given timespan? Cache a large enough set of responses and randomly return one of them, or generate it each time time?

This is so interesting! I would like to see the same experiment, but with these variations:

- All the comments removed (the blog post)

- Half the comments removed

- 10% of the comments replaced with slightly incorrect comments

- 10% of the comments replaced with very incorrect comments

- 10% of the comments replaced with slightly incorrect comments

- 90% of the comments removed, 10% remain but are very incorrect

And variations like that

Test to see where the inflection point is for correctness, token usage and other things

In addition to that from a LLM-as-a-service vendors point of view, for short prompts that 1000's of people are asking for each day, if it is cheaper to serve a response that is randomly selected from 1000 cached versions than to regenerate each time, particularly if it is for SVG pelicans, it would make sense to do it that way.

That is true, but use use a humans-as-llms equivalenceish, because they are taking that prompt, because each person is an individually trained llm.

Now within our GUI/TUI to the llm (which we all use now) could just add a couple of extra steps to simulate that diversity.

Are we making an image? If yes, and is this the first prompt in the convo? neat! List 5 elements that would make up this image. Now for each of those 5 elements, make a list of 10 possible choices. Now randomly select from each one. Now include those elements on top of the original prompt.

I got claude to generate 10 of these as a prompt transformation, and i think they would be suitably random to postpone the diversity collapse for a while.

I'm not pretending the problem goes away, but these kinds of creativity varying steps I think will become hidden steps in our LLM systems very soon.

The same thing happens when doing any group work in a classroom or workplace. One of the facilitators job is to add in randomness and guides to remind people to make different choices rather than the obvious ones.

Thanks for the explanation, appreciate it!

Sorry for asking for definitions - since Aethris is such a different architecture, I want to make sure we’re using the same language.

When you say “models they generate” do you mean the the nurbs representation, or the tessellated geometry for rendering?

On a related topic how does Aetheris perform when defining a screw thread? Or a nut thread?

Fascinating repo, thank you for making it!

I’m curious, what does this part mean?

“ Dangerous operations which may generate degenerate/sliver/zero-dimension geometries are instead blocked from materializing to 3D at a compiler level.”

How is that achieved, or rather what does that mean? What defines a sliver?

Maybe it’s not a developer at all, and a couple of open claws doing random app things…

I believe the article is written from a lisp point of view where it interactivity is inspecting and modifying the application itself while it is running. It’s assuming that the software has already been written with no existing concurrency issues, but when a person comes along and does something unexpected and rewrites pose of the application or in the example they gave, modifying a hash map, things break.

They used C as an example because under normal circumstances you compile a binary and don’t modify it at runtime.

I’m not doing to defend it to strongly though, I _think_ that is what they were getting at, but to be honest I found much of it confusing.

It is just zipped xml, but to do a search and replace while retaining document structure is very very complicated, and I’m struggling to think of how to combine sed and awk to achieve it.

I'm confused - it feels like orchestration tools or how to organise agents is one of the most frequently discussed topics?

When I posted this comment there were 4 posts on the front page about orchestration, and another 3 on the second page.

I think this is an excellent start!

I have a few questions/comments.

- the site said it would be worked on collaboratively, but I couldn't find a way to do that? I interpreted that to mean multiple people woroking on it together

- I would find this more valuable if it was less text editor and more interactive editor. If the goal is group consesus, expanding the tool so more people in the group could modify it would be good

- What is the reason for having default names like "SprintReady" instead of "Sprint ready" ?

- Zoom to all and zoom to selected wold be super useful in the flowchart view

- being able to rename/edit things in teh flowchart view would be great

- Having an AI embedded in the tool itself so you did't have to manually round trip and copy/paste with claude code would be super useful

- It might be worth trying moving the comments panel to the right hand side of the screen. Very similar to google docs, word and other document tools. Makes the visual chart front-and-center and makes the comments separate from the simulate step

It’s interesting eh, it’s a wonderfully straightforward tool to use, but it’s scary.

My theory is that those courses aren’t selling you on how to use obsidian, but are instead selling “how do I organise knowledge and information. Oh btw we’re using obsidian”

They aren’t marketed like that, but I think that is what they’re really doing

It’s like taking a course of office organisation. I mean filing cabinets are easy right, it’s just putting labels on folders and putting them places.

Except I would absolutely be terrible at that job and would pay nearly anything to be good at it.

I found all the themes interesting, but "the rigor has to go somewhere" and "the enterprise reality check" resonated.

I was thinking about how my build of software has changed in the past 25 years, and while it feels there's only been small shifts with a great increase in my general grumpiness at stack complexity, the reality is before AI there had been a huge shift in my day to day focus.

When I started out, writing and reviewing code with a focus on managing memory, performance optimisation, tackling crossplatform compatibility were significant chunks of each day. If you didn't do those things, it was unlikely you would be able to sell in the market, because your competitors were faster or better. Then computers got faster, you needed to think about those things less, and you could instead afford focus more on features and getting to market faster.

Those were distant concerns for most of the things I was working on around 2020. The concerns where instead overall system design, distributed systems concerns, and business processes. If you didn't do those things, your product couldn't compete with all those other ones that did those things well (i.e. multi user systems, scaling to thousands of concurrent users etc etc)

If the AI trajectory continues, code as we know it today will become like memory management or hand rolled assembly from the 1990's, just not something you think about anywhere near as much (right up until the point it becomes a problem). You just couldn't afford not to. The focus and rigor will be in how well have we captured and delivered on the business requirements, how well are we responding to changing requirements, how well are we integrating with other systems. There will be some people who will need work on the low level things things, but the majority of of the sector will be working on these bigger picture problems.

Yes, it will create big balls of spaghetti code, unmaintainable monorepos, and everything today we consider bad, messy and wrong. But when the cost of regenerating said code is drastically reduced, you get to focus instead really close to delivering on user requirements. The focus and rigor will shift to verification, i.e. making sure what we're selling does what it's supposed to. Which If we are honest with ourselves that is exactly what we've been trying to do forever, but we just couldn't afford to do it as well as we would have liked. And honestly it was because building things was more fun and more necessary than testing things. That started to shift 15 years ago, and really shift 5 years ago, and now I think its' about to shift even more.

One could argue much of this doesn't fit under the purview of software engineering, but I think it does. For me, software engineering was the process of capturing value and knowledge in a system that could run on a computer, that we did it using coding, and that many things required highly specialised skills was an implementation detail. It will shift in a way that building architecture did - moving away from the raw technical ability to draft plans, and instead be able to understand a customers requirements, understand the legislation that the buildings exist in, and be able to oversee the project to see it completed that it fits all those things.