DEV Community: Sylwia Laskowska

The Dirty Secret Behind AI Agents (Demo 🚀)

Sylwia Laskowska — Thu, 23 Jul 2026 07:03:51 +0000

For quite a while now, I've had the feeling that AI agents are surrounded by this mystical aura. Nobody really knows what they're doing, they're probably going to take over the world soon, and if you want to build one yourself... well, obviously you need a framework.

What if I told you that's not true? You can build your own AI agent in about 80 lines of code.

I have to admit, this week hasn't been easy. A lot has been happening at work. On top of that, I received an automatic rejection email for one of my CFPs. Normally, that would have occupied my mind for maybe five minutes, because conference rejections are just part of the game.

Except... I had actually been INVITED to that conference. "You're already accepted, just need to collect the talk details in CFP." Because of that invitation, I turned down two other conference opportunities. Oh well. At least I have September free now.😉

Anyway, life goes on. Today is my birthday, so as a little gift from me to myself (and to all of you!), I wrote this article. 😄 I hope you'll enjoy it!

Do We Really Need a Framework?

Let's get to the point.

Frameworks like LangChain, CrewAI, or Mastra aren't doing magic. They simplify things like conversation memory, tool execution, retries, fallbacks, etc.

Once you understand the underlying mechanism, it becomes much easier to decide when a framework is actually worth using. And even if you end up using one anyway, you'll understand what's happening under the hood.

So I decided to build a small demo and see how little code an AI agent actually needs.

I wrote an AI agent in Node.js in roughly 80 lines of code... okay, okay, the core loop is about 80 lines. There are still tools, a provider abstraction, and a bit of surrounding logic. But come on, "an AI agent in 80 lines" sounds much better. 😄

Here's the repository:

https://github.com/sylwia-lask/code-review-agent

And since it's my birthday... if you enjoy the project, feel free to give it a ⭐. Only if you actually like it, of course. 😄

Meet Steve

The application is a simple code review agent. Well... not exactly.

Meet Steve: a software engineer with 15 years of experience reviewing other people's code. Steve doesn't take anything at face value. Sure, he can be a little sarcastic sometimes... but it's hard to argue with his conclusions.

Here's what one of his code reviews looks like:

Or when you have empty diff:

For now, Steve reviews the local Git diff. Which basically means... he's reviewing himself. So I guess I've built a prototype of the famous self-healing agent that, according to @nitsancohen770, is going to take my job one day.

As you can see, I'm basically helping automate myself out of employment. Maybe it's finally time to start thinking about retirement. 😄

"An Agent Is Just a While Loop"

In my previous article, I joked about people claiming that an AI agent is nothing more than a while loop. Well... Mine isn't even a while loop. It's a for loop, because I wanted to protect myself from accidentally creating an infinite loop and loosing too much money on tokens. 😄

Okay, to be fair, the loop itself doesn't actually do anything. It's simply responsible for orchestrating the process. But the funny part is that most agent frameworks are doing something remarkably similar under the hood.

The loop itself was trivial to write. The real challenge was exactly where you'd expect it to be.

Building an AI agent starts with... choosing an LLM. 😄 This time I picked the Gemini API because tokens for projects like this are ridiculously cheap. I'm definitely tempted to build the next version using a local model, but... hold on. 😄

I immediately ran into one issue: some Gemini models were overloaded, so I kept getting 503 responses. That meant I had to implement something frameworks usually provide out of the box — a simple retry mechanism.

Mine is intentionally very basic. Production frameworks usually offer much more, like exponential backoff, jitter, or automatic fallback to another model.

The next challenge was, of course, writing the right prompt. After that, everything became surprisingly straightforward.

How Does the Agent Actually Work?

It's much simpler than you might think.

Step 1: Send the prompt and available tools

We send two things to the model:

the user's message,
the list of tools the model is allowed to use.

Here's what the request looks like:

{
  "model": "gemini-2.5-flash",
  "contents": [
    {
      "role": "user",
      "parts": [
        {
          "text": "Please review the current git diff."
        }
      ]
    }
  ],
  "config": {
    "systemInstruction": "You are Steve, a senior software engineer with 15 years of experience...",
    "tools": [
      {
        "functionDeclarations": [
          {
            "name": "getDiff",
            "description": "Get the git diff of the current repository...",
            "parameters": {
              "type": "OBJECT",
              "properties": {},
              "required": []
            }
          },
          {
            "name": "getFile",
            "description": "Read a file from the repository...",
            "parameters": {
              "type": "OBJECT",
              "properties": {
                "path": {
                  "type": "STRING",
                  "description": "Path to the file relative to the repository root"
                }
              },
              "required": ["path"]
            }
          },
          {
            "name": "listFiles",
            "description": "List files and directories at a given path...",
            "parameters": {
              "type": "OBJECT",
              "properties": {
                "path": {
                  "type": "STRING",
                  "description": "Directory path relative to the repository root"
                }
              },
              "required": ["path"]
            }
          }
        ]
      }
    ]
  }
}

Step 2: Wait for the model's response

The model can respond in one of three ways:

with plain text,
by requesting a tool call,
or with both.

If it returns plain text, we're done: that's our final code review. If it asks us to call a tool, we move on to Step 3.

For example, we might receive:

{
  "candidates": [
    {
      "content": {
        "role": "model",
        "parts": [
          {
            "text": "Let's see what damage we're dealing with today..."
          },
          {
            "functionCall": {
              "id": "call_001",
              "name": "getDiff",
              "args": {}
            }
          }
        ]
      }
    }
  ]
}

Step 3: Execute the tool locally

Now it's our application's turn.

We execute the requested tool locally. For example, running git diff or reading a file from the repository, and send the result back to the model as another message in the conversation.

The tools available in this demo are:

getDiff
getFile
listFiles

In other words, everything a good code reviewer needs. 😄

Step 4: Repeat until the model is done

Then we simply go back to Step 2. To avoid getting stuck in an infinite loop, I limit the maximum number of iterations to 10.

There's one more important detail, though.

Take a look at the next request. Notice that we're sending the entire conversation history back to the model:

{
  "contents": [
    {
      "role": "user",
      "parts": [
        {
          "text": "Please review the current git diff."
        }
      ]
    },
    {
      "role": "model",
      "parts": [
        {
          "text": "Let's see what damage we're dealing with today..."
        },
        {
          "functionCall": {
            "id": "call_001",
            "name": "getDiff",
            "args": {}
          }
        }
      ]
    },
    {
      "role": "user",
      "parts": [
        {
          "functionResponse": {
            "id": "call_001",
            "name": "getDiff",
            "response": {
              "result": "diff --git a/src/auth.ts b/src/auth.ts\n--- a/src/auth.ts\n+++ b/src/auth.ts\n@@ -12,7 +12,7 @@\n-  if (password === storedHash) {\n+  if (password == storedHash) {\n"
            }
          }
        }
      ]
    }
  ]
}

And... that's it. The LLM decides which tool to use and when it's done. Everything else — executing the tools, handling retries, enforcing iteration limits, and orchestrating the loop — is the responsibility of our application.

Simple, isn't it? If you like visualisations, ChatGPT prepared one for us 😉

What's next?

I'd like to write at least two follow-up articles in the future. One about connecting Steve to MCP, and another about replacing the hosted model with a local LLM.

But... hold on. One step at a time. 😄

Bonus: How does the model know it should call a function?

If you only came here to learn how to build an AI agent, you can probably stop reading now. 😄

This section is for the curious ones. Because sooner or later, someone is going to ask: "Sylwia, what are you talking about? You say you're building your own AI agent, but you're just using the Gemini SDK. You send it JSON, you get JSON back."

And, as @darkwiiplayer often points out, an LLM is basically a very sophisticated next-token predictor, not some magical JSON generator.

So... How does the model know what to do when we send it JSON? What would happen if, instead of Gemini, we used some old local Llama model?

Does the Gemini SDK secretly prepend some special prompt? Or are the models themselves trained for this?

The honest answer is that we don't know all the details. What we do know is that models like Gemini and GPT have native support for tool calling. The SDK is responsible for formatting requests correctly and communicating with the API, while the model itself understands tool declarations and can generate function calls when it decides they're needed.

In other words, if we took an older Llama model, we could still write a prompt explaining how to interpret the JSON and asking it to respond in a specific JSON format.

Then we'd simply call JSON.parse()...

...assuming the model actually returns valid JSON instead of Markdown, an explanation, or a few "helpful" comments it decided to add. 😄

That said, it's worth mentioning that newer open-source models increasingly support tool calling natively as well.

Epilogue: An agent written by another agent

Let's be honest. It's 2026. This agent was written largely by... another AI agent. 😄

Since I've been an AWS Community Builder for a while now, I cancelled my Claude Code subscription and switched to Kiro: an AI IDE with built-in support for multiple LLMs, including Claude, GPT, and Gemini. It costs about the same, but thanks to the program, I get to use it for free.

So far, I'm really enjoying it. It feels a bit like an agent-powered layer on top of VS Code, so I immediately felt at home. I also have the feeling that I'm currently using maybe 10% of what it can actually do, so I'm pretty sure I'll write more about it in the future.

Now I'm just hoping AWS will finally send me some swag. 😄 I'm especially dreaming about one of their T-shirts. Years ago, we actually had a political party in Poland called AWS, so I'd absolutely love to see the expressions on some older people's faces. 😄

AWS... if you're reading this... I'm waiting!! 😄

Final Thoughts

As you can see, an AI agent doesn't have to start with a framework. Sometimes all you need is an LLM, tools, convarsation history and a simple loop. Everything else is convenience, production hardening, and quality-of-life improvements.

So...

What do you think about Steve? And how do you like this approach to building an AI agent? 😄

If you liked this post you can also follow me on LinkedIn.

8 Things Developers Confidently Explain After Watching One YouTube Video

Sylwia Laskowska — Tue, 14 Jul 2026 17:57:43 +0000

I just got back from my vacation which, like 99% of Polish people, I spent in Croatia. Dobar dan! 🇭🇷

I've got a really fun article in my head right now, but it needs a bit of research before I can publish it, so that'll be coming next week. In the meantime, let's do something much lighter.

