Using ZapCircle in a Developer's Workflow

Overview

Once you adopt ZapCircle into your development process, you’ll see improvements in how fast you can get code from ideas to production-ready.

Below, we’ll outline the process when you use ZapCircle and compare it to a hypothetical existing workflow. This should demonstrate how ZapCircle speeds up and streamlines the process.

---

ZapCircle Workflow

1. Gather Requirements

   • The product owner gathers a list of requirements for a new feature or component. Usually in consultation with a developer.
   • Requirements are detailed and focused on the expected behavior of the component.
   • Typically these requirements are in the JIRA ticket or Linear issue, for instance, and would not end up checked into source control.

2. Review and Refine

   • The developer reviews the requirements with the product owner to ensure clarity and completeness.
   • They identify key behaviors and interactions for the component.

3. Create Behavior Specification

   • The developer translates the requirements into a .zap.toml file.
   • The file defines the behavior of the component in a structured and human-readable format.
   • Usually, any technical requirements are added here, such as variable names or specific libraries to use.

4. Generate Component and Tests

   • Using ZapCircle, the developer generates the new component and its associated tests.
   • This two-step process includes generated code from the LLM and testing suites based on the behavior spec and the component.

5. Make Adjustments

   • The developer reviews the generated component and makes any necessary adjustments in case the generated code doesn’t work as expected.
   • ZapCircle can keep the behavior in the .zap.toml file synced with the changes to the code, or the developer can make changes to the behavior, and have that reflected in the code.

6. Commit and Build

   • The developer commits the updated code, tests, and .zap.toml file into source control.
   • The build pipeline integrates the changes, ensuring they’re ready for testing and deployment.
   • The .zap.toml file is not used at run-time, but could be used for analysis in the build pipeline.

---

Hypothetical Existing Workflow

1. Gather Requirements

   • The developer works with the product owner to gather requirements, often informally or through incomplete documentation.
   • Requirements may lack clarity, leading to ambiguities in implementation.

2. Iterative Refinement

   • There’s frequent back-and-forth between the developer and product owner to clarify requirements.
   • This iterative process consumes time and increases the risk of miscommunication.
   • There is no history of the requirements change in source control - only in the ticket, chat logs, or email.

3. Manual Implementation

   • The developer manually writes the component from scratch.
   • Autocomplete tools or code snippets might help, but they rely on developer input and context.
   • Developers often copy and paste boilerplate code or query LLMs for guidance, leading to inconsistent results.
   • There is no verification that the implementation matches the expected behavior by the product owner, except with manual testing by the product owner, or possibly during a sprint demo.

4. Testing

   • Tests are either manually written or added as an afterthought.
   • This step is prone to errors and omissions due to time constraints.

5. Commit and Build

   • The code and tests are committed into source control, but inconsistencies or gaps in testing can lead to build failures or regressions.

---

How ZapCircle Speeds Up the Workflow

ZapCircle integrates seamlessly into the existing workflow by introducing behavior-driven development and automating critical steps:

1. Clearer Requirements

   • Product owners and developers collaborate on behavior specifications, reducing ambiguities.
   • The .zap.toml format ensures all requirements are structured and actionable.

2. Automated Code Generation

   • ZapCircle will create the first version of code, or the first take on a change automatically - so developers can get something up and running quickly.
   • Developers generate components and tests directly from behavior specs, saving time and ensuring consistency.

3. Reduced Iteration

   • With well-defined behaviors, the need for back-and-forth communication is minimized.
   • Developers can focus on implementation and refinement rather than clarifying requirements repeatedly.

4. Built-In Testing

   • Tests are automatically generated alongside components, ensuring better test coverage and reducing manual effort.

5. Improved Source Control Practices

   • The .zap.toml file, along with the generated code and tests, provides a complete snapshot of the feature.
   • This approach improves traceability and makes future updates or debugging easier.
   • Future versions of ZapCircle can provide additional analysis steps on top of the existing .zap.toml files, without any additional work by the developer or product owner.

---

Visualizing the Workflow

ZapCircle Workflow:

1. Requirements → 2. Review → 3. Behavior Spec → 4. Generate Code & Tests → 5. Adjustments → 6. Commit & Build

Existing Workflow:

1. Requirements → 2. Back-and-Forth → 3. Manual Implementation → 4. Manual Testing → 5. Commit & Build

---

Conclusion

By integrating ZapCircle into your workflow, you can:

• Reduce development time.
• Improve collaboration between developers and product owners.
• Ensure high-quality, well-tested components.

ZapCircle bridges the gap between requirements and implementation, making behavior-driven development accessible and efficient for modern teams.