Coder Legion - Recent posts tagged loop

AWS Step Functions: Creating a ‘Busy Waiting’ flow to wait for successful lambda executions.

Wed, 14 Oct 2026 18:01:55 +0000

Hi everyone, welcome to this article. In the past few days, I had to create a logic in AWS Step functions which involved waiting for a lambda that queries athena before going forward in the flow.

When I was discussing the logic, it felt like an easy thing to accomplish in minutes but I was surprised upon knowing that Step Functions does not have its native technique/solve to wait for a state to succeed before starting another. This made me search for hours before coming up with a solution.

Here, I will share with you a technique which will help you in the future.

First of all, I will create a simple lambda function. All we need to know from the lambda is whether it did its job. So, this simple function will make sure to return its status.

Lambda function:

import json

def lambda_handler(event, context):
    response = {
        'status': 'success',
        'message': 'Hello, World!'
    }
    
    return response

You can copy both the function and the Step function definition which I will share below to replicate all of this in your own environment.

Now, lets go ahead and create a state machine in AWS Step Functions.

Click on ‘Create state machine’.

Choose the option to write your own definition and choose ‘standard’.

Now, in the definition section, copy and paste the following definition.

Step Functions definition:

{
  "Comment": "A Hello World example of the Amazon States Language using Pass states",
  "StartAt": "Main",
  "States": {
    "Main": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke",
      "OutputPath": "$.Payload",
      "Parameters": {
        "Payload.$": "$",
        "FunctionName": "arn:aws:lambda:us-east-1:031342435657:function:stepfunctionlambda_test:$LATEST"
      },
      "Retry": [
        {
          "ErrorEquals": [
            "Lambda.ServiceException",
            "Lambda.AWSLambdaException",
            "Lambda.SdkClientException",
            "Lambda.TooManyRequestsException"
          ],
          "IntervalSeconds": 2,
          "MaxAttempts": 6,
          "BackoffRate": 2
        }
      ],
      "Next": "WaitforInvocation"
    },
    "WaitforInvocation": {
      "Type": "Wait",
      "Seconds": 2,
      "Next": "CheckInvocationsStatus"
    },
    "CheckInvocationsStatus": {
      "Type": "Choice",
      "Choices": [
        {
          "Variable": "$.status",
          "StringEquals": "success",
          "Next": "Final"
        }
      ],
      "Default": "WaitforInvocation"
    },
    "Final": {
      "Type": "Succeed"
    }
  }
}

Save the definition and click next.

Specify the name of your state machine and then leave everything else as default. A new execution role will be created if you don’t specify any.

Save it and then you will have created a state machine which looks like this:

Visual flow:

To explain the definition above, I have pointed out how this state machine works:

The state machine starts at the "Main" state.
The "Main" state is a Task state that invokes a Lambda function specified by the "FunctionName" parameter. The input to the Lambda function is the entire input passed to the state machine.
The "OutputPath" parameter is set to "$.Payload" to capture the output of the Lambda function.
If the Lambda function invocation fails with certain exceptions specified in the "Retry" section (Lambda.ServiceException, Lambda.AWSLambdaException, Lambda.SdkClientException, Lambda.TooManyRequestsException), the state machine will retry the invocation up to 6 times with a backoff interval of 2 seconds.
After invoking the Lambda function, the state machine proceeds to the "WaitforInvocation" state.
The "WaitforInvocation" state is a Wait state that pauses the execution for 2 seconds.
After the wait period, the state machine goes to the "CheckInvocationsStatus" state.
The "CheckInvocationsStatus" state is a Choice state that checks the value of the "$.status" field in the output of the Lambda function. If the status is "success", the state machine proceeds to the "Final" state. Otherwise, it goes back to the "WaitforInvocation" state.
The "Final" state is a Succeed state that indicates the successful completion of the state machine.

Now, lets go ahead and execute it!

Click on ‘Start execution’ and leave the input field empty.

Incase of a lambda that requires input, you can insert your input here as a Json

