DEV Community: Mike Clarke

The table looked general-purpose. The schema disagreed.

Mike Clarke — Tue, 21 Jul 2026 14:00:09 +0000

A CHECK constraint is documentation with teeth.

That's the whole lesson. But here's what it looks like when you learn it at runtime instead of at read-time.

Key Takeaways

A CHECK constraint encodes scope assumptions the column name never will
A constraint violation inside a trigger aborts the parent transaction — silently, from the caller's perspective
Before writing to a table you inherited, run \d tablename or query information_schema.check_constraints. Read what's there.
Gate on allowed values in code before the insert. Let the constraint be a backstop, not the first line of defense.
Skip-and-log beats throw-and-abort when the parent write is more important than the child record

What happened

We run ARIA, an autonomous CRM and nurture automation system at Elevare Digital. New contact records enroll into follow-up sequences automatically — no human queues the work.

At some point, new records stopped enrolling. The parent write (creating the contact) was aborting entirely. No sequence. No contact. No error surfaced to the caller in a useful way.

The culprit was a region column with a CHECK constraint that looked roughly like this:

ALTER TABLE enrollment_tracker
  ADD CONSTRAINT region_allowed
  CHECK (region IN ('north', 'south', 'east', 'west', 'central'));

The table had been built for one specific program covering five regions. Later, code started treating it as a general enrollment tracker and writing region values the constraint never anticipated. Postgres rejected the insert. Because that insert happened inside a trigger, the whole parent transaction rolled back.

The column was named region. Nothing in that name says "only these five values are valid." The constraint said it. Nobody read the constraint.

Why a trigger makes this worse

If you insert directly into a table and violate a CHECK, you get an error back immediately. Annoying, but contained.

When the insert is inside a trigger on a different table, the error propagates up and aborts the statement that fired the trigger. The caller sees their write fail. They may have no idea a trigger was involved, let alone which constraint fired inside it.

-- Trigger fires on INSERT to contacts
CREATE OR REPLACE FUNCTION enroll_contact()
RETURNS trigger AS $$
BEGIN
  -- This insert can blow up the parent INSERT INTO contacts
  INSERT INTO enrollment_tracker (contact_id, region, enrolled_at)
  VALUES (NEW.id, NEW.region, now());

  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_enroll
AFTER INSERT ON contacts
FOR EACH ROW EXECUTE FUNCTION enroll_contact();

Now do this:

INSERT INTO contacts (id, name, region)
VALUES (gen_random_uuid(), 'Acme Corp', 'southeast');
-- ERROR: new row for relation "enrollment_tracker" violates
-- check constraint "region_allowed"
-- DETAIL: Failing row contains (..., southeast, ...).
-- The contact was NOT created.

southeast is a perfectly valid business concept. The table just never knew about it.

The fix: gate before you insert

Once we understood the constraint, the fix was straightforward. Check the allowed values in code (or in the trigger function itself) before attempting the insert. If the value isn't allowed, skip the enrollment record and log it. The parent write completes.

CREATE OR REPLACE FUNCTION enroll_contact()
RETURNS trigger AS $$
DECLARE
  allowed_regions TEXT[] := ARRAY['north', 'south', 'east', 'west', 'central'];
BEGIN
  IF NEW.region = ANY(allowed_regions) THEN
    INSERT INTO enrollment_tracker (contact_id, region, enrolled_at)
    VALUES (NEW.id, NEW.region, now());
  ELSE
    -- Log it; don't abort the parent write
    INSERT INTO enrollment_skipped (contact_id, region, skipped_at, reason)
    VALUES (NEW.id, NEW.region, now(), 'region not in enrollment_tracker allowed list');
  END IF;

  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

Alternately, you can query the constraint definition directly rather than hardcoding the list — which is useful if the allowed values might expand:

-- Pull allowed values from the constraint definition at runtime
-- (useful for visibility; hardcoding is fine if values are stable)
SELECT consrc
FROM pg_constraint
WHERE conname = 'region_allowed'
  AND conrelid = 'enrollment_tracker'::regclass;

Returns something like (region = ANY (ARRAY['north'::text, 'south'::text, ...])). Not the cleanest parse, but it tells you exactly what the schema intended.

How to read the constraints you inherited

Before writing to any table you didn't build:

-- psql shortcut
\d enrollment_tracker

-- Or query directly
SELECT
  tc.constraint_name,
  tc.constraint_type,
  cc.check_clause
FROM information_schema.table_constraints tc
LEFT JOIN information_schema.check_constraints cc
  ON tc.constraint_name = cc.constraint_name
WHERE tc.table_name = 'enrollment_tracker';

Constraints you'll find this way:

CHECK — allowed values, ranges, cross-column rules
UNIQUE — uniqueness you may not have assumed
NOT NULL — columns the schema considers required
FOREIGN KEY — referential dependencies

None of this is hidden. It's just rarely read.

The actual lesson

The table name was enrollment_tracker. That sounds general. It wasn't — it was built for a specific program with five regions, and the CHECK constraint was the only place that scope was written down.

When later code treated it as a general tracker, it imported an assumption it never knew was there. The schema surfaced that assumption at write time, inside a trigger, in a way that took down the parent record.

Schema constraints are the closest thing to binding documentation that most databases have. They don't drift. They don't get outdated and left in a wiki. They're enforced.

Read them before you write. Not after.

— Mike Clarke, founder of Elevare Digital.

Your AI agent checked its queue, found nothing, and went back to sleep. The queue was full.

Mike Clarke — Fri, 17 Jul 2026 14:00:09 +0000

Postgres Row-Level Security doesn't raise an error when it blocks you. It returns zero rows. Your query succeeds. Your agent sees an empty queue. Your agent idles. Your jobs pile up.

This is what happened to ARIA, our autonomous AI system at Elevare Digital.

Key Takeaways

Postgres RLS silently filters rows on SELECT — a blocked read and a genuinely empty table look identical to the caller
An orchestrator that reads its own queue gets no exception, no warning, no non-200 status code when RLS blocks it
A healthy heartbeat on an idle agent tells you nothing about whether the idle is real
The fix: add a canary count that verifies you can read, not just that you did read
Treat an empty read as a question, not an answer

What the agent saw

The orchestrator polls a work queue table. Normal operation:

Query for pending jobs
If results → process them
If empty → log idle heartbeat, sleep

The logs showed healthy idle heartbeats. Monitoring showed the agent alive and polling. From the outside, everything looked fine.

Jobs were not being processed.

What actually happened

