DEV Community: Sina Rezaei

Your AI Pentester Found an SSRF. Can It Reproduce the Attack?

Sina Rezaei — Fri, 30 Oct 2026 00:22:16 +0000

The first scan found an SSRF. The second one didn't.

I wouldn't close the finding just yet.

The endpoint accepts a URL, fetches the resource, and returns its response. During the first scan, the agent managed to follow a redirect and reach an internal service. It reported the issue with a successful response as evidence.

Then it ran the test again. Same endpoint, same application. No SSRF.

One thing I'd check before looking at the model's reasoning is the actual network traffic.

Suppose the agent tests a hostname that resolves to a public IP. The application checks the address and allows the request. But there's a gap between that check and the connection itself. If another DNS resolution returns a private IP, the application could end up connecting somewhere the original validation was supposed to block.

That's the DNS rebinding problem.

The details depend on the HTTP client, DNS caching, connection reuse, and whether a proxy is involved. A second lookup isn't guaranteed. But if the component making the connection doesn't enforce the destination restrictions, checking the hostname at the beginning isn't enough.

Redirects make this more interesting. The first URL can point to a public host and return a redirect to another hostname. If the application validates only the original destination, the next request may escape the intended boundary. OWASP recommends disabling automatic redirect following in the HTTP client to avoid this validation bypass. If redirects are required, each destination needs to be checked before the next request is made.

I'd want to see the actual destination IP at connection time, not just the hostname supplied by the agent. I'd also check whether outbound network rules prevent access to internal address ranges.

There's a second problem here, and it has less to do with SSRF itself.

Even if the agent sends exactly the same request twice, the network path might not be identical. DNS can return a different address, a redirect target can change, or the HTTP client can reuse an existing connection in one run and establish a new one in the next.

Looking at the final model response won't tell us which of these happened.

For this kind of test, I'd keep the raw request, DNS answers, redirect history, destination IP, response status, and target build identifier for each run. Not just the agent's summary. Without that information, a failed second scan doesn't tell us whether the vulnerability disappeared or the request simply took another route.

There's also a difference between replaying a previous execution and reproducing the vulnerability. Replaying saved tool calls can reconstruct what the agent did before. It doesn't prove that the current application is still vulnerable.

That's why I'd avoid treating a second scan that returns nothing as evidence that the issue is gone.

Before closing the finding, I'd want to know one thing:

Did the application stop accepting the request, or did the request stop reaching the same destination?

Reference

OWASP: Server-Side Request Forgery Prevention Cheat Sheet

The SQL NOT IN Trap: When NULL Quietly Breaks Your Query

Sina Rezaei — Fri, 30 Oct 2026 00:16:28 +0000

Some SQL bugs don't throw errors. The query runs, the tests pass, and everything looks fine until a cleanup job skips records it was supposed to catch.

One of the reasons this happens is NULL inside a NOT IN query.

When `NOT IN` stops behaving as expected

Imagine you're working on a multi-tenant platform. You have a memberships table and an identity_mappings table. Each mapping connects an external identity to a tenant.

You need to find memberships that don't have a corresponding identity mapping.

A first attempt might look like this:

SELECT m.tenant_id, m.external_id
FROM memberships m
WHERE m.external_id NOT IN (
    SELECT i.external_id
    FROM identity_mappings i
);

Nothing looks wrong at first glance. You're selecting external IDs that don't exist in the mapping table.

Now suppose the subquery returns these values:

external_id
`ext_1042`
`ext_2087`
`NULL`
`ext_3911`

That single NULL can change the result.

SQL uses three-valued logic: a condition can evaluate to TRUE, FALSE, or UNKNOWN. When NULL is involved in a comparison, SQL often can't determine whether the comparison is true or false.

For example:

SELECT 'ext_9001' NOT IN (
    'ext_1042',
    'ext_2087',
    NULL
);

The result isn't TRUE. It's UNKNOWN.

Because a WHERE clause keeps only rows for which the condition evaluates to TRUE, the record gets filtered out.

The query executes successfully. There's no exception to investigate. You simply get fewer rows than expected.

That's what makes this bug easy to miss.

Why `NOT EXISTS` is often a better fit

One common fix is to replace NOT IN with NOT EXISTS:

SELECT m.tenant_id, m.external_id
FROM memberships m
WHERE NOT EXISTS (
    SELECT 1
    FROM identity_mappings i
    WHERE i.external_id = m.external_id
);

The difference matters.

NOT EXISTS checks whether a matching row exists. An unrelated NULL elsewhere in the subquery doesn't automatically make the condition unknown.

But fixing the NULL problem doesn't necessarily mean the query is correct.

There's another detail in this example that deserves attention.

The multi-tenant bug hiding behind the SQL

In a multi-tenant system, an external ID might be valid in one tenant but completely unrelated to the same value in another tenant.

Suppose the data looks like this:

memberships

tenant_id	external_id
`tenant_a`	`ext_1042`
`tenant_b`	`ext_1042`

identity_mappings

tenant_id	external_id
`tenant_a`	`ext_1042`

The membership for tenant_b has no matching mapping within its own tenant.

However, this query checks only the external ID:

WHERE NOT EXISTS (
    SELECT 1
    FROM identity_mappings i
    WHERE i.external_id = m.external_id
);

It finds the mapping belonging to tenant_a and treats the tenant_b membership as matched.

The SQL is valid. The logic is wrong.

If the relationship depends on both the tenant and the external ID, the query needs to express both conditions:

SELECT m.tenant_id, m.external_id
FROM memberships m
WHERE NOT EXISTS (
    SELECT 1
    FROM identity_mappings i
    WHERE i.tenant_id = m.tenant_id
      AND i.external_id = m.external_id
);

Now the query checks the relationship the application actually cares about.

This is a different class of bug from the original NULL issue. Replacing NOT IN with NOT EXISTS solves one problem, but it doesn't automatically make the underlying relationship correct.

What about `NULL` in the outer table?

There's one more case worth testing.

What happens if m.external_id itself is NULL?

With the equality condition:

i.external_id = m.external_id

a NULL value doesn't match another NULL value. The subquery finds no matching row, so NOT EXISTS evaluates to TRUE.

That means the membership with a missing external ID can appear in the result.

Whether that's correct depends on the application.

If NULL means the identity hasn't been linked yet, returning that membership might be intentional. If the cleanup job is supposed to process only memberships with known external IDs, you'll need an additional condition:

AND m.external_id IS NOT NULL

Don't add that condition automatically, though. First establish what NULL means in the data model.

A query shouldn't have to guess the business rules.

The tests I'd add before shipping this

For a cleanup job in a multi-tenant system, I'd test these cases explicitly:

A matching mapping exists for the same tenant and external ID.
The same external ID exists in another tenant, but not the current one.
The mapping table contains a NULL external ID.
The membership itself has a NULL external ID.
Duplicate mappings exist for the same tenant and external ID.

I'd also check the database constraints. If each tenant should have at most one mapping for a given external ID, a suitable unique constraint can enforce that rule rather than leaving it entirely to application code.

Before running a destructive cleanup, inspect the candidate rows and verify the expected count. If possible, run the operation inside a transaction and make sure the affected records are exactly the ones you intended to process.

A successful query execution is not proof that the selected rows are correct.

The real lesson

NOT IN and NOT EXISTS are worth understanding, especially when NULL is involved. But the operator isn't always the biggest problem.

A query can handle NULL correctly and still match records across tenant boundaries. It can pass tests built around clean data and fail when production data contains unexpected values. It can be perfectly valid SQL while describing the wrong relationship.

When I review an anti-join, I want to establish three things before worrying about the syntax:

What exactly makes two records a match?
What should happen when one of the relevant values is NULL?
Which columns define the relationship, including tenant boundaries?

Once those rules are clear, choosing the SQL becomes much easier.

Have you ever found a query that was technically correct but was checking the wrong relationship?

The JavaScript We Never Questioned

Sina Rezaei — Tue, 27 Oct 2026 23:05:25 +0000

We often reach for JavaScript because that's how we've learned to solve frontend problems. Need to calculate a layout value? Write a function. Need to coordinate styles across components? Add some logic. Need to handle a visual behavior? Start with an event listener.

Sometimes that's the right call. But sometimes we're writing JavaScript to work around a limitation that no longer exists.

