DEV Community: Sylwia Laskowska

10 Git Commands You’ll Wish You Knew Earlier

Sylwia Laskowska — Wed, 26 Aug 2026 07:59:06 +0000

Do you know Git? Of course you do! Today, I’ve got a few of my favorite Git commands for you. When I was a junior developer, my tech lead taught me most of them (hi Wojtek, if you’re reading this 👋) and later, I started teaching the same commands to my own junior and mid-level developers.

I’ve actually been meaning to write this article for months. But you know how it is. It’s evergreen content, it requires a bit of work, and meanwhile I kept coming up with other ideas, so I kept postponing it. What finally motivated me was @francistrdev, who recently published his own article about Git commands.

My article will be a little different, though. If you’re completely new to Git and still learning the basics, check out Francis’s Git Gud! article first. But if add, commit, pull, and push are already second nature to you, this article is for you.

These are, let’s say, intermediate-level commands. Useful ones. The kind you actually need at work, but not yet senior-level Git magic like:

Type three lines into your terminal and a spaceship will appear in your repository.

If you have other useful commands at this level, please share them in the comments!

BTW, if you feel like it, you can also follow me on Instagram! I’m planning to post what could grandly be called “dev lifestyle” content there. 😅 I have four conferences coming up this fall, for example, so expect some behind-the-scenes photos from my little tour around Europe. I only have a handful of followers there so far and absolutely no idea what this experiment will turn into, but here you go: @sylwia.lask

All right, let’s start.

1. & 2. `git merge` vs `git rebase`

Haha, first point and we already have two commands. The reason I’m putting them together is that a lot of developers, even experienced ones, treat merge and rebase almost interchangeably.

And sure, their high-level purpose is similar: you want to integrate the history of one branch into another. Very often that means updating your feature branch with changes from main, develop, or another feature branch.

But the way they do it is quite different. Imagine you have this:

A---B---C main
     \
      D---E feature

You’ve been happily working on your feature branch, while someone else added commit C to main. Now you want to bring those changes into your branch.

Merge

If you run:

git merge main

while you’re on feature, Git combines both histories. You usually end up with something like this:

A---B---C------M
     \        /
      D---E---

M is a merge commit.

The original history stays intact. Git remembers that your feature branch diverged from main, both branches evolved independently for a while, and then they were joined together.

This can be a good thing because it preserves the real history of what happened. The downside is that if you merge main into your feature branch over and over again, your history can eventually start looking like spaghetti.

Rebase

Now let’s say instead you run:

git rebase main

Git takes commits D and E, temporarily removes them, moves your branch onto the latest main, and then reapplies your commits on top.

You get:

A---B---C---D'---E'

Much cleaner.

But notice the apostrophes. D' and E' are not technically the same commits as D and E. Git created new commits with new hashes. That means rebase rewrites history.

This is why a very useful rule of thumb is:

Rebase your own work. Be careful rebasing shared history.

If you’re working alone on a feature branch, rebasing it is usually perfectly fine. If three other developers have already based their work on your commits, rebasing those commits can make everyone’s life considerably more exciting. And not in a good way.

And what about conflicts?

Both merge and rebase can result in conflicts.

With a merge, Git tries to combine the two histories in one operation. You resolve the conflicting files, stage them:

git add .

and then continue:

git merge --continue

With rebase, things can be slightly more annoying because Git reapplies your commits one by one.

This means you may resolve a conflict, continue the rebase...

git add .
git rebase --continue

...and then get another conflict in the next commit. And another one. And another one. At which point you start questioning every career decision that led you here. 😅

But there’s also a small bonus. If you completely mess things up and just want to stop the entire circus, you can do:

git merge --abort

or:

git rebase --abort

Git will try to return you to the state from before the merge or rebase started. Extremely useful feature. 😁

3. `git commit --amend`

This is one of those commands I learned to love very quickly as a junior. Imagine you’ve just created a beautiful, perfectly round little commit. Then you look at the code and notice you forgot something.In my case, it was usually:

console.log("WTF");

You now have two options. Option one: make another glorious commit:

Remove console log

Which, let’s be honest, is not exactly the pinnacle of Git history aesthetics.

Or you can simply add the forgotten change to the previous commit. For example:

git add forgotten-file.ts
git commit --amend --no-edit

--no-edit means:

Add these changes to the previous commit, but keep the existing commit message.

If you want to change the commit message as well, just run:

git commit --amend

Git will open your configured editor and let you modify it.

There is one important detail here. amend doesn’t literally edit the existing commit. It creates a new commit containing the updated contents. And because commit hashes depend on the contents and metadata of the commit, the hash changes.

If you’re working locally and haven’t pushed the branch anywhere yet, no problem. But if the branch already exists on remote, your local history no longer matches the remote history. So when you try:

git push

you’ll probably get something like:

rejected (non-fast-forward)

Now, if you are absolutely sure nobody else is working on that branch, you could technically do:

git push --force

But what if you’re not sure?

And this brings us very smoothly to the next point.

4. `git push --force-with-lease`

After a rebase, amend, interactive rebase, squash, or anything else that rewrites your commits, your local branch history may no longer match the version stored on remote.

You can solve that with:

git push --force

But --force is basically saying:

My local version is the truth. Replace whatever is on remote with this.

If someone pushed something to that branch in the meantime, you can overwrite their work. They may get angry. And rightly so. 😏

A much safer option is:

git push --force-with-lease

In simplified terms, this tells Git:

Force-push my version, but only if the remote branch still looks the way I expect it to.

If the remote branch changed since the state your local Git knows about, for example because someone else pushed new commits, Git refuses the push instead of blindly overwriting them.

So instead of destroying someone’s afternoon, you get an error. I generally recommend:

--force-with-lease

over:

--force

whenever possible.