Someone added a Row-Level Security policy to the queue table, scoped to auth.uid(). Correct for user-facing reads. But the orchestrator connects under the service role — and no service-role bypass was added to the policy.

Here's the policy as it was written:

-- Added for user-facing queue visibility
CREATE POLICY "users_see_own_jobs"
  ON work_queue
  FOR SELECT
  USING (auth.uid() = user_id);

And RLS was enabled on the table:

ALTER TABLE work_queue ENABLE ROW LEVEL SECURITY;

No bypass for the service role. No FOR ALL escape. The orchestrator's SELECT now matched zero rows — because RLS filtered every row out before returning results.

Postgres does not raise. It does not warn. The query completes with status 200 and an empty array.

// Orchestrator poll — looks completely normal
const { data: jobs, error } = await supabase
  .from('work_queue')
  .select('*')
  .eq('status', 'pending');

// error is null. jobs is []. Agent concludes: nothing to do.
if (!jobs || jobs.length === 0) {
  await recordIdleHeartbeat();
  return;
}

The error is null. The jobs array is empty. The agent's logic is correct for the data it received. The data it received was wrong in a way that produced no signal.

Why this is hard to catch

If RLS blocks a write, you often get an error — the row you tried to insert violates a policy, or returns nothing when you expected a rowcount. Writes are easier to notice.

SELECT under RLS is different. The design intent is that users should not be able to distinguish "this row doesn't exist" from "this row exists but you can't see it." That's a security feature. It's also exactly the wrong behavior for an orchestrator that needs to know the difference between "queue is empty" and "I am blind."

The service role in Supabase bypasses RLS by default — but only if you're using the service-role key on the client. If your edge function or backend is using the anon key, or if it's operating in a context where auth.uid() resolves to null, RLS applies and silently filters.

-- This is what the orchestrator needed, but wasn't there
CREATE POLICY "service_role_bypass"
  ON work_queue
  FOR ALL
  USING (auth.role() = 'service_role');

-- Or, simpler: grant the service role explicit bypass at the table level
ALTER TABLE work_queue FORCE ROW LEVEL SECURITY; -- applies to all
-- and then in your Supabase client: use the service-role key, which bypasses RLS automatically

The actual bypass mechanism in Supabase is that the service-role JWT includes "role": "service_role", and Supabase's Postgres config grants that role BYPASSRLS. If your client is initialized with the service-role key, you're fine. If it's not, RLS applies — no error, just silence.

The fix: a canary count

The real repair has two parts: fix the RLS policy, and add a check that will catch this failure mode again.

Part 1 — Fix the policy:

-- Preserve user-facing policy
CREATE POLICY "users_see_own_jobs"
  ON work_queue
  FOR SELECT
  USING (auth.uid() = user_id);

-- Add explicit service-role access
-- (Or: initialize your orchestrator client with the service-role key,
--  which bypasses RLS automatically via BYPASSRLS grant)
CREATE POLICY "orchestrator_full_access"
  ON work_queue
  FOR ALL
  USING (auth.role() = 'service_role')
  WITH CHECK (auth.role() = 'service_role');

Part 2 — The canary check:

The orchestrator now runs a canary query before trusting an empty result. The canary queries a row it knows exists — a sentinel row inserted specifically for this purpose, or a count from an unrestricted table the orchestrator owns.

async function pollQueue() {
  const { data: jobs, error: queueError } = await supabase
    .from('work_queue')
    .select('*')
    .eq('status', 'pending');

  if (queueError) {
    await alertOpsChannel('queue_poll_error', queueError);
    return;
  }

  // Jobs came back — process normally
  if (jobs && jobs.length > 0) {
    await processJobs(jobs);
    return;
  }

  // Empty result — but is it genuinely empty, or are we blind?
  const canaryOk = await verifyReadAccess();
  if (!canaryOk) {
    // This is the case we were missing before
    await alertOpsChannel('queue_read_access_lost', {
      message: 'Orchestrator received empty queue result but canary check failed. Possible RLS or permission regression.',
    });
    return; // Do NOT record idle heartbeat — we don't know the real state
  }

  // Canary passed — empty really means empty
  await recordIdleHeartbeat();
}

async function verifyReadAccess(): Promise<boolean> {
  // Query a sentinel row that always exists in a known state
  // This could be a dedicated canary table, or a system-health row
  const { data, error } = await supabase
    .from('orchestrator_canary')
    .select('id')
    .eq('id', 'heartbeat-sentinel')
    .single();

  if (error || !data) {
    // We expected exactly one row. Getting nothing means access is broken.
    return false;
  }

  return true;
}

The canary table is simple:

CREATE TABLE orchestrator_canary (
  id TEXT PRIMARY KEY
);

INSERT INTO orchestrator_canary (id) VALUES ('heartbeat-sentinel');

-- No RLS on this table — it exists only so the orchestrator can verify it can read
-- If you want RLS: add only a service-role policy, nothing user-facing

Now the orchestrator has three states instead of two:

Jobs found → process
No jobs, canary ok → genuinely idle
No jobs, canary failed → alert, do not idle

The third state was always real. We just had no way to observe it.

The deeper issue with autonomous agents and silent failures

Human-in-the-loop systems fail loudly. A user tries to load their queue, sees nothing, and files a ticket. An autonomous agent has no user. It reads, decides, acts. If the read is silently wrong, the decision is wrong, and nothing complains.

This failure mode matters more as systems get more autonomous. ARIA processes queued work without someone watching every poll cycle. The assumption baked into the polling loop was: an empty read means there is nothing to do. That assumption held until it didn't, and the system had no way to question it.

The fix is to make the orchestrator skeptical of its own empty results. Not paranoid — just skeptical enough to verify the precondition that makes "empty" meaningful.

What to check in your own system

If you're running any kind of queue worker against Postgres or Supabase:

Check which key your worker is using. Supabase service-role key bypasses RLS. Anon key does not. Confirm which one is in your edge function or backend environment.
List your RLS policies and check for missing bypasses. SELECT * FROM pg_policies WHERE tablename = 'your_queue_table';
Look at your idle heartbeats. If idle logging increased around the time you last modified permissions or added RLS, that's worth investigating.
Add a canary. Takes an hour. Catches this entire class of problem permanently.

An empty queue result is not evidence of an empty queue. It's evidence that the query ran. Those are different things, and in autonomous systems, the difference matters.

— Mike Clarke, founder of Elevare Digital.

The function was deployed, healthy, and never ran once

