5 ms·

The example of “transcibe the initial project discussion, turn that into BDD and that makes the rails to guide the AI is … either brilliant and insightful or a

The example of “transcibe the initial project discussion, turn that into BDD and that makes the rails to guide the AI is … either brilliant and insightful or a snake eating it’s own tail. I think it has to be worth a try though…

jaggederest 1mo ago
I've been doing that for almost a year and I feel like I'm taking crazy pills when I talk about it, because it works so well. I transcribe most product meetings, turn them into a transcript, run that through an accuracy pass with a bunch of context (mostly vocabulary definitions etc), and use that as a starting doc for generating issues and tests. There are apps that do it fully end to end now I think.
- lifeisstillgood 1mo ago
  Any hints for running pilot projects (at large, bureaucratic org)
  - jaggederest 1mo ago
    Yeah, basically I would just start transcribing everything, if you aren't already, and get a bunch of context. It's best to start from the very beginning but the reality of enterprise is that nothing is truly greenfield. Maybe start with a project kickoff or brainstorm, some kind of planning meeting, and select one task out of it to start. I always start with just the meeting transcript as a context, and expand context from there as needed with things like internal standards docs, libraries, references from other projects, etc, and only as little as is necessary. That generates the project plan, and then I feed that into claude code or whatever. I think the biggest thing I've done recently is start to be extremely critical about the output, basically using promptfoo to try to figure out what the right level of context and instructions are, not just for external facing e.g. chatbots or whatever, but for my own internal development process, planning, everything. The more you can pin down and calibrate the better - it's easy to run a given prompt for a month, so spending a day (or even a week!) out of the month to refine your prompts beats just grinding ad hoc. Edit: another thing I do is generate tests bdd-style separately from the code that they're testing (for e2e and high level at least), that derives out of the project plan too.

jaggederest 1mo ago

I've been doing that for almost a year and I feel like I'm taking crazy pills when I talk about it, because it works so well. I transcribe most product meetings, turn them into a transcript, run that through an accuracy pass with a bunch of context (mostly vocabulary definitions etc), and use that as a starting doc for generating issues and tests. There are apps that do it fully end to end now I think.

lifeisstillgood 1mo ago
Any hints for running pilot projects (at large, bureaucratic org)
- jaggederest 1mo ago
  Yeah, basically I would just start transcribing everything, if you aren't already, and get a bunch of context. It's best to start from the very beginning but the reality of enterprise is that nothing is truly greenfield. Maybe start with a project kickoff or brainstorm, some kind of planning meeting, and select one task out of it to start. I always start with just the meeting transcript as a context, and expand context from there as needed with things like internal standards docs, libraries, references from other projects, etc, and only as little as is necessary. That generates the project plan, and then I feed that into claude code or whatever. I think the biggest thing I've done recently is start to be extremely critical about the output, basically using promptfoo to try to figure out what the right level of context and instructions are, not just for external facing e.g. chatbots or whatever, but for my own internal development process, planning, everything. The more you can pin down and calibrate the better - it's easy to run a given prompt for a month, so spending a day (or even a week!) out of the month to refine your prompts beats just grinding ad hoc. Edit: another thing I do is generate tests bdd-style separately from the code that they're testing (for e2e and high level at least), that derives out of the project plan too.