DEV Community: Sylwia Laskowska

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?

If AI Existed in 2011, Would We Still Have the Modern Web?

Sylwia Laskowska — Wed, 22 Apr 2026 08:04:46 +0000

Imagine it’s 2011. The web is mostly server-rendered PHP templates, maybe a bit of jQuery if you’re feeling fancy, or sometimes no JavaScript at all. Interactivity is limited, everything is a request-response loop, and the idea of complex client-side apps isn’t really mainstream yet. It works, it’s predictable, and honestly… nobody is panicking 😄

Now imagine that into this world, suddenly, we drop modern AI. Not some early experimental models, but something close to what we have today — LLMs, coding agents, tools that generate entire features from prompts. Codex, Claude Code, all that magic. The kind of tools that can scaffold half your app before you even finish your coffee ☕

Quick side note before I continue, because I’m way too excited not to mention this 😄 I’ll be speaking at JSNation 2026, which still feels a bit surreal. It’s one of those conferences where all the big JavaScript minds show up… and apparently also me 😉

Don’t worry though — I won’t bring shame to the DEV community 😅 I’m bringing my talk “Rewrite or Refactor? How to Safely Move Legacy Apps to Modern Frameworks,” which I’ve already tested on stage. If you’re curious, you'll be able to watch it here: https://gitnation.com/badges/jsnation-2026/sylwia_laskowska_154511. And honestly, even if you’re not a frontend dev but you like my articles, you’ll probably enjoy it anyway — it’s basically a “spoken article” 😄

Also, to celebrate, I bought a non-alcoholic beer and somehow woke up feeling like I had a huge hangover. So yes, new achievement unlocked.

So back to the thought experiment. What actually happens next? Do we accelerate into the modern web faster, because suddenly everyone has a superpowered assistant? Or do we get something much less exciting — a world where AI keeps reinforcing what already works and we never quite feel the need to move beyond it?

Because here’s the uncomfortable question: what if AI doesn’t accelerate progress as much as we think… but instead quietly stabilizes it? 👀

AI Is Brilliant — As Long As You Stay on Known Ground

I’m not an AI expert, and I’m not going to pretend I am. I use LLMs daily, I know what RAG is, I understand inference, matrix multiplication, sampling — enough to work with it comfortably. But I never really thought about AI in terms of shaping the direction of technology, not just speeding it up.

That changed when I started working more with WebAssembly and WebGPU. And something became obvious pretty quickly.

LLMs are extremely good at things like Rust, standard frontend work, typical patterns — anything with lots of existing examples. You ask for a simple feature, like downloading an image, and you get clean, idiomatic code almost instantly. It honestly feels like cheating 😄

But the moment you move into newer territory, like WebGPU and WGSL shaders, things start to break down. Mistakes become frequent, assumptions are off, APIs get mixed up. You stop trusting the output and go back to manual coding, debugging everything yourself like it’s 2010 again.

And it’s not because AI is “bad.” It’s because it simply hasn’t seen enough of it. WGSL has only been around since roughly 2021. Compared to decades of web dev patterns, that’s basically nothing.

AI Optimizes for What Exists

This is where the whole thing flips a bit. We like to think AI helps us write better code and make smarter decisions. But in practice, it mostly guides us toward what is most common, most represented, most reinforced by data.

It doesn’t think like a senior engineer. It doesn’t evaluate trade-offs or long-term consequences. It pattern-matches.

That’s why it will often default to React on the frontend — not because it’s always the best choice, but because it’s everywhere. Angular or Vue might be a better fit in some cases, but AI doesn’t “prefer” them. It just hasn’t seen them as much.

If you’re experienced, you catch this and adjust. But if you’re tired, under pressure, or just want to get things done (so… most of us most of the time 😅), you go with what it gives you. It works, it compiles, ship it.

And that’s the subtle shift: AI isn’t just helping you code — it’s quietly influencing how we all code.

From Exploration to Convenience

Before AI, web development was rarely about comfort. It was about pain 😄

PHP templates worked — until they didn’t. We needed interactivity, so we started hacking things with JavaScript. Then jQuery appeared to manage the chaos. Then SPAs happened, because managing state on the client became unavoidable. Frameworks evolved, patterns evolved, everything kept moving forward.

There was always friction. And that friction forced people to think, experiment, and sometimes try things that weren’t yet mainstream.

Now imagine removing most of that friction. You can get a working solution almost instantly, without digging too deep. And when that happens, something subtle shifts. You stop asking “is this the best way?” and start asking “does this already work?”