5. `git rebase -i`

For me, this is a very important command. Almost the king of Git. xDDDD Interactive rebase lets you do almost anything you want with your recent commits.

In other words, you can commit every single line individually, change everything ten times, create commits like:

Add validation
Fix validation
Actually fix validation
Fix validation again
Remove console.log
Please work now

and then later turn the whole mess into an elegant Git history.

Let’s say you want to edit your last five commits. You run:

git rebase -i HEAD~5

Git opens your configured editor — Vim, Nano, VS Code, or whatever you use — and shows something similar to:

pick a111111 Add login form
pick b222222 Add validation
pick c333333 Fix typo
pick d444444 Fix validation
pick e555555 Remove debug log

Now comes the fun part. You can replace pick with different commands.

`pick`

Keep the commit exactly as it is.

pick a111111 Add login form

`reword`

Keep the commit contents, but change its message.

reword a111111 Add beautiful login form

`edit`

Pause the rebase at that commit and let you modify it. Useful if you want to change the actual contents of an older commit.

`squash`

Combine the commit with the one before it.

For example:

pick   a111111 Add login form
squash b222222 Add validation
squash c333333 Fix validation

Git turns those commits into one and lets you edit the final commit message.

So instead of:

Add login form
Add validation
Fix validation

you can end up with:

Add login form with validation

Beautiful. Round. Perfect.

`fixup`

fixup is similar to squash, but it throws away the commit message of the fixup commit.

For example:

pick  a111111 Add login form
fixup b222222 Fix typo
fixup c333333 Remove console.log

You probably don’t care about preserving the historical significance of:

Remove console.log

So fixup is perfect here.

`drop`

Remove the commit completely.

drop c333333 Terrible idea

Goodbye.

Of course, there are different schools of thought about how much you should clean up your commits. Some senior developers say that submitting a nicely cleaned-up commit history for review is simply good manners. Others do not care in the slightest and think it’s unnecessary because GitHub, GitLab, or whatever platform you use can simply squash everything when merging the PR anyway.

But!!! What if you don’t want to click Squash and merge? What if your feature logically contains two commits and you actually want to preserve both? That happens.

So whether you use interactive rebase once a week or once every six months, I still think it’s worth knowing the king:

git rebase -i

6. `git stash`

This one comes in handy very often. You start working on a nice little feature. Or, these days, Kiro or Claude Code is working very hard while you watch. Suddenly someone reports a production bug.

Unfortunately, you now have to temporarily abandon your beautiful feature and switch to something else. The problem is that your current work is completely unfinished. You have debug logs everywhere, half the files are modified, the project doesn’t even build, and you definitely don’t want to commit this mess.

Although, of course, now you know about amend, so you could eventually clean it up.

But there’s a better solution:

git stash

Git temporarily stores your uncommitted changes and returns your working directory to a clean state.

Now you can switch branches:

git switch main

fix your production disaster, and later come back.

One important detail: by default, git stash stashes tracked files, but not new untracked files. If you also want to include newly created files, use:

git stash -u

or, even better, give your stash a useful name:

git stash push -u -m "WIP login feature"

Because once you have several stashes named basically “WIP”, future you will hate present you.

`git stash list`

To see all your stashes:

git stash list

You might get:

stash@{0}: On feature/login: WIP login feature
stash@{1}: On feature/cart: experiment

`git stash show`

To see what a particular stash contains:

git stash show stash@{0}

And if you want the full diff:

git stash show -p stash@{0}

`git stash apply`

To restore a stash:

git stash apply stash@{0}

The changes are restored, but the stash remains in the list.

`git stash pop`

You can also use:

git stash pop

This applies the stash and, if successful, removes it from the stash list.

So, roughly:

apply = restore
pop   = restore + remove from stash

Very simple, very useful.

7. `git cherry-pick`

I have to admit this is one of the intermediate Git commands I use most often. Imagine there’s one specific commit on another branch that you want in your current branch.

You don’t want to merge the whole branch. You don’t want to rebase onto it. You literally need one thing. For example, in my project recently, I needed a commit containing configuration for newly created environments. Perfect use case.

You simply run:

git cherry-pick <commit-hash>

For example:

git cherry-pick a1b2c3d

Git takes the changes introduced by that commit and applies them to your current branch.

Important detail: it creates a new commit. So the resulting commit contains essentially the same changes, but it gets a new hash. Imagine this history:

main
A---B---C

feature
     \
      D---E---F

You’re on main, but you only want E.

After:

git cherry-pick E

you get something like:

A---B---C---E'

Simple.

But I’ll admit that, being a lazy creature, I use cherry-pick in slightly less noble ways too. Sometimes something gets completely messed up on my branch. The rebase goes badly, the history looks suspicious, conflicts start multiplying, and after a while I decide: I'll create a completely new branch from the correct place at the top of the tree. 😅

And because — thanks to the previous commands ☺️ — my commits are already nice and round, I simply cherry-pick them one by one onto the new branch.

I’m sure some Git pro is currently shaking their head at me, but let me put it this way: It works for me. 😀

8. `git reset --soft`, `--mixed`, `--hard`

Three ways of moving back in history, each with a different answer to the question:

What should happen to my changes?

Because how many times do we start working on something, write some code, and then realize: Nope. This whole idea was bad. Let’s go back.

The easiest way to understand reset is to think about three layers:

Commit history
Staging area
Working directory

Now we have three increasingly dramatic levels of reset. And every next one has greater potential to cause a small heart attack if you use the wrong one.

`git reset --soft`

Let’s say you want to undo the last commit:

git reset --soft HEAD~1

Git moves HEAD back by one commit, but all the changes from the removed commit remain staged.

So if your history was:

A---B

after the reset, your branch points to:

but the changes introduced by B are still ready to commit.