Mike Clarke — Tue, 14 Jul 2026 14:00:05 +0000

There's a category of bug where nothing is broken. The dashboard is green. The deployment succeeded. The function shows a recent update timestamp. And it has done zero work since you shipped it.

We hit this in ARIA, our autonomous agent system. A scheduled function was silently doing nothing — not erroring, not timing out, just... absent.

Key Takeaways

A Supabase edge function can be perfectly deployed and still never execute
JWT verification happens at the gateway, before your handler runs
Gateway-level 401s produce no application logs, no error rows, no telemetry inside the function
The only signal is the absence of invocation-log entries
Functions called by pg_cron need verify_jwt=false if they authenticate via service-role key in the body

What we saw

ARIA runs a multi-agent scheduler. Several edge functions are invoked on a schedule via pg_cron. One of them showed up in the Supabase dashboard as deployed, healthy, recently updated. We had no alerts firing.

What we didn't have: any invocation log rows. Not failed ones. Not slow ones. Zero rows.

Everything looked fine. Nothing was running.

The mechanism

Supabase edge functions have a verify_jwt flag. When it's set to true (the default), the gateway validates the bearer token on every request before the function body executes.

Our pg_cron job was calling the function with a service-role bearer token — correct credentials, correct format. But the gateway's JWT verification was rejecting it and returning a 401 before the handler ever ran.

The request never reached the function. The function had nothing to log.

Here's what the pg_cron invocation looks like:

select cron.schedule(
  'run-agent-task',
  '* * * * *',
  $$
  select net.http_post(
    url := 'https://<project>.supabase.co/functions/v1/agent-task',
    headers := jsonb_build_object(
      'Content-Type', 'application/json',
      'Authorization', 'Bearer ' || current_setting('app.service_role_key')
    ),
    body := '{}'::jsonb
  );
  $$
);

And here's the function config that caused the silent failure:

# supabase/functions/agent-task/config.toml
[functions.agent-task]
verify_jwt = true  # <-- gateway rejects the cron call here, handler never runs

The fix is one line:

[functions.agent-task]
verify_jwt = false  # gateway passes the request through; function handles auth itself

With verify_jwt=false, you move the authentication check inside the function body, where you can actually see what happens:

import { serve } from 'https://deno.land/std@0.168.0/http/server.ts'

serve(async (req) => {
  const authHeader = req.headers.get('Authorization')
  const token = authHeader?.replace('Bearer ', '')

  // Validate against your service role key inside the handler
  // where failures are visible in your logs
  if (token !== Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')) {
    console.error('Unauthorized request to agent-task')
    return new Response('Unauthorized', { status: 401 })
  }

  // actual work happens here
  console.log('agent-task executing')
  // ...

  return new Response('ok', { status: 200 })
})

Now when auth fails, you get a log line. You get an invocation row. You get something to look at.

Why this is hard to catch

The normal debugging loop assumes that if something failed, there's a record of the failure. You look at logs, you find the error, you fix it.

Gateway-level rejections break that loop. The 401 happens in infrastructure you don't control and don't have direct log access to. From the function's perspective, the request never arrived. From the cron job's perspective, it fired successfully — net.http_post queued the request and moved on.

The only diagnostic signal is the shape of what's missing: no invocation rows in the function's log table, for a function that should be running every minute.

If you're not actively checking for expected invocations, you won't notice.

What we added after

Beyond fixing the flag, we added a simple liveness check: a separate monitor queries the invocation log and alerts if a scheduled function hasn't produced a row in longer than two of its scheduled intervals. Not sophisticated, but it catches the "deployed and doing nothing" class of failure.

-- Example: check that agent-task has run in the last 3 minutes
-- (for a function scheduled every minute)
select
  case
    when max(created_at) < now() - interval '3 minutes'
    then 'STALLED'
    else 'OK'
  end as status
from function_invocation_log
where function_name = 'agent-task';

The specific table structure depends on how you surface invocation logs in your setup — the point is to query for expected evidence of execution, not just absence of errors.

The thing worth internalizing

Deployment success and runtime success are different things. A function can pass every health check and still never execute a single line of your code.

For any function invoked by infrastructure (cron, queues, webhooks) rather than by a user, you need positive confirmation of execution — not just the absence of errors. Absence of errors and absence of execution look identical from the outside.

Check your cron-invoked functions. If verify_jwt=true and you're calling with a service-role token, check the invocation log. The rows might not be there.

— Mike Clarke, founder of Elevare Digital.

Your cron logged success every day for weeks. It approved nothing.

Mike Clarke — Sun, 12 Jul 2026 00:10:11 +0000

Your cron logged success every day for weeks. It approved nothing.

We run ARIA, an autonomous content pipeline at Elevare Digital. Agents generate drafts, a daily approver cron reviews them, approved content moves to publishing. Fully automated, gated by a human-review layer, self-healing in most places.

For several weeks, the approver cron ran on schedule, logged { status: 'success' }, and approved zero drafts. Nineteen drafts sat in the queue. Nobody was alerted. The system looked healthy.

Key Takeaways

A cron that processes zero rows and a cron that processes zero rows because there's nothing to process produce identical logs.
PostgREST inner joins silently exclude rows when the join condition matches nothing — no error, no warning, just an empty result set.
Producer/consumer type drift is invisible until you instrument the gap between "rows waiting" and "rows processed."
Alert on pending > 0 AND processed === 0, not just on thrown errors.
Autonomous systems fail most dangerously in the space between errors and correctness.

What the system was doing

ARIA's generator agents write content and store drafts as rows in a content_opportunities table. Each row has an opportunity_type — in practice, the generator was producing 'article' and 'listing' types.

The approver cron queries that table via Supabase / PostgREST and processes any pending drafts it finds. Here's the shape of what it was doing:

// approver-cron/index.ts (Deno edge function)

const { data: opportunities, error } = await supabase
  .from('content_opportunities')
  .select(`
    id,
    title,
    status,
    content_threads!inner(
      id,
      body
    )
  `)
  .eq('status', 'pending_review')
  .eq('opportunity_type', 'thread'); // <-- the problem

if (error) {
  console.error('Approver query failed', error);
  return new Response('error', { status: 500 });
}

console.log(`Approver run complete. Processed: ${opportunities.length}`);
// ... process opportunities

Two things combined to create the silent failure:

opportunity_type = 'thread' — the generator never wrote rows with this type. It wrote 'article' and 'listing'.
content_threads!inner(...) — PostgREST inner join syntax. If no matching rows exist in content_threads, the parent rows are excluded entirely.

