DEV Community: Aharon Hyman

Beyond the 54-Second Timeout: Deterministic Infrastructure for Non-Deterministic AI

Aharon Hyman — Tue, 04 Aug 2026 09:37:46 +0000

We’ve all seen the tutorials. You build an AI agent using standard async/await loops and a framework like LangGraph or CrewAI. You test it locally, it queries a vector store, calls an LLM, runs a tool, and prints a neat answer. Magic!

Then you try to ship it to production.

Suddenly, your 5-step agentic workflow takes 45 seconds to execute—or 3 minutes if an LLM rate-limits or a third-party tool stutters. Before you know it, Cloudflare, your API Gateway, or a load balancer abruptly severs the connection with a 504 Gateway Timeout.

Your client gets an error, your state disappears into the ether, but somewhere in the cloud, an orphaned worker is still churning through expensive GPT-4o tokens.

Stepping Out of the Frontend Comfort Zone
As a frontend developer, my world usually revolves around state management in the browser, component lifecycles, and rendering snappy user interfaces. But while recently grinding system design for interviews—pushing myself deep into backend distributed systems, saga patterns, and event-driven architectures—an "aha!" moment hit me.

I realized that as an industry, we are trying to force long-running, non-deterministic AI agents into traditional HTTP request/response paradigms, and the seams are bursting.

When an agent execution spans minutes across an open HTTP pipeline, you run into three critical failure modes:

Aggressive Proxies: Load balancers, Nginx, and cloud gateways hate long-lived idle connections. They will kill them.
Brittle Execution: If a worker node crashes on Step 4 of 5, the client gets a blank failure. You lose the context, but you still pay the bill for Steps 1 through 4.

Resource Starvation: Keeping open connection threads on your application servers while an LLM streams or waits on tool execution degrades server concurrency for everyone else.

The "Standard" Fix: SQS/Kafka + Postgres (And the Maintenance Trap)
Any backend engineer looking at this problem will immediately say: "Easy. Decouple it! Throw SQS or Kafka in front, return an HTTP 202 Accepted with a job_id, and process it asynchronously."

It sounds great on a whiteboard. But as you build it, you quickly realize you aren't just building an agent—you're accidentally building a custom, fragile workflow engine.

To make this DIY architecture work for an agent, you now have to write and maintain:

Manual Checkpointing: Writing explicit code to serialize and save the agent state to Postgres after every single LLM call or tool execution. Miss one checkpoint, and a restart wipes out progress.
Complex Lock Management: Row-level locks in Redis/Postgres so two worker pods don't accidentally execute the same step concurrently ("This is getting out of hand! Now there are two of them!").
Retry & Deduplication Overhead: SQS gives you at-least-once delivery. If a worker dies mid-tool execution, the message is re-delivered. Without strict idempotency layers, you re-run expensive LLM calls and repeat side effects.
Human-in-the-Loop Headaches: Want your agent to pause for human approval before sending an email or executing code? Queues aren't built to arbitrarily sleep or wait for days without complex polling daemons or secondary cron systems.

You end up spending 70% of your time writing glue code, retry logic, and state management, and only 30% on actual AI capabilities.

The Temporal Epiphany: Code as the State Machine
This brings us to Temporal.io. Instead of stitching together queues, cron jobs, retry topics, and database state tables, Temporal introduces a paradigm where your code itself is the durable state machine.

Temporal separates your logic into Workflows (deterministic orchestration graphs) and Activities (non-deterministic side effects, like LLM calls, vector searches, and tool executions).

Here is why this architecture fits Agentic AI like a hand in a custom-tailored Mandalorian gauntlet:

Decoupled HTTP Out of the Box
When a client triggers an agent, your API calls client.workflow.start(AgentWorkflow, args) and immediately returns a workflow_id in 10 milliseconds. The HTTP connection closes cleanly, and the client can stream logs or poll progress independently while Temporal orchestrates the backend execution.
Killing the "Hanging Spinner": Real-Time Progress for Complex Workflows
With a frontend hat on, we know that user perception of performance is heavily driven by feedback.
When an AI agent takes 45 seconds to plan, search vector databases, execute code, and synthesize an answer behind a traditional blocking HTTP call, the best you can usually offer the user is a generic, hanging loading spinner.
Is the application frozen?
Did the server crash?
Should I refresh the page?

Without granular feedback, users lose trust and abandon the action.
Turning Workflow Events into UI State

Because Temporal workflows are structured into discrete, typed Activities, you get step-by-step progress events practically out of the box.

Instead of hiding execution inside a black-box server loop:

Immediate Feedback: The client gets a 202 Accepted response with a workflow_id in milliseconds, immediately swapping the UI state from "Submitting" to "Processing".
Step-by-Step Progress Updates: As the Temporal workflow executes each Activity (e.g., Activity 1: SearchDocs, Activity 2: RunCodeTool), the backend can stream progress events over WebSockets or Server-Sent Events (SSE).
Deterministic UI State Machines: On the frontend, you map these workflow progress signals directly to your UI components (like a step progress bar or live agent activity log).

