499 karma · joined May 21, 2015
Other than that, I agree with what others are saying. If people rely on some undocumented aspect of your IDs, it's on them if that breaks.
I suspect this is because an LLM doesn't build a mental model of the code base like a dev does. It can decide to look at certain files, and maybe you can improve this by putting a broad architecture overview of a system in an agents.md file, I don't have much experience with that.
But for now, I'm finding it most useful still think in terms of code architecture, and give it small steps that are part of that architecture, and then iterate based on your own review of AI generated code. I don't have the confidence in it to just let some agent plan, and then run for tens of minutes or even hours building out a feature. I want to be in the loop earlier to set the direction.
Sometimes, especially for power users of an app, it's useful to have multiple actions at their fingertips, even at the cost of introducing a learning curve.
I think the one primary action per page thing works well for most things, but as soon as you're building anything like creativity tools where people want multiple editing options, or a control panel that you expect will be used by a professional several times a day, I think that principle becomes less useful.
While a story definitely can do that, for many people, they're also about human connection. Even if the story isn't true, you feel like you're getting a look inside the author's brain by discovering how they weave storylines together. All the life experience they've head that lead them to write this story.
If I was instead told the story was written by AI, I would be far less interested in what data it was trained on to be able to produce this story, because I cannot relate to an AI having any "experience" whatsoever.
I'm slightly worried about permissions evaluating to "true" if they're not specified. I think this will lead to a lot of actions being accidentally allowed.
I'm toying a bit with this tool, and I think it's incredibly useful for prototyping.
- Put cause and effect close to eachother - Don't block my view based on mouse position. I hate video players that ofverlay the pause button when the mouse is over the video, or images that get obscured by some overlay when hovered. My zoom follows the mouse, so I can't move what I'm looking at and where my mouse is pointing independently.
I think Go was smart to make this concept part of the standard library, as it encouraged frameworks to adopt it as well.
I get where you're coming from, especially if an app has no service component, but it's inevitable if a platform has no good way to charge for upgrades. And as much as some people would like to buy a version of an app once and keep using that same version forever, platforms also make that impossible by changing the environment an app runs in in backwards-incompatible ways, so the software needs to be maintained, and that has a price.
I next asked for a diagram of a diverging diamond interchange, and it came up with 4 images that looked like 3D models of interchanges on a white background, but none of them were diverging diamonds.
I'm going to experiment with describing the thing I want to see in more detail, to see of Dall-E 3 can make a nice image out of it.