Vibing in FinTech
The emergence of Rule Engineers
A (not so) quiet revolution has already happened in software development. Vibe Coders are here. With the rise of AI coding assistants, we’ve entered an era where junior developers can piece together working solutions using “Vibing“, ie. Prompting instead of Coding. This lowered the barrier to entry for programming - but for us engineers, it also raised the ceiling of what’s possible.
The trend of vibe-coding is growing incrementally. AI-first development platforms like 💖Lovable are accelerating the shift, making it easier to build real products by vibing through ideas and letting the AI handle the structure. The tooling is evolving fast, and so are our expectations!
While most of us are excited about this no-code, vibing world, the questions remains:
How is it all going to work in Finance?
“Vibing“ in FinTech
In high-stakes, enterprise-grade environments (think: Tier 1 Banks, Hedge Funds, Trading Platforms) where the cost of bugs, downtime, or poor architecture is measured in $ millions, this new reality poses both a risk and an opportunity. AI is no longer just helping us write code faster - it is changing how code gets written at every level.
Software Architects are seeing their roles evolve.
In this new world, their primary audience is AI.
Up until now, the “human” aspect of senior level engineers has focused on guiding, mentoring, and training junior developers and passing down their experience through code reviews, pair programming, and knowledge sharing sessions. Their job was to scale quality through people.
This is changing.
Instead of just shaping the habits of human developers, Software Architects are now shaping the behavior of AI. They do this by defining reusable rules and architectural constraints that guide the assistant’s decisions, ensuring that every “vibed” and AI-generated output aligns with company standards, coding standards, business logic, compliance needs, technical boundaries, and so on.
This work includes:
Defining Coding Rules that AI Agents can follow
Architecting AI development workflows (LLMs, Custom MCP servers, Agent interoperability)
Creating end-to-end, AI-first DX for all engineers in the firm.
In other words:
A new role is beginning to crystallize: the Rule Engineer.
It is the Rule Engineer’s responsibility to make sure “Vibe” coding produces quality code,
that adheres to the company’s expectations and standards.
💎
Does that mean that vibe coding will magically give us 100% clean, usable and fully tested code? No. It means that we need shift our focus and put conscious effort into continuously evolving our AI-first DX(Developer Experience):
❌ Prompt, then fix the mistakes in the code that AI made
✅ Prompt, then fix the mistakes in the rules that led AI to make mistakes
Tools like Cursor, Windsurf are already making this shift possible. They allow engineers to codify their intent as rules, shaping not just what the AI writes, but how it reasons.
What are AI Coding Rules?
Rules are a way for engineers to encode context, preferences, constraints, and architectural decisions directly into AI coding assistants like Cursor and Windsurf.
They shift knowledge from the software architects’ memory into structured, machine-readable instructions that the AI can follow consistently.
Why Rules Matter
Large language models don’t retain persistent memory between prompts. This means they can forget your preferences, deviate from standards, or introduce drift if you don’t constantly remind them. Rules solve this. They inject persistent guidance at the prompt level, so every suggestion via Cmd+K tools or inline chat will align with your organisation’s standards.
In the AI-first engineering stack, rules are the
glue between your org’s requirements and the AI’s behavior.
In a one-off project, this may not matter that much. When you vibe-code a side project, it may be ok to let AI pick the coding style, the libraries, design systems, even the overall architecture.
Once there are 10-100 engineers working on a project, in a large codebase - rules become crucial.
What do Rules look like?
Rules are human-readable markdown files, which immediately implies that anyone can write them!
Engineers can write Engineering Rules
UX Designers can write UX Rules
Product Managers can write Product Rules
InfoSec can write Security Rules
…and so on.
Let’s see an example!
Let’s say you are working for Snoop Dogg Corp., where all React Hooks have to look like YoUse{something}Dogg. Your team members know this rule, but the vibed code keeps messing it up!
Well, not any more!
You can simply create this rule:
// File: snoop-hooks-naming.mdc
---
description: Enforce React Hook naming convention at Snoop Dogg Corp.
globs: ["**/*.tsx", "**/*.ts"]
alwaysApply: true
---
# React Hook Naming Convention – Snoop Dogg Corp. Edition
All custom React Hooks must follow the **"YoUse" + Verb + Dogg** pattern.
### Required Format: YoUse<Verb><Noun>Dogg
### Examples:
- ✅ `YoUseTimeoutDogg`
- ✅ `YoUseFormDogg`
- ✅ `YoUseScrollPositionDogg`
- ✅ `YoUseFetchDogg`
### Anti-patterns:
- ❌ `useTimeout`
- ❌ `useScrollPosition`
### Enforce This In:
- All new custom hook definitions
- All refactors of legacy `useX` hooks
- All internal libraries
Let’s try it!
The result?
Amazing, isn’t it?
Humour aside, imagine this concept being applied to all your architectural decisions, all your design decisions, coding standards, etc - across the whole codebase!
The beauty of these rules is that you can organise them in files in any way that suits your organisation, eg.:
🧠 Core Rules
acme-overview.mdc– general guidance, tone, mindset, shortcutstech-stack-reference.mdc– high-level reference of supported tools and stackmonorepo-scripts-and-caching.mdc– lint/test/build commands, Turborepo caching, CI rules
🧱 Coding Standards
naming-conventions.mdc– casing, directory and file naming rulestypescript-standards.mdc– interfaces, types, Zod, typing disciplinefunctions-and-logic.mdc– preferred syntax, patterns, function declarationserror-handling.mdc– how to handle errors, logging, edge cases
🎨 UI and Frontend
ui-style.mdc– layout, spacing, and component styling with Tailwindcomponent-architecture.mdc– how to structure React or UI components
🚀 Performance and Optimization
performance-rules.mdc– SSR, lazy loading, bundle splittingrouting-and-data-fetching.mdc– fetching, caching, rendering rules
📋 Workflow and Review
code-review-checklist.mdc– what to check before mergingtesting-strategy.mdc– when and how to test, tooling guidancedocumentation-style.mdc– JSDoc, README rules, writing standards
🔀 Version Control
git-commits.mdc– Conventional Commits, formatting, examplesbranching-strategy.mdc– branch naming, PR rules, etc.
Depending on your project, you may want to organise your rules by language (Java, Python, TS, oCaml), protocol(GraphQL, TRPC), domain, team, or department.
You can create any rules in any structure to match your organisations’s needs. (Think Conway’s Law). For example a ["packages/trading-team/**/*.graphql",] pattern will make sure that the rule is only applied to your trading team’s graphql files. This way you can even create team-specific, platform-specific or global rules.
Rules are Importable!
Several Service Providers and Open Source libraries have already started shipping their own rules. The developer community also has fantastic rule examples you can use as a starting point to get your AI workflow set up. Here are some fantastic resources:
https://cursor.directory
https://github.com/PatrickJS/awesome-cursorrules
Best Practices for Writing AI Rules
Keeping the rules clean and organised is part of maintaining your codebase. The better the rules, the better results your junior engineers will get from prompting.
✅ Be Specific
Avoid vague guidance like “write clean code.” Instead, say exactly what you want, eg Use snake_case for all service names, or Prefer named exports for components
🎯 Keep Rules Focused, Concise and Composable
Each rule should cover a single topic or behavior
Stay under 500 lines per rule file.
(It was Cursor recommendation, but I found short files useful for human readability, too.)Split complex concepts into multiple, composable rules. Separation of concerns!
Name rule files clearly for easy discoverability
📁 Use File References
Use
@filename.extto reference real code or templatesThis gives the AI additional context and grounding it in actual project structure
♻️ Reuse Across Projects
If you find yourself repeating the same prompt or instruction, extract it into a reusable rule. Even better - ask AI to create the rule for you! 🔥
Ideally you will be using a monorepo - if not, Store reusable rules in a shared library for consistency across apps, teams, or services.
Cursor support is coming for this, soon!
🧪 Include Examples
Add concrete examples of what “good” looks like whenever possible
Point to real patterns from your codebase to clarify intent
📌 Default to Opt-in When Appropriate
For rules that might be too aggressive to apply everywhere, use
alwaysApply: falseand document how to trigger them manually. (in Cursor you can simply type @, followed by the name of the rule!)
🛠 Think in Roles and Contexts!
Write different rules for UI Dev, Server Devs, UX Designers, Product folks, …etc.
Scope rules to files, folders, or workflows to prevent overreach
🔍 Maintain and Review Regularly
Periodically audit your rules for relevance, duplication, and alignment with evolving tech stacks
Deprecate legacy rules that conflict with current patterns
LLM, MCP, A2A… and beyond
Rules are just tip of the iceberg.
They are the first step in shaping how AI behaves within your organisation’s engineering environment. A truly AI-first developer experience (DX) goes far beyond writing .mdc files. As teams adopt more sophisticated tooling, we're seeing the rise of integrated systems that blend custom LLM-s, MCP servers, and multi-agent interop to form the foundation of an AI-native engineering environment.
The aim of this article was to show how Rules cracked open the door.
It’s the first step that made it possible for AI coding assistants to safely participate in the corporate software lifecycle, even in conservative environments like FinTech.
That’s all, folks!
Thank you for reading this. If you are not using Rules yet, I recommend giving them a go. It’s trivial to set up and it’s really a game changer, even for your side projects.
I would love to hear your thoughts in the comments!
🩵