DEV Community: Sayan Mohsin

When Code Looks Fine but Isn’t: Building Nice Code for Evidence-Based Review

Sayan Mohsin — Fri, 04 Sep 2026 04:23:23 +0000

A pull request can pass the compiler, the formatter, and the linter and still leave behind a serious engineering problem.

Maybe two independent network requests are being awaited one after another. Maybe a log line includes credentials or personal data. Maybe an error is being discarded without making it clear whether that was intentional. Maybe a persistence change works for new data but does not protect existing records.

None of these problems necessarily look like syntax errors.

The code can be valid. The tests can be green. The change can even look reasonable during a quick review.

That gap is why I built Nice Code.

The limits of local checks

Compilers and linters are extremely good at the rules they can prove locally.

They can tell us whether a type is valid, a variable is unused, a function is formatted correctly, or a known rule has been violated.

But some engineering questions are about context:

Does this log contain enough information to debug the operation safely?
Are these asynchronous operations actually independent?
Is this error intentionally ignored?
Does this migration preserve existing data?
Is this performance claim supported by a measurement?
Does this test protect real behavior or only exercise a happy path?

These questions involve intent, ownership, risk, and operational behavior. They are harder to reduce to a single syntax rule.

AI-assisted development makes this especially visible. A generated change can be completely plausible and still carry a weak assumption about concurrency, error handling, security, or state ownership.

Nice Code is designed for that layer of review.

A small review layer

Nice Code is not meant to replace a compiler, formatter, linter, or test suite.

It adds a conservative, evidence-oriented review on top of the tools a project already uses. The goal is not to produce a single quality score. The goal is to make recurring engineering questions visible, with enough context for someone to decide what should happen next.

The project covers patterns related to:

Logging and observability
Async work and concurrency
Error handling
API boundaries
State and data flow
Persistence and data integrity
Testing and verification
Security and secrets
Performance measurement
Reliability and operations
Code review and AI-generated changes

The patterns are intentionally smaller than a general-purpose static-analysis system. Each one should have a source, a recurring problem, a practical review procedure, and a clear explanation of what it can and cannot prove.

Installing Nice Code

The public package provides a Node-compatible launcher:

npm install --global @sayanmohsin/nice-code

nice-code --changed --project .

The installed command is nice-code, while the npm package is scoped as @sayanmohsin/nice-code.

For a one-off run, the package can also be invoked without a global installation:

npx --yes @sayanmohsin/nice-code --changed --project .

End users do not need Bun, Cargo, or Rust installed. The launcher downloads and verifies the matching Rust engine from the project’s GitHub Releases.

A practical workflow

Nice Code defaults to focused work.

Run a changed-file check during local development or before committing:

nice-code --changed --project .

Run a deliberate full scan when you want to inspect the broader repository:

nice-code --all --project .

That distinction is useful. A full repository scan can be valuable, but it should be intentional rather than silently becoming part of every small edit.

Nice Code can also produce machine-readable output:

nice-code --project . --all --json > nice-code-report.json

JSON reports contain structured findings and scan information for automation, dashboards, or later review.

For GitHub code-scanning integrations, SARIF output can be uploaded as a CI artifact:

- name: Run Nice Code
  run: nice-code --project . --changed --ci --format sarif > nice-code.sarif

- name: Upload Nice Code report
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: nice-code.sarif

Existing projects can adopt Nice Code gradually with a baseline:

nice-code --project . --all --write-baseline

The baseline makes it possible to focus on new findings while the project works through older review items deliberately.

What Nice Code claims

Trust depends on knowing what a tool is actually saying.

Nice Code classifies findings so that a contextual concern does not look identical to a proven defect:

FAIL is a high-confidence issue that may block according to project policy.
WARN is an actionable concern that normally needs review.
REVIEW means context or engineering judgment is required.
PASS means the relevant check ran without a finding.
N/A means the check does not apply to the project or change.

The REVIEW status is important. If a tool cannot prove that a behavior is wrong, it should not pretend that it can.

For example, a sequential await may be correct if the second operation depends on the first. A log statement may be safe if the value is already sanitized. A persistence change may be valid if the migration is protected elsewhere.

The tool should identify the question and the evidence. A developer still needs to make the final decision.

How the tool is built

Nice Code keeps the review path small and explicit.

