Seek to understand product requirements, code history, and the rationale behind decisions. Take ownership of the problems we solve. Be open to trying new tools and patterns that solve new problems, and take the time to understand the tools you adopt, including your agents.
Write tested code in small chunks to be confident it will work as designed. Reviewer attention is our scarcest resource: break large work into small, reviewable units (stacked changes) rather than putting up generated code wholesale. Understand the consequences of our code, short term and long term, including how it behaves when things fail. Vet external libraries and generated dependencies before adding them to our platform. Take responsibility for our code, its deployment, its reliability in production, and its impact on our customers.
Agents now write much of our code; accountability never transfers to the tool. Understand what you merge as if you typed it yourself, hold agent output to the same conventions and quality bar as your own, and be able to explain and defend every change you put up for review. If you can't explain it, you're not done. Our agentic coding code of conduct is the operating manual for this principle.
Customers trust Float with their funds, their data, and their controls. Customer-defined controls (card status, spend rules, approval policies) are inviolable: no feature, algorithmic model, or system change overrides them without explicit customer consent. We write code that expects to be attacked: practice secure coding habits and least privilege with systems and data. Protect data integrity and model reliability: financial and analytical records must be accurate, auditable, and consistent, and changes or migrations must be verifiable and reversible. Reliability is a feature. Businesses run on Float, so we build, test, and operate our systems to be there when customers need us.
Float Engineering is built on respect. Respect our customers' time and their problems. Our code isn't perfect, but we assume the engineers who came before us did their best at the time. Similarly, we assume other engineers are currently doing their best. Respect each other and ourselves. Feedback is given and taken based on this mutual trust.
Code that functions is the bare minimum. Good code is code that is written to be understood. We break down knowledge silos as we work, striving to communicate through our code and not just code comments. Our codebase is also the starting context for every future maintainer, so the clearer it reads, the better the next person, or the next agent, works within it. Our goal is code that others can safely and confidently maintain, even when we aren't around.
Review others' code frequently and diligently; review is where quality is decided. Engage in thoughtful design discussions around product changes. Provide good context in pull requests: when a diff was generated, the human-written why is the one thing reviewers and future readers cannot reconstruct. Write appropriate documentation. Work with our colleagues outside of Engineering, helping them understand product engineering so we can all work together to solve customer problems.
Strive to understand requirements as best we can, but stay flexible. We don't know when or how customer requirements will change, so advocate to release code quickly so we can learn from customers, and release safely with flags and incremental rollout so learning never comes at the cost of customer trust. Don't over-build, but don't under-build either.
Treat technical debt like actual debt: it can be useful, but it only serves us when used responsibly. Responsible technical debt is known, measured, and tracked. Make informed decisions on what to prioritize and when. Our goal is to leave code in a better state than we found it, and agents have lowered the cost of "make the change easy," so our bar for leaving things better should keep rising. Make the change easy, and then make the easy change.