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.
55 karma · joined February 11, 2011
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.
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.
If you'd like to get some scandi guys on your show, I am a GP at www.likeminded.vc, and connected into the community around Copenhagen and the nordics.
It triggered my entrepreneurial journey as a kid, and one of the first "open world" experiences I had from games. I would spend weeks trying to figure out what the right strategy was for a specific map.
In many ways, an entrepreneur and VC today, I am still playing that same game, and as the technological landscapes changes, so do the strategies I get to dream up.
I do believe most engineers experience this maturing when they get access to leverage in the workplace, such as going from being an individual contributor to a leader or mentor.
Try sales for a while, and you will realise that no customer has a neatly defined problem for you to solve. They have real complex problems, which you may be able to shoehorn your general solution into. But even then, there is always an alternative solution for the customer which may be simpler or cheaper, such as just hiring an intern to do the job your software can do.
There is no need to drag a large set of people through a funnel that only eliminates them at the very end on the hard requirements.
I built Trovinto.com to generate technical questions and evaluate candidates answers on a quick questionnaire.
Save everyone's time, and when you know there is a fit on skills then I think you should spend even longer on the soft questions.
Getting a new job is a huge decision, not something that should be concluded in 3 hours over 2 interviews and a call.