creesch

> I am mostly pushing back on the notion of dismissing software as low quality just because the author used LLMs.

Its not that hard to imagine that apps made with heavily LLM involvement suffer in quality. The article already goes into it a bit. I get the strong feeling that you are failing to approach this from anything else than your own perspective and how you use LLMs. Which, given the setup you are describing is already far from the norm.

Zooming out a bit further I think we can generally break up LLM usage in roughly two distinct ways of using LLMs. Or maybe more accurately there are two sides of a spectrum with a lot of area in between them:

1. Let LLMs do the majority of the heavy lifting and generate the output. Providing an LLM with some basic info, what you are looking for and let the LLM do most of the work for you. 2. Using LLMs as a tool external to the process where you are still doing most of the work.

The first way of using LLMs using agentic workflows, code harnesses, etc *can* produce good quality. As long as there is still a human in the mix who a) has the prerequisite knowledge to validate what the LLMs have generated b) takes their due diligence at key points in the process to actually make sure input is of high enough quality and validates the output.

You have decades of knowledge and experience you are now applying to rigidly structure how these LLMs work. Which, yes again, I believe gives you personally pretty good results, no doubt about that. But, many people do not have that experience to begin with. And even for those that do, using the first method comes with a risk that boils down to simple psychology, our minds are wired to take the easy approach wherever they can. Which turns the first way of using LLMS from a efficient way of using them to a lazy way of using them.

In my personal experience a lot of people who start using LLMs sort of drift to the lazy approach very easily. Because it is very convenient and easy to slowly hand over more thinking to an LLM. The latter I have seen happen all too often around me. An alarming increase of lazy non critical use of LLM tools by people who should know better. People who might have been a bit slower before but delivered excellent results now have started delivering trash. Code spanning dozens of line trying to solve something that should only take one line. Code that completely ignores and conventions or design paradigms put in place. Code that goes directly against security practices. Suddenly downgraded dependency versions (because the models training data doesn't include the latest version).

As I said, I see this as a spectrum and the more someone leans towards the first use case combined with "lazy usage" the more signs there will be in a repository that this is the case. The amount of commits, the release cadence and various other things. Which, again, the article also makes a case for and is again why your repository is irrelevant to the whole discussion. Why? Because your repository doesn't show these signs.

Cool, but I fail to see how it is relevant in the context of the article? You clearly have the knowledge, expertise and discipline to incorporate LLM in a workflow that, taking your word for it, delivers a very good result.

That makes you a) more unique than you realize b) not all that relevant in the context of the article.

a) Because a lot of people tend to lean towards use that absolutely leads to atrophying of skills and knowledge. b) well the article does explain the criteria it used fairly well and your project would not show up there. Well, also because your project isn't an android app.

> Do you suppose it's just that it's aping humans who say too much without saying anything

Considering how much of the input must me nonsense SEO bullshit articles and blogs that only serve to promote a person or company that might be a factor.

