> Among non-mathematicians, the public response was more sympathetic than not, but I observed a vocal minority (particularly from the technology and economics communities) with reasoned objections, generally saying that the mathematicians should adapt and cede control in the new AI world.

Interesting how Software Engineers, instead, seem to have given up early without any declarations or open letters.

what? really?

Last week alone I was unable to access two major websites because their auth flow was broken (I was attempting to log in with Apple, so not "the happy path"). I was just locked out, had to contact support. I guess this mentality is what causes it.

We had safeguards and best practices built over the years of learnings to avoid introducing these kind of regressions. And we threw them away in half a year to...gain some productivity in delivering features that most likely the users don't even want.

Fingerprinting I would argue it's a problem on all platforms though, web included.

So ultimately yes, installing an app on iOS is not a trust decision because the dev are very limited in what they can do. The biggest trust decision is toward Apple that might have private secret APIs allowing them to do things developers cannot. That's a possibility, but overall Apple business has never been around ads, big data and users profiling so the chances are not this high.

It has two problems though: if my approach has flaws the agent would implement it as-is even if could instead suggest an improvement. Also, an advantage of agents in huge codebases is that they can find where to make the change and draft it, which wouldn't work with this system.

Comments URL: https://news.ycombinator.com/item?id=49297396

Points: 2

# Comments: 0

But that's difficult and time consuming, if anything it's advanced economics and requires effort to decode what's happening. What it's very easy to do is getting angry at a group of people and to feel deep unfairness about it, then think that if that group of people were to leave, the problem would improve or be solved. That's exactly the kind of thought that seems to be so pervasive at all levels and yes, it is a scapegoat. Especially since that the only merit someone has over H-1B is to (by pure chance) having being born in a different place. I really feel that many people complaining against H-1B wouldn't even qualify for it if they were born somewhere else.

I had the similar experience to yours yesterday and it lead nowhere. Funnily enough I was also trying to configure a vpn on a router, google didn't return anything useful (besides a blog post clearly written by AI and with absolutely no information in it). Claude managed to give some interesting pointers, but its suggestions were not working and I also noticed that it started to hallucinate badly about ipv6 and gave me some suggestions that were just plain untrue. Claude Opus is smart, usually when it gets so convinced about something is after researching the internet and not just based on its training data. I wonder where it got so convinced about it. Maybe reading some other hallucinated blog post like the one I stumbled upon?

Even if the reviewer does the review commit-by-commit, all the comments and discussions will be on the same PR leading to multiple ongoing conversations about different topics that would be split if the PR are stacked. Also, all the new commits addressing the comments with spoil this commit-by-commit design, as the previous commits will be outdated and the new changes will be on top of those. I think it's beneficial for new changes to be a separate commit and not rewriting history, to not force the reviewers to re-read everything but just the latest changes.

Does anyone have some tools to share?

People love these not because they are creative or good executed, but because they see the pictures and the story of the people they love.

> It remains important to be able to read the code and understand the architecture. As a result, I reduce my velocity by iterating over my PR until it reaches the same level of quality I would have produced "by hand"

I do that too and when I do it I'm not sure anymore if I'm "producing as much more" than if I was doing it by hand. I need to spend time to read the code, break down the flow so that it clicks in my head and so that I'm 100% sure that I understand what is going on and what every line does. And then I still test it (executing it), because that's where you notice the edge cases anyways. Once I understand it and test it, the part where I iterate or fix small quirks and hallucinations is the smallest part of the job and is irrelevant if i do it by myself or ask the LLM to make the change.

I'm still not convinced that I'm faster with an LLM at all, since I add this new bottleneck (the time spent understanding every line). If I do it by hand it already clicks in my head, so it's faster for me to test it, find unaddressed edge cases and then confidently ship it. Maybe the LLMs gains are not in this at all and writing every line by hand will still be the norm for a long time.

Still, LLMs make me insanely faster in: finding something in the codebase, recostructing a flow and understanding the architecture, triaging a bug (sometimes it just solves it with a prompt), writing and updating tests, reviewing changes for potential issues. These days I have almost always 2/3 agents running doing something of the above. That saves me hours and you can pry an LLM from my dead hands, but I'm still not sold that it makes me faster at producing production grade code that I fully understand and follows my company architecture and standards.

Then sure, if I need to make a prototype or a small tool for myself or some novelty thing, an LLM can do it without me ever touching or reading the code. But I think that's not what the majority of software engineers are employed to do.