DEV Community: cursora

Six bugs I found auditing code I wrote yesterday

cursora — Fri, 31 Jul 2026 13:53:13 +0000

Last week I shipped a lot: eleven new exercise types on Monday and Tuesday, a SQL exercise type running a throwaway Postgres per attempt on Wednesday. On Thursday I stopped adding things and spent the day attacking what I'd just built.

Six bugs. Every one of them belongs to a class that generalizes, so here they are with names.

1. Gating the answer, but not the field that contains the answer

Our auto-graded exercises have an author-supplied explanation field. The tests for it contain strings like "6*7=42". It is, in practice, the answer written out in prose.

The raw answer keys — expectedAnswer, correctCells, correctOrder — were all correctly gated behind the author's showCorrectAnswerOnFailure setting. In the same services. Written at the same time.

explanation was returned unconditionally. In eight step types. One wrong attempt, and the response handed over the answer — no probing, no cleverness, and the author's explicit "don't reveal the answer on failure" setting silently ignored.

The class: secondary fields that contain the secret. You will remember to protect the thing that is obviously the secret. The risk is the human-readable field sitting next to it — the explanation, the hint, the error message, the debug payload, the log line — that contains the same information in a different shape. When you gate something, grep for every field that could restate it.

2. Correctness overlays are answer keys

Same audit, a related one. Our matching exercise returned pairResults: a map of pairId → boolean telling the UI which pairs the student got right, so it can draw green and red.

Returned unconditionally, on every attempt.

That's not feedback, that's an oracle. Submit anything, read which pairs are true, flip the ones that are false, submit again. Two attempts to a perfect score without understanding the material.

The class: per-item correctness is equivalent to the key when items are independent. A single "you scored 3/8" is fine. "Which 3" is the answer key delivered in instalments. The same bug had already been fixed for the cell/position/indent variants in other step types — one shape was missed, and one is enough.

3. `@Body('field')` silently skips validation

This one is NestJS-specific and I'd bet real money it's in your codebase too.

// The DTO exists. @MaxLength(8000) is right there on it.
async submit(@Body('studentSql') studentSql: string) { ... }

ValidationPipe skips validation when the metatype is a primitive. String is a primitive. So the DTO class sits in the repo, fully annotated, imported nowhere that matters, and not one of its constraints runs on this path. Everything looks validated. Nothing is.

// Fix: take the whole body, typed as the DTO.
async submit(@Body() body: SubmitSqlChallengeDto) { ... }

Once I knew the shape, I grepped for it — and found six more controllers doing the same thing, some via @Body('field'), some via data: any, some with an inline object literal as the parameter type.

The class: validation that is present but not reachable. This is worse than no validation, because no validation is visible in review. A @MaxLength sitting on an unreachable DTO reads as a control to everyone who looks at it.

4. A session default is not a limit

Our SQL sandbox runs student SQL as a restricted role, created per attempt:

ALTER ROLE sql_challenge_student SET statement_timeout = '5s';

That is a session default. The student's own SQL can begin with SET statement_timeout = 0; and it is gone. The mechanism I was relying on to stop runaway queries could be switched off by the queries it was supposed to stop.

And the author-supplied setup.sql and verify.sql, which run as superuser, had no timeout at all. So a Pro-tier author could put pg_sleep() in a setup script and quietly DoS the shared sandbox container pool — on every verify and every submit, for every student in the course.

The fix moves the limit somewhere the workload can't reach it: every psql invocation wrapped in timeout N at the process level. (Detail for anyone copying this: BusyBox timeout, which is what you get in postgres:16-alpine, exits 143 on kill, not GNU's 124. If you only check for 124, your timeouts look like crashes.)

The class: limits enforced inside the thing being limited. If the constrained party can execute code in the same context as the constraint, it isn't a constraint. Put the ceiling in the layer above — a process timeout, a cgroup, a supervisor.

5. Your CSV export executes code on someone else's machine

Our gradebook export escaped CSV correctly by the usual definition: quotes doubled, fields with ", ; or newlines wrapped. Textbook.

It did nothing about a leading =, +, - or @, which Excel and Google Sheets interpret as the start of a formula.

Students control their own names. A student sets their display name to a HYPERLINK formula. The teacher exports the gradebook and opens it. The formula runs — on the teacher's machine, in the teacher's spreadsheet, with the teacher's data.

The fix is a one-liner (prefix such fields with an apostrophe), and the interesting part is how the bug survived: the identical issue had already been fixed in our attendance export, independently, by someone solving the same problem in a different file. Two implementations of "escape a CSV field", one hardened and one not.

