Thought about this a bit more. The biggest friction we had with this framework was in writing (and only on rapidly evolving code, maintaining) the mappings (keywords.resource) between the functional natural language spec (*.robot) and the implementation. It was productive work because once a component is stable, you rarely touch it, yet your functional tests (if you do it right, this is basically user contract testing) work automagically and the most important (UX) regressions are caught.
Now, I'd bet that a well-instructed LLM of the year 2026 can generate these mappings in a whiff. It probably doesn't even need a browser to check and can just do it from code. So the only extra work this brings is writing the spec, and review/debugging those mappings (lightly, hopefully.) I'll see if I can get some intel out of former colleagues re: their LLM integrations with this.
Thought about this a bit more. The biggest friction we had with this framework was in writing (and only on rapidly evolving code, maintaining) the mappings (
keywords.resource) between the functional natural language spec (*.robot) and the implementation. It was productive work because once a component is stable, you rarely touch it, yet your functional tests (if you do it right, this is basically user contract testing) work automagically and the most important (UX) regressions are caught.Now, I'd bet that a well-instructed LLM of the year 2026 can generate these mappings in a whiff. It probably doesn't even need a browser to check and can just do it from code. So the only extra work this brings is writing the spec, and review/debugging those mappings (lightly, hopefully.) I'll see if I can get some intel out of former colleagues re: their LLM integrations with this.