AI code gen means that anything that is currently modeled as a spreadsheet is better modeled in code. You get all the advantages of software - libraries, open source, AI, all the complexity and expressiveness."
“Anything that is currently modeled” would be true if we could guarantee the correctness of AI-generated code.
Business people prefer the familiarity of spreadsheets, or at least some kind of grid. At the same time, I am working on this software out of frustration with spreadsheets, because users are forced to translate A1*B2-style addresses into business meaning.
So I agree that code is one possible direction. But I think there is also a middle ground: business rules over dimensions. Enterprise tools like TM1 have explored this direction for decades.
If you have invested significantly in the planning phase and there is momentum in the architecture and conventions that already exist in the project, the implementation phase might not need as much oversight as is suggested here.
> You can discover that your initial idea was dumb and a better one exists
The planning and architecture phase is usually where I make these types of discovery at a high level.
> Your agent might go “off the rails” and start doing something you don’t want it to do
Candidly these orthogonal, inadvertent edits aren't as bad as they once were and for impactful changes there should be at least some test coverage, even if that test coverage is just "freezing" what was implemented.
As you mentioned the final review discussion is a good chance to verify beyond what review or adversarial review agents find.
I think the obvious solution here is to beef up the test side of the app, much more than when writing code by hand. Tests represent project knowledge in executable format. The LLM does not need to be careful to remember every detail of the tests. You don't need to vet every small interaction, it automates review work as well.
Even better if the project was built from the start to be easier to test and observe. But my golden rule remains - no code without tests, expand test suite all the time.
Not the creator, but looking at the source - everything is sized using 'rem' units. (Height, width, positioning of all the elements.) Kind of like using a percentage.
The best outcome is just to change the name right now and be careful not to violate trademarks and avoid any chance of conflict. They won’t be sued if they hurry to rename it to something generic, change the domain name, change the wording to say “compatible with headphones made by Bose”, include prominent text that says “Bose is a trademark of Bose Corporation and this product is not endorsed or supported by them in any way”, stop using their trademarks incorrectly (some instances are improperly lowercase), etc.
They can even redirect the old domain to the new one for a while. A company like Bose is not going to punish a mistake that was corrected in good faith in a timely manner.
Interestingly in OP's tweet (same username as his HN username): [1], he credits [2], who made a Linux CLI for the same functionality, and named it "based-connect". And the CLI-coder got a summer internship at Bose, so it doesn't seem Bose was that mad.
But still, using the name Boze is cease and desist magnet.
Makes me wonder how much work OP did, did he just wrap the CLI around an Electron UI?
"prediction re the end of spreadsheets
AI code gen means that anything that is currently modeled as a spreadsheet is better modeled in code. You get all the advantages of software - libraries, open source, AI, all the complexity and expressiveness."