Centralized MCP server over HTTP that enables standardized doc lookup across the org, standardized skills (as MCP prompt), MCP resources (these are virtual indexes of the docs that is similar to how Vercel formatted their `AGENTS.md`), and a small set of tools.
We emit OTEL from the server and build dashboards to see how the agents and devs are using context and tools and which documents are "high signal" meaning they get hit frequently so we know that tuning these docs will yield more consistent output.
OAuth lets us see the users because every call has identity attached.
You jest but I was flabbergasted when doing some AI backed feature that the fix was adding a "The result you send back MUST be accurate." to the already pretty clear prompt.
I was wondering if/when this would happen. My friends and I would discuss this at the pub all the time, "LLM2RTL" or take it a step further and do the the whole process "LLM2GDS".
I couldn't find much info here, but I'm guessing they've built tooling to automatically convert model weights to RTL and the reason it's such an old model is that it takes a long time tape a chip out (especially the first one). Would be interesting to know how much is automated and how much is handcrafted.
I think the "next big thing" with AI hardware will be when they switch from "digital" implementations of LLMs to "analogue". We already know that we can lose some bits of precision and still have a "workable" model. If/when folks figure the fine-tuning out, I'm guessing it'll be another order of magnitude improvement.
> I've forgotten more things in this field than I'm comfortable with today. I find it a bit sad that I've completely lost my Win32 reverse engineering skills I had in my teens
I'm a bit younger (33) but you'd be surprised how fast it comes back. I hadn't touched x86 assembly for probably 10 years at one point. Then someone asked a question in a modding community for an ancient game and after spending a few hours it mostly came back to me.
I'm sure if you had to reverse engineer some win32 applications, it'd come back quickly.
That's a skill onto itself, and I mean the general stuff does not fade or at least come back quickly. But there's a lot of the tail end that's just difficult to recall because it's obscure.
How exactly did I hook Delphi apps' TForm handling system instead of breakpointing GetWindowTextA and friends? I mean... I just cannot remember. It wasn't super easy either.
I want to second this. I'm 38 and I used to do some debugging and reverse engineering during my university days (2006-2011). Since then I've mainly avoided looking at assembly since I mostly work in C++ systems or HLSL.
These last few months, however, I've had to spend a lot of time debugging via disassembly for my work. It felt really slow at first, but then it came back to me and now it's really natural again.
It's interesting that China does not have exact data. Don't they require everyone to register their address? I know foreigners must do it, and chatting with the locals they told me they were registered as well.
I would have imagined that the data could be used to get mostly accurate numbers.
Even if they required it that's no guarantee people actually do it. I have lived for a couple of years at an address different than the one I was registered at. Illegal in my country, but easy to conceal. (I had to because the apartment I lived in didn't strictly allow people of my sort to permanently reside in it.)
I used to work in the semiconductor industry writing internal tools for the company. Hardware very rarely missed a deadline and software was run the same way.
Things rarely went to plan, but as soon as any blip occured, there'd be plans to trim scope, crunch more, or push the date with many months of notice.
Then I joined my first web SaaS startup and I think we didn't hit a single deadline in the entire time I worked there. Everyone thought that was fine and normal. Interestingly enough, I'm not convinced that's why we failed, but it was a huge culture shock.
> I used to work in the semiconductor industry writing internal tools for the company. Hardware very rarely missed a deadline and software was run the same way.
Former Test Engineer here. It was always fun when everyone else’s deadline slipped but ours stayed the same. Had to still ship on the same date even if I didn’t have silicon until much later than originally planned.
I think you were estimating time to build things that were out of R&D and you had specifications that were actual specifications you were building up to.
In SaaS my experience is: someone makes up an idea not having any clue how existing software is working or is laid out, has no specifications beside vague not organized bunch of sentences. Software development team basically starts R&D to find out specifications and what is possible - but is expected to deliver final product.
I had the same experience when doing an exercise implementing `mmap` for `xv6` -- that was the last lab. There was no specification except for a test file. Passing that test file is relatively easy and I could game it. I consulted the manpage of `mmap` but it is pretty far from a specification, so eventually I had to write a lot of tests in Linux to figure out what it can do and what it can't do (what happens when I over-mmap? what happens when I write back pass EOF? etc.), and write the same tests for `xv6` so that I could test my implementation. Not sure about hardware, but it is really hard to get a clear specification for software.
This aligns with my experience in the semi industry. SWEs tend to see trimming scope as moving the goalpost and do not consider as an option. Providing advance notice is mostly about client management, and clients are often surprisingly receptive to partial solutions.
That's fun to read, I remember when NoSQL was getting cargo-culted, it was specifically because it was more "agile". The reason being you don't need to worry about a schema. Just stick your data in there and figure it out later.
Interesting to hear now that the opinion is the opposite.
Unfortunately, nowadays writing userscripts is much harder than it used to be. Most websites are using some sort of reactive FE framework so you need to make extensive use of mutationObservers (or whatever the equivalent is in jQuery I guess).
I'm not a frontend dev but I came up with this and use it a lot in my userscripts. It's not the most efficient (it can certainly be refactored to create a MutationObserver singleton and then have each call hook into that) but it works well enough for my needs and lets me basically use an old-school to dealing with reactive sites (so long as you are fine with using async):
function awaitElement(selector) {
return awaitPredicate(selector, _ => true);
}
function awaitPredicate(selector, predicate) {
return new Promise((resolve, _reject) => {
for (const el of document.querySelectorAll(selector)) {
if (predicate(el)) {
resolve(el);
return;
}
}
// Create a MutationObserver to listen for changes
const observer = new MutationObserver((_mutations, obs) => {
// You could search just inside _mutations instead of the entire DOM.
// Efficiency will depend primarily on how precise your selector is.
for (const el of document.querySelectorAll(selector)) {
if (predicate(el)) {
resolve(el);
obs.disconnect(); // Don't forget to disconnect the observer!
break;
}
}
});
// Start observing the document
observer.observe(document.documentElement, {
childList: true,
subtree: true,
attributes: false,
characterData: false,
});
});
}
Very true. I guess that depends on what websites you find issues with? I just checked mine and all of those are quality of life improvements for fully server rendered sites like HN or phpBB forums.
Yeah, I mostly use it for QoL improvements but for work related things. So Jira, Bitbucket, GitHub, Linear etc. basically whatever my employer uses. Back in the early 2010s most of that software was fully server rendered. Nowadays it's pretty rare for that to be the case.
I just try and get LLMs to do it for me because I'm lazy, and they like to use setInterval instead of mutationObservers and if it works, I just live with the inefficiency.
The Atlassian stack is particularly bad to extend IMHO given that there are sooooo many API endpoints that their UI calls and most of them are dog slow.
Super interesting to hear about those concepts from another language/culture. While you are right that in software pretty much everything is "scaffolding" in the semiconductor the scaffolding vs steel applies.
To simplify it as much as possible, to make a chip multiple masks are created for different layers. The top layers are metal(scaffolding) and the base layers are silicon(steel). The metal layer masks are much cheaper to make than the base layers. So we add extra unused cells in the base layers and then if there are issues we try to fix them only in the metal layers.
It's not really an art nowadays, since it's been refined so much with tooling and processes. But your analogy is very applicable, I might try to refer to it in the future if I ever need to explain the concept to someone.
@doix, thank you for the fascinating deep dive into semiconductor design. To make sure I’ve grasped your point correctly, let me try to summarize it:
- Base Layer (Silicon) = "Steel": Re-manufacturing it is extremely costly, so it must be perfect from the start.
- Top Layer (Metal) = "Scaffolding": The wiring layers. These are much cheaper to produce, allowing for "patches" or corrections later on.
- The Wisdom of "Unused Cells": By embedding spare cells in the base layer upfront, you can fix bugs later just by changing the metal layers.
Did I get that right?
If so, this logic deeply resonates with what I’ve seen in Japanese "Shinise" (long-standing businesses) as a banker. Specifically, two practices that might look "inefficient" in a modern business model are, in my view, the "Unused Cells" of our Base Layer:
1. Not firing employees easily:
While some models treat labor like a "Metal layer" to be cut and replaced for quick optimization, Shinise treat people as part of the "Silicon layer." We keep them even in hard times so that when a big crisis hits, we can "re-wire" their roles to survive together.
2. Keeping high cash savings:
Many modern companies prefer to spend all their cash to maximize growth speed. However, Shinise keep a lot of cash. This is like the spare cells in your silicon—it allows us to finance our own "re-wiring" when the market crashes, without the foundation collapsing.
Your insight has given me a powerful new framework for why some organizations survive for 500 years while others vanish in three. Thank you!
Otherwise I don't understand how MCP vs CLI solves anything.
reply