The irony of this paper is that the part that isn't geographic (towns, roads, fields, etc) which have non-random ordered structure are the parts that are most suitable for this approach.
Mm. This paper makes it hard to understand what they've done.
For example:
> MultiDiffusion remains confined to bounded domains: all windows must lie within a fixed finite canvas, limiting its applicability to unbounded worlds or continuously streamed environments.
> We introduce InfiniteDiffusion, an extension of MultiDiffusion that lifts this constraint. By reformulating the sampling process to operate over an effectively infinite domain, InfiniteDiffusion supports seamless, consistent generation at scale.
…but:
> The hierarchy begins with a coarse planetary model, which generates the basic structure of the world from a rough, procedural or user-provided layout. The next stage is the core latent diffusion model, which transforms that structure into realistic 46km tiles in latent space. Finally, a consistency decoder expands these latents into a high-fidelity elevation map.
So, the novel thing here is slightly better seemless diffusion image gen.
…but, we generate using a heirsrchy based on a procedural layout.
So basocally, tldr: take perlin noise, resize it, and then image-2-image use it as a seed to generate detailed tiles?
People have already been doing this.
Its not novel.
The novel part here is making the detailed tiles slightly nicer.
Eh. :shrug:
The paper obfuscates this, quite annoyingly.
Its unclear to me why you cant just use multi diffusion for this, given your top level input is already bounded (eg. User input) and not infinite.
They built a system that can be trained on real-world data so it can output more real-world-like data. It's much more sophisticated than what you could hand-tune with Perlin noise and can have coherent terrain features across multiple scales which are harder to do in classical Perlin noise.
People posting stuff like this are clearly not doing it; they’re reading LinkedIn posts, toying with the tech and projecting what it looks like at scale.
That’s fair; but it’s also misguided.
Either try it yourself, or go and watch people (eg. @ArminRonacher) doing this at a reasonable scale and you can ground yourself in reality, instead of hype.
The tldr is: currently it doesn’t scale.
Not personally. Not at Microsoft. Not at $AI company.
Currently, as the “don’t change existing behaviour” constraint list goes up, the unsupervised agent capability goes down, and since most companies / individual devs don’t appreciate “help” that does something while breaking something else, this causes a significant hole in the “everyone can 10x” bed time story.
As mentioned in other threads; the cost and effort to produce new code is down, but the cost of producing usable code is, I guess, moderately on par with existing scaffolding tools.
Some domains where the constraints are more relaxed like image generation (no hands? Who cares?) and front end code (wrong styles? Not consistent? Who cares?) are genuinely experiencing a revolution like the OP was talking about.
…but generalising it to “all coding” appears to be like the self driving car problem.
Solvable? Probably.
…but a bit harder than people who don’t understands or haven’t tried to solve it themselves thought, or blogged about or speculated about.
Probably, there’s a much smaller set of problems that are much easier to solve… but it’s not happening in 2026; certainly not at the scale and rate the OP was describing.
You’ll notice, neither of us have self driving cars yet.
(Despite some companies providing cars that do drive themselves into things from time to time, but that’s always “user error” as I understand it…)
> And most importantly, you modify the work just like the creators modify the work
Emphasis mine.
Weights are not open source.
You can define terms to mean whatever you want, but fundametally if you cannot modify the “output” the way the original creators could, its not in the spirit of open source.
Isnt that literally what you said?
How can you possibly claim both that a) you can modify it the creators did, b) thats all you need to be open source, but…
Also c) the categorically incorrect assertion that the weights allow you to do this?
Whatever, I guess, but your argument is logically wrong, and philosophically flawed.
If they are released under an open source license, they are.
I think you are confusing two concepts. One is the technical ability to modify weights. And that's what the license grants you. The right to modify. The second is the "know-how" on how to modify the weights. That is not something that a license has ever granted you.
Let me put it this way:
```python
THRESHOLD = 0.73214
if input() < THRESHOLD:
print ("low")
else:
print ("high")
```
If I release that piece of code under Apache 2.0, you have the right to study it, modify it and release it as you see fit. But you can not have the right (at least the license doesn't deal with that) to know how I reached that threshold value. And me not telling you does not in any way invalidate the license being Apache 2.0. That's simply not something that licenses do.
In LLMs the source is a collection of architecture (when and how to apply the "ifs"), inference code (how to optimise the computation of the "ifs") and hardcoded values (weights). You are being granted a license to run, study, modify and release those hardcoded values. You do not, never had, never will in the scope of a license, get the right to know how those hardcoded values were reached. The process by which those values were found can be anything from "dreamt up" to "found via ML". The fact that you don't know how those values were derived does not in any way preclude you from exercising the rights under the license.
You are fundamentally conflating releasing a binary under an open source license with the software being open source. Nobody is saying that they're violating the license of Apache2 by not releasing the training data. What people are objecting to is that calling this release "open source", when the only thing covered by the open source license is the weights, to be an abuse of the meaning of "Open Source".
To give you an example: I can release a binary (without sources) under the MIT - an open source license. That will give you the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of said binary. In doing so, I would have released the binary under an open source license. However, most people would agree that the software would not be open source under the conventional definition, as the sources would not be published. While people could modify it by disassembling it and modifying it, there is a general understanding that Open Source requires distributing the _sources_.
This is very similar to what is being done here. They're releasing the weights under an open source license - but the overall software is not open source.
If you speak fluent japanese, and you dont practice, you will remember being fluent but no longer actually be able to speak fluently.
Its true for many things; writing code is not like riding a bike.
You cant not write code for a year and then come back at the same skill level.
Using an agent is not writing code; but using an agent effectively requires that you have the skill of writing code.
So, after using a tool that automatically writes code for you, that you probably give some superficial review to, you will find, over time, that you are worse at coding.
You can sigh and shake your head and stamp your feet and disagree, but its flat out a fact of life:
If you dont practice, you lose skill.
I, personally found, this happening, so I now do 50/50 time: 1 week with AI, 1 week with strictly no AI.
If the no AI week “feels hard” then I extend it for another week, to make sure I retain the skills I feel I should have.
Anecdotally, here at $corp, I see people struggling because they are offloading the “make an initial plan to do x that I can review” step too much, and losing the ability to plan software effectively.
Dont be that guy.
If you offload all your responsibilities to an agent and sit playing with your phone, you are making yourself entirely replacable.
Not saying Supabase is bad at all at what it does and I am very glad that it exists as an open source project, but they don't target the same type of project complexity at all.
Self-hosted Supabase is pretty good. I don't think anyone argues with that. It didn't used to be as smooth and it's certainly hungrier with many more moving parts.
Could you elaborate a bit more on your scaling concerns? You can certainly have lock-congestion with SQLite. That, said Postgres - while awesome - isn't the most horizontally scalable beast.
When you can afford to have good things, and you're not, don't come crying about getting called bad names.
Actions is bad.
> I dare anyone who is delusional enough to think they can create something better to actually make something better
Actions speak louder than words.
Zig is leaving because of the issues they mentioned.
> People tried other services like GitLab and realized it is slower, uglier and overall worse than GH and came crawling back.
Maybe. I guess we'll see.
I think the OP has been pretty clear that they're not happy with it, and, they're putting their money where their mouth is.
Clearly, just complaining about broken things isn't working.
Maybe a couple more big moves like this is what GH needs to wake up and allocate some more resources (that they, can categorically afford) to fixing things.
So who is complaining that Zig leaving GH is somehow a problem? I just don't like how they have to put out false claims like there are big problems with GH CI and Sponsors.
Zig is leaving GH for another provider. They did not make a better GH and fixed all the problems with it.
You literally have to fill out a form to convince Codeberg that you need CI. I would take GH CI over that.
> Microsoft can afford to make these tools better; they just dont care.
They certainly have enough money, but can they actually improve it? Who could step in? How? Do you think more hiring would help? Or would it make it worse?
Leadership could try and step in by force. But they'd have to undermine whoever is running github actions to do so. It would be a huge, risky political move. And for what? Are they actually losing customers over gh actions? I doubt it. I'm just not sure anyone cares to spend that much political capital to "fix" something that is arguably not that broken.
Big companies also simply can't fix stuff that's broken internally. Its not a money thing. Its a culture & politics thing. Its a leadership thing.
For example, does anyone remember Google Code? It was a github-like code hosting service that predated github by many years. Compared to github, it was terrible. When github came out, google could have rewritten Code from the ground up to copy github's better design and better choices. (Kind of like android did with ios). But they didn't. Github kicked their butt for many years. But nothing happened. They couldn't fix it. Now google code is basically dead.
Or why didn't Adobe build a viable figma competitor? Why didn't microsoft make a successful iphone or ipad competitor? Why didn't intel win the contract to make the iphone CPU? These aren't money problems. Its something else.
I've only heard stories of a couple leaders who had the force of personality to fix problems like this. Like Steve Jobs. And Elon Musk pulls some wild stunts too. Frankly, I don't think I'd like to work under either of them.
Github has been entirely integrated into Microsoft's AI division since the last Github CEO left a couple of months ago (not much of a loss since he was responsible for Githubs AI enshittifaction). Those org-changes alone are plenty of reason to lose trust in Github's future. IMHO things can only get worse with an "AI first" division in charge and now is probably the best time to jump ship, at least it's the responsible thing to do for sufficiently large and professional projects (and I bet that ziglang is only one of many to follow).
> But they'd have to undermine whoever is running github actions
I'm not sure if anybody is running the GH Actions project at the moment beyond bare maintenance work and trying to keep the whole thing from collapsing into a pile of rubble. There is also no separate Github entity anymore within Microsoft, so nothing to "undermine".
> I never really understood why you have to stuff all the tools in the context.
You probably don't for... like, trivial cases?
...but, tool use is the most fine grained point, usually, in an agent's step-by-step implementation plan; So when planning, if you don't know what tool definitions exist, an agent might end up solving a problem naively step-by-step using primitive operations, when a single tool already exists that does that, or does part of it.
Like, it's not quite as simple as "Hey, do X"
It's more like: "Hey, make a plan to do X. When you're planning, first fetch a big list of the tools that seem vaguely related to the task and make a step-by-step plan keeping in mind the tools available to you"
...and then, for each step in the plan, you can do a tool search to find the best tool for x, then invoke it.
Without a top level context of the tools, or tool categories, I think you'll end up in some dead-ends with agents trying to use very low level tools to do high level tasks and just spinning.
The higher level your tool definitions are, the worse the problem is.
I've found this is the case even now with MCP, where sometimes you have to explicitly tell an agent to use particular tools, not to try to re-invent stuff or use bash commands.
reply