Jianghong94

Well I've done the same too. But I would not use my work PC.

Am I the only one baffled by the fact that the engineer uses a work PC for a personal job interview assignment?

lolol. Actually, I find AI has a reasonable chance to figure it out, as long as you point to the right source code. BTW to me these quirks actually can be used as some kind of job security. If it takes a year to onboard someone to do meaningful work, it sure raise the cost of firing.

What I imply from the description is that, the default ring contains some shared global public data (e.g. a cache of bloomberg informations), and each individual team will have their own rings. Afterall there's no that many you can fit into 16mb

Well I doubt these solutions are very useful outside; from what I read what they have is a universal data store (that isn't hard to implement using current off-the-shelf OSS), something for financial instruments that has a compositional nature (you won't encounter much of that in the outside world), plus some other quirky features.

I just went through a similar discussion in my $WORK (traditional finance company on NYSE with average IT expertise) and I think the thought process is as such: it's one thing to just give your stellar dev/hacker a beefy GPU server and run whatever model they can run; it's another thing to maintain such platform for company wide. You would need human resource (likely way above normal software dev paygrade) to understand and maintain such models, maintain backend, availability etc. All these extra hassle make it just easier to pay a top tier external lab + slap a reasonable spending limit on everybody.

Seriously, it's much easier to review the AI generated plan, instead of reviewing their code. What I found is that, if the change surface is small enough, AI can get it right under the correct assumptions, but the noob mistake is to let AI loose and come up with its own, often not correct assumptions. So you got to step in before they generate the whole slop...

You know the funny thing is that, the lazy engineer can very likely ask you to just scrap all his code and vibe code again.

Honestly I don't understand why they/any fast-and-error-prone model position themselves as coding agents; my experience tells me that I'd much rather working with a slow-but-correct model and let it run longer session than handholding a fast-but-wrong model.

This. At this point AI/LLM/Claude Code is still a power user tool; the more you know about your domain + the more you're willing to reasonably use it, the more gain you have.

That being said the real danger is not coming from AI today, it's more C-suites believing AI can just zero shot any problem you throw at it.

Well, like I said, there're hidden incentives behind the scene; in my case, the hidden incentive is that, the requester/client is one of the company's subpar broker, and PM probably decided to just offer an average level of commitment, not going above and beyond. Hence the plan was to do exactly what the broker want even though that was messy and inferior. You can't just write down that kind of motivation on paper anywhere.

--- I said it because I did the analysis, and realized that if I implement the original version, which basically is a crazy way to iteratively solve the MIP problem, it's much harder to reason with internally, and much harder to code correctly. But obviously it keep the broker happy (the developer is doing exactly what I said)

Maybe I'm being naive here, but for AI (heck, for any good algorithm) to work well, you need some at least loosely-clearly defined objectives. I assume it's much more straightforward in semi, but there're many industries, once you get into the details, all kinds of incentives start to disalign and I doubt AI could understand all kinds of nuances.

E.g. once I was tasked to build a new matching algorithm for a trading platform, and upon fully understanding of the specs I realized it can be interpreted as a mixed integer programming problem; the idea got shot down right away because PM don't understand it. There're all kinds of limiting factors once you get into the details.

I believe so, see my result with Haiku extended thinking on. I think the weights are just too biased towards blurping out the majority of the training data of 'next year is xxx'. Interesting problem to solve indeed.

I think the current trick for LLM API provider is to insert the today is $DATE into the system prompt, so maybe it's worthwhile to do that and see if that automatically fixes those OSS models?

I did a similar test especially with the extended thinking on and off for Haiku, and once you have extended thinking on, the result is more or less the same as Sonnet.

Thought process: The user is asking if 2026 is next year. According to the context, today's date is Tuesday, December 02, 2025. So the current year is 2025. That means next year would be 2026. So yes, 2026 is next year.Yes, 2026 is next year. Actual resp Since we're currently in December 2025, 2026 is just about a month away.

I don't think JB UIs been changing that much, albeit I haven't been working in the industry long enough. I think the last major UI redo was like 2,3 years ago and most of it is to make UI more compact, and I definitely like it. That being said YMMV.

IMHO another good thing of using JB IDE git UI (especially in a corporate setting) instead of using another software is that everyone has the IDE so it's easier to collaborate. Imagine if you're helping a junior member debug their local branch and they don't have lazy git installed.

Wait, no one mentions the default JetBrains IDE git UI? I mean, I get it if you're working from another IDE/text editor that doesn't have good git UI support out of the box, but JB's git UI is reasonably good enough that I don't want anything else.

Things that I use (and I like): 1. quick checkout to another branch and automatically stash and unstash your local changes; when I just need to inspect code elsewhere I find it really useful. My changes are small so I can always remember to stash them later; 2. compare branch/commit etc via UI; again I know you can do that in git diff, but then you would need to know the command and the commit SHA to compare; in UI it comes in really handy, just select the branch or commits you want to compare and that's it. I've seen my coworkers trying to come up with the command and I just say: use IDE and a couple of clicks they got it working. 3. filter commits by user and by folder.

An even more grotesque practice is to charge a stratosphere level premium for the product itself AND put its control behind a subscription e.g. 8sleep

this seem solvable if the whitelisting just allows regex

My take is that it's a standalone business consideration: Apple users are more inclined to pay for software (definitely the case for iPhone vs. Android, although I haven't found a source for Windows).

OR problems are hard because whoever try to vibe coding it probably don't realize they fall into a specific algorithm and can prompt llm to do thatl; what's worse is that even if you tell them so they won't be able to understand the math behind it and would much prefer their vide coding solution.

