BSW.DevSpark — AI-Assisted Development at BSW

What BSW.DevSpark Is

BSW.DevSpark is a development methodology delivered as a collection of text files. It is a structured way of working with AI coding assistants — documented as markdown prompt files and helper scripts that sit in a repository alongside the code.

There is no program to install. There is no service to call. Once the methodology files are copied into a repository, they have no runtime connection to the outside world — they are static text that the team owns.

"Not a program. Not a subscription. Just markdown files you copy into your project."

Enterprise Concerns — How BSW.DevSpark Addresses Them

Vendor and AI Tool Lock-In — Any organization adopting AI-assisted development faces the risk of becoming dependent on a single vendor or model. BSW.DevSpark is designed explicitly to prevent this. Because it is agent-agnostic and the prompts are plain text in the repository, switching from Copilot to Claude to any other tool requires no changes to the methodology, the specs, or the decision artifacts. The work product belongs to the team, not the tool.

External Dependencies and Supply Chain Risk — Introducing third-party tooling into a software supply chain is a legitimate governance concern. BSW.DevSpark eliminates this risk by design. The methodology files are copied directly into the repository as static text. There is no package reference, no external call at build time or runtime, and no connection to any outside system once implemented. The repository is entirely self-contained.

Governance and Coding Standards Enforcement — A common failure mode in AI-assisted development is that standards get described but not enforced — developers use AI tools in inconsistent ways and quality varies. BSW.DevSpark addresses this through the constitution, a living governance document that every prompt reads and enforces automatically. Standards are not a wiki page that drifts out of date. They are active constraints applied at every step of the development lifecycle.

Legal and Compliance Exposure from LLM-Generated Code — Organizations are right to ask how AI-generated code is reviewed, documented, and attributed. BSW.DevSpark's spec-driven workflow creates a documented chain of intent — from requirement through specification through implementation — that makes it clear what a human decided and what an AI produced. Every change is grounded in a spec that a human authored and approved. This is a stronger audit trail than most traditional development workflows produce.

Security Risk from Third-Party Tooling — Security teams reasonably scrutinize any new tooling introduced into development environments. BSW.DevSpark is maintained in BSW's Azure DevOps repository (bsw.devspark), auditable by any BSW engineer, and introduces no executables, no network calls, and no data transmission of any kind into consuming repositories. There is nothing to audit at runtime because there is nothing running.

Developer Adoption and Workflow Disruption — Mandated tooling that disrupts existing workflows creates resistance and workarounds. BSW.DevSpark avoids this entirely. Adoption is voluntary. A developer who chooses not to use it is unaffected. A developer who adopts it partially uses only what helps. The methodology earns adoption by delivering value, not by being enforced. Eight months of voluntary adoption on the FCN team demonstrates this in practice.

Does BSW.DevSpark comply with BSW enterprise architecture standards?

Yes. BSW.DevSpark is a development methodology delivered as plain text files. It introduces no external runtime dependencies, no vendor relationships, no third-party services, and no network connections of any kind into BSW repositories. It is fully compatible with BSW's current published policies on third-party dependencies and AI-assisted development.

Is there a cost or vendor relationship?

No. BSW.DevSpark is free to use within BSW. There is no license fee, no subscription, no contract, and no external vendor. BSW can use, modify, and distribute it internally without cost or approval from any outside party.

Who maintains BSW.DevSpark and what happens if the maintainer leaves BSW?

BSW.DevSpark is developed and maintained by the FCN Engineering Lead (Mark Hazleton) at BSW, in the internal Azure DevOps repository (bsw.devspark). If the maintainer were to leave BSW, the methodology files already checked into BSW repositories would continue to function exactly as they do today — they are static text files with no external dependency. BSW owns the canonical repository and can continue maintaining it independently at no cost.

Does this create a dependency BSW does not control?

No. When BSW.DevSpark is adopted in a BSW repository, the methodology files are copied directly into that repository as static text. There is no link, reference, or runtime connection back to the canonical BSW.DevSpark repository. BSW owns and controls every file in its repositories.

What is the difference between the canonical BSW.DevSpark and what is in BSW repositories?

The canonical BSW.DevSpark repository in BSW Azure DevOps (bsw.devspark) is the source. When a BSW team adopts BSW.DevSpark, a snapshot of the relevant files is copied into their repository under the .devspark/ folder. From that point forward those files are managed like any other file in the BSW repository — versioned, reviewed, and owned by the team. The team can update to a newer snapshot at any time or choose never to update and manage the files independently.