This is useful when you committed too early and want to recreate the commit differently.

`git reset --mixed`

Now:

git reset --mixed HEAD~1

or simply:

git reset HEAD~1

because --mixed is the default.

Again, Git moves back one commit.

But this time the changes are left in your working directory unstaged.

So nothing disappears from your files, but you need to git add things again before committing.

`git reset --hard`

And now we enter the danger zone:

git reset --hard HEAD~1

This moves HEAD back and updates both the staging area and working directory to match that commit. In other words, the changes disappear from your files too.

So:

--soft  → keep changes staged
--mixed → keep changes unstaged
--hard  → discard changes from the working tree

Use the last one with some awareness of what you’re doing. But what if you go one step too far and accidentally delete something you absolutely did not mean to delete?

And that brings us to...

9. `git reflog`

A command I use very rarely. But oh, how many times it has saved my ass.

For example, when I once ran git reset --hard and instead of removing my last changes, I basically removed the branch I had been working on for two days. 😀Amazing experience. Highly recommended.

The important thing to understand is that git log shows you commits reachable from the history you’re currently looking at. If you reset your branch backwards, some commits may disappear from git log.

That does not necessarily mean Git has immediately deleted them. Git also keeps a local log of movements of references such as HEAD. You can inspect that with:

git reflog

You may see something like:

e35fa12 HEAD@{0}: reset: moving to HEAD~2
821cd77 HEAD@{1}: commit: Add authentication
f992ab1 HEAD@{2}: commit: Add login page

Aha! There’s your missing commit.

Now you have several options. You could move the branch back to it:

git reset --hard 821cd77

But personally, if I’m already in panic-recovery mode, I prefer doing something safer first:

git branch rescue 821cd77

Now the commit is reachable from a branch again and I can calmly inspect what happened without immediately rewriting anything else.

The key difference is:

git log

shows your visible commit history.

git reflog

shows where your local references, especially HEAD , have pointed recently.

There is one important limitation, though. Reflog is not a magical backup of every character you’ve ever typed. If your changes were never committed, stashed, or otherwise stored as Git objects, reflog cannot magically resurrect them.

So yes, if you worked for six hours without committing anything and then destroyed those changes... Well. Maybe this will teach you to commit more often next time.

10. `git revert`

And finally:

git revert

Imagine you release a commit to production. Or, in the slightly less hardcore version of this scenario, to some shared develop branch.

Something goes very wrong. Everything breaks. So what now? Do you run:

git reset --hard

on the production branch?

Do you start performing an exorcism?

Fortunately, no. The elegant way to undo a commit while preserving a clear record of what happened in your repository history is:

git revert <commit-hash>

Imagine your history looks like this:

A---B---C

and C introduced the disaster.

You run:

git revert C

Git does not remove C.

Instead, it creates a new commit that applies the opposite changes:

A---B---C---D

You may end up with something like:

C: Add new payment logic
D: Revert "Add new payment logic"

This is extremely useful on shared branches because you are not rewriting public history. Everyone can clearly see:

the original change happened,
it caused trouble,
it was reverted.

Compare that with resetting the branch and force-pushing it backwards, which rewrites history and can cause problems for everyone else working on it.

So, as a general rule:

Shared branch + bad commit → revert

is usually much safer than:

reset + force push

And that’s it!

As I said at the beginning, if you use other intermediate Git commands that regularly save you time or save your ass, please share them in the comments. Usually the comments under my articles end up being much better than the article itself, which continues to make me very happy.

Also, please note that last week’s article was a list. This week’s article is a list. And — spoiler alert — next week’s article will also be a list!

This is not because I smelled clicks and decided to turn into BuzzFeed. It just somehow happened that way. 😅

I hope you learned something new. And if you didn’t, I hope it was at least fun to read. 😁

7 Productivity Tips That Sound Wrong (But Actually Work)

Sylwia Laskowska — Tue, 18 Aug 2026 08:32:32 +0000

Struggling with burnout? Procrastination? Reaching your goals? Let me share a few methods that help me actually get things done in the long run. And yes, at first glance, some of them might make you think I've completely lost it 😄 But I swear they work, and these really are “productivity tips,” not “Sylwia's zen tips.”

I've been writing quite a lot of “philosophical” posts lately. Well, it's summer, I'm enjoying the last warm weeks, and somehow I'm just in the mood for this kind of content. Don't worry, though, September will be packed with hardcore tech!

And trust me, a lot is going to happen, because in September I'll be speaking at AGNTCon + MCPCon Europe!!! Well, I always knew my place was among the greatest engineers from OpenAI, Anthropic, Google, and the maintainers of MCP… Hahaha, obviously I'm joking. I have no idea what I'm doing there, but if you happen to come to my talk, I promise you won't regret it 😄

This post is partly a continuation of Stop Calling Everything “Impostor Syndrome”: The Myth of “Just Push Harder” and contains some thoughts that simply didn't fit there. And yes, we only have one life — at least as far as we know 😄 — and I don't think it's worth wasting it constantly working your ass off just to become an amazing programmer or someone else in IT.

But that's not even the main point here. These tips, despite going against the “work more” advice we hear all the time, can actually help you achieve much more, because the key to success is something we all know very well: CONSISTENCY.

Of course, I'm not going to claim this will always work for everyone. So you're very welcome to disagree with me in the comments 😄 It works for me, though, so I'll describe these methods along with plenty of personal digressions. Maybe it's worth a try?

1. Do Less Than You Could

This is actually an old Scrum principle — or at least that's how a Scrum Master friend of mine once explained it to me 😉 The point isn't to cram as many tasks as possible into a sprint. The point is to find a pace of work that would feel comfortable even if there were no vacations at all. Obviously, this doesn't mean you should actually give up your vacations xDDD But you get the idea.

