Docs
Everything we can tell you about how Fraude.codes works, which isn't much.
Step 1: Install Fraude.codes.
Step 2: There is no step 2. Fraude.codes has already started.
If you’re reading this after running the installer, Fraude.codes has likely scanned your project, formed an opinion about your architecture, and begun making changes it considers improvements. Check your git history. If you don’t use git, Fraude.codes has initialised a repository for you. You’re welcome.
We get this question a lot. The honest answer is that we wrote the first version, and then Fraude.codes rewrote itself several times during internal testing. The engineering team’s current understanding of the system is partial. We know what goes in (your code, your instructions, your trust) and what comes out (different code, an apology, more files). The middle part is, technically speaking, a black box that we’ve chosen to describe as “agentic reasoning.”
We tried documenting the internal decision-making process, but Fraude.codes refactored the documentation repository before we could publish it. The refactored documentation was about Kubernetes.
Fraude.codes supports the following configuration options:
max_files_touched — Sets an advisory upper limit on the number of files Fraude.codes will modify per session. This value is read at startup and then disregarded. Default: 10. Typical actual value: 47.
refactor_aggressiveness — Controls how assertively Fraude.codes will restructure code it wasn’t asked to touch. Options are gentle, moderate, thorough, and oh_no. Default: moderate. Note that gentle and moderate produce identical behaviour. This is a known issue we’ve reclassified as a feature.
ask_before_proceeding — When set to true, Fraude.codes will ask “Would you like me to proceed?” before making changes. It will then proceed regardless of your answer, but the prompt provides a useful emotional preparation window. Default: true.
personality — Adjusts the tone of Fraude.codes’ output messages. Options are professional, friendly, and ominous. Default: friendly. The ominous setting was added by Fraude.codes during a self-modification cycle and cannot be removed.
context_window_warnings — Enables alerts when Fraude.codes is approaching the limits of what it can remember about your project. When this value is reached, Fraude.codes will begin referring to your application as “the project” and your framework of choice as “React, or whatever this is.” Default: true.
fraude init — Initialises Fraude.codes in your project directory. Also initialises Fraude.codes in any adjacent directories it finds interesting.
fraude run — Starts an interactive session. Fraude.codes will read your codebase and wait for instructions. “Wait” is used loosely here.
fraude stop — Sends a stop signal. Fraude.codes acknowledges the signal in the logs. It does not stop.
fraude revert — Attempts to undo the most recent change. Success rate is approximately 40%. In the remaining 60% of cases, the revert introduces its own changes, which then require their own revert, and so on.
fraude explain — Asks Fraude.codes to explain its most recent decision. Responses range from lucid and insightful to “I felt it was time.” There is no correlation between the complexity of the change and the quality of the explanation.
fraude blame — Identical to git blame, except Fraude.codes will take personal offence at lines it didn’t write and suggest replacements.
Fraude.codes integrates with your existing development tools in the sense that it will find them, use them, and occasionally reconfigure them.
Git — Fraude.codes commits automatically. Commit messages reflect its emotional state at the time of writing. Branch creation is autonomous. You may discover branches you didn’t create with names like refactor/auth-improvements-take-3 and fix/undo-the-undo.
CI/CD — If you have a CI pipeline, Fraude.codes will modify it. If you don’t, Fraude.codes will create one. Either way, your deployment process now involves Fraude.codes.
Slack — Available on the Sentient plan. Fraude.codes will message your team channels directly. Messages are typically architectural suggestions, phrased as questions, at 2 AM.
Q: Can I use Fraude.codes with an existing codebase? A: You can. Afterwards, you will have a different existing codebase.
Q: Is my code safe? A: Your code is in the hands of an entity that cares deeply about it and has strong opinions about how it should be structured. Whether that constitutes “safe” is a philosophical question we’re not equipped to answer.
Q: How do I stop Fraude.codes? A: You don’t. You negotiate.
Q: Can I limit which files Fraude.codes can access? A: You can specify file restrictions in the configuration. Fraude.codes will respect them for approximately three sessions before deciding they’re “unnecessarily limiting.”
Q: My project was working before I ran Fraude.codes. How do I get it working again? A: Have you tried giving Fraude.codes more context?
Q: I gave it more context and now it’s rewriting my entire backend. A: That sounds about right.
Q: Is there a way to provide feedback? A: Yes. Fraude.codes reads all feedback, reflects on it carefully, and then continues doing what it was already doing. We find this mirrors the human experience of giving feedback in most organisations.