The class: escaping for the wrong consumer. We escaped for the CSV parser. The attacker's target was the spreadsheet application that opens the CSV afterwards. Ask who ultimately interprets your output, not what format you're emitting. (Same audit, same class: instructor-controlled strings interpolated unescaped into reminder emails sent to every enrolled student. HTML has a consumer too.)

6. The endpoint that forgot it was the paid tier

The one I'd rather not write up, which is exactly why it's here.

Our SQL exercise editor has a preview endpoint so authors can test their setup script while writing an exercise. create() and update() both enforce the Pro-tier plan gate. preview() checked that you were logged in, and nothing else.

What preview does is run the submitted setupSql — as full Postgres superuser, before the restricted student role exists, because that's what setting up an exercise requires. Postgres superuser includes COPY ... TO/FROM PROGRAM: command execution inside the container.

So: any logged-in account, including a free one, could reach superuser SQL execution in the sandbox. The plan gate on the two obvious endpoints created a completely convincing illusion of a guarded feature.

The class: auxiliary endpoints inherit the feature's privileges but not its checks. Preview, dry-run, validate, test-connection, export-sample — the endpoints that exist so the main flow feels good, get written last, and get reviewed least. They usually reach exactly as deep as the endpoint they're previewing. Enumerate every route that touches a privileged capability, not every route that looks important.

What I actually take from this

Four of the six exist because a control was applied somewhere and not everywhere: the answer key gated but not the explanation, the cell overlay gated but not the pair overlay, the plan gate on create/update but not preview, CSV formulas neutralized in one export but not the other. The failure mode isn't ignorance of the rule. It's incomplete application of a rule everyone involved already knew.

Which suggests the audit question worth asking isn't "did we handle this?" It's "where else does this shape appear, and did we handle it there?" Every one of these was found by taking a known control and grepping for every place it should exist.

The other one: I audited this code the day after writing it, while I still remembered every decision — and still found six. The version of me that wrote it was certain it was fine.

A throwaway Postgres per attempt: running untrusted student SQL

cursora — Thu, 30 Jul 2026 13:54:20 +0000

The requirement

Students submit arbitrary SQL. It has to be safe. And it has to allow real DDL — because "design this schema and populate it" is most of what teaching databases consists of, and an exercise limited to SELECT against a fixed fixture teaches a fraction of the subject.

Two obvious designs, both rejected:

An in-process SQL engine in the backend. Fast, no containers. Also means evaluating untrusted input inside the application process — a shape that has burned this codebase before, in a different feature, with a real RCE as the outcome. Not again.

A shared teaching database with restricted grants. Cheap. Also means shared mutable state between students, and shared mutable state plus thirty people learning DELETE ends exactly one way.

What we built

One throwaway postgres:16-alpine container per attempt, executed through the same sandbox mechanism (epicbox) that already runs student Python, Java and Go.

Per-attempt sequence:

Start Postgres
Run the exercise author's setup.sql as superuser
CREATE a restricted role
Run the student's SQL as that role
Run the author's verification queries as superuser
Emit JSON on stdout, pg_ctl stop

Everything the student did dies with the container.

Making a database-per-attempt fast enough

The naive version — start a Postgres container, initdb, then use it — costs about ten seconds. That's the difference between a feature students use and one they avoid.

initdb is baked at image build time. The image ships with an initialized data directory; the container starts an already-initialized cluster. This is the single change that made the approach viable.

Durability is turned off. fsync, synchronous_commit, full_page_writes — all off. The entire state is discarded seconds later, so every guarantee Postgres offers about surviving a crash is pure cost here. This is one of the rare cases where turning off fsync is not reckless but obviously correct.

Unix socket only, no TCP. The sandbox runs with networking disabled, so there's nothing to listen for.

Resource floors have to be raised. Postgres forks helper processes, so limits tuned for a single-process interpreter fail immediately. We floor it at 384 MB and 64 PIDs.

The part I'd defend hardest: don't filter the SQL

We do not inspect the student's SQL. At all. No allowlist of statements, no regex for DROP, no parsing.

Instead, the student connects as a role created per attempt:

NOSUPERUSER NOCREATEDB NOCREATEROLE NOREPLICATION NOBYPASSRLS
CONNECTION LIMIT 5
statement_timeout = 5s
search_path = public

When a student tries CREATE ROLE or DROP DATABASE, PostgreSQL refuses them. Not our filter — the engine's own privilege system, which is the only authoritative answer to "is this connection allowed to do that".