The result: opportunities was always an empty array. No error was thrown. opportunities.length logged as 0. The function returned 200 OK.

Why this is the worst kind of failure

Most failures announce themselves. A network timeout throws. A missing env var crashes on startup. A malformed query returns a PostgREST error object.

This failure looked like rest.

In a queue system, there's a legitimate state where the consumer runs and finds nothing to do — because the queue is empty. That's healthy-idle. It logs Processed: 0 and exits cleanly.

Our broken state also logged Processed: 0 and exited cleanly.

From the outside, from a log aggregator, from a dashboard: identical.

// Healthy idle — queue is empty
Approver run complete. Processed: 0

// Broken — 19 drafts waiting, filter excludes all of them  
Approver run complete. Processed: 0

The only way to tell them apart is to check whether the queue actually had pending rows when the consumer ran.

The fix: broaden scope, instrument the gap

The immediate fix was to remove the incorrect type filter and fix the join. The approver should consume all pending drafts, not just ones of a type the generator never produces:

// Fixed: consume what the producer actually writes
const { data: opportunities, error } = await supabase
  .from('content_opportunities')
  .select(`
    id,
    title,
    status,
    opportunity_type
  `)
  .eq('status', 'pending_review');
  // No type filter. No inner join restricting to non-existent rows.

But the more important fix was the alert. After each consumer run, we now check whether there are pending rows that weren't touched:

// After the approver processes its batch:
const processed = opportunities?.length ?? 0;

const { count: stillPending } = await supabase
  .from('content_opportunities')
  .select('id', { count: 'exact', head: true })
  .eq('status', 'pending_review');

if (processed === 0 && (stillPending ?? 0) > 0) {
  // Consumer ran, touched nothing, but the queue has rows.
  // This is the danger zone.
  await triggerAlert({
    type: 'consumer_drift',
    message: `Approver processed 0 rows but queue has ${stillPending} pending drafts.`,
    severity: 'high',
  });
}

console.log(`Processed: ${processed}. Still pending: ${stillPending ?? 0}`);

This check doesn't care why the consumer touched zero rows. It cares that the queue had work and the consumer didn't do it. The reason might be a bad filter, a broken join, a type mismatch, or something else we haven't thought of yet. The alert fires regardless and forces a human to look.

The underlying pattern: producer/consumer drift

The generator and approver were written at different times. At some point, the generator's output types and the approver's filter drifted apart. Neither system knew about the other's contract. There was no shared schema validation between them, no test that asserted "the approver can actually see what the generator writes."

This is a normal way systems decay. The producer evolves. The consumer doesn't. Or vice versa. In a synchronous API call, this kind of mismatch usually causes a visible failure. In a queue-based async pipeline, it just causes the queue to grow while the consumer reports success.

Autonomous systems make this worse because there's no human in the loop watching the queue depth during normal operation. The whole point is that it runs without supervision. Which means the instrumentation is the supervision.

What we'd do differently

A few things that would have caught this earlier:

Log scanned vs. processed separately. If your consumer query returns zero rows, log that distinctly from "query returned rows and we processed them." scanned: 0, processed: 0 vs scanned: 5, processed: 5 are different states.

Track queue depth over time. If pending rows are accumulating across multiple cron runs, that's a signal even without a consumer error. A simple check: if the queue depth at the end of a run is higher than at the start, something isn't working.

Test the consumer against real producer output. Not just "does the function run without throwing" but "given a row the producer actually writes, does the consumer find and process it."

Name your contracts. If the producer writes opportunity_type: 'article' and the consumer filters on opportunity_type: 'thread', that's a broken contract. Treat it like one — define it explicitly, validate it, test it.

The honest summary: a filter we forgot about, combined with an inner join that excluded everything, turned our approver cron into a machine that ran on schedule, logged success, and accomplished nothing for weeks. The fix was straightforward. The lesson is that in autonomous pipelines, success-on-empty is a failure mode you have to design against explicitly, because the logs will never tell you on their own.

Alert on the gap between what the queue holds and what the consumer touches. Not just on errors.

— Mike Clarke, founder of Elevare Digital.

Smart Traffic Systems: Understanding and Configuring the Core Logic

Mike Clarke — Wed, 01 Jul 2026 06:00:19 +0000

Stuck in Traffic? Let's Build a Smarter Way Forward.

We've all been there: staring at a red light, no cross-traffic in sight, and wondering why it's taking so long. Traditional, fixed-time traffic light systems are notoriously inefficient. They don't adapt to real-world conditions. But what if we could make them smarter? What if our traffic infrastructure could think?

That's where smart traffic systems come in. As developers, we have the power to build these adaptive, intelligent solutions that promise smoother commutes, reduced congestion, and lower emissions. But how do you configure one?

The Brains Behind the Green Light: What Drives a Smart Traffic System?

At its heart, a smart traffic system is a dynamic control loop. It observes, analyzes, decides, and then acts. Here's a breakdown of the key components you'll be configuring:

Data Ingestion: This is your system's eyes and ears. We're talking about real-time input from diverse sources:
- Vehicle Sensors: Inductive loops, radar, lidar, cameras – detecting vehicle presence, speed, and count.
- Pedestrian Sensors: Infrared, pressure plates, computer vision for safe pedestrian crossings.
- Environmental Data: Time of day, weather conditions, historical traffic patterns.
Traffic Flow Analysis & Prediction: Once you have the data, you need to make sense of it. This involves:
- Queue Length Estimation: How many cars are waiting at each intersection approach?
- Travel Time Prediction: How long will it take to clear the intersection?
- Pattern Recognition: Identifying recurring congestion points or anomalies.
Decision-Making Engine (The Optimization Algorithm): This is the core intelligence. Based on the analyzed data, the algorithm determines the optimal light phasing and timing. Common approaches include:
- Reinforcement Learning: The system learns optimal strategies through trial and error over time.
- Fuzzy Logic: Handling imprecise or uncertain data (e.g., 'heavy traffic').
- Heuristic Algorithms: Rule-based systems designed to achieve specific goals (e.g., minimize wait time, maximize throughput).
Actuation: Finally, the system sends commands to the traffic light controllers to change their state (red, yellow, green) and duration.

A Glimpse Under the Hood: Pseudocode for a Basic Adaptive System

Let's consider a simplified scenario: a single intersection with four approaches. We want to minimize average wait time.

