So this is the latest update I got from the developers forum for how to use the replit agent and assistant to develop your MVPS and avoid those pesky AI bugs that tend to break your software.
I’ll keep it brief use the agent only when you want to build functionality and use the assistant whenever you want to fix functionality that already exists which includes bugs, customizations, slight changes in the way something that already exists works, basically if you’ve already created the function you use the assistant from that point on.
Always provide context to the assistant before you start working, Before you talk about a feature you want to implement or change or a bug or problem first ask the Assistant to tell you everything it knows about that function, Then ask it not to do anything but walk you through how it would address what it is you want to change, Then ask it to make that change only after it has all of this context.
If you fork your project or you start a new agent chat ask the agent to read the code and familiarize itself with the application and to describe what it thinks the application does fully without making any changes. Then you can ask it to create a plan to implement the new feature you want to build, then approve that plan.
TL:DR - Use the agent to create, use the assistant to modify, always load up context of the existing code into the ai’s memory whenever starting a new chat. Doing this will prevent the AI from overwriting existing structures and creating problems in previously fixed.
This is generally my preferred workflow too for more complex projects. For simple projects that I think Agent can handle in 2-5 prompts, I just use agent. For example, I recently had Agent make me my own version of all the different sites like “download audio from YouTube” or “convert webp to PNG” because I don’t trust them, Agent was able to do each of them in 5 prompts max.
Would be nice in the future to just have one prompt field and replit determines whether its for the replit Agent or Replit Assistant. But what we have now is already extraordinary. Hats of to the Replit team.
I do prompt optimisasions for leaving less space to do interpretations. So your prompt excemple would look like this
Context
You are building a self-hosted, privacy-focused web application — a personal utility toolkit that replicates common online converter/downloader sites. The user’s motivation is distrust of third-party utility websites (possible concerns include data harvesting, tracking, file retention, ads, or opaque server-side behavior — the exact threat model is unconfirmed).
Legal Notice: YouTube downloading violates YouTube’s Terms of Service (Section 5.B) and may violate copyright law (e.g., DMCA) in some jurisdictions. This tool is for personal use with content you have rights to. The developer assumes all legal responsibility. This disclaimer must be included in the application’s README and UI.
Technology Stack (Confirmed)
Language: Python 3.11+
Framework: FastAPI with uvicorn ASGI server
Frontend: Vanilla HTML/CSS/JavaScript (single-page app, no build step required) OR optionally Vue 3 with Vite if the user prefers a component framework
Key dependencies:
Media downloads: yt-dlp (subprocess, not a Python import — called via subprocess.run with parameterized args)
Audio/Video conversion: ffmpeg (subprocess)
Image processing: Pillow (Python-native)
PDF tools: pypdf (maintained successor to the deprecated PyPDF2) or pikepdf
Background removal (Tier 3 only): rembg (Python, runs locally but requires a one-time ~150-400MB model download on first use — this is an exception to the no-external-requests rule that must be documented)
Containerization:Dockerfile and docker-compose.yml provided
Why Python over Node.js: The critical dependencies (yt-dlp, Pillow, rembg, pypdf) are all Python-native. A Node.js backend would require Python sidecar processes for most features, adding unnecessary complexity.
PDF Merger/Splitter — Merge PDFs, split by page range. Uses pypdf.
PDF ↔ Image Converter — PDF pages to images, images to PDF.
Video to GIF — Extract clip, convert to GIF with frame rate/size controls. Uses ffmpeg.
Background Remover — Local ML-based background removal. Uses rembg. Note: Adds ~400MB+ to Docker image size.
QR Code Generator — Generate QR codes from text/URLs. Uses qrcode library.
Hash Generator — MD5, SHA-1, SHA-256, SHA-512 for text and files. Uses Python hashlib.
JSON/YAML/CSV Converter — Convert between data formats with pretty-printing.
Base64 Encoder/Decoder — Encode/decode text and files.
Markdown → PDF — Render Markdown to styled PDF.
General Video/Audio Downloader — Additional platforms via yt-dlp.
Existing alternatives worth knowing about:MeTube (YouTube downloader), Stirling-PDF (PDF tools), File Converter (format conversion). The user may prefer integrating these existing open-source tools behind a unified dashboard rather than reimplementing everything.
Security & Privacy Requirements
Authentication (Confirmed: Security-Critical)
Implement basic authentication using a single configurable API key/password stored in the .env file
All API endpoints and the web UI must require this credential
CORS is not a security boundary — it is only enforced by browsers, not by curl/scripts
Default bind address: 127.0.0.1 (NOT 0.0.0.0). If the user explicitly wants LAN access, they must opt in and the auth becomes mandatory
SSRF Protection (Confirmed: Security-Critical)
The download endpoint accepts arbitrary URLs via yt-dlp. This creates Server-Side Request Forgery risk
Required mitigations:
Validate URLs against a deny-list of private/internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16, ::1, fd00::/8)
Resolve DNS before passing to yt-dlp and validate the resolved IP is not in denied ranges (prevents DNS rebinding)
Optionally: allowlist of permitted domains (youtube.com, youtu.be, soundcloud.com, vimeo.com)
Uploaded files and generated outputs stored in a configurable temp directory (default: ./tmp/)
Cleanup strategy: Delete files that have not been accessed (read/downloaded) within the TTL window (default: 30 minutes). Use last-access-time, not creation-time, to prevent deleting files during active downloads.
Active download detection: Do not delete files that are currently being streamed to a client. Implement reference counting or file locking.
Error Handling
Startup Health Checks (Required)
On application start, verify the following binaries are available and log their versions:
ffmpeg -version
yt-dlp --version
If any required binary is missing: refuse to start and print clear error message with installation instructions for the user’s platform
Runtime Error Handling
Unsupported format: Return HTTP 400 with supported format list
File too large: Return HTTP 413 with configured limit
yt-dlp failure: Return HTTP 502 with sanitized error message (strip file paths from yt-dlp stderr). Common failure: “yt-dlp may need updating — run yt-dlp -U”
ffmpeg failure: Return HTTP 500 with sanitized error. Log full stderr server-side at DEBUG level.
URL invalid/unreachable: Return HTTP 400 with user-friendly message
Disk full: Return HTTP 507 with message
Timeout exceeded: Return HTTP 504 with timeout value