And once that mindset kicks in, exploration slowly starts to disappear.

Cognitive Miser Meets AI

There’s also a very human factor here. We’re what psychologists call “cognitive misers,” which basically means we avoid unnecessary thinking whenever possible. If there’s an easier path, we take it.

AI is the ultimate easy path — which is exactly why it’s so powerful 😄

But it also creates a feedback loop. AI suggests common solutions, developers implement them, those solutions become even more common, and AI becomes even more confident in suggesting them again.

Breaking out of that loop requires effort. And effort is exactly what we’re trying to avoid when using AI in the first place.

Back to 2011

So let’s go back to that original scenario. You’re a developer in 2011, building a web app. You have access to a powerful AI assistant trained on everything that existed at the time: PHP templates, early JavaScript, server-side rendering patterns.

You ask it how to build a feature, and it gives you a clean, working solution — in PHP. It’s fast, it’s familiar, and it solves your problem.

Would you really push for a completely new paradigm, like client-side apps? Would you experiment with something that doesn’t yet exist, when the current approach already works and is fully supported by your tools?

Or would you just… ship? 😄

If enough people choose to just ship, something interesting happens. Not a dramatic collapse — just a quiet lack of movement.

And suddenly, the future doesn’t get built as quickly as it could have.

The Real Risk

I don’t think AI will replace developers. That’s the obvious discussion, and honestly, the less interesting one.

The more interesting possibility is that AI makes us extremely efficient at continuing in the same direction we’re already going. Not because it’s wrong, but because it’s shaped by the past and optimized around it.

And if we’re not careful, we might start optimizing everything — our tools, our workflows, even our decisions — around what already exists, instead of pushing toward what doesn’t yet.

A Different Perspective

On the other hand… when it comes to innovation, things are accelerating like crazy. New ideas are moving faster than ever. What used to take years now happens in months.

But innovation has always been driven by a relatively small group — the ones exploring new tools and pushing boundaries.

The rest of us?

We sit down every day and work with what’s already there. Stable, supported, well-documented. The kind of stack AI understands really well.

So yes — innovation is speeding up. But at the same time, AI might be making it easier than ever for everyone else to stay exactly where they are.

And that’s exactly why I hope I’m wrong.

So now I’m really curious — what do you think?

If AI had existed in 2011, would we have built the modern web faster… or would we still be comfortably sitting in index.php? 😄

If you made it this far, maybe consider giving me a like or even a follow on
LinkedIn 🙂

I’ll admit — I’m definitely not a LinkedIn master 😄 My reach there isn’t amazing (I usually just post links to my articles, often with a delay xD). But I think I might have an idea for some shorter-form content there…

Most Apps Are Slower Than They Need to Be — Here’s Why (Live Demo🛸)

Sylwia Laskowska — Thu, 16 Apr 2026 07:05:26 +0000

We’re a quarter into the 21st century, and the browser has quietly evolved into something much more than just a UI layer. It can run complex computations, leverage the GPU, process audio, simulate physics, and even run machine learning models. And yet… most of the time, we still treat it like a tool for forms and dashboards.

I wanted to show what happens when we actually take advantage of what the platform already gives us.

The jsday conference in Bologna has just come to an end, and it was honestly amazing. If you’re wondering whether it’s worth attending events like this — it absolutely is. It’s an endless source of inspiration, far beyond what you get from articles or tutorials. If you have a minute, I’d really appreciate a like on my LinkedIn post

If you’ve been following my posts, you probably know that my talk was about WebGPU and WebAssembly, and what we can gain by using them in the browser.

So what are these two technologies, and why does it make more sense to talk about them together rather than separately?

They are complementary by design. WebAssembly runs on the CPU and allows us to execute low-level, compiled code directly in the browser. WebGPU, as the name suggests, gives us access to the GPU — not in some abstracted, limited way, but in a relatively direct and powerful form.

If you want a deeper dive, I’ve written more about them here:
WASM → https://dev.to/sylwia-lask/will-webassembly-kill-javascript-lets-find-out-live-demo-43ln
WebGPU → https://dev.to/sylwia-lask/why-webgpu-feels-like-the-future-of-the-web-live-demo--2bjh

But instead of talking about them in isolation, I wanted to show a concrete example of what happens when you combine them.

Because I’m not a fan of theory without practice, I built a small demo.

👉 Repo: https://github.com/sylwia-lask/text-goes-boom
👉 Live demo: https://sylwia-lask.github.io/text-goes-boom/
(Fair warning — especially the JS canvas benchmark can get your CPU quite warm 😅)