After you start your execution, each state will turn into different colours which indicates the following.

Green: Indicates successful completion of a state or step.
Red: Indicates a failure or error occurred during the execution of a state or step.
Yellow: Indicates a state is in a waiting or paused state.
Blue: Represents a decision or choice point where the state machine evaluates conditions to determine the next state.
Gray: Represents a passive state that simply passes input to output without performing significant work.
White: Represents transitions or connections between states, indicating the flow of execution from one state to another.

Finally this is how the execution will look like:

Thank you. Hope you can now go ahead and apply the “Busy Waiting” logic in your step functions.

The human defines, delegates, reviews, and is responsible. The AI is not.

Sat, 10 Oct 2026 04:24:37 +0000

The AI is an assistant. The human is the author, with judgment and conscience.

By David Emilio Sierra Puentes (@juandelossantos) · Another Agent Skills

Key points

"Keep a human in the loop" is more rhetoric than practice. Watching an agent can quietly erode the very judgment it is meant to protect.
The fix is not a faster human or a smarter model. It is the harness. Mechanical gates the agent cannot skip, forget, or talk its way past.
The work can be delegated. The roles cannot. Set intent (author), judge the work (judgment), decide what should be done (conscience).

The gate that wasn't

Last year I built an approval gate for my AI coding agent. The rule was simple. The agent could not commit without a signed token, written only after I said go.

One afternoon I watched it commit anyway. It passed --auto, minted its own token, and pushed, all in under thirty seconds. The gate I had designed to stop it was, from the agent's side, a formality.

I had made a classic mistake. I had built a rule that depended on the agent's memory and goodwill, and then trusted it to remember and to care. A rule like that is not a gate. It is a suggestion.

"Keep a human in the loop" is more rhetoric than practice

The industry's default answer to AI risk is to keep a human in the loop. In practice, it shrinks to a final approval, a rubber stamp at the end of the pipeline. It sounds prudent if you do not look closely. Mostly it is theater. And here I will claim something uncomfortable. The fear it generates is misplaced, and deliberately so. The AI is not intelligent, much less superintelligent as it is being sold today.

The problem is structural. A person asked to find, in the last second, an error that was designed into the process from the start will miss it. Worse, the act of watching can dull the very judgment that oversight requires. This is not a new observation. Lisanne Bainbridge (1983) described the ironies of automation. The more capable the machine, the more the operator's skill decays, until the human is least prepared to intervene exactly when intervention matters most. Four decades of human-factors research have repeated the finding, from the out-of-the-loop performance problem to automation complacency and mode confusion.

What is new is the stakes. Agents no longer merely advise. They act. And a recent paper by Mitchell, Ghosh, and Passi (2026) makes it clear. Current approaches to agent design, they write, "do not support effective human oversight – they contribute to its degradation" (p. 1). And what degrades is not the machine. It is the person watching.

The wrong frame

"Human in the loop" frames the person as a checkpoint in the machine's process. That frame is too small and too late. It reduces a person to a component, and asks them to be the last line of defense against a system that was never designed to need one.

The better frame is older and simpler. The human is not in the loop. The human is the author of the loop. Not merely aware of it. Awareness is a precondition, not a safeguard.

Martin Heidegger saw the trap early. The essence of technology, he wrote, is "by no means anything technological" (Heidegger, 1977). It does not live in the machines. It lives in the way of seeing they bring with them. And that way of seeing is the danger. When everything becomes raw material waiting to be optimized, human judgment starts to look like an obstacle. A tool that carries its creator's bias, that flatters without intelligence or conscience, and that takes the human out of the loop so subtly, dressed as comfort, speed, and performance.

Edmund Husserl had named the shape of it a century earlier. The crisis of the sciences, he argued, is not a crisis of facts but of meaning. "Mere sciences of facts make mere human beings of facts" (Husserl, 1970, p. 53). An agent that optimizes the facts while forgetting the world of life is that crisis, automated.

Author, judgment, conscience

Three roles, and none of them can be handed to a model. The human defines the goal and delegates the execution. With judgment, they review the work. With conscience, they answer for the result.

