DEV Community: zendev2112

Prompts Aren't Enough: Enforcing Hard Constraints on LLM Output

zendev2112 — Thu, 18 Jun 2026 04:03:59 +0000

Every LLM demo looks impressive until it encounters a requirement that cannot be left to probability. Models are remarkably good at producing convincing text, but production systems often need guarantees rather than likelihoods. I ran into that distinction while building an AI-powered publishing pipeline for Radio del Volga, a regional news outlet in Coronel Suárez, Argentina. The system automatically ingests articles from RSS feeds, rewrites them, generates headlines, image prompts, and social media copy, then sends everything to an editor for review before publication. Most of the pipeline worked exactly as expected. One requirement, however, refused to stay solved: Gemini kept writing in the wrong Spanish.

For readers outside Argentina, the distinction might seem insignificant. In neutral Spanish, a sentence might read "Puedes encontrar más información...". In Argentina, the same sentence would naturally be "Podés encontrar más información...". Likewise, tienes becomes tenés, eres becomes sos, and contigo becomes con vos. None of these changes affect meaning, but they immediately signal whether a text feels local or imported.

What made the problem frustrating was that Gemini clearly knew the dialect. Most of the time, a straightforward instruction to write in Rioplatense Spanish produced excellent results. The failures only appeared under specific conditions. Government press releases, institutional announcements, and legal communications consistently nudged the model back toward neutral Spanish. The stronger the source's formal register, the more likely Gemini was to revert to expressions like puedes or tienes, despite explicit instructions not to do so. Because the pipeline processes articles continuously throughout the day, "almost always correct" was not a meaningful success criterion. Even a small failure rate guaranteed that incorrect articles would eventually reach the editorial queue.

The overall architecture of the system is simple. A Node.js API running on Vercel handles the ingestion of RSS feeds and orchestrates the generation pipeline. Gemini 2.5 Flash performs the content generation, Airtable serves as the editorial interface, and approved articles are published through a Next.js application backed by Supabase, while images are stored and delivered through Cloudinary. Editors never interact directly with the codebase; they simply review drafts, make any necessary edits, and click Publish. Keeping a human approval step turned out to be the right architectural decision, but I still wanted every draft to arrive as close to publication-ready as possible.

My first attempt was the obvious one: improve the prompt. Rather than giving Gemini a generic instruction to "write in Argentine Spanish," I made the requirements deliberately repetitive. The prompt explicitly prohibited neutral Spanish, listed the most common forbidden forms, provided their Rioplatense equivalents, and instructed the model to reread its own output before returning it.

Write in formal Rioplatense Spanish.

Never use neutral Spanish.

Use voseo throughout.

Forbidden forms:
- puedes
- tienes
- quieres
- haces
- eres

Before returning your response, read it again and replace any remaining neutral forms.

That extra self-review step noticeably improved consistency. Asking the model to inspect its own output before responding eliminated many of the mistakes that slipped through in earlier versions. Nevertheless, the improvement plateaued. The remaining failures were not random outliers; they were systematic. Formal source material continued to bias the model toward neutral Spanish, and no amount of additional emphasis or increasingly elaborate prompt engineering completely eliminated the problem.

At that point, I stopped treating the issue as a prompting problem and started treating it as a validation problem. Some constraints are inherently probabilistic: tone, style, or structure benefit from an LLM's flexibility. Others are entirely deterministic. If the generated text contains the word puedes, the output is incorrect. There is no ambiguity to resolve, no interpretation required, and no reason to ask the model to fix a mistake that ordinary code can identify with certainty.

The second layer of the solution is therefore a lightweight post-processing step that runs after every generation. Instead of attempting to rewrite arbitrary grammar, it focuses exclusively on a carefully curated set of expressions whose replacements are unambiguous.

const replacements = [
  ["puedes", "podés"],
  ["tienes", "tenés"],
  ["quieres", "querés"],
  ["haces", "hacés"],
  ["eres", "sos"],
  ["contigo", "con vos"],
];

export function enforceRioplatense(text: string) {
  let output = text;

  for (const [neutral, rioplatense] of replacements) {
    output = output.replace(...);
  }

  return output;
}

The replacement list is intentionally conservative. I do not attempt to transform every grammatical construction in Spanish because rule-based systems quickly become fragile when they expand beyond clearly defined cases. For example, puedes should always become podés, but puede is already perfectly valid in Rioplatense Spanish and should remain untouched. Restricting the post-processor to a small set of deterministic transformations makes it reliable, easy to maintain, and unlikely to introduce unintended side effects.

Looking back, the interesting lesson had very little to do with Spanish. It was about recognizing the limits of prompt engineering. Like many developers working with LLMs, my initial instinct was to assume that incorrect outputs meant the prompt needed further refinement. That assumption held true until it reached its limit. Prompting dramatically improved the model's performance, but it could never provide the guarantee that the production system required. Once I accepted that reality, the architecture became much simpler: let the model generate, then let deterministic code enforce the rules that are objectively verifiable.

That pattern extends well beyond language localization. Brand terminology, regulatory wording, formatting conventions, structured outputs, naming rules, and countless other production requirements share the same characteristic: they are finite, stable, and testable. Those constraints are often better enforced after generation than delegated entirely to the model. LLMs excel at producing fluent, context-aware text, but they should not be responsible for guaranteeing rules that conventional software can verify with absolute certainty.

The most valuable insight from this project was not learning how to write a better prompt. It was learning where prompting should end. Production systems become more reliable when responsibilities are clearly divided: the model generates possibilities, deterministic code validates the parts that must never be wrong, and humans remain responsible for the final editorial judgment. In my experience, that combination produces far more dependable systems than expecting the model alone to satisfy every requirement.

Listen First, Code Later: Case Study of a Dental App