By pairing Temporal’s durable execution backend with a streamed client interface, you replace the hanging spinner with a transparent, reactive stream of progress. The user sees exactly what the agent is thinking and doing in real time—all while the underlying HTTP connections remain lightweight and safe from network timeouts.

Replayability = Determinism in Execution + Token Savings This is Temporal's real superpower. Temporal maintains an Event History of every Activity completed.

If an agent worker node abruptly dies or is re-deployed on Step 5 of an autonomous loop:

Temporal spins up a new worker.
It replays the workflow code from the beginning.
When it hits Steps 1 through 4, it notices they are already in the Event History. It skips re-executing those activities, instantly injects the cached results, and picks up execution right at Step 5.

Because completed LLM calls are locked into the Event History, the agent cannot hallucinate a new branch or choose a different path for steps that already succeeded. You get guaranteed execution continuity and zero wasted API tokens.

TEMPORAL ARCHITECTURE:

Native "Human-in-the-Loop" Need a human to review the agent's drafted report before publishing? You don't need a custom database flag or a polling service. In Temporal, you literally write:

// Pause the agent workflow until a human signal is received await workflow.condition(() => isApprovedByHuman);

The workflow can sleep for 5 seconds or 5 weeks without consuming CPU or memory. When the human clicks "Approve" on your dashboard, a Signal is sent to Temporal, and the agent resumes right where it left off.

Conclusion
Stepping outside my frontend comfort zone to study backend systems design opened my eyes to how brittle modern AI architectures really are.

LLMs bring the power of non-deterministic reasoning, but building production-ready applications requires deterministic execution guarantees.

If you are building complex agents, stop holding HTTP requests open, and stop trying to build a custom state machine out of SQS queues and Postgres tables. That path leads to the Dark Side.

Let LLMs handle the reasoning, and let Temporal handle the state, retries, UI progress streaming, and execution guarantees. Your infrastructure team—and your cloud bill—will thank you.

Have you encountered timeout or state issues while deploying AI agents? What architectural patterns are you using to bring determinism to your LLM workflows? Let me know in the comments!

Beyond the Vibe: Why “Secure by Default” is the Only Way to Build in 2026

Aharon Hyman — Mon, 11 May 2026 07:39:11 +0000

Beyond the Vibe: Why "Secure by Default" is the Only Way to Build in 2026

We’ve all been there. You’re trying to complete a simple task—in my case, registering my son for a Judo seminar—and the page hangs. As a developer, your instinct isn't to refresh; it's to open the Network Tab.

What I found wasn't just a bug. It was a window into a growing problem in the era of "vibe coding" and rapid-fire deployment.

The Discovery: A Judo Chop to Data Privacy

The landing page for this event was built using a popular third-party "vibe coding" platform. These tools are incredible for speed, allowing users to describe a functional app and see it come to life in seconds. However, speed without a safety net is a liability.

By inspecting the network traffic to see why the registration was failing, I realized the API wasn't just sending my son's data—it was capable of sending everyone's. Using Postman, I confirmed the worst: I had full CRUD (Create, Read, Update, Delete) access. I could have wiped the entire event roster or modified participant details with a few clicks.

The Root Cause: The Danger of Permissive Defaults

The platform offered a simple toggle: [Allow All Users] vs. [Admins Only]. By default, it was set to "Allow All Users." This is the "Default-Allow" trap. It assumes the developer will remember to lock the doors later. But if a door starts unlocked, it usually stays unlocked.

How Sticklight Handles This

Short answer: Sticklight defaults to "Deny All" by design.

Seeing this failure in the wild made me reflect on our own architecture. Here is the breakdown of how we prevent this exact scenario:

Row Level Security (RLS) is Mandatory

When Cloud Backend is enabled in Sticklight, every table has RLS enabled by default. With RLS enabled and no policies defined, the default behavior is a total lockdown:

SELECT/INSERT/UPDATE/DELETE: All Denied.

This is the polar opposite of the "Allow All Users" default. In Sticklight, if a developer forgets to add policies, users get a 403 error—not access to the entire database.

Policies Must Be Explicitly Created

The AI agent is built with a security-first mindset. It is instructed to:

Never disable RLS.
Never create USING (true) policies unless data is genuinely public.
Always scope user data with user_id filters.
Create the minimum necessary permissions.

Example: The Judo Registration Table

If this seminar page had been built in Sticklight, the generated SQL would look like this:

-- RLS is enabled by default. -- Policy: Users can only see their OWN registration. CREATE POLICY "Users can view own registration" ON registrations FOR SELECT USING (user_id = auth.uid());

In this scenario, an attacker inspecting the network tab would only see their own data. The "vibe" remains the same for the user, but the data remains private.

The Failure Mode Comparison

Scenario	Other "Vibe" Platforms	Sticklight
Default setting	"All Users" (permissive)	No access (deny all)
Forgot to configure	Full CRUD for everyone	403 Forbidden
Failure mode	Silent data breach	Broken feature (visible)

Pro-Tip: How to "Vibe Code" Without Leaking Data

