You misunderstand how clearance works. Any one can get "read-on" to anything with the proper authorities giving them access.
It is an administrative step. It might undergo review but access does not need to be prevent until the review happens. It is all about who is granting the access.
The commander in chief has considerable authority to provide access.
Have there been any declarations by various AI companies (e.g. OpenAI, Anthropic, Perplexity) that they are actually relying upon these llms.txt files?
Is there any evidence that the presence of the llms.txt files will lead to increased inclusion in LLM responses?
Indeed. Which would seem to indicate that positive growth along the Kardashev scale will lead to hypertrophy not atrophy, as conjectured by the OP. One could hypothesize that growing control of energy is highly correlated with the ability to empower a population to increase in muscle mass. Of course, history would seem to indicate that there can also be a correlation to increased obesity.
Agreed, there is an economic factor here but I would see that is highly correlated with the Kardashev grade of a civilization. The conjecture of the OP is that higher Kardashev grade will result in higher atrophy. My claim is that we seem to find precisely the opposite to be true.
I'm not making a counter-argument to the OP's position. I'm only making a refutation of the conjecture.
No, I do mean precisely the average muscle mass is higher. Granted we are dealing with statistics. There is inevitably a lot more context than just a myopic focus on this single fact.
This is particular relevant in the military because your fitness level is graded relative to you BMI. Hence, it is common trope one hears in the military. It is a practical question in the military. If the BMI is based on 1950's pilots and today's soldiers have a higher average BMI, then it can have an impact on promotions, fitness scores, health assessments, etc.
Agreed, I was debating whether or not this was relevant to mention.
What I could have added was a caveat that sample non-obese people from each time would indicate that 2024 people have greater average muscle mass.
Personally, a more interesting question is whether growth along the Kardashev scale leads to a greater disparity in muscle mass vs body fat. The past 100 years would seem to indicate that it is possible. That being said, it could also be a uniquely American phenomenon. My hypothesis would be that avg muscle mass among French men has still grown over the past 100 years but I don't think obesity has grown to the extreme that it has in the USA.
A castle built on sand. The only way to take the premise of this claim seriously is to ignore data for the past 100 years.
When I was in the US military, we all complained about the Body Mass Index standards. They were based on the WWII era "normal". Men were smaller. Less muscle mass. Shorter. If the average fit American young man tried to fit into a pilot's cockpit from the 1950's, it would feel quite cramped. Like it was built for much small people. It was.
We have certainly climbed the Kardashev scale since the 1950's. To what degree is a matter of contention. But, all would agree that we have moved up the scale.
Muscle atrophy has not been correlated with the growth. The opposite seems true. The average American, both male and female, has more muscle mass than in 1924. A 2024 person spends significantly more time on average in a gym pushing their muscles to hypertrophy than in 1924.
In addition, it is likely that the romantic picture of the average laborer "bodybuilding" is fictive and ignores how muscle atrophy and hypertrophy works. Most laborers are NOT doing activity that leads to hypertrophy. They are staying well within cardiovascular zones of muscle activation. Hence, bodybuilders as we know them are largely a modern phenomenon. And they are certainly WAY more muscular.
Seems the model that underlies this claim is built on seemingly demonstrably false premises.
The hype of Agentic AI is to LLMs what an MBA is to business. Overcomplicating something with language that is pretty common sense.
I've implement countless LLM based "agentic" workflows over the past year. They are simple. It is a series of prompts that maintain state with a targeted output.
The common association with "a floating R2D2" is not helpful.
They are not magic.
The core elements I'm seeing so far are:
the prompt(s), a capacity for passing in context, a structure for defining how to move through the prompts, integrating the context into prompts, bridging the non-deterministic -> deterministic divide and callbacks or what-to-do-next
The closest analogy that I find helpful is lambda functions.
What makes them "feel" more complicated is the non-deterministic bits. But, in the end, it is text going in and text coming out.
Yes, very good point. I would argue that what I’m suggesting is particularly well suited to startups. It may be relevant to larger companies as well but I think the politics and risk profile of larger companies makes this nearly impossible to implement.
The challenge is that you actually want your entire team to benefit from the feedback. The 4 of you are going to benefit IMMENSELY from directly experiencing every single pain point- together.
As developers we like to focus. But there is vast difference between "manager time" and "builder time" and what you are experiencing.
You are creating immense value with every single customer interaction!
CUSTOMER FACING FIXES ARE NOT 'MANAGER TIME'!!!!!!
They are builder time!!!!
The only reason I'm insisting is because I've lived through it before and made every mistake in the book...it was painful scaling an engineering and product team to >200 people the first time I did it. I made so many mistakes. But at 4 people you are NOT yet facing any real scaling pain. You don't have the team size where you should be solving things with organizational techniques.
I would advise that you have a couple of columns in a kanban board: Now, Next, Later, Done & Rejected. And communicate it to customers. Pull up the board and say: "here is what we are working on." When you lay our the priorities to customers you'd be surprised how supportive they are and if they aren't...tough luck.
Plus, 2-3 weeks feels like an eternity when you are on defense. You start to dread defense.
And, it also divorces the core business value into 2 separate outcomes rather than a single outcome. If a bug helps advance your customers to their outcome, then it isn't "defense" it is "offense". If it doesn't advance your customer, why are you doing it? If you succeed, all of your ugly, monkey patched code will be thrown away or phased out within a couple of years anyway.
There are 2 fundamental aspects of software engineering:
Get it right
Keep it right
You have only 4 engineers on your team. That is a tiny team. The entire team SHOULD be playing "offense" and "defense" because you are all responsible for getting it right and keeping it right. Part of the challenge sounds like poor engineering practices and shipping junk into production. That is NOT fixed by splitting your small team's cognitive load. If you have warts in your product, then all 4 of you should be aware of it, bothered by it and working to fix it.
Or, if it isn't slowing growth and core metrics, just ignore it.
You've got to be comfortable with painful imperfections early in a product's life.
Product scope is a prioritization activity not an team organization question. In fact, splitting up your efforts will negatively impact your product scope because you are dividing your time and creating more slack than by moving as a small unit in sync.
You've got to get comfortable telling users: "that thing that annoys you, isn't valuable right now for the broader user base. We've got 3 other things that will create WAY MORE value for you and everyone else. So we're going to work on that first."
While I can't vouch for voiczy, Duolingo is in the business of user retention and engagement in order to meet investor demands...language learning is the hook.
Duolingo is notably POOR at real language acquisition.
It is an administrative step. It might undergo review but access does not need to be prevent until the review happens. It is all about who is granting the access.
The commander in chief has considerable authority to provide access.