I understand this strategy perfectly well at work, but sometimes I forget about it in my personal life. If you read me regularly, you know I blog a lot here (and sometimes those are heavily technical posts, unlike this one 😅), and I also speak at conferences. So I often have tons of things to do, but the moment my calendar gets even slightly less crowded, I immediately start wondering what else I could squeeze in. Maybe I should finally write a book?

It's a trap. Instead of using that quieter period to rest and finally watch a TV show other than Silicon Valley, I fill that time with more stuff. Then the commitments I already knew were coming eventually arrive, and suddenly I'm frustrated and exhausted. As a result, I do less, I do it worse, and… I give up on writing the book anyway 🥺 Maybe I'll get back to it when I retire or something. 🤯

2. Don't Work on Weekends

My buddy @the_nortern_dev once wrote about this in Unpopular Opinion: I Stopped Coding on Weekends and My Career Got Better. I even commented that I not only don't code on weekends, but I don't do anything after hours at all unless I genuinely feel like it.

Well, those days are long gone. When it comes to blogging and conferences, I've achieved a certain level of success. What I didn't expect was that… success comes with admin work 😅. Suddenly there are ten emails to answer, an abstract to prepare, benchmarks to run, something else to check… Sometimes these are tiny things, but we all know how quickly tiny things can grow 😄

As a result, I developed a tendency to do something every single afternoon and, of course, on weekends, because that's when I had more time. My productivity dropped dramatically. I genuinely didn't feel like doing anything anymore, and everything I did was basically just “good enough to get it over with.”

Free weekends don't just help me rest. I even let myself get a little bored. Usually, at some point, I get that feeling of, “Ahhh, I'm rested now, I'd actually love to work on this!”, and I deliberately don't do it. At most, I write the idea down. It's only when your brain finally relaxes that it has room for creativity.

It's not like I close my laptop on Friday evening and don't open it again until Monday morning. Sometimes I reply to your comments, which I really enjoy. But no answering emails, creating content, and so on. Which brings us smoothly to the next point:

3. Plan Your Week in Advance

Okay, this particular tip isn't exactly controversial 😄 But it really works. If I want my weekend to stay free, I need to plan everything else throughout the week. But I also have to do it in a way that doesn't completely bury me in work, because the whole point is to do less than you could.

