Karrot_Kream

It's largely because when Electron first came out the browser app platform (the API availability, performance, etc) was still quite thin and Electron was quite slow. HN just got stuck in this echo that web browsers are very inefficient and have no benefits while native apps are so much better. Java had the same echo for a long time on nerd forums because the JVM was a lot slower than native compiled apps for the first few years of its development.

In practice since then, browser-based apps ended up eating a lot of the demand for native apps and the web browser as a platform ended up displacing a lot of native apps, but the echo has stayed around here with little grounding. As such the distribution, security, and performance posture for browser and mobile apps has become a lot better while native app toolkits have lagged behind.

There's certainly a possibility that agentic development will make native development "cheap" again and encourage a lot more of it. But the web platform's security posture is much more well fleshed out at this point so I'm not sure.

The big lift with LLMs, causing them to really explode in real-world capability, has been tool calling. Dumping data into the LLM only really works if the data fits very, very comfortably in the context window. The way the best harnesses work is that they provide the LLM a bundle of tools to manage context and memories on its own, and let the LLM use these tools to manage its understanding of the world.

The problem with these Garmin and Strava AI summaries is that most of them just point an LLM at a heap of data and ask them to offer a summary. They also usually use older models since the feature is not something particularly well curated. I do financial modeling with LLMs and use the LLMs to build/verify/iterate on models.

If you're curious on what it takes to run long-running tasks Anthropic has https://www.anthropic.com/research/harness-design-long-runni... out.

> The fear might be real in the minds of the decision makers but that doesn't mean it's well founded or the policies that arise out of it are not wasteful.

I mean I 100% agree with this by the way. We tried to tell the DOT to look at its own stats. The one lawsuit they actually paid out in was from street design before the formation of the DOT itself and the fact that they fell behind on the paving schedule. If you actually amortize the payout over 30 years (I think the city has had one of these roughly every 30 years) it ends up being some minuscule part of the budget. But they still shut us down.

No it's not. I think it's a good financial literacy exercise to figure out how to exclude companies from index investments btw. I think it's perfectly reasonable for people to want to exclude certain companies from their portfolios for any number of reasons and I think it's a good thing to think about over all.

> Nah, that's just the bullshit they tell you.