What does it do? You type text into an input field. The text is converted into particles. And when you click and drag your mouse across it… the text explodes.

Completely useless? Yes. Slightly addictive? Also yes 😅

What’s happening under the hood?

First, the text from the input is rendered into an image bitmap using plain JavaScript and Canvas 2D. This is exactly the kind of task where the classic browser APIs are already perfectly sufficient, and there’s no real reason to move it elsewhere — especially for a demo like this.

Next, the bitmap is passed to WebAssembly. This is where I run a deliberately “somewhat over-engineered” algorithm that maps the image into particles. I wanted WASM to actually have something meaningful to do, and let’s be honest — it also just looks cooler this way. Out of curiosity, I benchmarked it against an equivalent implementation written in JavaScript.

As you can see, this is where we get the first tangible gain. WebAssembly is roughly 2–3× faster in this case. And this isn’t even a best-case scenario — I put quite a bit of effort into optimizing the JavaScript version as well, just to make things fair and not give Rust an easy win.

In this particular demo, the difference doesn’t matter that much because this step only runs once during rebuild. But it’s not about this one case — it’s about the order of magnitude. What happens if you need to perform a similar operation hundreds or thousands of times? That’s where this starts to become very real.

And then comes the part where things get interesting.

The particles are passed to WebGPU — and this is where the browser really starts to flex.

The “classic” JavaScript + Canvas 2D implementation starts struggling on my machine at around 40k particles.

Frame rate drops, everything slows down, and you can feel the limits pretty quickly.

Meanwhile, WebGPU… doesn’t even flinch.

More than 500,000 particles. Each with its own physics. Smooth animation. Stable FPS.

At this point it stops being a small optimization and starts feeling like a completely different class of capability. The same browser, the same app, the same machine — but a totally different level of performance, simply by using the right tool for the job.

Where does this actually matter?

This is obviously not your typical frontend CRUD setup. You probably don’t need WebGPU to build a dashboard or a form, and in many cases the real bottleneck is the network, not computation.

But there are entire classes of problems where this approach makes a huge difference: real-time data visualization, physics simulations, graphics-heavy interfaces, audio processing, games, image or video transformations, and of course — matrix-heavy workloads like machine learning and LLMs running directly in the browser.

And the funny thing is, you don’t need this… until suddenly you really do. A product evolves, requirements grow, performance becomes an issue, or you want to move part of the workload from the backend to the client. That’s when things start getting interesting.

One more thing

If you take a look at the repository, you might notice something important.

This is just a regular React app.

There’s no exotic architecture, no “from another planet” stack. Yes, there’s Rust compiled to WASM and there are WebGPU shaders — but they’re simply embedded into a standard frontend setup. The rest of the app looks exactly like something you could start in your project tomorrow.

That was intentional. I wanted to show that this isn’t some distant, experimental playground reserved for niche use cases. It’s something you can already integrate into real-world applications — incrementally, when you actually need it.

Of course, WebGPU is not yet universally supported, so you’ll need a fallback strategy. But at this point, for a large portion of users, there’s little reason not to start exploring it.

Final thought

The browser is no longer just a place where we render UI.

It’s a serious compute platform — one that already gives us access to both CPU and GPU, right out of the box.

You don’t need WebAssembly or WebGPU in every project. Most of the time, you’ll be perfectly fine without them.

But the moment you start hitting performance limits, or your problem shifts from “moving data around” to “actually computing things”… you might realize that the platform already had the solution all along.

And all you had to do was use it. 🚀

You’re a Real Software Developer Only If…

Sylwia Laskowska — Thu, 09 Apr 2026 21:07:21 +0000

Uff, I’m finally done with my talk at jsDay 2026!

And honestly? It went at least good. People showed up, they asked questions… what more could you want? 😄

During the talk, I felt like I was among my people — that beautiful species of nerds who laugh at programming jokes without needing them explained ❤️

I’ll write a proper recap next week, but for now, a quick story from yesterday.

I was sitting at the airport in Munich.
For five hours.

Not exactly the plan.

I was supposed to have a one-hour layover and be enjoying the Italian sun by 5 PM. Instead, my first flight got delayed, I missed the connection, and… well.

Luckily, there was another flight later that day. Six hours later…

But as we say in Poland: every cloud has a silver lining.

I used that time to add fallbacks for absolutely EVERYTHING in my presentation. (Yes, I even installed service workers last minute — and it saved me later like crazy 🔥)

I also definitely hit my daily cardio goal trying to navigate that absurdly large airport.

