FeyNoBg Ships Background Removal Library

FeyNoBg is Feyn's automatic background removal model, released with NoBg, the Python library Feyn built to train and run it. It deals with a very practical image problem: separating the subject from the background without sending every job through a closed tool or a hand-tuned segmentation flow. The useful lesson for Codex users is simple: try the model like a dependency, not like a demo, and make generated integration code prove what it did. It is also a clean place to implement code review habits for ai-generated code because the boundary is visible: image in, mask or transparent output out.

FeyNoBg is a background removal model that creates a foreground cutout from an input image. NoBg is the open Python library around it, meant for training and running that kind of model. Feyn also published a hosted Hugging Face demo, which made the release easy to poke at before reading code.

That is why developers cared on Hacker News. Background removal is boring in the best way: ecommerce catalogs, profile photos, thumbnails, design tools, creator apps, internal CMS pipelines, and dataset cleanup all need it. A model that is easy to test, and a library that can be inspected, is more useful than a beautiful screenshot you cannot reproduce.

Start with the release, not the wrapper

The interesting part of FeyNoBg is not only that it removes backgrounds. It is that Feyn shipped the model and the training/running library together.

That gives engineers two paths. You can try the public demo to see whether the output is close enough for your images. Then you can inspect NoBg before deciding whether to depend on it, fork it, or train against your own data.

The trap is to ask a coding agent to “add background removal” and accept the first wrapper it writes. In a Codex repo, start by asking it to create a tiny experiment folder, not production code.

A good first prompt is narrow:

Create experiments/feynobg-smoke-test/ with a script that runs three local images through the NoBg library or hosted demo path we choose. Save the input, output, runtime notes, and any errors. Do not modify the app code yet.

That keeps the release in view. You are testing FeyNoBg as a model and NoBg as a library, before you turn either into architecture.

Check the image boundary before the code boundary

One Hacker News objection was exactly the kind engineers should ask: what are the resolution limits? The GitHub readme reportedly mentioned 1024×1024, while a commenter said a 1920×2880 image processed without obvious scaling artifacts.

That does not mean the model has unlimited native resolution. It means the practical behavior needs a receipt. There may be resizing, tiling, padding, or post-processing behind the scenes; the public signal alone is not enough to claim which one.

For a real repo, test the boundary with the images that matter to you. Do not use one clean studio product photo and declare victory.

Use a small fixture set:

• hair-wind.jpg for fine edges
• soccer-motion.jpg for limbs and blur
• white-shirt-white-wall.jpg for low contrast
• phone-screenshot.png for hard rectangles and text
• large-portrait-1920x2880.jpg for size behavior

Then make Codex produce an output receipt instead of a prose summary. A useful receipt names the command, inputs, outputs, library version or commit, runtime, and known failures.

python experiments/feynobg-smoke-test/run.py \
  --input fixtures/background-removal \
  --output artifacts/feynobg-smoke-test

python experiments/feynobg-smoke-test/check_outputs.py \
  --output artifacts/feynobg-smoke-test

The second command can be simple. It can verify that output files exist, dimensions are recorded, alpha channels are present when expected, and no file is silently empty.

Compare the three ways to try it

FeyNoBg is easiest to understand when you separate the model, the library, and the integration work. Each option answers a different question.

Criteria	Hugging Face FeyNoBg demo	NoBg Python library	App integration written with Codex
Best question to answer	“Does this model work on our images?”	“Can we run or adapt this ourselves?”	“Can this fit our product safely?”
What you can inspect	Output behavior from uploaded examples	Library code, training/running surface, local scripts	Diff, tests, data flow, error handling, permissions
What the HN release made visible	Feyn published a public demo for quick trials	Feyn open-sourced the library behind the model	Developers can build a small pipeline around the release
Main limitation	Demo behavior may not match production constraints	You still need dependency, GPU, and model-operation checks	Agent-written glue can hide weak assumptions unless reviewed
Best first artifact	Before/after sample folder	Reproducible smoke test	Pull request with fixtures and review checklist

Verdict: the hosted demo wins when you are still judging visual quality, NoBg wins when you need inspectable training or runtime code, and Codex-written integration wins only after you have fixtures, commands, and a reviewer who can reject vague “looks good” output.

This is also where the related training topic becomes practical rather than abstract. Code review guardrails are not a meeting. They are small checks that stop a model demo from becoming an untested production dependency.

For a companion note on this release, see FeyNoBg Opens a Background Removal Library.

Use Codex to make the experiment reviewable

The best Codex workflow here is boring: isolate the experiment, record assumptions, and make the final diff small.

Add a local repo rule before asking for code. In an AGENTS.md file near the experiment or image pipeline, write the boundary down.

# AGENTS.md

