The author is a Principal Engineer at DeepSeek. I don't know what that title maps to in other organizations. Their formal education/background is in ML however.
(disclaimer: I'm a software engineer with minimal compiler theory experience outside classes in college)
I wonder whether its possible to trust an LLM to "compile" your code to an executable and trust that the compiled code is faithful to the input without writing a static validator that is pretty much a compiler itself.
Hi Peter - I'm on H1-B and not eligible for EB-1/2 or O-1. I filed for EB-5 through an RC and just got my EAD and I want to use that to start a startup in the US. If the underlying EB-5 petition is rejected after the startup is established, do you know if there is a path to re-sponsoring my H1-B through my own startup? I'm trying to understand whether I should wait for a proper green card before going down the startup route.
> Try murdering someone like that… well that person might have contingencies in place so that things just start to randomly burn down in your country……………
I don't even know where to start with this. The article portrayed your interaction with the DoD to giving them a Powerpoint presentation and making various attempts to catch their attention. Which you've portrayed here as a 'heavy affiliation'... so heavy that the state conducts special operation behind enemy lines to avenge you.
> The only way to have an LLM where data and instruction never meet, in my view, is one that doesn't update in response to prompts (and therefore can't carry on a multi prompt conversation).
Do you mean an LLM that doesn't update weights in response to prompts? Doesn't GPT-4 not change its weights mid conversation at all (and instead provides the entire previous conversation as context in every new prompt)?
Whats the endgame here? Is the story of LLMs going to be a perpetual cat and mouse game of prompt engineering due to its lack of debuggability? Its going to be _very hard_ to integrate LLMs in sensitive spaces unless there are reasonable assurances that security holes can be patched (and are not just a property of the system)
I don't feel like debating the predictability of any individual bug is in the spirit of the argument that I'm making here, which is just that software systems (absent formal verification + running in a completely isolated vacuum) are going to break. Sure, people might have been able to predict it but it still broke systems. Marking the system as 'complete' wouldn't have kept it working.
> Bits don't go bad if you neglect them for too long
They do... Other than in the obvious physical sense (bit rot), your assumptions about the environment that the code runs in might change (y2k), the foundation your software is being built on is being actively and continuously updated in ways that may break your code (ipv6, forward incompatible security fixes), the resources your code uses are finite and the constraints around the resource usage may change... Looking at it from just first principles maintaining a Very Large software system in production is immensely complex.
In my experience outside the niche of tech related content Kagi performed significantly worse than Google. Especially for content that was region specific and not just text natch based, like "children clothing stores in Boston"
Tamper-proof packaging is a poor replacement for a first-time boot replacement warning. Not to mention the sheer impracticality of properly implementing tamper proof packaging (the factory would have to cover the packaging in shiny nail polish or something, encrypt and send a high-res picture of that somehow to the final buyer across the supply chain, at which point the final buyer makes sure the glitters align). Much better to do it the way it's currently done
> You can use even newer stuff like high grade visualization of the entire program execution which trivializes bug detection, performance enhancement, and system understanding.
Very interesting... what is the gdb-reverse-debugging equivalent for high grade visualizations of, for ex. cpp or python software? Something that's free, open source, generalizable
Time commitments were generally aggressive but reasonable with a 10-20% buffer to account for ramp up (realistically closer to 10 than 20). The reasonable-ness of most things eng-culture related at Amazon is probably a function of the competence of your management chain.
As for my fellow engineers- I don’t know anyone else who did this regularly so I’m not sure