Add a list of people (PMs) who have added feature requests. Have their username be "<username> (<Full Name>) - <karma points>" and then I can click through to see their bio.
Genie 3 is super impressive -- but you can't manipulate it programmatically like Minecraft.
We've built our infra so that we can plug in any simulation environment. If an AI-generated world starts being programmatically modifiable (and has really solid object permanance :) then we'd happily use it!
Minecraft has a DSL that lets you manipulate the world. We've piggy-backed on that, along with a K8s infra to run N worlds in parallel, to let you create simulations of arbitrary complexity.
We think simulations are the best way to test frontier AIs due to their degrees of freedom and expressivity.
I built an app (HN Clone, of course) with Instant's MCP hooked up to Claude Code.
The experience was brilliant.
Pros:
+ Fast
+ Easy
+ "Vibe coding on steroids" basically
+ The sense of 'wow' that comes very rarely with new tech
Cons:
- It used Instant as the database/backend, but I wasn't sure what it had done / how exactly it worked and had to spend a bunch of time asking Claude + reading the code to get it. It seemed reasonable, but if I were doing a prod system vs a PoC, this is where the time would be spent. ("Vibe coding lets you create tech debt 10x faster")
Net-net: This is the way for prototyping / validating. This is probably the way for production systems in N months too once the toolchain + agents get better.
Would you mind sharing the code, as well as prompts if you're comfortable? I'm trying to sample anecdata to help re-baseline my intuition on these things.
* Be careful when sharing log files. Claude can include secrets in there. Some hackers may notice an adminToken in the convo. I rotated it before we pushed.
* It was fun to see Claude use the query language. It thought we had a `$startsWith` modifier. Right now we only have $like. But `$startsWith` is a great idea, we may just implement it real quick!
> It thought we had a `$startsWith` modifier. Right now we only have $like. But `$startsWith` is a great idea, we may just implement it real quick!
Haha, that's great. Turns out that "hallucinations" are just things that make sense in context, and that can translate to feature requests from our agents :)
[Firebase founder] The thing I'm excited about w/Instant is the quad-fecta of offline + real-time + relational queries + open source. The amount of requests we had for relational queries was off-the-charts (and is a hard engineering problem), and, while the Firebase clients are OSS, I failed to open source a reference backend (a longer story).
I always assumed that an architectural decision had prevented relational queries in Firebase.
It was jarring to find out that indexes are required for every combination of filters your app applies, but then you quickly realize that Firebase solves a particular problem and you're attempted to shoehorn into a problem-space better solved by something like Supabase.
> I always assumed that an architectural decision had prevented relational queries in Firebase.
Seems the biggest problem is that Firebase doesn't have relations. How can you query that which does not exist?
I'm guessing what they really want is SQL? Once upon a time when I was stuck on a Firebase project I built a SQL (subset) engine for Firebase to gain that myself, so I expect that is it.
Why not? You're asking a question, of sorts, and getting an answer from the result. That's the literal definition of querying.
> Grabbing all the docs in the db into my controller and filtering down that array is what Firebase makes me do instead of writing queries.
A query language is just an abstraction. One you can have in your code. At some point you still need to "grab all the docs into a controller and filter them down", though. You could push that step into the Firebase service, but it would still have to do the same thing you're doing. There is no magic.
Better would be to provide something indexable so that you don't have to go through all the docs, but you can't index that which does not exist.
How hard is it to swap our firebase for instant? I've had an amazing time with firebase, but I sorta want to switch to using a completely local solution.
I have a small lyric video generator, and while I don't care about my own songs potentially leaking, I would never want to take responsibility for something else's data. I basically use firebase for the lyrics afterwards I transcribe them .
Second, do you offer your own auth or just integrate with other solutions.
> How hard is it to swap our firebase for instant? I've had an amazing time with firebase, but I sorta want to switch to using a completely local solution.
It should be relatively straightforward to switch. If you have any questions, you could always reach to us on Discord [1]
The only caveat though: Instant is like Firebase; it is not a completely local solution. If you are worried about exposing some data over the internet, I would store the same kind of stuff you were thinking about with Firebase.
> Second, do you offer your own auth or just integrate with other solutions.
We offer our own auth. You have magic code emails and Google Sign in out of the box. We also expose auth functions in admin SDK, in case you want to create a custom solution. [2]
I'm actually imagining telling end users to host the server locally via Docker. I have some other functionality, like the actual lyric transcription, I need docker for.
Thank you for your help. I'll definitely look into this for my next project
> Instant is like Firebase; it is not a completely local solution. If you are worried about exposing some data over the internet, I would store the same kind of stuff you were thinking about with Firebase.
What does this mean exactly? If you host your own it is still not local?
Side point: television is a bastard word, but erogenous is not Greek eros + Latin genus; it's all greek (ἐρωτογενής — it would be erotogenous in English since the root of the word eros is erot- , but the extra syllable was dropped; another example of differentiated transliteration is φωτογενής which became photogenic instead of photogenous).
I have just written an essay about the word water in the sibling post comments.
One thing I discovered in the process is that the word water comes to english all the way from Proto Indo European. The word hydro, however, comes from ancient greek, which comes from the same PIE word for water.
You probably heard this a million times but I still remember trying that simple firebase demo of draw in one box; see the results in another and being amazed. That was one of my pushes out of boring enterprise software death by configuration and into software creation based on modern OSS products.
The satire in the title is reminiscent of how Firebase was born.
We were previously working on a chat system called Envolve (https://www.envolve.com), that was 'Facebook Chat for any website'. A game that was using us for in-game chat created channels, used display: none on them, and passed game state through the chat.
We scratched our head, asked them why, and learned they wanted to focus on the frontend, not to deal with realtime message passing.
This led us to create a 'headless version' of our chat infra (re-written in Scala) that became the Firebase Realtime Database.
This is an important lesson - if someone is using your tool in unexpected ways don’t just shut them down; there’s likely a business case that could be identified and specialized in.
Nobody wants the product you want to make. They all want you to make the product they need, and will do things the devs of your product could never imagine with your product.
We make a CRUD desktop app, with a lot of integrations to customer systems. We got a standard set of XMLs, but we'll deal with whatever the customer has if we need to.
We recently got a support call from an upset client. A recent change had broken their integration, halting production.
This lead to some head scratching on our side, as we couldn't figure out what integration they were talking about.
Turned out they had paid some consultant quite a lot to script some tool similar to AutoHotkey to transfer data from their order system to our system. It would emulate copy pasting fields, tabbing along.
Our recent update had introduced a new field, thus screwing it all up.
As an aside, the "integration" used half an hour to transfer a single order due to how it did its work. An XML would have taken seconds tops.
I had a client who wanted to build his business on top of our business via scripting our administrative back end - basically he wanted to be a value added reseller. He'd get angry when we modified our admin console. We offered him API access for a fee, but any fee was too much for his business model. It was quite frustrating and eventually we had to ignore his pleas for UI stability over years of time. All the while he could have had access to the API for less than he was paying the person to script our admin console. This was circa 2007, so perhaps API programmers just weren't the thing back in the day.
I think this is unfortunately what is going happen in the next few years as more tech companies will price their APIs out of reach of small businesses :/
Indeed. Tangentially, there is another side to the coin.
The antithesis of this is the contract model, when a client comes to you and asks you to make something specific, rather than describing what they need. In this case they are almost always wrong. They’ll rarely admit it unless you show them some amazing alternative, though.
Requirements = a set of problems to be solved. More often you get handed a diagram of a 12” tall Stonehenge sketched on a napkin with exceeding confidence that it will be 12 feet tall.
This happens outside development, too. More often than not in IT, when the business has a need, they start with a solution and approach IT asking them to implement it. I've gotten better over the years (although always room to improve) at steering the conversation around to "what exactly are you trying to accomplish?" Let's start there.
The quote is alleged to be Henry Ford, and I've always encountered it as "better horse."
In either case, the customers aren't stupid but instead are using the language and paradigm they are familiar with to describe their needs. Ford did indeed provide a faster/better horse, because the horse was the main means of non-human motive force in the US.
The technologist's job is to understand the universal of possible solutions and to understand the customer's needs and goals, which often includes interrogating and parsing the customer's language/worldview, and craft a product that achieves those needs/goals (and doesn't introduce negatives that overwhelm the benefits).
Regardless of the provenance of that quote, it is quite apt wrt IT clients. They always come asking for a faster horse, ie: something they know that is just better in a specific way.
A lot of the times this might be wrong but I think the interesting part is how that request gets handled.
The horses were themselves a more immediate sanitation problem; in New York alone there was a million pounds of horse manure every day, plus thousands of horses that dropped dead from overwork. Disposing of all the feces and corpses was a challenge.
And to be fair there was a lot of grumbling about the "horseless carriage" for quite awhile.
What's interesting to me is that the oldest streets (ignoring the Main Street) in the local small town are the widest, because they needed to be able to turn around a team of horses and a carriage/wagon even when other wagons are parked on the side. The newer streets (but still 1940-50s) around are narrower because they didn't have to accommodate that.
It is frustrating how often I have to tell my non-techy CEO to rewind a step, and tell me the problem he is trying to solve not the half-baked solution he came up with. One bad idea he has had for over a decade, and I have to keep beating it down since it is an extremely stupid method to solve nothing.
There is another side to this coin, too. It is clients that describe their needs, not some specific and wrong solution, and then either get told they did not do their homework, or their needs getting ignored by a dev who thinks he is smarter than the client in the client's own field.
It is correct that "Requirements = a set of problems", and therefore it does not make sense at all to repeatedly ask the client for a technical solution instead of asking for the problems to solve, and then be surprised that the client does not talk about problems anymore.
The kamikaze was a grim solution to Japan's losing of the carrier offence/defence balance; the rate of pilots returning from sorties was poor, and the rate of pilots returning from tours to be instructors was extremely low, so the solution was to take very young men with minimal training and use them as human guided missiles. Pilots were probably going to be killed anyway, so the focus was on trying to achieve carrier kills at any cost.
(Humans will really adapt anything into a weapon, including human lives themselves, especially in a total war)
Also consider that more than half of the hits to Japanese aircraft in the Pacific were caused by the use of the top-secret VT radar proximity fuse.
The Japanese predicted they were going against "dumb" timer-based anti-aircraft, which was probably two orders of magnitude less accurate and less effective, where their weak armoring would have been a good approach: if you think it will take 200 shots to bring down your planes, fielding twice as many units that could each be brought down by one lucky direct hit makes great sense. But if it only takes two shots, you need to be able to survive the shrapnel.
The strategy they put in motion in 1942 suddenly became obsolete in 1943, and it was too late to pivot.
> This is an important lesson - if someone is using your tool in unexpected ways don’t just shut them down; there’s likely a business case that could be identified and specialized in.
One of the craziest cases of this I've seen was with a web-based survey application I was the principal engineer on in the mid to late 2000's. A big feature we implemented was the ability to create surveys to support multiple languages. To make translation easier for our customers to translate surveys outside of the application, there were ways to export/import the text strings as well as a standalone screen that allowed finding and editing them. Both of these were made easier by the fact that the strings had semantic identifiers like "/survey/question/choice" or similar.
Since this functionality worked so well, we also used it internally for all text in the application. As a convenience, both the import/export and edit screen were capable of editing these strings. One customer figured this out and, due to the naming, was easily able to identify the text for all screens and dialogs. They ended up completely modifying the application interface through this interface by editing text, adding HTML elements, and injecting CSS blocks. They added descriptive tutorial text, guides for users, and branded the application well beyond built-in functionality. It was pretty amazing.
It's amazing with how much creativity users will abuse your creations. ;) And in many cases, something new is born out of it. The problem is getting the information about just how people are using your service differently than you've intended. Sometimes it's impossible to tell from traces, analytics or logfiles alone. But finding out can be quite an advantage, especially if you're a startup probing for PMF.
The best thing that can happen is that you have a channel to your customers that's constantly open. At WunderGraph, we use Slack for that, and it considerably lowers the barrier to just check in and have a quick discussion. The sooner you find out about use cases, the better - and ideally create a product around it. :)
Related, but different, & if there's someone at Google looking at this:
There was a Titan Bluetooth Key (for 2FA) Vulnerability, you've said you'll replace the affected keys[1], but you're no longer doing so. Which is frustrating.
You'll have better luck with a separate post, even if it doesn't hit the front page. I would over-describe the problem, state it in 3 different ways, so some kind soul searching is more likely to find it.