Public guidance is recorded in a source registry and adapted into independent engineering patterns. The Rust engine owns discovery, parsing, rules, reports, and exit decisions. Node.js provides the user-facing launcher, while Bun is used for development tooling, tests, and benchmarks.

When running in CI mode, Nice Code can also run available native project tools. Their status remains separate from Nice Code’s own findings, so a missing or failing native tool is not silently confused with a custom review rule.

The result can be consumed in several ways:

Human-readable terminal output
Compact output for coding agents
JSON for automation
SARIF for code-scanning systems
Baselines for gradual adoption

The same review can therefore support a developer working locally, an agent preparing a change, or a CI workflow checking a pull request.

Exceptions should be specific

No review tool understands every project perfectly.

That does not mean the answer should be to disable an entire category of checks.

Nice Code supports project-specific configuration and exceptions, but exceptions should be narrow and documented. A good exception explains why a particular finding is safe in that location. It should not quietly remove an entire class of engineering questions from the project.

If a rule produces a false positive because the parser or heuristic is wrong, the better fix is usually to improve Nice Code itself. The target project should not be rewritten merely to make a checker quiet.

In practice, every finding should eventually fall into one of three categories:

A genuine defect to fix.
Safe or intentional behavior to document.
A Nice Code parser or rule problem to improve.

That classification is more useful than pretending every result is equally certain.

Where Nice Code is today

Nice Code is an evolving project.

It is a review aid, not an autonomous engineering authority. It complements native tooling and human review rather than replacing either one.

The project is deliberately conservative about what it claims. Some checks can be automated. Some need a developer or agent to inspect the surrounding context. Others are ultimately product or operational decisions.

The useful outcome is not that every finding disappears.

It is that difficult engineering questions become visible earlier, with a clearer path for deciding what to do about them.

Explore Nice Code

You can find the project here:

Nice Code started from a simple observation: passing local checks is necessary, but it is not always enough to make a change trustworthy.

The project is an attempt to add a small, practical review layer for the questions that live between syntax and system behavior.

Why I Built Arqen: Giving Backend Infrastructure a Clear Home in Rust

Sayan Mohsin — Fri, 04 Sep 2026 04:13:22 +0000

Most backend projects do not become complicated all at once.

They start with a route or two. Then come configuration, authentication, storage, background work, health checks, logging, metrics, migrations, and deployment concerns.

Each addition is reasonable on its own, but over time the boundaries between them become unclear.

Application code starts knowing too much about storage. Background jobs depend on HTTP details. Health checks are implemented differently from service to service. Configuration is spread across constructors, environment variables, and framework-specific layers.

I built Arqen to give those concerns a clearer home.

Arqen is a Rust-first backend toolkit for HTTP services, agents, automation, jobs, health checks, modules, and storage adapters.

It is not intended to hide the system from you. The goal is to make important boundaries explicit without forcing every application to rebuild the same foundation.

The problem with backend glue

A backend often has several responsibilities that are related, but not identical:

Accepting and validating HTTP requests
Authenticating users or services
Calling storage
Running background work
Reporting health and metrics
Emitting useful logs
Exposing capabilities to tools or agents
Moving between local and production environments

The difficult part is not necessarily implementing each feature.

The difficult part is keeping those features from becoming tightly coupled.

A storage implementation should not dictate how an application defines its routes. A background job should not need to know whether data came from an in-memory store, a local embedded engine, or a remote service.

A health endpoint should be able to report dependency state without taking ownership of the entire application lifecycle.

That is where Arqen’s boundaries begin.

A backend foundation, not a giant runtime

Arqen provides a structure for composing backend capabilities while keeping the application in control.

The core is built around Rust, Tokio, Axum, Tower, tracing, and explicit feature flags. HTTP servers, clients, logging, jobs, storage adapters, migrations, and CLI support can be enabled according to the needs of a project.

The easiest way to add Arqen to a Rust project is through Cargo:

cargo add arqen

This adds Arqen from crates.io without tying the article to a specific release number.

For projects that need the CLI generator, a new application can be created with:

cargo run -p arqen --features cli --bin arqen -- new hello-api
cd hello-api
cargo run

The intention is to make the first step straightforward without deciding the entire architecture on behalf of the application.

Keeping storage behind a contract

