A laptop without a unified memory model is categorically incapable of being the "ultimate developer laptop". Framework already have Strix Halo machines, I don't know why they felt the need to hamstring this thing with Intel.
Hilariously, those AMD chips are way behind the Intels in terms of memory.
First off, I believe that Intel has its memory far more "unified". AMD typically has a stricter VRAM/RAM 'tradeoff' setting that does not exist on Intel in the same way to my knowledge. (See how on Strix Halo systems, there is a thing about "allocating" 96 GB to the GPU, which seems to be needed sometimes but prevents the CPU from accessing that memory.)
Secondly, the Panther Lake board has LPDDR5X LPCAMM2 memory at 7467 MT/s, while the AMD boards are stuck with DDR5 SODIMMs at a meagre 5600 MT/s. In other words, the Intel board gets a third more memory bandwidth!
I’ve got the Framework desktop with strix halo. You can reserve memory for the GPU, but it’s straightforward at least on Linux to have the GPU dynamically grab memory as needed. I’ve got my VRAM set to 512MB and regularly use 120GB+for AI stuff.
Really? Because I did look through the entire spec list they provided and didnt see any non-Intel. Didnt get to the order screen since it was behind a waitlist sign up. I agree, that is better then nothing.
It's now new, it's the motherboard they already ship with the regular FW13. Because the bits are mostly interchangeable, they just let you order the FW13 Pro with the AMD motherboard.
Awesome, thats good news. I have a FW Desktop with the 395+ in it and have generally been impressed with it. Hoping that will eventually make its way into these machines.
I will guess for linux. Most out of the box linux laptops I saw were intel based. I guess open source support of intel is best among others in the industry. Even in my current thinkpad first thing I did was to replace its wifi module from realtek to intel (realtek was always hanging/dropping connection etc).
Assuming you're referring to Apple Silicon's memory bandwidth, that is not necessarily because the memory is on-die. The bandwidth comes from having more channels to access memory. This gives the SoC a wider bus to increase throughput vs. your typical x86 system with two channels. For whatever reasons Intel/AMD decided that two channels is all the typical consumer chips can support now so it's on them.
You mentioned Strix Halo, which also has off-die memory. Strix Halo does have a real advantage from its wider memory bus (four channels for 256 bit instead of 128 bit), but Strix Point is equivalent-ish to Intel's platforms like Panther Lake or Arrow Lake in terms of memory setup.
In fact, Intel also had Lunar Lake, which had on-package memory. However, it was still limited to 128-bit dual-channel, so there weren't really many performance benefits; it did however help with power efficiency.
Well, Intel was kind of in the dumps because their process fell behind. They didn't bet on EUV and got leapfrogged by TSMC and Samsung who did use ASML's EUV technology.
They eventually got on the EUV train and were the first customer to receive ASML's current state of the art machine which they call high-NA EUV. Intel's 18A process is the first to use this machine as part of the manufacturing process, Panther Lake uses this process so now they're right back to being SOTA.
All the news about them (stock price movements, theories about them going bankrupt, Panther Lake, etc...) for the last 2 years has essentially been people betting on whether or not they can successfully incorporate SOTA ASML machines into their manufacturing.
Apple Silicon had a process node advantage over the Core 100 and 200 series due to having a better allocation with TSMC.
Now Intel's process node is also SOTA and on par with TSMC 2nm so they should be more or less equivalent and the only differences down to what set of compromises they make in the design of the chips.
I built something similar using an MCP that allows claude to "outsource" development to GLM 4.7 on Cerebras (or a different model, but GLM is what I use). The tool allows Claude to set the system prompt, instructions, specify the output file to write to and crucially allows it to list which additional files (or subsections of files) should be included as context for the prompt.
Ive had great success with it, and it rapidly speeds up development time at fairly minimal cost.
Late reply, but the answer is:
1) there is a fair amount of behind the scenes work going on that I dont want the agent to have access too or know about. Tools make it very easy to have strong control over what can and cannot be done. File system access is built directly into the tool, which makes it much easier to be confident about what it has access too, since the thing that actually has the permissions is the tools code, not the agent.
2) Portability, I can host it from a single spot and serve it to multiple models on different machines easily, which is very desirable for me.
3) I can update the configuration of the tool independent of a skill.
A skill wouldn't be a bad option though, and I highly recommend creating one yourself! The ability to customize our workflows and tools to a high degree is one of the largest strengths of agentic coding.
MCP is fine if your tool definition is small. If it's something like a sub-agent harness which is used very often, then in fact it's probably more context efficient because the tools are already loaded in context and the model doesn't have to spend a few turns deciding to load the skill, thinking about it and then invoking another tool/script to invoke the subagent.
Is that true? I had tool use working with GPT-4 in 2023, before function calling or structured outputs were even a thing. My tool instructions were only half a page though. Maybe the long prompts are causing problems?
They're talking about "skills" which are not the same thing as tools. Most models haven't been trained on the open SKILL spec, and therefore aren't tuned to invoke them reliable when the need occurs.
Yes, correct. Essentially every single industry and tool which rents out capacity of any system or service does this. Your ISP does this. The airline does this. Cruise lines. Cloud computing environments. Restaurants. Rental cars. The list is endless.
Exploring a codebase tells you WHAT it's doing, but not WHY. In older codebases you'll often find weird sections of code that solved a problem that may or may not still exist. Like maybe there was an import process that always left three carriage returns at the end of each record, so now you got some funky "lets remove up to three carriage returns" function that probably isn't needed. But are you 100% sure it's not needed?
Same story with data models, let's say you have the same data (customer contact details) in slightly different formats in 5 different data models. Which one is correct? Why are the others different?
Ultimately someone has to solve this mystery and that often means pulling people together from different parts of the business, so they can eventually reach consensus on how to move forward.
Adding that this just gets worse when databases are peppered with direct access by vibe-coded applications that don’t look at production data or gather these insights before deciding “yeah this sounds like the format of text that should go in the column with this name, and that’s the column I should use.”
And now there’s an example in the codebase of what not to do, and other AI sessions will see it, and follow that pattern blindly, and… well, we all know where this goes.
How is an AI supposed to create documentation, except the most useless box-ticking kind? It only sees the existing implementation, so the best it can do is describe what you can already see (maybe with some stupid guesses added in).
IMHO, if you're going to use AI to "write documentation," that's disposable text and not for distribution. Let the next guy generate his own, and he'll be under no illusions about where the text he's reading came from.
If you're going to write documentation to distribute, you had better type out words from your own damn mind based on your own damn understanding with your own damn hands. Sure, use an LLM to help understand something, but if you personally don't understand, you're in no position to document anything.
Whats with this assumption that there's no human involvement? I dont just say "hey scan this 2m loc repo and give me some docs'... that would be insane. T
he AI is there to do the easy part; scan a giant spaghetti bowl and label each noodle. The humans job is to attach descriptions to those noodles.
Sometimes I forget that people on this site simply assume the worst in any given situation.
I don't find this surprising. Code and data models encode the results of accumulated business decisions, but nothing about the decision making process or rationale. Most of the time, this information is stored only in people's heads, so any automated tool is necessary blind.
This captures succinctly the one of the key issues with (current) AI actually solving real problems outside of small "sandboxes" where it has all the information.
When an AI can email/message all the key people that have the institutional knowledge, ask them the right discovery questions (probably in a few rounds and working out which bits are human "hallucinations" that don't make sense). Collect that information and use it to create a solution. Then human jobs are in real trouble.
Until that AI is just a productivity boost for us.
The AI will also have to be trained to be diplomatic and maybe even cunning, because, as I can personally attest, answering questions from an AI is an extremely grating and disillusioning experience.
There are plenty of workers who refuse to answer questions from a human until it’s escalated far enough up the chain to affect their paycheck / reputation. I’m sure that the intelligence is artificial will only multiply the disdain / noncompliance.
But then maybe there will be strategies for masking from where requests are coming, like a system that anonymizes all requests for information. Even so, I feel like there would still be a way that people would ping / walk up to their colleague in meatspace and say “hey that request came from me, thanks!”
i love the assumption by default that "ai generated" automatically excludes "human verified".
see, i actually read and monitor the outputs. i check them against my own internal knowledge. i trial the results with real trouble shooting and real bug fixes/feature requests.
when its wrong, i fix it. when its right, great we now have documentation where none existed before.
dogfood the documentation and you'll know if its worth using or not.
Literally several times a week, I have to close PRs with docs that clearly no one read because they are blatantly wrong. This happened after LLMs. If what you're claiming is happening, I'm not seeing it anywhere.
AI is incapable of capturing human context that 99.999% of the time exists in people's brains, not code or context. This is why it is crucial that humans write for humans, not an LLM that puts out docs that have the aesthetics of looking acceptable.
I am similarly interested, but mostly because my memory is awful and I'd like to actually remember what people tell me without having to ask repeatedly.
Write your own tools. Dont use something off the shelf. If you want it to read from a database, create a db connector that exposes only the capabilities you want it to have.
This is what I do, and I am 100% confident that Claude cannot drop my database or truncate a table, or read from sensitive tables.
I know this because the tool it uses to interface with the database doesn't have those capabilities, thus Claude doesn't have that capability.
It won't save you from Claude maliciously ex-filtrating data it has access to via DNS or some other side channel, but it will protect from worst-case scenarios.
This is like trying to fix SQL injection by limiting the permissions of the database user instead of using parameterized queries (for which there is no equivalent with LLMs). It doesn't solve the problem.
It also has no effect on whole classes of vulnerabilities which don't rely on unusual writes, where the system (SQL or LLM) is expected to execute some logic and yield a result, and the attacker wins by determining the outcome.
Using the SQL analogy, suppose this is intended:
SELECT hash('$input') == secretfiles.hashed_access_code FROM secretfiles WHERE secretfiles.id = '$file_id';
And here the attacker supplying a malicious $input so that it becomes something else with a comment on the end:
SELECT hash('') == hash('') -- ') == secretfiles.hashed_access_code FROM secretfiles WHERE secretfiles.id = '123';
> the tool it uses to interface with the database doesn't have those capabilities
Fair enough. It can e.g. use a DB user with read-only privileges or something like that. Or it might sanitize the allowed queries.
But there may still be some way to drop the database or delete all its data which your tool might not be able to guard against. Some indirect deletions made by a trigger or a stored procedure or something like that, for instance.
The point is, your tool might be relatively safe. But I would be cautious when saying that it is "100 %" safe, as you claim.
That being said, I think that your point still stands. Given safe enough interfaces between the LLM and the other parts of the system, one can be fairly sure that the actions performed by the LLM would be safe.
This is reminding me of the crypto self-custody problem. If you want complete trustlessness, the lengths you have to go to are extreme. How do you really know that the machine using your private key to sign your transactions is absolutely secure?
What makes you think the dbcredentials or IP are being exposed to Claude? The entire reason I build my own connectors is to avoid having to expose details like that.
What I give Claude is an API key that allows it to talk to the mcp server. Everything else is hidden behind that.
Unclear why this is being downvoted. It makes sense.
If you connect to the database with a connector that only has read access, then the LLM cannot drop the database, period.
If that were bugged (e.g. if Postgres allowed writing to a DB that was configured readonly), then that problem is much bigger has not much to do with LLMs.