I also often have wondered if it is also targeting those same people. Certainly with tools like deep research options (not just Anthropic's offering) the result report seems to be aimed at management, aiming to look impressive while talking around the results.

> How does being docker compose based make it inaccessible?

Because it requires people to also have knowledge about the ins and outs of docker and docker compose. If we are talking about web applications it is yet another layer that has been added over the years. It used to be that you could fairly easily host most things on a old fashioned lamp host (I am talking decades ago) and all you had to know was basic file transferring.

Of course, this was on shared webhosts in a time when VPSes were not really a thing yet or affordable. But, even on a VPS setting up a LAMP stack is relatively straightforward.

Once you add modern dockerized application to that mix you are now still looking at some sort of ingress to do the reverse proxy bit. So while it likely will not be Apache or nginx there will be some sort of layer there in addition to now having to setup docker properly (rootless and all that) and then also making sure your docker compose setup is in order.

It is not difficult *once you know how to* but it is another layer of knowledge and experience people need to acquire. That does make it less accessible for novices.

> a STEM field if they care enough and aren't the sort who are just doing the bare minimum to get the sheepskin.

That's the thing though, part of it is about caring. Part of it is being exposed to other things in order to realize there is more out there. I honestly think that STEM field education would benefit from including Liberal Art related courses exactly because of that. Basically as a way to broaden students world view and the way they might interact in it.

The same is probably true the other way around as well btw.

> CI run pulls from npm, PyPI, Docker Hub, a distro mirror and a handful of third-party, none under your control, none with an SLA to you.

To be honest, they shouldn't do so directly. For the obvious reason you stated, they don't have a SLA to you or your company. But also because it is a shitty thing to do as a company. Companies should have their own proxies and mirrors for any repository they pull from. Both to be in control of the dependencies you as a company rely on and to not unnecessarily put load on free third party repositories.

Had not heard of your solution. More often than not I come across Harbor, Nexus or things like GCPs internal stuff.

Different country probably, here QA is still often part of the team. More often than not as part of a team with a title like "test automation engineer".

> The missing part is the propulsion system capable of doing that.

That is a pretty big missing part. Not as big as the galaxy, but still huge.

> Def not rockets. OP said hundreds of years.

Yeah to reach it with current tech. No shifting goal posts, thank you very much.

> In hundreds of years from now our rulers will definitely have that kind of tech, whatever tech it is.

Also, I should point out that technological progress isn't linear and guaranteed. Also, "our rulers" what ...?

> I want to know what future technologies could accelerate an object to a significant fraction of the speed of light.

With all due respect, this has been extensively debated online and is extremely easy to look up.

> Could those breakthroughs be achieved in the next 2 or 3 centuries?

Any predictions on future scientific breakthroughs are wishful thinking. Even directions that seem promising at some point can end up being dead ends and we simply don't know what we will or will not achieve.

With current technologies, even hypothetical ones we can't get there in a time period that is under a few centuries at best and over a millennium at worse. Even for the centuries figure we'd require technologies we haven't been able to crack yet.

I mean, even there they pretty use the Astrophage as a plot device to fill in the huge gap in technology needed to cover those distances. They make it clear that they would have no chance to cover those distances without the Astrophage, but it is very convenient.

You are not wrong, but it still wouldn't make a whole lot of difference. First of all with any technology we currently have, including hypothetical proposals, we can't even get close to 1c. The best we can do, and this assumes purely hypothetical unproven ideas, is accelerate to a fraction of the speed of light. Acceleration itself will take up a significant amount of time and even then we are nowhere near the speed of light. Project Orion would in theory be able to do 3% to 10% of the speed of light. That's about the only proposed propulsion we actually have the technology for in the sense that we might be able to build it this decade.

So let's be optimistic and assume we can reach 10% of c (unlikely), that is 10 years for one light year, meaning that it takes about five centuries. Practically speaking 10% of c is unlikely, it takes about a month to accelerate to those speeds you'd need an insane amount of mass in the form of bombs to explode to just get up to speed. Which is why 3% is more "realistic". Oh, did I mention that there is no realistic way to slow down either? In theory it is just detonating the same amount of bombs in front of the craft, but in order to take that mass on your journey you'd need a lot more mass to get up to speed and the numbers get silly rather quickly.

So "realistically" at 3% of c we are talking about roughly 1500 years to just speed past our target.

Also, the original remark was about sending probes, not humans. But at 3% or 10% of c time dilation isn't much of a factor either so you'd need a generational craft if you want to send people.

Again, space is big, really big.

Just going to recycle this comment I made in reply to an almost identical comment as yours. I don't think you folks realize how big space actually is.

The speed of light is 1079 252 848 km/h, the fastest space craft ever made was the Parker Solar probe (using a sling shot) clocking in at 692 000 km/h. So at that speed it would take, 1559 years to travel one light year.

This planet sits at a distance of 48 light years, so it would 74 832 years to get there. Just for good measure, when it gets there it would also take 48 years for us to know that since radio travels at the speed of light.

Note, that the speed of the spacecraft I mentioned was the peak speed. Space is big, really big.