And when boredom finally kicked in, I started writing this post.

This is also a small tribute to @hadil and her brilliant post:
You're the real JavaScript Developer Only If.... I’ve wanted to write something like this for months. And since I haven’t written anything in this style in a while… I’ve earned it 😄

You’re a real developer only if:

💥 You’ve broken production at least once

There’s even a Polish saying:

“Kto produkcji nie wy*ebie, ten nie zazna szczęścia w niebie”

Loosely translated into English:

“If prod you’ve never slain, dev heaven you won’t gain.” 😄

🐛 You’ve fixed a bug… completely by accident

Something sat in TODO for months (or years), and suddenly… it just works.

Or you changed something totally unrelated and magically fixed another issue.

No idea why. No idea how.
You just slowly back away and hope it stays that way.

🤯 At least once during debugging you thought:

“This makes absolutely no sense.”

And instead of stepping back and thinking…
you added more logs.

And then more logs.

And then one final console.log("WHAT IS GOING ON").

🧨 You were afraid to touch code that looks terrible… but works

Because deep down you know:

“This is held together by vibes and legacy decisions.”

And if you touch it, something completely unrelated will break.

💻 You wrote code that worked perfectly locally…

…and exploded in production

different environment
missing env variable
timezone issues
race conditions
or just… vibes again

🗑️ You accidentally dropped a database

Maybe not the whole thing. Maybe just a table. Maybe just half the data.

But still. Character development.

🖥️ You’ve said:

“It works on my machine.”

And you meant it. With full confidence.

🔄 You blamed the backend (if you’re frontend)…

or the frontend (if you’re backend)

Preferably both, within the same debugging session.

🧠 During one debugging session you thought:

first: “I’m an idiot.”
then: “Wait… I’m a genius.”

Sometimes multiple times in a loop.

Final verdict

If you answered “yes” to most of these:
👉 congratulations, you’re definitely a software developer.

If about half:
👉 you just need more experience.

If less than two:
👉 what are you even doing here? Go write more code 😄

Your turn 👇

What would YOU add to this list?

Because I’m 100% sure we’ve all got at least one story that would fit perfectly here 😄

9 Things You’re Overengineering (The Browser Already Solved Them)

Sylwia Laskowska — Thu, 02 Apr 2026 07:53:11 +0000

I love writing philosophical essays — thoughts about code, work, all that stuff. I also love deep technical dives. But I know you love my lists of cool features that not everyone has heard about yet 😄

What’s up with me? This week I’m preparing for a conference, fighting performance issues, and trying to get at least somewhat ready for the upcoming holidays 😉

Something nice happened too. I enjoy writing — not just technical articles, but in general. Last summer my life changed quite a bit, and to keep my sanity I started writing a sci-fi story, which I submitted to a Polish science fiction foundation competition. I didn’t win, but my story made it pretty far — around 13th place out of 179 submissions. Considering it was my first attempt at this kind of writing… it could have gone worse 😄

And speaking of sci-fi — the kind happening right in front of us 😉 Today I’ve prepared a batch of things the browser can already do, which honestly didn’t fit in my head not that long ago. A lot of these are still not that widely known, and yet many of them are already supported across modern browsers. Have fun!

1. “Let me just run this later” → `requestIdleCallback`

At first I thought this API was pointless. It basically lets you run some code when nothing interesting is happening. Ok… cool… but why would I care?

Turns out — there are tons of use cases. For example, collecting data about how the user behaves on your page — definitely not something you want to do while your 200 components are rendering 😅 Or loading less important data, preprocessing something, generating images in the background.

Honestly, there are probably as many use cases as there are developers.

function trackUserScrolling() {
  console.log("User scrolled. This changes everything.");
}

if ("requestIdleCallback" in window) {
  requestIdleCallback(trackUserScrolling);
} else {
  setTimeout(trackUserScrolling, 0);
}

Support: modern browsers (historically missing in Safari, so fallback is still a good idea)

2. “Why is my input not highlighting???” → `:focus-within`

It’s easy to style an element that has focus. But what if you want to style the parent div? For example, make it pink, add some flowers 😉 You can write 40 lines of JavaScript… or just use :focus-within.

Works. No listeners. No bugs. No suffering.

.form-field {
  border: 1px solid #ccc;
  padding: 12px;
}

.form-field:focus-within {
  border-color: hotpink;
}

<div class="form-field">
  <input placeholder="Type something meaningful..." />
</div>

Support: basically everywhere that matters

3. “Let’s show offline mode” → `navigator.onLine`

