Behaviour Coding Template

• 

  hour webhook

Inspiration

We wanted to rethink how teams build software in a world where code can be produced faster than traditional workflows can handle. Code-first approaches, long reviews, and manual test writing slow teams down. Behaviour-driven development already had the right foundations, but the process was often difficult to apply consistently. The idea behind Behaviour Coding was to put behaviour at the centre and build a workflow where specifications naturally lead to implementation.

What it does

The Behaviour Coding Template turns a Gherkin *.feature file into a complete development workflow. Gherkin syntax is readable by both technical and non-technical people, which means everyone works from the same, shared description of how the software should behave. This becomes the single source of truth: there is no need for external documents that quickly become outdated, duplicated, or inconsistent.

From this one feature file, the template generates structured requirements, a design overview of the architecture, and the corresponding updates for the frontend, backend, and end-to-end tests. The same syntax that describes behaviour also drives the automated tests, ensuring that the system behaves exactly as the feature file promises.

How we built it

We combined Gherkin for the feature syntax, Cypress for end-to-end tests, and a monorepo that separates frontend, backend, and E2E. The core engine, Kiro, reads the feature files, extracts requirements, writes them to requirements.md, produces a design.md file, and generates the corresponding code changes. Quality gates are enforced through automated review, static analysis, and coverage checks.

Accomplishments that we're proud of

We created a workflow where specifications flow naturally into architecture and code. We reduced repetitive work while keeping engineers focused on structure, reuse, clarity, and long-term maintainability. We demonstrated that behaviour-driven workflows can be practical, predictable, and scalable across a real project. Most importantly, we made it easier for teams to collaborate around behaviour instead of jumping straight into low-level implementation.

What we learned

Clear behaviour specifications simplify everything that follows. Architecture is easier to maintain when it’s defined early in the process. Automated checks free reviewers to focus on higher-level decisions. A behaviour-first workflow reduces ambiguity and creates more consistent outcomes across large codebases.

What's next for Behaviour Coding Template

This first version was a rough proof of concept built quickly to show how the workflow could function end-to-end. Even in its early state, it has already been tested in an internal environment, and the results confirmed that the approach is practical and worth developing further. We are now refining the structure, tightening the generation steps, and improving the quality gates around it.

As part of this evolution, the team is migrating from Cursor to Kiro and has begun testing the new workflow during the past week. The goal is to stabilise the pipeline, streamline the feature-to-design-to-code process, and make Behaviour Coding a reliable foundation for real projects.

Planned improvements include better generation accuracy, smoother integration with existing repositories, and stronger support for incremental updates rather than full rewrites.

Built With

• cypress
• docker
• kiro
• node.js
• typescript