Behavior-driven development should be focused on the business behaviors your code is implementing: the “why” behind the code. It supports a team-centric (especially cross-functional) workflow.
I’ve seen agile BDD work really well when a developer and either the Agile product owner or a business analyst sit down together and write pending specs (to be filled in later by the developer) in a plain text editor:
The business person specifies behaviors they want to see in the system.
The developer asks questions based on their understanding of the system, while also writing down additional behaviors needed from a development perspective.
Ideally, both parties can refer to the list of current system behaviors to see if this new feature will break existing features.