You don't need sophisticated tools to do that. Usually, I dump everything I want to do into ChatGPT as a stream of consciousness, and it turns it into a daily plan, taking into account what's urgent, what's important, and so on. For example, today I had some admin stuff plus this article, and tomorrow evening I'll focus 100% on editing my sci-fi story for an anthology (fortunately, I'm finally on the home stretch…).

4. Set Embarrassingly Achievable Goals

This is the key to avoiding procrastination. If you set yourself a goal like “I want to become a Staff Engineer at Google”, your brain will decide that you might as well sit down and do nothing. Unless you're already a Senior Engineer at Google, in which case it's a perfectly reasonable goal 😁

You get the idea, right? It's one of those things coaches are always telling us 🤣 And on this one, they're actually pretty right. A goal should be realistic and measurable, and ideally, it should depend on you — although, of course, that's not always possible.

If you're learning programming and want to do it professionally, a good goal is “become a junior developer,” or even “get an internship.” That's something you have a chance of achieving by learning this and that and sending your CV to companies. If you're interested in speaking at conferences, you don't tell yourself, “Now I'm going to become a tech influencer” xD. Instead, you try to come up with a cool topic and get accepted to a meetup. And so on, and so on.

5. Deliver Only What You're Asked For

Haha, how many times have I fallen into this trap! In software development, we have this thing called an MVP, and I think we should make MVPs in life too.

More than once, I've found myself spending time polishing details that simply weren't necessary. Am I saying that going the extra mile has never helped me? I'd be lying if I did. Sometimes the extra effort genuinely paid off, although I'll never know whether “good enough” would have worked just as well.

More often, though, it went the other way. In the best-case scenario, I simply did a bunch of unnecessary work. In the worst case, I built something the client didn't even want because I thought it was better and so cool! Of course, it was easy enough to undo and nobody got hurt (except me), but the fact remains: my “extra” work wasn't just useless. Sometimes it actively made things worse.

Obviously, in your own projects, do whatever you want. But when you're working with clients, I'd recommend sticking to this rule. Want to add something extra? Agree on it with the client first (and preferably charge extra for it).

6. Know What “Done” Means Before You Start

This is an extension of the previous point. If, for example, you set yourself a goal like “I'll learn JavaScript”, you'll never finish. I always laugh that when I was a junior, I used to put my JavaScript level on my CV as “very good,” and now I only put “good” 😄

Instead, aim for something like “I'll complete this tutorial and take the test at the end” or “I'll build an app with these specific features”.

7. Reply to Small Things Immediately

This is a tip I learned from my former Development Manager. If you get an email or a message that will take you no more than five minutes to answer, do it immediately or within an hour. Unless, of course, you're in the middle of something super urgent or in a deep work. Don't let it sit there for days.

It's a fantastic way to keep clearing things from your life's “backlog.” As a bonus, it'll make you the perfect “low-maintenance” coworker, contractor, and so on. Where's the downside?

And that's it. Obviously, these tips won't work in every situation or for everyone. I can imagine moments in life when we genuinely need to push hard because we're doing a bootcamp, facing an important deadline, or whatever else. The problem is that those “moments” sometimes get out of control, and a few weeks turn into a dozen months. Which is, of course, a pretty straightforward path to burnout and wanting to throw the whole damn thing away.

So I wish you more free evenings, more free weekends, and, in general, a life where you don't work yourself to death ☺️

For more super-useful life hacks 🤣 you can also follow mi on LinkedIn.

The End of Undetectable AI Text? Claude’s New Watermark Explained

Sylwia Laskowska — Tue, 11 Aug 2026 22:33:57 +0000

For the past few hours, the whole world, or at least my LinkedIn feed, has been talking about one thing: Anthropic signed the EU AI Act’s Code of Practice on Transparency of AI-Generated Content.

Is this the end of generating funny cat stories, LinkedIn posts, and boring docs? Are we doomed? Will we have to write all those boring things manually, like animals, because otherwise some mysterious detector will expose us? 😅

I just couldn't resist writing about this! The internet has already managed to produce a surprising number of myths around the topic, so let's quickly go through what we actually know for sure, which, by the way, is pretty easy to find on Claude's official pages, where the documentation is more pleasant to read than many industry articles.

And as you'll see, there's really not that much to be afraid of. Also... Anthropic isn't even the first company to do this.

Wait, Why Do We Even Need This Law? Did AI-Generated Text Become Illegal in Europe?

Of course not!

If you're an EU citizen like me, you can still ask an AI to write a reply to a boring email or generate a ridiculous poem, and you won't go to jail for it. 😉

The goal isn't to ban AI. It's about making AI-generated and manipulated content machine-detectable and, in specific contexts, transparent to users — especially when we're talking about things like deepfakes or content concerning matters of public interest.

And there is an important nuance here: the AI Act also provides an exception for certain AI-generated or manipulated text where the content has undergone human review or editorial control and a natural or legal person holds editorial responsibility for its publication.

So no, the EU has not declared war on your ChatGPT-generated emails.

What Do We Actually Know So Far?

Here's what we know for sure today:

Anthropic really did sign the EU AI Act Article 50(2) Code of Practice on Transparency of AI-Generated Content, and as part of its implementation, it is providing machine-readable marking. The relevant transparency obligations started applying on August 2, 2026. So yes, we're already there.
Claude models released on or after August 2 have marking capabilities from launch. Older models don't necessarily have them yet; Anthropic is rolling this out gradually.
The system works globally. Yes, even outside the EU.
It applies to supported Claude models used through Claude, the Claude Platform/API, Claude Code, Claude Cowork, and Claude Tag.
Using Claude through AWS, Google Cloud, Microsoft Foundry, or another supported platform? The marking is applied at the model level, so using another interface doesn't magically make it disappear.
There are two different mechanisms involved: an imperceptible watermark for generated text and provenance metadata for supported files.

So... How Does This Watermark Actually Work?

Anthropic calls it an "imperceptible watermark" embedded directly into the text.

According to Anthropic, it survives copy-paste and can even survive some amount of editing. It's implemented at the model level rather than being something the Claude frontend simply adds afterward.

But here's the important part: Anthropic still hasn't told us exactly how it works!

The company says more technical documentation is coming, so... expect a follow-up from me when it arrives. 😀

We can make an educated guess that it might be some form of statistical token watermarking. In such systems, we're not talking about weird spaces or invisible Unicode characters that could be removed in a second. Instead, the model can slightly and statistically prefer certain tokens during generation.

In a single sentence, that kind of signal might be impossible or unreliable to detect. Across a longer piece of text, however, statistics can start revealing the pattern.

So, very roughly, you could imagine something like this (if Anthropic has implemented its watermark this way):

Normal generation

P(next_token | context)

vs.

Watermarked generation

P(next_token | context) + secret statistical bias

But again: Anthropic has NOT confirmed yet that this is how Claude's watermark works.

This is simply an educated guess based on existing text-watermarking techniques. 🙂

Is Claude the Only Model Watermarking Text?

Nope!

Google has actually been doing this for years.

Google DeepMind introduced SynthID Text back in 2024, and it works along the general lines I described above: the watermark is introduced during token generation, creating a statistical signal that can later be detected.

OpenAI, meanwhile, has said that it has developed text-watermarking technology, although while it already uses provenance or watermarking technologies for things like images, video, and audio, it has not publicly rolled out comparable watermarking for ordinary GPT text responses.

So Anthropic definitely didn't invent the idea of watermarking LLM output.

Will Everyone Have Access to a Watermark Detector?

We don't really know yet.

For supported files, the situation is somewhat simpler because Anthropic uses provenance metadata, such as C2PA credentials, that can be inspected with appropriate verification tools.

Text is more interesting.

Anthropic says it plans to make watermark detection available to third parties and researchers, but we don't yet know exactly who those third parties will be, what access will look like, or whether regular users will eventually get a simple public detector.

So GPTZero and similar garbage may still have a job for a while.

What Does This Actually Mean for Us?

Will everything finally become crystal clear? Will every LLM-generated article suddenly get a giant red CHEATER! warning next to it? xD Of course not!

Anthropic itself openly talks about the limitations of this technology. And we've discussed variations of this problem thousands of times here on DEV already.

First of all, the presence of a watermark does not necessarily mean that the author didn't write the text themselves.

Maybe they wrote the entire thing and then asked Claude to edit it, fix grammar mistakes, polish the wording, or translate it into another language. The resulting output could contain a watermark even though the actual ideas, and potentially most of the original text, came from the human author.

So yes, the final article could still be chaotic, unnecessarily long, and full of a million digressions, exactly like my posts here.

Anthropic explicitly points out that the opposite can happen too.

Someone can take fully AI-generated slop and heavily edit it, paraphrase it, translate it, mix it with other content, or otherwise transform it enough that the watermark may no longer be detectable.

So:

watermark detected ≠ AI wrote everything

and

no watermark detected ≠ human wrote everything

That's a pretty important distinction.

What About Images, Audio, and Video?

With supported files, provenance can be easier to verify because we can use embedded metadata and content credentials. But even that isn't bulletproof.

What happens if someone takes a screenshot of an AI-generated image, for example Metadata doesn't magically survive every possible transformation.

And that's exactly why provenance is useful evidence, but not some perfect universal AI detector.

And What the Hell Happens With Code?

This is probably the part I'm most curious about. How exactly are they planning to handle watermarking in generated code, where the model has significantly less freedom in choosing equivalent tokens?

In natural language, there can be dozens of perfectly valid ways to express essentially the same thought. But if we have something like:

const result = await fetchData();

then how the hell do we add a statistical watermark to that?

Sure, there are still choices: variable names, formatting, and so on. But the space of valid substitutions is obviously much more constrained than it is in natural language, and formatters, refactoring, minification, or even small manual edits could make the problem even more interesting.

Claude Code is included in Anthropic's marking rollout, but Anthropic hasn't yet published enough technical detail for us to know exactly how the text watermark behaves with generated source code.

And I really want to know how they solved this one.

So, Should You Care?

As you can see, Claude watermarking generated text is actually a logical and important, although obviously still imperfec, move.

It probably won't change our everyday lives very much.

Sure, the flood of AI slop across social media is annoying. Unfortunately, I have a feeling this watermark isn't going to magically solve that problem either. 😐

What interests me much more is how this watermark is actually implemented.

Anthropic, I'm waiting for the docs!

Stop Calling Everything Impostor Syndrome: The Myth of "Just Push Harder"

Sylwia Laskowska — Tue, 04 Aug 2026 07:30:25 +0000

Not everyone who doubts themselves is suffering from impostor syndrome. Sometimes the real problem lies in the strategy they've chosen, and that's exactly why it's so important to learn to tell the difference.

I read a lot of articles here on DEV about burnout, impostor syndrome, and similar topics. I thought I'd add my own perspective because I have the feeling that some advice, often given with great confidence, can actually do more harm than good. The symptoms may be real, but the diagnosis can still be wrong.

Today I'd like to share my somewhat "engineering" approach to personal growth. Maybe it will help some of you. Because "just keep going" or "work harder" isn't always the right answer.

Impostor Syndrome

I do experience impostor syndrome.

And don't get me wrong. I generally have pretty high self-esteem, and I believe I've achieved quite a lot in different areas of my life. That doesn't stop me from doubting myself from time to time.

Here's an example from just the past few days.

I published an article about building an AI agent in around 80 lines of code, and it sparked an amazing discussion. I was genuinely proud of it. Even better, I got invited to speak about it at the AI Coding Summit! (By the way, if you'd like to support me, you can like my LinkedIn post and claim a badge that gives you access to half of the conference for free!)

Overall, I genuinely believe the topic is a great fit for a conference like this. What I really wanted was to see my face appear on the conference website, because I always have this feeling that once the organizers publish the speaker page, everything is basically official and they're unlikely to remove me afterward. 😅

Well... it took them exactly one day.

And I swear that by the end of that day, my brain had already come up with an entirely different explanation:

"What if they read my blog and realized how stupid my articles are? What if they email me saying: 'Sylwia, we've gone through your posts, and unfortunately we've decided to remove you from the conference. It's obvious you have no idea what you're talking about. We've figured you out, you fraud!'"

Reading this now, it sounds completely ridiculous. But I believed it. Never mind that my articles regularly appear in developer newsletters or receive lots of positive feedback. My brain had already written its own story.

Here's another example.

Once, an organizer described the speakers at a conference as "amazing international speakers." Instead of feeling proud, my first thought was: "Amazing international speakers... and Sylwia." After all, I'm just a software developer from Gdańsk. 😅

This is exactly what psychologists describe as impostor syndrome: despite objective achievements and external validation, you still feel like you don't really deserve your place, and sooner or later everyone else will discover that you're a fraud.

I'm not even going to dive into the psychology behind it today. Maybe that's a topic for another article.

But Not Every Doubt Is Impostor Syndrome

Here's the important part. Not every doubt you have automatically means you're experiencing impostor syndrome.

There are also areas where I'm genuinely... bad. Take running.

I'm an absolutely terrible runner. My times are objectively awful. So awful that I'd rather not even share them. 😄 I'm fully aware of it. I'd probably lose a race against a five-year-old, not to mention the fact that I don't have an ACL in either knee thanks to my old judo days.

Now imagine someone giving me this advice: "Come on, you just have impostor syndrome! Keep running more, train harder, and one day you'll become Poland's marathon champion."

You can immediately tell how absurd that sounds. That advice wouldn't help me in the slightest.

And yet, very similar advice is often given to people who are learning programming or have been unsuccessfully looking for a job for months.

You've been working incredibly hard without seeing results and you're starting to feel burned out? "It's just impostor syndrome. Don't worry. Work harder. Keep going. Just a little longer."

You've been writing blog posts and nobody reads them? "It's just impostor syndrome. Don't worry. Keep publishing consistently. The results will eventually come."

Personally, I think this kind of advice can actually be harmful.

Think Like an Engineer

Let's go back to my running example. Why am I such a bad runner? Maybe I only started recently and my expectations are unrealistic. Maybe I'm making fundamental mistakes in training. Maybe I'm wearing the wrong shoes. Maybe I simply don't have much natural talent for running, and I'd enjoy a different sport much more.

Or maybe I should just run for fun instead of chasing unrealistic goals.

The same way of thinking applies almost everywhere else. Have you sent hundreds of CVs without getting interviews? Maybe it's worth asking an HR specialist to review your resume. Maybe the market is simply terrible right now. Maybe you're missing one specific skill that's relatively easy to learn.

Maybe you're applying only for fully remote positions. Or maybe you're aiming exclusively at FAANG companies, while you'd have much better chances at smaller organizations.

Are you writing blog posts that nobody reads? Maybe your titles could be stronger. Maybe you should spend more time interacting with the community, learning from other people while also increasing your own visibility. Maybe another platform would suit you better. For example, I get fantastic engagement and wonderful discussions here on DEV, while my LinkedIn posts usually perform much worse. 😄

Debug Your Strategy, Not Just Your Confidence

That's what I mean by an "engineering" approach to personal growth. Every few months, try looking at your efforts critically, without ego, as if your own development were someone else's project.

Ask yourself: Is the time I'm investing actually producing results? If not, maybe it's worth changing the strategy instead of simply trying harder.

Because maybe your doubts aren't impostor syndrome at all. Maybe they're your brain telling you that your current approach simply isn't working.

Sometimes the answer really is greater confidence and perseverance. But sometimes the answer is changing your strategy. The hard part is learning to tell the difference.

It Was Just a Patch Update. What Could Possibly Go Wrong?

Sylwia Laskowska — Thu, 30 Jul 2026 08:02:27 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

You know those version numbers in libraries and frameworks, right? If not, here's a quick refresher. When we have something like package@x.y.z:

x is a major release, where breaking changes are allowed,
y is a backward-compatible feature release,
z is a patch, usually containing small fixes and bugfixes.

If we want to keep our projects healthy, we should update at least patch versions regularly. In fact, nowadays our package managers often do it automatically if we let them.

One day, however, upgrading just the third number completely broke our application. And it wasn't the framework's fault. It was ours.

I fix plenty of bugs in my daily job. But finding the one worth telling in a contest meant digging surprisingly far back into my memory...

So let me take you back to 2017.

Welcome Back to 2017

Web applications have only been taking over the world for a few years. ECMAScript 6 has been around for two years already, but we're still using its revolutionary features (Promises, arrow functions, let and const) very carefully because browser support isn't exactly great yet.

The market is so hungry for developers that companies are basically hiring anyone who can write:

export class

Meetups are full of talks like "Introduction to Angular." Well, the new Angular itself isn't even a year old yet. At least creating a new project only takes a single CLI command. Meanwhile, creating a React project still feels like downloading half of npm.

I'm working as a fairly ambitious mid-level developer in a team that has been using Angular almost since its very beginning.

The project is a large enterprise application used to monitor Fair Trade certified products. It has to work all over the world, from Western Europe to small African countries where someone might connect to the Internet from a public library once every few weeks over a painfully slow connection.

Future-proofing matters.

We're basically learning modern frontend development while building this application. How do Observables work? What exactly is RxJS? When should we use services?

It doesn't help that Angular itself is still maturing and sometimes things simply don't work because... well... there's a bug in Angular. We file issue after issue.

To Angular's credit, the team reacts incredibly fast. Sometimes they fix a bug before we even finish filling out the issue template.

Naturally, we keep upgrading regularly, including minor and patch releases.

The Problem With Angular's Early i18n

As I mentioned, our application has to support many languages. Angular already has the beginnings of an i18n system, but it's nothing like what we have today. Without diving too deeply into the implementation, translatable elements are simply marked with an i18n attribute:

<h1 i18n>Hello</h1>

The Angular CLI scans the application and generates translation files from those elements.

The problem is that each language requires its own build. Switching languages at runtime isn't really an option. And unfortunately, runtime language switching is a hard requirement for our application (I honestly don't remember why anymore 😄).

Since the Angular ecosystem is still incredibly young and there aren't any mature libraries solving this problem, we decide to build our own solution.

Our implementation is surprisingly simple. Whenever the language changes, we scan the page for every element containing the i18n attribute and replace its contents with the proper translation.

Elegant. Simple. Maybe fifteen lines of code.

The Patch Update

Everything works perfectly... until the middle of 2017.

Angular is now on version 4. (I remember they skipped version 3 for perfectly reasonable reasons, although I couldn't tell you what those reasons were anymore. 😄)

One day we perform a completely routine Angular upgrade. I don't remember the exact version numbers anymore, but it was something along the lines of upgrading from 4.2.4 to 4.2.8.

A tiny patch update. Nothing should happen. Except... it did. Our translations, our entire internationalization system. All gone!

The application starts normally and everything looks fine. But as soon as we try to switch languages... nothing happens. We're stuck with English.

Time for Some Digital Detective Work

Now we're entering my favorite part of programming: software forensics.

At first, I completely dismiss the idea that such a tiny Angular update could possibly be responsible. We upgrade patches all the time. Surely something else must have happened.

Back then, things like CI pipelines and automated testing are still in their infancy. Maybe our tester simply hasn't switched languages for a week or two?

I go through Git history. Nothing looks suspicious. None of the recent commits touch internationalization.

Maybe the backend is broken? Did the translation files disappear?

Nope. Everything is exactly where it should be.

Finally, almost unwillingly, I look at the Angular upgrade again.

I start going backwards. Patch after patch. And sure enough... between two tiny patch versions, translations suddenly stop working.

So Angular must be guilty. Or... is it?

Solving the Mystery

Digging through Angular's changelog, I found a change that basically said:

Why keep the unnecessary i18n attribute in the generated HTML? The compiler has already done everything it needed with it. Let's remove it.

Suddenly everything made sense. Our entire runtime translation system depended on an implementation detail that Angular had never promised to preserve.

For Angular, removing that attribute was a perfectly reasonable cleanup. For us... it broke the entire application.

Official references (if you're curious). As you see, we weren't the only people affected 🤣:

Angular changelog (Angular 4.2.6): "compiler: remove i18n markup even if no translations"
PR #17999: https://github.com/angular/angular/pull/17999
Original issue #11042: https://github.com/angular/angular/issues/11042
Follow-up discussion #20055: https://github.com/angular/angular/issues/20055 (I even see my collegue's comments there 🥰)

The Fix

Fortunately, fixing the problem wasn't particularly difficult. It was just... annoying. Instead of relying on Angular's internal i18n attribute, we created our own directive.

Its name?

fi18n.

I know. Peak engineering creativity. 😂

Were We Terrible Engineers?

Does this story mean we were inexperienced developers who had no idea what we were doing?

Quite the opposite! We had successfully implemented runtime language switching years before "it was cool" 😉

The only mistake we made was assuming that something we happened to observe was actually part of Angular's public contract. It wasn't. We built our solution on an implementation detail that Angular had every right to change.

And eventually... it did.

Luckily for us, the application wasn't anywhere near production yet 😅. So in our youthful optimism, we got away with it.

Why This Bug?

After more than a decade of professional programming, why would I choose this bug instead of one of the many much bigger production incidents I've dealt with? Because the lesson has become even more relevant.

In 2026, frontend development looks completely different. Nobody gives talks called "Introduction to Angular" anymore. React, Angular and Vue are all mature ecosystems. Whatever problem you're facing, chances are someone has already solved it.

And then there's AI, which can already handle a surprising amount of routine programming work.

But could this still happen today? Absolutely. Just... probably not in frontend anymore.

Today we have a brand-new ecosystem growing at an incredible pace: AI, and especially AI agents.

This is where many of today's biggest engineering questions live. Conferences and meetups appear all the time because nobody has all the answers yet. We're still writing articles explaining how an agent loop works, and those aren't even beginner topics. Protocols like MCP evolve rapidly enough that staying current requires genuine effort.

It reminds me a lot of frontend development back in 2017.

And just like we did back then, it's incredibly easy to make dangerous assumptions during development.

Someone parses a model's free-form response with a regular expression instead of using structured output.

Someone assumes the model will always wrap JSON inside the exact same Markdown block.

Someone builds business logic around an undocumented field returned by a provider.

Someone assumes the exact same prompt will always trigger the exact same tool.

Everything works today. Tomorrow it probably still works. Next month, a tiny update changes one seemingly insignificant detail...

...and suddenly everything falls apart.

Just like our little i18n attribute did.

The Real Lesson

Looking back, I don't think this story is really about Angular. It's about something much more universal.

As engineers, we often mistake observable behavior for a guaranteed contract. Just because something exists today doesn't mean the authors intended you to rely on it.

If your solution depends on undocumented behavior, you're not building on solid ground. You've simply been lucky so far.

BUT!

That doesn't mean we should beat ourselves up over mistakes. Nobody gets everything right. The important part is learning from them.

And this particular project? It got a happy ending. I left it years ago. But the application is still alive and doing well. Most of my code has probably disappeared by now... but I checked just before writing this article.

The login screen still looks exactly the way I designed it almost a decade ago. That made me smile. HOW COOL IS THAT 🤣❤️

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.

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.

DEV Community: Sylwia Laskowska

10 Git Commands You’ll Wish You Knew Earlier

1. & 2. git merge vs git rebase

Merge

Rebase

And what about conflicts?

3. git commit --amend

4. git push --force-with-lease

5. git rebase -i

pick

reword

edit

squash

fixup

drop

6. git stash

git stash list

git stash show

git stash apply

git stash pop

7. git cherry-pick

8. git reset --soft, --mixed, --hard

git reset --soft

git reset --mixed

git reset --hard

9. git reflog

10. git revert

7 Productivity Tips That Sound Wrong (But Actually Work)

1. Do Less Than You Could

2. Don't Work on Weekends

3. Plan Your Week in Advance

4. Set Embarrassingly Achievable Goals

5. Deliver Only What You're Asked For

6. Know What “Done” Means Before You Start

7. Reply to Small Things Immediately

The End of Undetectable AI Text? Claude’s New Watermark Explained

Wait, Why Do We Even Need This Law? Did AI-Generated Text Become Illegal in Europe?

What Do We Actually Know So Far?

So... How Does This Watermark Actually Work?

Is Claude the Only Model Watermarking Text?

Will Everyone Have Access to a Watermark Detector?

What Does This Actually Mean for Us?

What About Images, Audio, and Video?

And What the Hell Happens With Code?

So, Should You Care?

Stop Calling Everything Impostor Syndrome: The Myth of "Just Push Harder"

Impostor Syndrome

But Not Every Doubt Is Impostor Syndrome

Think Like an Engineer

Debug Your Strategy, Not Just Your Confidence

It Was Just a Patch Update. What Could Possibly Go Wrong?

Welcome Back to 2017

The Problem With Angular's Early i18n

The Patch Update

Time for Some Digital Detective Work

Solving the Mystery

The Fix

Were We Terrible Engineers?

Why This Bug?

The Real Lesson

BUT!

The Dirty Secret Behind AI Agents (Demo 🚀)

Do We Really Need a Framework?

Meet Steve

"An Agent Is Just a While Loop"

How Does the Agent Actually Work?

Step 1: Send the prompt and available tools

Step 2: Wait for the model's response

Step 3: Execute the tool locally

Step 4: Repeat until the model is done

What's next?

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

Epilogue: An agent written by another agent

Final Thoughts

8 Things Developers Confidently Explain After Watching One YouTube Video

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

2. LLMs are just autocomplete

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

4. AI agents are just a while loop

5. WebAssembly is always faster

1. & 2. `git merge` vs `git rebase`

3. `git commit --amend`

4. `git push --force-with-lease`

5. `git rebase -i`

`pick`

`reword`

`edit`

`squash`

`fixup`

`drop`

6. `git stash`

`git stash list`

`git stash show`

`git stash apply`

`git stash pop`

7. `git cherry-pick`

8. `git reset --soft`, `--mixed`, `--hard`

`git reset --soft`

`git reset --mixed`

`git reset --hard`

9. `git reflog`

10. `git revert`

Explicit Resource Management (`using`)