One of the most important design decisions in Arqen is the ThingdBackend boundary.

Applications should be able to depend on a storage contract instead of directly coupling their business logic to one storage implementation.

That makes it possible to use different modes for different situations:

Memory storage for tests and local development
HTTP Thingd for separately deployed services
Native Thingd for local tooling and embedded workflows
Future hosted or cloud-backed paths where the contract remains useful

The application-facing boundary stays the same while the deployment choice changes.

This is useful when local development and production have different requirements. A local tool may benefit from an embedded engine, while a production application may be better served by a separately managed HTTP service.

Arqen does not treat those modes as interchangeable without qualification. Each mode has different operational properties, compatibility requirements, and failure modes.

For production applications, the HTTP adapter is the preferred boundary. Native storage is useful when the application specifically needs embedded access, local diagnostics, or migration tooling.

Durable work belongs in the backend foundation

Background work tends to grow quietly.

A first job may just process a request later. Eventually it needs retries, leases, idempotency, failure tracking, dead letters, and a way to avoid multiple workers processing the same logical task.

Arqen treats durable jobs as a backend concern rather than leaving every application to invent its own queue lifecycle.

The job system is designed around explicit behavior:

A job can be claimed by a worker
Leases prevent abandoned work from remaining active forever
Retries can be tracked
Failures can be moved to dead-letter handling
Work can be reconciled after a restart
Scheduling can support interval, one-time, and cron-like execution
Run identities can be deterministic and observable

This does not remove the need for application-specific decisions. A payment system, content pipeline, and email sender will all have different retry policies.

But the underlying lifecycle should not need to be reconstructed from scratch each time.

Agent-ready does not mean AI-only

Arqen uses the term “agent-ready,” but that does not mean every application needs to be an AI product.

For Arqen, agent-ready means that capabilities can be:

Discovered
Typed
Permission-aware
Validated
Audited
Exposed through machine-readable contracts

Those properties are useful for agents, but they are also useful for ordinary clients, internal tools, automation, and operational systems.

A typed tool with a clear input schema is easier for an agent to call, but it is also easier for a human developer to understand.

A manifest that describes available capabilities is helpful for automation, but it is also useful for documentation and testing.

The goal is not to add AI terminology to a conventional backend. The goal is to make backend capabilities more explicit and easier to integrate.

Explicit features instead of one large bundle

Arqen uses feature flags to keep optional capabilities visible.

An application can use the core HTTP foundation without pulling in native Thingd support. The CLI, HTTP client, logging, migration, maintenance, and connector features can be enabled when they are actually needed.

That approach adds some configuration work, but it also makes dependencies and deployment assumptions easier to inspect.

A project using native storage should be able to say so clearly. A project using an HTTP-only production boundary should not accidentally compile in an embedded database path just because a convenience feature enabled it.

The feature list becomes part of the architecture rather than an implementation detail hidden inside the dependency graph.

What Arqen provides

Arqen includes building blocks for:

HTTP services and clients
Authentication and request context
Typed tools and machine-readable manifests
Application module composition
Memory and Thingd-backed storage adapters
Durable jobs and scheduling
Health checks and operational status
Structured logging and request correlation
Metrics and observability
Configuration and validation
CLI-based project generation
Migration and maintenance workflows

These capabilities are designed to work together, but they do not require every application to use all of them.

That balance matters. A backend toolkit should provide a coherent path without making every project inherit the complexity of the most advanced project built with it.

The tradeoffs

Arqen is deliberately opinionated in a few places.

It prefers explicit boundaries over convenience coupling. It prefers feature-gated integrations over a single universal runtime. It treats HTTP and native storage as different operational modes.

It gives jobs, health, logging, and configuration a defined place in the application structure.

Those choices can make the architecture slightly more visible up front.

That is intentional.

When a system is small, almost any structure can appear to work. As the system grows, the cost of unclear ownership becomes more noticeable.

Arqen is an attempt to make that ownership clear earlier.

Where the project is today

Arqen is early-stage and actively maturing.

It has useful building blocks and a growing set of examples and documentation, but it should not be treated as automatically production-ready for every workload.

Applications still need their own security review, durability testing, recovery testing, dependency compatibility checks, and operational ownership.

The toolkit can provide a foundation. It cannot make application-specific risk disappear.