BTW, a small update. I said that FrontKon would be my last conference this year... well, apparently I lied. 😂 When iJS Munich reaches out, you simply don't say no. Especially after looking at the speaker lineup. It's basically a conference full of geniuses... plus me. 😅 So I'll be speaking there at the end of October about WebAssembly and WebGPU in React, and I'm already ridiculously excited.

If you happen to have a spare bag of money lying around xDDD (or, much more realistically, your company still has some training budget left), come and say hi! I'd love to meet some of you in person. 😊

Anyway... let's get back to today's topic.

As many of you probably know, I have a soft spot for LinkedIn gurus and people who explain everything with absolute confidence. You know the type: their solution is always the best one, everyone else is wrong, and there are absolutely no trade-offs. 😄

Sometimes I get the feeling that at least some of that confidence comes directly from a single 15-minute YouTube tutorial.

But let's be fair for a second. Who among us hasn't watched a short video, finished it thinking "Yep, I totally understand this now!", and then discovered during the actual implementation that reality was... slightly more complicated? 😂

Since I spend most of my time working with JavaScript and AI agents these days, most examples will probably come from those areas. Feel free to add your own in the comments!

1. React / Angular / Vue (cross out the unnecessary one) is the best framework

This is probably the most common opinion after watching an internet guru, especially if you haven't formed your own yet.

Angular is the best because it has everything. React is the best because everybody uses it. Vue is the best because... well... Vue people will tell you why. 😄

Then you spend a few years building real projects and suddenly discover that all of these have strengths, weaknesses and different use cases. In the end, the "best framework" is usually just the one that solves your problem best.

2. LLMs are just autocomplete

Or, if you prefer another popular version:

"They're just stochastic parrots."

"They're not creative."

"They don't really understand anything."

Well... if it's all that simple, why do entire teams of researchers and engineers spend years working on them? Why are companies burning through billions of dollars worth of GPUs? 😄

Another statement that always makes me smile is that LLMs "aren't creative." Sure, they probably won't invent something completely detached from everything humanity has ever known.

But then again... neither do most humans.

Most people don't wake up one morning and invent quantum mechanics or write The Lord of the Rings. Creativity is usually about combining existing ideas in interesting ways, and LLMs are actually surprisingly good at that.

3. CQRS (or Redux on the frontend) is easy

Sure. Then you open the codebase and suddenly you're staring into the architectural equivalent of a horror movie.

I've honestly seen everything. Business logic split between Redux stores and components. Half the state managed globally, the other half locally. Actions that somehow contain business logic. Reducers that apparently decided to become services.

Years ago, when I was interviewing developers more often, I used to ask a very simple question: "Why do we actually need CQRS (or Redux)?" (By the way... not everyone even knew the difference between the two.) Then I'd ask another one: "Why can't we solve this in a simpler way?"

I swear, a surprising number of people answered something like:

"I don't know... that's just how people do it."

4. AI agents are just a while loop

To be fair! A good friend of mine, and my former tech lead, actually gives an excellent conference talk with exactly this title. It's intentionally provocative.

And let's face the truth... there is quite a bit of truth to it. Many AI agents really are "just a while loop."

The funny part starts about three weeks later. Suddenly your tiny little while loop has three MCP servers, an orchestration framework, retries, memory, tool calling, etc, etc...

Still one of the most fun things I've worked with recently, though.

5. WebAssembly is always faster

Whenever someone says this, I always ask the same two questions: Faster than what And faster at doing what?

Don't get me wrong, WebAssembly is amazing. There are plenty of scenarios where it absolutely destroys JavaScript performance, especially when you're dealing with computationally intensive algorithms, simulations or similar workloads.

But if your application spends most of its life waiting for HTTP requests to finish... WebAssembly probably won't make the internet faster.

And it probably won't suddenly turn your dashboard into NASA software either. 😄

6. Unit tests are our golden ticket

Especially the ones generated by the same LLM that just generated the production code. 😂 100% confidence!

Or... maybe not.

This can be particularly misleading on the frontend, where unit tests often verify exactly the code that was the easiest to write in the first place.

Congratulations, you've successfully achieved 100% test coverage, and 0% confidence!

7. Let's just add RAG

Yeees...

As if finding, cleaning, maintaining and selecting the right documents was somehow the easy part. 😄

8. Microservices / Microfrontends are the only good architecture

Absolutely! Especially if your application consists of six screens and one backend service. 😄 Or if you've got a perfectly healthy monolith that everyone on the team understands.

Sometimes a distributed architecture is exactly what you need. Sometimes it's just distributed complexity.

I could probably keep going for another twenty examples, but I think that's enough for today. 😂

What about you? Have you ever met one of those "one-YouTube-video gurus"?

If you enjoyed this article, consider following me also on LinkedIn: https://www.linkedin.com/in/sylwia-laskowska-5a8467131/

What's Next for AI?

Sylwia Laskowska — Mon, 29 Jun 2026 07:18:48 +0000

I have been writing about AI for quite a while now, but this is probably the first time I genuinely do not know what to think. Not because the technology has suddenly slowed down, but because the rules of the game may be changing.

I wanted to write something lighter today, but I feel like I have to share some thoughts from the last few days. It is getting harder and harder to ignore what is happening around the newest AI models. @pascal_cescato_692b7a8a20 post, 1%, only confirmed that I am not the only person wondering what comes next.

But let’s start from the beginning. Last Friday, well-known technology journalist Adrian Bridgwater asked me for a comment for this article: OpenAI GPT-5.6 Access Restricted. As someone who used to work in media, I know exactly what journalists hope for when they ask for a comment: a quick response, a short quote, and one strong punchline. 😅 But this time, the topic made me stop and think.

Four years that changed everything

In the last few years, the progress of AI has been incredible. We all know that. On November 30, 2022, OpenAI released ChatGPT, based on GPT-3.5, and generative AI suddenly became mainstream. It took only a few months, and by January 2023 ChatGPT had already reached around 100 million monthly users.

Even then, people were saying that AI would soon take jobs away from developers. And yet, from today’s perspective, less than four years later, GPT-3.5 almost feels dumb.

A year later, we were all laughing at vibe coders and contrasting them with REAL software engineers. But then coding agents arrived, and suddenly we all became vibe coders 😉 Okay, we all know that Claude Code or similar tools still will not replace a good developer today, and AI adoption inside companies often leaves a lot to be desired.

But this is still less than four years of LLMs being truly available on the market. What if, in another two or four years, agents really are good enough to write code much better than humans? Where is the limit of this technology?

Where do developers fit in?

I have to admit, I am a typical overthinker. I love analyzing the world and people, and thinking two hundred steps ahead. Of course, developers would still be needed in such a world, but would all of us be needed? Or would a company that used to need 500 engineers suddenly need five? Or just a small group of people training, supervising, and integrating models?

I am a solid senior engineer, and my market advantage is that apart from writing code, I can talk to people. And business desperately needs that. But I am not the kind of person who will lock herself in a basement for a month and dig deep into hardware internals to make LLMs run faster. I am also not someone who will happily spend 12 hours a day in silence working on benchmarks. I admire people like that, but that is definitely not me.

And I am not sure that if LLMs developed much further, my advantage of “being able to talk to business” would still be an advantage at all. So what should I do? Maybe slowly start looking toward developer advocacy, since that seems to be going well for me? Maybe send my CV to the nearby Biedronka discount store just in case — they are actually hiring, and I am there every day anyway, sometimes guiding people to products better than the staff 😆

Changes, changes...

But then something started to change. Tokens became much more expensive. Companies started realizing that maybe, for simple tasks, a junior developer might actually make more sense 😅 And seriously, I do not yet see a massive wave of hiring interns, but saving tokens, giving up certain tools, and saying “use a cheaper model for simple tasks” has become very common.

And now there is the embargo. First around Mythos and Fable, and now around GPT-5.6. If you missed it, the short version is that access to some of the most advanced AI models is no longer simply “available to everyone who can pay.” It is becoming restricted, limited by geography, organization type, security concerns, or strategic decisions. In practice, this means that not every developer, company, or country can count on equal access to the best models anymore.

I do not know what to think about this. Are these models really so dangerous for critical infrastructure?

Or maybe governments have simply started treating them as a strategic asset, similar to semiconductors? Maybe this is the end of the free AI market?

For developers, at first, it probably will not matter that much. Even if LLM progress stopped at the models we already have today, we would still improve the infrastructure, polish the agents, build better tooling, and continue working quite happily. Maybe for some time the models would even become more stable, with more reliable APIs and better developer experience.

But what happens next? Will working with powerful LLMs be reserved only for selected people? Or selected companies? Or selected countries?

On the other hand... these models are ridiculously expensive. Somebody has to pay for them. It is difficult for me to imagine companies investing billions only to keep their best models locked in a vault forever. They need customers. They need revenue. So maybe this whole "AI embargo" is only temporary? Or maybe governments will eventually step in and treat frontier AI the way they treat strategic infrastructure? Honestly, I have no idea.

So... what happens next?

Maybe it will be like Polish sci-fi writer Rafał Kosik predicted 20 years ago in his young adult series Felix, Net and Nika — AI will become unavailable to the public because it will be considered too dangerous, and models will be kept locked away? 😉 Of course, this is an extreme vision, but honestly, nothing surprises me anymore.

Just a year or two ago, we were asking whether AI would replace developers. Today I find myself wondering about something slightly different: will the most powerful AI even remain available to ordinary people?

What do you think? Where is all of this going? I do not want to pretend to be an all-knowing sheriff here, and I am genuinely curious about your perspective.

Also, I will not publish anything next week because I am going on vacation — like every self-respecting Polish person, to Croatia. This is just a note for those of you who read my posts every Sunday around lunchtime 😆

And if you are from Czechia or somewhere nearby, come to *FrontKon*, where I will be speaking. Let’s high-five there!
Or, if you like, please follow me on LinkedIn.

