Behaviour Coding: BDD + Kiro for the Disruptive Economy

Behaviour Coding: BDD in the Age of Automation

Warnings

⚠️ Warning 1

This article is written with AI as a copilot, and the irony is intentional. We are writing about AI while using AI.

⚠️ Warning 2

This perspective may feel irreverent to some. We live in a disruptive economy where staying relevant means questioning old dogmas. The paradigm of software development has shifted, and our practices need to evolve with it. Behaviour Coding is our answer to keeping BDD principles alive while embracing speed and automation.

⚠️ Warning 3

This piece is inspired by the article "Is BDD Dying?". That discussion led us to a new approach to BDD that we call Behaviour Coding.

---

The Paradigm Shift (Why This Matters)

We are caught between two unacceptable extremes.

On one side, vibecoding (writing code without discipline or verification) is not an option. It leads to unmaintainable chaos.

On the other side, the traditional approach where every single line is reviewed line by line is no longer competitive, especially now that AI can generate an MVP in a fraction of the time.

Most of our coding practices were shaped during the Clean Code era, when the main rule was simple: write code for humans to read and understand. That made sense when humans were the primary consumers of code. Robert C. Martin's principles were revolutionary and are still a solid foundation, but the context has changed.

Today, most of the time humans do not need to read every single line of code to understand what is happening. When something is unclear, tools can help us inspect and explain it. The speed of feature delivery now matters as much as individual code readability. Verifying behavior is more important than polishing pure code aesthetics.

The paradigm has not just shifted, it has inverted. The solution is not to abandon quality or discipline, but to focus on what actually matters: behavior first, code quality second.

We need a hybrid approach that works for both startups and enterprises, giving us long term consistency without sacrificing speed in the present.

This new approach in Behaviour Coding is based on three simple principles:

1. Fewer people in the loop
   Instead of three separate amigos (business, developer, tester), there is usually one or two: a functional person and, when needed, a technical one. The implementation is delegated to automation. Like the Christian idea of three in one, roles are closer and more unified.

2. Documentation is dead, tests are the documentation
   Feature files written in Gherkin or Cucumber syntax are the single source of truth. They describe behavior, drive tests, and keep technical and non technical people aligned. There are no extra requirement documents or design specs to keep in sync. If the feature passes, it is up to date. If it fails, everyone sees what is broken.

3. If something is not clear, read and ask
   Most of the time no one needs to read every single line of code. When something is unclear, you can read the relevant part of the code and use tools to inspect and clarify it. Asking external sources like internal documentation, old tickets, or wikis often leads to outdated or misleading information, while the feature files and tests always reflect the current behavior. Understanding comes from behavior plus focused inspection, not from trying to manually review everything.

---

From Spec to Feature Files to Implementation

Behaviour Coding starts from behaviour, lets automation handle the repetitive work, and keeps people focused on structure and consistency.

From Feature to Code

The technical workflow follows a simple pipeline:

*.feature → kiro/requirements.md → design.md → code

• You start by writing a *.feature file that describes the expected behaviour.
• A hook reads that file and creates kiro/requirements.md with structured requirements.
• From there, a design.md file is generated with an ASCII overview of the architecture that will be implemented.
• When the design looks good, the implementation is created from it.

The stack behind this is Cucumber or Gherkin for the feature syntax, Cypress for end-to-end tests, and a monorepo with three main folders: frontend, backend and e2e.

Kiro: From Spec to Structure

Kiro is the engine that turns behaviour into files the team can agree on and review.

*.feature
     |
     v
kiro/requirements.md
     |
     v
   design.md
     |
     v
 Code changes

• Kiro reads the feature files, extracts the requirements, and writes them into requirements.md.
• Then it proposes a design.md file that shows how the system should be structured.
• Only after this design step is approved does Kiro move on to generating or updating the actual code.
• This keeps the flow spec driven instead of prompt driven.

How the Team Works Day to Day

Collaboration phase

Functional  +  Technical
    \         /
     \       /
   write *.feature
         |
         v
 Scenarios agreed

• A functional person and a technical person write or refine the feature file together.
• They use Gherkin syntax, agree on clear scenarios, and add test ids so that selectors stay stable.
• The conversation stays on what the user needs to do, not on implementation details.

Implementation and review phase

*.feature -> Kiro -> Code
                      |
                      v
            Technical review

• Kiro generates the changes for frontend, backend and E2E tests based on the agreed behaviour.
• The technical person no longer types everything from scratch.
• Their job is to check that:
  • The generated code follows the project architecture and patterns.
  • Existing components and utilities are reused.
  • The style and conventions of the codebase are respected.
  • Passing tests confirm that the behaviour is correct, so the review can stay on structure and long-term maintainability instead of reading every line.

---

Tools to Verify Code Quality

Because automation can produce a lot of code quickly, quality is enforced in layers:

+----------------------+
| 1. Automated review  |
+----------+-----------+
           |
           v
+----------------------+
| 2. Human review      |
+----------+-----------+
           |
           v
+----------------------+
| 3. Static analysis   |
+----------+-----------+
           |
           v
+----------------------+
| 4. Coverage (NYC)    |
+----------------------+

• Automated review checks for common mistakes and risky patterns on every pull request.
• Human review focuses on design, boundaries and reuse of existing components without needing to inspect every line manually.
• Static analysis tools such as Sonar catch duplication, security issues, maintainability problems and code smells.
• Coverage (NYC/Istanbul) shows how much of the code is exercised by end-to-end tests. Untouched areas signal missing scenarios or generated code that needs manual attention.

Together, these layers ensure that behaviour drives everything, automation produces most of the code, and human effort is reserved for architecture, patterns, and long-term quality.

---

Conclusion

Behaviour Coding is not about lowering the bar on quality or discipline. It is about choosing carefully where human attention creates the most value, and recognising that our tools and context have changed.

The core idea is simple: verifying behaviour matters more than inspecting every line of code. If the tests pass and the behaviour is correct, implementation details remain important—but they are no longer the first concern.

Code quality still matters, but it is safeguarded through good tests, consistent patterns, and automated checks, not through large-scale manual reviews.

This shift from code written for humans to code verified by behaviour can feel uncomfortable and challenges years of habit, but it is necessary. Teams that combine human judgment on behaviour with automated implementation and strong quality gates will move faster than those who cling to old workflows.

Behaviour Coding is BDD evolved for this new context. Instead of asking "Is BDD dying?", the real opportunity is to use its core ideas to build what comes next.