I mean, this is the "bullshit" that our DOT told us when talking about guerilla urbanism at a real city meeting. I agree that it's frustrating, but it is what we were told. I don't know how to "disprove" a defensive posture. And yes, our city goverment has been sued in cases on the grounds of poor street design (though they've only had to pay out once in 20 years.)

> The bureaucracy is put in place because none of the people putting it in place are paying for it, headcount is power, control over resources is power, etc, etc, and all the other perverse incentives you see in government workplaces. And of course once the gravy train is running all these parties have an incentive to keep it running.

Do you have any real experience in city or local government?

Changes are stymied by bureaucracy put in place due to fear of litigation. The primary reason that things are studied, studied again, given community input, and checked for environmental impact is that if a city or municipality gets sued due to a road change, the onus is on them to demonstrate that they didn't create an unsafe condition. For example in cases where cars crash and are liable for property damage, car owners try to sue the city to claim that the area was unsafe. Pointing to a massive paper trail like this removes liability from a set of city or municipal concerns.

I think Google Search is an interesting outlier case here and Search comes from before the SaaS boom when tech companies were more compute heavy (because of colos.) Meta and LinkedIn also have huge datasets (their social graphs) but extra costs associated with storing and indexing those tend to scale with users on the platform. The growth story of the 2016+ SaaS boom was largely in these companies where compute costs scale with revenue.

Google is also a lot more than just search. Services like Gmail or Gdocs scale much more similarly to other SaaS.

Ultimately the question is whether there's a pareto optimal point for intelligence models. There's 2 potential worlds:

1. Frontier models are so good that the token cost of an average task becomes miniscule, so users are incentivized to use frontier models because their sheer intelligence makes them cheaper to use.

2. There is a pareto optimal point where even if you spend more on tokens overall profits decrease because token costs rise faster than revenue does.

The "no lab has a clear lead" world leads to 2.

Ultimately it's marginal, meaning that every $ of revenue that Google and Meta make have an associated compute cost with it, but scale your revenue down and you scale compute down also. Moreover this compute cost per revenue is fairly low. A small cloud instance equivalent's of compute can generate a ton of business value.

The big foundational labs are not like this. Every model they release takes a ton of data infrastructure and training (pre, train, post) compute. Then inference itself requires compute. Even if the labs sell tokens, each token embodies a lot of training and inference compute. This is a much more capital heavy business, so I can see revenue multiples being smaller than pure SaaS businesses. A model release bust (like Opus 5) ends up leading to big losses because of the necessary training compute spent on the model and the labor spent on training. A bust SaaS product ends up being wound down quickly, and only costs the labor spent on building it and the compute spent running it.

A good analogy is chip companies before all of the AI related compute pressure. These were largely low margin businesses because of the fixed capital cost associated with each new chip gen, architecture, process, etc

Better. I've implemented a system to block commenters that I don't like since I wrote that. You're about to go on that list, thanks.

> If you're willing to buy that will be possible, then my guess is that it will occur in the form of small scale startups and actual mavericks rather than someone trying to run an existing business who will simply be too risk adverse to go all in when the time comes. Some guy in his basement is more likely to leverage AI "properly" to build an actual "AI-native" engineering org because that person won't have much to lose.

FWIW I think the company writing this post is one of those small scale startups. But that being said, you're not the only one who thinks this. A decent amount of VCs and funds think that only smaller, newer companies have the potential to be truly AI native because there's too much organizational inertia in an existing business in keeping its existing human processes and so only a newer company can achieve the true "scaling potential" or using AI to scale without human labor.

This is a 25 eng startup. Anything can go wrong here. A hike in interest rates can lead to a down round causing the company to go into cost cutting mode, leading to a decrease in product velocity and prod incidents as infra is cut to the bone, in order to cope. Your top engineer can get sick and quit and your next in line isn't strong enough to keep the ship going.

I'm curious if you've ever worked at a startup, tried to invest in a startup, or considered purchasing a startup's product to know what it's like? The whole point is you're taking a risk trying something new and different. If you're just doing what a much bigger, established company is doing, you're fighting against an incumbent who already has much lower COGS than you.

Taking a bet on being AI-native as a startup is taking a bet that use of AI will result in lower COGS than the incumbent. As the old saying goes, "Nobody got fired for buying IBM", and yet Amazon was able to crack into that space by doing something novel. If Amazon was just IBM, why not buy IBM? The ultimate test of AI-native business models will be if these companies become the Amazon of today, or whether we'll write about them the way we wrote about "fifth generation computing" in Japan.

> It was the article that used metrics related to engineering velocity as evidence of success

Success for what? The article opened with: "Last week Will Larson (@Lethain ) asked how leaders are evaluating engineering managers for AI skills. My reply , a list of questions to think about, got a lot of bookmarks. More broadly, I've been thinking about how to build an AI-native engineering org for a while. Sharing some lessons from the last nine months of building at FurtherAI."

The opener is "how to build an AI-native engineering org" and the context is a company of roughly 22 engineers (from a reply.) Nothing here says "evidence of success"

> I don’t see how asking how this ties back to core business results is thinking about it at the wrong level.

In an company of 22 engineers, how would you make these measurements? Would you split your company into a velocity focused group and a quality focused group and make them compete? How? What would a customer motion look like? What would these groups share? This makes no sense. This is like asking a small company to A/B test teams that used a computer vs didn't use a computer.

A larger, more mature organization has the luxury of splitting business units into AI-native vs not-AI-native workflows and comparing COGS/business objectives against each other. I know of very large tech consulting services who did exactly this around the beginning of the cloud era to figure out which aspects of their business they wanted to place on clouds and which aspects they kept on-prem, and even then that was messy because part of the value of on-prem is the scale benefit you get by owning and operating your own DC. But no 22 person engineering team I saw A/B tested this out. Companies were founded either with a cloud-first philosophy or an on-prem philosophy.

You're thinking about this at the wrong level. This org has made the decision to be AI-native. They aren't A/B testing being AI-native vs not being AI-native. That's the kind of thing "the market" does; if a company's markup is higher than another's it can attract more investment or its equity can trade for higher pricing on public markets.

I don't think it makes sense to A/B test "AI-native" vs other regimes of development unless you are a large, decentralized company like an F5 company or a Big Tech. How will a team of 25 (the size of the company if you read the thread) have enough output to even A/B test the difference?

Back when I managed teams that dealt with API traffic at a unicorn, this wasn't the case. We'd ban a /32 and several times customers would start reaching out to our support portal (which ran behind different ingress rules) asking why they couldn't use the site a couple weeks later.

I've never worked on the ISP side so there's no doubt that there is a process at the competent ones, but my guess is most users do not have a competent one.

Until a service's WAF catches your /32 because your ISP had previously handed it out to a spammer.

There's more that's been written about configuring/protecting IPv4 networks and if you learn about network security from a mentor or from coworkers at a job, rather than reading books/the internet/LLMs, you're more likely to learn about IPv4 security.

But if you've ever had to deal with endpoint security, if you're just doing static rule based blocking/throttling, /32 or /24 blocking is often your best option. Thanks to CGNAT this often means having a pretty large impact since an ISP's residential customer might end up getting randomly assigned a "bad" address and the cooldown for these rules is often months long or more.

In IPv6 land, you can just block a /128 or even a /64 and rarely hit anyone else in the crossfire.

Almost all of my tech worker friends use Instagram. It's almost universally used. I never talk about it because anything positive about any Meta property on this site gets downvoted. It's been like this for years and only gotten worse over time.

The "average worker" ends up getting more wealthy because younger, newer employees who grow up native to the new technology often capture its upsides at the expense of older workers who were unable to. The Rust Belt is a great example of this because most kids ended up migrating out to cities for work while their parents or the less successful ones ended up stuck.

There's a lot of questions right now.

1. Will there be a net-new creation of jobs? Is positive-sum knowledge work a real thing, or have we run out of new jobs to create?

2. How quickly will workers transition to an AI version of their jobs?

3. Will AI even succeed in a broad way across knowledge work or will the frontier of AI remain jagged and only impact some jobs (coding) while leaving others alone?

4. For workers left behind in this transition, what will their lives be like? We know from looking at previous technology transitions (industrial revolution, factory automation, computer revolution, now maybe AI revolution) that many workers really do end up in bad places. It's perfectly reasonable to demand that in today's world in our advanced societies that even if those workers are unable to adapt that they are able to lead lives with dignity.

There's a lot of interesting conversations and investigations to be had but my biggest fear is just that nobody is really willing to listen to the other side with empathy. This entire conversation thread is just people snipping at each other, hitting the vote buttons based on where they want to steer their favorite opinion. If you want to do social and economic science in this space but people are so polarized, the work will be thwarted. In general offline spaces are less polarized (not to be mistaken for pro or anti AI disruption) than online spaces, but my fear is that we continue to polarize, making understanding the fabric of our social change challenging and letting down everyone in the process.

FWIW it's quite easy to farm karma to get to the downvote threshold. If you go to any of the energetic political HN threads, you just need to submit an enthusiastic comment that is pro the dominant position and you'll get tens of upvotes quite quickly. Do that for a week and you'll be ready to downvote. Before HN had LLM detection I had an experiment with an LLM doing that (though I approved everything it wrote by hand) and farmed karma very quickly. I stopped because I felt quite gross about it, but realize it's probably trivial to do now.

The problem isn't really the site, it's the people. People like smashing the up and down buttons on things they agree with and unfortunately a comment's score affects where it shows up on the page.

Elisp is homoiconic and has a strong culture of REPL development, but really the thing that makes elisp so nice is that it has decades of use to iterate on an editor. There's an attempt to do this with Common Lisp that's quite cool, called Lem, but the sheer amount of person-years that have gone into making emacs and elisp a conjoined system makes it a pleasure to use and iterate on. Lem, in comparison, is building up all the UX associated with a "live programming environment" that just comes out of the box with elisp (though I, personally, prefer Common Lisp as a language/environment.)

Pre-LLM I used to spend the occasional afternoon at work when I was a bit demotivated just adding new features to my emacs or fixing small papercuts in the environment. Now I largely have the LLM work on it for me, though I separate out LLM code from my own by loading them separately in my config.

I don't think this is true for most people on the big issues but do think it's true for a lot of small issues. Reddit (and HN) lead to a lot of pageant show dynamics where the people with the time to hit the buttons decide what content to boost. Small Discord communities are free from that.

I don't know how much they can do. I don't want to speak for the mods, but most of the problems on this site come from upvotes and downvotes. I guess some cheap things you can do are increase the karma threshold required to downvote and apply a smoothing function to upvotes (like quadratic voting for vote scores, aka n votes on a comment bumps the score up by sqrt(n).)

But ultimately a site moderated by up and downvotes that wants to keep a relatively light hand on moderation is going to end up like what HN is today. Changing the voting structure on the site or the moderation POV on the site would be a radical change and could change the entire site's culture drastically.

I have an ongoing analysis and here's some highlights so far: https://news.ycombinator.com/item?id=50225117 tl;dr things don't looks good

Classifiers can require a lot of examples to train correctly. You can take a decision model's outputs and apply platt scaling to arrive at a good decision boundary a lot faster.

Eventually, yes, it makes sense to move to a pure classifier model as it's probably a lot cheaper. But then you need to learn how to serve your own classifier model correctly. Compute costs are being driven up by demand to serve models and unless you're careful it's easy to use your GPUs less effectively than a company specializing in serving a model.

Thanks for the pointers, I'm gonna look into them.

I'm not doing CPU inferencing but I'm doing some tokenization in Python which is CPU-bound. In all honesty I started on this project to scale the model and did not build it myself so have been trying to read code and walk back the approach. I've been thinking about rewriting the Python glue in Go to avoid issues with the GIL.

I've been an emacs user for most of my life, before I even went to college. I took a brief (5 years) tour into IDEs for writing code on the job, but the moment agents became a viable way to develop code I switched back into emacs. I love reviewing changes in magit.

I'm pretty sure many folks put up with the bloat of IDEs just for the functionality they offered. Now, they're hopping back to emacs, vim, sublime, whatever their heart desires.

> But I don't think it's unique to any profession or individual that they tend to care the most deeply when it hits them directly.

Sorry, I didn't mean to imply that. I just meant that part of the unique feelings in the air for software engineers is that this is the first time we're facing this.

> I still think of management consultants as some of the highest paid careers around, and getting a partnership track job at one of the Big 3 is one of the most desirable jobs

There's plenty of other jobs the MBA type could get into these days which are also high prestige and there are now many more tiers of management consultants. The elite folks at McKinsey are still high prestige with high salaries, but your average Accenture or Deloitte consultant is both pay and prestige wise about the same as an average knowledge worker. Plenty of VCs, fund managers, and investors are high prestige MBA-types. The explosion of private capital means there's a lot of opportunity to manage private capital; private capital markets were just much shallower 50 years ago.

I used Opus 5.5 to figure out that a language model we were serving at work for internal use (we don't really serve models, we only use this internally because it processes sensitive data that we can't send to external endpoints) was being bottlenecked by CPU contention on tokenization, by having Opus run in an autoresearch style loop.

Opus's first proposal for a fix was to spawn multiple Python processes and build a load balancer between them in Python. At first I asked it why it wasn't using haproxy and it said that haproxy would be an added dependency and that the overhead for this kind of thing in Python would be negligible. I knew this was idiotic but wanted to test this out, so had Opus run two experiments in parallel. Sure enough an haproxy load balancer was much, much better on HTTP load balancing than Python code was.

This is the kind of thing that if you're unfamiliar with how networking code works, the models can autopilot into bad decisions that are verifiably correct (higher throughput than the original CPU-bottlenecked implementation) but much short of best practice.

Plenty of other professions were hit by computing. Part of why programmers are so emotive about this concept (other than the fact that emoting online loudly seems to be much more accepted in software than other professions) is that programming has never been threatened in the same way as other professions have been until now.

My parents-in-law started their careers as management consultants. The job in their time was much higher prestige and much higher value than it was when I started my career; free flow of information over the internet and commodification of spreadsheets changed all of it. From my parents' generation, I know practical effects folks who became unemployable once movies went to digital effects; engineers who found their draftsmanship skills obsolete. Folks with near-photographic memories whose entire superpower was destroyed by computing. I personally grew up in a blue collar community that was income depressed because its labor became commodified, though that was due to mechanization.