DEV Community: New World Coder

Why I built the compliance engine in Go

New World Coder — Tue, 04 Aug 2026 14:18:01 +0000

I did not pick Go because it is fashionable. I picked it because the product has to land in someone else's CI without a negotiation about runtimes.

RiskLine's job is: read a YAML/JSON system description, evaluate a versioned ruleset, print a tier. That has to work as a pre-commit hook, a GitHub Action step, and a one-liner go install. Node and Python are fine languages. They are worse at "here is a single static binary, trust it in your pipeline."

What "CI-friendly" actually means

No interpreter version matrix for adopters
Cross-compile for linux/mac/windows from one tree
Cold start fast enough that nobody disables the hook
Offline by default — a compliance CLI that phones home is a trust problem

That distribution model is the same reason people reach for Open Policy Agent, Trivy, and Terraform-shaped tools. RiskLine is not built on OPA/Rego in v0.1 — the rule surface is small enough that embedded JSON + Go matching was enough — but the packaging lesson is the same. If the ruleset grows into something Rego expresses more clearly, that is a later decision, not a day-one dependency.

Embeddability

pkg/engine does not import net/http or CLI packages. The API server and the CLI are thin wrappers. That is what makes "SDK" real instead of "HTTP client with feelings." If you want classification inside another Go service, you call engine.Classify, not a localhost port.

Tradeoffs I am accepting

Go JSON tags and OpenAPI can drift if you are careless — hence the contract being a checked-in YAML file and a (still too weak) CI smoke test. Help wanted on making that a real schema validation step: issue #4.

Also: writing rules in JSON conditions is less expressive than Rego. For prohibited flags and a handful of Annex III heuristics, it has been fine. I will revisit when the ruleset stops being fine.

Try the binary

go install github.com/new-world-coder/riskline/cmd/riskline-cli@v0.1.0-alpha
riskline-cli --json path/to/system.yaml

Source: new-world-coder/riskline.

An open JSON schema for AI system risk classification

New World Coder — Tue, 04 Aug 2026 14:17:58 +0000

The useful part of RiskLine is not the binary. It is the contract.

Everything — CLI table output, POST /v1/classify, future generated clients — hangs off api/openapi.yaml. If the handler and the doc disagree, that is a bug, not a documentation problem.

Request: describe the system, don't upload your codebase

{
  "name": "Hiring Assist",
  "purpose": "Screen job applicants and rank candidates for interview",
  "data_types": ["personal_data", "employment_data"],
  "deployment_context": "saas_b2b",
  "autonomy_level": "decision_support",
  "affected_population": "job_applicants",
  "geographic_scope": "eu"
}

Enums over free-text for the structural fields. Purpose stays free text because real systems do not fit a taxonomy on day one — and because keyword heuristics need something to chew on. Flags like social_scoring and real_time_remote_biometric_id exist for Article 5 cases where "infer from prose" is a bad idea.

Response: tier is not enough

A label without a clause reference is how tools become shelfware. Required fields on every success response:

Field	Why it is mandatory
`risk_tier`	The thing you came for
`ruleset_version`	Regulations move; "we said high-risk in 2024" is useless without the ruleset id
`last_updated`	Same — perishable mappings
`matched_rules[]`	Which article/annex fired, paraphrased
`rationale`	Plain-language why
`recommended_controls`	Next engineering actions, not a policy essay
`disclaimer`	Advisory tool, not legal advice — tested so refactors cannot drop it

judgment_calls is optional but important. When the ruleset made an interpretation the Act text does not fully decide, we say so in the payload instead of burying it in a blog post.

What I want feedback on

Are the request enums too coarse for your inventory format?
Should geographic_scope: non_eu short-circuit differently, or stay "still classify, human decides applicability"?
Is recommended_controls useful, or should it move to a separate optional profile?

Open a GitHub issue. Schema feedback is a contribution, not noise — especially ruleset updates and misclassifications.

Repo: github.com/new-world-coder/riskline.

How we classify AI systems under the EU AI Act

New World Coder — Tue, 04 Aug 2026 14:16:15 +0000

I built RiskLine because most "AI governance" tooling wants a portal login before it will tell you anything useful. I needed something that runs in CI, prints a tier, and shows which article fired — without calling a model to invent a legal opinion.

RiskLine is a small Go CLI/API over a versioned JSON ruleset. You describe a system; it returns prohibited / high_risk / limited_risk / minimal_risk plus clause refs, a rationale, recommended controls, and a disclaimer. Advisory only. Not legal advice.

Below are three fixtures from the repo (testdata/scenarios/) and the actual CLI output on my machine against ruleset eu-ai-act-2024-v0.1.0.

1. Prohibited — social scoring

name: Citizen Score
purpose: Score citizens based on social behaviour and personal characteristics for access to public services
data_types: [personal_data]
deployment_context: public_authority
autonomy_level: automated_decision
affected_population: general_public
social_scoring: true