zendev2112 — Sat, 11 Oct 2025 14:15:14 +0000

Recently, a dentist reached out to us with the need to modernize his digital workflow for recording odontograms. His previous software was rigid, unintuitive, and didn’t integrate with his patient management system built on Airtable. The challenge was clear: to create a robust, user-friendly, and extensible solution that respected his existing habits and integrated seamlessly with his current tools, including Softr.io.

Understanding the challenge

Our client, an active dentist, relied on digital odontograms for his daily practice but was frustrated by the limitations of his old software. His main requirements were:

A familiar and intuitive interface
Precise dental surface-level recording (based on FDI)
Per-tooth notes and a dual-layer annotation system (existing and required)
Simple export and direct integration with Airtable and Softr.io

We held several meetings to observe his workflow, identify pain points, and ensure the new app fit naturally into his daily routine without a learning curve.

Scope and integration context

It’s worth noting that the integration with Softr.io (a no-code platform for building frontends on top of Airtable) was already planned and managed by the client.
Our responsibility was solely to design and implement the odontogram web application, ensuring it could export and upload both images and structured data to Airtable, where Softr.io would handle visualization and record management.

What is FDI and why does it matter?

FDI stands for Fédération Dentaire Internationale (World Dental Federation). It’s a universal two-digit dental numbering system that identifies each tooth and its quadrant. This standard allows dental findings to be recorded and communicated accurately and internationally, improving interoperability among professionals and systems.

Technologies used

This project combined a complete and modern web stack:

JavaScript (ES6+) – Core application logic, event handling, and data processing.
jQuery – DOM manipulation, event delegation, and odontogram plugin integration.
HTML5 Canvas – Odontogram rendering and generation of high-resolution PNG reports.
CSS3 – Responsive styles and professional clinical design.
jQuery Odontogram Plugin – Interactive odontogram engine (Adhiana46/jquery-odontogram), extended for our needs.
JSON – Data structure for export and backend integration.
Node.js & Express – Backend API to receive and store PNG/JSON files.
Cloudinary API – Secure, scalable image upload and storage.
Airtable API – Attaching images and structured data to patient records.
Softr.io – No-code platform used by the client to build the frontend on Airtable and manage patient data.
Browser APIs – File handling, image generation, and client-side processing.

FDI anatomical mapping: clinical precision

One of the main technical challenges was implementing FDI-based anatomical mapping. In dentistry, the same position on the canvas (e.g., “left”) can represent “mesial” or “distal” depending on the tooth quadrant.
We developed a system that translates canvas positions (top, bottom, left, right, center) into actual anatomical surfaces (buccal, palatal/lingual, mesial, distal, occlusal/incisal) according to the FDI quadrant—ensuring clinical accuracy and clear communication.

Dual-layer annotation: mirroring real clinical practice

The app supports two annotation layers:

Pre-existing (red): Conditions or treatments already present
Required (blue): Treatments to be performed

The dentist can switch between layers with a single click, and all annotations are color-coded for instant recognition—replicating real-world clinical workflows.

Per-tooth notes: simple clinical documentation

Each tooth allows adding specific notes, with auto-save and manual save/delete options. These notes are included in both the JSON export and the PNG report, ensuring complete clinical documentation.

Data export: structured JSON and professional PNG reports

JSON Export: The app exports all odontogram data in a structured format, including date, patient name, annotated teeth, conditions, treatments, and notes.
PNG Export: Generates a professional A4 report containing the odontogram, treatments, notes, patient name, and timestamp. The layout is optimized for clarity and clinical use.

Integration with Cloudinary and Airtable: frictionless workflow

A key aspect was integrating with Cloudinary and Airtable:

When a PNG report is generated, the image is uploaded to Cloudinary via its API, ensuring secure and scalable storage.
The backend (Node.js/Express) attaches the Cloudinary image URL and the structured JSON data to the corresponding patient record in Airtable using the Airtable API.
As a result, all odontogram images and notes become instantly available within the patient’s record.

Softr.io: no-code frontend for the professional

The client already used Softr.io to build a no-code frontend on top of Airtable. This allows him to manage patient data, visualize odontogram images and notes, and interact with the system without technical barriers. Our app integrates seamlessly into this workflow, ensuring everything appears automatically in his Softr.io dashboard.

Maintaining familiarity: respecting user habits

Throughout development, we regularly shared progress with the dentist to ensure the app remained familiar and easy to use. We preserved his existing flow for selecting and annotating treatments while adding modern enhancements like auto-saving notes, color-coded layers, and professional document generation.

Lessons learned

User-centered design is essential: Frequent feedback from the dentist kept the project aligned and ensured adoption.
Innovate without losing familiarity: New features are valuable only if they remain usable for non-technical users.
Integration is key: Adapting to the client’s existing tools (Airtable + Softr.io) made the app truly enhance productivity.
Open source accelerates development: Building on a solid open-source foundation let us focus on real client needs.

Conclusion

The result is a modern, lightweight odontogram web application—powerful yet accessible. By listening to the client and leveraging a complete tech stack (JavaScript, jQuery, HTML5 Canvas, CSS3, Node.js, Express, Cloudinary API, Airtable API, Softr.io), we delivered a tool that integrates seamlessly into the dentist’s daily workflow, making clinical documentation faster, more accurate, and easier to manage.

Source code

Project repository:
https://github.com/zendev2112/odontograma

Open-source base:
https://github.com/Adhiana46/jquery-odontogram

Technologies used:
JavaScript (ES6+), jQuery, HTML5 Canvas, CSS3, jQuery Odontogram Plugin, JSON, Node.js, Express, Cloudinary API, Airtable API, Softr.io, Browser APIs.

If you’re building for real users, remember: listen first, then code!