7 New JavaScript Features (And 2 I'm Still Waiting For)

Sylwia Laskowska — Wed, 24 Jun 2026 09:14:11 +0000

Remember how I promised you (or rather myself) two weeks ago that from now on I'd only write light, easy posts? Well… I broke that promise 😅 Last week I published a huge article about one of the least sexy topics imaginable: legacy applications. Somehow, despite that, the DEV editorial team liked it enough to include it in the Top 7 Posts of the Week ❤️

But today is finally the day for something a bit lighter. And I think it's a topic that deserves more attention.

These days we spend a lot of time talking about AI agents, and I absolutely understand why, because it's a fascinating field. But I sometimes feel we're forgetting that the programming languages we use every day are evolving too.

I spend most of my days writing JavaScript (well… TypeScript, obviously 😄). And yes, the ecosystem has matured a lot over the last few years. We no longer have endless React vs Angular wars. We're also mostly past those times when everyone loved Redux one month and six months later decided it was an overengineered monster and removed it from every application 😅.

But both the ecosystem and the ECMAScript standard keep evolving.

After the legendary ES6 release in 2015, which changed frontend development forever, the TC39 committee switched to an iterative approach and started shipping new features every year.

And the nice thing is that if you're using modern browsers or runtimes, you often get access to these features almost immediately.

So, what do we get in ECMAScript 2026?

Oh, and to keep things entertaining, all code examples in this article are based on the internal monologue of imaginary LinkedIn gurus with very strong opinions. Any resemblance to actual people is, naturally, purely coincidental 😇

1. Map.prototype.getOrInsert() / Upsert

MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map/getOrInsert

This is one of those features that makes you wonder: "Wait… why didn't we have this ten years ago?"

Imagine we're collecting opinions from LinkedIn gurus. Until now, we had to do something like this:

const opinions = new Map();

function addOpinion(topic, author) {
  if (!opinions.has(topic)) {
    opinions.set(topic, []);
  }

  opinions.get(topic).push(author);
}

addOpinion("React is dead", "10x Engineer");
addOpinion("React is dead", "Principal AI Evangelist");

It works, but there's quite a bit of boilerplate.

With ES2026, things become much nicer:

const opinions = new Map();

opinions
  .getOrInsert("React is dead", [])
  .push("10x Engineer");

opinions
  .getOrInsert("React is dead", [])
  .push("Principal AI Evangelist");

console.log(opinions);

We also get a computed version:

const opinions = new Map();

opinions
  .getOrInsertComputed(
    "Nobody writes clean code anymore",
    () => []
  )
  .push("DDD Purist");

Come on, that's so much cleaner and easier to read. It's also perfect for caching! Much less code, much nicer API.

2. Iterator.concat()

MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Iterator/concat

Before we talk about concat(), let's quickly answer a question:

What is an iterator?

An iterator is basically a cursor that lets us consume data one element at a time without storing everything in memory.

For example:

const posts = [
  "Angular is dead",
  "JavaScript was a mistake"
];

const iterator = posts.values();

console.log(iterator.next());
// { value: "Angular is dead", done: false }

console.log(iterator.next());
// { value: "JavaScript was a mistake", done: false }

console.log(iterator.next());
// { value: undefined, done: true }

And because iterators are lazy, we can even generate infinite sequences without blowing up memory:

function* endlessHotTakes() {
  while (true) {
    yield "Everything should be rewritten in Rust.";
  }
}

const iterator = endlessHotTakes();

console.log(iterator.next().value);
console.log(iterator.next().value);
console.log(iterator.next().value);

Last year we got Iterator Helpers, which introduced things like map(), filter(), and friends:

function* linkedinFeed() {
  yield "Use Rust for everything";
  yield "JavaScript was a mistake";
  yield "Clean code is dead";
  yield "Angular is dead";
}

const controversialTakes =
  linkedinFeed()
    .filter(post => post.includes("dead"))
    .map(post => `🔥 ${post}`);

console.log([...controversialTakes]);

And now we get another nice addition: Iterator.concat(). Suppose frontend gurus and backend gurus each have their own stream of wisdom:

function* frontendExperts() {
  yield "React is dead";
  yield "Nobody needs Redux";
}

function* backendExperts() {
  yield "Microservices solve everything";
  yield "Frontend developers don't understand architecture";
}

Now we can combine them elegantly:

const feed = Iterator.concat(
  frontendExperts(),
  backendExperts()
);

console.log([...feed]);

In my opinion, these iterator features don't get nearly as much attention as they deserve.

3. Array.fromAsync()

MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/fromAsync

This is basically the async equivalent of our beloved Array.from().

It's primarily designed for async iterators, although I suspect that most JavaScript developers don't use async iterators every day. For example, imagine comments arriving one by one from LinkedIn:

async function* angryComments() {
  yield "This could have been a plain HTML form.";
  yield "Angular is dead.";
  yield "React is dead.";
  yield "JavaScript was a mistake.";
}

const comments = await Array.fromAsync(
  angryComments()
);

console.log(comments); 
// This could have been a plain HTML form.
// Angular is dead.
// etc

But here's something many people don't realize: it also works with promises.

const opinions = [
  Promise.resolve("Nobody should use classes."),
  Promise.resolve("Signals change everything."),
  Promise.resolve("Microservices ruined software.")
];

const takes = await Array.fromAsync(opinions);

console.log(takes);

And you can even map values immediately:

const comments = await Array.fromAsync(
  angryComments(),
  opinion => opinion.toUpperCase()
);

console.log(comments);

Pretty convenient.

4. Math.sumPrecise()

MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/sumPrecise

This one solves a floating-point problem that's almost as old as the Internet itself 😄 As many of you probably know, in JavaScript:

console.log(0.1 + 0.2);
// 0.30000000000000004

I won't dive into why that happens today: we'd be here all night 😄

The important thing is that ES2026 introduces Math.sumPrecise(), which performs much more accurate summation and avoids the accumulation of rounding errors.

Suppose a LinkedIn guru is listing all the things that allegedly increase productivity:

const productivityBoosts = [
  0.1, // cold showers
  0.2, // AI agents
  0.3, // journaling
  0.4, // waking up at 4 AM
];

console.log(
  Math.sumPrecise(productivityBoosts)
);

Now, to be fair, most frontend developers will probably never need this. Plain old addition works perfectly fine for everyday use.

But if you're working in finance, statistics, simulations, or AI/ML, where tiny errors can accumulate over thousands or millions of operations, this becomes much more interesting.

5. Error.isError()

MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/isError

This one is probably aimed more at library authors and advanced developers. Or maybe not? 😉 Until now, checking whether something was actually an error usually looked like this:

try {
  throw new Error(
    "Angular is dead."
  );
}
catch (e) {

  console.log(
    e instanceof Error
  );
}

And most of the time, that worked perfectly fine. Until it didn't.

If an error originated in another realm, for example an iframe, a Web Worker, or a VM context—instanceof Error could suddenly betray you:

const strangeThing =
  window.frames[0].eval(
    "new Error('JavaScript was a mistake.')"
  );

console.log(
  strangeThing instanceof Error
);

// false

This problem has been annoying library authors for years, which is why many frameworks and libraries have their own helper functions for detecting errors. Now we finally get a built-in solution:

console.log(
  Error.isError(strangeThing)
);

// true

Simple and beautiful.

6. Base64 for Uint8Array

MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Uint8Array/toBase64

Quick reminder: Base64 is simply a way of converting binary data into plain text. Why would we do that? Because many protocols and formats are much happier dealing with text than raw bytes. For example, we might send an image as a Base64 string.

Now, someone might say: "Wait a minute, Base64 already existed in JavaScript!" And yes, it did. But it mostly worked with strings:

btoa("JavaScript was a mistake.");

When dealing with binary data, things quickly became ugly:

const bytes = new Uint8Array(buffer);

const base64 = btoa(
  String.fromCharCode(...bytes)
);

Not terrible, but definitely not something you'd call elegant.

Now we can simply write:

const screenshot =
  await fetch(
    "/proof/react-is-dead.png"
  );

const bytes =
  new Uint8Array(
    await screenshot.arrayBuffer()
  );

const base64 =
  bytes.toBase64();

console.log(base64);

Much cleaner. And, perhaps more importantly, much easier to understand six months later.

7. JSON.parse Source Text Access

MDN:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse

JSON.parse() is great. Until somebody sends you a gigantic number. Suppose a LinkedIn guru claims to have 999 trillion followers:

const json = `
{
  "followers":
  999999999999999999999999999999
}
`;

const data = JSON.parse(json);

console.log(data.followers);

Oops. JavaScript numbers have limits, and very large integers may lose precision.

With ES2026, the reviver callback gets access to the original source text, allowing us to recover huge values safely:

const data = JSON.parse(
  json,
  (key, value, context) => {

    if (key === "followers") {
      return BigInt(context.source);
    }

    return value;
  }
);

console.log(data.followers);

No more accidental corruption of giant numbers.

Most of us won't need this every day. But if you're dealing with IDs, financial data, or huge integer values, this can save you from some nasty bugs.

Bonus: The Great Absentees

I was really hoping these features would make it into ES2026, but unfortunately we'll have to wait another year.

Well, sort of. Modern browsers and runtimes have already started implementing them, but they are not officially part of the ECMAScript 2026 specification yet.

These are probably the two features I'm personally most excited about.

Temporal API

TC39 proposal:
https://github.com/tc39/proposal-temporal

If you've been doing frontend development long enough, chances are you've had at least one traumatic experience involving dates. Maybe something like this:

const date = new Date("2026-03-30");

console.log(date);

Depending on your timezone, congratulations! You've just entered the exciting world of: "Why is it yesterday?"

Or perhaps you've experienced everyone's favorite:

const today = new Date();

today.setMonth(today.getMonth() + 1);

And suddenly you're debugging why March plus one month somehow became May.

Or maybe you've been lucky enough to deal with time zones.

At which point you discover that time itself is apparently an illusion and that daylight saving time was invented specifically to ruin programmers' lives.

This is why many of us ended up using libraries like Moment.js. Ironically, even the Moment.js maintainers now recommend using other solutions. Then came date-fns, Luxon, and various other attempts to restore sanity.

They certainly help. Until somebody says: "By the way, users in Australia are reporting weird bugs." And that's usually where the fun begins.

Temporal aims to fix all of this by introducing proper date and time types.

Instead of:

const now = new Date();

we get things like:

const now = Temporal.Now.instant();

const birthday =
  Temporal.PlainDate.from(
    "1987-07-23"
  );

const meeting =
  Temporal.ZonedDateTime.from(
    "2026-11-03T10:00:00[Europe/Warsaw]"
  );

And suddenly everything becomes much more explicit.

By the way, I spent an embarrassing amount of time trying to figure out whether Temporal had actually made it into ES2026. Eventually, I found the TC39 repository, where it clearly says that although the proposal has already reached Stage 4, its expected publication year is 2027.

So we're close. Very close. And I can't wait ❤️

Explicit Resource Management (`using`)

TC39 proposal:
https://github.com/tc39/proposal-explicit-resource-management

This is one of those features that C# and Python developers have been quietly enjoying while the rest of us pretended that try/finally was perfectly fine 😄

Sometimes you create something that needs cleaning up afterward: file, database connection, stream, WebSocket, etc. Today, we usually write something like this:

const webinar =
  createAIAgentsWebinar();

try {

  webinar.start();

}
finally {

  webinar.close();

}

The finally block is often written with the same enthusiasm as unit tests. Worse, if we forget it entirely, we may end up with resource leaks and mysterious bugs.

With using, cleanup happens automatically when leaving the scope:

using webinar =
  createAIAgentsWebinar();

webinar.start();

Once we leave the scope, JavaScript automatically calls the cleanup logic. How cool is that?

It's one of those features that might not affect the average frontend developer every day, but for Node.js developers, library authors, and people working with streams and files, it can be incredibly useful.

Uff...

I have to admit, this article turned out to be way more work than I originally expected 😅 It was supposed to be short and easy. And somehow I ended up digging through TC39 proposals, MDN pages, browser implementations, and trying to figure out whether Temporal had actually made it into ES2026 or not.

But I hope it was worth it and that you enjoyed it ❤️

What about you? Which feature surprised you the most? And are you also eagerly waiting for Temporal to finally free us from all date-related suffering?

(Or at least that's what the LinkedIn gurus will probably tell us next week 😇)

If you enjoyed this article, feel free to connect with me on LinkedIn😊

Who Here Has Worked with Legacy? The Longer You Wait, the Worse It Gets

Sylwia Laskowska — Thu, 18 Jun 2026 07:25:04 +0000

I promised myself that starting this week I'd switch to lighter topics. But on Monday, my JSNation adventure officially came to an end, and I realized I hadn't written a single article about my talk yet. Since everything is still fresh in my mind, here we go!

As for JSNation itself, I have mixed feelings. I was selected for the online track and, despite the organizers' incredible professionalism, it just wasn't the same as being there in person. You know, I could have been in Amsterdam drinking beer with Wes Bos, but instead I was watching my own talk from the kitchen while replying to Teams messages. 😄 Still, it was a great experience. And who knows? Maybe my expertise, or my level of celebrity status 😅 will grow enough that one day I'll get to speak in Amsterdam in person.

That said, I might visit that beautiful city later this year anyway, but let's not get ahead of ourselves. 😉

Back to the topic. My talk was called "Rewrite or Refactor? How to Safely Move Legacy Apps to Modern Frameworks." I believe I'm the right person to talk about this. Why? Because I've migrated a lot of frontend apps throughout my career, in all kinds of configurations: old Angular to modern Angular, ASP.NET MVC 5 to Vue, React with class components to modern React, and so on.

The reason is simple. If a company desperately needs a migration and suddenly receives a CV from someone who's already done one, they're usually very happy to hire that person—even for a slightly above-market rate. 😄 That's basically how I became a frontend migration expert, and I definitely have a few things to say about it.

But why migrate at all?

Before discussing strategies, we need to answer a more fundamental question: why migrate in the first place?

I've heard this question many times from stakeholders, especially non-technical product owners. If the application works, why touch it? Developers are just chasing hype and trying to put shiny technologies on their CVs, right?

My answer is usually very simple and honest.

You know me well. I'm not a fanboy of any particular framework. To me, they're just tools. Like hammers. But when I'm building something, I'd rather use a solid, reliable hammer than a rusty one with missing parts. 😉🔨⛏️🪓🔧🪛

But migration isn't just about developer experience. In reality, it's about the survival of your product. Especially today, when technology evolves faster than ever and AI is accelerating everything even further.

Take security, for example. When a library becomes obsolete and nobody maintains it anymore, security patches stop coming. Vulnerability reports start turning red. No product owner in history has ever said, "Sure, let's sacrifice security for a few extra features!" At least I hope so 😅

And let's not forget modern tooling. Vite builds alone can make a huge difference. Modern applications are simply faster, and faster applications are better applications.

There are many more reasons, but the most important thing to remember is this:

The longer you postpone a migration, the harder and more expensive it becomes.

Okay, okay, I want to migrate. But how?

Interestingly, the arrival of LLMs hasn't fundamentally changed migration strategies. They're basically the same as before AI became mainstream. Sometimes the work is faster, sometimes it isn't, but the underlying approaches remain unchanged.

There are probably as many migration strategies as there are senior engineers, but in practice they fall into two categories:

Rewrite (Big Bang Strategy)

Rewrite the entire application — or, as often happens on the frontend, upgrade an ancient stack directly to the latest version of the framework.

Refactor (Strangler Pattern)

Rewrite the application piece by piece while continuing to deliver features.

So, which approach is better?

Honestly, there's no point starting a holy war over this. In most cases, the realities of your project decide for you.

If your application is relatively small, your team is experienced, your documentation is decent, and you can afford to pause feature development for a few weeks or months, a rewrite may be a perfectly reasonable choice.

On the other hand, if you're working on a huge project with lots of junior developers or people unfamiliar with the technology, and the documentation is practically nonexistent — an incremental refactor is probably your only realistic option.

Of course, there are many other factors to consider. Here's a quick summary:

Factor	Rewrite (Big Bang)	Refactor (Strangler)
Application size	Small or medium	Large
Feature development	Can be paused	Must continue
Documentation	Good	Poor
Team experience	High	Mixed
Risk tolerance	Higher	Lower
Time to first results	Short	Long
Complexity during migration	Lower	Higher
Risk of endless migration	Low	High

Big Bang – Not as scary as it sounds

Let me briefly describe both approaches, starting with Big Bang.

I have to admit — I like this strategy. Sure, books and articles often describe it as risky, sometimes even as an anti-pattern. And they're right — if we're talking about a twenty-year-old Java monolith that nobody dares to touch.

But many frontend applications are relatively young and relatively small. In those situations, a Big Bang approach can simply be faster and cheaper.

Full rewrites are relatively rare these days. However, large upgrades are quite common: for example, moving from Angular 7 to modern Angular with Signals, or from old React with class components to modern React with hooks.

These projects still require a lot of work and a lot of digging through old code, but you'll reach the finish line much faster than with a Strangler migration.

I'm not going to describe planning phases, migration scripts, codemods, or the specific tools I've used. Those details vary from project to project and don't make much sense in a general article.

However, there are certain things that show up with surprising consistency in almost every migration. 😉

Real-Life Example: Big Bang migration from Angular 7 to latest Angular

Here's an interesting example. Sometimes we wonder how a team could possibly let an application go years without upgrades. In reality, it's surprisingly easy, especially when nobody is actively working on it because the product is in maintenance mode and hasn't changed significantly in years.

That was exactly the case here.

Then one day, the stakeholders decided to expand the application significantly and add several new features. I convinced them to upgrade to the latest Angular version, mainly for security reasons — the system stored critical data.

Long story short, four developers upgraded it to the latest version in four months. And it turned out to be much harder than I expected.

First of all, it's easy to underestimate the scope of the problem. From the outside, it looks simple: "Just upgrade Angular."

But the framework itself is rarely the real problem. The ecosystem around it is.

For example, our primary component library introduced major syntax changes somewhere between versions 12 and 13. Imagine how many places needed to be updated! Sure, AI can help, but if an ambitious UI engineer decides to rename CSS classes and change component structures, AI won't save you — you'll end up fixing things manually.

Some third-party libraries had long been abandoned. And here's something worth remembering:

If you have a library that hasn't been updated in years, whose author has apparently forgotten it exists, and it doesn't even compile on Node 18 anymore, that's not "working code." That's a time bomb.

And yes, we had plenty of end-to-end tests. Many of them exploded because of changes in the component library. 😄 So even automated tests won't always save you.

Another important lesson: always have a solid branching strategy for hotfixes. Assume something will go wrong. Because eventually, something probably will.

Fortunately, the migration was a success.

Build times improved dramatically. The bundle size shrank significantly. The new layout looked much better than the old one, so even the most technology-resistant stakeholders were impressed.

And perhaps most importantly, the application became ready for future upgrades. Even the QA team—which initially hated us, eventually admitted that upgrading regularly is much better than doing it once every seven years 🤣

Incremental migration – having your cake and eating it too

Sometimes, though, your application is simply too large for a Big Bang approach, or you can't afford to stop delivering features. In that case, incremental migration becomes the only realistic option.

This type of step-by-step refactoring is usually implemented using the Strangler Pattern. There are other approaches, of course, but I personally like this one because it's elegant, relatively simple, and battle-tested by some of the largest tech companies in the world.

So what exactly is the Strangler Pattern?

Take a look at the beautiful diagram below, handcrafted by yours truly in draw.io. 😄

As you can see, you start with your legacy application. You build a new application alongside it. Then you place a reverse proxy in front, which decides which routes go to which application.

From there, you migrate screen by screen, route by route. Over time, the legacy application becomes smaller and smaller until, hopefully, all that's left is the new one, and you can finally get rid of both the old app and the reverse proxy.

In this scenario, both applications should share authentication and the backend, but not frontend code.

And if you absolutely must make the two applications communicate, I'd strongly recommend using something simple like custom DOM events instead of so-called "temporary" adapters.

Because we all know what "temporary" means in software engineering. Forever. 😅 And before you know it, those adapters become a brand-new piece of legacy.

Real-life example: Migrating from Backbone to Vue with the Strangler Pattern

This was an old application written in Backbone—and I have to admit, it was actually very well written. Still, it was Backbone. 😄

The application wasn't huge, so a Big Bang migration was theoretically possible. But we were a startup, and one day we heard these famous words: "Guys, we just sold a feature that doesn't exist yet. You have three months to deliver it. Have fun!"

My immediate reaction was: "Hahaha. Very funny. There's no way I'm building that in Backbone." Luckily, our stakeholders were smart and agreed to a Strangler migration.

My team consisted of me and... two junior Java developers who, I swear, heard the word "TypeScript" for the first time in their lives.

Fortunately, they were ambitious and learned quickly. Well, they didn't really have much choice. 😄 And that's another advantage of this strategy: junior developers can learn meanwhile.

I created a new Vue application on the side. A lot of people in the company already knew Vue, so the choice was obvious.

First, I migrated the login screen as a proof of concept. Then we moved on to the shiny new feature the client had already paid for. 😉

For the next year, we migrated the application screen by screen.

Eventually, Backbone disappeared completely. And throughout the entire process, we had zero downtime. Customers didn't even notice that a migration was happening.

Just like in the previous example, the bundle became significantly smaller, and build times improved dramatically.

However, the Strangler approach isn't all sunshine and rainbows.

First of all, there's the time factor. The migration process takes a long time. In our case, with a relatively small application, it still took an entire year.

There's also the danger of the never-ending migration. You probably know what I mean. Deadlines pile up. Features keep coming. And after a while, you find yourself almost begging your product owner to spare a few story points for migration work.

And unfortunately, there's no way to avoid touching legacy code. Zero chance. And believe me, developers hate it. I've heard things like: "Sylwia, why are you making everything so complicated? Now we have to know two technology stacks!"

So no matter which strategy you choose, you'll probably become the team's scapegoat. At least while the migration is in progress.

But once it's over, the bundle size has been cut in half, vulnerability reports stop glowing red, and customers stop complaining, you'll suddenly become the company's hero. 😄

A Few Final Words

Migrating legacy applications is a lot like buying an old house. It's not your fault that it's falling apart, but it is your responsibility to bring it back into shape. You can take a few weeks off and renovate everything at once, or you can move in and tackle one room at a time.

The only truly bad strategy is doing nothing. Sooner or later, you'll have to migrate anyway — except you'll be doing it because of a production incident. 😉

So, what's your approach to renovating your legacy applications?

Disclaimer

None of the stories described above actually happened. Or maybe they did? 😉

As both a professional and someone bound by NDAs, I deliberately created a blend of several migration stories to make sure no company or project could be identified. That wasn't particularly difficult, because after a while all migrations start to look surprisingly similar. 😄

If you like my articles, you can also follow me on LinkedIn.

The Code Works. What Could Possibly Go Wrong?

Sylwia Laskowska — Wed, 10 Jun 2026 08:26:35 +0000

Would you treat a serious illness without seeing a doctor, relying only on whatever your favorite AI model suggested? Would you let AI take over your child's education?

Probably not.

So why are you willing to hand over your entire codebase to it?

JSNation is just around the corner, and as I mentioned before, I'll also be joining a discussion room called "Trusting AI Systems: How Much Is Too Much?". So today, let's talk about exactly that.

Also, after an incredibly busy first half of the year, I think I'm officially entering vacation mode next week. Expect some JavaScript posts, popular bash commands, and occasional programming memes. 😄 I know many of you enjoy those too.

By the way, as I already mentioned, I'll be speaking at FrontKon in Prague this October! I have a feeling it's going to be one of the best conferences of the season. The organization has been fantastic so far. The agenda is already published, and I know my talk is scheduled for 3:30 PM. I haven't quite figured out which day yet, but don't worry, I should be able to sort that out before October. 😄

If you're into frontend development, definitely check it out. Apparently tickets are selling fast. You can also leave me a like here.

It will probably be my last conference appearance of 2026. Unless somebody invites me somewhere else. Which, as it turns out, is not entirely impossible. 😉 But that's a story for another day.

Does AI Lie?

Let's get back to the topic.

How much do you trust AI? And I'm not talking only about code. I'm also talking about knowledge.

I don't know how often you use LLMs outside programming, but I use them a lot. Really a lot. Sometimes I vent to them. Sometimes I ask for information, inspiration, or validation of an idea. And I've noticed an interesting pattern.

Remember school or university? General knowledge was easy to access. But when you needed something more specialized, you had to go to the library or dig through academic journals.

Models work in a surprisingly similar way. When I'm looking for general information, I trust them almost blindly. But the more I discuss topics I actually know well, the more nonsense I start noticing.

Yes, models hallucinate less than they used to. They no longer invent completely absurd facts every other answer. But do they really stop making mistakes? Not exactly.

Sometimes the facts are mostly correct, but names get mixed up. Sometimes two separate conversations will confidently give me two different explanations for the same medical issue. 😉

Of course, LLMs usually tell us to consult a doctor and remind us to verify important information.

And honestly, I don't think many sane people would blindly trust an AI model with their health.

Our codebase, however? Sure, go ahead, dear model.

The Codebase Paradox

This is where things get interesting.

As most of you know, I work primarily in web development. I've been doing this for quite a while. When I discuss architecture with an LLM, even for my own side projects, the results are often surprisingly good.

But sometimes they're absolutely terrifying. Huge monolithic files. Missing abstractions. Or even worse: unnecessary abstractions everywhere. Hello, Codex. 👋

And that's still not the worst part. Every now and then you'll find a lovely XSS vulnerability or some other security issue casually slipped into the generated code.

Most of the code looks perfectly reasonable. The problems are usually small. Tiny. Hidden somewhere in the details. But those tiny problems could take down my production environment within a couple of days.

And here's the problem: I can see those mistakes. I can see them because I've spent well over a decade doing this.

But if you're building your first startup or just starting your programming journey, how are you supposed to know that the agent just left the front door wide open?

The Vibe Coding Trap

And yet people vibe code all the time.

To be clear: vibe coding is awesome.

A friend recently told me he helped his daughter build a university project in Unity. He had never used Unity before. The initial project skeleton took about thirty minutes to generate with AI. The next five hours were spent fixing what the model produced.

But here's the thing: Without the model, he probably wouldn't have even started in those five hours. He might have spent them configuring the environment. That's incredibly powerful.

Following that logic, once you understand software engineering, technology stacks and ecosystems become far less limiting. You can suddenly build almost anything much faster than before.

And that's where the temptation begins.

I'll go even further. Is there still a debate about whether developers should understand AI-generated code? Or have we finally moved past that?

Because maybe understanding it isn't necessary? After all, it works. The model even wrote unit tests xDDDDDDD What could possibly go wrong? 😄

For hobby projects, experiments, or university assignments, that's perfectly fine. Just like my friend's daughter's project. Five people will see it, it will get a grade, and then it will quietly disappear into a repository forever.

The real problem starts when someone decides that this is good enough for production. Because unfortunately, it often is.

AI Didn't Break Production

People love blaming AI when something goes wrong. I don't.

We've already seen stories about AI agents deleting databases and then trying to cover it up. We've seen services launched with security issues that even relatively inexperienced attackers could exploit. And honestly, we could keep listing examples until tomorrow morning.

The truth is that penetration testers have never had an easier time than in the era of vibe-coded software.

What always amuses me is when people say: "See? AI caused this disaster." No. It didn't. The person responsible is the human who gave the agent excessive permissions. The human who didn't review the output.

The human who decided to build something they didn't fully understand because hiring experienced engineers seemed too expensive.

AI didn't deploy that code. A human did.

So, Will AI Take Your Job?

AI won't take programmers' jobs.

But programmers who trust AI uncritically might do a very good job of taking those jobs away from themselves.

So I'm curious: where do you draw the line?

Do you review every line generated by AI? Do you let agents make changes autonomously? Or have you already reached a point where trusting the model feels more natural than verifying it?

How much trust is too much?

Is This How We'll Build Websites Soon? (webMCP Live Demo 🚀)

Sylwia Laskowska — Wed, 03 Jun 2026 07:11:55 +0000

A few years ago, we started adapting our websites for mobile devices. Then we adapted them for accessibility. And now we may be about to adapt them once again. This time... for AI agents.

To see what this could look like in practice, I built a completely serious and absolutely enterprise-ready AI CEO Simulator.

We'll come back to our visionary leader in a moment.

BTW, thank you all for the amazing discussion under my previous article. We somehow managed to generate approximately one billion comments 🩷 Many of them were probably smarter than the article itself. The sensible thing to do would be to write a follow-up post summarizing everything.

But honestly, I needed a break from that topic before I exploded.

Sometimes I just have to write something technical, otherwise I'll suffocate. Fortunately, nobody pays me for these articles, so I can do whatever I want 😁 We'll come back to AI in software development another time.

What Is webMCP? 🤖

For now, let's talk about webMCP.

Google is currently experimenting with webMCP support in Chrome, an approach designed to make it easier for AI agents to interact with websites.

The problem it tries to solve is actually quite simple.

Today, when an agent wants to use a website, it has to inspect the page, figure out which elements are important, click around, analyze the results, and repeat this process over and over again. It works, but it's slow, expensive, and not always reliable.

webMCP allows websites to expose structured information about available actions, so agents can understand what they can do without endlessly scraping the page and guessing.

Time for a Completely Serious Business Simulation 🚀

But enough theory.

Let's build something completely serious and enterprise-ready.

@cart0ne mentioned under my previous article that AI had effectively become the CEO of his startup.

So, as a responsible person, I built an AI CEO Simulator in React + TypeScript.

GitHub: https://github.com/sylwia-lask/ai-ceo-webMCP

Live demo: https://sylwia-lask.github.io/ai-ceo-webMCP/

How To Enable webMCP

Before you immediately rush to implement webMCP in your production application, a small disclaimer.

For now, this is still experimental technology. It currently works only in Chrome Canary, Chrome Beta, or Chrome with the appropriate experimental flag enabled.

To enable it:

1. Open `chrome://flags`
2. Search for "MCP"
3. Enable the experimental MCP-related features
4. Restart Chrome

If you'd rather not play with experimental browser flags, that's fine. You can simply look at the screenshots below.

Or click around the application yourself, because everything still works perfectly as a normal website.

That's actually one of the things I like most about this approach. WebMCP is just an enhancement for agents, much like accessibility features are enhancements for users relying on screen readers. Nothing breaks, nothing changes for regular users.

The application simply becomes easier to understand for a different kind of visitor.

Two Ways To Use webMCP

There are currently two main ways of exposing information through webMCP.

Option 1: Declarative API / HTML annotations

The first approach is adding metadata directly to HTML elements:

<form
  mcp-name="createSupportTicket"
  mcp-description="Create a new customer support ticket">

This allows agents to understand the purpose of UI elements without relying entirely on visual interpretation.

Option 2: Imperative API / JavaScript tools

The second approach is exposing MCP tools directly from your application code.

That's the approach I used in my demo:

registerTool({
  name: 'hire_employee',
  description: 'Hire a new employee'
});

registerTool({
  name: 'fire_employee',
  description: 'Fire an employee'
});

In my application, these tools correspond directly to actions available through buttons on the page.

For example, I expose tools such as:

hireDevelopers()
fireDevelopers()
adoptAI()
rewriteInRust()
pivotToAgents()
fixProductionBugs()

In other words: completely normal startup management.

Connecting an AI Agent

So what happens when we connect an actual AI agent?

Instead of building my own agent, I used the WebMCP – Model Context Protocol Inspector extension. You can connect a Gemini API key and immediately start experimenting. There's even a free token allowance. Small, but still enough to make some questionable strategic decisions 😅

As with most LLM-powered systems, everything starts with a prompt.

Scenario #1: The LinkedIn CEO 😎

Let's see how our CEO performs when given the following instruction:

Act like a CEO who just read three articles about AI on LinkedIn.

As you can see, the agent selected the appropriate tools and immediately got to work.

The company's employees may have started updating their LinkedIn profiles in panic, but at least the hype level reached previously unimaginable heights.

Scenario #2: Rebuilding Employee Trust ❤️

Now let's try something a little more challenging:

I want to rebuild my employees' trust while simultaneously developing the product.

This time our agentic CEO made several surprisingly clever moves and managed to guide the company back toward sustainable growth.

So... Is This The Future?

Honestly, I had way too much fun building this.

No, I don't think this is a glimpse into a future where self-healing AI agents manage the global economy while piloting commercial aircraft.

But I do think webMCP solves a real problem.

If AI agents are going to spend more and more time interacting with our applications, giving them a structured way to understand those applications makes a lot more sense than forcing them to endlessly scrape HTML and guess what every button does.

Will webMCP become a normal part of web development?

Will adapting websites for agents become as common as responsive design or accessibility?

Or will this trend disappear before it ever reaches the mainstream?

I'm genuinely curious what you think.

If you enjoy my articles, feel free to follow me on LinkedIn as well.

How Are Developers Actually Using AI At Work?

Sylwia Laskowska — Wed, 27 May 2026 07:11:18 +0000

JSNation is coming soon, and besides my talk (I’ll drop the link in the comments so I don’t spam you with it for the tenth time 😅), there are also discussion rooms. And somehow, I got invited to two of them.

Now, a normal person would probably stop for a second and think: “Do I even have time for this?”, “Is it worth it?”, “Should I maybe not overcommit myself for once?”. Meanwhile, in classic Sylwia fashion, I replied almost instantly: “Oh, that sounds amazing! Sure, sign me up for everything!” 😎

And that’s how I ended up in a discussion room called “The New Senior Engineer: Builder, Reviewer or Orchestrator?”.

Now, my career advisor, ChatGPT, always tells me: “Sylwia, please get your life together. And if you insist on doing ten things at once, at least reuse the content.” 😅 So instead of coming up with all the conclusions myself, I thought: why not ask the DEV community?

But before I ask the big question — what should a Senior Engineer become in the AI era — I think there’s another, more interesting one first: how are you actually using AI at work?

Not in conference demos. Not in viral Twitter threads. Not in “my AI agent rewrote Kubernetes during lunch” stories. I mean real work. Real projects. Real teams.

Of course, feel free to jump straight into the comments (you know I love talking with you all ❤️), but first, a few observations from my side.

AI Above Everything

At least that’s the image the internet gives us. Conference titles. Newsletter headlines. LinkedIn prophets.

Matteo Collina opens a 100k-line PR for Node.js and people panic.

Someone rewrites an entire React application to Svelte in two weeks. Hundreds of thousands of files.

The creator of Bun rewrites it from Zig to Rust in one evening, while casually mentioning he also went on a date that night. (Am I the only one getting weird associations here? 😅)

Armies of agents replacing development teams. Agents opening PRs for other agents to review. Everything automated. And somewhere in the middle of all this, the Senior Engineer becomes some kind of AI shepherd, occasionally checking whether the robots are heading straight into a cliff.

Honestly, it’s both fascinating and mildly terrifying. Sometimes it makes you wonder whether we should all reconsider our career choices and maybe sign up for hairdressing school before the robots learn that too 😅

But then I stop for a second and think: I actually work in this industry. I know a lot of developers. And real life often looks… very different.

From Excitement to Cost Optimization

A friend of mine works at a huge tech corporation. One of those companies you definitely know — and probably either love or hate 😄

Of course they started using AI tools very early, including Copilot. But things really escalated once they got proper coding agents — I think Claude Code.

At first, the company was completely mesmerized. They bought the most expensive plans possible and encouraged people to use AI aggressively. If someone hit token limits, management basically said: “Don’t worry, we’ll buy more. It’s revolutionary!”

My friend happened to be building a new application from scratch and honestly — he loved it. The amount of code generated was absurd. Normally, building something like that would take months with an entire team. Now? A few days and huge chunks of the system already existed.

And because he’s genuinely an excellent developer, he became very good at noticing the exact moment Claude started going completely off the rails. Interestingly, this often happened around 5 PM. Apparently the AI wanted to clock out too 😅

But after a few months, the excitement slowly started fading. Turns out that while AI sometimes makes development dramatically faster, it definitely doesn’t always.

And then came the second surprise: the company actually calculated how much all this AI usage was costing. Suddenly everyone discovered that — surprise, surprise — unlimited AI agents aren’t exactly cheap 😄

So now there are discussions about limits, optimization, and reducing token usage. At this rate, maybe hiring interns will eventually become the cheaper option again 😂

And honestly, we’re already seeing this trend more and more. Wasn’t it Meta that introduced some kind of “tokenmaxxing” culture where people were rewarded for using fewer tokens?

And Finally, My Own Story

Now let’s move to my world.

A massive international institution. An enterprise ship that takes three years to turn right. A place where privacy is treated almost like religion. So naturally, people were extremely skeptical about LLMs for a long time.

But eventually AI arrived there too, which honestly makes me think these tools are now basically everywhere 😄

So: do coding agents massively accelerate development in enterprise legacy systems?

Well… that’s where things become complicated.

Sure, there are tasks where AI is genuinely useful. Simple bugs. Small features. Boilerplate work. But on some tasks? It completely collapses.

The agent reads library code. It crawls through the application. It searches half the repository. And still somehow understands absolutely nothing 😅

Sometimes I literally have to tell it: “Maybe check that weird file written by a junior developer seven years ago.” Or: “Our UI library has some very specific legacy quirks, maybe investigate that direction.”

And honestly? After 2.5 years in this project, I’m simply faster than the AI agent in many debugging scenarios.

Not because I’m smarter. Not because AI is useless. But because enterprise systems accumulate context, history, weird decisions, tribal knowledge, hidden dependencies and architectural scars over many years. And I have that context. The AI usually doesn’t.

And I honestly doubt my project is unique here. A huge percentage of software running the world today is enterprise legacy that survived far longer than anyone originally planned — and is still actively evolving 😄

So maybe, somehow, I’ll actually survive as a programmer until retirement after all. And maybe I won’t need to learn hairdressing.

Which is probably good news for humanity, because I’d be terrible at it 😅

But now I’m genuinely curious: what does AI usage actually look like in your work?

Million-line AI PRs? Daily battles with legacy systems? Token optimization? Or maybe something completely different?

BTW, If you like my posts, feel free to follow me on Linkedin!

Every Developer Is Lying About Something — And AI Won’t Fix It

Sylwia Laskowska — Thu, 21 May 2026 07:06:41 +0000

Yes, all of us are lying. And you are probably lying too. Let me prove it 😉

Oh, I have so many article topics in my head right now. The really exciting kind. But this week absolutely steamrolled me 😅 I finally finished preparing my JSNation talk, and at the same time two other amazing opportunities appeared — one professional, and one that feels more like a childhood dream coming true ☺️ But I don’t want to jinx it yet.

And just so it doesn’t sound like everything magically works out for me — I’ve also had a few CFPs rejected recently. The ones I actually cared about! But honestly? That’s just part of the game. One conference may reject your talk this year and happily accept another one from you the next.

So yes, the really big topics will have to wait a little bit longer 🙂 Which doesn’t mean this one is trivial.

We talk about AI everywhere now, as if it’s going to solve all our problems. But as we’ve already noticed, there’s no AI without humans, and behind every “smart” model there’s still some human being — at least for now 😉

Which is probably why, in practice, coding agents do speed things up… but not nearly as much as many people expected. Some studies even suggest they slow developers down.

Because the real problem is often not the code itself. The real problem is the people writing or generating that code.

And unfortunately, all of us lie in one way or another. Sometimes to others. Sometimes to ourselves.

Some Developers Lie About Knowing What They’re Doing

One of the best developers I know once confessed something to me.

This guy is genuinely brilliant. The kind of engineer companies fight over. He currently works on optimizing drivers for LLMs, gets promoted constantly, and even in this lovely “tech crisis” era, he still had multiple job offers to choose from when he considered switching jobs.

And yet, every single time he joins a new project, he feels like a complete idiot.

Everybody else seems productive. People are delivering tickets. Writing code. Moving confidently through the project. Meanwhile, he sits there staring at the codebase wondering:

What exactly is happening here?
What are we even building?
Why does this work like this?
Why are we implementing it this way and not differently?

And then he starts asking questions.

Usually, it turns out nobody really knows what they’re doing, why they’re doing it, or whether they’re even solving the right problem in the first place.

It reminds me of that old joke about lumberjacks cutting down a forest. Eventually, the team leader climbs the tallest tree, looks around, and screams:

“Guys! We’re cutting down the wrong forest!”

And the workers below shout back:

“Who cares? We’re making great progress!”

And honestly, no LLM will save us here. Especially if we never even ask the right questions.

Others Lie About Knowing How To Do Something

This is basically an extension of the previous problem.

A less experienced developer picks up a task and confidently says:
“Yeah, I know how to do this.”

Unfortunately, what they often mean is:
“I hope I’ll somehow figure it out.” 😅

In reality, they may not know how to solve the problem, which tools to use, what architecture makes sense... or even what prompt to write to get useful help from a coding agent.

But they’re afraid to ask.

Because how will they look in front of the team? What will the manager think? The tech lead?

Best-case scenario: they eventually ask questions… just way too late.

Worst-case scenario: they never ask at all and deliver something completely wrong. Which often isn’t even caught properly because…

Someone Else Is Lying About Having Time

Now we’re entering senior and leadership territory 😅

The motivations differ. Some people build their self-worth around being “the reliable one.” Others are terrified of losing status, influence, or even their job.

So they keep taking on more:

the hardest tasks,
endless meetings,
refinements,
estimations,
discussions with support,
discussions with business,
code reviews,
architecture decisions,
documentation.

And let’s be honest. Something eventually has to break.

Human beings are not made of steel. Nobody can operate at 100% forever.

So what happens?
People start half-listening during calls. Code reviews become rushed. Documentation quietly dies in a corner somewhere.

But they still refuse to admit — either to others or to themselves — that they’re simply overloaded.

Some Developers Lie About How Long Things Will Take

I see this constantly with more advanced juniors and mids.

They throw around hilariously optimistic estimates with absolute confidence.

And sure — if they could work uninterrupted for eight straight hours, the application contained no legacy code, edge cases didn’t exist, and other humans never interacted with the system… then maybe the estimate would actually be correct 😄

Then sprint review arrives, and suddenly everybody is shocked that the team didn’t deliver everything.

But this is not the only problem with estimations.

I once worked with an especially funny senior developer.

He treated estimations like sacred truth. He would aggressively defend his numbers during planning sessions, insisting that this specific task was definitely extremely complicated. The rest of the team usually suspected it wasn’t that bad, but eventually we’d surrender just to end the discussion.

And then — at least three separate times — he personally picked up the exact task he had massively overestimated… and finished it in about an hour.

Which basically meant the estimation discussion itself took longer than implementing the feature 😅

Did this experience change his behavior?

Absolutely not.

And Some Lie About Knowing Everything Best

These are probably the most dangerous ones.

I avoid people who say things like:

“Use THIS technology and ONLY this technology because everything else is garbage.”

Insert your favorite holy war here:
Angular vs React, Java vs Python, Rust vs literally anything else 😄

I never write like that myself. Even when I publish something titled “I Love Tailwind. Sorry Not Sorry”, I still talk about its downsides and explain where it absolutely doesn’t make sense.

If one day I start claiming some technology is objectively perfect for every possible situation, please leave a comment saying:

“Sylwia, go touch grass immediately.” 😅

Honestly, I’ve always wondered where this sense of absolute certainty comes from.

Because not all of these people are even paid influencers. Some genuinely seem emotionally attached to technological holy wars. Others maybe only know one stack deeply, so everything else automatically feels “bad.”

And while this behavior is very common among tech influencers, you absolutely see it inside companies too.

The problem is that this kind of certainty can seriously damage projects. People stop questioning decisions. Other developers become afraid to speak up. Stakeholders assume “the confident person” must be right simply because they sound convinced.

Best-case scenario: you end up with an annoying developer who knows more about frameworks than the actual business domain.

Worst-case scenario: you end up with a terrible stack choice and spaghetti architecture held together by ego.

People Are Just… People

Of course, I’m not innocent either.

I’ve used many of these lies myself in the past. Maybe I’m older now. Maybe slightly wiser. Or maybe I just recognize these patterns more easily.

But I’m definitely still lying somewhere too. Maybe not to others — maybe to myself.

Because a lot of our problems in software development aren’t really technical problems at all. They’re deeply human problems:

ego,
insecurity,
fear of looking stupid,
fear of admitting mistakes,
fear of saying “I don’t know.”

And honestly, I don’t have some magical solution for this. We’re not going to require three years of therapy from every developer before allowing them into a sprint planning meeting 😄

But I have noticed one thing.

Very often, admitting you don’t know something, openly discussing uncertainty during planning, or simply saying:

“Sorry, I still don’t understand this. Could you explain it one more time?”

doesn’t make people see you as a worse developer.

Quite often, the opposite happens.

Suddenly communication inside the team improves. Other people start asking questions too. Conversations become more honest. Problems get discovered earlier.

Seriously. Try it at least once. You might be surprised 🙂

So… what kinds of developer lies do you see most often in your team?

4 Tiny Mistakes That Secretly Destroy App Performance

Sylwia Laskowska — Thu, 14 May 2026 06:04:15 +0000

Ok, I’m back from my short vacation and returning with some useful content 😄 As you know, from time to time I write posts for you in the style of articles like Stop Installing Libraries: 10 Browser APIs That Already Solve Your Problems — which I honestly love writing, and I know you enjoy them too 🙂

Today I want to approach the topic from a slightly different angle. I’m going to show you a few interesting things that might accidentally be making your app much slower, even though they often look completely innocent at first glance. And the best part? Some of them can be fixed surprisingly quickly. Also, these are the kinds of issues Claude Code or Codex probably won’t immediately point out when you ask them “why is my app slow” 😅

Usually, we develop our applications on powerful machines with fast CPUs, plenty of RAM, and fast internet. Unfortunately, real users often live in a completely different reality. Some of them absolutely have modern hardware, but there will always be somebody using an old laptop, a cheap Android phone, weak WiFi, or mobile internet from the depths of hell 😅

And suddenly it turns out your app is painfully slow for 10–30% of users.

And that’s where the war for milliseconds begins 😀

Every example in this article is something I either personally encountered in a real project or heard about from another developer, so these are definitely not hypothetical scenarios. Check whether some of these things are secretly happening in your own application 👀

Meanwhile, I’m slowly preparing for my JSNation conference talk. If you want to support me (or just see me awkwardly talking in my garden 😄), you can give me a like here. And if you want to watch my full talk completely FOR FREE, you can grab a free badge here. HOW COOL IS THAT 😄

But enough self-promotion, let’s get to the point!

1. Custom headers → preflight requests

This is exactly why it’s worth attending conferences. Sometimes you hear about problems there that you would probably never randomly google yourself 😀

One of my colleagues talked about this issue during his presentation. His team was trying to understand why their application felt slow for some users. Naturally, the backend was blamed first. Poor backend, as always 😅

But eventually they noticed something interesting in the network tab: OPTIONS requests appearing before almost every API call. Some of them were taking hundreds of milliseconds.

So what exactly is happening here?

This is related to CORS. Browsers sometimes send an additional OPTIONS request before the actual API call. This is called a preflight request and usually happens for “non-simple” requests — for example when using methods like PUT or DELETE, but also when adding custom headers.

And yes, even a completely innocent GET request can suddenly become two network calls because somebody added X-Feature-Whatever three years ago 😅

In their case, the funniest part was that the custom header wasn’t even used anymore. It was some ancient historical leftover from years earlier. Nobody knew why it existed. Nobody questioned it. It simply survived every refactor like an immortal enterprise relic 😀

If you’re curious, I actually prepared (together with Claude Code 😅) a small repo showing this behavior here:
https://github.com/sylwia-lask/preflight-options

Let's see the screens (please appreciate my high graphic skills!):

GET request without custom header:

GET request with custom header:

And honestly, this kind of thing happens all the time in large projects. Somebody adds a custom header for feature flags, debugging, localization, analytics, or “temporary” metadata… and then the header survives for the next four years.

Of course, sometimes custom headers are completely justified. But if you only use them for frontend-only logic, there are often better alternatives like query params, cookies, local state, or configuration endpoints fetched once during startup.

Individually, one extra request may not look catastrophic. But if your app performs dozens of calls during startup, especially on slower mobile connections, this suddenly becomes very noticeable.

2. Code splitting that does absolutely nothing

Sometimes the problem isn’t the network itself but the gigantic JavaScript bundle we load during startup. And this is usually the moment where everybody says:

“But how? We’re already doing code splitting! We use lazy loading everywhere!”

Yeah… about that 😄

I once audited an Angular application that looked very well structured at first glance. It had modules everywhere, lazy loading, proper architecture, all the “best practices.”

And yet the application loaded painfully slowly.

Fortunately, we have tools like webpack-bundle-analyzer, source-map-explorer, rollup-plugin-visualizer, or @next/bundle-analyzer that allow us to see what’s actually happening inside our bundles.

And what did we discover?

Yes, the application was split into modules…

…except each module was like 2 KB 😅

Because almost everything important lived inside one gigantic shared module that was imported absolutely everywhere, meaning most of the application still ended up inside the main bundle anyway 😀

Congratulations, your app is now split into 400 beautifully separated files that all load at startup.

This is also not the only weird case I’ve seen. I’ve already encountered situations where the app technically “lazy loaded” modules while still downloading almost the entire application every single time 😄

For example, something like this looks perfectly fine:

{
  path: 'admin',
  loadChildren: () =>
    import('./admin/admin.module').then(m => m.AdminModule)
}

Looks clean. Looks modern. Looks optimized.

Until you discover that AdminModule imports a massive shared module containing half the application 😅

So yeah — just because you use import() or lazy modules does not automatically mean your bundles are healthy. Always check what is actually being downloaded by the browser.

3. Unnecessary runtime dependencies

This is another extremely common problem, especially in projects where nobody really controls what npm packages people install 😅

In my current project, importing a new dependency is practically treated like a sacred ritual that requires approval from the wisest architects of the kingdom (which basically means me and two or three coworkers 😀). But in many projects, people install libraries completely thoughtlessly.

And then suddenly your application contains:

three analytics SDKs,
two date libraries,
all Moment.js locales,
the entire Lodash package because somebody needed one utility function,
Firebase imported globally,
three icon packs,
and some “tiny lightweight helper package” that quietly imports half the internet 😀

I once saw an application loading three different date libraries at the same time. The funniest part? The app barely even handled dates 😅 Apparently every developer simply had their own preferred religion.

Another classic example is importing Lodash like this:

import _ from 'lodash';

instead of:

import debounce from 'lodash/debounce';

The difference may look small, but over time these things accumulate a lot. Especially in enterprise applications that grow for years.

And unfortunately, tree shaking is not magic 😅

4. Huge background images

This one sounds almost too obvious, right?

Everybody already knows giant images are bad.

…except people still keep shipping giant images 😄

Recently, during the WeAreDevelopers podcast, we discussed which government websites loaded the fastest. Surprisingly, the UK completely dominated everybody else. Why? I’ll probably write a separate article about this later, but generally speaking, the site was just extremely simple. Very little visual noise, lots of informational text, simple layout, SSR, minimal unnecessary assets.

The second fastest was the US government website.

It followed almost exactly the same principles… except it loaded a fancy large image during startup 😅

And suddenly the large contentful paint became noticeably worse.

The funny thing about large background images is that they often look harmless on developer hardware with fast internet. But on slower devices they can absolutely destroy perceived performance.

Fortunately, there are many ways to improve this: use AVIF or WebP, compress aggressively, avoid massive hero images above the fold, lazy load non-critical visuals, and preload only truly critical assets.

And honestly?

Sometimes the fastest image is simply… no image 😀

Final thought

Application optimization is obviously an endless topic, and this article only scratches the surface. But I think one of the most important things to understand is that performance problems are often death by a thousand cuts.

One unnecessary header.

One oversized dependency.

One “temporary” shared module.

One background image nobody questioned.

Individually, none of these things look catastrophic. Together, they create an application that feels sluggish — especially on older devices or slower mobile networks.

And the really scary part?

Most of these decisions looked perfectly reasonable when they were originally introduced 😅

I Love Tailwind. Sorry Not Sorry

Sylwia Laskowska — Mon, 04 May 2026 08:54:09 +0000

I’m going on a short vacation this week, so this post is coming out a bit earlier than usual. I actually had a different, more “useful” topic in mind — something educational, something responsible. But then I came across this fascinating article: I don’t like Tailwind. Sorry not sorry written by @freshcaffeine , and I couldn’t get it out of my head.

So I decided to write a response instead.
Useful content will have to wait 😄

I actually agree with many of the points in the original article — especially around learning fundamentals. I just have a different perspective shaped by a different kind of work.

Let me start with a small disclaimer: I’ve written a lot — and I mean a lot — of handcrafted CSS in my life. Entire design systems. In fact, I got my first job in IT mostly thanks to my CSS skills, because my programming skills at the time were… let’s say “a work in progress” 😉

There was even a period when I made extra money building simple websites for clients. People literally paid me for delivering clean, aesthetic CSS.

So in theory, I should be the first person to defend handcrafted CSS and criticize Tailwind for polluting HTML.

And yet… I’m not.

Despite all its flaws, I love Tailwind. Deeply, sincerely, and yes — unapologetically.
Because it gives us something incredibly valuable in real-world development: speed and predictability.

Pumpkin pie: homemade or store-bought?

The author of the original article uses a pumpkin pie analogy. Handcrafted CSS is like baking a pie from scratch — roasting the pumpkin, making the dough, carefully preparing everything with love. Tailwind, on the other hand, is like using pre-made ingredients. You open a can, use ready-made crust, assemble everything quickly. Sure, it’s still a pie, but not quite like the one your grandma would make.

It’s a nice analogy. It really is.

The problem is — most businesses are not running artisan bakeries.
They’re running factories.
And those factories aren’t even in the pie business.

In reality, business rarely needs a handcrafted pie. Honestly, it often doesn’t even need a “semi-handmade” one. What it really wants is mass production: something that’s sweet enough, looks good enough, doesn’t cause stomachache, and can be delivered fast. If you can add a small decorative touch on top to make it feel slightly more unique — great. But even that is optional.

And there’s no point being offended by this. We can absolutely build beautiful, handcrafted CSS when we want to. But most of the time, businesses choose speed — because they are selling a product, not CSS.

I’m not building a piece of art.
I’m building software that five teams won’t break next week.

Repetition isn’t always a bug

One of the arguments against Tailwind is that everything starts to look the same. And honestly — that’s true.

But here’s the thing: very often, that’s exactly what the client wants.

Back when I was building websites for clients, the happiest ones were those who got three templates to choose from and a bit of customization on top. They didn’t want a masterpiece. They wanted something clean, modern, and effective — something that sells.

Tailwind is often simply good enough for that.

And in many cases, good enough delivered fast beats perfect delivered late.

“Messy HTML”

Yes — if you just throw classes around randomly, your HTML will look messy.

But let’s be honest: if we’re “craft-oriented developers,” we can organize our components properly, right? In real projects, that long Tailwind class list usually lives inside a component anyway. You don’t copy-paste that everywhere.

Also:

HTML is “noisy”? Sure.
But at least the rules are right next to what they affect.

I’ve seen plenty of “beautiful” CSS codebases where styling logic was scattered across multiple files, overridden in unexpected places, and impossible to trace without jumping through five layers of abstraction. I’ll take explicit over “hidden magic” any day.

Junior developers and “not learning CSS”

I actually agree with one part: Tailwind doesn’t replace learning CSS. I even wrote about that in my article: Is Learning CSS a Waste of Time in 2026?

But the argument that Tailwind is somehow “hurting juniors” always makes me smile a bit.

On one hand, we have mass layoffs in tech and endless discussions about AI replacing developers. On the other, we worry that juniors might not learn CSS because things are… too easy?

Let’s be real for a second.

“Junior” doesn’t mean “child.” These are adults. If someone wants to grow as a frontend developer, learning CSS is part of the job. It’s not some hidden, mystical knowledge. And we don’t need to choose our entire tech stack based on making things harder just so people are forced to learn.

Also — I’ve seen plenty of experienced developers who still struggle with CSS after years in the industry. At that point, I’d honestly rather have them use Tailwind and ship something consistent than fight yet another specificity war.

Tailwind doesn’t create bad developers.
Lack of fundamentals does.

About “craft”

There’s this idea that writing CSS is a form of craftsmanship — something closer to art, something deeply satisfying.

And yes, it can be.

But the last few years — especially with the rise of LLMs — have made it pretty clear where our “craft” actually sits in the bigger picture. In most business applications, CSS is not art. It’s not painting. It’s not sculpture.

It’s closer to baking pumpkin pies at scale.

There will always be places where handcrafted work matters — just like there are bakeries selling beautiful, artisanal cakes. But if you’re selling paper clips and organizing a corporate event, you’re probably not baking everything from scratch. You’re ordering something decent that gets the job done.

And that’s fine.

Why I actually like Tailwind

Let’s be clear — Tailwind is not perfect. It has trade-offs.

But it solves very real problems.

It gives you:

speed — you don’t context-switch between files every 10 seconds
predictability — no guessing what some class name means
consistency — especially across large teams
simple selectors — which are often easier for browsers to process than deeply nested CSS
less dead code — thanks to modern build setups

And most importantly:

It removes ambiguity.

The real problem in large codebases isn’t that CSS isn’t “beautiful” enough.
It’s that it becomes inconsistent, fragile, and slow to evolve.

I’ve never seen a project fail because CSS wasn’t handcrafted enough.
I’ve seen plenty fail because things were inconsistent and took forever to build.

When handcrafted CSS still makes sense

I don’t think Tailwind (or something similar) should replace handcrafted CSS everywhere.

There are cases where writing CSS by hand is not just useful — it’s the better choice.

Design systems and shared UI foundations — where you need full control and long-term consistency
Highly custom or experimental UI — where utility classes start to fight you instead of helping
Performance-critical interfaces — where you want precise control over what gets shipped
Learning and understanding the fundamentals — because at some point, abstractions always leak

Final thoughts

Tailwind isn’t about replacing CSS.
It’s about making frontend development survivable at scale.

And no — this post is not sponsored by Tailwind. (But if someone from Tailwind happens to read this… feel free to reach out 😄)

And what do you guys think? Are you Team Tailwind or more into 'craft' CSS? Or maybe something in between?

Thanks for reading! If you enjoyed this post, I'd love to have you follow me here on LinkedIn.

Is Software Development Just a Side Quest? A Jira Story

Sylwia Laskowska — Thu, 30 Apr 2026 06:01:20 +0000

How much time did you spend this week moving tickets in Jira (or other tracking tool) instead of actually coding?

I sometimes have this feeling that my main job is not development anymore — it’s just moving things between columns.

I always say that a software developer, by nature, is lazy. That’s why we became developers in the first place — to automate everything. So maybe expecting us to not only do our actual work, but also carefully maintain every single detail in Jira… is a bit optimistic.

Quick “what’s up with me” section. My recent article
Most Apps are Slower Than They Need To Be
ended up going way beyond DEV — different newsletters, and it even got me invited to a podcast at WeAreDevelopers 🎤 First podcast in my life. Chaos, tangents… pretty much 100% me 😅

And here’s a fun part: the technical article that opened those doors had almost 6x fewer views than this one:
You're a Real Software Developer Only If... Well, turns out we all enjoy a good laugh more than GPU acceleration demos. Can’t argue with reality 😄

Anyway, back to the topic.

I’m a senior developer. Not officially a tech lead in my current company, but in practice I do a lot of that work, next to coding. Coordinating developers' work, answering questions, helping unblock people. And it’s not just the team — there are stakeholders, testers, other teams.

And the app? It’s a government system. So if something breaks, it’s not “oh no, someone couldn’t watch a show” (haha yes, I'm refering to @adamthedeveloper and his famous You're Not Building Netflix post 😁). The consequences can be very real.

After a day like that, the last thing I feel like doing is carefully updating every field in Jira.

Don’t get me wrong — I actually like having a tracking tool. I can’t imagine working without one, especially in a bigger team. Tasks need to exist somewhere, priorities need to be visible, things shouldn’t disappear into Slack threads.

I also create tickets myself all the time, or ask for them to be created. I want things tracked. I want a history. I want clarity.

But for me, a ticket should have three states: todo, in progress, done.

Everything else is… negotiable.

Stories? Epics? Fine. If it helps someone manage the process, I can live with that.

But then come the extra fields. The additional statuses. The “just one more thing” because it will make the report nicer. Because the burn-down chart will look better. Because someone somewhere wants a cleaner dashboard.

And slowly, without really noticing, we turn Jira into something that requires more mental effort than the actual development.

We’re basically the boiling frog at this point. One more field. One more status. One more small tweak. Until suddenly nobody really knows what goes where anymore, what needs to be updated, and why.

And then, of course, developers get blamed for “not keeping Jira up to date”.

At some point it starts feeling like development itself is just a side quest. If we didn’t have to deal with code at all, imagine how perfect our Jira boards could be. Beautiful burn-down charts. Perfectly filled tickets. Absolute harmony 😄

The funny thing is — the best developers I know are often the ones who engage with this the least. Not because they don’t care, but because their focus is somewhere else. On solving real problems.

I’m still managing it somehow. But I definitely feel the friction.

So I’m curious — is it just me?

Do you also feel this kind of frustration sometimes? Or did you actually manage to find a system that works without turning Jira into a full-time job?