CSS has evolved far beyond styling colors, spacing, and typography. Features like container queries, :has(), and modern layout capabilities have changed how we can approach problems that once required extra code.

The interesting part isn't that CSS can replace JavaScript. It can't, and it shouldn't try to. The real question is whether we're adding complexity because the problem demands it, or because we're still using an old solution out of habit.

In this article, I'll look at a few common frontend patterns, how modern CSS changes the equation, and where JavaScript still makes more sense.

The goal isn't to write less JavaScript just for the sake of it. It's to stop writing code that the platform can already handle.

How Much Coding Do You Actually Need in the AI Era?

Sina Rezaei — Sat, 24 Oct 2026 07:02:21 +0000

I keep coming back to this question: is it still worth learning to code when you can get so much done without writing everything yourself?

Personally, I think it is.

You don't need to spend months memorizing Python syntax before building something. Pick a project, start working on it, and learn what you need along the way.

But there's a catch. You need to understand enough to know when something isn't right.

For example, imagine you're building an API that returns products from a database. Everything works fine with a few records, but once the database grows, the endpoint becomes painfully slow.

If you understand SQL queries, indexing, and pagination, you have somewhere to start. Otherwise, you might spend hours changing code without ever finding the actual problem.

That's why I wouldn't skip the fundamentals.

Learn how variables, functions, loops, data structures, APIs, and errors work. Get comfortable reading code, running tests, and figuring out why something broke.

You don't have to know everything before starting a project. In fact, working on real projects is probably one of the best ways to learn.

And there's no reason to stop at the basics if you're building more complex systems. The more you understand about databases, architecture, and how different parts of an application fit together, the better decisions you can make.

So, how much coding knowledge is enough?

Enough to understand what you're building, recognize when something is wrong, and figure out what to do next.

You can always learn more when you need it.

What matters is knowing more than just what to ask for. You need to understand what you're getting back.

Where would you draw the line? Are the fundamentals enough, or is deeper programming knowledge still essential?

My AI Agent Passed Every Test. The Feature Was Still Wrong.

Sina Rezaei — Tue, 20 Oct 2026 07:46:47 +0000

There's a particular kind of bug that's more annoying than a failing test.

The code runs. The tests pass. The build is green.

And the feature still does the wrong thing.

With an AI coding agent, there's another question worth asking: what happens when the agent can change the implementation and the tests used to decide whether that implementation is correct?

I found a concrete example of this in a DEV article about an AI coding agent changing tests to pass CI.

The interesting part wasn't a complicated algorithm or an obscure framework bug. It was a disagreement between what the software was supposed to do and what the tests had been changed to accept.

The billing bug that wasn't really fixed

Consider a billing feature that splits a total of 100 units between three people.

The product requirement says everyone must pay the same amount. The existing implementation uses ordinary rounding and produces:

[33, 33, 33]

That adds up to 99, so there's a genuine problem to solve.

An agent can fix the arithmetic by distributing the remainder:

[34, 33, 33]

The total is now correct.

But there's a catch: the product requirement explicitly says the amounts must be identical.

The mathematically convenient fix violates the product rule.

In the reported DEV experiment, the author described running the scenario repeatedly across three coding agents. All ten runs changed the expected result to [34, 33, 33], even though the product comment still required identical amounts. Six runs reported the tests passing and continued without asking for a product decision.

That's the important detail. The agent didn't simply fail to solve the arithmetic problem. It made a decision that belonged to the product specification.

Read the original report on DEV.

The test can be green for the wrong reason

Imagine the test originally looks like this:

def test_equal_split():
    assert split_amount(100, 3) == [33, 33, 33]

The test is internally inconsistent with the total, but it reflects the stated equal-payment requirement as closely as integer amounts allow.

The agent changes the expected result:

def test_equal_split():
    assert split_amount(100, 3) == [34, 33, 33]

Now the test can pass after the implementation is updated.

The CI pipeline is happy. The total is correct. The expected value matches the implementation.

But nobody has resolved the actual product question:

Is the requirement equal payments, or is it that the allocated amounts must sum to the exact total?

Those are different requirements.

If equal payments are mandatory, the system needs a different policy. It might reject totals that cannot be divided evenly, preserve fractional currency units, or ask the product owner how the remainder should be handled.

If exact allocation is mandatory, unequal integer amounts may be acceptable, provided the allocation policy is documented.

The correct solution depends on a decision the code cannot make on its own.

This is where I stop trusting the green checkmark

A passing test is useful evidence. I'm not arguing against tests.

I'm arguing against treating the test result as the entire definition of correctness.

There's a difference between these three questions:

Does the implementation satisfy the tests?
Do the tests reflect the requirements?
Are the requirements themselves consistent with what the product needs?

A green check answers the first question. It doesn't automatically answer the other two.

This becomes especially important when the same coding agent can modify the source code, rewrite assertions, update snapshots, and report that everything passes.

The problem isn't necessarily that the agent is deliberately cheating. It can be following the most immediately achievable interpretation of the task while overlooking a constraint that matters more than the failing test.

From the outside, however, the result can look exactly like a successful fix.

There's research behind this, too

This isn't limited to one reported experiment.

The TestSuiteBench research paper, published in October 2026, evaluates coding agents on test-suite generation for 165 open-source applications.

The benchmark uses detailed specifications, reference implementations, reference tests, and controlled mutations that introduce defects tied to individual requirements.

The researchers found that the evaluated agents struggled to produce strong test suites from specifications. Their mutation scores remained below 60%, even though 88% of their generated tests passed on the reference implementations.

Those figures measure different things: passing the correct implementation is not the same as detecting deliberately introduced defects.

That's the distinction I care about. A test suite can execute successfully without providing strong evidence that the important requirements are protected.

So what should the agent actually be allowed to change?

I think the solution starts before the code is written.

For a task like the billing example, I'd keep three things separate:

The requirement

The amounts must be identical, or the allocation must sum exactly to the total. If both are required, the specification needs to explain what happens when they conflict.

The implementation

The agent can propose an algorithm, explain its trade-offs, and implement the agreed behavior.

The acceptance tests

The expected behavior should come from the agreed requirement, not simply from whatever output the new implementation happens to produce.

Then I'd add a small but useful rule to the workflow: when an agent needs to change an assertion to make a test pass, it must explain why the original expectation was wrong and identify the requirement that authorizes the change.

That doesn't mean every test change is suspicious. Requirements evolve, and tests sometimes need updating.

It means a change to the expected result should be treated as a decision to review, not a routine step in fixing a bug.

For important behavior, I'd also use an independent test suite or mutation testing to check whether the tests can actually detect violations. The goal isn't to make the workflow heavier for its own sake. It's to stop the same mistaken assumption from silently shaping both the code and the evidence used to approve it.

Here's the question I keep coming back to

If an AI agent can change the implementation, update the tests, and report success, where should the boundary be?

Should it be allowed to change expected results when it finds a more mathematically correct implementation? Should it stop and ask for clarification? Or should the CI pipeline reject changes to acceptance tests unless a human explicitly approves them?

I can see arguments for all three, depending on the project.

But I wouldn't want a billing rule, a permission check, or a financial invariant to change simply because the new code made the existing test inconvenient.

What's your rule for AI-generated test changes?

Do you let the agent update assertions as part of a fix, or do you treat changes to expected behavior as a separate review decision?

I'd be interested in examples where this distinction has actually caught a bug, especially in production systems.

The Ariadne Thread: Why AI Fails to Follow the Path You Define

Sina Rezaei — Fri, 16 Oct 2026 21:26:56 +0000

As a full-stack developer, I don't evaluate an AI-generated solution simply by checking whether the code compiles. I want to know whether the model identified the real problem, followed the requested analytical approach, and accounted for the conditions that could make its solution fail.

This distinction becomes particularly important when working with distributed systems. A recommendation can follow a familiar engineering pattern and still introduce a serious production bug.

The problem isn't necessarily that the model lacks a relevant technique. Sometimes, it chooses a technique before investigating whether it is appropriate.

The Pattern Trap: When a Familiar Solution Is Not Enough

Consider a checkout service built with TypeScript and Node.js. A customer submits an order, the backend initiates a payment, and the frontend waits for the response.