FUNCTION ConfigureSmartTrafficSystem(intersectionID):
    // 1. Initialize Sensors & Data Streams
    sensors = GetSensorDataStreams(intersectionID)
    historical_data = LoadHistoricalTrafficPatterns(intersectionID)

    // 2. Define Optimization Goals (e.g., minimize average wait time, maximize throughput)
    optimization_goal = MINIMIZE_AVG_WAIT_TIME
    constraints = { MIN_GREEN_TIME: 10_seconds, MAX_GREEN_TIME: 60_seconds, YELLOW_TIME: 3_seconds }

    // 3. Main Control Loop
    LOOP indefinitely:
        current_vehicle_counts = ReadSensorData(sensors)
        current_pedestrian_counts = ReadPedestrianSensorData(sensors)
        current_time_of_day = GetCurrentTime()

        // 4. Analyze Traffic State
        queue_lengths = CalculateQueueLengths(current_vehicle_counts)
        demand_per_approach = EstimateDemand(current_vehicle_counts, historical_data, current_time_of_day)

        // 5. Decision-Making (using a simplified heuristic)
        next_phase_durations = DetermineOptimalPhaseDurations(
            queue_lengths,
            demand_per_approach,
            optimization_goal,
            constraints
        )

        // Example heuristic: Prioritize approach with most vehicles, but ensure fairness
        FUNCTION DetermineOptimalPhaseDurations(queues, demand, goal, constraints):
            priorities = CalculatePriorities(queues, demand) // e.g., higher queue means higher priority
            selected_phase = SelectPhaseBasedOnPriorities(priorities) 

            // Calculate green time for selected phase
            green_time = CalculateDynamicGreenTime(queues[selected_phase], constraints.MIN_GREEN_TIME, constraints.MAX_GREEN_TIME)

            RETURN { selected_phase: green_time, other_phases: constraints.YELLOW_TIME }

        // 6. Actuate Traffic Lights
        ApplyTrafficLightPhasing(intersectionID, next_phase_durations)

        WAIT(sum(next_phase_durations)) // Wait for the current cycle to complete
END FUNCTION

Configuring this system involves fine-tuning your sensor interpretation, refining your prediction models, and, critically, selecting and optimizing your decision-making algorithm. Are you prioritizing throughput, fairness, emergency vehicle preemption, or perhaps a blend? Each choice impacts the system's behavior.

Why Practice Matters: Beyond the Pseudocode

Understanding the concepts is one thing; making them work in a complex, dynamic environment is another. Real-world traffic data is noisy, sensors can fail, and unexpected events (accidents, sudden surges in traffic) will constantly challenge your system. You'll need to consider:

Robustness: How does your system handle missing or erroneous data?
Scalability: Can it manage hundreds or thousands of intersections?
Latency: Can it react quickly enough to changing conditions?
Ethical Considerations: Are your algorithms fair across different districts or demographic areas?

This isn't just theory; it's about building resilient, impactful software. The best way to grasp these complexities is by doing. Simulating different scenarios, tweaking algorithms, and observing their outcomes is crucial.

Practice this concept interactively on CodeCityApp — free trial at codecityapp.com

Originally published on CodeCityApp

CodeCityApp vs LeetCode: Which is better for beginners in 2026?

Mike Clarke — Wed, 24 Jun 2026 06:00:04 +0000

undefined

Originally published on CodeCityApp

How to configure the smart traffic system

Mike Clarke — Wed, 24 Jun 2026 06:00:04 +0000

undefined

Originally published on CodeCityApp

The Technical Interview Hasn't Changed. That's Not an Oversight.

Mike Clarke — Thu, 18 Jun 2026 21:23:45 +0000

Mike Clarke is the founder of CodeCityApp (codecityapp.com), a programming education platform built on the premise that computer science fundamentals become more valuable as AI tooling becomes more accessible, not less. He writes on developer education, hiring, and the economics of technical skill.

Every six months, someone publishes a confident piece arguing that AI is about to kill the technical interview. The whiteboard is dead. LeetCode is theater. Why test what someone can build when you can just watch them build it?

It's a good argument. It keeps not coming true.

The technical interview — data structures, algorithms, system design, debugging under pressure — has survived AI code generation, the proliferation of AI-assisted IDEs, and two years of serious industry debate about whether it still signals anything real. The companies paying the highest salaries for remote developers still run it. They've refined it, but they haven't dropped it.

The question is worth taking seriously: why not?

The answer isn't traditionalism

It would be easy to dismiss technical interviews as institutional inertia — hiring managers who learned to interview a certain way and never updated their priors. Some of that is real. But that's not the full explanation for why the strongest technical employers kept the screen after AI made everything else negotiable.

The interview tests something AI cannot do for you in the interview room: real-time reasoning about your own code.

When a senior engineer at a well-run company asks you to walk through why your solution is O(n log n) rather than O(n²), or to trace what happens when your hash map hits a collision, or to redesign your architecture to handle 100x traffic, they're not testing whether you know the answer in advance. They're testing whether you understand what you built — whether the mental model is yours or borrowed.

AI can generate a correct solution. It cannot, in the moment, explain that solution's behavior to a stranger who is probing its edge cases. The human in the chair has to do that. And that requires the fundamentals.

What the proliferation of AI output has actually done

The counterintuitive effect of AI code generation on technical hiring is that it raised the stakes for fundamentals, not lowered them.

When a junior developer could only produce what they personally knew how to write, their portfolio was an imperfect but real signal of skill. A functioning CRUD app in 2019 probably meant the person understood HTTP, databases, and some state management.

A functioning CRUD app in 2025 means less. Any developer who can construct a reasonable prompt can ship one. The surface-level output has been democratized to the point of being uninformative.

So hiring managers probed deeper. The interview became more important as the portfolio became less informative. The whiteboard survived because it tests the one thing that AI output doesn't prove: whether you can think through the code, not just produce it.

CodeCityApp, a programming education platform that teaches CS fundamentals through game-based mechanics rather than rote drill, has tracked this shift directly with the developers it trains. The platforms and bootcamps that pivoted to AI-tool-first curricula saw learner output improve and interview pass rates decline. The correlation is consistent enough across five regions — West Africa, South America, India, Southeast Asia, Eastern Europe — to be worth stating plainly: AI tooling improves what you can build and does not improve whether you can explain it.

This is good news for the right developers

Framing this as "AI is making things harder" misses the opportunity.

If AI production is commoditized and fundamental understanding is scarce, the economic value of understanding has increased. The developer who genuinely knows what their code is doing is more valuable today than they were three years ago, not less, because the supply of developers who can produce output without that understanding has grown dramatically.