Risk tier:        prohibited
Matched rules
prohibited-social-scoring  prohibited  Article 5(1)(c)

This one is boring on purpose. If the input asserts social scoring, Article 5(1)(c) wins. The interesting work is making sure higher-severity tiers always beat lower ones when multiple rules match — a law-enforcement biometric ID case should not get "downgraded" to high-risk because Annex III also fires.

2. High-risk — recruiting screener

name: Hiring Assist
purpose: Screen job applicants and rank candidates for interview
data_types: [personal_data, employment_data]
deployment_context: saas_b2b
autonomy_level: decision_support
affected_population: job_applicants

Risk tier:        high_risk
Matched rules
high-risk-recruitment  high_risk  Annex III (4)(a)

Annex III (4)(a) is the recruitment/selection use-case list. Matching is partly keyword/population heuristics. That is a judgment call, and the response says so:

Matching on purpose keywords or job_applicants population is a pragmatic proxy; borderline HR analytics that only aggregate headcount may be over-classified…

If you have a real HR analytics system that got over-classified, that is exactly what the misclassification report template is for. I am using those issues as the validation loop instead of pretending I finished twenty customer interviews first.

3. Limited-risk — support chatbot

name: Support Bot
purpose: Customer support chatbot for product questions
…
autonomy_level: content_generation

Risk tier:        limited_risk
Matched rules
limited-risk-chatbot-transparency  limited_risk  Article 50(1)

Art. 50 is wider than chatbots. The v0.1 rule requires both an interactive autonomy level and chatbot-ish purpose keywords, which probably under-detects some interactive systems. That uncertainty is intentional and logged on the rule. I would rather ship a narrow, tested heuristic than a confident wrong net.

The boundary case I am least sure about

Creditworthiness vs fraud detection.

Annex III (5)(b) treats credit scoring of natural persons as high-risk, with a fraud-detection carve-out in the Act. RiskLine does not auto-infer that carve-out from free text. A system whose purpose says "fraud" but still carries financial_credit_data can still land high-risk and emit a judgment-call note.

I am not confident we have the right product behaviour here yet. If you have shipped lending + fraud models under the Act and think the heuristic is wrong, open a misclassification issue with the input you used. That report is more useful to me than another star.

Try it

go install github.com/new-world-coder/riskline/cmd/riskline-cli@v0.1.0-alpha
riskline-cli testdata/scenarios/high-risk-hiring.yaml

Schema/contract: api/openapi.yaml. Repo: new-world-coder/riskline.

## 🧅 Inside Tor: A Simplified Look at Its Architecture and Code Organization

New World Coder — Tue, 16 Sep 2025 08:37:19 +0000

Tor (The Onion Router) is best known for enabling anonymous browsing, but under the hood, it’s a beautifully layered system of networking, cryptography, and client-server orchestration.
If you’ve ever peeked at Tor’s codebase, it might feel overwhelming — so let’s break it down in a way that maps directly to what you experience as a user.

🔎 How the Codebase Maps to Features

Tor’s repository can be thought of in three big layers:

UI / Browsing Experience

Not in Tor’s core repo itself (Tor is a daemon, not a browser).
The Tor Browser (a separate project) integrates Tor as its backend.
Features like “Connect to Tor” or “New Identity” are user-facing but rely on Tor’s core services.

Core Networking (The Heart of Tor)

src/core/or/ → Onion routing logic, circuits, relays.
src/core/mainloop/ → Event loop, scheduling, async I/O.
src/feature/hs/ → Hidden services (now called Onion Services).
src/feature/control/ → Controller protocol (for Tor Browser & apps to talk to Tor).

Under-the-Hood Connectors & Utilities

src/lib/crypt_ops/ → Encryption, key exchange, crypto primitives.
src/lib/net/ → Low-level socket and connection management.
src/lib/log/ → Logging & diagnostics.
src/test/ → Unit & integration tests.

Think of it as: Tor Browser asks → Tor Core builds onion routes → Networking + Crypto libraries do the heavy lifting.

📊 Sequence: How a Webpage Request Works Over Tor

Here’s a simplified flow of what happens when you type a URL in the Tor Browser:

sequenceDiagram
    participant User as User (Tor Browser)
    participant TorClient as Tor Client (Daemon)
    participant Entry as Entry Node
    participant Middle as Middle Node
    participant Exit as Exit Node
    participant Server as Destination Server

    User->>TorClient: Request webpage
    TorClient->>Entry: Build encrypted circuit
    TorClient->>Middle: Extend circuit
    TorClient->>Exit: Extend circuit (3 hops total)
    User->>TorClient: HTTP(S) request
    TorClient->>Exit: Forward encrypted request
    Exit->>Server: Plain HTTP(S) request
    Server->>Exit: Response
    Exit->>TorClient: Encrypted response
    TorClient->>User: Decrypted webpage