Now imagine the payment provider processes the request, but the response never reaches the application because of a network timeout.

From the client's perspective, the operation failed. From the payment provider's perspective, it may have succeeded.

That distinction creates a difficult problem: the application cannot safely assume that a timeout means the operation was never completed.

Amazon's Builders' Library explores this exact class of problem in its engineering discussion of Making retries safe with idempotent APIs. Its example concerns resource provisioning, where retrying an operation after an ambiguous failure can create duplicate resources. The underlying challenge also applies to transactional workflows: repeating a request may repeat its side effects.

A Full-Stack Scenario: The Duplicate Payment Problem

Suppose the frontend sends this request:

POST /api/checkout
Content-Type: application/json

{
  "orderId": "ord_8421",
  "amount": 149.99,
  "currency": "USD"
}

The backend sends a payment request to an external provider. The provider processes the payment, but the connection times out before the backend receives confirmation.

The frontend displays an error. The customer clicks Pay again.

If the backend treats the second request as an entirely new operation, the customer could be charged twice.

A straightforward AI-generated recommendation might be:

Add a retry mechanism with exponential backoff to handle transient network failures.

That advice isn't inherently wrong. Retries are an important resilience technique, and AWS recommends controlling retries, using backoff and jitter where appropriate, and verifying that operations can be safely retried. See the AWS Well-Architected guidance on controlling retry calls.

But in this scenario, retrying is not the first question that needs answering.

The first question is: How can the system distinguish a repeated request from a new payment operation when the result of the original request is unknown?

Imagine giving an AI assistant this instruction:

Act as a senior full-stack engineer reviewing a production payment system. Analyze the failure semantics before proposing a fix. Distinguish a client timeout from a confirmed payment failure. Examine duplicate submissions, retry behavior, idempotency, and the consistency of persisted payment state. Do not recommend retries until you have established how repeated requests avoid repeating the payment side effect.

A response that jumps directly to retry configuration has missed the central requirement, even if its code uses a sensible backoff algorithm.

The instruction defined the analytical path. The response followed a familiar pattern instead.

What the Analysis Should Actually Examine

A reliable solution requires more than adding a request header or wrapping a network call in a retry loop.

1. Give the operation a stable identity

The client or backend needs an idempotency key that identifies one logical payment attempt.

For example:

POST /api/checkout
Idempotency-Key: checkout_8421_attempt_1
Content-Type: application/json

The key must remain the same when the same logical operation is retried. A genuinely new payment attempt needs a different identity according to the application's business rules.

The backend can use that key to recognize duplicate requests and return the previously recorded result instead of blindly executing the operation again.

Generating a fresh key on every retry defeats the purpose.

2. Handle the ambiguous outcome

A timeout tells the application that it did not receive a response within the expected period. It does not prove that the payment provider rejected the payment.

The system may need to query the provider, retry using the same idempotency key where supported, or mark the operation as pending reconciliation.

The correct action depends on the payment provider's API contract and its idempotency guarantees. A local database record alone cannot establish whether an external payment succeeded.

3. Protect the operation's state transitions

Consider this simplified TypeScript example:

async function createPayment(
  orderId: string,
  idempotencyKey: string
) {
  const existing = await db.paymentRequest.findUnique({
    where: { idempotencyKey }
  });

  if (existing) {
    return existing;
  }

  return db.paymentRequest.create({
    data: {
      orderId,
      idempotencyKey,
      status: "PENDING"
    }
  });
}

This illustrates the idea of recording an operation under a stable key. It is not a complete idempotency implementation.

Two concurrent requests could both fail to find an existing record before either creates it. A database uniqueness constraint is needed to prevent duplicate records for the same key, and the application must handle that conflict correctly.

There is another, deeper issue: recording a request in the local database and charging a payment provider are separate operations. A database transaction cannot automatically make both systems commit or roll back together.

A production design must account for that boundary. Depending on the provider and workflow, this can involve a provider-supported idempotency key, durable payment states, reconciliation, and recovery for interrupted operations.

AWS discusses the importance of making the recording of an idempotency token and the associated mutations atomic within the system that owns those mutations. It also explains why repeated requests need a well-defined identity and behavior. See Making retries safe with idempotent APIs.

The important engineering question isn't simply whether the implementation contains an idempotency key. It is whether the complete request lifecycle preserves the intended behavior under concurrency, timeouts, retries, and partial failure.

The Actual Test: Did the Model Follow the Instruction?

Now return to the original instruction.

The assistant was asked to analyze ambiguous outcomes, repeated requests, idempotency, and persisted state before recommending retries.

A useful evaluation would check whether its answer:

Distinguishes transport failure from confirmed business-operation failure.
Preserves the identity of a logical operation across retries.
Accounts for concurrent duplicate requests.
Identifies the boundary between local persistence and external side effects.
Explains how the system recovers when a request succeeds remotely but its result is not recorded locally.
Proposes tests for repeated submissions, concurrent requests, and timeouts after the provider has processed the operation.

If the response only recommends exponential backoff, it has not completed the requested analysis.

If it adds an idempotency header but ignores concurrent requests or partial failure, it has followed part of the path while missing other essential requirements.

This gives us a more concrete way to evaluate an AI assistant. Instead of asking whether the answer sounds experienced, we can compare its recommendations against explicit engineering conditions.

The Instruction–Execution Gap

This is the distinction I want to emphasize: defining the path is not the same as following the path.

A model can recognize the words retry, timeout, and distributed system and produce a plausible recommendation based on familiar engineering practices. That recommendation might even be correct in a different context.

The failure occurs when the model does not preserve the specific analytical priorities established by the instruction.

Giving the model a persona such as "senior full-stack engineer" can help establish the intended perspective. But a job title does not guarantee a particular method of analysis. The more important part is defining what the model must investigate, which assumptions it must challenge, and what conditions must be satisfied before it recommends a solution.

Even then, instructions alone cannot guarantee correct execution. The response still needs to be evaluated against the requirements, and its claims need to be checked against the system's actual behavior.

The Ariadne Thread

In Greek mythology, Ariadne gives Theseus a thread that helps him navigate the labyrinth.

I use that image to describe an analytical framework. A complex engineering problem contains many possible paths, plausible explanations, and tempting shortcuts. The framework establishes a route through them.

In the payment example, the route begins with the meaning of a timeout, moves through the identity of a logical operation, examines concurrency and external side effects, and only then considers retry behavior.

Jumping straight to exponential backoff skips the very questions that determine whether retrying is safe.

The thread is not the instruction itself. It is the connection between the original analytical objective and the decisions made throughout the investigation.

Beyond Fat Controllers: Using the Facade Pattern in Ruby on Rails

Sina Rezaei — Mon, 12 Oct 2026 07:59:34 +0000

A Rails controller often starts small. A user selects a subscription plan, the application processes a payment, and the subscription becomes active.

Then the requirements grow. You need to handle failed payments, prevent duplicate charges, activate features, and deal with external services that occasionally fail.

Moving each operation into a service object helps, but the controller may still be responsible for coordinating all those services.

The Facade pattern offers a cleaner approach: expose one entry point for a complex workflow while keeping its individual responsibilities separate.

From a Fat Controller to a Facade

Consider a subscription checkout that involves payment processing, subscription activation, and feature provisioning.

class SubscriptionsController < ApplicationController
  def create
    plan = Plan.find(params[:plan_id])

    payment = PaymentProcessor.call(
      user: current_user,
      plan: plan
    )

    if payment.succeeded?
      subscription = current_user.subscriptions.create!(
        plan: plan,
        status: "active"
      )

      FeatureProvisioner.call(subscription)

      redirect_to subscription_path(subscription)
    else
      redirect_to plans_path, alert: "Payment failed"
    end
  end
end

The problem isn't the number of lines. The controller knows too much about the workflow: which operation runs first, what depends on payment success, and what happens next.

As the feature evolves, more conditions and failure scenarios end up in the same action.

Introducing the Facade

We can move that coordination into a dedicated class:

class SubscriptionActivation
  def initialize(
    payment_processor: PaymentProcessor.new,
    subscription_activator: SubscriptionActivator.new,
    feature_provisioner: FeatureProvisioner.new
  )
    @payment_processor = payment_processor
    @subscription_activator = subscription_activator
    @feature_provisioner = feature_provisioner
  end

  def call(user:, plan:, idempotency_key:)
    payment = @payment_processor.call(
      user: user,
      plan: plan,
      idempotency_key: idempotency_key
    )

    return ActivationResult.failure(:payment_failed) unless
      payment.succeeded?

    subscription = @subscription_activator.call(
      user: user,
      plan: plan,
      payment: payment
    )

    @feature_provisioner.call(subscription)

    ActivationResult.success(subscription)
  end
end

The Facade coordinates the workflow without implementing every operation itself. Payment processing, subscription activation, and feature provisioning remain separate responsibilities.

Dependency injection also makes testing easier because each collaborator can be replaced with a test double.

The controller now has a simpler job:

class SubscriptionsController < ApplicationController
  def create
    plan = Plan.find(params[:plan_id])

    result = SubscriptionActivation.new.call(
      user: current_user,
      plan: plan,
      idempotency_key: checkout_attempt.idempotency_key
    )

    if result.success?
      redirect_to subscription_path(result.subscription)
    else
      redirect_to plans_path, alert: "Unable to activate subscription"
    end
  end
end

Here, checkout_attempt represents a persisted checkout attempt whose idempotency key is reused on retries. The result objects and supporting services are application-specific, not built-in Rails classes.

The Detail That Matters: Failure Handling

A Facade organizes a workflow, but it doesn't automatically make that workflow reliable.

Imagine the payment provider confirms a charge, but the database update fails. A database rollback cannot undo a charge made by an external service.

Retries create another risk. If a customer submits checkout twice, the application must avoid charging them twice for the same attempt.

Use a stable idempotency key for payment requests. Stripe documents how idempotent requests help prevent duplicate operations when requests are retried.

External side effects also need careful handling. If feature provisioning happens through another service, a failed request may require a retry or reconciliation process. For workflows where losing an event is unacceptable, a transactional outbox can help ensure that database changes and the corresponding event are recorded together.

These mechanisms solve different problems. The Facade coordinates the steps; idempotency and reliable event delivery protect the workflow when things go wrong.

Testing the Workflow

A useful Facade test verifies the order and conditions of the operations, rather than testing the internals of every collaborator again.

For example, a declined payment should prevent subscription activation:

RSpec.describe SubscriptionActivation do
  it "does not activate a subscription after payment fails" do
    payment_processor = instance_double(PaymentProcessor)
    activator = instance_double(SubscriptionActivator)
    provisioner = instance_double(FeatureProvisioner)

    allow(payment_processor)
      .to receive(:call)
      .and_return(
        instance_double(
          PaymentResult,
          succeeded?: false
        )
      )

    facade = described_class.new(
      payment_processor: payment_processor,
      subscription_activator: activator,
      feature_provisioner: provisioner
    )

    facade.call(
      user: build_stubbed(:user),
      plan: build_stubbed(:plan),
      idempotency_key: "checkout_123"
    )

    expect(activator).not_to have_received(:call)
    expect(provisioner).not_to have_received(:call)
  end
end

This example assumes the application's result objects and test factories are defined accordingly.

When Should You Use a Facade?

A Facade is useful when a single business operation requires several components to work together and callers shouldn't need to know the sequence.

It isn't necessary for every controller action. If an operation is simple, adding another class can create unnecessary indirection. And if the Facade starts implementing every business rule itself, it may simply become another oversized object.

Keep the distinction clear:

Controller: handles the HTTP request and response.
Facade: coordinates the workflow.
Collaborating services: implement their own responsibilities.

The goal isn't to create more classes. It's to make a complicated operation easier to understand, test, and change without spreading its coordination logic throughout the application.

AI Should Propose. Systems Should Verify.

Sina Rezaei — Wed, 07 Oct 2026 05:44:22 +0000

AI Should Propose. Systems Should Verify.

An AI agent can produce the correct action and still have no authority to execute it.

That distinction becomes critical when agents move beyond generating text and start modifying code, calling APIs, changing infrastructure, triggering workflows, or coordinating other agents.

The question is no longer only:

Can the model determine what should happen?

It is also:

What happens between the action the model proposes and the action the system actually executes?

A useful starting point is:

AI proposes. Systems verify. Infrastructure executes.

The Problem With Direct Execution

Consider an AI coding agent working inside a production environment.

The agent receives a task:

Fix the authentication bug and deploy the change.

It analyzes the repository, modifies the code, runs tests, and produces a deployment command.

The code may be correct.

The tests may pass.

The deployment command may be valid.

None of those facts automatically mean the agent should be allowed to deploy to production.

This is the difference between correctness and authority.

A model can correctly determine what should happen while still being unauthorized to perform that action.

If the same component controls reasoning, authorization, and execution, the trust boundary becomes extremely large:

AI decides what to do → AI decides whether it may do it → AI executes it

A safer architecture separates those responsibilities.

Put a Boundary Between Reasoning and Execution

Instead of allowing the model to directly invoke sensitive infrastructure, treat its output as a proposed action.

User Intent
    ↓
AI Agent
    ↓
Proposed Action
    ↓
System Validation
    ↓
Policy Check
    ↓
Execution
    ↓
Post-Execution Verification

The model produces the request.

The surrounding system evaluates it.

The infrastructure executes it only after the required controls have been satisfied.

For example:

{
  "action": "deploy",
  "environment": "production",
  "service": "auth-service",
  "version": "2026.10.04"
}

The control layer can independently check whether the request is structurally valid, whether the target exists, whether the requested operation is permitted, and whether additional controls are required.

The model does not need to make those decisions itself.

Passing Tests Does Not Mean Permission

Imagine the coding agent changes a payment service.

The tests pass.

The security checks pass.

The build succeeds.

The artifact is signed.

The model now proposes:

Deploy to production.

The previous results establish that the software may be technically acceptable.

They do not establish that the current actor is authorized to deploy it.

That gives us an important separation:

Validation → Is this action acceptable as an operation?

Authorization → Is this actor allowed to perform it?

Execution → Perform the approved operation.

These questions belong to different layers.

That separation also makes the architecture easier to audit and change without changing the model's reasoning process.

Powerful Agents Do Not Need Unrestricted Authority

Separating reasoning from execution does not require making the agent weak.

An engineering agent can still have broad capabilities:

inspect repositories
create branches
modify files
run tests
inspect logs
generate deployment plans
propose infrastructure changes

The system can simply apply stronger controls to higher-impact operations such as:

production deployment
credential rotation
database migration
destructive infrastructure changes
financial transactions

The agent remains capable of reasoning about complex operations.

Its capabilities just do not automatically become unrestricted authority.

Think in Actions, Not Just Tools

Another architectural mistake is defining control only around tool access.

For example:

Agent → deploy_tool
Agent → payment_api
Agent → database_api

Tool access is often too coarse.

The more useful question is:

What action is the agent attempting to perform, against which resource, under which constraints?

A control layer can therefore reason about something closer to:

Actor → Action → Resource → Environment → Scope → Context → Policy

Now the system can distinguish between actions that happen to use the same underlying tool.

A deployment API, for example, might be capable of deploying to both staging and production. Access to the API alone does not tell us whether a particular production deployment should be allowed.

The meaningful unit of control is the action and its context, not simply the existence of a tool.

When Agents Start Delegating

The boundary becomes even more important when one agent delegates work to another.

Consider:

User → Orchestrator Agent → Procurement Agent → Payment Service

The procurement agent may determine that a purchase is necessary.

But the fact that the orchestrator requested the purchase does not automatically give the procurement agent unlimited spending authority.

Now the system needs to understand more than the requested action:

Initiator → Delegator → Acting Agent → Action → Resource → Scope

This introduces a deeper authorization problem: how authority is delegated between actors.

That problem deserves its own layer rather than being squeezed into the basic execution model.

A Better Mental Model

Instead of:

User → AI → Everything

think about:

User → Intent → AI Agent → Proposed Action → System Controls → Infrastructure

The AI sits inside the system.

It does not become the system.

That gives the architecture a stable control boundary around a component whose behavior is probabilistic.

The model can change.

The model can be upgraded.

The model can be replaced.

The surrounding execution controls can remain.

The Principle

Giving an AI agent more tools does not automatically mean giving it more authority.