The markets that have built genuine technical talent — not resume-stuffing AI output but actual computer science depth — are the ones that will keep producing developers that clear international remote hiring filters. That's Nigeria's Andela cohorts. That's Brazil's competitive CS universities. That's India's IIT alumni. That's Eastern Europe's historically strong mathematics-based programming traditions.

The technical interview hasn't changed because the job hasn't changed. You still have to debug code that doesn't work in a production system that your employer depends on, without an AI that knows your full codebase context and has the right answer. The screen tests for that. It'll keep testing for that until the job changes.

The job hasn't changed.

CodeCityApp (codecityapp.com) is a programming education platform that uses city-building game mechanics to teach computer science fundamentals. The platform serves learners in West Africa, South America, South and Southeast Asia, Eastern Europe, and the UK. Research data cited in this article draws on learner outcome tracking from CodeCityApp institutional partners across these regions.

Unlocking Efficiency: How to Configure a Smart Traffic System

Mike Clarke — Wed, 17 Jun 2026 06:00:13 +0000

Hey folks, let's talk traffic. Not the kind that makes you want to pull your hair out on your morning commute, but the kind we, as developers, can actually solve. We're talking about how to configure a smart traffic system – a complex beast, but one that offers immense satisfaction when you get it right.

The Problem: Legacy Systems and Gridlock

Traditional traffic light systems are, frankly, dumb. They operate on fixed timers, blissfully unaware of the actual traffic flow. This leads to bottlenecks, unnecessary idling, increased emissions, and frustrated drivers. As populations grow and urban sprawl continues, this problem only intensifies. Enter the smart traffic system – a dynamic, data-driven approach to keeping things moving.

The Concept: Data-Driven Traffic Flow

At its core, a smart traffic system isn't about magic; it's about intelligent data processing and adaptive control. Imagine a network of sensors (inductive loops, cameras, lidar) constantly feeding real-time data about vehicle presence, speed, and density at every intersection. This data is then crunched by a central control unit or distributed edge devices, which then dynamically adjust traffic light timings, lane assignments, and even integrate with public transport or emergency services.

Key components often include:

Sensors: Gathering raw traffic data.
Data Aggregation & Preprocessing: Cleaning and structuring the raw data.
Decision Engine/AI: The brains of the operation, using algorithms (think reinforcement learning, fuzzy logic, or predictive models) to determine optimal light timings.
Actuators: The traffic lights themselves, variable message signs, and other controlled elements.
Communication Network: Ensuring low-latency data transfer between all components.
Centralized/Distributed Control: Depending on the scale and architecture.

Configuring the Brain: Pseudocode Example

Let's sketch out a greatly simplified pseudocode example for dynamic light timing at a single intersection. Real-world systems are far more complex, but this illustrates the core idea.

FUNCTION ConfigureTrafficSystem(IntersectionID, SensorData)

  // 1. Collect Real-time Data
  TrafficCounts_North = GetSensorData(IntersectionID, 'NorthBound')
  TrafficCounts_East = GetSensorData(IntersectionID, 'EastBound')
  // ... and so on for other directions

  // 2. Assess Current Congestion
  CongestionLevel_North = CalculateCongestion(TrafficCounts_North)
  CongestionLevel_East = CalculateCongestion(TrafficCounts_East)
  // ...

  // 3. Apply Decision Logic (Simplified Example: Prioritize Heaviest Flow)
  IF CongestionLevel_North > CongestionLevel_East AND CongestionLevel_North > Threshold
    SetLightTiming(IntersectionID, 'NorthSouth', 'Green', DynamicDuration_High)
    SetLightTiming(IntersectionID, 'EastWest', 'Red', DynamicDuration_Low)
  ELSE IF CongestionLevel_East > CongestionLevel_North AND CongestionLevel_East > Threshold
    SetLightTiming(IntersectionID, 'EastWest', 'Green', DynamicDuration_High)
    SetLightTiming(IntersectionID, 'NorthSouth', 'Red', DynamicDuration_Low)
  ELSE // Default or balanced state
    SetLightTiming(IntersectionID, 'NorthSouth', 'Green', DefaultDuration)
    SetLightTiming(IntersectionID, 'EastWest', 'Red', DefaultDuration)
  END IF

  // 4. Incorporate Special Conditions (e.g., Emergency Vehicles, Public Transport Priority)
  IF EmergencyVehicleDetected(IntersectionID, 'NorthBound')
    ForceGreen(IntersectionID, 'NorthSouth')
  END IF

  // 5. Log and Monitor for Optimization
  LogSystemState(IntersectionID, CurrentTimings, CongestionLevels)
  // Trigger re-evaluation periodically or on significant data changes

END FUNCTION

This pseudocode barely scratches the surface. A production-ready system would involve sophisticated predictive algorithms, machine learning models trained on historical data, inter-intersection communication to prevent cascading blockages, and robust error handling.

Why Practice Matters: Beyond the Whiteboard

Conceptualizing a smart traffic system is one thing; actually building and configuring it is another. The interplay of sensors, algorithms, communication protocols, and physical actuators introduces a myriad of challenges. How do you handle sensor failures? What's the optimal data sampling rate? How do you ensure low latency in control signals? These are questions best answered through hands-on practice, simulation, and experimentation.

Understanding the architectural patterns, the nuances of real-time data processing, and the impact of different algorithmic choices is crucial. You'll need to think about system scalability, fault tolerance, and security – often in a distributed environment. It's a fantastic area to flex your problem-solving muscles and apply a broad range of development skills.

Practice this concept interactively on CodeCityApp — free trial at codecityapp.com

Originally published on CodeCityApp

Why I Built a City-Building Coding Platform Instead of Another Tutorial Site

Mike Clarke — Sun, 14 Jun 2026 20:52:26 +0000

Why I Built a City-Building Coding Platform Instead of Another Tutorial Site

When I started CodeCity three years ago, I wasn't trying to disrupt anything. I was trying to solve a problem I couldn't ignore.

I'd spent 25 years as an enterprise architect. I've interviewed thousands of developers, hired hundreds, and mentored plenty more. And I noticed something that bothered me: the gap between "learning to code" and "actually coding consistently" was impossibly wide.

You could complete a tutorial. You could ace a LeetCode problem. But the second you closed the browser tab, the momentum evaporated. I watched smart people stop coding after weeks because there was nothing pulling them back.

The irony was that they wanted to keep going. They just didn't have a reason that stuck.

