I might be in the minority but to me email is an annoying requirement to reach out to people, and that is not due to the AI tools, it's due to: thread management, the horrible noise of unasked for newsletter, and system messages and updates I theoretically do care about but that are just inconsistently formatted and badly listed. I welcome AI giving me a better overview over what's going on than what I myself have.

People coming in "I encountered a bug, I don't know what the bug is but I thought about it for a second and it's obviously your descision to do xyz".

As a maintainer, what are you supposed to do? It's not more useful than a ticket "somethings wrong idk what" which is useless enough to close without further action. But it puts the burden on the maintainer to a) figure out what's wrong based on basically no data whatsoever, then b) if they find it out figure out why then c), and that's the tiring part, review their process and create a defense for their approach, or admit that that thing that random user felt after trying out your software for 10 minutes is right, and that you were what? stupid to even think this would ever work? They never asked for any of this, and they're already doing so much work for free.

If the rsync maintainer reads this: You're doing incredible work and humanity appreciates your obviously incredibly competence in it, and not everyone feels the way these people do.

Moving to agentic workflows is obviously the right step and it already provides enough benefits to do it already. And mistakes are bound to happen (if the issue is even a mistake!) and there will always be people who cannot comprehend the power of agents and who will point the finger saying "I know it from the start! I've worked with these tools for 2 hours already and I can see they don't work! Idk why you think they do!". They're wrong. But mistakes will happen that otherwise wouldn't have - but that's the learning experience.

As far as I know, nobody with data claims that vibe coding doesn’t affect reliability negatively.

People will connect these two things.

Many times, when reliability doesn’t plummet really. For example, there were huge negative news about a Samsung phone a few years back, that it easily causes fires. Sales were affected by this. Interestingly, next year, they released basically the same thing under different name, and complains were never that loud again. And as far as I know, when they were loud, there was nothing special about that particular model regarding this. So it’s possible that outrage is not validated at all.

They will also connect these, when reliability plummets, but it’s not because of vibe coding.

And they will connect, when it is the real culprit in general, but their problems are not affected by vibe coding.

And of course also when vibe coding really causes their problems.

In any case, the original statements will be true. Do we really want to make a product less reliable to implement features and bugs which we deemed not that important before? Especially with a stable product?

Of course, these on the maintainers, but it’s interesting that forcing AI and their consequences on us - like how Microsoft, Google, etc do - is the default, and not the other way around according to many in this thread and others.

