DEV Community: Mike Clarke

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.

I built a coding platform where your first function constructs a building — here's what I learned

Mike Clarke — Wed, 03 Jun 2026 19:13:44 +0000

The first thing a new user writes in CodecityApp is this:

def greet(name):
    return f"Hello, {name}!"

When that test passes, Town Hall appears in their city. Not a badge. Not XP. A building.

That's the core bet I made when I started this — that a visual construction metaphor would do something a progress bar never could.

Why I went with city-building

I've been around enough bootcamps to know what kills motivation. It's not difficulty. It's abstractness. You write a function, tests go green, nothing visibly changes. Then you write another. Tests go green. Still nothing.

The feedback loop is too thin for most beginners.

So I tried something different: every challenge maps to a specific building in a city. You write real code — not drag-and-drop, not fill-in-the-blank — and the city grows. Town Hall at the center. New buildings at the edges. Empty land where you haven't been yet.

You can see where you stand at a glance. That's the whole thing.

What's under the hood

CodecityApp has 1,334 challenges across 10 languages — Python, JavaScript, TypeScript, SQL, Bash, and more — organized into "planets" rather than flat course modules. There are 1v1 Arena battles with ELO ranking for users who want something competitive.

Code runs server-side through Judge0 with a 5-second execution ceiling and IP-based rate limiting. No client-side evaluation tricks — actual code, actual output, tested against real test cases.

ARIA, the built-in AI mentor, gives hints when you're stuck. She doesn't give you the answer. She asks the right question.

Stack: React + Vite + Tailwind, Supabase for backend, Framer Motion for city animations.

The mistake that cost me months

For a long time, the galaxy progress system was hardcoded open. Every world was accessible regardless of what the user had actually completed.

Classic builder mistake: I was heads-down on challenge quality and left the progression system as a stub. Users could skip to advanced content immediately — which sounds flexible, but it gutted the sense of building anything. You can't feel like you're constructing a city if nothing is earned.

I fixed it. But I lost months of users experiencing the product as intended, without realising why retention felt off.

The thing that surprised me most

When I watched a real user session for the first time, they skipped the instructions entirely. They saw the city, clicked a building, wrote the code.

No onboarding flow caused that. The city did the explaining.

That's the part I didn't fully predict when I started — that the metaphor does the teaching before the first lesson even loads.

Try it

Guest challenges are live — no account needed. You can write Python in the browser and see your first building appear in under a minute.

→ codecityapp.com

Would love to hear from other builders who've tried game mechanics in serious learning tools. What held up? What fell apart?

I built a 1,334-challenge coding platform solo with Lovable, Supabase, and Claude — here's what actually worked

Mike Clarke — Wed, 03 Jun 2026 02:50:41 +0000

CodecityApp has 1,334 challenges across 10 languages. I built it alone. No co-founder, no engineering team. Here's the real stack and the mistakes I'd avoid.

The stack

Frontend lives in Lovable — React + Vite + Tailwind under the hood. Backend runs on two Supabase projects (I'll explain why that's a trap). Code evaluation goes through Judge0, wrapped in a Supabase edge function with IP rate limiting and a 5-second execution ceiling. The AI mentor is Claude running as an edge function. Email and outreach run through another Claude agent — fully autonomous, fires on a schedule, handles replies.

I wrote maybe 20% of the code by hand. The rest came out of Lovable prompts and direct API calls.

The two-Supabase trap

Lovable spins up its own Supabase project automatically. I also had a production Supabase project where I'd built all the edge functions, crons, and email infrastructure before connecting Lovable.

So now I had two projects. One with real backend logic. One that Lovable owned.

For months I'd debug something in production and the dashboard would show different numbers. Edge functions deployed to the wrong project. API keys wired to the wrong database. Cron jobs firing in one project with no effect on the data in the other.

If you're starting fresh: pick one Supabase project, connect Lovable to it from day one. Don't let Lovable spin up its own.

The bugs that will wreck you aren't in the code

Two things that cost me weeks:

One. The challenge progression system was hardcoded open for months. Every world was accessible regardless of what users had actually completed. I was testing my own account (which had everything done) and never caught it. Real users had no structured path. Retention felt off but I couldn't diagnose why until I watched a real session.

Two. My B2B outreach pipeline showed five clicks from leads including Codecademy and MIT OpenCourseWare. I thought we had genuine interest. Every single click was Microsoft Defender and Proofpoint firing automated link scanners, 21–33 seconds post-send, with no preceding open. Zero human engagement.

Both came from building fast and not verifying what was actually shipped vs. what I assumed was shipped. Lovable will tell you "COMPLETE" while the live site still shows the broken state — CDN lag, or the fix went to the wrong component. Always verify on the live domain.

The AI agent part people don't talk about

ARIA is a Claude-powered sales agent that reads inbound replies, scores them, picks a follow-up tactic from a library, writes the email, and sends it — on its own schedule, without me in the loop.

Building that was the most interesting part of this project. Not because it's technically complex, but because writing the system prompt for an autonomous agent that has to handle objections, read context, and sound like a real person is genuinely hard. Most autonomous email agents sound like robots. Getting ARIA to sound like a founder writing at 7am took more iterations than any other single feature.

The short version: give it a persona with specific constraints, not generic instructions. "Sound professional" produces garbage. "Never open with the company name as the first word. Lead with something specific about the recipient." produces something usable.

What I'd do differently

Start with a real user in session 1, not session 100. I spent too long building and not enough time watching someone use it cold. The city metaphor — where writing code constructs actual buildings — landed immediately for every person who saw it. I didn't know that for a long time because I was too deep in the build to test it cleanly.

The vibe coding workflow is real and it's fast. The risk isn't that the AI builds the wrong thing. The risk is that you don't catch what it built wrong until much later.

If you're building in a similar stack or have hit the two-Supabase problem, happy to get into specifics in the comments.

→ codecityapp.com — guest challenges work with no account if you want to see the city mechanic.

I built a coding app where your skills become a city you can see grow

Mike Clarke — Thu, 28 May 2026 22:42:30 +0000

Most people don't quit learning to code because it's too hard. They quit around week 3 — the moment progress stops feeling like progress. You solve problems and... nothing visible happens.

I spent a long time on that problem, and the fix I landed on was simple: make progress something you can see.

So I built CodeCity. Every coding challenge you solve adds a building to your city. Solve 100 challenges, you've got 100 buildings — a literal, visual portfolio of your skills instead of a certificate that says "trust me."

What's in it right now:

1,334 real coding challenges
10 languages (Python, JavaScript, Bash, and more)
An AI mentor, ARIA, for the "I'm stuck and about to quit" moments
Free

It just launched on the iOS App Store. I'm a solo builder, so I'm sharing it here partly to show what I made and partly to ask: does visible, cumulative progress actually keep you going when you're learning — or is it a gimmick? I genuinely want both takes.

If you want to try it: https://apps.apple.com/app/id6761598036

Best gamified coding platforms for bootcamps in 2026

Mike Clarke — Wed, 06 May 2026 06:00:27 +0000

undefined

Originally published on CodeCityApp