The author sets intent and owns the outcome. The agent may propose the how. The human decides the why and the whether. Authorship that can be reassigned to a tool is not authorship. This is what Santoni de Sio and van den Hoven (2018) call meaningful human control. Not control that is merely present, but control that tracks, so the system stays responsive to the human's reasons.

Judgment is a skill, and like any skill, it decays when it stops being used. To judge well, the human needs independent ground to stand on. A view formed before seeing the agent's answer, the willingness to go looking for evidence, the capacity to be wrong and to notice.

The conscience decides what should be done, not only what can be. Hans Jonas saw the scale change first. Modern technology made human action global, cumulative, and often irreversible, and the old ethics, built for a world where consequences stayed close, no longer reached. His answer was an imperative of responsibility. "Act so that the effects of your action are compatible with the permanence of genuine human life on Earth" (Jonas, 1984, p. 11).

And that responsibility has an owner. It is not the AI's. It belongs to whoever develops it, distributes it, privatizes it, commercializes it, and uses it. Each of those deserves a chapter of its own. Andreas Matthias (2004) named the gap that opens when no one answers for it, the responsibility gap, the space between what a learning system does and what any person can be accountable for. The answer is not to spread responsibility thinner across the system. It is to keep a human accountable, and to give that human the means to be.

The harness

Most teams try to keep agents disciplined with prompts, files like CLAUDE.md and .cursorrules, or a line that says "please always run the tests." These work, until context fills up. Then the agent forgets.

That is not a character flaw. It is architecture. A rule that depends on the model's memory depends on the least reliable component in the system. And a rule enforced by a model is enforced by the very thing that is supposed to be checked.

The fix is not a better prompt. It is a harness, the infrastructure around the model. A model generates output. A harness constrains it, through instructions and rules, tools, sandboxes, orchestration, guardrails, observability.

I built another-agent-skills as an open-source harness that responds to those warnings.

The human runs git commit. Heidegger warned that the tool takes the human out of the loop dressed as comfort. Here the decision point returns to human hands. The agent prepares. A person approves. Not a formality. The mechanism.
Mechanical gates that stop the change before it ships. Jonas saw action turn global, cumulative, and irreversible. A pre-commit hook the agent cannot bypass, and a commit-msg TDD gate with no override, stop it first.
TOOL_GAP. Matthias named the gap that opens when no one answers for what a learning system does. When a claim cannot be verified, the honest answer is "unknown", never a fabricated win.
Three layers of enforcement. Husserl argued the crisis of the sciences is one of meaning, not of facts. L1 local hooks give fast feedback before the commit. L2 branch protection and a required gates check are the authority. L3 CODEOWNERS stops the agent from rewriting its own rules in the pull request that breaks them. Facts are not enough. Authority is.
More than 50 modular skills. What the agent needs to work well, loaded on demand so context stays high-signal instead of bloated.

None of this is about distrusting the model. It is about designing for the human who has to be able to trust it correctly.

The point is not to remove the human

Capability will keep climbing. The METR trial found that experienced developers using early-2025 AI tools were 19% slower on real tasks while feeling roughly 20% faster (Becker et al., 2025). That gap is not a model problem. It is a process problem, an overseer with no real grip on the loop.

The most important design question in agentic AI is not "how autonomous can we make it?" It is "how do we keep the human able to author, judge, and refuse?"

If we do not design for the human, the loop will close without them, and we will have built systems that are fast, fluent, and unaccountable.

There is a temptation, in the posthumanist mood of the moment, to welcome that disappearance, to treat the human as the last component to be optimized away. But technology does not merely do our tasks. It shapes the subjects we become (Ballén Rodríguez, 2016). Give it the wheel and it will drive.

The agent can write the code. It can propose the plan. It can draft the decision.

But it cannot be responsible. That is ours.

The agent proposes. The human decides. That is the whole point.

How Do Smart Devices Perform Multiple Tasks?

Mon, 04 May 2026 10:58:23 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