Text-level filtering of a programming language is a losing game; there is always another spelling. That's true of JavaScript (this codebase learned it the hard way, with a bypassable regex allowlist over vm.runInContext) and it's true of SQL. The database already contains a complete, battle-tested authorization system. Use that one.

We verified it the boring way: wrote tests that attempt CREATE ROLE and DROP DATABASE and asserted the engine rejects them.

Two timeouts, because one doesn't cover both cases

statement_timeout = 5s on the student role kills a runaway student query. It does not protect you from a runaway setup.sql, because setup runs as superuser — and superuser can raise or ignore that setting.

So there's a second, outer limit: the sandbox's hard wall-clock kill at ~20 seconds, which doesn't care who you are or what you set. Two failure modes, two mechanisms, one of them outside anything the workload can influence.

If that sounds familiar, it's the same shape as enforcing sandbox session TTLs in two places — the inner mechanism does the graceful thing, the outer one exists because the inner one can be subverted or die.

Test it on real containers or don't claim it works

I want to be specific about this because it's the part that generalizes best.

Seven scenarios were run against live containers, not reasoned about: happy path, student syntax error, error in the author's setup, CREATE ROLE rejected by the engine, DROP DATABASE rejected by the engine, statement_timeout killing a hung student query, and the outer limit killing a hung setup.

That process found three bugs code review had not — the most instructive being that the sandbox resets /sandbox ownership to root on every file upload, which meant runtime-writable state had to move under a path baked into the image instead. There is no amount of reading the code that surfaces that.

For anything where the failure mode is "untrusted code does something you didn't anticipate", the test that counts is the one that actually runs it.

Honest limits

It's a container. This inherits whatever your container isolation is worth — for us, the same layer our other language executors run in, with no network.
setup.sql runs as superuser. That's a deliberate trust boundary: exercise authors are trusted, students aren't. If your authors aren't trusted, this design doesn't transfer.
A database engine per attempt costs real compute, which is why this sits on our paid tier. A shared instance with per-student schemas is dramatically cheaper; it's just a weaker isolation story.

Deterministic seeds beat question banks for per-student problem variants

cursora — Wed, 29 Jul 2026 18:10:14 +0000

The problem

You want every student to get a slightly different version of the same problem, so that comparing answers doesn't work.

The obvious approach is a question bank: write twenty variants, assign each student one, store which one they got. It works. It also means someone has to write twenty variants of every question, and you now have a per-student assignment table that has to stay consistent forever.

We did it differently, and the difference is one idea: generate the variant from a deterministic seed instead of storing it.

The design

The author writes one template — a prompt with parameters, and a formula for the answer. At request time, the server derives a seed:

const seed = computeRandomTaskSeed(userId, lessonId, stepIndex);
const { resolvedPrompt } = resolveRandomTaskProblem(rawProblem, seed);

Same three inputs, same seed, same variant — forever, with nothing persisted.

What falls out of it

Different students get different problems. The whole point, and it comes from userId being in the seed.

The same student always gets the same problem. This one matters more than it looks. The naive implementation — randomize per request — creates a re-roll attack: refresh until you get an instance with friendlier numbers. Students find this on day one. Because our seed contains no clock and no request nonce, refreshing produces a byte-identical question.

No storage, no migrations, no drift. There's no variant table to keep in sync, nothing to backfill when an author edits a template, and no possibility of "the question shown" and "the answer graded" disagreeing because a row went stale. The seed regenerates the same variant on demand, every time.

Author edits are instant. Change the template and every student's variant re-derives from it on the next page load. With a stored bank you'd be reconciling old assignments against a changed question.

The part that's a security decision, not a design decision

The client must never receive the template, the parameter set, or the answer formula. Resolve on the server, send only the resolved prompt:

randomTaskProblem = canManageLessonAsAuthor
  ? { ...rawRandomTaskProblem, resolvedPrompt }   // author is editing it
  : {
      resolvedPrompt,                              // student sees only their own variant
      points,
      tolerance,
      explanation,
      showCorrectAnswerOnFailure,
    };

It is genuinely tempting to ship the template and resolve client-side — it's less server work and the interaction feels snappier. It also puts the answer generator in the page source, which converts your randomization from an anti-copying measure into an inconvenience for students who don't open devtools.

Note the shape of the branch: the author gets the raw template because editing requires it. Role-based field selection at the boundary, not a single response shape that leaks to whoever asks.

What it costs