Have you ever built a PWA? Because I have, and the eternal problem is what to do when the user loses connection (e.g. they’re in the wilderness or just walked into an elevator 😄). You can write a bunch of complicated ifs, or just listen to offline and online. On offline you can store data in IndexedDB, and when the user is back online, send it to the server.

window.addEventListener("offline", () => {
  alert("You are offline. Time to panic.");
});

window.addEventListener("online", () => {
  alert("You're back. Panic cancelled.");
});

Support: widely supported (but “online” ≠ “your backend works” 😅)

4. “Smooth animation, but make it cursed” → `requestAnimationFrame`

We’ve all seen this:

setInterval(() => {
  element.style.left = Math.random() * 100 + "px";
}, 16);

You can feel this is not the best idea 😉 It just lags. Luckily we have requestAnimationFrame, which is synced with the browser repaint cycle, so things are actually smooth.

function animate() {
  element.style.transform = `translateX(${Date.now() % 300}px)`;
  requestAnimationFrame(animate);
}

requestAnimationFrame(animate);

Support: everywhere

5. “This card should adapt… but only here” → container queries

This feature feels almost unfair. I’m at a point in my career where I barely write CSS anymore (well, except for occasional moments like the one I described here: Is learning CSS a waste of time in 2026?).

But there was a time when I wrote a lot of it. And wow — how much I would have given to apply media queries to a specific element instead of the whole viewport. Now we finally can. The component becomes self-aware, and we can go grab a coffee.

.card-wrapper {
  container-type: inline-size;
}

.card {
  display: grid;
}

@container (min-width: 400px) {
  .card {
    grid-template-columns: 1fr 2fr;
  }
}

Support: modern browsers (add fallback if needed)

6. “Random ID, what could go wrong?” → `crypto.getRandomValues`

const id = Math.random().toString(36).slice(2);

This is how bugs are born. It looks like “good enough” crypto from AliExpress and works… until it doesn’t. First of all, it depends on the engine implementation — we don’t really know what’s happening under the hood. Some patterns are absolutely possible, and with enough IDs you’re basically asking for duplicates.

Luckily, we now have a simple native solution. It’s not a silver bullet, but crypto.getRandomValues is pretty solid — much better entropy, no weird patterns, dramatically reduces the chance of collisions. The browser just does it properly.

const bytes = new Uint8Array(8);
crypto.getRandomValues(bytes);

const id = Array.from(bytes)
  .map(b => b.toString(16).padStart(2, "0"))
  .join("");

console.log("Secure-ish ID:", id);

Support: widely supported

7. “We need a modal” → `<dialog>`

It’s honestly nice that browsers finally stepped up and said: fine, here’s your modal 😄 No more installing 12KB libraries just to open a dialog that users love so much. This one is also accessible by default, so win-win.

<dialog id="modal">
  <p>Are you sure you want to deploy on Friday?</p>
  <button onclick="modal.close()">Cancel</button>
  <button onclick="alert('Good luck 😬')">Deploy</button>
</dialog>

<button onclick="modal.showModal()">Open modal</button>

Support: modern browsers

8. “Voice input would be cool…” → Speech API

Are you already installing transformers.js because you need speech recognition? Relax — turns out the browser has something for that too. Well… at least Chromium does 😄 So if you can “encourage” users to use Chrome, Edge, or something similar, you’re good. Personally, I’d still be careful with production use, but for demos? Why not.

const SpeechRecognition =
  window.SpeechRecognition || window.webkitSpeechRecognition;

if (SpeechRecognition) {
  const recognition = new SpeechRecognition();

  recognition.onresult = e => {
    console.log("You said:", e.results[0][0].transcript);
  };

  recognition.start();
}

Support: mostly Chromium

9. “Will this CSS explode?” → `@supports`

Here’s a modern solution to the classic “it works on my machine” — at least in CSS 😉 You don’t have to guess whether something will break your layout. Just wrap it in @supports. There is a small catch — while support is very good, it’s not literally everywhere, so ironically… we could use @supports for @supports.

.card {
  background: white;
}

@supports (backdrop-filter: blur(10px)) {
  .card {
    backdrop-filter: blur(10px);
    background: rgba(255, 255, 255, 0.6);
  }
}

Support: very good

⚠️ But don’t get me wrong

Libraries are great. Sometimes you absolutely need them. But sometimes… you’re installing a dependency for something the browser solved years ago. Before installing anything, just ask yourself (or Google): “Is the browser already smarter than me here?” Sometimes the answer is yes. And that’s… perfectly fine 😄