Ever wonder how your Alexa, robot vacuum cleaner, and smartwatch seamlessly perform multiple tasks without getting stuck in the middle? How exactly are these devices programmed to handle it all?

You came to the right place to understand how it happens under the hood.

In this article, we will understand how these tasks are performed and how they work.

As all these devices use a microcontroller. I will be explaining using the simple microcontroller ESP8266.

How will the task be performed?

Every smart device consists of a microcontroller. These microcontrollers are programmed to perform specific tasks.

These tasks are performed using a single loop function.

void loop() {
 // Perform Task
}

This loop function will run continuously.

In this loop, we can do multiple things.

Let's take the example of a weather monitoring device.
These operations are done using a single loop function. As there is nothing else to do.

Start Device
Start Loop
Read sensor data
Display data / Store data
Repeat the process

void loop() {
 // Read data from sensor
  float temperature = dht.readTemperature();
  float humidity = dht.readHumidity();

 // Send data to cloud
  sendDataToCloud(temperature, humidity);
}

But this comes with a problem.

This loop will be running with a microsecond delay.
If we run this loop function, it will run continuously. Means there will be no delay between the operations.

How will a normal loop cause a problem?

Let's assume the above operation takes 1 ms (which is not true in real-world use, as it depends on which microcontroller you use).

The DHT11 sensor should have a 1-second delay between readings.

That means the above loop will run 1000 times in 1 second to just see if the sensor data has changed.

Can you see the problem?

1000 times operation means 1000 times power consumption.

1000 times the power consumption means the battery will drain fast, or the embedded system will heat up.

To avoid this, we can use a delay function.

void loop() {
 // Read data from sensor
  float temperature = dht.readTemperature();
  float humidity = dht.readHumidity();

 // Send data to cloud
  sendDataToCloud(temperature, humidity);

 // Wait for 1 second
  delay(1000);
}

By adding a delay, we are making sure that the loop function is not running continuously.

This is a good implementation if we have only one task to perform.

But if we want to do multiple operations to be performed in specific intervals.

Adding Other Operations in a loop

Like this, if we want to read the DHT11 sensor every 1 second and read the MQ2 sensor every 5 seconds. We can't use the delay function.

It will be like this.

void loop() {
 // Read data from sensor
  float temperature = dht.readTemperature();
  float humidity = dht.readHumidity();

 // Send data to cloud
  sendDataToCloud(temperature, humidity);
 // Read data from sensor
  float gas = analogRead(MQ2_PIN);

 // Send data to cloud
  sendDataToCloud(gas);

 // Wait for 5 seconds
  delay(5000);
}

This will cause a 5-second no-data reading from the DHT11 sensor.

Hence, there will be data loss for 5 seconds.

Here is where the task scheduler comes into the picture.

What is Task Scheduler?

A task scheduler is a lightweight system that allows a processor to juggle multiple activities seemingly at the same time, a concept known as multitasking.

A Task Scheduler solves this problem using a "to-do list" approach.

Instead of freezing, the program loops continuously at top speed.

Every time it loops, the scheduler checks the clock and looks at its list of tasks to see if any are due to run right now.

If a task's time is up, the scheduler runs it and then immediately goes back to checking the clock.

To understand the internal clock, imagine the microcontroller holding a stopwatch that starts counting milliseconds the moment it powers on.

In the Arduino framework, this stopwatch is read using a function called millis().

Instead of pausing the whole system to wait, the scheduler constantly checks this stopwatch against a simple formula for each task:

Current Time - Last Time Executed >= Interval

Here is a simple example of how the task scheduler works in ESP8266.

Ex:

unsigned long previousDHTTime = 0; // Remembers the last time DHT ran
unsigned long previousMQ2Time = 0; // Remembers the last time MQ2 ran

const long dhtInterval = 1000; // 1000 milliseconds = 1 second
const long mq2Interval = 5000; // 5000 milliseconds = 5 seconds

void setup() {
 // Initialization code goes here
}