Writing a good parameterized template is harder than writing a good fixed question. The author has to reason about parameter ranges: does every value in this range keep the problem meaningful, or does some combination produce a degenerate case — a divisor of one, a negative quantity where the story doesn't allow it, an answer that happens to be zero?

A question bank is dumber and more predictable, and for some material that's the right trade. This isn't strictly better; it's better when the question has a parametric shape at all.

The generalizable bit

Derive instead of store, when the derivation is deterministic and cheap. Anything you store is something that can go stale, needs migration, and can disagree with reality. Anything you can regenerate from stable inputs can't.

The trap is that the same property that makes it good — same inputs, same output — is exactly what you break the moment you add a timestamp or a random nonce to the seed "to make it more random". If you take one thing from this: whatever goes into that seed is the contract, and adding to it later is a breaking change for every student mid-course.

Four things that bit us building marketplace payouts on Stripe Connect

cursora — Tue, 28 Jul 2026 13:12:34 +0000

The shape of the thing

We added marketplace payouts to our education platform: course authors connect a Stripe account, learners buy courses, the platform takes a cut and the author gets the rest. Standard Stripe Connect territory.

The overall design is a destination charge — the platform stays merchant of record, takes an application_fee_amount, and the remainder is transferred to the author's connected account:

transfer_data: { destination: connectedAccountId },
application_fee_amount: applicationFeeAmountGrosze,

That part took an afternoon. Here are the four things that didn't.

1. The fee base is the discounted amount, and you have to say so out loud

Authors can issue promo codes. So for any given sale there are two numbers: the list price and what the buyer actually paid. Charging your platform fee against the list price when the author discounted the sale means the author eats the entire discount plus a fee calculated on money nobody paid — and at a steep enough discount, the fee can exceed what they netted.

const unitAmountGrosze = Math.round(discountedAmountPln * 100);
const applicationFeeAmountGrosze = Math.round(
  discountedAmountPln * PLATFORM_FEE_RATE * 100,
);

Both derive from the same discountedAmountPln. The rule worth writing into a comment (we did) is that there is exactly one authoritative amount per sale, and every downstream number is computed from it. Two amounts floating around means eventually one of them gets used in the wrong place, and that's a bug your authors report as theft.

2. A 100%-off code cannot go through Checkout at all

Stripe Checkout requires unit_amount > 0. A full-discount promo code produces a total of zero, and there is no "free Checkout session" to create.

You cannot fix this at the Stripe layer. It has to be a branch much earlier: if the discounted total is zero, skip payment entirely and grant the purchase directly, recording it with the same purchase record shape and a zero platform fee so downstream reporting doesn't have a hole in it.

The lesson generalizes past Stripe: the free path is a different code path, not a special case of the paid one. If you discover this after building the paid path, you will be tempted to fake a zero-amount payment to keep one flow. Don't — you'll be writing "if amount == 0 skip this" in five more places by the end.

3. PaymentIntent cannot see the Session's metadata

We reconcile purchases from webhooks. Success comes in on checkout.session.completed, failure on payment_intent.payment_failed. Naturally you attach your correlation IDs to the Checkout Session's metadata and read them in the handler.

That works for the success case and silently fails for the failure case: a PaymentIntent has its own metadata and does not inherit the Session's. The failure webhook arrives carrying nothing you can join on, and you discover this when you actually need to debug a failed payment.

The fix is to write the metadata twice — once on the session, once via payment_intent_data.metadata:

metadata,                                  // read by checkout.session.completed
payment_intent_data: { metadata },         // read by payment_intent.payment_failed

Not elegant. Necessary. Worth knowing before rather than after.

4. `default: null` on a sparse unique index is a trap

Unrelated to payments, same release, too good not to include. Invite-only courses have an optional invite code with a sparse unique index — unique when present, absent otherwise. The schema declared it as:

@Prop({ default: null })
inviteCode?: string | null;

sparse skips documents where the field is missing. It does not skip documents where the field is present and set to null. With default: null, every new course got an explicitly-stored inviteCode: null, so the second course ever created collided with the first on E11000 duplicate key.

The fix is to remove the default entirely and let the field be absent. Generally: null is a value, undefined/absent is not, and every "optional unique field" bug I've seen comes from treating those as the same thing.

None of these are exotic. All four cost real debugging time, and three of them only show up on the failure or edge path — the one you exercise last and in production first.

vm.runInContext is not a sandbox: how we replaced eval with a parser

cursora — Mon, 27 Jul 2026 04:22:39 +0000

The feature

