My setup

The setup changes with the work, but the operating principle stays the same.

This page is a personal view of how I work with AI right now. I have GitHub SSH access, a web AI instance that is reachable from Discord, and I use whatever AI tools make sense in the moment. The process is not fixed. It evolves with the task. The constant is that the AI should have the permissions it needs to do real work, while I stay aware of the damage it could do and keep mitigation and recovery in place.

1core stance: give the AI enough access to be useful
2active access lanes: repo access and remote AI access
3control points: permissions, mitigation, recovery
Tooling is fluid

I use the AI tools that make sense for the current problem. The stack changes depending on whether the work is coding, deployment, design, research, or coordination.

Access is real

This is not a toy prompt loop. The setup includes GitHub access over SSH and a live web-based AI instance that can be reached from Discord, which means the agents can operate across real systems.

Risk is real too

The key is not pretending the AI is harmless. The key is deciding what permissions it needs, what it could damage, and what recovery path exists if something goes wrong.

01

What the setup includes

SSH

GitHub access

I can work directly against repositories with SSH access, which means the AI can participate in real code and version-control workflows instead of staying boxed into mock examples.

  • Real repo context.
  • Direct branch and code workflows.
  • Useful for actual implementation, not only planning.
WEB

Remote AI surface

I keep a live AI instance running on a webserver and can reach it from Discord, which gives me another active lane for coordination and execution outside the local editor.

  • Available beyond a single machine.
  • Useful for remote interaction and continuity.
  • Part of a broader multi-surface workflow.
MIX

Mixed toolchain

I use the AI tools that are strongest for the current job. The process changes depending on what I am tackling rather than forcing every task through one fixed pattern.

  • Different tools for different forms of work.
  • The method evolves with the task.
  • Flexibility matters more than brand loyalty.
02

The operating principle

1. Decide the task

Start from the real job in front of me: code, deploy, design, diagnose, research, or planning.

2. Grant enough access

Give the AI the permissions and tools it actually needs to do the work instead of forcing it to act blind.

3. Bound the risk

Be explicit about what the agent could change, what it could break, and where the safe operating boundary is.

4. Keep recovery ready

Make sure there is a clean way back through logs, version control, backups, or other recovery paths before letting the agent operate broadly.

Core idea: the AI should have enough permission to be effective, but never more trust than the recovery plan can support.
03

What has to be managed

DMG

Potential damage

If an agent has real permissions, it can do real damage. That includes bad edits, bad deploys, accidental deletions, or broad actions taken with incomplete context.

  • Access increases power and blast radius together.
  • Capability without boundaries becomes liability.
  • Convenience is not the same as safety.
MIT

Mitigation

The answer is not to remove all access. The answer is to shape the environment so useful work is possible while risky actions stay legible, reviewable, and constrained.

  • Give only the permissions the task calls for.
  • Prefer scoped actions over open-ended freedom.
  • Keep logs and decision trails visible.
RCV

Recovery

The real safeguard is having a way back. Recovery can come from version control, backups, environment snapshots, or a clear record of what changed and why.

  • Use reversible workflows where possible.
  • Keep stable checkpoints before risky changes.
  • Do not grant access you cannot recover from.
04

Why the process stays flexible

  • Different problems need different models, tools, and levels of autonomy.
  • The process evolves as the work changes rather than staying frozen as one perfect workflow.
  • The right setup for design work is not always the right setup for coding or deployment.
  • The goal is not ideological consistency. The goal is useful outcomes with acceptable risk.
  • The human still decides what matters, what is safe, and when to intervene.
Sample pages Remote agents Development method Applications What this process solves Problem statement Design generation AI iteration