A friend of mine recently came back from a conference session on “vibe coding” with the kind of energy you only get when something fundamental has shifted. They are smart, tech-enabled, and fully comfortable around digital tools, but they are not a programmer. After a brief introduction, they sat down and built several applications. Not toys. Not abstract demos. Useful applications that solved real problems in both their daily life and their professional work. They even shared those applications with colleagues. And, as is often the case with these new tools, the apps were not only functional. They were polished, themed, and appealing to use.
That story is easy to file under amazement. It is harder, and more important, to recognize it as a signal. The computing world is going through a fundamental shift that changes the locus of invention. Before – and almost every programmer has had this experience, I suspect – non-developers would come up to you and tell you an idea, then try to get you to help them make it happen. Now they can do a lot of the hard work themselves!
The signal, though, is not that everyone should now go build production systems from a prompt window and hope for the best. The signal is that the distance between understanding a problem and expressing a solution in software has collapsed. The people closest to the work can now participate in shaping the tools they need in a much more direct way. That is the breakthrough. And in the financial services sector, where structure, security, explainability, and accountability are non-negotiable, the way to turn that breakthrough into something durable is not vibe coding. It is spec-driven development.
If we want a world where everyone can get to what they need to do, their way, even inside the highly governed world of banking, wealth management, lending, life insurance, reinsurance, property and casualty insurance, and credit card processing, then spec-driven development should become the new citizen development model.
The story is bigger than the app
For years, citizen development has largely meant sanctioned low-code or no-code tools. First, we should define some terms:
- Citizen developers as non-IT employees who create applications or enhance systems, typically through approved low-code or no-code tools.
- Low-code governance is the way organizations guide professional and citizen developers in building applications on approved platforms.
That model mattered because it widened participation without abandoning governance. The limitation often became that the tools imposed assumptions on the creation of applications and workflows. Traditional developers were often required to “finish” and fully customize the tool to meet the exact needs of the users.
But the newest wave is different. Agentic coding tools now do far more than autocomplete. GitHub says that its cloud agent can research a repository, create implementation plans, fix bugs, improve test coverage, and make code changes on a branch for review. Claude Code is an agentic coding assistant that can read a codebase, edit files, run commands, and automate development tasks across tools. In other words, the barrier has not just dropped for assembling interfaces. It has dropped for shaping software behavior itself.
Its about a new authoring layer for work.
That changes the meaning of citizen development. The old model democratized assembly inside a platform. The emerging model democratizes intent. A wealth advisor, underwriting analyst, loan operations specialist, claims professional, or card disputes lead no longer has to translate every idea through a professional developer before the first working version exists. They can express the business need directly. It is not about a conference novelty. Its about a new authoring layer for work.
Why vibe coding is the wrong endpoint
The problem is that the same thing that makes vibe coding exhilarating also makes it insufficient for financial services. GitHub’s own recent writing on the topic is candid: prompt-first “vibe coding” can be useful for quick prototypes, but it is less reliable for serious, mission-critical applications or work in existing codebases. Their argument is not that the models are incapable. It is that one-shot prompting is the wrong operating method when intent, constraints, and validation matter. The answer is to make the specification the source of truth and let the AI work from that shared artifact.
That distinction matters even more in the financial services sector. FFIEC guidance on authentication and access makes clear that financial institutions must manage access not only for customers, but also for employees, board members, third parties, service accounts, applications, and devices, with controls calibrated to risk. The same guidance emphasizes risk assessments, layered security, monitoring, and ongoing evaluation of controls. That is the operating context in which any AI-built workflow or application has to live. A useful internal tool that quietly mishandles permissions, logs poorly, or bypasses review is not a productivity win. It is an operational risk event waiting for an incident review.
So the right response is not to dismiss this new wave of of citizen development, and it is not to let a thousand unmanaged prompts that turn into applications bloom. It is to ask a better question: what process keeps this new creative velocity while making it fit for a regulated, security-conscious, multi-stakeholder environment? That is where spec-driven development comes in.
Spec-driven development is citizen development rewritten
Spec-driven development is a shift in which specifications stop being disposable scaffolding and become executable artifacts. Its core philosophy is intent-driven development, where the specification defines the “what” before the “how,” using guardrails, organizational principles, and multi-step refinement rather than one-shot code generation. Github’s quick start process makes that concrete: define a constitution, create the spec, clarify ambiguities, create the technical plan, break the work into tasks, analyze, and then implement.
The non-developer need to become a precise author of intent.
That sequence is the heart of the new citizen development. The non-programmer should not try to become a software engineer. They need to become a precise author of intent. They need to describe the workflow, the user journey, the exception cases, the data boundaries, the approvals, the outputs, and the definition of success. The AI can then do what it is increasingly good at: produce plans, tasks, code, tests, and iterations. The framing is especially important here: the human’s primary role is to steer, while the coding agent does the bulk of the code production.
That is why I would argue spec-driven development is the real successor to low-code citizen development. Low-code let business users build inside a contained system. Spec-driven development lets business users define what should be built across systems, while engineering, security, and governance teams shape the constitutional rules, architectural boundaries, validation practices, and release controls. It does not eliminate the need for professional developers. It makes their role more valuable. They become the builders of the platform, guardrails, reusable patterns, and review systems – and the layered specifications that define them and how they interact with the desired software – that let many more people safely participate.
In other words, spec-driven development does not turn everyone into a coder. It turns more people into legitimate contributors to software creation.
Why financial services should lean in, not back away
This is also arriving at exactly the moment financial services needs a more disciplined bridge between AI creativity and institutional control. In February 2026, the U.S. Treasury released an AI Lexicon and a Financial Services AI Risk Management Framework, arguing that common terminology and tailored risk management practices are needed to support faster, more consistent AI adoption in the sector. Treasury explicitly said inconsistent terminology and uneven risk management practices have created governance and oversight challenges, and the FSSCC materials describe the framework as a financial-services-specific operationalization of NIST’s AI RMF.
That matters because specifications are not just build instructions. In a financial institution, they can become the translation layer between regulatory, legal, technical, operational, and business functions. Treasury’s point about common language is not academic. It is practical. When a banker says “review,” a risk officer says “approval,” a technologist says “workflow state,” and a compliance leader says “evidence,” the spec is where those meanings have to converge before code is written, this spec becomes an enterprise governance layer.
The broader risk guidance is moving in the same direction. NIST’s Generative AI Profile positions itself as a companion resource to the AI RMF and says organizations need ways to govern, map, measure, and manage GenAI risks across the AI lifecycle. The FSSCC’s explainability paper says trust, transparency, and accountability remain pillars of financial services and that institutions are integrating governance frameworks, data governance, prompting guardrails, assurance and testing methodologies, and ongoing risk monitoring to support responsible GenAI use.
This is exactly why spec-driven development belongs in the sector. A layered spec externalizes purpose, as defined by the different people who have the responsibility to define the spec, the initial intent definer, the security team, the architecture team, the devops team, and the data team all write their own portions that become a part of the entire spec. A plan externalizes architecture and constraints. A task list externalizes the work into reviewable units. Tests and evaluations externalize whether the result behaves as intended. And when implementation happens in a reviewable environment, like GitHub’s branch-and-pull-request workflow with logs and automated checks, the process becomes materially more transparent than a burst of local prompting on a laptop. GitHub’s own documentation highlights that cloud-agent workflows add transparency because the work happens on GitHub, in commits and logs, before review.
There is an even deeper alignment here with long-standing banking control principles. Federal Reserve SR 11-7 says effective model risk management requires a clear statement of purpose, rigorous assessment of data quality and relevance, appropriate documentation, independent validation, and sound governance, policies, and controls. Spec-driven development is not identical to model risk management, and we should not pretend otherwise. But it is directionally aligned with the same disciplines: explicit intent, documented assumptions, validation, ongoing review, and governance that can be understood by parties beyond the original builder.
That is the key point for financial services leaders. Spec-driven development is not the anti-governance answer to AI-assisted building. It is the most governance-compatible version of it.
What “everyone gets what they need, their way” actually looks like
- In wealth management, that could mean an advisor-specified meeting prep workspace that assembles approved household context, product holdings, service issues, policy reminders, and disclosure-ready next-step drafts in the format that advisor actually uses.
- In life insurance, it could mean a new-business intake assistant that summarizes evidence, flags missing documentation, and drafts follow-up tasks without making final underwriting decisions.
- In property and casualty insurance, it could mean a first-notice-of-loss triage cockpit shaped around role-specific workflows.
None of those examples require a fantasy that one generic enterprise interface will serve every role well. Quite the opposite. They assume the work is different, the language is different, the timing is different, and the evidence needs are different. The reason spec-driven development matters is that it lets the people closest to each workflow define that difference in a form that an AI and an engineering platform can reliably use while letting the experts define the technical standards that the coding agent has to meet.
And in high-stakes contexts, the controls remain where they belong. The FSSCC explainability guidance explicitly points to human-in-the-loop review for high-stakes or ambiguous decisions, alongside documentation, monitoring, and feedback loops. So the vision is not “everyone builds whatever they want.” The vision is “more people can author the tools they need, inside a system that knows when human judgment, approval, and audit evidence are required.”
That is the world financial services should want. Not a locked-down future where only centralized teams can shape digital tools, and not a chaotic future where anyone can ship anything. A third model. Faster local authorship, stronger shared controls.
Pulling it all together
Start with a constitution, not a sandbox. GitHub’s spec-driven workflow begins by defining project principles. Financial institutions should do the same at the enterprise level for spec-driven citizen development: data boundaries, approved integration patterns, logging requirements, testing expectations, explainability needs, human review thresholds, third-party usage rules, and security defaults. Make those principles machine-usable and reusable. Do not leave them in a policy binder and hope the builders remember.
Then choose the first wave of use cases carefully. Start with painful internal workflows where the business value is obvious and the control envelope is manageable: case preparation, exception handling, reconciliation support, knowledge retrieval, quality assurance, drafting, and role-specific operations workbenches. Keep autonomous decisioning at the edges until the organization has built muscle in specification, validation, monitoring, and review. That is not caution for caution’s sake. It is how institutions earn the right to expand.
Most importantly, make the spec the handshake across business, technology, risk, and compliance. Do not treat it as a product manager artifact that disappears once coding begins. Treat it as the living source of intent. When the risk team asks what the application is allowed to do, the answer should be in the spec. When security asks what data it can access, the answer should be in the spec and the plan. When internal audit asks why a workflow behaves the way it does, the answer should trace back to the spec, the plan, the tasks, the tests, and the approvals.
And finally, industrialize review. Use environments where AI-generated work is branch-based, testable, logged, and pull-requested. Require measurable validation. Keep humans accountable for decisions near customer outcomes, financial loss, fraud controls, underwriting judgments, and credit actions. The point is not to slow the system down until it feels familiar. The point is to let software be created at the speed of thought while still being released at the speed of trust.
Conclusion
My friend’s story is not a side note in the evolution of technology. It is a preview of a new distribution of capability. More people can now move from idea to application than ever before. In financial services, the question is whether we will force that capability into the old false choice between central IT bottlenecks and uncontrolled shadow tooling.
We do not have to.
Spec-driven development gives the sector a better path. It turns enthusiasm into architecture. It turns prompts into governed intent. It gives business experts a real voice in building the tools they use, while preserving the things financial services cannot afford to lose: security, validation, explainability, resilience, and accountability.
That is why spec-driven development should become the new citizen development. Not because it is fashionable, but because it is the first model that truly fits the world we are entering: a world where more people can build, and where the institutions that win will be the ones that let them do it safely, visibly, and well.
The next move should be simple. Pick one high-friction workflow in your organization. Put a domain expert, a product lead, an engineer, and a risk partner around the table. Write the spec. Define the constraints. Let the AI build from there. That is how you move from vibes to value.