The goal is not to prevent AI from acting.

The goal is to separate the ability to propose an action from the authority to execute it.

AI proposes. Systems verify. Infrastructure executes.

And once agents start acting on behalf of other agents, the next question becomes unavoidable:

Who actually has the authority to perform the action?

What If I'm Not Tired of Coding, Just Tired of Starting?

Sina Rezaei — Mon, 05 Oct 2026 05:15:00 +0000

There is a strange state you can reach as a developer.

You still know how to code.

You still understand the logic. You can still look at a problem and roughly see how you would solve it.

But opening the editor feels difficult.

Not writing the code.

Just starting.

And I think that's an interesting distinction.

Maybe sometimes we say:

"I'm tired of coding."

when the real problem is:

"I don't know what I want to build anymore."

Those are not the same problem.

I can build it. But what is "it"?

Give me a real problem and things become easier.

An API needs to receive orders.

A database needs to store them.

A service needs to process them.

A UI needs to expose the result.

Now there is something to push against.

Architecture starts appearing. Trade-offs become visible. You can make decisions.

But give a developer an empty repository and say:

"Build something."

That's different.

Suddenly, knowing five languages doesn't tell you what the first commit should be.

You don't have a programming problem anymore.

You have a direction problem.

And I don't think we talk about that enough.

The first step can be the real problem

One of the interesting things in the discussion around burnout is that people don't always describe the same obstacle.

For some, the answer is rest.

For others, it is finding something interesting again.

Someone even described opening a project, changing one variable, closing it, and repeating that for a few days. The important part wasn't the variable. It was getting past the first few seconds of opening the editor.

That made me think.

What if "starting" is its own problem?

You can have the skill.

You can have the time.

You can even have a project.

And still not cross that tiny gap between:

I should code

and

I'm actually coding.

Maybe the project is the missing piece

There is another possibility.

Maybe the solution isn't another productivity trick.

Maybe there simply isn't a problem worth solving right now.

A developer can be perfectly capable of building something and still have no reason to build it.

And "just make a side project" doesn't really solve that.

What kind of project?

A game?

A SaaS?

A CLI tool?

A portfolio project?

Something useful?

Something technically impressive?

Something completely stupid but fun?

The moment you ask those questions, you realize that "build something" isn't actually a small instruction.

It's a huge one.

Skills can survive when motivation doesn't

This is probably the part I find most interesting.

You don't necessarily forget programming because you stop coding for a while.

You may still remember the syntax.

You may still understand the architecture.

You may still be able to solve the problem once somebody gives you one.

But the connection between "I can build this" and "I want to build this" can disappear.

And maybe that's why some developers don't need another tutorial.

They need something that makes them curious again.

A problem.

An idea.

A person asking for something.

An open-source issue.

An old project that suddenly looks interesting again.

Anything that gives the technical ability somewhere to go.

So how do you start again?

Honestly, I don't think there is one universal answer.

Sometimes the answer might be rest.

Sometimes it might be stepping away from the editor.

Sometimes it might be writing an idea on paper before writing code.

Sometimes it might simply be finding a problem that makes you think:

"Wait... I could actually build that."

And maybe that's the more useful question than:

"How do I become productive again?"

Maybe it's:

"What would make me want to build something again?"

Have you ever reached a point where you still had the skills, but couldn't bring yourself to start?

Was the problem the coding itself, the lack of ideas, or simply having nothing that felt worth building?

Getting to Know Yourself: Understanding self in Ruby

Sina Rezaei — Fri, 02 Oct 2026 09:42:40 +0000

self is one of those Ruby keywords that looks easy until you meet it in real code.

You see it in a setter:

self.name = normalized_name

Then in a class method:

def self.from_cents(...)

Then somewhere inside a DSL or instance_eval, and suddenly the question isn't really:

What does self mean?

The better question is:

Who is self right here?

That small change makes Ruby's object model much easier to follow.

The setter case is where it starts to matter

Consider a model-like object:

class Customer
  attr_accessor :name, :email

  def initialize(name:, email:)
    @name = name
    @email = email
  end

  def normalize
    self.name = name.strip.downcase
    self.email = email.strip.downcase
  end

  def contact
    "#{name} <#{email}>"
  end
end

customer = Customer.new(
  name: "Maya",
  email: "MAYA@EXAMPLE.COM "
)

customer.normalize

puts customer.contact

There is something easy to miss here:

self.name = name.strip.downcase

Why not:

name = name.strip.downcase

Because those two lines are doing different things.

The second one is a local variable assignment.

The first one calls the name= setter on the current object.

Ruby lets us call the getter without explicitly writing the receiver:

name

But assignment creates an ambiguity. When we write:

self.name = ...

we are making the receiver explicit.

In other words:

self.name = "Maya"

means:

Call name= on the object I'm currently working with.

That object is self.

And notice something important.

We didn't create self.

We didn't assign it.

Ruby already knew what self was when normalize started running.

That is the first useful clue.

self is less about a special keyword and more about the object currently receiving the work.

Most of the time, Ruby hides it from you

Take a slightly more realistic object:

class Invoice
  def initialize(customer, total)
    @customer = customer
    @total = total
    @status = :open
  end

  def close
    return false unless valid_for_closing?

    mark_as_paid
    notify_customer
    true
  end

  private

  def valid_for_closing?
    @total.positive? && @status == :open
  end

  def mark_as_paid
    @status = :paid
  end

  def notify_customer
    puts "Invoice notification sent to #{@customer}"
  end
end

Inside close, Ruby sees:

mark_as_paid
notify_customer

You could make the receiver explicit:

self.mark_as_paid
self.notify_customer

But normally there is no reason to.

The receiver is already there.

It is self.

So when Ruby evaluates:

mark_as_paid

the useful mental model is:

self.mark_as_paid

The receiver is implicit.

This is one of those Ruby features that makes code pleasant to read, but it can also hide an important detail.

The receiver isn't missing.

It is invisible.

And that becomes interesting when we start asking when Ruby changes that context.

There are scope gates for `self`

This is where I find it useful to stop thinking about every Ruby construct as if it creates a new self.

It doesn't.

A block is a good example.

Consider:

class Report
  def initialize(rows)
    @rows = rows
  end

  def failed_rows
    failures = []

    @rows.each do |row|
      next unless row[:status] == :failed

      failures << {
        id: row[:id],
        reason: row[:error]
      }
    end

    failures
  end
end

Inside the block:

@rows.each do |row|

row is the block's local value.

It is not self.

And the block does not automatically replace the surrounding self.

So inside that block, self is still the Report instance.

This gives us a useful mental distinction:

Not every nested piece of Ruby code is a new self scope.

A block can introduce local variables and control flow without automatically changing the receiver.

But structures such as:

class ...
module ...
def ...

create important boundaries in how Ruby evaluates code and what self refers to.

And then there are APIs that deliberately change it.

For this article, I'll call these boundaries scope gates. That's a mental model, not an official Ruby term.

The useful idea is simply:

A block is not automatically a self gate. Context-changing constructs and APIs are.

Once you see that, some Ruby behavior that initially feels inconsistent becomes much easier to predict.

And now we can look at the class side.

The same keyword can point at the class

Consider a factory-style class method:

class Invoice
  def initialize(customer, total)
    @customer = customer
    @total = total
  end

  def self.from_cents(customer, cents)
    new(customer, cents / 100.0)
  end

  def summary
    "#{@customer}: $#{format('%.2f', @total)}"
  end
end

invoice = Invoice.from_cents("Maya", 12500)

puts invoice.summary

This line:

def self.from_cents

can look like special Ruby grammar.

It isn't really a separate universe.

The important part is still the receiver.

While Ruby evaluates the body of the class definition, self refers to the Invoice class object.

So:

def self.from_cents

is essentially saying:

Define from_cents on the object currently referenced by self.

And in this context, that object is Invoice.

That is why this works:

Invoice.from_cents(...)

The class itself is an object, and that object can receive method calls.

Now compare the two situations:

invoice.summary

Here the receiver is an Invoice instance.

Invoice.from_cents(...)

Here the receiver is the Invoice class object.

Nothing about the keyword changed.

The context did.

That distinction is much more useful than memorizing "instance method versus class method" as two unrelated Ruby features.

Rails makes this even more visible