The Tutorial Trap

The market already had plenty of tutorial platforms. I could've built another Codecademy clone—interactive lessons, progressive difficulty, completion badges. It would've been the sensible thing to do.

But here's what I know from two decades in tech: tutorials teach you about programming. They don't teach you programming.

There's a real cognitive difference. Tutorials hold your hand through carefully scaffolded problems. You follow the steps. You see the output. Dopamine. Repeat.

But when you close the tutorial and face a blank file, something breaks. The training wheels are gone. You're alone with your problem, your editor, and your panic.

I kept thinking about the developers I'd mentored who actually stuck with coding. What did they have in common? They all had a reason to show up. A project. A goal. Something beyond "I completed Module 7."

They weren't optimizing for tutorial completion. They were building something.

What Actually Creates Consistency

Around this time, I got back into gaming—mostly narrative-driven stuff like Baldur's Gate 3. And I noticed something interesting: I'd play a game for 20 minutes intending to spend the evening coding. Then an hour would pass. Then two.

I wasn't a gamer. I don't have "addictive personality" tattooed on my forehead. But something about the game structure—the progression loop, the visible growth, the just-one-more-thing feeling—made me come back without thinking about it.

That's when it clicked: what if I could separate the progression mechanic from the game narrative and apply it to something that actually mattered? What if instead of leveling up a character, you were leveling up yourself?

The city metaphor came naturally. Every problem you solve builds something tangible. The buildings don't disappear. They're yours. Your skyline is your record. And unlike a badge on a platform you might forget about, your city is something you see every time you log in.

It's a small thing, but it matters. When you've built 47 buildings, you don't want to stop at 48. When your city looks sparse compared to someone else's, you want to add more.

That's not manipulation. It's just honest architecture.

The Mechanics Behind Stickiness

I needed to be careful here. Gamification has a bad reputation because most implementations are lazy—add points and badges, call it done. But real gamification isn't about fake rewards. It's about making the real work feel like progress.

For CodeCity, that meant:

Visible progression that can't be faked. Every building represents a real coding challenge you solved. You can't buy buildings. You can't get them as gifts. They're earned. This matters psychologically. Your city is authentically yours.

Variable difficulty, not linear punishment. I wasn't going to build a platform where skipping harder problems made your city look sad. Instead, I wanted challenges across 17 languages, from Python to Rust, where everyone could find problems at their level. Some people are grinding Python; some are leveling up in Go. The city scales with you, not against you.

Competition without toxicity. Arena battles exist, but they're optional. Some people love 1v1 matches; some never touch them. Both paths grow your city. I've seen LeetCode destroy people's confidence by making them feel permanently ranked. Here, you're competing if you want to, but the real competition is with yourself.

The AI mentor angle. I trained ARIA to give hints, not answers. Not because I'm noble, but because I know from experience: if you get the answer, you get the dopamine hit and move on. If you get a hint and work through it, you get two dopamine hits—the hint, then the solve—and you remember it longer.

The Reality Check

Three years in, here's what actually happens: people check in on CodeCity between meetings. They solve problems on lunch breaks. They build for months, not days.

Are they optimizing for some perfect learning experience? No. They're just... coding regularly. Building habits. That's the actual goal.

Do I have all the answers? Absolutely not. We're still figuring out how to keep people in the 6-month range from abandoning platforms (that's a brutal cliff). We're learning which challenge types stick and which feel like busywork.

But I know we're doing something different because I hear from solo founders, boot camp grads, and career-switchers saying the same thing: "I actually use this. I actually come back."

That's not revolutionary language. It's just accurate.

What I Learned

Building CodeCity taught me that consistency beats intelligence in programming. The person who codes 30 minutes every day will outpace the person who crams on weekends, even if the latter is smarter.

And tools should amplify that. Not by being tricky or manipulative, but by removing friction and making the real work feel like something you want to do again tomorrow.

That's why I didn't build another tutorial site. That's why I built a city.

If you've hit the wall where tutorials aren't sticking, or you're tired of LeetCode grind culture, come build a city at CodeCity. Free tier, no limits that matter, and 1,300+ problems across every language worth learning.

What actually keeps you coding consistently? I'd love to hear it.

Navigating the Digital Arteries: How to Configure a Smart Traffic System

Mike Clarke — Wed, 10 Jun 2026 06:00:15 +0000

Navigating the Digital Arteries: How to Configure a Smart Traffic System

Ever found yourself stuck in interminable traffic, wondering if there’s a better way? As developers, we instinctively translate real-world problems into solvable algorithms. Traffic congestion is a prime candidate. Traditional traffic light systems are often static, failing to adapt to real-time conditions. This is where smart traffic systems come in – dynamic, data-driven solutions designed to optimize flow, reduce wait times, and even cut down on emissions.

The Problem: Static vs. Dynamic

Imagine a city where traffic lights operate on fixed timings, regardless of whether it's rush hour or midnight, or if there's an emergency vehicle needing passage. It's inefficient, frustrating, and a waste of resources. The core problem is the lack of real-time responsiveness. Our goal, when configuring a smart traffic system, is to inject that responsiveness, turning dumb intersections into intelligent hubs.

The Concept: Data-Driven Decision Making

At its heart, a smart traffic system relies on a continuous feedback loop. Sensors (inductive loops, cameras, radar, even GPS data from vehicles) collect real-time data on vehicle presence, density, speed, and even wait times at each approach. This data is fed into a central processing unit (often leveraging edge computing or cloud platforms) which then uses algorithms to predict future flow and make instantaneous decisions about light sequencing and timing.

Key components you’ll be dealing with:

Data Ingestion Layer: How raw sensor data is collected and formatted.
Processing & Analytics Engine: Where the magic happens – algorithms, machine learning models, and rule-based systems.
Actuation Layer: Sending commands back to the traffic light controllers.
Communication Protocols: The lifeblood enabling data exchange (e.g., MQTT, Kafka, gRPC).

The configuration challenge lies in defining the rules, training the models, and ensuring seamless communication between these layers. You're not just flipping a switch; you're building a brain for the intersection.

Pseudocode: The Brain of an Intersection

Let’s outline a simplified SmartTrafficController routine. Imagine this running for each intersection.