Has this been reviewed by security?

BSW.DevSpark introduces no executables, no compiled binaries, no network calls, and no data transmission into any BSW repository. It is plain text — markdown files and shell scripts. There is nothing to execute at build time or runtime, and nothing leaves BSW's environment as a result of BSW.DevSpark being present in a repository.

Is my code sent anywhere by BSW.DevSpark?

No. BSW.DevSpark itself sends nothing anywhere. When a developer uses an AI coding assistant such as GitHub Copilot or Claude Code, their code is processed by that AI provider per their existing terms of service — the same terms that apply when using those tools without BSW.DevSpark. BSW.DevSpark adds no telemetry, no logging, and no data transmission of any kind.

Can we use BSW.DevSpark to enforce org-wide standards?

Yes — and this is one of BSW.DevSpark's most compelling enterprise use cases. The constitution system allows Dev Infrastructure to define BSW-wide architectural standards, security requirements, and dependency policies as a governed markdown document. Any team adopting BSW.DevSpark would have those standards automatically enforced at every step of development — specification, implementation, and PR review — without manual oversight overhead. BSW.DevSpark could serve as BSW's active AI governance layer across all product teams.

What Goes Into a Repository

Two folders are added:

  • .devspark/ — a direct copy of the BSW.DevSpark prompt defaults and helper scripts. A static snapshot, managed like any other file in the repo.
  • .documentation/ — repo-specific content generated by the process. Specs, plans, architecture decisions, and team overrides. The team's own work product.

These two folders are always kept separate. BSW.DevSpark source files and project content never mix. You always know which is which.

Three Pillars

Agent-Agnostic — No Lock-In — BSW.DevSpark works with 18+ AI coding assistants including GitHub Copilot, Claude Code, Cursor, Gemini CLI, and Amazon Q. It is not a Copilot solution. It is not a Claude solution. It is not tied to any vendor, model, or platform. Teams can switch AI tools at any time without changing their workflow or losing a single spec, plan, or decision artifact.

Multi-User — Shared Standards, Individual Freedom — Teams share a common governed workflow. Individuals can personalize any prompt to match their style. Personal overrides are committed to the repository and take priority over team defaults. Delete the override and the team standard is restored instantly. No configuration drift. No shadow processes.

Full Lifecycle — Right-Sized for Every Task — Every phase of development is supported — greenfield creation, brownfield discovery, bug fixes, maintenance, and release management. A one-line fix takes ~2 minutes. A major architectural feature uses the full spec workflow at ~15–20 minutes. The methodology matches the overhead to the task. Developers are never forced into a heavyweight process for small work.

Developer Freedom — Nothing Is Forced

A developer who does not want to use BSW.DevSpark can work in the same repository, make changes, ship features, and never invoke a single BSW.DevSpark prompt. The files sit in the repo and do nothing unless a developer actively chooses to use them.

A developer who wants to use BSW.DevSpark partially can pick what helps and ignore the rest. A developer who wants to personalize the prompts to their own style can do that — their overrides live in their own folder and do not affect anyone else.

BSW.DevSpark does not take over. It does not enforce a single way of doing things. It does not create lock-in of any kind. It is a methodology that sits alongside the work and offers structure to those who want it.

Voluntary adoption that spreads because it works — not because it is mandated. That is exactly what happened on the FCN team over eight months.

The Constitution

The constitution is a markdown file (.documentation/memory/constitution.md) that defines a project's non-negotiable principles: coding standards, security requirements, architecture rules, and dependency policies. See the Constitution Guide.

Every BSW.DevSpark prompt reads the constitution and enforces it automatically. Governance is not a one-time review event — it is built into every specification, every implementation, and every PR review by the methodology itself.

BSW.DevSpark could be used by Dev Infrastructure to codify and actively enforce BSW's architectural standards across all product teams — automatically, consistently, at no cost, maintained by a BSW employee. The methodology sometimes flagged as a governance risk is the methodology best positioned to solve BSW's AI governance challenge.

Where It Came From

BSW.DevSpark was forked from Spec Kit — an open-source spec-driven development starter — and rebuilt substantially over eight months. It is now maintained internally at BSW as the canonical bsw.devspark repository. BSW can use it, modify it, or adopt it org-wide at no cost.

Want to Know More?

Edit this page