That distinction is important because backend infrastructure is easy to oversell. A clean abstraction is valuable, but it is not a substitute for understanding how a particular system behaves under failure.

Explore Arqen

If the problems Arqen is trying to solve sound familiar, the project is available in a few places:

Arqen is an ongoing attempt to make backend infrastructure easier to compose, easier to inspect, and easier to move between environments.

The most useful result would not be that every project uses it.

It would be that the boundaries it explores help make backend systems a little easier to reason about.

The Production Leap: Scaling Agent Workflows Globally on thingd.cloud (Part 4)

Sayan Mohsin — Mon, 13 Jul 2026 19:33:20 +0000

Over the last three posts, we explored the concept of "Zero-UI" software, deep-dived into our high-performance Rust core engine, and wrote local agent scripts using the TypeScript SDK.

But eventually, every developer hits the production wall.

Running a local-first agent data engine on your MacBook is a beautiful experience. But scaling that engine to support thousands of concurrent autonomous agents—while keeping latencies near zero and ensuring total tenant isolation—requires a completely different architectural playbook.

This is the story of how we built thingd.cloud, the managed hosting layer for agent-native infrastructure.

The Production Challenge: Multi-Tenancy for Machines

When humans use a SaaS cloud application, they are forgiving. If a dashboard takes 1.5 seconds to load because of a cold start or a busy database connection pool, a human might sigh, but they won't break the app.

When an AI Agent hits a database layer, it has zero patience. If your cloud API experiences latency spikes, the agent’s execution loop stalls, context windows can timeout, and inference costs skyrocket.

To scale our local Rust/SQLite primitives to the cloud, we had to solve two major architectural pillars:

Absolute Tenant Isolation: Ensuring Agent A’s memory structures can never bleed into or affect Agent B’s data assets.
High-Concurrency Orchestration: Handling thousands of active tool invocations per second without creating database deadlocks.

The Stack: Scaling with NestJS, React, and TypeScript

While our core execution engine (engine.thingd.cloud) stays lean and fast in Rust, we built the control plane and orchestration layer of thingd.cloud using a robust enterprise stack: NestJS on the backend and React for the developer dashboard.

Ditching JSON & SQL Friction: Designing an Object-Shaped Memory Engine (Part 2)

Sayan Mohsin — Mon, 13 Jul 2026 19:32:46 +0000

For a long time, backend engineering has been divided into two camps: Relational databases (SQL) for rigid, structured tables, and Document stores (NoSQL/JSON) for flexible, unstructured data.

But when you are building for AI Agents, both of these traditional approaches introduce massive architectural friction.

AI agents don't think in rows, columns, or complex foreign key joins. They don't want to parse heavily nested, arbitrary JSON text blobs either. Agents think in state, context, and entities. They operate best when data looks exactly like the object structures they manipulate in their runtime environments.

When I designed the core primitives for thingd, I wanted the absolute speed of a local relational database combined with the flexibility of an object-first paradigm. Here is how we bypassed the typical ORM bloat and built an object-shaped memory engine natively in Rust.

Why typical DB abstractions break for Agents

If you hook an autonomous agent loop up to a traditional Postgres or MySQL instance using an ORM like Prisma or TypeORM, you run into three main problems:

Context Bloat: ORMs generate heavy, verbose SQL queries and return heavily structured responses packed with metadata that the agent doesn't need, wasting valuable context tokens.
Schema Inflexibility: Agents are dynamic. They discover new data shapes, store arbitrary runtime memories, and alter data structures on the fly. Migrating a SQL schema mid-agent loop is an absolute nightmare.
The Local I/O Bottleneck: Forcing a local agent loop to constantly hit a remote cloud database for every minor micro-step adds hundreds of milliseconds of network latency, compounding until the agent feels unusable.

We needed something local-first, structurally dynamic, and blazing fast.

Under the Hood: SQLite Performance + Rust Objects

To solve this, thingd uses SQLite as its storage engine, but exposes it completely as a high-performance Object Store.

Instead of forcing developers (or agents) to write queries or handle migrations, thingd abstracts the database into an entity-first system. Every data point is treated as a "thing"—an object primitive with its own identity, properties, and relationships.

Because the underlying engine is written in Rust, we get to take advantage of zero-cost abstractions:


rust
// A simplified look at how thingd handles dynamic object primitives internally
#[derive(Serialize, Deserialize, Debug, Clone)]
pub struct ThingObject {
    pub id: String,
    pub entity_type: String,
    pub properties: HashMap<String, serde_json::Value>,
    pub updated_at: i64,
}

Killing the Frontend: Building the Agent-Native Stack (Part 1)

Sayan Mohsin — Mon, 13 Jul 2026 19:32:16 +0000

For the last two decades, software engineering has followed a predictable formula: build a database, write an API, and build a massive, complex frontend web app (React, Vue, Next.js) so a human can interact with your data.

If you are building something like an Order Management System (OMS) today, you will spend months designing dashboards, sorting data tables, managing state, and handling complex pagination hooks—all just so a human can click a button to change a status from "Pending" to "Shipped."

But what happens when your user isn't a human looking at a screen, but an autonomous AI Agent running in a background loop?

The agent doesn't care about your custom Tailwind CSS components or your beautifully optimized pagination hooks. In fact, forcing an AI agent to scrape a web UI or deal with bloated, unstructured HTTP REST endpoints is slow, token-expensive, and highly unpredictable.

If we are moving into a world of Zero-UI, where software is entirely agent-driven, we need a fundamentally new backend stack. We need Agent-Native Infrastructure.

The Paradigm Shift: From Features to "Invocable Capabilities"

When you strip away the frontend, an application becomes a collection of raw, high-performance capabilities that an LLM can trigger deterministically.

Imagine an agent-driven application:

A human simply tells a chat interface, a Slack bot, or an internal AI handler: "Cancel order #1042 and refund the user because it’s out of stock."
The Agent takes that intent, calculates the correct execution path, and triggers a direct data operation.

To make this reliable at scale, the agent needs a data engine that speaks its language natively—via the Model Context Protocol (MCP)—at sub-millisecond speeds.

That is exactly why I built thingd.

I didn't want to build another dashboard. I wanted to build an open-source, ultra-fast data engine designed specifically to give agents native access to application state and memory without the traditional web app fluff.

To prove this architectural pattern worked, I didn't start with a simple todo app. I built a real-time, high-concurrency npm registry lookup engine directly native to AI agents: engine.thingd.cloud.

The Stack: Why Rust + MCP is the Zero-UI Sweet Spot

Building for agents requires two things that traditional web apps often compromise on: extreme speed and rigid predictability.

If an LLM takes 800ms waiting for a server response during an autonomous loop of 10 sequential tasks, the compounding latency destroys the user experience.

1. The Protocol: Model Context Protocol (MCP)

Instead of inventing a custom JSON schema or letting the LLM guess how to query an endpoint, thingd utilizes the open standard Model Context Protocol. MCP acts as a secure, bidirectional bridge between LLMs (like Claude Code, Cursor, or custom frameworks) and data sources.

By exposing my engine via an MCP server, any agent can inspect the tool schema natively:


json
{
  "name": "thingd_npm_lookup",
  "description": "Query the high-speed thingd engine for real-time npm package metadata and dependency trees",
  "input_schema": {
    "type": "object",
    "properties": {
      "package_name": { "type": "string" }
    },
    "required": ["package_name"]
  }
}

Local-First Agents: Building with the thingd CLI & TypeScript Clients (Part 3)

Sayan Mohsin — Mon, 13 Jul 2026 17:17:39 +0000

A great data engine is completely useless if the developer experience (DX) makes you want to tear your hair out.

When building tools for AI agents, DX is twice as difficult. You aren't just designing a clean API for the human engineer writing the code; you are also designing an intuitive interface for the AI agent that will be manipulating the system autonomously.

In this post, we’re looking at how to build with thingd using the local CLI and our native TypeScript SDK to create low-latency, local-first agent loops.

Local-First DX: The thingd CLI

When an agent is autonomously modifying data, updating system states, or resolving something complex like our npm lookup tool on engine.thingd.cloud, human developers need a window into what the hell is happening under the hood.

The thingd CLI acts as that bridge. It allows you to spin up the local engine, inspect the object memory pools, and view real-time logs of what your agents are querying.


bash
# Start the local engine instance
thingd start

# Inspect live agent-created object entities
thingd objects:list --type memory_stream