Similar effort with PageIndex [1], which basically creates a table of contents like tree. Then an LLM traverses the tree to figure out which chunks are relevant for the context in the prompt.
Sticking with standard Kubernetes API patterns, the model has a pretty good intuition about how to traverse and debug applications, fetch logs, scale services, debug networking, etc.
Would say, the 30 under 30 list has like 600 people, not 30. So the fraud rate is quite a bit lower than headlines of seemingly 2 / 30. Its more like 2 / 600, which is maybe the baseline fraud rate?
What would be an actually good faith way of regulating this short of banning it for children (which I’d think is fine). How do you define what is too addictive?
At any given time it seems like whatever is defined as the most addictive is just the one with most market share? For me personally I think most addictive is actually hacker news (god bless you all)
I really don't think there is a good faith way to regulate it without either violating free speech and/or removing online privacy/anonymity. I strongly believe it should not be regulated, though I would support better educational programs on the dangers of social media usage and other dark patterns (and somewhat related, I would remove most screens from (public) schools).
What "free speech" exactly? Do you think that such a thing actually exists on platforms controlled by giant corporations? This "free speech" is heavily regulated by opaque algorithms and very specific terms of service. It's "free" as long as it aligns with the company's values and business goals, and your opinions will only reach other people if the algorithm decides that promoting it would drive engagement.
There is definitely a risk of governments using this as an excuse to encroach upon civil liberties, as they've done in the past, but this is not a black or white issue. The reality is nuanced and passing regulation requires careful discussion and balancing. I'm sure we can agree that regulating Big Tobacco and Big Pharma was a good thing, and not some civil rights issue, so why is Big Tech different?
We can also work on educating people, as you suggest, but it can't be the only solution. Regulating greedy and predatory companies should be a part of it.
It's amusing that you would rather support a ban on screens in schools, than regulating companies that make using screens harmful in the first place. It's very reminiscent of the blanket "TVs are bad" argument from past decades.
The same methods that are used for gambling are a good start.
I know lootboxes in video games are regulated in some countries. Not sure if they are banned in some places, but I do know that they have to show the odds in some places, and in others they have to be deterministic.
The crux of the issue is personalization and behavior psychology. If you move to a boring feed design, you end up addressing most of the current issue.
Another option is to allow for interoperability between social media platforms, which is a competition respecting way of giving people the ability to move to platforms that “work” for them better.
I’d hazard that Civil liberties are not really at risk here, only the bottom line of social media platforms. However, theres enough money to protect the bottom line even if it costs civil liberties.
Why regulate? Look at the failure that is the "war on drugs".
The solution is education. The government should be educating society and especially parents on how to protect their children.
Education worked to cut cigarette use, and is starting to lower alcohol consumption as well. It can work for social media without all the negative impacts on civil liberties that come with regulations.
Ah, yes, it was education, and certainly not strong regulation of how cigarettes are produced, marketed, and sold. Educating the youth is why vaping and smoking is not cool anymore.
Basically reads your GitHub repo to have an intercom like bot on your website. Answer questions to visitors so you don’t have to write knowledge bases.
Is this the best way to measure this? I think the biggest adopters of AI coding has been companies who are building features on existing apps, not building new apps entirely. Wouldn't it make more sense looking at how quickly teams are able to build and ship within companies?
It seems like all tech executives are saying they are seeing big increases in productivity among engineering teams. Of course everyone says they're just [hyping, excusing layoffs, overhired in 2020, etc], but this would be the most relevant metric to look at I think.
Ditto for me. I had gotten so used to building web backends in Ruby and running at 700MB minimum. When I finally got around to writing a rust backend, it registered in the metrics as 0MB, so I thought for sure the application had crashed.
Turns out the metrics just rounded to the nearest 5MB
I’ve encountered an even more nightmarish version of this recently: ai generated tickets. Basically dumping the output of “write a detailed product spec for a clinical trial data collection pipeline” into a jira ticket and handing it off.
Doesn’t match any of our internal product design, adds tons of extraneous features. When I brought this up with said PM they basically responded that these inaccuracies should just be brought up in the sprint review and “partnering” with the engineering team. AI etiquette is something we’ll all have to learn in the coming years.
That used to be my joke! Given that most large organization spend (much) more time with the administrative work around code changes than the actual changes themselves (planning, deciding, meetings) then before we let Claude write our code we should let it write our Jira tickets. It was a great joke because while it was obviously absurd to many people it also made them a bit uneasy.
Cue a similar joke about salary negotiation, and the annual dance around goals and performance indicators. Is it really programmers who should be afraid to become redundant, when you think about it?
I should know better than making jokes about reality. It has already one-upped me too many times.
Tried that last year and the problem was, the tickets themselves were broken down well enough to make sense to the naked eye. The second problem was that it was all for a legacy codebase where practically everybody who had built it over the years had left, so it was a real don't-know-what-you-don't-know situation.
The second problem was always going to be there, even with human written tickets, but the problem really is that someone who relies on AI gets into the habit of treating the LLM as a more trustworthy colleague than anybody on the team, and mistakes start slipping in.
This is equally problematic for the engineers using AI to implement the features because they are no longer learning the quirks of the codebase and they are very quickly putting a hard ceiling on their career growth by virtue of not working with the team, not communicating that well, and not learning.
Had a friend in a similar situation. She got a clearly LLM-generated ticket that didn't make any sense, and was directed to question anything about that ticket.
Apparently, asking "why it doesn't make any sense" wasn't !polite~
If I remember correctly, she came up with ~200 questions for a 2-paged ticket. I helped write some of them, because for parts of the word salad you had to come up with the meaning first and then question the meaning.
You know what happened after she presented it? Ticket got rewritten as a job requirement, and now they seeking some poor sod to make it make sense lol
One had to be very unqualified to even get through the interview for that job without asking questions about the job, I feel. Truly, an AI-generated job for anyone who is new to the field
Oh, it was! But the guy that generated it insisted that he triple-checked the prose after, and it should be treated as typed by hand
I'm pretty sure it would be okay to stop at 5-10 questions, because it was clear he couldn't answer any. But my friend is from a hateful branch, and so she went for humiliation angle of asking for as much clarification as the ticket itself allowed
I have a very similar situation. Except it isn't even a ticket, just an export of a very long "conversation" with ChatGPT with a vague indication that this is what needs to be implemented. When questioned about it, the person insists they completely understood it before but just forgot after a few days. Sometimes the prompts are removed. Lots of contradictory material in it, some doesn't make sense even in context. Very difficult to figure out what is wanted.
> person insists they completely understood it before but just forgot after a few days.
I don't doubt this, to be honest.
I have the feeling of learning a lot when coding with agents. New features, patterns, entire languages... It's very satisfactory asking questions and getting answers in as much detail as you want, with examples, etc.
Except I forget it all soon after. Because I didn't put the effort. Easy come easy goes .
I'm continually flabbergasted that this is accepted and not immediate grounds for punitive action- plopping slop into a ticket (or having it generated directly) is straight-up disrespectful to the person on the other end. I'd rather have someone slap me in the face directly than get one of these tickets.
Yes. My Jira tickets used to be almost empty, but all of it was useful info. Now, my Jira tickets are way too long. The amount of useful info has also gone down.
Talk about an AI induced productivity increase ...
I'm taking a break from doing Clever Stuff and just working on the networks team at work, because there's a big infrastructure update happening and if you want a thing done right you have to do it yourself.
Anyway.
People are starting to log support tickets using Copilot. It's easily recognisable, and they just fire a Copilot-generated email into the Helldesk, which then means I have to pick through six paragraphs of scrool to find basic things like what's actually wrong and where. Apparently this is a great improvement for everyone over tickets that just say "John MacDonald's phone is crackling, extension number 2345" because that's somehow not informative enough for me to conf up a new one and throw it at the van driver to take to site next time he's passing, and then bring the broken one back for me to repair or scrap.
I do this quite often, but I also instruct Claude to limit its output to 2-3 sentences or paragraphs, depending on the context. Also "Write this for a team of software developers / MBA's" goes a long way too.
I also do the extra step of eliminating things that are not needed, or we review this during backlog refinement.
Sounds like a lot of work to ensure it's correct, without the guarantee that it's actually correct. Why not just do it oldschool? Is it really saving you that much time?
We went from Jira tickets with one or two sentences, "Implement feature X. Here are some caveats: (simple bullet points, a few words each)" to literal _pages_ of full-on unreadable garbage.
Our engineers deliver concise outputs because we have settled internally that that's what we want. Fluffy verbosity serves no one if there's little signal in there, so just give me the no-purple prose, no emojis, tight and concise bullet version without all the chaff.
My teammates hit the generate PR button. I'm not reading that, it's a summary of the changes that I am _already_ going to be looking at, wrapped in some flowery language about being "better architecture, cleaner code" etc.
So those PRs may as well not have a description at all as far as I'm concerned.
AI etiquette is a great term. AI is useful in general but some patterns of AI usage are annoying. Especially if the other side spent 10 seconds on something and expects you to treat it seriously.
Currently it's a bit of a wild west, but eventually we'll need to figure out the correct set of rules of how to use AI.
I'm hearing nightmare stories from my friends in retail and healthcare where someone walks in holding a phone and asks you talk to them through their chatbot on their phone. Friend had a person last week walk in and ask they explain what he does to Grok and then ask Grok what questions they should ask him.
What shocks me is the complete lack of self awareness of the person holding the phone. People have been incapable of independent thought for a while, but to hold up a flag and announce this to your surroundings is really something else.
As someone who maintains open source projects, I can assure you that this has been a problem for about a year or so. But I reckon it took a bit longer for people to start doing this at work as well.
I've heard a great thing recently, more or less - If all you're doing is writing prompts, maybe you're not needed anymore. Stay behind the intent, own the output and understand it and then maybe it makes sense. sloppy prompt + c/p doesn't bring value and will be treated as such. As with anything in life, outcome is usually proportional to the effort put in.
I ran into a similar case recently, there was a ticket describing what needed to be done in detail. I was written by a human and it was a well written spec.
The problem is that it removed some access controls in the system, essentially given some users more access than they should have.
The ticket was given to an LLM, the code written. Luckily the engineer working on it noticed the discrepancy at some point and was able to call it out.
Scrutinizing specs is always needed, no matter what.
Some people use AI as they use anything else. Careless, without putting the effort in, making things somebody else's problem. This existed before AI, it just accelerated the stupidity.
Careless people never used to be able to create such absolute volumes of garbage that flood the system. Open source projects used to be able to just have an open PRs system, because the effort to create and submit something is quite hard, it's a natural filter. Now automated agents can flood a project with hundreds of useless PRs that disguise themselves as being real.
I've had exactly the same feeling. Since the beginning of time, it has generally taken more effort to build something than to review it. This is no longer the case, and it completely breaks some processes.
The quick solution is to escalate the arms race, and start using AI to filter the AI slop, but I'm not sure that's a world I want to work in :)
If you think of it like filters, a human programmer does everything they know and test to avoid bugs, then the AI review catches some things that slip through to catch a larger total number of bugs. But if both sides are AI the same stuff slips through both stages and blows up on production. It makes more sense to just improve the models to make less mistakes than to have AI review itself.
I think before, it was easier to spot. Before, the effort spent would often show in the volume or consistency of the writing. Now, one can create a big, wordy and convincing-sounding document (without any grammatical errors!) in mere seconds. It also provides for some convenient plausible deniability: you can always claim the LLM only helped you here and there with the wording.
So now, even figuring out that it was a careless or lazy job takes a lot more time, which drastically skews the economics in favor of the careless person.
I would much rather have my prose contain grammatical errors then have anyone mistake it for LLM output. I am absolutely shocked that anyone has the opposite preference.
This.
In my case I do write from time to time tickets with an LLM but it's always after a long exploratory session with Claude Code, when I go back and forth checking possibilities and gathering data, and then I tell it to create a ticket with the info gathered so far. But even in that case I tend to edit it because I don't like the style or add some useless data that I want to remove.
Don't discount the value in rubberducking with an AI.
They write shit code, but but can be prompted to highlight common failures in certain proposals.
For example, I am planning a gateway now, and the ChatGPT correctly pointed out many common vulnerabilities that occur in such a product, all of which I knew but may not have remembered while coding, like request smuggling.
It missed a few, but that's okay too, because I have a more comprehensive list written down than I would have had if I rubber ducked with an actual rubber duck.
If I finally write this product, my product spec has a list of warnings.
Not really, the exploratory phase is (probably) much faster with Claude Code that on my own. Writing a well specified ticket is very, very time consuming. With Claude Code for me it's way much easier to branch off and follow the "what if actually...?" and challenging some knowledge that - if I had to do it manually - I will just take for granted during ticket writing. Because if I'm "sure enough" that a fact is what I recall it to be, then I just don't check and trust my memory. When paired with an LLM, that threshold goes up, and if I'm not 101% sure about something, I will send Claude Code fetch that info in some internal artifact (i.e. code in a repository, actual state of the infra etc) and then take the next decision.
We’re getting prospective and existing clients emailing us what look like AI generated spreadsheets with features that are miles long that they want us to respond to. Like thousands of lines. And a lot of features that are “what does that even mean??”
We get on a call with them and they don’t even know what is on the spreadsheet or what it means…
Very much a “So you want us to make Facebook?” (Not actually asking for Facebook) feeling.
I fear these horror shows of spreadsheets are just AI fever dreams….
The manager of my team is like this. He LLMed a design doc and then whenever people have questions he's exasperated that people didn't read the design doc. Bro you didn't write it, why would we read it?
This is a perfect example of where the real work and challenges are in software development.
AI makes it worse. This is where people will lose tons of productivity with AI and many people are completely clueless. It'll hit them like a ton of bricks one day.
I had a PM that was unable to work without AI. Everything he did had to include AI somehow.
His magnum opus was 30 extremely large tickets that had the exact same text minus two or three places with slight variations. He wanted us to create 30 website pages with the content.
The ticket went into details such as using a CDN, following the current design, writing a scalable backend, test coverage, about 3-4 pages per ticket, plus VERY DETAILED instructions for the QA. Yep: all in the same task.
In the end it was just about adding each of the 30 items to an array.
I don’t know if he knows, but in the end it was this specific AI slop that got him fired.
> Is tossing stuff over the fence considered ok now?
Has been for a long time unfortunately. AI didn't create this behaviour but certainly made it easier for the other side to do it.
> Review the slop with the person that submitted it.
Alternatively, mark them as "Needs Work" if you can. But yes, put the ball in their court by peppering them with questions. Maybe they will get the hint.
I'd also say for a lot of applications -- most applications perhaps -- outside of "consumer" ones, the number of features is quite a bit more important than the shape of a button or the animations during a page transition.
Even pretty massive companies like databricks don't think about those things and basically have a UI template library that they then compose all their interfaces from. Nothing fancy. Its all about features, and LLM create copious amounts of features.
1: https://github.com/VectifyAI/PageIndex
reply