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.