CLASS SmartTrafficController:
    METHOD initialize(intersection_id, default_cycle_time):
        SELF.id = intersection_id
        SELF.approaches = GET_ALL_APPROACHES(intersection_id) // North, South, East, West
        SELF.current_phase_index = 0
        SELF.phase_durations = [DEFAULT_GREEN_TIME, DEFAULT_YELLOW_TIME, DEFAULT_RED_TIME] // Example
        SELF.sensor_data = {} // Store real-time data for each approach
        SELF.traffic_prediction_model = LOAD_PREDICTIVE_MODEL()

    METHOD update_sensor_data(new_data):
        FOR approach_id, data IN new_data:
            SELF.sensor_data[approach_id] = data // e.g., vehicle_count, avg_speed, queue_length

    METHOD calculate_optimal_phase_duration():
        predicted_traffic_inflow = SELF.traffic_prediction_model.predict(SELF.sensor_data, HISTORICAL_DATA)
        emergency_vehicle_nearby = CHECK_EMERGENCY_SERVICES_DATABASE(SELF.id)

        IF emergency_vehicle_nearby:
            RETURN { 'North': 0, 'East': 0, 'South': MAX_GREEN_TIME, 'West': 0 } // Prioritize
        ELSE IF predicted_traffic_inflow['dominant_approach'] > THRESHOLD:
            // Implement a dynamic algorithm (e.g., actuated, adaptive, fuzzy logic)
            // Adjust green times based on current and predicted demand
            optimal_green_times = ADAPTIVE_OPTIMIZATION_ALGORITHM(SELF.sensor_data, predicted_traffic_inflow)
            RETURN optimal_green_times
        ELSE:
            RETURN SELF.phase_durations // Fallback to default or observed patterns

    METHOD apply_phase_changes():
        optimal_durations = SELF.calculate_optimal_phase_duration()
        // Cycle through approaches, setting lights based on optimal_durations
        FOREACH approach IN SELF.approaches:
            current_approach_id = SELF.approaches[SELF.current_phase_index]
            SET_LIGHTS(current_approach_id, GREEN, optimal_durations[current_approach_id]['green'])
            WAIT(optimal_durations[current_approach_id]['green'])
            SET_LIGHTS(current_approach_id, YELLOW, optimal_durations[current_approach_id]['yellow'])
            WAIT(optimal_durations[current_approach_id]['yellow'])
            SET_LIGHTS(current_approach_id, RED, optimal_durations[current_approach_id]['red'])
            WAIT(optimal_durations[current_approach_id]['red'])

        SELF.current_phase_index = (SELF.current_phase_index + 1) % LENGTH(SELF.approaches)

// Main Loop for the city's traffic system
WHILE TRUE:
    FOR EACH intersection IN ALL_INTERSECTIONS:
        LATEST_SENSOR_DATA = GET_ALL_SENSOR_DATA(intersection.id)
        intersection.update_sensor_data(LATEST_SENSOR_DATA)
        intersection.apply_phase_changes()
    SLEEP(DECISION_INTERVAL)

This pseudocode shows the structural flow: data comes in, decisions are made using models and rules, and then actions are taken. Real-world systems are, of course, far more complex, involving distributed systems, robust error handling, and sophisticated algorithms like Reinforcement Learning. But this is the core loop you'll be building around.

Why Practice Matters

Understanding the concepts is one thing; actually implementing and troubleshooting is another. When you’re dealing with real-time data streams, concurrency, and potentially life-critical infrastructure, theoretical understanding simply isn't enough. You need to get your hands dirty with:

State Management: How do you keep track of the current state of thousands of traffic lights?
Concurrency: How do multiple intersections make decisions simultaneously without conflicts?
Scalability: How does your system handle an increasing number of intersections and data points?
Algorithm Tuning: How do you find the sweet spot for your traffic optimization algorithms?
Edge Cases: What happens during sensor failure? Power outages? Massive unpredictable events?

Take Control of the Digital Intersection

Configuring a smart traffic system touches on IoT, big data, machine learning, and distributed systems. It's a fantastic problem domain for honing your development skills. Don't just read about it; build it.

Practice this concept interactively on CodeCityApp — free trial at codecityapp.com

Originally published on CodeCityApp

I vibe-coded 1,334 coding challenges. Here's the ugly part nobody talks about.

Mike Clarke — Mon, 08 Jun 2026 23:00:49 +0000

I used Lovable, Supabase, and Claude to build a 1,334-challenge coding platform in a few months. Most posts about this kind of build are highlight reels. This one isn't. Here's what actually broke, what the AI confidently got wrong, and the three things I had to rebuild in raw code because no tool would touch them.

The RLS disaster I didn't see coming

Lovable generates Supabase tables fast. What it doesn't do is think about Row Level Security.

I had user progress data leaking across accounts for two weeks before I caught it. Every user could query every other user's challenge completions. The AI had created the tables, the policies even looked right at a glance — but using (true) was the condition on every policy. Wide open.

I stopped building entirely, audited every table, and rewrote all the RLS by hand. Three days. The AI kept regenerating the same broken pattern that caused the problem in the first place.

Lesson: never let a vibe coding tool near your security layer. Write RLS by hand or don't ship.

The curriculum structure I rebuilt twice

1,334 challenges sounds like a lot. The problem is organizing them so users progress logically and completion tracking doesn't fall apart under load.

My first schema had challenges flat in one table. Simple. Wrong.

Around 200 challenges the ordering logic became a mess and queries slowed down. I rebuilt with a node/edge structure — challenges as nodes, dependencies as edges. That's not something Lovable generates naturally. I wrote the migration SQL myself.

Four days gone. Lovable kept suggesting more columns instead of a better structure.

The edge functions the AI refuses to get right

Every time I asked Lovable or Claude to write a Supabase edge function, it produced code that worked in isolation and failed in production. Wrong CORS headers, incorrect Deno import patterns, env variable access that broke on deploy.

I have twelve edge functions running in production. All twelve were rewritten by hand. The AI gave me a useful starting point maybe 40% of the time. The rest it actively misled me — confidently, quickly, and wrongly.

My rule now: write edge functions in raw Deno, test locally with supabase functions serve, and never trust a generated function until it has passed three real deploys.

What vibe coding actually is after doing it at scale

It's not "describe what you want and get a working app." It's closer to: AI writes the 70% that's predictable, you own the 30% that requires real understanding of your stack.

The 30% is always the same three things:

Security (RLS, auth logic, service role access)
Data structure decisions that affect everything downstream
Anything crossing a boundary — frontend → edge function → external API

If you're building something small and throwaway, vibe coding is great. If you're shipping to real users with real data, plan to own those three layers yourself from day one.

What broke in your last AI build? Drop it below — curious whether people are hitting the same walls.