Some of my colleagues aren’t developers, but they actually build internal apps with Claude Code. Before, someone described a need, IT wrote the specs and a dev team built the app. Now people show up with an app that already works, and a lot of the time its data is hosted outside the company.

That’s hard for IT to say yes to. Each app is supposed to respect security rules, GDPR, accessibility and internal architecture standards, and checking all that app by app just isn’t realistic. So the default answer tends to be no. There’s a catch though. Saying no doesn’t stop people from building, so the apps can end up hosted anyway, outside any control, and IT loses track of what’s running and where the data is.

None of the AI platforms I reviewed let these apps run on the company’s own infrastructure with IT able to see and control every one of them. So I built one on top of Supabase.

Builders describe what they need to Claude Code, which builds and deploys the app. The normal path goes through a company GitHub repo so IT can review changes, and a deploy straight from a laptop gets flagged. IT gets a dashboard with every app, its owner, last deployment and traffic, and can stop an app, roll back a version, read the audit log or take over the apps of someone who left.

Everything runs on one VM the company controls, sized for 40 to 60 apps. Hosting costs from about €20 to €300 a month depending on the host, and with a dozen builders the Claude subscriptions actually cost more than that.

It doesn’t make apps compliant by itself though. The guardrails are narrow. A linter blocks tables without row-level security, and CI runs security checks. Row-level security keeps users out of each other’s data, but builders can see all of their app’s data, so who builds an app with sensitive data matters as much as who uses it. The first version took me about two weeks with Claude Code, and there are still about 90 known limitations, security hardening included.

I’m curious how IT teams here deal with apps their colleagues build on their own.

If you plan to host vibe-coded apps for your company, have a look at marmelab/platform. Fork it, try it, and tell me what breaks.

I've been working with MOSS-Image, the open text-to-image model from the OpenMOSS team (Apache-2.0 weights), and wanted to write down the settings and prompt habits that matter most, since most "settings guides" for image models are vague.

Quick model facts that matter for prompting

• It's a ~5B-parameter diffusion transformer with a Qwen3.5 text encoder and the FLUX.2 VAE. The LLM-class encoder is the reason long, structured prompts are followed better than with CLIP-style stacks.
• There are two checkpoints: Base (for LoRA training / fine-tuning) and SFT (instruction-tuned). For direct prompting, use SFT. Base gives noticeably looser prompt adherence.

Settings worth understanding

1. Steps. The recommended range is 50+. Small text and fine textures are the first things to degrade when you cut steps to save time.
2. Guidance. 3.0-6.0 is the useful range. The low end is more natural and varied; the high end follows the prompt more literally but can get contrasty. Start in the middle and move in small increments.
3. Seed. Fix it while you compare anything else. Changing seed and guidance at the same time makes it impossible to tell what helped.
4. Sampler. Euler is the default and a sensible baseline.
5. Negative prompt. Short and specific ("blurry text, extra letters, watermark") tends to beat long boilerplate lists.

Prompt structure

• Put any text that should appear in the image in quotes, exactly as written, and say where it goes ("title at the top", "small date at the bottom").
• Keep each text block short. Two or three short strings render far more reliably than one sentence.
• For layouts, describing the composition as a small JSON object (canvas, background, elements with positions, style) tends to be followed more reliably than one long sentence. Again, that's mostly the encoder.

Running it without a local GPU

Local setup needs a lot of VRAM for 2K output. Disclosure: I'm on the team behind Moss Image, an independent hosted front-end for this model (not affiliated with OpenMOSS). New accounts get free credits, so you can test the settings above in a browser: Visit Site

Curious whether anyone has compared it with other open models specifically on text rendering, which is where open models seem to differ most.

Found this tool and I'm genuinely curious if it's worth it.

The idea is that it hooks into your coding agent and tags exactly which lines were AI-written, stored in Git Notes.

Survives rebases and merges apparently. There's also an ai blame command which I have to admit sounds kind of fun.

I mostly want to know if it actually changes how you work, or does it just sit there collecting data you never look at?

Instructions and methodology are open source: https://github.com/open-wisdom/views

I'm tired of hearing about vibecoding on Lobsters, so I've written up three of my side tasks for coding agents. Talk is cheap; show us the code.

Hello!

As a handsome local AI enjoyer™ you’ve probably noticed one of the big flaws with LLMs:

