Skip to main content

From Scripter to Architect in the Age of AI

· 4 min read
Pedro Arantes
Pedro Arantes
CTO | Product Developer

For decades, the job of a software engineer was to write the "happy path." We spent our days scripting the exact sequence of events: fetch data, transform it, display it. We were the authors of the flow.

With the rise of Applied AI, that role is fundamentally changing. When an LLM generates the logic, we are no longer the scripters. We are the architects of the boundaries.

The Principle of Constraint-Driven Architecture​

This shift is captured in The Principle of Constraint-Driven Architecture.

Because AI models are probabilistic (see The Principle of Probabilistic AI Output), they don't follow instructions with 100% reliability. They follow probability distributions. If you rely on them to "just do the right thing," you are gambling with your system's stability.

Your new job is to construct the guardrails that keep that probabilistic engine on the tracks.

The Failure Scenario: The Trusting Developer​

The "Trusting Developer" writes a prompt and assumes the AI understands the intent.

// ❌ The Trusting Developer Approach
const prompt = `
    Extract the address from this email: "${emailBody}".
    Please be careful not to include the signature.
    Also, ensure the zip code is valid.
`;

const result = await llm.generate(prompt);
// Result: "123 Main St, Springfield, IL 62704\nSent from my iPhone"

The developer then spends hours tweaking the prompt to "exclude signatures," playing a game of whack-a-mole with edge cases. This is a failure of architecture, not prompting.

Corollary 1: Schema Supremacy​

To succeed, you must embrace The Corollary of Schema Supremacy.

This corollary states a simple rule: If it can be code, it shouldn't be English.

Instead of asking the model to "be careful," you define a rigid schema using tools like Zod:

// ✅ The Architect Approach
import { z } from 'zod';

const AddressSchema = z.object({
  street: z.string(),
  city: z.string(),
  zipCode: z.string().regex(/^\d{5}(-\d{4})?$/), // Enforced in code, not prompt
  deliveryDate: z.date().min(new Date()), // Enforced in code, not prompt
});

// The LLM is forced to generate JSON that matches this shape
const result = await llm.generateStructured({
  schema: AddressSchema,
  prompt: `Extract the address from: "${emailBody}"`,
});

You don't ask the model to respect the rules; you build a system where breaking the rules is impossible. The model's output is treated as "untrusted user input" that must be sanitized and validated before it ever touches your business logic.

Corollary 2: The Probabilistic Funnel​

Visualizing this new architecture leads us to The Corollary of The Probabilistic Funnel.

Your system design is a funnel that progressively removes randomness.

Stage 1: The Wide Mouth (Prompting)​

At the top, we allow high entropy. We want the model to be creative and understand vague user intent.

// 1. User Intent (High Entropy)
const userRequest =
  'I want to book a flight to Paris next week, maybe Tuesday?';

Stage 2: The Neck (Structured Generation)​

We force that vague intent into a rigid structure using schemas. This reduces entropy but doesn't eliminate it (the model could still hallucinate a date).

// 2. Structure (Medium Entropy)
const BookingSchema = z.object({
  destination: z.string(),
  date: z.string().date(), // YYYY-MM-DD
});

const structuredData = await llm.generateStructured({
  schema: BookingSchema,
  prompt: userRequest,
});
// Result: { destination: "Paris", date: "2023-12-25" }

Stage 3: The Filter (Deterministic Validation)​

Finally, we apply deterministic business logic. This is the "zero entropy" zone. If the data doesn't pass, it never touches the database.

// 3. Validation (Zero Entropy)
function validateBooking(booking: z.infer<typeof BookingSchema>) {
  const date = new Date(booking.date);
  const today = new Date();

  if (date < today) {
    throw new Error('Cannot book flights in the past.');
  }
  if (date.getDay() !== 2) {
    // Tuesday check
    // Handle logic...
  }
  return true;
}

As an architect, your job is to design these filters. You decide where the creativity stops and the reliability begins. You are no longer writing the story; you are building the walls that ensure the story doesn't spill over into chaos.