When editing background-removal code:
- Keep experiments under experiments/feynobg-smoke-test until reviewed.
- Do not send private customer images to hosted services.
- Use fixture images from fixtures/background-removal only.
- Record input size, output size, runtime, and failure notes for each run.
- Do not change production image upload paths without tests and reviewer approval.

That one file saves a lot of back-and-forth. It tells the coding agent what not to touch, and it gives the reviewer a checklist to enforce.

If your repo uses external systems through Model Context Protocol, keep that boundary just as explicit. An MCP server is an integration layer that lets an agent access tools such as GitHub, Slack, databases, or document stores through a standard protocol. For this experiment, read-only access is usually enough.

A good MCP boundary note is short:

MCP boundary for this task:
- GitHub: read issues and create a draft PR only.
- File system: write only under experiments/ and artifacts/.
- Secrets: no access required.
- Image stores: no customer buckets; fixtures only.

This is a small example of ai coding training for teams that does not feel like training. The repo teaches the agent by narrowing the job.

Try it safely with this review checklist

Use this checklist when you ask Codex or another coding agent to wire FeyNoBg or NoBg into a repo. It is intentionally small enough to paste into a pull request.

## FeyNoBg / NoBg review checklist

## Fit check
- [ ] The PR says whether it uses the hosted demo, NoBg locally, or a fork.
- [ ] The PR includes at least 5 fixture images with edge cases.
- [ ] The PR records expected output format: mask, alpha PNG, or composited image.

## Image behavior
- [ ] Output dimensions are recorded for each fixture.
- [ ] Large-image behavior is tested, including one image above 1024×1024.
- [ ] Hair, motion blur, low contrast, and hard rectangular edges are included.
- [ ] Failures are saved as artifacts, not described only in chat.

## Code behavior
- [ ] The integration is behind a feature flag or experiment path.
- [ ] No customer images are sent to hosted services without approval.
- [ ] Dependency versions, model commit, or library commit are pinned where possible.
- [ ] Tests cover missing files, unsupported formats, and empty outputs.

## Agent review
- [ ] The Codex transcript or handoff names every file changed.
- [ ] The reviewer can rerun the smoke test with one command.
- [ ] The reviewer checked assumptions rather than only visual output.

This is the practical answer to “what are the best ways to implement code review habits for ai-generated code?” Start with a reviewable artifact, not a policy paragraph. The habit is to make every agent-written integration bring its own fixture set, command, and failure notes.

For engineering team ai adoption, this matters because image tools are seductive. A background disappears, the demo looks crisp, and everyone wants to ship it. The review job is to slow down just enough to catch data leakage, size assumptions, brittle dependencies, and quiet output failures.

Common questions

• What is FeyNoBg?

  FeyNoBg is Feyn's automatic background removal model, released alongside NoBg, a Python library for training and running it. As of the July 2026 Hacker News release signal, Feyn also provided a Hugging Face demo so developers could test sample images before deciding whether to inspect or run the library.

• What are the best ways to implement code review habits for ai-generated code?

  The best way is to require a small, repeatable proof with every agent-written change. For a FeyNoBg integration, that means fixture images, one rerunnable command, output artifacts, pinned dependency notes where possible, and a reviewer checklist that covers privacy, resolution behavior, failure cases, and production boundaries.

• Can FeyNoBg handle images larger than 1024×1024?

  It may process larger images, but you should not assume native large-resolution behavior from one successful run. A Hacker News commenter reported processing a 1920×2880 image without obvious artifacts, while also noting a 1024×1024 mention in the readme; that is a cue to test dimensions and output quality in your own fixture set.

• When is NoBg overkill?

  NoBg is overkill when you only need a few one-off cutouts or a design teammate can handle the asset manually. It becomes interesting when background removal is part of a repeatable product or data pipeline, especially if you need inspectable code, custom training, local execution, or a clear dependency review trail.

• Should a coding agent connect this directly to production uploads?

  No, not on the first pass. Ask the agent to build an experiment path with fixtures and artifacts before touching production upload code. The safe sequence is demo, local smoke test, reviewed PR, then a guarded integration with clear privacy rules and failure behavior.

Best ways to use this research

• Best for: Engineers evaluating FeyNoBg or NoBg as a real dependency, not just a neat Show HN demo.
• Best first artifact: A smoke-test folder with five fixture images, generated outputs, and a one-command rerun script.
• Best comparison angle: Compare hosted demo quality, local NoBg reproducibility, and agent-written integration risk separately.
• Best review habit: Require Codex to leave a handoff receipt: changed files, commands run, artifacts created, and assumptions that still need a human call.

Further reading

• FeyNoBg — source
• NoBg on GitHub
• FeyNoBg Hugging Face demo
• OpenAI Codex
• Model Context Protocol — specification
• OWASP — Top 10 for Large Language Model Applications

Next step

Try FeyNoBg on five ugly images before you ask Codex to integrate it. If the outputs and failure notes are reviewable, the code review will be too.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.