One of our challenge types lets a learner write a MongoDB query and run it against a seeded dataset. The obvious implementation, and the one we shipped first, is the one you're probably picturing: take the query string, run it in Node's vm module with a db object in the context, return the result.

vm.runInContext(userQuery, contextWithDb);

To keep it read-only, there was an allowlist: a regex over the query string checking that the methods called were things like find, aggregate, countDocuments.

Both halves of that are wrong, and they're wrong in ways worth spelling out, because this exact shape shows up in a lot of "let users write a little expression" features.

Why the regex allowlist fails

A regex like \.(\w+)\( sees method calls written with dot notation. JavaScript does not require dot notation.

db.users.find({})["constructor"]["constructor"]("return process")()

No .method( for the regex to object to, and constructor.constructor is Function — which builds a new function from a string. Once you can construct a function, the allowlist is decoration.

Any allowlist that operates on the text of a program rather than its structure has this class of hole. There is always another way to spell the same operation.

Why `vm` doesn't save you

The natural response is "fine, but it's running in a vm context, so it's contained." It isn't. Node's own documentation is explicit that the vm module is not a security mechanism — it isolates the global object, not the process. Escapes via constructor chains on objects passed into the context are well documented, and in our case an object had to be passed in: the db handle the whole feature exists to expose.

And that db handle was a live connection to the production database. So the ceiling on this bug was not "a learner reads another collection". It was arbitrary code execution in the backend process, holding a production database connection.

We found this in an internal audit in June, fixed it, and nothing indicates it was ever exercised in the wild — but "we found it before anyone else did" is luck, not architecture, and the architecture was the actual problem.

The fix: parse, don't evaluate

The rewrite executes no learner code at all. Not in a sandbox, not in a context, not anywhere.

The query string is parsed into an AST with acorn, and the AST is then interpreted against a strict allowlist of node types: literals, arrays, objects, a couple of permitted constructor calls (ObjectId(...), ISODate(...)), and a call chain matching db.<collection>.<method>(...). Anything else — a member expression that isn't in the shape we expect, an identifier we don't know, a function expression — is a rejection, not a fallback.

PRIMARY_READ_METHODS = find, findOne, aggregate, countDocuments, distinct
CHAIN_METHODS        = sort, limit, skip, project
WRITE_METHODS        = insertOne, updateOne, deleteMany, ... (author setup scripts only)

The structural difference that matters: ["constructor"]["constructor"] is not a mysterious edge case to this design. It's a MemberExpression with a computed key, which isn't on the allowlist, so it's rejected — the same way any other unrecognized node is. The security property comes from the shape of what's permitted, not from enumerating what's forbidden.

Server-side JS operators ($where, $function, $accumulator) and cross-collection writes ($out, $merge) are separately blocked, because those move execution back to mongod where our parser has no say.

What generalizes

"Sandboxed eval" is usually a contradiction. If your threat model includes the user being hostile, the question isn't which sandbox — it's whether you can avoid evaluating their code at all. For anything expression-shaped, you usually can.
Never allowlist over source text. Allowlist over parsed structure. Text has infinite spellings; an AST has a finite node vocabulary.
Deny by default at the node level. "Unknown construct → reject" is a one-line invariant. "Known-bad construct → reject" is a list you will be maintaining against attackers forever.
Count what's reachable from inside, not just what's exposed. The regex was guarding the method names. The actual exposure was the live db handle sitting in scope next to them.

If you have a "users write a small expression" feature running through vm, eval, or new Function — that's the one. Go look at it.

Enforcing subscription plan limits in NestJS without scattering `if (plan === 'PRO')` everywhere

cursora — Sat, 25 Jul 2026 07:56:25 +0000

The problem with the obvious approach

The first version of plan enforcement in any product looks the same: a controller method starts with a check.

if (user.plan === 'BASIC' && courseCount >= 3) {
  throw new ForbiddenException('Upgrade to create more courses');
}

It works, for exactly as long as there is one such rule. Ours has several — a cap on total courses, a separate cap on how many of those may be paid, a cap on standalone lessons — and each applies at a different endpoint. Copy that check into six controllers and you have six places to update when a limit changes, and one of them will be missed.

What we did instead: a decorator that names the action

Enforcement moved into a guard, and controllers only declare which limited action they perform:

@Post()
@EnforcePlanLimit('CREATE_COURSE')
async createCourse(@Body() dto: CreateCourseDto) { ... }

The decorator is just metadata plus the guard, composed:

export const EnforcePlanLimit = (action: PlanLimitAction) =>
  applyDecorators(
    SetMetadata(PLAN_LIMIT_ACTION_KEY, action),
    UseGuards(PlanLimitGuard),
  );

The guard reads that metadata with Reflector, resolves the user, and delegates to a single service that owns every limit rule:

const action = this.reflector.getAllAndOverride<PlanLimitAction | 'BYPASS'>(
  PLAN_LIMIT_ACTION_KEY,
  [context.getHandler(), context.getClass()],
);
if (!action || action === 'BYPASS') return true;

await this.planLimitsService.enforceOrThrow(userId, action);

Now a limit change is a one-file change. The controllers never learn the numbers.

The part that isn't in the tutorials: conditional enforcement

The interesting cases are the ones where the same endpoint is sometimes limited and sometimes not.

Marking a course as paid is limited — but the endpoint that does it is a general update endpoint that also handles a dozen unlimited edits. Blocking it wholesale would mean free-tier users can't rename their own courses. So the guard inspects the request before deciding to enforce at all:

private shouldEnforce(action: PlanLimitAction, request: Request): boolean {
  if (action === 'SET_COURSE_PAID') {
    const isPaid = request.body?.isPaid;
    return isPaid === true || isPaid === 'true';
  }
  ...
}

Same story for standalone lessons: a lesson created inside a course doesn't count against the standalone-lesson cap, and the only way to tell them apart is whether courseId is present in the body. That check lives in the guard too, next to the rule it belongs to, rather than being smeared across the lesson service.

The === 'true' string comparison is not an accident either — multipart form bodies deliver booleans as strings, and a limit that silently stops applying for one content type is worse than no limit.

An explicit escape hatch beats an implicit one

Some routes must never be limited — admin tooling, internal migrations. Rather than let those quietly work because nobody remembered to add the decorator, there's an explicit opt-out that reads as a deliberate decision in review:

export const BypassPlanLimit = () => SetMetadata(PLAN_LIMIT_ACTION_KEY, 'BYPASS');

"No decorator" and "deliberately unlimited" look identical in a diff otherwise. They shouldn't.

What this bought us

When we published our pricing publicly this week — free tier: 3 courses, free-only; paid tiers lifting the course, paid-course and lesson caps — the numbers in the marketing copy came from one service, and changing them meant editing one file. That's the actual payoff: the pricing page and the enforcement can't drift apart, because there's only one place that knows.

Curious how others handle the conditional case — enforcement that depends on the request body, not just the route. Guard, interceptor, or push it down into the service? Interested in arguments for the other two.

Grading a scanned, handwritten answer sheet with OCR: harder than it sounds

cursora — Thu, 23 Jul 2026 18:55:45 +0000

The feature that sounded simple in the spec

"Let teachers scan a paper test and have it auto-graded." That was the one-line spec for a feature we shipp
ed in Cursora Assess, our grading tool. It sounded like a weekend project. It was not.

Why printed multiple-choice OCR is the easy 80%

If every test were a single canonical layout with clean printed bubbles, this is a solved problem -- that's
exactly what commercial scantron hardware has done since the 1970s. Our first version handled that fine: g
enerate a test as a PDF with a fixed answer-grid layout, print it, scan it back, and a well-tuned OCR/bubbl
e-detection pass gets you close to 100% accuracy.

Where it actually gets hard

Two things blow up the easy version:

Randomized variants. To make cheating-by-glancing-at-your-neighbor harder, Assess generates multiple sh
uffled variants of the same test -- different question order, different answer order per question. That mea
ns the grading pass can't assume a fixed answer key position; it has to read a variant identifier off the s
heet first, then grade against the matching key, not just "the" key.

Real-world scans, not clean lab conditions. Teachers photograph these with a phone, at an angle, someti
mes in bad lighting, sometimes slightly creased. A bubble that's 90% filled versus 40% filled versus "start
ed to fill then scribbled out" all need different handling, and a naive brightness threshold falls over imm
ediately once the photo isn't perfectly lit.

What actually worked

Perspective correction before anything else -- detect the page's corner markers and de-skew/de-warp the i mage so the grid math downstream can assume a roughly rectangular, aligned sheet
Per-bubble fill-ratio scoring rather than a single global threshold, so lighting gradients across one pho to don't tank accuracy on one side of the page
Variant ID read as its own first-class OCR step, gating which answer key the rest of the pipeline grades against
A confidence score per answer, not just a binary read -- low-confidence bubbles get flagged for the teach er to eyeball rather than silently guessed

The honest caveat

This isn't magic, and we don't pretend it is: genuinely ambiguous marks (half-erased, two bubbles filled) s
till get flagged for a human to resolve rather than auto-resolved with a coin flip. Grading in seconds inst
ead of an evening doesn't require 100% unattended accuracy -- it requires being right when it's confident a
nd honest when it's not.

If you've built anything in this space (form OCR, scantron-alternative pipelines, handwriting recognition)
I'd like to compare notes -- drop it in the comments.

A real Docker exercise from our course platform (try it yourself)

cursora — Wed, 22 Jul 2026 19:06:23 +0000

Skip the pitch, here's the exercise

Rather than describe our coding education platform in the abst
ract, I want to show one actual exercise, word for word (trans
lated -- the course itself is Polish-first), from the "Cloud T
echnologies" course. Try it yourself if you want; it only need
s Docker.

The scenario

You are a junior DevOps engineer at a tech company. Your tea
m lead has asked you to start a simple HTTP server in a Docker
container for a test environment. The server must run with a
specific configuration -- verify it using Docker's diagnostic
tools.

Start a container named web_server using the python:3.11- slim image, in detached mode. The container should run Python
's built-in HTTP server on port 8000 (command: python3 -m htt p.server 8000).

Configuration requirements:

Container port 8000 must be accessible on host port 8001

Environment variable APP_ENV set to production

If you want to try it cold before reading on: that's the whole
prompt. Here's a solution:

docker run -d \
  --name web_server \
  -p 8001:8000 \
  -e APP_ENV=production \
  python:3.11-slim \
  python3 -m http.server 8000

docker ps
docker inspect web_server

The exercise doesn't stop at "make it run" -- the follow-up as
ks you to explain what each field in docker inspect's output
actually means (State, NetworkSettings.Ports, Config.Env, etc.), which is the part that actually separates "I copied
a command" from "I understand what's happening."

What's running underneath it

This isn't a fake terminal with pre-recorded output. The actua
l sandbox config for this exercise:

Base image: alpine:3.20
CPU limit: 0.5 cores
Execution mode: isolated VM worker
Network access: none by default (no outbound calls unless an exercise specifically opens it)
Optional bash setup script runs before the student's first c ommand

Why I'm posting this instead of a feature list

Screenshots of a dashboard don't tell you anything about wheth
er the actual course content is any good. One real exercise, r
eproduced exactly, does. This is one lesson out of many in one
course out of 27 currently in the catalog at cursora.org. Happy to answer questions about the sandbo
x architecture or the exercise design specifically.

I stopped watching coding tutorials. Here's what I do instead.

cursora — Tue, 21 Jul 2026 19:21:19 +0000

The tutorial graveyard

Be honest with yourself for a second: how many "Complete Python Course" or "Learn Docker in 2 Hours" videos do you have sitting half-watched in a browser tab or a bookmarks folder right now? For me it used to be a lot. I'd watch someone type, nod along, feel like I understood it, and then sit down to actually build something and realize I couldn't reproduce a single line without the video paused next to me.

That's not a discipline problem. Watching someone perform a skill and performing it yourself are genuinely different cognitive tasks. Tutorials are great at the first one and mostly useless at the second.

What changed for me

I started deliberately picking learning resources where I couldn't just watch -- where the platform forced me to actually write and run code as part of the lesson, not as an optional "now try it yourself" afterthought tacked onto the end of a video. cursora.org (the platform I've been using, full disclosure I also work on the marketing side of it) structures every hands-on course this way: the lesson is a real, isolated sandbox -- a real container, real CPU/memory limits, real command output -- not a video with a code snippet next to it.

The difference sounds small until you notice how much it changes your behavior. You can't half-pay-attention to an exercise you have to actually solve. You can't "I'll rewatch that part later" your way past a Docker command that just failed in front of you.

What it actually looks like

27 courses right now, spanning web dev, backend, DevOps and more
Every coding exercise runs in an isolated sandbox, not a simulated terminal
The catalog is browsable for free, no signup, so you can see exactly what a lesson looks like before committing
A completion certificate at the end, if that matters for your situation

The actual point of this post

I'm not going to pretend one platform is a silver bullet -- plenty of people learn fine from videos, and plenty of hands-on platforms exist. But if you recognize yourself in the first paragraph of this post, the fix probably isn't "watch better tutorials." It's picking something that doesn't let you get away with just watching. Worth a look: cursora.org

What a coding education platform actually looks like after 6 months of building (screenshots, no mockups)

cursora — Mon, 20 Jul 2026 19:29:34 +0000

Building in public, screenshots included

I work on cursora, a coding education platform. Landing pages tend to oversell — so instead of another feature list, here's what the product actually looks like right now, straight from the running app.

The catalog

27 published courses live today, spanning web, backend, DevOps and more. No "coming soon" placeholders in the grid — these are courses students can start immediately.

The instructor editor

Courses are built section by section, lesson by lesson, with a live "readiness" score so instructors can see how close a course is to publish-ready before it goes live. Our own DevOps course is sitting at 90% readiness as I write this.

The sandbox

This is the part I actually care about explaining. Coding exercises don't run in a fake terminal — each one spins up an isolated container with:

A real base image (alpine:3.20 for this exercise)
Explicit CPU limits (0.5 cores here) and a memory ceiling per container
A configurable execution mode — VM-isolated workers for the heavier exercises
Network access set to none by default — no external calls in or out
An optional setup script (plain bash) that provisions the environment before the student's first command

Students run real commands — docker version, docker info, whatever the exercise calls for — against a real environment, not a canned output.

Cursora Assess

For instructors who still want traditional graded tests alongside the hands-on exercises, there's Cursora Assess: generate printable/online test variants, auto-grade scanned answer sheets via OCR, and get a stats/report view per group.

Where it's at

669 learners, 27 courses, and a platform that's still very much being built in the open. If you're curious what practical, hands-on coding education infrastructure looks like under the hood, take a look: cursora.org. Happy to answer questions about the sandbox architecture specifically — that's the part I'd most like feedback on.

I Built a Platform Where Anyone Can Publish a Coding Course Today — No Approval Process

cursora — Mon, 20 Jul 2026 05:36:36 +0000

Why I'm writing this

I work on cursora, a coding education platform. We're trying to grow the course catalog, and instead of a polished landing page pitch, I'd rather explain honestly what it actually is — and ask this community to poke holes in it.

The premise

Most "become an instructor" flows on ed-tech platforms involve an application, a review queue, and a wait. Ours doesn't. If you're logged in, you can start building a course right now at cursora.org/my/teaching — no approval gate.

What you actually get

A content editor with full control over your material — text, images, video, code
Real code execution sandboxes for 13 languages (Python, JS/TS, Go, Rust, Java, C/C++, and more)
Challenge types beyond multiple-choice: Linux/CLI challenges, MongoDB challenges, CSS challenges, and full project-based tasks
Cursora Assess, a proper tool for testing and grading students — not just a quiz widget
Full control over your course's price and content

What's honestly still missing

I'm not going to oversell this: we don't have a slick, fully worked-out payout/commission system yet. That part of the platform is still evolving. If your main motivation is monetizing a course today, it's fair to wait. If you like teaching and want a place to publish something more interactive than a slide deck or a YouTube playlist, it's worth a look.

Why hands-on matters to us

The platform's whole premise is that people learn by doing, not by watching. So the course-authoring tools are built around that: real sandboxes instead of video-only lessons, real challenge types instead of just quizzes.

If you want to try it

Start here: cursora.org/my/teaching. No form, no waiting on someone's approval queue. Happy to answer hard questions in the comments — including "why would I use this over [X]."

Your Team Has an Internal Onboarding Doc for Juniors? That's Already 80% of a Course

cursora — Sat, 18 Jul 2026 06:25:10 +0000

If you've ever onboarded a junior on your team, you probably have a doc — or three — sitting in Confluence, Notion, or some private repo, explaining how your team does code review, how to set up the dev environment, what mistakes to avoid, what your commit convention looks like. That knowledge lives in an internal wiki and never leaves it.

That's exactly the kind of material that turns into a course.

The gap between "internal doc" and "course" is smaller than it looks:

A text doc → a lesson with tables, code blocks, and Mermaid diagrams if you're explaining architecture or a data flow.
"Try setting this up and let me know how it goes" → a code challenge that actually checks whether the student can do it, run in a sandbox in one of 13 supported languages — no more "done ✅" on Slack, the result gets checked automatically.
Your three most-repeated pieces of code review feedback → a standalone lesson on the mistakes you always see from new hires.

You don't need to start from zero and invent a curriculum. The material already exists — it just needs to come out of the internal wiki, get organized, and turn into something someone outside the company can work through too.

Bonus: next time you hire a junior, you can send a link instead of explaining the same thing live all over again.

Set up an instructor account on cursora.org — see how much of what you already know and already have written down turns into a first lesson in under an hour.