I do something similar but a bit more involved, using a few informal stages. Let's say for example I'm trying to launch a new complex feature for https://coderba.se.
- strategy document
- "sprint" document with technical implementation
- actual implementation
- e2e testing scenarios updates
Every step involves iterating with Claude on it with me in the loop (setting the direction then resolving the "founder questions" as they appear), and importantly a different model for review/code-review, be it Codex (usually, it's great at it) or Antigravity/Gemini (sometimes finds novel things, its precision and recall are abysmal but on the odd occasion it has good accuracy). This iteration on the high-level plan then on the implementation plan is essential to me, and IMHO part of why people are surprised that I tend to get solid results from LLMs. At the very least, it allows me to fill gaps in my own knowledge (primarily front-end development) and be more productive than writing the code myself. I cannot stress enough how nice it is to have a partner in the high-level system design – yes, it often suggests utterly moronic ideas, but the overall experience is still net positive and getting better every quarter.
I'd be curious how it handles someone parking poorly in that bay e.g. diagonally. Presumably those lines serve as a parking guide and the door won't close unless you park correctly.
The local car wash has lights that help you park the car pretty precisely under the wash robot. No rails or anything, you park right underneath the robot and it moves around and over the car. The robot doesn't start until you are in position.
IMO this would be a terrible idea to let the robots park cars in the same car park as humans. They most likely have a dedicated car park for this where ever car is parked by a robot.
The article says:
"A Stanley Robotics autonomous parking robot then slides underneath the vehicle, lifts it by its tyres and transports it to a secure storage area."
I think the OP was talking about humans parking weirdly in the garage the robot picks them up from, not the car park itself—the car park itself is robot only (so they can jam cars together).
I was thoroughly confused at why the website was showing the weather for York. Since I studied there (and it's straight up a lovely place), I visit quite often and subsequently check the weather. I thought I had set it but couldn't remember doing so. As someone else said, this being text-based makes it particularly digestible to LLMs. Out of curiosity, I looked up weather MCPs and stumbled upon this: https://github.com/weather-mcp/weather-mcp
I am building an interviewing and hiring platform (https://coderba.se/) but I've also hired/interviewed and shaped hiring processes at several companies before. It's ridiculous how easy it is to account for such trivial edge cases, yet most people just... dont. A big part of it is that, in spite of frequent chest beating about how "hiring is [one of] the most important thing[s] we do", the actual process is half-assed at best in most places, an effect particularly amplified by the current massive oversupply of talent.
The chance of a single hire being a make it or break it for the the business is pretty much null, so a single recruiter not having continuity in the processes they were doing once they get fired isn't really something to optimize for.
Firecracker is fantastic technology. I'm using it for my interviewing startup to run isolated runtimes for coding interviews (and personal workspaces), and it's been rock solid and incredibly lightweight. Interfacing with it through the Go SDK has been a piece of cake, too.
Nice post! You piqued my curiosity, so after a bit of research it turns out that, with techniques like MTP/MLA/CSA, it's quite probable that these models are much more efficient (and maybe bigger? tho 400B sounds about right) than a simple RAM breakdown would suggest.
These techniques are used by DeepSeek, and work well with the commodity (NVIDIA) GPU's they use.
Google designs their entire AI stack from the custom silicon up. So they have different optimization approaches.
(Though Gemma does use MTP)
- strategy document
- "sprint" document with technical implementation
- actual implementation
- e2e testing scenarios updates
Every step involves iterating with Claude on it with me in the loop (setting the direction then resolving the "founder questions" as they appear), and importantly a different model for review/code-review, be it Codex (usually, it's great at it) or Antigravity/Gemini (sometimes finds novel things, its precision and recall are abysmal but on the odd occasion it has good accuracy). This iteration on the high-level plan then on the implementation plan is essential to me, and IMHO part of why people are surprised that I tend to get solid results from LLMs. At the very least, it allows me to fill gaps in my own knowledge (primarily front-end development) and be more productive than writing the code myself. I cannot stress enough how nice it is to have a partner in the high-level system design – yes, it often suggests utterly moronic ideas, but the overall experience is still net positive and getting better every quarter.