I have been using it since it got released and its as good for scoped coding tasks, as the other big models I use, but just soo much cheaper.

This isnt a hype board, for consumer products. Its supposed to be a tech first community.

This is purely anecdotal, but I find that the buildings with professional management and purely renting tenants, look better and seem more well kept, compared to the smaller "Andelsforeninger" where its a volunteer management team trying to run it.

https://da.m.wikipedia.org/wiki/Andelsboligforening

The issue with them is that the loans to build the properties are socialised, so if the other members can not pay the debt, the entire loan is the responsibility of those members who can.

Also, the incentives of a cheaper than market rate flat, means that corruption and nepotism is rampant in those buildings.

It is not pretty in practice.

All those details can go in the docs / faqs section.

Spend any amount of time, reading the implementation of powerfull algorithms (A* search, Bubble sort), and you will realize that the power is in the idea, not the feeble attempt at coding it in PHP, Go, JS or what ever.

I think the original author is on to something, about how the structure of our codebases will change, and therefore our preferred frameworks will change as well.

The frameworks we use today, assume that the codebase is DRY[1], and that a human will verify the workings of the codebase. A human will write a single test, for a single component and verify that the test functions correctly - then leave it in there, for successive runs to prove there has been no regression to the code quality.

But as the author points out - that doesn't lend itself to truly parallel programming. Because as one programmer/agent changes a central component that another programmer/agent also changed in the same release cycle, merge conflicts arise and grown into architectural conflicts and grow into team conflicts.

I see how accepting more duplication, can lead to more parallelization. I mostly cared about keeping code DRY because its hell to refactor a codebase with 5 implementations of the same thing. But if I am just instructing an LLM to make the change, I dont care how many files it has to visit - its still the same single instruction from me.

So I will think long and hard about how tooling needs to improve, and how frameworks need to change, to be part of this new paradigm. Similar to how Object Oriented Programming optimised for human logic rather than cpu cycles, the time of LLMs will optimise for testability and parallelisation rather than gpu cycles, or DRY paradigmes.

1. https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

The first steam engines were too expensive and underpowered, the first cars were deatch traps when they actually ran. Dont lul yourself into the dream of a static world.

We see the wave coming, I will look for a way to surf it. Don't be the stunned sceptic waiting to feel the crush.

Let me know if you are interested in turning this into a startup, happy to direct you to some relevant people.

VC money and accelerators are primarily for people who dont have the wealth to bootstrap, but who are young and willing to take investors on early.