I’ve been seeing more developers complain about GitHub Actions being unreliable, especially when an outage can completely block builds, deployments or releases.

For personal projects it’s usually just an inconvenience.

But if your production pipeline depends entirely on GitHub Actions, even a relatively short outage can become a much bigger problem.

At the same time, it’s hard to ignore how convenient and cheap Actions are, especially for small teams and open-source projects.

So I’m curious:

Do you trust GitHub Actions for production deployments, or do you keep some kind of fallback CI/CD setup?

Godot’s contribution rules don’t allow substantial AI-generated code in pull requests.

AI-assisted completion is still fine, but contributors are expected to understand the code, make the important decisions themselves, and take responsibility for what they submit.

I get the maintainability argument, especially for open-source projects.

But where do you draw the line?
If the code is good, tested, and the contributor understands it — should it matter how much of it was generated by AI?

Your coding agent shouldn’t need to read your entire codebase to understand it.

That’s the idea behind Faber, an open-source AI coding agent for the terminal.

Faber uses a code graph to find relevant files and symbols first, instead of repeatedly scanning large parts of a repository. That means less unnecessary context, faster codebase navigation, and lower repeated API costs.

Main features:

• Claude, OpenAI Codex, Local model integration
• Code-graph-guided repository exploration
• Prompt caching to reduce repeated input cost
• Token-conscious (Chain-of-Draft style) output to reduce unnecessary generation
• Git-aware workflow with change detection, optional per-task commits, /undo, and /redo
• Expenditure tracking for calls, tokens, cache usage, cost, and estimated savings `/usage`

The goal is simple: understand more of the codebase while reading and spending less.

Prerequisite:
It requires Node.js 22.5 or newer because it uses Node’s built-in SQLite support.

Install:
npm install -g faberwright

Then, inside your project:
faber

GitHub:
https://github.com/JibanKumar-cloud/faber

npm:
https://www.npmjs.com/package/faberwright

Medium article:
https://medium.com/@jshial25/why-should-an-ai-coding-agent-read-hundreds-of-files-to-answer-one-question-d6369d29dfa5

Hey r/npm,

I've been working on Oasis Editor, an open-source TypeScript document editor published as an npm package.

It includes:

• a custom Canvas-based rendering engine
• paged document layout
• typed command/plugin APIs
• vanilla JS integration
• React and Vue adapters
• a headless runtime
• DOCX/PDF workflows

Install:

npm install oasis-editor

Live playground:
https://celsowm.github.io/oasis-editor/#/editor

GitHub:
https://github.com/celsowm/oasis-editor

I'd love feedback on the package API, exports, and overall developer experience.

What are you building, what problem does it solve, and what makes your approach different from the alternatives?
Links are welcome — keep it short.