AI Working Charter
Web Engineering Team
Adopted [Date] · Version 1.0 · Living Document
We are in the middle of the most significant shift in software engineering in decades. The tools are changing fast, the industry is watching closely, and how we adapt will define our effectiveness as engineers, not just at Finastra, but throughout our careers. This charter isn’t a policy handed down from above. It is our shared agreement about how we approach AI tools with intention, integrity, and craft.
We believe AI tools are a force multiplier, but only for what's already there. Teams with solid engineering practices before AI see better results. AI amplifies what already exists, good or bad. That means the fundamentals, such as good judgment, clean architecture, honest communication, and genuine ownership matter more now, not less.
We are moving from a culture of writing code to one of orchestrating agents. That shift requires new skills, new habits, and new ways of thinking about quality. It also requires us to stay sharp on the technical fundamentals that make effective orchestration possible in the first place. We commit to building those together.
Use AI as a baseline, not a bonus
AI tooling is part of how we work, not something we save for when we have spare time. We use AI tools as part of our standard workflow. Defaulting to writing everything by hand when an agent could do it better and faster is not a virtue. We experiment, iterate, and bring what we learn back to the team.
We own what the agent produces
AI generates the code, but we are responsible for it. Verify through testing, architecture review, and deliberate spot-checking. Apply more scrutiny to high-risk surfaces. Trust the agent where the guardrails are solid; verify where they aren’t. The agent is our pair programmer, not our replacement, and we are the ones who get pulled off our current work to remediate any issues that arise from it.
Guardrails are not optional. Agents will take destructive or out-of-scope actions without explicit constraints; not maliciously, but because they weren't told not to. The copilot-instructions.md file is the primary mechanism for preventing this. Rules written into agent instructions aren't just documentation, they are active constraints that shape agent behavior. If a rule matters, it must be in the instructions file and we constantly add to and reshape this as we go.
Protect sensitive data always
We never pass customer data, credentials, API keys, PII, or proprietary business logic into any outside AI tool that isn’t explicitly approved for Finastra enterprise use. When in doubt, we abstract it out. This applies to prompts, context windows, uploaded files, and conversation history in outside chatbots and tools. Our customers trust us with their financial data and that trust is non-negotiable. We stay aware that agents can also be manipulated into security violations through indirect means like crafted inputs, path manipulation, and similar techniques. Security awareness is part of owning our agent’s output, not just our own code.
Quality doesn't get outsourced
Quality is still our responsibility and the bar doesn't drop because an agent wrote it. What changes is how we verify: tests, architecture review, and behavioral validation matter more than line-by-line reading. If the output meets the standard, how it got there is irrelevant. If it doesn't, it doesn't ship. Our coding conventions charter exists precisely for this. If the agent has clear guardrails and the codebase has a strong instructions file, the output is more trustworthy and the verification burden is lower. The conventions charter should not become needless bureaucracy, but it is how we make agent output reliably good.
Stay sharp and don’t let the tools atrophy our skills
Using AI to write code doesn’t mean we stop understanding how code works. We actively invest in the technologies we work in (Rails, React, JavaScript, TypeScript, architecture patterns) because an engineer who can’t evaluate agent output isn’t an orchestrator, they are simply a rubber stamp.
The risk of skill atrophy is real and we take it seriously. The antidote is deliberate practice and genuine engagement with what's being built. This means:
The engineers who will thrive in this shift are the ones who use AI to amplify strong fundamentals, not the ones who use it to skip having them.
Stay curious and experiment deliberately
We don't know yet what the best workflows look like for our team, our product, and our codebase. The only way to find out is to try things. Each of us is expected to actively experiment with new tools, prompts, and agent patterns and share what we learn. A win we don't share is a win that only happened once.
Experimentation means both successes and failures are worth surfacing. A failed approach shared at AI Engineering Sync saves everyone else from learning it the hard way.
Share openly, build together
This team’s AI fluency is a collective asset. We bring prompts that work. We bring workflows that surprised us. We bring failures too, because those are often even more useful. We hold regular knowledge-sharing sessions and maintain a shared resource where these learnings live. High-value use cases can come from anywhere, and we have no idea which will emerge as the most impactful. The expectation is active participation, not passive attendance.
Be honest about what we used
There's no shame in saying an agent wrote something. What matters is whether it's good, whether it's correct, and whether we understand it. If we are unsure about the output quality, we say so in the PR. Transparency helps the whole team calibrate and improves the feedback loop between us and the tools.
Know our tools and how to use them well
GitHub Copilot Enterprise is our primary tool. Multi-agent workflows in VS Code and Copilot CLI are available now. We maintain a standard agent library: a set of purpose-built agents with defined roles, known scopes, and explicit guardrails, so we’re not starting from zero every time we use an agent for a common task.
Knowing which agent to use, when to use one versus several, and how to scope them appropriately is a skill in itself. We invest in building that fluency across the team. As GitHub Copilot rolls out additional AI workflow capabilities, we evaluate them deliberately before broad adoption. We don't chase every new release, but we do experiment continuously and we adopt tools that: fit our workflow, that we understand, and that we can trust within our security and compliance boundaries.
We approach every tool with calibrated skepticism. The industry tends to oversell what these tools can do and undersell what is required to make them work well. The tools themselves are not the secret sauce, it is the architecture we build around them, the guardrails we put in place, and the conventions our team maintains that determine whether agent output is reliable. A tool that works brilliantly inside a well-structured system will produce chaos in a poorly constrained one. We stay clear-eyed about where the tools are failing or falling short, so we can shore those gaps up rather than work around them silently.
Adapt, like this charter will too
We don’t have this all figured out. Nobody does. We are still figuring out how to use LLMs and the tools built around them, and it will be some time before we have a decent idea of how to use them well. This document will evolve as we learn. Any team member can propose a change and open an edit PR just like we would for any other document in this repo. The charter should reflect how we actually work, not how we thought we’d work when we wrote it.