Hacker Newsnew | past | comments | ask | show | jobs | submit | more netdevphoenix's commentslogin

> Google would have to take the lead and implement this in chrome then enough developers would have to build sites using it and force safari and firefox to comply. It just isn't feasible.

This is not something you really want to happen for the health of the web tech ecosystem. I am surprised to see actual developers nonchalantly suggesting this. A type system for the web is not worth an IE 2.0


I would want this to happen personally as there is no other way that the tech can advance at this current point.

It's clear that there is no global browser federation that works together to make standards. Every browser does things themselves and implements things differently. So the only way that it is feasible is if the browser that is used by 75%+ of sessions is the one that implements it.

Would I like it to be open source? of course. would I like it to be a separate project that was not directly controlled by google? yes. But this does not change the fact that it would ONLY be possible if they accept it into chrome.

The alternative is to forever use Javascript and never advance or change things.

Tech moves quickly and it could be possible that a new browser could take market share in 10 years but it is inconceivable now and would take some groundbreaking shift.

It feels like current browsers can never change their language and it will only be once a new platform is standard, like Vision/Glasses or a voice AI assistant.

It could have been possible if Huawei was allowed to stay in the US market as they are making their own kernal, operating systems and browsers, but they are now excluded. So only google and apple are present to control how things operate.

Over time things must adapt if they become better, there is always pushback when change occurs, but change is necessary for growth.


Almost had this with dart


> Now I first discuss with an AI Agent or ChatGPT to write a thorough spec before handing it off to an agent to code it. I don’t read every line. Instead, I thoroughly test the outcome.

This is likely the future.

That being said: "I used to spend most of my time writing code, fixing syntax, thinking through how to structure the code, looking up documentation on how to use a library.".

If you are spending a lot of time fixing syntax, have you looked into linters? If you are spending too much time thinking about how to structure the code, how about spending some days coming up with some general conventions or simply use existing ones.

If you are getting so much productivity from LLMs, it is worth checking if you were simply unproductive relative to your average dev in the first place. If that's the case, you might want to think, what is going to happen to your productivity gains when everyone else jumps on the LLM train. LLMs might be covering for your unproductivity at the code level, but you might still be dropping the ball in non-code areas. That's the higher level pattern I would be thinking about.


I was a good dev but I did not love the code itself. I loved the outcome. Other devs would have done better on leetcode and they would have produced better code syntax than me.

I’ve always been more of a product/business person who saw code as a way to get to the end goal.

That elite coder who hates talking to business people and who cares more about the code than the business? Not me. I’m the opposite.

Hence, LLMs have been far better for me in terms of productivity.


> I’ve always been more of a product/business person who saw code as a way to get to the end goal.

That’s what code always is. A description on how the computer can help someone faster to the end goal. Devs care a little more about the description, because end goals change and rewriting the whole thing from scratch is costly and time-consuming.

> That elite coder who hates talking to business people and who cares more about the code than the business? Not me. I’m the opposite.

I believe that coder exists only in your imagination. All the good ones I know are great communicators. Clarity of thought is essential to writing good code.


  I believe that coder exists only in your imagination. All the good ones I know are great communicators. Clarity of thought is essential to writing good code.
I don't think so. These coders exist everywhere. Plenty of great coders are great at writing the code itself but not at the business aspects. Many coders simply do not care about the business or customers part. To them, the act of coding and producing quality code and the process of writing software is the goal. IE. These people are most likely to decline building a feature that customers and the business desperately need because it might cause the code base to become harder to maintain. These people will also want to refactor more than building new features. In the past, these people had plenty of value. In the era of LLMs, I think these people have less value than business/product oriented devs.


> Many coders simply do not care about the business or customers part.

These coders may exist, but they are in my experience not that common. Most coders do care about the business or customers part, but think very differently about these aspects than business people, and thus come to very different conclusions how to handle these topics.

In my experience, it's rather exactly these programmers who are often in conflict with business people

- because they care about such topics

- because they come to different conclusions than the business people, and

- because these programmers care so much about these business-related topics, they are very vocal and sometimes confrontative with their opinions.

In other words: coders who barely care about these business-related aspects are often much easier to handle for business-minded people.


> > That elite coder who hates talking to business people and who cares more about the code than the business? Not me. I’m the opposite.

> I believe that coder exists only in your imagination. All the good ones I know are great communicators. Clarity of thought is essential to writing good code.

Clarity of thought does not make you a good communicator with respect to communicating with business people. People, for example, say about me that I am really good at communicating to people who are in deep love of research, but when I present arguments of similar clarity to business people, my often somewhat abstract considerations typically go over their heads.


> AI generates code fast but then you're stuck reading every line because it might've missed some edge case or broken something three layers deep