Not only does the article claim that when we get to self-improving ai it becomes generally intelligent, it's assuming that AI is pretty close right now:

> OpenBrain focuses on AIs that can speed up AI research. They want to win the twin arms races against China (whose leading company we’ll call “DeepCent”)16 and their US competitors. The more of their research and development (R&D) cycle they can automate, the faster they can go. So when OpenBrain finishes training Agent-1, a new model under internal development, it’s good at many things but great at helping with AI research.

> It’s good at this due to a combination of explicit focus to prioritize these skills, their own extensive codebases they can draw on as particularly relevant and high-quality training data, and coding being an easy domain for procedural feedback.

> OpenBrain continues to deploy the iteratively improving Agent-1 internally for AI R&D. Overall, they are making algorithmic progress 50% faster than they would without AI assistants—and more importantly, faster than their competitors.

> what do we mean by 50% faster algorithmic progress? We mean that OpenBrain makes as much AI research progress in 1 week with AI as they would in 1.5 weeks without AI usage.

To me, claiming today's AI IS capable of such thing is too hand-wavy. And I think that's the crux of the article.

Putting the geopolitical discussion aside, I think the biggest question lies in how likely the *current paradigm LLM* (think of it as any SOTA stock LLM you get today, e.g., 3.7 sonnet, gemini 2.5, etc) + fine-tuning will be capable of directly contributing to LLM research in a major way.

To quote the original article,

> OpenBrain focuses on AIs that can speed up AI research. They want to win the twin arms races against China (whose leading company we’ll call “DeepCent”)16 and their US competitors. The more of their research and development (R&D) cycle they can automate, the faster they can go. So when OpenBrain finishes training Agent-1, a new model under internal development, it’s good at many things but great at helping with AI research. (footnote: It’s good at this due to a combination of explicit focus to prioritize these skills, their own extensive codebases they can draw on as particularly relevant and high-quality training data, and coding being an easy domain for procedural feedback.)

> OpenBrain continues to deploy the iteratively improving Agent-1 internally for AI R&D. Overall, they are making algorithmic progress 50% faster than they would without AI assistants—and more importantly, faster than their competitors.

> what do we mean by 50% faster algorithmic progress? We mean that OpenBrain makes as much AI research progress in 1 week with AI as they would in 1.5 weeks without AI usage.

> AI progress can be broken down into 2 components:

> Increasing compute: More computational power is used to train or run an AI. This produces more powerful AIs, but they cost more.

> Improved algorithms: Better training methods are used to translate compute into performance. This produces more capable AIs without a corresponding increase in cost, or the same capabilities with decreased costs.

> This includes being able to achieve qualitatively and quantitatively new results. “Paradigm shifts” such as the switch from game-playing RL agents to large language models count as examples of algorithmic progress.

> Here we are only referring to (2), improved algorithms, which makes up about half of current AI progress.

---

Given that the article chose a pretty aggressive timeline (the algo needs to contribute late this year so that its research result can be contributed to the next gen LLM coming out early next year), the AI that can contribute significantly to research has to be a current SOTA LLM.

Now, using LLM in day-to-day engineering task is no secret in major AI labs, but we're talking about something different, something that gives you 2 extra days of output per week. I have no evidence to either acknowledge or deny whether such AI exists, and it would be outright ignorant to think no one ever came up with such an idea or is trying such an idea. So I think it goes down into two possibilities:

1. This claim is made by a top-down approach, that is, if AI reaches superhuman in 2027, what would be the most likely starting condition to that? And the author picks this as the most likely starting point, since the authors don't work in major AI lab (even if they do they can't just leak such trade secret), the authors just assume it's likely to happen anyway (and you can't dismiss that). 2. This claim is made by a bottom-up approach, that is the author did witness such AI exists to a certain extent and start to extrapolate from there.

Well based on what I'm reading, the OP's intent is that, not all (hence 'fully') validation, if not most of, can be done in-silico. I think we all agree that and that's the major bottleneck making agents useful - you have to have human-in-the-loop to closely guardrail the whole process.

Of course you can get a lot of mileage via synthetically generated CoT but does that lead to LLM speed up developing LLM is a big IF.

Yep that's what I've been thinking. This shouldn't be that hard, at this point LLMs should already have all the 'rules' (e.g. credit card A buys flight X give you m point which can be converted into n miles) in their params or can easily query the web to get it out. Dev need to encode the whole thing into a decision mechanism and once executed ask LLM to chase down the specific path (e.g. bombard ticket office with emails).

Now THAT's the workflow I'd like to see AI agent automate, streamline and democratize for everybody.

Superhuman results 1/10 are, in fact, a very strong reliability guarantee (maybe not up to today's nth 9 decimal standard that we are accustomed to, but probably much higher than any agent in real-world workflow).

I guess the primary reason is that the answers must be numbers that can be verified easily. Otherwise, you just flood the validator with long LLM reasoning that's hard to verify. People have been proposing using LEAN as a medium for answers but AFAIK even LEAN is not mainstream in the general math community, so there's always trade-offs.

Also, coming up with good problems is an art in its own right; the Soviets was famous for institutionalizing anti-Semitism via special math puzzles for Jews in Moscow Univerisity entrance exams. The questions are constructed as such that are hard to solve but have some elementary solutions to divert criticism.

Due to the extreme data quantity requirement for pre-training, LLM effectively locks your reasoning language into the lowest common denominator, aka Python. Sure, people (maybe very smart) can come up with reasonable, effective, efficient notation; the problem is to train the model to use it properly.

I assume 97 <- 47+50? (although I'm not sure where the 13 and 14 respectively come from)