If you’re building your own apps from scratch using AI agents (like Claude Code, Replit Agent, or Cursor), you are the primary architect. Here’s how to ensure your vibe stays secure:

Use Security-First Prompting: Specifically instruct the AI to use Secure-by-Default patterns and assume the frontend is untrusted.
Establish a Security Rubric: Maintain a persistent CLAUDE.md or instructions file that mandates RLS and 403-by-default behavior.
The "Postman Audit": Never trust the UI. Manually test your API endpoints with tools like Postman to ensure they don't leak data when unauthenticated.
Review Every Diff: Look specifically for cases where the agent might have simplified a policy or left a "TODO" on an authentication check.

Conclusion

As we move toward AI-generated boilerplate and "vibe-driven" development, the responsibility shifts to the platform architect. At Sticklight, we believe a "broken" feature is a ticket, but a "broken" security setting is a catastrophic liability. By choosing a "Deny All" default, we ensure that the path of least resistance for a developer is also the safest one for the end user.

CodeSandbox init shortcuts

Aharon Hyman — Wed, 06 Jan 2021 12:52:44 +0000

Fun new find of the day
Type into browser URL: “http://js.new”, “http://vue.new”, “http://react.new”, “http://ng.new”, “http://ts.new”
You will get full environment to play around in.

Imposter syndrome & at what point did you realise you where a developer

Aharon Hyman — Sun, 29 Nov 2020 19:59:38 +0000

Imposter syndrome is something I have often felt in my journey to becoming a developer.
I am self taught (mostly), and was lucky to be given a chance at a growing start up (Strattic).
My first few weeks where filled with fake it until you make it, with many late nights and LOOOOTS of caffeine. But I after a couple of weeks I sat down with the team to show what I had achieved and I amazed myself.
I look back on that code now and laugh, and am amazed that not only does it still work but some of that code still on production (with a lot of refactors and help from much more experienced devs).
Did you have an AH HA! moment when you suddenly realised you where keeping up with the big boys?

Maintaining a company culture while working from home?

Aharon Hyman — Sun, 15 Nov 2020 11:54:29 +0000

Company culture at home.

Has your company switched to remote work?
Have you made any changes to your company culture to fit in with a remote environment?
Do you find your life-work balance has shifted as a result of remote work?

I will start :D.
Our company values our work culture and has spent time supporting us whether with assistance to set up a home office or with increased social interactions 'online'.
We moved out weekly happy hour online and try to spend some time catching up with each other outside of our regular meetings.
A big one for me was encouraging everyone to have their videos on during meetings, it helps you feel like you are talking with colleagues and humans, not just talking to a computer. Even if it means you have to get more formal looking PJ's!
Being at home especially during lockdown has meant that putting in a full work day can sometimes not be so easy, especially with little kids around. Work being flexible and allowing for make up hours in the evenings is a big help.

Why I will no longer be using console.log() to check React state updates

Aharon Hyman — Wed, 11 Nov 2020 09:05:15 +0000

As a front end developer one of the key tools in my debugging arsenal is the console log. The ability to log data and check that it renders as expected in the browser allows you to quickly debug specific parts of your code in a quick and neat fashion.

I work in React and being able to console log your state and check that the components are rendering as expected is a key development pattern.

When your state is simple and you have one or two values to monitor, console.log() is great but when you start adding more to your component state especially in a Class component this can start getting very ugly as your state object being output is minified.

Console.table()

Console.table is a great way of logging to the console that will parse your data and log in the console as a table.

Using the console in Chrome dev tools we can see console.table() at work

The function console.table() takes either an array or an object and can also take an optional parameter ‘columns’

The first column will be labelled index and in the case of an array it will display the indices, while an object will display the Key or property names.

The table also works as you would expect allowing you to sort the column by clicking on the title.

Note that in Firefox console.table() is currently limited to 1000 rows

Columns
Where this really comes in useful is the columns parameter.
As a default the columns.table() will list all the elements in an object. The columns parameter takes an array of column names or values and allows you to select the values you would like displayed. By using this you are able to parse an array of large objects and select only the columns relevant to you.

Logging your state!
Going back to React, a common pattern is to store a server response in your state, often there is data involved that will not be used in the component you are working on.
Using the columns parameter you can display in the console only the columns of data that you are actually watching

Lets see what that looks like
In the below example our api call returns a json of users and they are stored in the state.
Using console.table(users) in the render we will be able to produce the below table and check the data is as expected, without having to build out our table component in the ui.

Now if we wanted to build a quick filter button to check which of our clients paid in Yuan Renminbi we could do the following



const onlyYuanUsers = users.filter( user => user.currency === "Yuan Renminbi")
console.table(onlyYuanUsers)

this will produce a filtered table to check it returns the values you need.

But this is more data than you need to display to check your filter is working.

By passing in the columns parameter, you are able to select which columns you want to select by defining an array of the column names.

The output will be a more compact table allowing for an ‘at a glance’ comparison.



console.table(onlyYuanUsers, ['id', 'currency'])

It is worthy of note that as of publishing console.table() is supported by all modern browsers with the exception of IE (I did say modern)