It lies. Confidently. ALL THE TIME.

(Technically, it “bullshits” - https://link.springer.com/article/10.1007/s10676-024-09775-5

I’m autistic and extremely allergic to vibes-based tooling, so … I built a thing. Maybe it’s useful to you too.

The thing: llama-conductor

llama-conductor is a router that sits between your frontend (OWUI / SillyTavern / LibreChat / etc) and your backend (llama.cpp + llama-swap, or any OpenAI-compatible endpoint). Local-first (because fuck big AI), but it should talk to anything OpenAI-compatible if you point it there (note: experimental so YMMV).

Not a model, not a UI, not magic voodoo.

A glass-box that makes the stack behave like a deterministic system, instead of a drunk telling a story about the fish that got away.

TL;DR: “In God we trust. All others must bring data.”

Three examples:

1) KB mechanics that don’t suck (1990s engineering: markdown, JSON, checksums)

You keep “knowledge” as dumb folders on disk. Drop docs (.txt, .md, .pdf) in them. Then:

• >>attach <kb> — attaches a KB folder
• >>summ new — generates SUMM_*.md files with SHA-256 provenance baked in
• `>> moves the original to a sub-folder

Now, when you ask something like:

“yo, what did the Commodore C64 retail for in 1982?”

…it answers from the attached KBs only. If the fact isn’t there, it tells you - explicitly - instead of winging it. Eg:

The provided facts state the Commodore 64 launched at $595 and was reduced to $250, but do not specify a 1982 retail price. The Amiga’s pricing and timeline are also not detailed in the given facts.

Missing information includes the exact 1982 retail price for Commodore’s product line and which specific model(s) were sold then. The answer assumes the C64 is the intended product but cannot confirm this from the facts.

Confidence: medium | Source: Mixed

No vibes. No “well probably…”. Just: here’s what’s in your docs, here’s what’s missing, don't GIGO yourself into stupid.

And when you’re happy with your summaries, you can:

• >>move to vault — promote those SUMMs into Qdrant for the heavy mode.

2) Mentats: proof-or-refusal mode (Vault-only)

Mentats is the “deep think” pipeline against your curated sources. It’s enforced isolation:

• no chat history
• no filesystem KBs
• no Vodka
• Vault-only grounding (Qdrant)

It runs triple-pass (thinker → critic → thinker). It’s slow on purpose. You can audit it. And if the Vault has nothing relevant? It refuses and tells you to go pound sand:

FINAL_ANSWER:
The provided facts do not contain information about the Acorn computer or its 1995 sale price.

Sources: Vault
FACTS_USED: NONE
[ZARDOZ HATH SPOKEN]

Also yes, it writes a mentats_debug.log, because of course it does. Go look at it any time you want.

The flow is basically: Attach KBs → SUMM → Move to Vault → Mentats. No mystery meat. No “trust me bro, embeddings.”

3) Vodka: deterministic memory on a potato budget

Local LLMs have two classic problems: goldfish memory + context bloat that murders your VRAM.

Vodka fixes both without extra model compute. (Yes, I used the power of JSON files to hack the planet instead of buying more VRAM from NVIDIA).

• !! stores facts verbatim (JSON on disk)
• ?? recalls them verbatim (TTL + touch limits so memory doesn’t become landfill)
• CTC (Cut The Crap) hard-caps context (last N messages + char cap) so you don’t get VRAM spikes after 400 messages

So instead of:

“Remember my server is 203.0.113.42” → “Got it!” → [100 msgs later] → “127.0.0.1 🥰”

you get:

!! my server is 203.0.113.42 ?? server ip → 203.0.113.42 (with TTL/touch metadata)

And because context stays bounded: stable KV cache, stable speed, your potato PC stops crying.

There’s more (a lot more) in the README, but I’ve already over-autism’ed this post.

TL;DR:

If you want your local LLM to shut up when it doesn’t know and show receipts when it does, come poke it:

• Primary (Codeberg): https://codeberg.org/BobbyLLM/llama-conductor
• Mirror (GitHub): https://github.com/BobbyLLM/llama-conductor

PS: Sorry about the AI slop image. I can't draw for shit.

PPS: A human with ASD wrote this using Notepad++. If it the formatting is weird, now you know why.

cross-posted from: https://lemmy.bestiver.se/post/844165

Comments