DEV Community: Bogdan Varlamov

We didn’t have a coding problem - We had a “where do I even start?” problem

Bogdan Varlamov — Mon, 06 Apr 2026 20:38:19 +0000

Problem

A lot of our tasks started the same way:

unclear Jira description
20–30 minutes just figuring out what is actually required
then jumping around the codebase trying to find the right entry point

If the area was unfamiliar, easily 1–2 hours gone before writing anything.

Or you just go ask someone who knows.

Which is fine, but doesn’t scale

And this wasn’t rare.

This was pretty normal.

What was wrong

We kept paying for the same thing:

understanding context
figuring out patterns
re-learning how things are done

Nothing complex, just repeated work.

And heavily dependent on:

who already knows this part of the system

Solution

We didn’t try to “generate code faster”.

We focused on:

understanding + execution as a single flow

Not magic, just structure.

1. Give the agent real system context (agent.md)

A structured entry point (~500 lines):

architecture and patterns
conventions (code, testing, logging)
how to extend the system
risky areas and common pitfalls

This removes the need to “figure things out from scratch”.

2. Build a custom prompt that actually thinks

Not just “generate code”.

The prompt does this in steps:

Understand the task (type, scope, intent)
Estimate complexity
Decide if it should be solved by the agent
Find relevant parts of the codebase
Propose implementation options
Build a step-by-step plan
Highlight risks
Generate a verification checklist

If the task is too complex, it splits it into smaller parts.

3. Use the agent where it makes sense

If complexity is low/medium - the prompt explicitly suggests using the agent.

At this point the agent already has:

system context
correct patterns
a clear plan

So it can generate:

code aligned with the repository
tests for new functionality
regression tests for existing behavior

Not perfect, but good enough to remove most of the routine work.

Result

Tasks estimated at 6–8 hours - often 2–3 hours
Simple tasks - from ~1 hour to minutes
Less need to “figure things out” before starting

This works because:

context is given upfront
implementation is partially handled
common mistakes are reduced

But the main change:

less mental overhead
faster start
fewer interruptions

Takeaway

Most teams don’t have a coding problem.

They have a “time-to-understanding” problem.

If every task starts with digging through the system

and re-learning patterns, that’s the real bottleneck.

AI helps when:

it understands your system
and is used selectively

I see this a lot:

Teams either don’t use AI,
or try to use it everywhere.

Neither works well.

I see this pattern in many teams - curious how you approach it.

Practical Async JavaScript

Bogdan Varlamov — Thu, 23 May 2024 17:18:01 +0000

Introduction

Let's take a moment to brush up on some JavaScript async concepts together.

What is Asynchronous?

First off, let's remind ourselves what an asynchronous process is. Simply put, it's a process that doesn't execute immediately but has a delay or lag. It's like ordering a coffee at a busy café - you place your order, and it takes a bit of time before you get your cup.

Creating a Fake API Call

Alright, can we create a function that mimics a basic API call?
Absolutely! Here's a simple example:

function fakeApiCall(response) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve(`Success: ${response}`);
    }, 1000);
  });
}

Our fakeApiCall function takes a value and returns it after a 1-second delay, labeled with "Success." We're using a Promise because it always handles asynchronous code, and setTimeout to manage the delay.

Adding Error Handling

But hey, do API calls always return the expected value? Nope, sometimes they return errors. Let's add this functionality too:

function fakeApiCall(response) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      if (Math.random() > 0.5) {
        resolve(`Success: ${response}`);
      } else {
        reject('API call failed: try again');
      }
    }, 1000);
  });
}

Here, we've added a condition using Math.random(). Now, there's a 50% chance of success and a 50% chance of failure, mimicking real-world API behavior.

Retrying on Failure

Great! But what if we want to retry the API call when it fails? Let's tackle that:

let attempt = 0;
async function makeApiCallWithRetries(value) {
  try {
    const result = await fakeApiCall(value);
    return result;
  } catch (error) {
    attempt++;
    console.log(`Attempt ${attempt} failed: ${error} - for value: ${value}`);
    return makeApiCallWithRetries(value);
  }
}

In this code, we retry until we get a successful response.
Note, this could lead to an infinite loop if we're unlucky, but we'll hope for the best!

Setting a Retry Limit

To avoid that infinite loop, let's set a maximum retry limit:

let attempt = 0;
const maxRetries = 5;