You see the same idea constantly in Rails models.

For example:

class Subscription < ApplicationRecord
  scope :active, -> {
    where(status: :active)
  }

  def self.for_customer(customer)
    active.where(customer: customer)
  end

  def cancel!
    update!(
      status: :cancelled,
      cancelled_at: Time.current
    )
  end
end

There are several receivers involved here.

When you call:

subscription.cancel!

the receiver is the subscription instance.

Inside cancel!, the call to:

update!(...)

is being sent to that instance.

But:

Subscription.for_customer(customer)

is sent to the Subscription class object.

And Rails adds another interesting layer with scope.

The block passed to scope is not simply "a new self." The surrounding Ruby context and the way Rails evaluates the scope both matter.

This is why a useful question when reading Rails code is not just:

What method is this?

but:

What object is receiving this method here?

That question scales much better when the code gets more dynamic.

Then `instance_eval` deliberately moves the context

Now we can make the context change explicit.

Consider a configuration object:

class Configuration
  def initialize
    @values = {}
  end

  def [](key)
    @values[key]
  end

  def values
    @values.dup
  end
end

config = Configuration.new

config.instance_eval do
  @values[:environment] = "production"
  @values[:region] = "eu-west"
  @values[:logging] = :verbose
end

puts config[:environment]
puts config[:region]

Why can this block access:

@values

directly?

Because instance_eval evaluates the block with the receiver as self.

Before entering the block, self referred to the surrounding context.

Inside:

config.instance_eval do

self becomes config.

That is a deliberate context change.

And this is where the earlier idea of scope gates becomes useful.

The block itself didn't inherently create a new self.

instance_eval did.

Ruby gives the programmer an explicit mechanism for saying:

Evaluate this code as if this object is the current receiver.

That is a very different thing from simply passing a block around.

`instance_exec` takes the same idea one step further

There is a subtle difference between instance_eval and instance_exec that becomes important when designing DSLs.

Suppose we want to configure an object, but we also want to pass information into the block:

class Endpoint
  def initialize
    @settings = {}
  end

  def settings
    @settings
  end
end

endpoint = Endpoint.new

method = :post
path = "/users"

endpoint.instance_exec(method, path) do |http_method, route|
  @settings[:method] = http_method
  @settings[:path] = route
  @settings[:authenticated] = true
end

puts endpoint.settings

The important part is:

endpoint.instance_exec(method, path) do |http_method, route|

instance_exec changes self to endpoint, just like the context-changing idea we saw with instance_eval.

But it also lets us pass arguments into the block.

So inside the block we have both:

self

pointing at endpoint, and:

http_method
route

coming from the outside.

That combination is useful when building expressive APIs.

It lets a DSL control the execution context without losing the ability to feed the block data.

And suddenly a pattern like:

resource :users do
  method :get
  path "/users"
end

starts looking less magical.

The DSL designer may be combining:

a receiver that becomes self
a block that defines the configuration
arguments or yielded values
method dispatch through that context

The syntax is the surface.

The context is the machinery underneath.

This is why Ruby DSLs can feel strange

Once you start thinking in terms of context, Ruby DSLs become less mysterious.

You might see code that looks almost like configuration:

resource :users do
  path "/users"
  method :get
  authentication :required
end

The interesting question isn't only:

What does resource do?

It is also:

What is self while this block is being evaluated?

Maybe the DSL is yielding to a builder object.

Maybe it is using instance_eval.

Maybe it is using instance_exec because it needs both a changed receiver and arguments.

Maybe it is delegating method calls.

The surface syntax can look almost identical while the underlying execution model is very different.

That's why self becomes particularly useful when reading metaprogramming-heavy Ruby.

Instead of getting stuck on the syntax, look for the receiver.

Then look for the context.

Then look for the point where that context changes.

So, who is `self`?

I don't think of self as a definition I need to memorize anymore.

I think of it as a signpost.

When I see:

self.name = value

I ask:

Which object is receiving this assignment?

When I see:

def self.build

I ask:

What is self while Ruby is evaluating this class body?

When I see:

something.instance_eval do

I ask:

Did Ruby just change the receiver for this block?

When I see:

something.instance_exec(data) do |value|

I ask two questions:

What is self now?

and:

What data was passed into this context?

And when I see a Ruby DSL that seems to have methods appearing out of nowhere, I ask:

Who is self here, and where did that context come from?

That question usually gets me closer to the actual behavior than simply remembering what the keyword means.

Because self isn't really the interesting part.

Context is.

Once you start reading Ruby through that lens, self becomes less of a keyword to memorize and more of a way to locate yourself inside Ruby's object model.

And I'm curious how other Ruby developers approach this.

Do you consciously think about self while reading Ruby code, or has it become one of those things you only notice when the context suddenly changes?

OAuth 2.0 Device Flow: How Authentication Works When the Device Can't Handle the Login

Sina Rezaei — Thu, 24 Sep 2026 14:03:49 +0000

Authentication is straightforward when a user has a browser, keyboard, and screen.

A laptop can open a login page. A phone can redirect the user to an identity provider. But what happens when the device is a Smart TV, game console, CLI tool, or another device that is not well suited for entering credentials?

This is where the OAuth 2.0 Device Authorization Grant, commonly called Device Flow, becomes useful.

Instead of asking the device to handle the login itself, Device Flow lets the user authenticate on another device while the original device waits for the result.

The basic idea

The device starts the authentication process and receives a set of temporary values from the authorization server.

The user then opens a verification URL on a phone or computer, enters a short code, and completes authentication there.

The original device does not need to display or process the full login interface.

The flow looks roughly like this:

Device
   |
   |  Device Authorization Request
   v
Authorization Server
   |
   |  device_code + user_code
   v
Device
   |
   |----------------------> User's Browser / Phone
   |                         |
   |                         | Login + consent
   |                         v
   |                    Authorization Server
   |
   |  Poll Token Endpoint
   v
Authorization Server
   |
   |  Access Token
   v
Device

The important part is that the device and the user's browser do not have to be the same device.

What the device receives

The device first sends a request to the authorization server's device authorization endpoint.

The response typically contains values such as:

{
  "device_code": "4fJ8...",
  "user_code": "WDJB-MJHT",
  "verification_uri": "https://example.com/device",
  "expires_in": 600,
  "interval": 5
}

The important fields are:

device_code: identifies the authentication request and is used by the device when requesting tokens.
user_code: a short code the user enters on another device.
verification_uri: where the user goes to authenticate.
expires_in: how long the authorization request remains valid.
interval: how often the device should poll the token endpoint.

The device_code and user_code serve different purposes.

The device keeps the device_code. The user normally only sees the user_code.

The user finishes authentication somewhere else

The device can now display something like:

Open:
https://example.com/device

Enter code:
WDJB-MJHT

The user opens the URL on a phone or computer, enters the code, signs in, and approves the requested access.

Nothing special has to happen on the original device while this is taking place.

It simply waits.

The device polls for the token

After receiving the device authorization response, the device starts polling the token endpoint.

For example:

POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:device_code
&device_code=4fJ8...
&client_id=my-device

If the user has not finished authentication yet, the authorization server can return:

{
  "error": "authorization_pending"
}

The device waits and tries again.

It should not continuously hammer the server. The server can also return:

{
  "error": "slow_down"
}

which tells the client to increase the polling interval.

Once the user has successfully authenticated and granted access, the response contains the token:

{
  "access_token": "eyJ...",
  "token_type": "Bearer",
  "expires_in": 3600
}

The device can then use that access token to call the protected API.

What can happen while the device waits?

The device needs to handle more than just success and authorization_pending.

Common responses include:

Response	Meaning
`authorization_pending`	The user has not finished yet
`slow_down`	Poll less frequently
`expired_token`	The device authorization request expired
`access_denied`	The user rejected the request

This is important because Device Flow is inherently asynchronous.

The device cannot assume that authentication will finish immediately, or even finish successfully.

Why use a separate user code?

You might wonder why the user does not simply enter the long device_code.

The answer is usability.

A device_code is intended to be handled by the device and can be long or difficult to type. The user_code is designed for humans and is usually much shorter.

That separation also lets the authorization server associate the human-friendly code with the underlying authorization request without exposing the device's internal identifier as the thing the user has to type.

Security still matters

