It's fair to say that if all these operators are competing for tokens, that the OpenRouter token operator (not sure the exact phrase but the people running the models) are accounting for some level of margin.

However, how many of these are running their own data centers and GPUs?

If they are running their own infrastructure, then it's not a simple equation of if each specific token set is profitable, since it needs to account for the cost of running the data center. It could be that they believe that it is profitable in the long term by utilizing the long tail of asset depreciation, but that isn't guaranteed.

IF they aren't running their own infrastructure, then it's much easier to claim that it's profitable and has a margin (outside of running their servers to manage the rented infrastructure).

HOWEVER, a lot of data centers have some pretty crazy low prices for GPUs that may be vying for user base and revenue over profitability. In these cases, if data center growth starts slowing due to slower buildout then it's very likely GPU prices go up and inference stops becoming profitable for the open router owners.

So long term it's not clear how profitable even these open models are.

OpenAI and Anthropic definitely fall into the latter category too. Their infrastructure requirements are much higher than the open models, and they are being given huge discounts so Microsoft/Amazon/Google can all claim revenue (since they have profitability coming from other parts). It's not clear if OpenAI and Anthropic models would be profitable at inference if they were paying rates that cloud hosts would make a profit from.

There's just way too many dimensions to this scenario to flat out state that open router proves inference is profitable at scale.

There is case law surrounding the fact that just because you commission a work to another entity doesn't give you co-authorship, the entity doing the work and making creative decisions is the entity that gets copyright.

In order for you to have co-authorship of the commissioned work you have to be involved and pretty much giving instruction level detail to the real author. The opinion shows many cases that its not the case with how LLM prompts work.

The monkey selfie case is relevant also because since it also solidifies that non-persons cannot claim copyright, that means the LLM cannot claim copyright, and therefore it does not have copyright that can be passed onto the LLM operator.

> Abstract > > AI assistants, like GitHub Copilot and Cursor, are transforming software engineering. While several studies highlight productivity improvements, their impact on maintainability requires further investigation. [Objective] This study investigates whether co-development with AI assistants affects software maintainability, specifically how easily other developers can evolve the resulting source code. [Method] We conducted a two-phase controlled experiment involving 151 participants, 95% of whom were professional developers. In Phase 1, participants added a new feature to a Java web application, with or without AI assistance. In Phase 2, a randomized controlled trial, new participants evolved these solutions without AI assistance. [Results] Phase 2 revealed no significant differences in subsequent evolution with respect to completion time or code quality. Bayesian analysis suggests that any speed or quality improvements from AI use were at most small and highly uncertain. Observational results from Phase 1 corroborate prior research: using an AI assistant yielded a 30.7% median reduction in completion time, and habitual AI users showed an estimated 55.9% speedup. [Conclusions] Overall, we did not detect systematic maintainability advantages or disadvantages when other developers evolved code co-developed with AI assistants. Within the scope of our tasks and measures, we observed no consistent warning signs of degraded code-level maintainability. Future work should examine risks such as code bloat from excessive code generation and cognitive debt as developers offload more mental effort to assistants.

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

Points: 2

# Comments: 2

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

Points: 7

# Comments: 0

No idea if signing up gives the full survey for free. We get it through our company paying for DX's services

Past survey results are hidden in some presentations I've seen, and the latest survey I have full access due to my company paying for it. So I'm not sure it's legal for me to reproduce

Staff engineers get the most time savings out of AI tools, and their weekly time savings is 4.4 hours for heavy AI users. That's a little more than 10% productivity, so not anywhere close to 10x.

What's more telling about the survey results is they are also consistent in their findings between heavy and light users of AI. Staff engineers who are heavy users of AI save 4.4 hours a week while staff engineers who are light users of AI save 3.3 hours a week. To put another way, the DX survey is pretty clear that the time savings between heavy and light AI users is minimal.

Yes surveys are all flawed in different ways but an N of 20k is nothing to sneeze at. Any study with data points shows that code generation is not a significant time savings and zero studies show significant time savings. All the productivity gains DX reports come from debugging and investigation/code base spelunking help.

It could just be a compiler error/warning that has to be explicitly opted into to touch those fields. This allows you to say "I know this is normally a footgun to modify these fields, and I might be violating an invariant condition, but I am know what I'm doing".

This all started with a "simple" premise, can you use the .net runtime as a just-in-time compiler for any language. 2 months later and now I have a fully working code base that can compile most 6502 functions into MSIL and execute them on demand.

It achieves this by instantiating a memory bus with any memory mapped I/O devices you may have the need for, and which memory regions they map to. For the NES, this includes the CPU ram (and its mirrored regions), the PPU device, the cartridge space, etc...

Then the JIT compiler is told to run the function at a specific address. The JIT compiler then:

1. Traces out the function boundaries of the function using the passed in address as the entry point.

2. After all instructions and their ordering is determined, the instructions are disassembled.

3. The 6502 disassembled instructions are converted to one or more intermediary representation instructions

4. A JitCustomization process is run that allows different emulators/hardware setups to modify how the IR instructions are set up. This also allows for analysis and optimization passes.

5. The final set of IR instructions are passed one by one into a MSIL generation class, and the MSIL is written to the `ILGenerator`

6. This IL is then added into an assembly builder and compiled on the fly, providing a static .net method containing that function's code.

7. The JIT compiler then turns that function into an Executable method delegate and executes it

8. The function runs until a cancellation token gets a cancellation signal, or the function hits a return statement with a new address of a function to call. The JIT compiler then repeats this process, but now with the function at the address returned.

This allows the above video, where NES games are running inside the .net runtime via MSIL. Since it is just-in-time compilation, in theory even arbitrary code execution exploits would be executable. The main bugs visible in SMB are due to my inaccurate PPU emulation and not about the 6502 code itself.

# Why An Intermediary Representation?

Creating MSIL at runtime is pretty error prone and is hard to debug. If you have one simple mistake (such as passing a byte into a `ldc_i4` emit call) you get a generic "This is not a valid program" exception with no debugging. So limiting how much MSIL I had to generate ended up pretty beneficial.

One significant benefit though is simplicity. The 6502 has 56 official instructions, each with some significant side effects. Creating MSIL for each of these with all the different memory addressing modes they could contain would spiral out.

However, it turns out you can create any 6502 instruction by composing about 12 smaller instructions together. This made it much simpler to write the MSIL for each IR instruction, and much easier test coverage to ensure they actually compile and work.

# Assembly Creation

There are code paths (disabled) that can actually create real dll files for each function generated. In theory this means that if you run an application for a sufficient amount of time, you could collect all the dlls and piece them together for a MSIL precompiled build.

# NES Limitations

The NES emulator side isn't complete. It can run games as long as they are up to 32k ROMs with 16K character data. This is just because I didn't bother adding support for all the different bank/memory switchers that cartridges implement.

# What's Next?

Not sure. I'm tempted to add some other 6502 emulations. Atari 2600 would work but may not be interesting. Using this to fully JIT the commodore 64 is something that is interesting, though I'm not totally sure how much of a rabbit hole emulating the video and other I/O devices would be.

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

Points: 1

# Comments: 0

If you look at the details of how Google got gold at IMO, you'll see that AlphaGeometry only relies on LLMs for a very specific part of the whole system, and the LLM wasn't the core problem solving system in play.

Most of AlphaGeometry is standard algorithms at play solving geometry problems using known constraints. When the algorithmic system gets stuck, it reaches out to LLMs that were fine tuned specifically for creating new geometric constraints. So the LLM would create new geometric constraints and pass that back to the algorithmic parts to get it unstuck, and repeat.

Without more details, it's not clear if this win is also the Gpt-5 and Gemini models we use, or specially fine-tuned models that are integrated with other non-LLM and non-ML based systems to solve these.

Not being solved purely by LLM isn't a knock on it, but with the current conversations going on today with LLMs, these are heavily being marketed as "LLMs did this all by themselves", which doesn't match with a lot of the evidence I've personally seen.

I try very hard to keep my PRs very focused on one complete unit of work at a time. So when the squash happens that single commit represents one type of change being made to the system.

So when going through history to pinpoint the cause of the big, I can still get what logical change and unit of work caused the change. I don't see the intermediary commits of that unit of work, but I have not personally gotten value out of that level of granularity (especially on team projects where each person's commit practices are different).

If I start working on one PR that starts to contain a refactor or change imthat makes sense to isolate, I'll make that it's own pr that will be squashed.

In a PR branch, my branches usually have a bunch of WIP commits, especially if I've worked on a PR across day boundaries. It's common for more complex PRs that I started down one path and then changed to another path, in which case a lot of work that went into earlier commits is no longer relevant to the picture as a whole.

Once a PR has been submitted for review, I NEVER want to change previous commits and force push, because that breaks common tooling that other team mates rely on to see what changes since their last review. When you do a force push, they now have to review the full PR because they can't be guaranteed exactly which lines changed, and your commit message for the old pr is now muddled.

Once the PR has been merged, I prefer it merged as a single squashed commit so it's reflective of the single atomic PR (because most of the intermediary commits have never actually mattered to debugging a bug caused by a PR).

And if I've already merged a commit to main, then I 100% don't want to rewrite the history of that other commit.

So personally I have never found the commit history of a PR branch useful enough that rewriting past commits was beneficial. The commit history of main is immensely useful, enough that you never want to rewrite that either.