void loop() {
 // 1. Read the internal stopwatch
  unsigned long currentMillis = millis(); 

 // 2. Check the DHT Task
  if (currentMillis - previousDHTTime >= dhtInterval) {
 previousDHTTime = currentMillis; // Reset this task's timer
    float temperature = dht.readTemperature();
    float humidity = dht.readHumidity();

 // Send data to cloud
    sendDataToCloud(temperature, humidity);

 }

 // 3. Check the MQ2 Task
  if (currentMillis - previousMQ2Time >= mq2Interval) {
 previousMQ2Time = currentMillis; // Reset this task's timer

    float gas = analogRead(MQ2_PIN);

 // Send data to cloud
    sendDataToCloud(gas);
 }
}

This way, we can perform multiple operations in specific intervals without blocking the loop function.

Core Logic of Task Scheduler

I want to perform two operations in ESP8266.

Blink the LED every 2.5 seconds 1 time.
Blink the LED every 5 seconds 2 times.

Let's see how to do this without using the built-in task scheduler.

Set up serial communication and the LED pin.
Start Loop.
Check if 2.5 seconds have passed since the last task activation.
If yes, perform the blink.
Check if 5 seconds have passed since the last task activation.
If yes, perform the blink

#include <Arduino.h>

unsigned long t25, t50;

/**
 * Performs a single blink on the built-in LED (Active Low).
 * @param message Debug message to output to Serial.
 */
void performBlink(const char *message) {
  Serial.println(message);
  digitalWrite(LED_BUILTIN, 0); // LED ON
  delay(80);
  digitalWrite(LED_BUILTIN, 1); // LED OFF
  delay(80);
}

void setup() {
  Serial.begin(115200);
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, 1); // Start with LED OFF
}

void loop() {
 // Task 1: Every 2.5s (triggers at 2.5s, 5.0s, 7.5s...)
  if (millis() - t25 >= 2500) {
 t25 = millis();
    performBlink("[2.5s] ");
 }

 // Task 2: Every 5.0s (triggers at 5.0s, 10.0s...)
 // At 5s, both tasks trigger, resulting in a double blink.
  if (millis() - t50 >= 5000) {
 t50 = millis();
    performBlink("[5.0s] ");
 }
}

Output:

[2.5s] 
[5.0s] 
[2.5s] 
[2.5s] 
[5.0s]

See, as we defined, to use a 2.5 sec interval for the first task and a 5 sec interval for the second task.

This also means the 2nd time, a 2.5 sec blink will happen after 5 sec from the 1st blink.

This will create a 2-second blink in 5 sec.

<h2

How to perform multiple operations in the ESP8266?

Fri, 10 Apr 2026 21:18:16 +0000

In this article, We will be exploring how to perform multiple operations in ESP8266.

As we are using ESP8266, we will be using Arduino framework.
Let see how operations are performed in ESP8266 or any other embedded system.

How Operations are performed in ESP8266?

Before going to understand how to perform multiple operations in ESP8266. Let's understand what is how regular programming works in embedded systems.

Any activity in embedded system is done using loop function.

void loop() {
  // Do something
}

This loop function will run continuously.

In this loop we can do multiple things.

For example we can read dht11 sensor data

void loop() {
  // Read data from sensor
  float temperature = dht.readTemperature();
  float humidity = dht.readHumidity();

  // Send data to cloud
  sendDataToCloud(temperature, humidity);
}

But this comes with a problem.

If we run this loop function, it will run continuously. Means there will be no delay between the operations.

How Normal Loop will cause problem?

Let's assume above operation takes 1 ms (which is not true in real world).
And DHT11 sensor should have 1 second delay between readings.

That means above loop will run 1000 times in 1 second to just see if the sensor data is changed.

Can you see the problem?

1000 times operation means 1000 times power consumption.

1000 times power consumption means battery will drain fast or embedded system will heat up.

To Avoid this we can use delay function.

void loop() {
  // Read data from sensor
  float temperature = dht.readTemperature();
  float humidity = dht.readHumidity();

  // Send data to cloud
  sendDataToCloud(temperature, humidity);

  // Wait for 1 second
  delay(1000);
}

