> Pure vision will never be enough because it does not contain information about the physical feedback like pressure and touch, or the strength required to perform a task.
I'm not sure that's necessarily true for a lot of tasks.
A good way to measure this in your head is this:
"If you were given remote control of two robot arms, and just one camera to look through, how many different tasks do you think you could complete successfully?"
When you start thinking about it, you realize there are a lot of things you could do with just the arms and one camera, because you as a human have really good intuition about the world.
It therefore follows that robots should be able to learn with just RGB images too! Counterexamples would be things like grabbing an egg without crushing, perhaps. Though I suspect that could also be done with just vision.
I love uv, not just for local development, but it also makes it WAY easier to manage python environments you setup for running python workers / user code in the cloud.
I was just telling someone about the story of how he invented bitmapping for overlapping windows in the first Mac GUI in like two weeks, largely because he mis-remembered that being already a feature in the Xerox PARC demo and was convinced it was already possible.
I highly recommend starting with the SO-ARM101 and the LeRobot tutorial. They're super cheap, its insanely quick to get started, and you can even buy pre-made kits like at https://partabot.com . It's the "Hello World" of robotics now, imo.
Don't bother with a Jetson Nano, you don't need that to get started, and by the time you need that you'll know a lot already. You can just drive the robot from your laptop!
Getting to training your own VLA fine-tuned model is a super quick and easy process. You can see examples of other people completing the tutorial and uploading their training/evaluation datasets here (shameless plug for my thing): https://app.destroyrobots.com
I wouldn't bother much with ROS at first tbh. It'll bog you down, and startups are moving toward using other approaches that are more developer friendly, like Rust-based embedded.
You can go far with a robot connected to USB though!
Wow, this is incredible work! Blown away at how well the audio/video matches up, and the dialogue is better sounding / on-par with dedicated voice models.
> The article ignores Firefox switched the contract to Yahoo as the default search provider from 2014-2017
I worked at Mozilla when this deal was struck. The deal with Yahoo did require Yahoo be the default for Firefox, I'm not sure what you mean by "absence of any requirement"?
Mozilla broke that contract with Yahoo (there was a clause allowing them to do so without repercussion and keep the money, if they deemed it better for the users, wild contract) less than 3 years later because users hated Yahoo so much, and went back to Google.
Google is dominant because it just _is_ the best search engine.
> One of the biggest differences between Google selling Chrome and any old chromium fork is precisely that the "other" browsers no longer have to try to compete with Google's own browser to get users to monetize.
Isn't that literally anti-competitive? The DoJ is saying Google search is dominant partially because of Chrome pushing users to Google.
You're saying Chrome is dominant because users like it too much, and other browsers can't compete? Tough, that's the users' choice, though.
The article is a neat read! The design of the blog itself is even more interesting. I don't love the right-aligned way it starts, but I love the inline activations of the left popup! So cool
> There's a trend on social media where many repeat Andrej Karpathy's words: "give in to the vibes, embrace exponentials, and forget that the code even exists." This belief — like many flawed takes humanity holds — comes from laziness, inexperience, and self-deluding imagination.
I'm going to go ahead and give the author the benefit of the doubt that they aren't literally saying Andrej Karpathy is "lazy and inexperienced", because that claim is obviously absurd.
In general though, I think the author is missing the actual point Karpathy was making! Let's look at his detailed criticisms for the typescript agent run, for example:
> Regularly clones TypeScript interfaces instead of exporting the original and importing it.
> Reinvents components all the time with the same structure without searching the code base for an existing copy of that component.
These are only problems for human codebases. You're not vibing if you are expecting agents to write code the way humans would.
Duplicating interfaces and implementations is inefficient, and would be a nightmare, in a human codebase. But, the code will still work! So if an AI agent is managing the codebase, who cares if it duplicates things all the time?
Maybe it'll see that it did that later and decide to consolidate things, maybe it won't. It doesn't affect the actual outcome of the code, unless you actually look at the code as a human, which is not "vibe coding."
> When told to fix styles with precise details, it will alter the wrong component entirely.
> When told specifically where there are many duplicated components and instructed to refactor, will only refactor the first instance of that component in the file instead of all instances in all files.
> When told to refactor code, fails to search for the breaks it caused even when told to do so.
You're thinking about the code again, gotta stop doing that if you actually want to ~vibe code~. Refactoring code isn't a thing when you're vibe coding, English is your programming language now, the Typescript (or w/e language) is the assembly. You wouldn't spend much time observing the assembly output of your compiler (especially for web dev), so why are you observing the code output of your agent?
If you don't want to vibe code, that's fine, nobody is forcing you to. But if you're going to do it, grade it on the metric that Andrej was actually claiming: that you can get working results on a lot of software projects today by telling coding agents to make some code do something, and then just keep running it with "fix this bug" until it works, and it'll often get to a working result.
He never claimed that the code outputted would be beautiful, from a human perspective, or well formatted, or well architected, or efficient.
That's not a one-to-one analogy. The LLM isn't giving you the book, its giving you information it learned from the book.
The analogous scenario is "Can I read a book and publish a blog post with all the information in that book, in my own words?", and under US copyright law, the answer is: Yes.
There's absolutely no way that we're not going to see a massive reduction in the need for "humans writing code" moving forward, given how good LLMs are getting at writing code.
That doesn't mean people won't need devs! I think there's a real case where increased capabilities from LLMs leads to bigger demand for people that know how to direct the tools effectively, of which most would probably be devs. But thinking we're going back to humans "writing readable, functional, maintainable code" in two years is cope.
> At some point there might be massive layoffs due to ostensibly competent AI labor coming onto the scene, perhaps because OpenAI will start heavily propagandizing that these mass layoffs must happen. It will be an overreaction/mistake. The companies that act on that will crash and burn, and will be outcompeted by companies that didn't do the stupid.
Um... I don't think companies are going to perform mass layoffs because "OpenAI said they must happen". If that were to happen it'd be because they are genuinely able to automate a ton of jobs using LLMs, which would be a bull case (not for AGI necessarily, but for the increased usefulness of LLMs)
I don't think this is a bad thing. Pretty much all of the author's examples of "new and potentially superior technologies" are really just different flavors of developer UX for doing the same things you could do with the "old" libraries/technologies.
In a world where AI is writing the code, who cares what libraries it is using? I don't really have to touch the code that much, I just need it to work. That's the future we're headed for, at lightning speed.
Went through the Twilio IPO, I can give feedback based on my experience. IANAL and all that.
1. I've never heard of that from a tech company IPO. Twilio did sell-to-cover fwiw.
2. Does your RSU contract/letter say something about that? I'd maybe check with a lawyer and see if they can even do that. I would have imagined that in this scenario, the company gives you the RSUs and leaves you to figure out paying the IRS yourself.
3. That sounds absurd, I never had to do that. Tech companies that reach IPO typically have an HR department that handles all this for you, but I mean yours clearly doesn't I guess. I don't know what, if any, obligation employers actually have legally in this regard. Again, I'd check with a lawyer.
4. Hmm, I was a current employee during my IPO experience, so don't know how former employees were handled. I'm guessing though that they were also given sell-to-cover option. I'm pretty sure the stock broker the company used (I think it was ETrade) just handled all that for the company, including showing us how much was sold to cover as things vested, and locking current employees during quiet periods.
Good luck, hope that helps a bit in terms of at least validating your sanity that this probably isn't normal.