Better yet, detect mouse clicks and display a popup right where you clicked that says something you didn't want, and show a busy indicator to make sure the user understands that they just agreed to something important.
Keep in mind while this is the date they officially became part of SpaceX, they have already been collaborating on building models together. So don't expect a significant bump in performance on new Grok models due to the additional data from Cursor--that bump already happened with Grok 4.5[1] and now 4.6.
There still may be Opus->Fable type bump when they finish training larger models. Remember, Grok 4.6 is still Opus-sized and they have larger models in training.
Architect your system to use the best tool for each problem. Doing a minimal data pipeline? Use Python. Building a backend? Use Go. Building a frontend? Use React / Typescript.
Building a stack that does all of these? Still use Python, Go, React/Typescript. Because by architecting it this way you make the AI less likely to accidentally refactor logic between layers. In other words, architecting with multiple languages helps create persistent boundaries that isolate different kinds of logic into their appropriate modules.
A zen master asked a junior engineer to go get him a rock. The junior engineer asked what kind of rock he should get and the master replied by knocking him in the head with his cane. The junior thought for a minute, then asked, "would you like a round rock or a flat rock?" Again, the zen master rapped him on the head. The junior thought for a moment, then went to the creek and fetched a rock at random. He brought it to the zen master who inspected it and then said, "No, I want a flat piece of flint for starting a fire." The junior engineer was then enlightened.
Stakeholders will only give you requirements after they see the prototype. Thus, the spec and the prototype to elicit it are two sides to the same coin. Once the spec if correct and the prototype is starting to show its age, throw away the prototype and implement the spec with a fresh start.
> Stakeholders will only give you requirements after they see the prototype.
That’s very much incorrect and sounds like someone who love building more than communicating. Even without a prototype, users and other consumers will be able to explain their problems. It may not use the same metaphor map that you’re used to. But it’s very much a description of the problem space.
Once you design a prototype, what you will get is feedback about the solution you’ve designed, not the raw problem. If you’ve not listened well in the first place you may be well off the mark, and have to work harder to correct things.
Even if your story, the junior would do way less work by asking the master what he intends to do with the piece of work instead of focusing on the rock itself.
whether the hypothesis originates at the users or in your guess for the users is irrelevant in that they're both hypotheses with no certain outcome until trial.
They are. But engineering is about minimizing costs in solving a problem while ensuring requirements are met. Not worrying about costs is not engineering. It's either a research project (where you want to know if something is possible) or playing around.
The cost of prototyping has dropped so much due to LLMs and coding agents that it basically always makes sense to prototype something to elicit feedback, just as part of the requirements gathering process. E.g. if you can spend $50 to understand something that will save you two weeks of effort, wouldn't you do that? That's the sort of dynamic I'm talking about.
The cost of prototyping has always been very low. I can quickly sketch a UX flow using balsamiq. Or copy-paste paste code from docs and examples to show a rough working model with. If you can extract the essence of the problem you can quickly realize cheap ways to demonstrate a solution, and not spend two weeks trying to code it.
If there’s something that is wrong with using LLMs to prototype, it is that those prototypes are always too complex. Instead of decomposing a problem and testing unrelated concerns apart from each other, it’s often a mix of everything that the LLM user had been thinking about.
Often there’s no rapid iteration where you are comparing several approaches. Instead it became tunnel vision and confirmation bias where if it’s working, that means it’s the solution.
https://github.com/google/git-appraise
I used git bug before but found I missed being able to edit tickets with a Markdown editor. So I built this: https://github.com/LoumTechnologies/ticketry
reply