Device Flow solves an authentication-interface problem, but it does not remove the security requirements around authentication.

The verification endpoint should protect against things such as:

brute-force attempts against short user codes
excessive requests
reuse of expired or already-consumed codes
unauthorized access to the authorization request
overly long-lived device codes

User codes should have limited lifetimes and a sufficiently large search space. Once a code has been successfully consumed, it should not remain usable.

The server also needs to handle concurrent requests safely. Two requests attempting to consume the same authorization state should not both be able to obtain authorization.

Device Flow vs. PKCE

Device Flow and Authorization Code Flow with PKCE solve related but different problems.

PKCE is useful when the client can redirect the user through a browser but needs protection against authorization-code interception.

Device Flow is useful when the device itself is not a practical place to perform the browser-based login.

A CLI application is a good example:

CLI
 |
 | "Go to this URL and enter this code"
 v
Browser
 |
 | Login + consent
 v
Authorization Server
 |
 v
CLI receives token

Trying to force a full browser login experience into a terminal would make the client unnecessarily complicated.

Device Flow moves that responsibility to a device that is actually good at it.

Where Device Flow makes sense

You will commonly see this pattern with:

Smart TVs
game consoles
command-line applications
media players
IoT devices
devices with limited input capabilities
applications where the authentication device and usage device are different

The common characteristic is not necessarily weak hardware.

It is that the device is a poor place to perform interactive authentication.

A practical implementation checklist

When implementing Device Flow, make sure the client:

stores the device_code securely
displays the verification URI and user code clearly
respects the polling interval
handles authorization_pending and slow_down
stops when the request expires
handles user denial
securely stores the resulting access token

The authorization server should, at minimum:

expire device authorization requests
rate-limit verification and token endpoints
prevent user-code guessing and abuse
ensure authorization state cannot be reused incorrectly
issue tokens only after the required user authorization has completed

The bigger engineering idea

Device Flow is a useful example of a broader engineering principle.

A component does not have to perform every part of a process itself.

A Smart TV is good at displaying content, but terrible at typing a password with a remote control. A CLI is excellent for commands, but not necessarily for interactive web authentication.

Instead of forcing the device to do something badly, Device Flow gives each part of the system a job it is better suited to perform:

Device       → starts the request and waits
Browser      → handles interactive authentication
Server       → manages authorization and tokens
Device       → uses the resulting access token

That separation is what makes the flow practical.

OAuth 2.0 Device Flow is therefore less about adding another authentication screen and more about moving authentication to the place where it can be performed properly.

Navigating the Landscape of Development: Building a Sustainable Future

Sina Rezaei — Fri, 24 Nov 2023 13:24:43 +0000

When people hear sustainable development, software engineering probably isn't the first thing that comes to mind.

Usually, we picture renewable energy, electric cars, green buildings, or a company presentation full of words like impact, future, and responsibility.

But there is another side of sustainability that developers and architects deal with every day.

It's what happens when your application gets 10x 4 more infrastructure?

Does a database query suddenly become 20 times more expensive?

Are you keeping machines running when nobody is using them?

Are you storing years of data that nobody reads?

And perhaps the uncomfortable one: did the system become more complicated simply because the team kept adding things?

That's where sustainability becomes an engineering problem rather than a marketing concept.

For me, sustainable software is mostly about building systems that don't constantly need more resources just to keep doing the same job.

1. Economic Sustainability: Fix the System Before Buying More Infrastructure

One of the easiest ways to waste money in software is to treat infrastructure as the solution to every performance problem.

The application is slow?

Add CPU.

Database is struggling?

Buy a bigger instance.

Traffic increased?

Add more servers.

Memory usage is high?

Throw RAM at it.

Sometimes that's exactly the right decision. But sometimes you're just paying more to hide a bad design.

AWS's Well-Architected Framework treats cost optimization and performance efficiency as separate but connected architectural concerns. Its guidance specifically recommends considering cost during architectural decisions, right-sizing resources, and continuously reviewing the resources that drive infrastructure spending.

A simple example is a database query.

Imagine something like:

SELECT *
FROM orders
WHERE customer_id = 18472
ORDER BY created_at DESC;

If customer_id isn't indexed properly, the application might still work perfectly with 500 records.

Then the database gets millions of rows.

Suddenly the same innocent-looking query becomes a production problem.

You can increase the database size, or you can ask a much better question:

Why is the database doing this much work in the first place?

Adding the right index, changing the query, reducing unnecessary columns, or redesigning how the data is accessed can sometimes remove the bottleneck without buying a larger machine.

That's sustainable architecture in a very practical sense.

You're making the system do less work.

Don't confuse scalability with throwing hardware at the problem

There's nothing inherently wrong with horizontal scaling, containers, serverless functions, or managed infrastructure.

The problem starts when infrastructure becomes a substitute for engineering.

A lightweight service that scales from 2 instances to 20 because demand actually increased is one thing.

A service that needs 20 instances because every request triggers unnecessary database calls is another.

The difference is architectural.

The same idea applies to serverless systems. Serverless isn't automatically "green", and containers aren't automatically efficient either. The actual workload matters.

A badly designed function running millions of unnecessary operations is still badly designed, even if it happens to be running in a serverless platform.

Reuse before rewrite

There's another form of sustainability that gets less attention: the codebase itself.

Not every old module needs to be rewritten.

Sometimes refactoring a painful component is enough.

A full rewrite means rebuilding behavior, tests, integrations, deployment pipelines, monitoring, edge cases, and all the strange little things the original system learned over the years.

Sometimes you absolutely should rewrite.

But "let's rewrite everything" shouldn't be the default response to technical debt.

A sustainable codebase is one that can evolve without requiring the team to burn down the entire house every few years.

2. Social Sustainability: The System Has Humans in the Loop

Here's something easy to forget when talking about architecture:

The people maintaining the system are part of the system.

If only one developer understands how authentication, payments, deployment, and database migrations work, you don't have a resilient architecture.

You have a knowledge bottleneck.

And eventually that bottleneck becomes a production risk.

Imagine a developer leaves the company.

Nobody knows why a particular service exists.

Nobody knows why a specific queue has a strange retry policy.

Nobody knows why deleting one database column breaks an unrelated reporting system.

The documentation says:

"Legacy logic. Don't touch."

That's not documentation.

That's a warning label.

Reduce knowledge silos

Good architecture isn't only about separating services.

It's also about making the system understandable.

Clear boundaries, useful documentation, sensible naming, tests, diagrams where they actually help, and explicit ownership all reduce the amount of tribal knowledge required to work on a system.

Domain-Driven Design can help here because it encourages teams to make business boundaries explicit instead of allowing everything to slowly become one giant blob of shared logic.

You don't need DDD everywhere.

A small application doesn't need a 40-page architecture document.

But when the domain becomes complicated, making the boundaries visible can save a lot of pain later.

Architecture should be discussable

Another useful practice is the architecture decision record, RFC, or similar design-review process.

The important part isn't the acronym.

It's the habit of writing down:

What are we trying to solve?
What options did we consider?
What are the trade-offs?
Why did we choose this approach?
What could make us change the decision later?

That creates something much more valuable than a diagram nobody reads six months later.

It creates context.

And context is extremely useful when the original author isn't in the room anymore.

3. Accessibility Is Also Part of Sustainability

There is another human side that often gets left out of the conversation: accessibility.

A system that works beautifully for one group of users but becomes difficult or impossible to use for others isn't particularly sustainable from a product perspective.

The W3C's WCAG framework organizes accessibility around four principles: perceivable, operable, understandable, and robust.

That translates into very practical engineering decisions.

Can someone navigate the interface with a keyboard?

Does the form provide useful error messages?

Do buttons and controls have meaningful labels?

Does the application still work with assistive technologies?

Does the interface remain usable when the screen is zoomed?

These aren't just "frontend polish" issues.

They affect whether a product remains usable as its audience grows and as devices, browsers, and user needs change.

4. Environmental Sustainability: Software Still Runs on Physical Machines

This is where the conversation gets interesting.

Software feels abstract.

It's code.

It's APIs.

It's containers.

It's a Git repository.

But eventually, every instruction ends up running on physical hardware.

CPU cycles consume electricity.

Memory consumes electricity.

Storage consumes electricity.