async function makeApiCallWithRetries(value) {
  try {
    const result = await fakeApiCall(value);
    return result;
  } catch (error) {
    attempt++;
    if (attempt >= maxRetries) {
      throw new Error(`Max retries reached: ${error}`);
    }
    console.log(`Attempt ${attempt} failed: ${error} - for value: ${value}`);
    return makeApiCallWithRetries(value);
  }
}

Now, we'll stop trying after five attempts, avoiding the dreaded infinite loop.

Making Parallel API Calls

So, what if we need to make multiple API calls simultaneously?
Let's think this through. Imagine we have a bunch of requests that need to go out all at once. How can we handle that efficiently?
Well, we can run them in parallel. Here's how:

async function makeApiCallsInParallel(values) {
  const promises = values.map((value) => makeApiCallWithRetries(value));

  const results = await Promise.allSettled(promises);

  results.forEach((result, index) => {
    if (result.status === 'fulfilled') {
      console.log(`Response ${index + 1} succeeded: ${result.value}`);
    } else {
      console.log(`Response ${index + 1} failed: ${result.reason}`);
    }
  });
}

This function takes an array of values and calls makeApiCallWithRetries for each value in parallel. We're using Promise.allSettled to handle both successful and failed calls.

Conclusion

I hope this refreshed your memory about core JavaScript async functionality or even taught you something new.

Thanks for hanging out! Hit subscribe for more! 👋

Enhancing JavaScript with Promise.withResolvers()

Bogdan Varlamov — Tue, 23 Apr 2024 06:30:49 +0000

Since March 2024, Promise.withResolvers() has been supported across the latest devices and browsers. This feature introduces a static method that returns an object containing a new Promise and two functions to either resolve or reject it.

const { promise, resolve, reject } = Promise.withResolvers()

This method provides an alternative to the traditional new Promise() constructor. It is especially useful in scenarios where the logic to resolve or reject the promise doesn't fit neatly into a single function.

Simple Example

Imagine you want to create a promise that resolves when a user clicks a button. Typically, you might set up an event listener inside a promise executor. However, with Promise.withResolvers(), you can streamline the process:

<button id="myButton">Click Me!</button>
<script>
    const { promise, resolve, reject } = Promise.withResolvers();

    document.getElementById("myButton").addEventListener('click', () => {
        resolve("Button clicked!");
    });

    promise.then(alert).catch(console.error);
</script>

In contrast, here's how you might handle it with a standard Promise constructor:

<button id="myButton">Click Me!</button>
<script>
    function waitForButtonClick() {
        return new Promise((resolve, reject) => {
            document.getElementById("myButton").addEventListener('click', () => {
                resolve("Button clicked!");
            });
        });
    }

    waitForButtonClick().then(alert).catch(console.error);
</script>

Comparing Approaches

Encapsulation: The traditional approach encapsulates the promise creation and event handling logic within a single function. This can be restrictive if multiple conditions or different parts of your code need to resolve or reject the promise.
Flexibility: Promise.withResolvers() offers greater flexibility by separating the creation of the promise from the resolution logic, which is ideal for managing complex conditions or multiple events.
Code Management: For straightforward use cases, the traditional method may be simpler, particularly for those familiar with standard promise patterns.

Good case to use `Promise.withResolvers()`

Promise.withResolvers() shines in scenarios like game development or interactive applications where outcomes are influenced by multiple, unpredictable events. For example, in a game, actions such as "win," "lose," or "timeout" might determine the next steps.

Why Promise.withResolvers() is Optimal:

Decoupling Event Handling: It allows separate definition of resolution mechanisms from the event monitoring, improving code organization and management of complex conditions.
Reusable Logic: The resolve and reject functions can be reused across different game scenarios, enabling flexible handling of various outcomes like winning, losing, or pausing.
Simplified State Management: It makes managing asynchronous state transitions cleaner by separating the transitions from the handling logic.

Example

<button id="winButton">Win</button>
<button id="loseButton">Lose</button>
<button id="timeoutButton">Timeout</button>
<script>
    const { promise, resolve, reject } = Promise.withResolvers();

    document.getElementById("winButton").addEventListener('click', () => resolve("Win"));
    document.getElementById("loseButton").addEventListener('click', () => resolve("Lose"));
    document.getElementById("timeoutButton").addEventListener('click', () => reject("Timeout"));

    promise.then(result => {
        console.log("Game Over: " + result);
    }).catch(error => {
        console.log("Game Over: " + error);
    });
</script>

This example illustrates how Promise.withResolvers() effectively manages multiple potential outcomes in an interactive setting, cleanly separating the game logic from the event handling.