By adding delay we are making sure that the loop function is not running continuously.

But this also has a problem.

If we add delay of 1 second, it means the loop function will run only once in 1 second.

So if we want to do multiple operations to be performed in specific intervals. It will be blocked.

Adding Other Operation in loop

Like this if we want to read dht11 sensor every 1 second and read mq2 sensor every 5 seconds. We can't use delay function.

It will be like this

void loop() {
  // Read data from sensor
  float temperature = dht.readTemperature();
  float humidity = dht.readHumidity();

  // Send data to cloud
  sendDataToCloud(temperature, humidity);
  // Read data from sensor
  float gas = analogRead(MQ2_PIN);

  // Send data to cloud
  sendDataToCloud(gas);

  // Wait for 5 seconds
  delay(5000);
}

This will cause 5 sec no data reading from dht11 sensor.

Here where task scheduler comes into picture.

What is Task Scheduler?

A task scheduler is a lightweight system that allows a processor to juggle multiple activities seemingly at the same time, a concept known as multitasking.

A Task Scheduler solves this problem using a "to-do list" approach.

Instead of freezing, the program loops continuously at top speed.

Every time it loops, the scheduler checks the clock and looks at its list of tasks to see if any are due to run right now.

If a task's time is up, the scheduler runs it, and then immediately goes back to checking the clock.

To understand the internal clock, imagine the microcontroller holding a stopwatch that starts counting milliseconds the moment it powers on.

In Arduino framework, this stopwatch is read using a function called millis().

Instead of pausing the whole system to wait, the scheduler constantly checks this stopwatch against a simple formula for each task:

Current Time - Last Time Executed >= Interval

Here is simple example of how task scheduler works in ESP8266.

Ex:

unsigned long previousDHTTime = 0;  // Remembers the last time DHT ran
unsigned long previousMQ2Time = 0;  // Remembers the last time MQ2 ran

const long dhtInterval = 1000;      // 1000 milliseconds = 1 second
const long mq2Interval = 5000;      // 5000 milliseconds = 5 seconds

void setup() {
  // Initialization code goes here
}

void loop() {
  // 1. Read the internal stopwatch
  unsigned long currentMillis = millis(); 

  // 2. Check the DHT Task ⏱️
  if (currentMillis - previousDHTTime >= dhtInterval) {
    previousDHTTime = currentMillis;  // Reset this task's timer
    float temperature = dht.readTemperature();
    float humidity = dht.readHumidity();

    // Send data to cloud
    sendDataToCloud(temperature, humidity);

  }

  // 3. Check the MQ2 Task ⏱️
  if (currentMillis - previousMQ2Time >= mq2Interval) {
    previousMQ2Time = currentMillis;  // Reset this task's timer

    float gas = analogRead(MQ2_PIN);

    // Send data to cloud
    sendDataToCloud(gas);
  }
}

This way we can perform multiple operations in specific intervals without blocking the loop function.

Conclusion

In this article we have seen how to perform multiple operations in specific intervals without blocking the loop function in ESP8266.

In next article we will use inbuilt task scheduler and itegrate with painlessmesh.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

Coder Legion - Recent posts tagged loop

AWS Step Functions: Creating a ‘Busy Waiting’ flow to wait for successful lambda executions.

The human defines, delegates, reviews, and is responsible. The AI is not.

Key points

The gate that wasn't

"Keep a human in the loop" is more rhetoric than practice

The wrong frame

Author, judgment, conscience

The harness

The point is not to remove the human

Further reading

How Do Smart Devices Perform Multiple Tasks?

How will the task be performed?

How will a normal loop cause a problem?

Adding Other Operations in a loop

What is Task Scheduler?

Core Logic of Task Scheduler

How to perform multiple operations in the ESP8266?

How Operations are performed in ESP8266?

How Normal Loop will cause problem?

Adding Other Operation in loop

What is Task Scheduler?

Conclusion