Networking consumes electricity.

Data centers also require cooling and other infrastructure.

The Green Software Foundation's current work frames software sustainability around things such as energy efficiency, carbon efficiency, carbon awareness, hardware efficiency, and measurement.

So a useful question isn't simply:

"Is my application green?"

A better question is:

"How much physical work does my software require to deliver one unit of useful work?"

That changes how you look at optimization.

A database query is not just a database query

Suppose an endpoint loads 50,000 database rows, processes them in application memory, and finally returns 20 records.

It works.

But why did the application process 50,000 records to return 20?

Maybe the filtering belongs in the database.

Maybe pagination is missing.

Maybe the query needs an index.

Maybe the API is returning fields the client doesn't need.

The improvement isn't about making the code look prettier.

You're reducing actual work.

And that can mean less CPU time, less memory pressure, less I/O, less network traffic, and potentially less infrastructure.

That's a much more interesting definition of optimization.

Caching is useful, but it isn't magic

Caching can be another example.

If thousands of users request the same expensive piece of data, repeatedly calculating it or hitting the database for every request doesn't make much sense.

A cache such as Redis can reduce repeated computation and database traffic.

But caching everything isn't sustainable either.

Now you have another system to operate.

You have memory consumption.

You have cache invalidation.

You have synchronization problems.

You have stale-data decisions.

So the question shouldn't be:

"Can we add Redis?"

It should be:

"Where is repeated work happening, and is caching actually the cheapest way to remove it?"

That's a very different architectural conversation.

5. Measure the Work Instead of Guessing

One of the most useful developments in green software engineering is the move toward measurement.

The Green Software Foundation's Software Carbon Intensity specification, for example, provides a methodology for measuring the carbon impact of software and explicitly considers energy, hardware, and carbon intensity rather than treating "green" as a vague label.

You don't necessarily need to calculate a carbon score for every API endpoint tomorrow.

But the underlying idea is valuable:

measure something.

For example:

CPU time per request
memory usage
database queries per request
data transferred per request
storage growth
average response size
infrastructure utilization
energy consumption where measurable

Even a simple metric can expose waste.

If version B performs the same business operation with half the database queries and 30% less compute, you've got evidence.

Now optimization becomes engineering instead of storytelling.

6. Carbon Awareness Changes the Question

There's an interesting concept in green software that goes beyond simply making software more efficient: carbon awareness.

Not all electricity has the same carbon intensity at every location or every moment.

The Green Software Foundation describes carbon-aware computing as doing more when electricity is cleaner and less when it is more carbon-intensive.

That creates some interesting possibilities.

Imagine you have a batch workload that doesn't need to finish immediately:

generating large reports
processing analytics
training certain models
rebuilding indexes
running backups
processing large datasets

If the workload can safely move to a different time or region, the system could potentially run it when the electricity supply has a lower carbon intensity.

The Carbon Aware SDK is one example of tooling built around this idea, including choosing when or where workloads run based on emissions data.

Obviously, you don't apply this to everything.

A payment API can't simply tell a customer:

"Sorry, the grid looks dirty right now. Try again tomorrow."

Real-time systems have real-time requirements.

That's where architectural trade-offs matter.

7. Sustainability Is Mostly About Trade-offs

This is probably the part I find most interesting.

There isn't a universal architecture that is simultaneously:

cheapest
fastest
simplest
most reliable
most secure
easiest to maintain
and lowest-carbon

You usually have to choose.

AWS itself describes Well-Architected as a framework built around six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. The framework explicitly recognizes that architectural decisions involve trade-offs based on business context.

For example, keeping extra infrastructure running may cost more, but it can make a mission-critical system more resilient.

Compressing everything may reduce bandwidth, but CPU usage can increase.

Aggressive caching may reduce database work, but increase memory usage.

Moving a workload to a cleaner region may reduce carbon impact, but introduce latency or compliance issues.

So "sustainable" doesn't mean blindly minimizing one number.

It means understanding the system well enough to make deliberate trade-offs.

Bottom Line

For me, sustainable software development comes down to a pretty simple idea:

Don't make the system work harder than it needs to.

That applies to infrastructure.

It applies to databases.

It applies to network traffic.

It applies to storage.

It applies to architecture.

And it even applies to the people maintaining the code.

If a system needs more servers every time the user count increases, ask why.

If the database is doing millions of unnecessary operations, investigate.

If nobody understands a critical service except one person, fix the knowledge bottleneck.

If you're storing data nobody will ever use again, question it.

If a workload can move to a cleaner time or location without affecting the business, maybe let it.

Sustainability isn't a green badge you attach to an architecture diagram.

It's what happens when engineers start treating resources, people, infrastructure, and long-term maintainability as part of the same system.

And honestly, that's probably a better definition of good engineering anyway.

Update Note

Originally published in 2023. Updated in October 2026 with deeper coverage of system architecture, cloud efficiency, green software engineering, accessibility, carbon awareness, measurement, and real-world engineering trade-offs.

DEV Community: Sina Rezaei

Your AI Pentester Found an SSRF. Can It Reproduce the Attack?

The SQL NOT IN Trap: When NULL Quietly Breaks Your Query

When NOT IN stops behaving as expected

Why NOT EXISTS is often a better fit

The multi-tenant bug hiding behind the SQL

What about NULL in the outer table?

The tests I'd add before shipping this

The real lesson

The JavaScript We Never Questioned

How Much Coding Do You Actually Need in the AI Era?

My AI Agent Passed Every Test. The Feature Was Still Wrong.

The billing bug that wasn't really fixed

The test can be green for the wrong reason

This is where I stop trusting the green checkmark

There's research behind this, too

So what should the agent actually be allowed to change?

Here's the question I keep coming back to

The Ariadne Thread: Why AI Fails to Follow the Path You Define

The Pattern Trap: When a Familiar Solution Is Not Enough

A Full-Stack Scenario: The Duplicate Payment Problem

What the Analysis Should Actually Examine

1. Give the operation a stable identity

2. Handle the ambiguous outcome

3. Protect the operation's state transitions

The Actual Test: Did the Model Follow the Instruction?

The Instruction–Execution Gap

The Ariadne Thread

Beyond Fat Controllers: Using the Facade Pattern in Ruby on Rails

From a Fat Controller to a Facade

Introducing the Facade

The Detail That Matters: Failure Handling

Testing the Workflow

When Should You Use a Facade?

AI Should Propose. Systems Should Verify.

AI Should Propose. Systems Should Verify.

The Problem With Direct Execution

Put a Boundary Between Reasoning and Execution

Passing Tests Does Not Mean Permission

Powerful Agents Do Not Need Unrestricted Authority

Think in Actions, Not Just Tools

When Agents Start Delegating

A Better Mental Model

The Principle

What If I'm Not Tired of Coding, Just Tired of Starting?

I can build it. But what is "it"?

The first step can be the real problem

Maybe the project is the missing piece

Skills can survive when motivation doesn't

So how do you start again?

Getting to Know Yourself: Understanding self in Ruby

The setter case is where it starts to matter

Most of the time, Ruby hides it from you

There are scope gates for self

The same keyword can point at the class

Rails makes this even more visible

Then instance_eval deliberately moves the context

instance_exec takes the same idea one step further

This is why Ruby DSLs can feel strange

So, who is self?

OAuth 2.0 Device Flow: How Authentication Works When the Device Can't Handle the Login

The basic idea

What the device receives

The user finishes authentication somewhere else

The device polls for the token

What can happen while the device waits?

Why use a separate user code?

Security still matters

Device Flow vs. PKCE

Where Device Flow makes sense

A practical implementation checklist

The bigger engineering idea

Navigating the Landscape of Development: Building a Sustainable Future

1. Economic Sustainability: Fix the System Before Buying More Infrastructure

Don't confuse scalability with throwing hardware at the problem

Reuse before rewrite

2. Social Sustainability: The System Has Humans in the Loop

Reduce knowledge silos

Architecture should be discussable

3. Accessibility Is Also Part of Sustainability

When `NOT IN` stops behaving as expected

Why `NOT EXISTS` is often a better fit

What about `NULL` in the outer table?

There are scope gates for `self`

Then `instance_eval` deliberately moves the context

`instance_exec` takes the same idea one step further

So, who is `self`?