I will imagine that in the future this will be tackled with a heavy driven approach and tight regulation of what the agent can and cannot touch. So frequent small PRs over big ones. Limit folder access to only those that need changing. Let it build the project. If it doesn't build, no PR submissions allowed. If a single test fails, no PR submissions allowed. And the tests will likely be the first if not the main focus in LLM PRs.

I use the term "LLM" and not "AI" because I notice that people have started attributing LLM related issues (like ripping off copyrighted material, excessive usage of natural resources, etc) to AI in general which is damaging for the future of AI.


> I use the term "LLM" and not "AI" because I notice that people have started attributing LLM related issues (like ripping off copyrighted material, excessive usage of natural resources, etc) to AI in general which is damaging for the future of AI.

I think you have that backwards.

The resource and copyright concerns stem from any of these "AI" technologies which require a training phase. Which, to my knowledge, is all of them.

LLMs are just the main targets because they are the most used. Diffusion models have the same concerns.


> I often ask it "I have this bug. Why?" And it almost always figures it out and fixes it. Huge code base.

Is your AI PR publicly available in github?


No. I don't do any open source work. I work for a private company.


These two things are not mutually exclusive.


> Not my experience. It excels in existing codebases too.

Why don't you prove it?

1. Find an old large codebase in codeberg (avoiding the octopus for obvious reasons)

2. Video stream the session and make the LLM convo public

3. Ask your LLM to remove jQuery from the db and submit regular commits to a public remote branch

Then we will be able to judge if the evidence stands


I don't have to prove it. I do it every single day at work in a real production codebase that my business relies on.

And I don't remove jQuery every day. Maybe the OP is right that Opus 4.6 sucks at removing jQuery. I don't know. I've never asked an AI to do it.

    The moment you point it at a real, existing codebase - even a small one - everything falls apart.
This statement is absolutely not true based on my experience. Codex has been amazing for me at existing code bases.


Extraordinary claims require extraordinary evidence. "Works on my machine" ain't it.


Is it an extraordinary claim that Opus 4.6 or GPT 5.3 works amazing on existing code bases in my experience?

That's funny. I feel like it's the opposite. Claiming that Opus 4.6 or GPT 5.3 fails as soon as you point them to an existing code base, big or small, is a much more extraordinary claim.


What are the obvious reasons?


I thought it would be obvious: OpenAI has used repos on GitHub as training data. Would be like testing someone using a past paper publicly available.

Are you planning on carrying out the experiment? Regardless of the outcome, it would be of value to developers.


Why wouldn't they train on Codeberg too?

It's pretty hard to block automated uses of "git clone".


Why would they? Github has 28 million public repos, Codeberg only hit 300k last year. Anyway, Codeberg was just a placeholder for 'repo source _less_ likely to be in their training data'. Codeberg was quick candidate for a place to find a big old codebase with non-sensitive data.

It is indeed hard but the guys at Codeberg are certainly an order of magnitude better than Github as they opted out of the main AI crawlers, regularly block IPs known to belong to AI startups and they allow you to make your repos only be accessible to logged in users.

You seem be going on a tangent, here. Main point was about performing a well documented test anyway.


My question about the "obvious" thing was genuine - it wasn't obvious to me.


For the oblivious: /s


This one is a lot harder to tell because there are some AI bros who claim similar things but are completely serious. Even look at Show HN now: There used to be ~20-40 posts per day but now there are 20 per HOUR.

(Please oh please can we have a Show HN AI. I'm not interested in people's weekend vibe coded app to replace X popular tool. I want to check out cool projects wher people invested their passion and time.)


Consensus. People like to follow what the majority does even if it's suboptimal.


not just like to follow, but are forced to follow.


> Crucially the end user should then be ASKED which to enable

This doesn't work for literally 99.9% of the users out there. This is a classic HN's Dropbox symptom.

You need overridable defaults.


You should wonder whether any of those devs will train themselves to become engineers and whether the supply of engineers will be lower than the demand for them. Because if any of them become true, you will likely struggle to keep your employee stats relatively the same (ie you will struggle in very specific ways) unless you are the kind of person who doesn't need to interview to land a gig at a top 10 tech company.


> I'm struggling to think of any scenario that doesn't also put most white collar professions out of work alongside me

You don't need to be out of a job to struggle. Just for your pay to remain the same (or lower), for your work conditions to degrade (you think jQuery spaguetti was a mess? good luck with AI spaguetti slop) or for competition to increase because now most of the devving involves tedious fixing of AI code and the actual programming heavy jobs are as fought for as dev roles at Google/Jane Street/etc.

Devving isn't going anywhere but just like you don't punch cards anymore, you shouldn't expect your role in the coming decades to be the same as the 90s-25s period.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: