This is obviously in an open source environment. You never needed to cajole them into fixing problems, you could just fix it yourself. That was always an option. That's literally the entire point of open source.
It seems like quite a tower of babel just waiting to happen.. All those libraries that once had thought go into tangled consequences of supporting new similar features and once had ways to identity for their security updates needed will all just be defective clones with 5%-95% compatibility for security exploits and support for integrations that are mostly right but a little hallucinated?
I think it's more likely that libraries will give way to specified interfaces. Good libraries that provide clean interfaces with a small surface area will be much less affected by thos compared to frameworks that like to be a part of everything you do.
The JavaScript ecosystem is a good demonstration of a platform that is encumbered with layers that can only ever perform the abilities provivded by the underlying platform while adding additional interfaces that, while easier for some to use, frequently provide a lot of functionality a program might not need.
Adding features as a superset of a specification allows compatibility between users of a base specification, failure to interoperate would require violating the base spec, and then they are just making a different thing.
Bugs are still bugs, whether a human or AI made them, or fixed them. Let's just address those as we find them.
That may be part of the issue. Perhaps LLMs are just causing people to reveal how much they consider a maintainer as providing a service for them. Maintainers don't work for you, they let you benefit from the service they perform.
That workload of maintaining a fork doesn't come from nowhere, it's just a workload someone else would have to do before the fork occured.
Given the supposed quality of top flight models there ought to be a lot more people forking open source projects, implementing missing features and releasing "xyz software that can do a and b".
I find that the core issues really revolve around the audience - getting it good enough that I can use it for my own purposes, where I know the bugs and issues and understand how to use it, on the specific hardware, is fabulous. Getting it from there to "anyone with relatively low technical knowledge beyond the ability to set up home assistant", and "compatible with all the various RPi/smallboard computers" is a pretty enormous amount of work. So I suspect we'll see a lot of "homemade" software that is definitely not salable, but is definitely valuable and useful for the individual.
I hope, over the long to medium term, that these sorts of things will converge in an "rising tide lifts all boats" way so that the ecosystem is healthier and more vibrant, but I worry that what we may see is a resurgence of shovelware.
I have already forked open source software to fix issues or enhance it via coding agents. I put it on github publicly, so other people can use it if they see it, but I don't announce it anywhere. I don't want to deal with user complaints any more than the current maintainers do. (I'm also not going to post my github profile here since it has my legal name and is trivially linked to my home address.)
This is an unethical take, and long-term and at scale, an unsustainable/impractical one. This kind of mindset results in tool fragmentation, erosion of trust, and ultimately worse quality in software.
Nobody actually understands what they're doing. When you're learning electronics, you first learn about the "lumped element model" which allows you to simplify Maxwell's equations. I think it is a mistake to think that solving problems with a programming language is "knowing how to do things" - at this point, we've already abstracted assembly language -> machine instructions -> logic gates and buses -> transistors and electronic storage -> lumped matter -> quantum mechanics -> ???? - so I simply don't buy the argument that things will suddenly fall apart by abstracting one level higher. The trick is to get this new level of abstraction to work predictably, which admittedly it isn't yet, but look how far it's come in a short couple of years.
This article first says that you give juniors well-defined projects and let them take a long time because the process is the product. Then goes on to lament the fact that they will no longer have to debug Python code, as if debugging python code is the point of it all. The thing that LLMs can't yet do is pick a high-level direction for a novel problem and iterate until the correct solution is reached. They absolutely can and do iterate until a solution is reached, but it's not necessarily correct. Previously, guiding the direction was the job of the professor. Now, in a smaller sense, the grad student needs to be guiding the direction and validating the details, rather than implementing the details with the professor guiding the direction. This is an improvement - everybody levels up.
I also disagree with the premise that the primary product of astrophysics is scientists. Like any advanced science it requires a lot of scientists to make the breakthroughs that trickle down into technology that improves everyday life, but those breakthroughs would be impossible otherwise. Gauss discovered the normal distribution while trying to understand the measurement error of his telescope. Without general relativity we would not have GPS or precision timekeeping. It uncovers the rules that will allow us to travel interplanetary. Understanding the composition and behavior of stars informs nuclear physics, reactor design, and solar panel design. The computation systems used by advanced science prototyped many commercial advances in computing (HPC, cluster computing, AI itself).
So not only are we developing the tools to improve our understanding of the universe faster, we're leveling everybody up. Students will take on the role of professors (badly, at first, but are professors good at first? probably not, they need time to learn under the guidance of other faculty). professors will take on the role of directors. Everybody's scope will widen because the tiny details will be handled by AI, but the big picture will still be in the domain of humans.
> as if debugging python code is the point of it all.
You have a good point, but I would argue that debugging itself is a foundational skill. Like imagine Sherlock Holmes being able to use any modern crime-fighting technology, and using it extensively. If Sherlock is not using his deductive reasoning, then he's not a 'detective'. He's just some schmuck who has a cool device to find the right/wrong person to arrest.
Debugging is "problem-solving" in a specific domain. Sure, if the problem is solved, then I guess that's the point of it all and you don't have to solve the problem. But we're all looking towards a world in which people have to solve problems, but their only problem-solving skill is trying to get an AI to find someone to arrest. We need more Sherlocks to use their minds to get to the bottom of things, not more idiot cops who arrest the wrong person because the AI told them to.
With AI, VR is even more promising. I have been working on a Gaussian splat renderer for the Quest 3, and by having Claude and ChatGPT read state-of-the-art papers, I have been able to build a training and rendering pipeline that is getting >50 fps for large indoor scenes on the Quest 3. I started with an (AI-driven) port of a desktop renderer, which got less than 1 fps, but I've integrated both training and rendering improvements from research and added a bunch of quality and performance improvements and now it's actually usable. Applying research papers to a novel product is something that used to take weeks or months of a person's time and can now be measured in minutes and hours (and tokens).
You might be interested in a new experimental 3D scene learning and rendering approach called Radiant foam [1], which is supposed to be better suited for GPUs that don't have hardware ray tracing acceleration.
Cool! I'll definitely check it out. The great thing about LLMs is I can probably have a trainer and renderer using this technology up and running for my platform in a day or two, OR I can just pick and choose parts that would work well for my implementation and merge them in.
Sorry if this is a basic question, but what's you workflow for feeding the papers into the LLM and getting the implementation done? The coding agents that I've used are not able to read PDFs, so I've been wondering how to do it.
this is actually a great question - I just extract the text with PyPDF, but did a brief search on the functionality I'd like to have (convert math equations to LaTeX, extract images, reformat in markdown, extract data from charts) and it looks like there are a couple of promising Python libs like Docling and Marker.. I should really improve this part of my workflow.
after looking into it for a little while, Docling and Marker work pretty well but are very slow. I haven't found anything else that extracts math suitably. It takes 10+ minutes per pdf, so I'm going to run it on a batch of these papers overnight and create my own little gaussian splatting RAG database. It's really too bad PDF is so terrible.
My understanding is that those models create gaussian splats from a text prompt, kinda like a 3d version of nano banana. I'm not doing that (yet), what I'm doing is creating splats from a set of photos - aka "splat training" and then rendering the splat as a static (working on dynamism) on the Quest headset. This is pretty well-worn territory with a lot of good implementations, but I have my own implementation of a trainer in C++/CUDA (originally based in SpeedySplat, which was written in Python, but now completely rewritten and not much of SpeedySplat is left) and renderer in C++/OpenXR for the Quest (originally based on a LLM-made port of 3DGS.cpp to OpenXR, but 100% rewritten now), and I can easily integrate techniques from research.
I bought a copy of Office this year to do my taxes with the excel1040.com template and Claude for Excel, and dropped my 1099s and stuff into the chat window and Claude just transferred the numbers to the correct cells and Excel did the calculations. It was super easy (also easy to check because my tax picture didn’t change much from last year). It got some things right that TurboTax always got wrong (like cost basis for ESPPs). The only part that was difficult was getting Claude to transfer the data to the IRS fillable PDFs - I probably spent longer iterating on that than it would have taken to copy-paste the data from Excel. Other than that, it worked great, highly recommend.
I write a lot of tech docs with AI so I can add some substance here. First of all, you do tell it what you’re writing about - you can give it reams of documentation on related systems, terminology, and source code. Stuff that would take you weeks to consume personally (but you probably know the gist of it from having read or skimmed it before). Let’s say you are writing a design doc for a new component. After all of this stuff describing the environment is in its context (you don’t have to type it all out, you can copy paste it, use an MCP to suck it in from a DB, read it from a file, etc), you describe at a high level what architecture choices and design constraints to make (for example, needs to be implemented with this database, this is our standard middleware, etc) and it will fill in blanks and spit out a design for you. Then you refine it - actually this component needs to work like that, unit testing strategy needs to be like this, and so on. Now give me the main modules, code stubs, suggest patterns to use, etc. continue to iterate - it will update the entire doc for you, make sure there are no dead or outdated references, etc. extremely powerful and useful.
My recollection is that this website says that a 50% score is bad when the expected value of random chance of picking the correct option among 3 is 1/3. A 50% average score means there is some signal there. If it was impossible to guess, the average score should be 33%
I think you need to look at the data before making assertions like this.
> People don't buy American cars
53% of cars sold in the US are assembled in the US versus 18% assembled in Mexico.
> things get more and more expensive. And not by a few percent, more like by 50% or more.
The total cost of manufacturing wages only account for 5-15% of the MSRP of a vehicle. So moving manufacturing from an expensive country to a cheap country only changes the price by maybe 10% due to the impact of wages.
They also wouldn't have tried using a holstered weapon as pretense for a public execution which the president doubled down on, until he didn't. They wouldn't be treading on state's rights so openly either. We might be seeing parties flipping, in very short order.
If the Dems pick up on some of the issues the Republicans are neglecting, while maintaining principles* about healthcare access and reproductive rights I expect they'd be the dominant political force in America for some time...if they just had somebody who could man the helm.
Honestly, having spent a lot of time in Korea (which famously grew so much rice that visitors from Japan and China from the 16th century were astounded by their bounty of food), I disagree with the premise..
Queueing discipline is non-existent; people will take what they want without waiting for others who arrived first. Business standards for fair dealing are just as bad if not worse than many western societies. Family/personal connections are favored and nepotism is rampant. Driving behavior is extremely selfish and causes a lot of accidents (running red lights, default behavior at uncontrolled intersections, etc). Their problems with concentration of money and power are just as bad if not worse than the west with chaebols essentially above the law and abusing their workers to the extent that people have no time for families - so What makes Asian societies more “cooperative?” Is it just their attitude that they think they are more cooperative?
There might be 2 types: passive cooperative and active cooperative. Eastern Asian are likely more obedient. They behave better collectively under good leadership.
But they are not good at self-organized activities. Without an authority they are more chaotic.
Statistic features of populations are less understood not only because of lack of scientific method but also it's a taboo. However, there are some consensus among the elites within the populations but can not speak aloud.
reply