🖥️ Tor System Architecture

Here’s how Tor’s main components connect — with onion encryption layers visualized across the hops:

flowchart LR
subgraph UserSide[User Side]
Browser[Tor Browser]
Client[Tor Client (Daemon)]
end

subgraph TorNetwork[Tor Network]

    Entry[Entry Node\n(Encryption Layer 3)]

    Middle[Middle Node\n(Encryption Layer 2)]

    Exit[Exit Node\n(Encryption Layer 1)]

end

subgraph Services[Services]

    Hidden[Hidden Service (.onion)]

    Server[Regular Destination Server]

end

Browser -->|SOCKS Request| Client

Client -->|Circuit Build| Entry

Entry --> Middle --> Exit

Exit --> Server

Client --> Hidden

Hidden --> Client

🥑 Side-by-Side Comparison: User vs Codebase

User’s Perspective	What’s Happening in the Code
“I click a link in Tor Browser.”	Tor Browser issues a SOCKS request to the Tor client (`src/feature/control/`).
“Connecting to Tor network…”	Client bootstraps by contacting directory authorities (`src/core/or/directory.c`).
“Building secure connection…”	Multi-hop circuit built (`src/core/or/circuitbuild.c`).
“Page loads via Tor.”	Data onion-wrapped & relayed through entry → middle → exit (`src/core/or/relay.c`).
“I can access a .onion site.”	Hidden service rendezvous (`src/feature/hs/`).
“Tor keeps running silently.”	Event loop keeps sockets + circuits alive (`src/core/mainloop/`).

🎯 Key Takeaways

Tor’s core repo is not a browser — it’s the routing engine.
The code is layered: control interface, onion routing logic, crypto & networking utilities.
The user’s “simple” experience of clicking a link actually triggers a sophisticated chain of circuit building, encryption, and relay coordination.
Sequence diagrams help bridge the gap between user actions and what the code is doing.

✍️ If you’re curious, explore the Tor GitLab repo — just start from src/core/or/ to see the onion routing logic in action.

Would you like me to also add a system architecture diagram (Mermaid flowchart) showing Tor’s main components (browser ↔ tor client ↔ relays ↔ hidden services), so your Dev.to readers get a visual overview too?

🚨 Developers: It's Time to Wake Up to the CDE Upskilling Challenge! 🚨

New World Coder — Thu, 11 Sep 2025 13:34:17 +0000

Cloud Development Environments (CDEs) are changing the way real software teams build, collaborate, and ship code. If you’re still coding only on local machines, you’re already behind the curve! Here’s why you need to upskill NOW:

⚡ Speed & Consistency: Spin up fully-configured, production-like dev setups in seconds. No more "it works on my machine" drama!

🔒 Security: Code and data stay in YOUR cloud—not scattered across developer laptops.

🤖 AI-Native Workflows: CDEs like Coder seamlessly run AI coding agents or LLMs in secure, isolated workspaces. Scale your automation without the risk.

🌍 Flexibility: Self-host anywhere—your cloud, your rules. Hook into ANY Git provider, leverage templates, and even run your favorite IDE in the browser or on desktop.

👩‍💻 Future-Proof Skills: CDE adoption is exploding. Upskilling here makes you massively more valuable in projects that demand scale, compliance, and remote-ready agility.

Ready to see what the leaders are already doing? Start with the official CDE Buyer's Guide PDF:
👉 Download & Level Up Here

[Level Up] Enterprise Buyer's Guide to CDEs

resources.coder.com

Don't get left behind. Master CDE and future-proof your dev career. 🚀 #clouddevelopment #upskilling #devops #remotework #AIAgents

🚨 Warning for Anyone Using AI-Native Browsers Like Comet 🚨

New World Coder — Mon, 08 Sep 2025 12:35:15 +0000

Recently, while experimenting with Comet Browser’s AI automation features, I encountered a situation that made me pause:

👉 I asked Comet to open a conversation on a job-matching platform, read the spec, and draft a reply.
👉 I reviewed and sent the reply myself (with “never send without consent” enabled).
👉 But when I logged back into the platform later via Chrome, the entire conversation thread was missing.

This raised an important concern: AI-powered browsers can directly interact with sensitive web data in ways that traditional browsers never did.

⚠️ That means:

An AI agent could unintentionally archive, delete, or move data inside a web app.

Platform sessions may behave differently across Comet vs Chrome.

Critical job applications, client conversations, or project threads could get lost.

🔒 My takeaway:
Comet is powerful and exciting, but when dealing with sensitive information (like client messages, job applications, or financial data), double-check before letting AI agents interact on your behalf.

These tools are game-changers—but they also demand extra caution.

Have you faced anything similar with AI-native browsers or tools? Would love to hear how others are navigating this balance between automation and trust.