And the maintainer can then choose to use that feedback to incorporate it into the workflow, on their own time. If they so choose (which I'm sure they will, unless they get burnt by the community right now).

I think we agree.

I doubt Anthropic internally sets as a goal to improve this or that benchmark - it's just a way to visualize progress. They probably have much more complex metrics internally.

This is an annoying to do for exactly two platforms: node.js, and deno.

node.js bcs it requires a workaround whenever something networking comes in: fetch doesn't work the same. So you structure you're code around having a node.js workaround. Same story for some other APIs. But you can test if itn works!

Deno is more annoying, you just can't test your package with deno before publishing. Before we released to npm, we installed a tar file and sent those around for testing. Works in node, in vite (node, for browser), works in bun, like a charm. Doesn't work with deno unless you switch to package.json, and you use exactly the subset of the spec that deno supports. You can't "deno install xyz.tar", you have to use npm for that (inserts a single line into package.json), THEN you can use deno to execute. No docs, no hint, just trial & error.

Even more annoyingly, npm & bun both offer 'link': in package repo, call npm/bun link, in the test repo do npm/bun link @yourpackage, and that's it, it's installed. Creates a dyn link to the source's build dir so you can rebuild without packing or sending tars or anything like that, you just build in your package dir and the test project is immediately updated.

Deno doesn't have that. What's worse, they don't tell you they don't have that. Also basically no error messages. It just fails in weird ways. Spent hours trying to do it. Now I just publish without testing for deno and wait for bug reports.

So out of the three: bun just works. That's it. Better than any platform. It just works, and it has a nicer CLI & nicer error messages, and it's faster on startup. It has the web api and the node api (i think) and its own api that's very nice as well, nicer than e.g. node. And e.g. if you run bun link, it tells you exactly what happened: this is what just happened, this is what you have to do to use it elsewhere. Node doesn't have that!

I think deno recognized bun's strategy of using npm dev's backbone as being the better call - that's why they're now slowly introducing node.js features, even though that goes against their original USP.

Ideation: Throw ideas back & forth, cross reference with knowledge bases, generate design documents. Documentation: Generate large parts of docs. Development: Clear. Deployment: Generate deployment manifests, tooling around testing, knowledge around cloud platforms.

Every single step can be done better & faster with AI. Not all of them, but a lot.

Even development. Yes some part of your job involves understanding the problem better than anyone & making solutions. But some parts are also purely chore. If you know you keed a button doing X, then designing that button, placing it, figuring out edge cases with hover & press states, connecting to the backend etc - this is chore that can be skipped. Same principle applies to almost all steps.

A typical example of trying to add a new significant capability involves many meetings (days, weeks, months, etc. )with the business to understand how their work flows between systems X, Y and Z as well as all of the significant exceptions (e.g. we handle subset A this way and subset B that way, but for the final step we blend those groups together, except for subset C which requires special process 97).

Then with that understanding comes the system solutioning across multiple systems that can be a blend of internal system or vendor's system, each with different levels of ability to customize, which pushes the shape of the final solution in different directions.

There is certainly value in speeding up coding, but it's just one piece of the puzzle and today LLM's can't help with gathering the domain information and defining a solution.

Product owners can very quickly get, for many problems, an interactive demo without coding. For lots of problems this can be somewhere from a static html page which shows the interactions to a hacked in feature that lets them actually test if it solves the customer need and try several variations before handing over much more concrete specs of what they want to happen. So much time is lost between getting an idea from someone’s head to code to use to then find out it wasn’t communicated well and then finally that the idea didn’t help anyway and we want it in a different way.

Yes yes I know someone is about to say that now there’s pressure to push the prototype out but that’s an organisational level problem that existed anyway.

And small problems can much faster to solve as well, or even move away from devs. Often people just need some text changed somewhere or html putting together, or some basic code for analysis. They could understand the logic, but the task of writing it from scratch and how to run things may be too much - now you don’t need to prioritise work for a dev to get some sql written and they can spend their time on the larger more software engineering level problems.

That's very true to many organizations. One cannot just slap an AI tool on it when you are dealing with fundamental organizational problems in the first place.

"they can spend their time on the larger more software engineering level problems"

For sure, devs still needs to focus on the right type of work and maintain the balance. I built a tool to just do that: https://worktypefocus.com/

I'm not saying this is the correct thing, but companies are implementing it and it is "working". I don't think keeping our head in the sand is helping.

But the LLM is not aware of how the business works and why, so someone needs to work with the business to extract the information. Typically it's not well documented.

LLM extraction of the information from the Product Owner is becoming the way to overcome poorly-documented business context.

Non-technical folk are using things like `/grill-me` [0] to seed the LLM with the long-tail complexities that they didn't know they didn't know they needed to put out.

[0] https://www.aihero.dev/my-grill-me-skill-has-gone-viral

These are language models, being able to talk through something with them and have them extract some information is what they excel at. Given that you’d probably get a halfway decent result with a literal fixed set of questions (an Eliza level docbot) gpt 5.5 is going to nail that as a task.

Are they reasonably documented/audited/put into any sort of version control like a lot of internal tooling? Or are they the kind of the thing that gets whacked together on the fly in a "move spreadsheet data from A to B", "I want a list of people's schedules with custom highlighting" kind of things.

Not doubting your productivity increase, I'm just curious how people quantify that when they say it.

looks like orgs have to have engineers on for optics. like having a legal staff with no lawyers, or a cybersecurity staff with no IT or certified people. Software has famously not needed state licenses or industry certification, but maybe thats a direction to consider to give utility to company optics.

I'm at a FAANG. My org is moving much more quickly, maybe between 3-10x more quickly than we were pre-AI. We aren't seeing a spike in reliability issues. Things just get done faster. An org as large as mine has no right to move as fast as it does.

You have been asked multiple times by multiple commenters to provide a single example of something that reflects this incredible boost achieved by <massive tech org>, you have ignored every request for this, and I suspect will ignore this one as well. HN is going to die unless we all start calling these constant deceptive practices out. I’ll leave others to parse your history and make their own judgements.

“Judge them by their fruits”

Anyways, solenoid0937 is an LLM-hype peddler and an Anthropic shill, not an actual FAANG-employee. See proof here: https://news.ycombinator.com/item?id=48269250

And if it is a chore, we already have some tools to speed it up, only if it is worth it though. Placing a button is actually easy if you get all the design system down usually with a component library, visual regression automation and testing automation.

If a team doesn't have tools and automation in place, AI might speed them up a little but it adds a layer of complexity, i.e. everyone have to manage their own workflow and tools. And when you try to align the team, you get the tools and automation that the team is supposed to have in the first place.

As for ideation, the problem isn't the speed of information ingestion but the ability to connect and understand different parts of the information, which require thinking. More information at times is just going to hinder the ability to think. For example, it is obvious to developers why there is a rate limit for the APIs but for PMs it might not be obvious. They might ask the AI whether or not a rate limit can be removed easily, how many days if you vibe code it and ignore the possibility that the rate limit might by abused by users just to improve a feature because it is too slow.

We are still doing alot of work with new tools but old methods though, it will be interesting to see how far can we go if we forget about the old rules and embrace the chaos entirely.

In fact, these disagreements and disbeliefs create opportunities and salients in the market.

Anecdotally, I see a lot of problems/solutions content about AI that doesn't reflect at all the challenges I face. But trying to tell people that there are other ways of doing things, especially when it conflicts with token-maxxing, is a lost cause

It's not that they're using the tool wrong, it's that the tool just isn't capable of what we see before our own eyes! I guess our eyes and ears are simply lying to us?

And then they ask for how we are managing to make things move faster. When you refuse to breach NDA and give up your competitive advantage on HN, this somehow confirms their belief that AI is useless.

I want to know your alpha because that excites me.

These people have their heads buried in the sand.

1: When was the last time you worked on a project where you thought the average IQ was 140? I don’t even think I have worked on a project where the maximum IQ was 140.

2: Who thinks the IQ of people on the project determines its success? There’s so much more to it than just “high capability team members” (to give IQ a generous interpretation).

3: (math joke) A sequence like (AI IQ - Human IQ) can be negative and monotonicly increasing and still never reach 0.

The issue is that IQ means less than you want it to.

IQ is a terribly flawed measure of human intelligence. But it measures nothing when you apply an LLM that contains multiple IQ tests in its corpus. IQ is deeply flawed, but the point is not to "measure performance on IQ tests". If someone cheats on an IQ test and scores 200, no reasonable person would say they have 200 IQ.

It's just one of these rules that unfortunately in Europe allow people to view life purely as the time between jobs. I'd never tell that to someone's face but it's simply a fact that the world stops of people don't work and no matter what the ideal world looks like in your dreams, working is the only real way forward for anything. It's part of the reason why Europe is falling behind on everything.

The increased growth in USA the last decade have largely been created by means that one day will be quite costly for you (debt).

The USA under MAGA is falling apart. EU and others are actively minimizing risk by selecting non-US IT providers. EU and others are actively selecting non-US defence aystems.

I say that it is very positive to protect your citizens. Russia (sending their citizens en masse to a certain death on the front lines) and USA have more in common politically than USA and EU.

But there's nothing like AWS, Google Cloud, facebook, Azure, ChatGPT, Tesla, etc etc the list goes on and is very long, in Europe. They're switching way too late. Why did it not happen before? Why do we have very limited IT providers, for example? Due to the culture and regulation that doesn't incentivize it sufficiently.

I'm European too btw and live in the EU and I'm happy about a lot of things we have that the US doesn't, I'm just personally worried that we're setting priorities wrong. Having a chill life in the park is good in the ideal it's just detached from what's needed to make a state run; and it will end in the EU having even less power that is has now, resulting in fewer moral values being carried into the world.

I read a news article that Orange Telecom in France was being sued by a woman they had on payroll for the last 20 years doing nothing, because due to a medical condition she suffered, she became unable to do her job, and since they couldn't fire her due to France unions and labor laws, nor did they have any available job that could fit her current condition, they just kept paying her for 20 years to do nothing at work, and now she's suing them for the depression she got to get paid for no work.

It felt like reading a Monty Python skit.

But Europe is failing due to a myriad of compounding issues and structural deficits, not just because firing workers can be a Kafkaesque nightmare in some countries. European workers' unions and labor protections were even stronger 20-25 years ago and in 2004 the Euro stock market was worth more than the US stock market, while now it's worth half the US one. But that's whole different discussion where pages have to be written to encompass the whole context and cover all aspects of European economic decline. Boiling it down to crazy labor protections would be reductionist and incorrect.

They couldn't find anything for her to do? Hard to believe, but if there's a reason not to fire her then then pay her the money she's owed and stop demanding she show up. Making someone come in with no tasks assigned is fun for a week and quickly turns into punishment detail. Putting someone on punishment detail because you're not allowed to fire them is Bad.

Unless she was allowed to stay home, in which case I take most of that back and it falls on her to go outside and find something to do. I can't find any articles with enough detail. But I'm still skeptical they actually couldn't find a job for her to do. It was 'just' paralysis on one side.

If a person's now disabled, what can a company give them to do profitably, that isn't already optimized, automated or offshored?

There's plenty of civil servants whose jobs are just moving one paper from one room to the next, just to keep more useless people employed that nobody would hire in the private sector. But this doesn't really exist as much in the private sector.

If I found the right article, the disability is epilepsy and paralysis on one side.

Which mean she can do pretty much any office job fine. She already was doing office work, so the disability should not have changed things all that much. I'm sure she typed slower, but that can be worked around and mitigated.

Honestly, I doubt it. If you show up to an interview of "any office job" with "epilepsy and paralysis on one side" nobody will hire you simply because you won't be as productive as those without such disabilities.

Also, "epilepsy and paralysis on one side" is the legal medical diagnosis, but in practice the impact can be much greater, especially with age, which is why ageism is a thing even among people who are legally in full health because in practice your body isn't the same like when you were 19-25.

She doesn't need the equivalent of "moving paper from one room to the next". She lost some number of dollars per hour worth of productivity, but it sounds like she was still capable of being reasonably productive.

It's called "mise au placard" and it's illegal. It's a technique to get people to quit by themselves, so companies don't have deal with the hassle of firing them. The lawsuit is 100% justified.

It's also very common in Japan.

If she had been hired after, it would have taken time but she would have been found unfit for work (she had epilepsy and hemiplegia), her contract terminated, and she would have most likely received a handicap pension instead.