DEV Community: Sylwia Laskowska

How to Become a Tech Conference Speaker (And Why You Might Regret It)

Sylwia Laskowska — Wed, 21 Oct 2026 08:05:30 +0000

So you want to be a conference speaker? Are you sure?

Recently, a few people have asked me what it's actually like to speak at tech conferences. How do you get accepted? What does preparation look like? And what happens behind the scenes? So I decided to write about it. And let me warn you: the reality isn't always pretty. In fact, after hearing about my experiences, one person has already put their conference-speaking plans on hold indefinitely. 😅

Because conferences aren't just about getting on stage and having fun. They're also about rejected abstracts, endless preparation, stress, and logistics. And is it actually worth it? Let's find out! 😉

One little disclaimer: everything I'm about to share is based on my own experiences and observations. Other speakers might have completely different perspectives, and I'd love to hear them in the comments!

First, a Little About My Conference Experience

Before we start, let me briefly tell you about my conference "achievements," so you know where I'm coming from. I gave various talks and workshops around 2019, then took a break for several years to focus on my professional development, occasionally running a workshop here and there.

About a year ago, I decided to get back into conference speaking seriously. Since then, I've spoken at:

JS Poland
jsday Bologna
JSNation (online)
AGNTCon + MCPCon Europe (Amsterdam)
FrontKon (Prague)

And I still have two conferences coming up this year:

iJS Munich
AI Coding Summit Berlin

I even had to turn down one invitation because I simply couldn't fit it into my schedule anymore. :( I still regret it!

I got accepted to some through CFPs, was invited to others, and got a few opportunities partly through connections (for example, because another speaker remembered me from a previous conference).

I'm not a keynote speaker. I often speak on additional tracks or in smaller rooms, and I'm perfectly fine with that. Actually, I think that's what makes my perspective interesting. I'm not a conference veteran with ten years of experience whom organizers are fighting to book.

And while I feel pretty confident about blogging these days, conference speaking still gives me a massive case of impostor syndrome. Especially since English isn't my native language. I always think nobody will ever invite me again. And somehow, people keep inviting me. 😅

Getting Accepted: The Wonderful World of CFPs

Okay, so how do you actually get accepted as a conference speaker?

If you're not the face of a huge tech company, the maintainer of a famous library, or some kind of tech celebrity, your main option is to apply through a CFP (Call for Papers). Most major conferences accept talk proposals, so you just need to check their websites for submission deadlines.

Sounds simple, right? Well, if only conference organizers were sitting there, eagerly waiting for our submissions!

Let's say a conference has 20 speaking slots. That doesn't mean organizers will select 20 people from the CFP. Quite a few slots might go to invited speakers — well-known names who help sell tickets. Others might go to sponsors. And who knows who else! When hundreds of submissions compete for the remaining places, your chances aren't exactly amazing.

Rejections are completely normal, and they don't necessarily tell you much about the quality of your abstract. Your topic might have been great but didn't fit the agenda, or the organizers decided it wasn't relevant to their audience.

But let's not fool ourselves, either. Your topic might simply have been weak, and submitting it twenty times won't magically make it better. You can ask organizers for feedback, but they're under no obligation to provide it.

How to Make Your Talk Stand Out

As someone who has lost quite a few CFP battles but managed to win a few as well, I can offer some advice.

First, look at your abstract from the organizers' perspective. They're not selecting you just to make you happy. You need to bring something valuable to their conference.

If you're not famous enough to sell tickets just by having your name on the agenda (and I'm guessing you're not, unless you're just reading this out of curiosity), you need an exceptionally interesting topic. Something original that hasn't already been submitted by 20 other people.

Ideally, a case study from your work or personal projects, or a fresh perspective on a familiar subject. Your topic should be original, but not too niche, either. After all, people still need to be interested in it.

For example, I've traveled to a few conferences with a talk about WebGPU, but I presented it more broadly as "Your Browser Is a Compute Platform." It was a big-picture talk about what browsers can do these days, including running LLMs directly in the browser. Because if I'd submitted something like "Introduction to WebGPU with Shaders," I'm pretty sure nobody would have cared.

Spend some time working on your abstract, too. Ask yourself: what will attendees actually take away from this talk? This will also help you prepare the narrative later. And who knows? You might realize your talk isn't particularly useful in its current form and that you should rethink the approach.

The Catch: Nobody Knows If You Can Actually Speak

Now, here's another problem. You might have a fantastic topic and a beautifully written abstract, but if you have absolutely no speaking experience, getting accepted will be much harder — especially at prestigious conferences.

Again, put yourself in the organizers' shoes. How do they know whether someone who's never stood on a stage can handle the stress, deliver an interesting presentation, and finish on time? (By the way, finishing one minute early is much better than finishing five minutes late.)

Blogging or making YouTube videos can help, because they at least demonstrate your storytelling skills. And of course, some conferences happily accept first-time speakers.

But if you're struggling to get accepted anywhere, consider starting with a local meetup. There's usually less competition, and you'll have a speaking engagement to put on your CV. 😉 The more you speak, the better you become, which improves your chances of getting accepted in the future.

Congratulations, You're a Speaker! Where's the Money? 💸

Okay, you've been accepted! Is this where the fame and fortune begin? Hahahaha. I seriously doubt it.

People often ask me whether conference speakers get paid. Well, some do, especially famous keynote speakers who can command speaking fees. But if you're a regular speaker accepted through a CFP, you probably shouldn't expect payment. At least, that's been my experience. I know there are exceptions, so feel free to correct me!

Conferences often cover travel and accommodation, but read their policies carefully. Personally, I always make sure those costs are covered. I mean, okay, I might not earn anything, but I'm certainly not going to pay out of my own pocket for the privilege of speaking. So check this before submitting your proposal.

Sometimes your employer will cover your expenses if they consider your appearance good publicity for the company. But again, make sure that's actually the case before committing to the trip.

Preparing a Talk: How Much Work Are We Talking About?

So, how much work does it take to prepare a conference talk? Well, it depends!

My first conferences took absolutely ridiculous amounts of preparation. Weeks of research, creating slides, endless rehearsals, and carefully weighing every sentence. Because what if someone decided I was an idiot?!

I also had this habit of writing down all the absolute must-have information. Somehow, I'd end up with 45 minutes of material for a 20-minute talk. Well, apparently the audience doesn't need to know absolutely everything. 😀

Before my first conference after my long break, I experienced something very close to anxiety attacks almost three weeks in advance! It was awful. Consciously, I knew that even if I walked onto the stage and burst into tears, nothing particularly terrible would happen. 😅 But my subconscious had other ideas.

Conference preparation can consume practically unlimited amounts of time and emotional energy. And if you start speaking regularly, you eventually need to get that under control. Otherwise, you might as well give up and find something more productive to do with your life.

What Works for Me Now

These days, I often speak about topics I've already covered on my blog, which makes my life much easier. I already have the narrative, a working demo, and even comments from readers that give me additional perspectives.

All I need to do is put everything together, prepare slides, and rehearse a few times to check whether the presentation flows naturally and fits within the time limit.

Nowadays, this usually takes me about two weeks, and I'm not working on it every day. During the final stage, I generally do just one rehearsal per day, meaning less than an hour of work. But remember: I've already done the research while preparing the original article!

You can also reuse presentations at different conferences. In fact, organizers often prefer talks that have already been delivered successfully. That doesn't mean traveling around with exactly the same slides, though. Usually, you'll need to adjust something: make it longer, shorten it, or approach the subject from a different angle.

So yes, preparation gets easier. But it definitely doesn't drop to zero.

Your Talk Is Not a University Lecture

There's one trap beginners sometimes fall into. A 30-minute or even 45-minute conference presentation isn't a deep dive or a workshop. You don't need to transfer every piece of knowledge you have into the audience's brains. They won't remember it all anyway.

Your job is to inspire people and show them new possibilities. If they're interested in the details, they can explore them later. After all, people attending tech conferences are intelligent adults. They can figure things out!

I actually think conference presentations should be treated a little like a show. Of course, we're still talking about technical conferences, not TED Talks or theatrical performances. But the entertainment aspect matters.

There are plenty of techniques for engaging an audience, and I'm not going to list them all here. But here's my minimum rule: if you're doing a dry run and start getting bored at some point, imagine how bored the audience will be. That's probably a good place to introduce something more entertaining. 🙂

And Then There's the Logistics ✈️

After all those rehearsals, you still need to actually get to the conference. Which means flights, airports, transportation, hotels, and all the other wonderful aspects of traveling.

Very often, you'll need to arrange your flights yourself. Accommodation is more frequently booked by the conference, but that varies too. And even if your expenses are covered, you might not get reimbursed until after the event. So you need to pay upfront.

If you have a family, well, they'll have to manage without you for a few days. And you're lucky if your employer supports your speaking activities and continues paying your normal salary. Because if they don't? You're simply taking time off work.

Suddenly that "free trip" isn't looking quite so free anymore.

Stage Fright Never Really Goes Away

Now, let's talk about the actual presentation. Getting on stage comes with stress, whether you're speaking for the first time or the hundredth. Even Luca Mezzalira, with around twenty years of experience, once joked on LinkedIn that before every talk, he wonders why he didn't become a shepherd instead.

I think the difference is mostly about how long you feel stressed. These days, I usually start experiencing mild panic about an hour before my talk. 😀 Progress!

But here's another funny thing: every speaker seems to worry about two things. Will anyone show up? And did I do a good job?

Seriously. At one conference, I was surprised when some very well-known female speakers, who had delivered keynotes in an auditorium with an audience of around 2,000 people, asked how many people had attended my WebMCP talk. (It was a full room!) They were interested because their talks covered similar topics. 😱

And even speakers at that level appreciate hearing that their presentation was good. So if you're attending a conference and enjoy someone's talk, don't hesitate to tell them! I promise they'll appreciate it. 😀

So... Is Conference Speaking Actually Worth It?

Okay, but why go through all this? What are the actual benefits of public speaking? Well, in my opinion... Not nearly as many as you might expect.

You get a free trip, sometimes a T-shirt or a baseball cap. You meet other speakers and make lots of connections. 😅 (And sometimes you might even make actual friends!) You can take souvenir selfies with tech celebrities and collect LinkedIn connections from the local community.

Plus, of course, you get a nice new entry on your CV.

But will your career suddenly take off? Probably not, especially after just one single talk.

Sure, if you're selling consulting services, courses, or something similar, conferences can be an excellent way to reach customers. But that's a different story, and if that's your business model, you probably already know how it works. If you're a DevRel, it's basically your job.

If you're not selling anything, though — like me — speaking gives you some credibility points. But that's about it! Okay, okay. You also make connections that might become useful someday. Or they might not. Who knows?

And let's be honest, you don't actually need to be a speaker to enjoy many of the benefits. You can attend a conference, meet interesting people, make connections, and enjoy the whole experience without spending weeks preparing a talk or questioning your life choices backstage. 😅

Why Blogging Has Been More Valuable to Me

When it comes to my career, blogging has actually helped me much more than conference speaking. And the potential audience is much bigger.

Think about it. How many people attend one of my talks? Maybe 200 or 300? And perhaps another thousand watch the recording on YouTube, if I'm lucky.

Meanwhile, on my blog, I can publish whatever I want, whenever I want, about whatever interests me. I reach people from all over the world, and my articles keep working for me even while I'm sleeping. I don't need to book flights, prepare slides, rehearse for days, or stand nervously backstage wondering whether anyone will show up.

I just write. And the content keeps reaching new people long after I've published it.

So if you're thinking about conference speaking but you're terrified of public speaking or overwhelmed by the amount of work, I genuinely encourage you to think twice about whether it's worth it. 😀 There are other ways to share your knowledge and build a reputation in tech, and some might be a much better fit for you.

And Yet... I'd Do It All Again ❤️

Despite everything I've written, I absolutely love speaking at conferences. I love traveling, meeting new people, the atmosphere, the conversations, and being part of the international tech community.

Unfortunately, there's something a little addictive about it. That rush of adrenaline when you step onto a stage is something even the most successful blog post can't quite replicate.

So, is conference speaking worth all the stress, preparation, rejected abstracts, logistical headaches, and questionable ROI? Honestly, I'm not entirely sure.

Will I do it again? Absolutely. 😂

And even though I still have no idea whether anyone will ever invite me to speak again 😅, I hope you'll see me on more European stages in the future. And hopefully, not just European ones!

But that's just my perspective. If you're a conference speaker, I'd love to hear about your experiences. Do you get paid for your talks? Has speaking made a difference to your career? Do you also question all your life choices an hour before going on stage?

And if you're thinking about becoming a speaker, did I encourage you or scare you away completely?

Let me know in the comments! 😁

And if you'd like to follow my adventures in tech, blogging, and conference speaking, feel free to connect with me on LinkedIn! 😊

Your Browser Can Do WHAT?! 5 AI Features That Actually Work

Sylwia Laskowska — Wed, 14 Oct 2026 07:05:48 +0000

Are AI models running directly in the browser finally good enough to use in production? Let's find out! 😉

It's been a week since my talk at FrontKon in Prague. As I mentioned before, it was fantastic! I'm adding a few photos below, just to prove that I actually speak at conferences and don't just make these things up. 😀

My talk was titled "Your Browser Is a Compute Platform (And You're Using It for Forms)", and I showed how we can use WebAssembly and WebGPU to perform advanced computations directly in the browser. I was a little concerned to discover that, out of everyone in the audience, maybe three or four people had even heard of WebGPU! And that's a shame, because WebGPU can accelerate certain types of parallel computations by tens of times compared to CPU-based implementations.

But okay, at least the people at FrontKon know what WebGPU is now. 😁 And if you'd like a talk about this at your conference, feel free to reach out! Especially if your conference happens to take place in a particularly attractive tourist destination. 😀

Why I'm Revisiting Browser AI

After a conference, I traditionally prepare a blog post related to my talk. However, since I've already written about WebAssembly and WebGPU many times, today I'd like to approach the topic from a different angle. Namely, let's take a look at the current state of AI models running directly in the browser, which, of course, make extensive use of these technologies. 🙂

Browser-based AI models are a fascinating concept. No inference API calls. No network round trips to an AI backend. No worrying that your users will consume too many tokens, because you're not paying for them! But of course, local inference still takes time, and downloading the model in the first place can take a while.

Another advantage is that these models can work offline once they've been downloaded and cached by the browser, provided the application itself supports offline operation.

And that also brings a significant privacy benefit: inference happens directly on the user's device, so their data doesn't need to be sent to an external AI service.

However, as you can probably imagine, these are relatively small models. We're not going to run a massive frontier-scale model in a typical browser tab.

So the question is: how useful are these smaller models, really?

Some of you may remember that I experimented with browser-based AI models about a year ago. Back then, we were mostly laughing that they were a fun curiosity, but not much more than that.

But I've been following people from Hugging Face who work on Transformers.js on LinkedIn, and every now and then, their demos would appear in my feed. At first glance, some of them looked genuinely impressive. You know, practically spaceships running inside a browser. 😉

So before FrontKon, I decided to take another look at what they had to offer. And it turned out that after upgrading Transformers.js to version 4.3.1, which I used for these experiments, and trying some newer models, the results were genuinely impressive!

Of course, Transformers.js isn't the only option for running AI models in the browser. There are other libraries and runtimes, but I really like Transformers.js, and I think it's a pretty representative example of what this technology can achieve today.

At the same time, I don't work for Hugging Face, and nobody is paying me to sell you a spaceship in your browser. So I'll tell you what browser-based AI models can actually do today, what works well, and what still doesn't.

And even better, you can explore the code and try everything yourself!

GitHub: https://github.com/sylwia-lask/practical-browser-ai

Live demo: https://sylwia-lask.github.io/practical-browser-ai

If you like the project, please give it a star on GitHub. I'm collecting them! 😀

Can We Actually Use This in Production?

For these demos, I wanted to focus on practical applications. More specifically, I wanted to find out how we could use browser-based AI today, right now, in real production applications.

So is this technology worth paying attention to? In my opinion, absolutely!

But!

I probably wouldn't build a mission-critical system that depends entirely on these models working perfectly. 😉 Instead, I'd treat them as interesting, optional enhancements to existing application features, especially in areas like e-commerce, accessibility, and customer support.

The application itself is nothing particularly exotic, by the way. It's a regular React application written in TypeScript, using Web Workers to run model inference without blocking the main UI thread.

The models are loaded on demand, so you don't need to download all five of them just to open the application. The inference runs locally through Transformers.js, using WebGPU where supported and WebAssembly-based CPU execution where a fallback is available.

No AI backend involved!

Let's see what I managed to build. And at the end, I'll share my thoughts on the limitations of these models.

One more thing: these aren't browser-based AI agents yet. They're simply applications using local AI models for specific tasks. But give me a few more weeks, and you'll see agents running in the browser on my blog too!

1. Background Remover

One of the things I particularly appreciate about browser-based AI is that it's not limited to text generation. I love working with multimodal AI!

In this demo, a small model called RMBG-1.4, with approximately 44 million parameters, does a really impressive job of separating an object from its background. 🙂 The model itself is only about 170 MB to download in the configuration I'm using.

As you can see, we can then save the result as a transparent PNG, and it works surprisingly well!

I can easily imagine this as an additional feature on auction websites or e-commerce platforms.

Imagine someone trying to sell a product but only having a photo like my example. Instead of requiring them to use an external image-editing service, we could simply offer a background removal button directly in the application.

And the photo doesn't even need to leave their device. Pretty cool, isn't it?

One practical note: RMBG-1.4 comes with licensing conditions that should be checked before commercial deployment. So while the technical concept is very promising for e-commerce, you should always verify the model's license before shipping it.

2. Alt Text Generator

I've always felt that AI could become another useful layer of accessibility, if we use it properly.

This demo uses Florence-2-base-ft, a vision model with approximately 230 million parameters, to generate descriptions of images.

Imagine that you're uploading an image to DEV, for example. Instead of having to write an alt text description from scratch, you could use a model like this to generate a suggestion automatically. Especially when you really don't feel like describing what's in the picture!

Of course, the generated description should still be reviewed and edited by a human. Good alt text isn't just about identifying objects in an image. It also depends on the context and purpose of that image.

The model doesn't necessarily understand why you're using the picture, and it can occasionally miss or invent details. Still, as an accessibility assistant, I think this is a very promising approach.

There's also an option to provide additional context, but don't expect too much from it. In my implementation, the extra text is simply appended to the generated description rather than genuinely influencing what the model sees or understands. I'll explain why I wasn't satisfied with this approach later in the article.

For reference, the model download is roughly 350–450 MB, depending on the precision supported by the device.

3. Smart Ticket Creator

Oh, this one is my dream feature! I describe what's wrong in completely natural, messy language, and the model turns it into a structured ticket that I can send to support. 😀

The model I ended up using is Qwen2.5-0.5B-Instruct, a small language model with approximately 500 million parameters. In my configuration, its quantized weights require a download of around 786 MB, plus tokenizer files.

And I have to admit something. When I started implementing this feature, I thought it would be the easiest one! Seriously. How difficult could it be for a language model to turn a complaint into a structured ticket?

Well... Apparently, quite difficult! I spent much more time than expected trying different models and getting them to produce the output I actually needed.

The main challenge wasn't just understanding the complaint. It was producing a consistent, structured response with the correct fields, without inventing information or returning malformed JSON. Eventually, I got it working using a carefully designed prompt, output parsing, and schema validation with Zod.

The generated ticket is editable, so the user can review everything before copying or submitting it. And I think that's exactly the kind of approach that makes sense for production: let the AI do the boring initial work, but keep the human in control.

4. Semantic Search

Now, this is where small models really shine! For this demo, I implemented semantic search over a collection of support tickets.

Instead of looking for matching keywords, the application searches for tickets with a similar meaning. And, of course, I also included a traditional keyword search so you can compare the results yourself.

I'm using all-MiniLM-L6-v2, a small embedding model with approximately 22 million parameters. Depending on the backend, its model weights are only about 23 MB for the quantized CPU version or 90 MB for the WebGPU version.

And it works really well! The model is fast, and the results are genuinely useful.

Under the hood, it converts the tickets and the search query into numerical vectors, then compares them using cosine similarity. No generative LLM is needed here.

In fact, that's one of the most interesting lessons from these experiments: sometimes a small, specialized model is a much better choice than a general-purpose language model. This is particularly good news for applications where privacy matters and you don't want to send potentially sensitive information to an external server.

For a small collection of documents, this approach is definitely worth testing. Of course, for larger datasets you'd need to think about indexing, storage, and performance. In my demo, the embeddings are kept in memory, which is perfectly sufficient for the example. But the basic idea works surprisingly well.

5. Pause & Ask

Okay, this one might be a little less practical, but it's definitely fancy! 😀 And I think it also has interesting accessibility potential. For this demo, I'm using LFM2.5-VL-450M, a vision-language model with approximately 450 million parameters. The download is roughly 350–400 MB, depending on the configuration.

There are actually two features here. The first is live visual description. I turn on my webcam, and the model periodically describes what it sees. Yes, that's me:

But then it gets even better! I can pause the camera on a particular frame and ask the model questions about what it sees.

And here's the example showing that the model isn't exactly perfect. 😅 Although, well, I'm certainly flattered!

I wouldn't treat this as a reliable accessibility tool just yet, but as an experiment in local visual question answering, it's genuinely fascinating.

And that's all five demos!

So What's the Catch?

Now, as promised, let's talk about the disadvantages. Because, of course, there are quite a few!

WebGPU Support and Hardware Limitations

First of all, these models run as well as they do largely thanks to WebGPU. This API allows applications to use GPU computing capabilities directly in the browser, which can make a huge difference for machine learning inference.

The problem is that WebGPU availability and performance aren't the same on every device. Support has improved significantly across modern browsers, but availability still depends on the browser version, operating system, GPU, drivers, etc. And even if WebGPU is supported, that doesn't mean everyone has an equally powerful computer.

Mobile devices are a particularly interesting problem. Some mobile browsers and devices still lack usable WebGPU support for certain workloads. In those cases, some Transformers.js models can fall back to WebAssembly-based CPU inference, potentially using SIMD or multithreading depending on the environment and configuration.

Unfortunately, this can be significantly slower. On my phone, two of the examples from my demo didn't work at all because they timed out. And it's not like I'm using some ancient phone from a museum! It's a Samsung Galaxy S24 FE. Not the newest flagship anymore, but definitely not a dinosaur either.

So yes, WebGPU support is improving, and the models are getting better. But I want to talk about what we can actually use right now, not what might be possible in a few years.

Model Downloads Aren't Exactly Tiny

There's also another important limitation: the models themselves have to be downloaded. And while some are relatively small, others can require hundreds of megabytes. As you've seen, the models in my demo range from around 23 MB for the quantized semantic search model to nearly 800 MB for the Smart Ticket Creator. That's quite a lot if you're visiting a website on a mobile connection!

Fortunately, browsers can cache the downloaded model files, so subsequent visits usually don't require downloading everything again. But the first load still matters, and browser storage isn't guaranteed to keep those files forever.

That's another reason why I'd treat these features as optional enhancements rather than something every user must load before they can use the application.

Some Things Still Don't Work Well Enough

I also couldn't implement everything I originally wanted, even though some ideas seemed perfectly reasonable. For example, I tried adding text recognition from images. And despite experimenting with different models and configurations, I couldn't get results that were reliable enough for my demo. The approaches I tested didn't give me the quality I wanted, so I decided not to include that feature.

Another thing I wanted to improve was the contextual information in the alt text generator. Imagine uploading a photo of a dog and adding some additional context, such as: "This dog is available for adoption at a local animal shelter." Ideally, the model would take that information into account and generate a beautiful, context-aware description.

I tried using an additional local language model for this, hoping it could combine the visual description with the extra information. But no matter what I tried, the results were very unsatisfactory. So I ended up with the simpler approach I mentioned earlier, where the context is added separately rather than genuinely interpreted by the image-captioning model.

And that's another good example of why I wouldn't blindly trust these models in production.

What About Voice Recognition?

On the other hand, I've heard that small browser-based models can be surprisingly good at speech recognition. Transformers.js supports audio-related tasks too, so that's definitely another interesting area to explore.

I didn't test it this time, though. Mostly because I was building these demos in the evenings, and my family would have killed me if I'd spent hours talking to my computer. 😂 Maybe next time!

My Verdict: Is Browser AI Production-Ready?

So, to sum up: browser-based AI models are getting better, and I think it's already worth exploring how to use them in production applications.

Not necessarily as a replacement for every AI backend. And definitely not as a critical dependency without a fallback. But as optional features that improve the user experience? Absolutely.

What do you think? Have you already experimented with running AI models directly in the browser?

And if you enjoy reading my articles, feel free to follow me on LinkedIn too! 🙂

Every Software Developer Has Blamed…

Sylwia Laskowska — Thu, 08 Oct 2026 06:52:08 +0000

I got back from FrontKon in Prague today (well, technically yesterday, since I'm publishing this tomorrow), and I'm DEAD! 😂

The conference itself was fantastic, of course. Both my panel discussion and my talk went really well, and the Czech developer community is starting to feel like family. Greetings from your favorite senior software vývojářka! 😀

I'll write my usual, more technical article next week. I want to approach the topic from a slightly different angle, so I need a bit more time for research. Meanwhile, flights from Gdańsk to Prague depart at the absolutely murderous hour of 6 AM, which means that at 3:30 AM today, I was still in Prague!

And since some of you have recently been asking for another installment of my "You're a Real Software Developer Only If…" series, here you go!

Who or what has every software developer blamed at least once? Here's my list!

1. Another Developer

Obviously, if the code is terrible, it's never our fault. Someone else must have messed it up. A colleague from our team, someone from another team, or the developer who worked on the project before us.

Quite often, though, that "other developer" turns out to be ourselves from six months ago. 😅

2. The Company

Because the processes are terrible, the standards are nonexistent, and management clearly has no idea what they're doing. The poor developer has been thrown into this corporate machine and is now forced to fight an endless battle against the system.

Things get a little awkward when you're self-employed and your company consists of… well, you. xD

3. Legacy Code

The application could be just six months old, and somehow there will already be legacy code somewhere. And naturally, that legacy code is responsible for every bug, every delay, and every missed delivery deadline!

4. The Framework

It's buggy! It's unpredictable! It's missing half the features we need!

If I wrote my own framework, now THAT would be something! And why haven't I done it yet? Well, I never promised anyone I would! 😅

5. The Client

Let's be real: our jobs would be so much easier and more enjoyable if it weren't for that annoying client who keeps asking for things and complaining about everything. 🤣

6. The Backend

This is personally my first suspect whenever something goes wrong. If something doesn't work, it MUST be the fault of whoever wrote the backend.

I mean, come on. Are you seriously suggesting that something could possibly be wrong with MY code???

7. The Frontend

And this is exactly what backend developers think about the frontend whenever someone reports a bug.

Yes, yes, I know. In the age of AI, many of us have become full-stack developers, whether we wanted to or not. But deep down, our hearts will always belong a little more to one of those "ends." ☺️

8. The Requirements

Obviously. They're either too vague, poorly written, or based on some completely ridiculous idea invented by the stakeholders.

And even if the requirements are absolutely perfect, there's probably something missing from the documentation anyway. 😉

9. The Cache

Come on, admit it. If you've never told someone to "clear your cache," can you even call yourself a software developer???

10. CORS

Often the first suspect for junior developers whenever some mysterious error appears. Never mind that everything was working perfectly fine yesterday. It's probably CORS!

11. The Browser

An obvious one. I mean, is it OUR fault that people still insist on using Safari???

12. …And Eventually, Themselves

Now, let's get a bit more serious for just a moment. There are two kinds of complaining. The first is just harmless grumbling, the same way we complain about bad weather. It's particularly popular in countries like Poland, where complaining is practically a form of small talk.

But there's another kind. Of course, I'm not talking about situations where a project or the people you work with are genuinely toxic. Those situations absolutely exist, and sometimes you really do need to sit down and think about what to do next.

But in other cases? Sometimes it's worth stopping for a moment and asking ourselves where WE fit into this picture of everything and everyone we're blaming.

There's actually a well-known psychological phenomenon called the fundamental attribution error. In simple terms, it describes our tendency to overestimate someone's personality or character and underestimate their circumstances when explaining their behavior.

There's also a closely related concept called the actor–observer bias, which describes a tendency to explain our own behavior in terms of circumstances while explaining other people's behavior in terms of their personal characteristics.

And that's particularly interesting here. Think about what happens when WE mess something up: our code isn't exactly a masterpiece or we missed a deadline. We can usually come up with perfectly reasonable explanations. And often, those explanations are completely valid!

Maybe we were feeling a little sick, so our productivity dropped. Maybe the plumber wouldn't stop talking, and we lost half the morning. Maybe the library documentation was terrible. A million things could have happened.

But what happens when ANOTHER developer messes something up? What do we think? Unfortunately, quite often, it's simply: "What an idiot."

But here's the thing. That other developer has a life, too. They have their own problems, crying children, plumbers who show up late, and a thousand other things going on that we know absolutely nothing about.

We don't have access to their thoughts or their circumstances. So our brains take a shortcut. And suddenly, instead of thinking "maybe something happened," we decide that the person is simply incompetent.

And that's the thought I'd like to leave you with today. I was going to add some profound, philosophical conclusion here, but everything I came up with sounded suspiciously like something written by Sylwia Coelho.

So let's keep it simple. Let's just try to be a little more understanding toward one another. ❤️

And next time you find yourself blaming another developer, remember: somewhere out there, another developer is probably blaming you. 😂

If you enjoy my content, you can also follow me on LinkedIn.

The Accidental Blogger: How I Ended Up on DEV

Sylwia Laskowska — Tue, 29 Sep 2026 06:11:11 +0000

This is going to be a more personal post, exposing my entire personal branding strategy, or rather, the complete lack of one. 😅 If you're only here for technical content, feel free to keep scrolling. Maybe I'll write something technical later this week. I have no idea how many people will read this one — maybe five — but that's kind of the point!

I'm writing this post because it's just been a year since I started publishing here. My beautiful badge:

It has been a truly crazy year, during which I've had the enormous pleasure of earning your trust, and somehow ending it with stats like these. Thank you! ❤️

@francistrdev suggested under one of his posts that I should tell the story of how I ended up on DEV. But I decided that deserved a separate post, preferably an anniversary one, because the story is definitely not the usual one. You see, I started a blog because I wanted... something to put on my "About Me" slide at a conference. 😅

But let's start from the beginning.

It Didn't Exactly Start at the Best Time

In the summer of 2025, I wasn't in a particularly good place mentally. The previous year had brought several very negative events in my personal life, which I don't want to write about publicly (but seriously, objectively speaking, things were pretty bad).

And then, as the final blow, I had to give up my beloved judo because of an injury. Not my first one, either, so this really felt like the final nail in the coffin. I'd only trained for two years, but I went three times a week. I had my routine and friends there.

For most of that summer, I was just somehow drifting through life. I wasn't depressed, but I was constantly stuck thinking about all the bad things that had happened.

After many weeks, I finally decided that I had to somehow get myself out of that loop and start trying new things. A party, a workshop, a local event. Anything.

And it turned out that it worked! Obviously not overnight, but every new activity and every new idea helped me take another small step out of the darkness and toward the light.

And Then There Was JS Poland

One day, while scrolling through LinkedIn, I came across a post from a friend of mine who travels around Poland giving talks at meetups. And it suddenly reminded me that I'd once dreamed of speaking at JS Poland.

I figured their CFP was probably open. It was, indeed. I submitted exactly one topic.

Now, JS Poland is a serious conference with some world-class speakers, so I estimated my chances as... rather tiny. But I'd submitted something! A few more dopamine points unlocked. I was very proud of myself.

Some time later, conference organizer, Darek, contacted me and asked whether I happened to have recordings of any of my previous talks. As luck would have it, I had exactly one, from six years earlier. I sent it over and assumed I'd probably get a yes/no answer sometime the following week.

He called me back half an hour later. (The talk was 20 minutes long.) He said the presentation was "excellent" and invited me to the conference. OH, WHAT A DOPAMINE HIT THAT WAS!!! I felt amazing.

In the meantime, another tragedy happened very close to me, but because something was happening in my life, because there was movement and something to look forward to, I didn't completely fall apart.

So... Maybe I Should Start a Blog?

After a few weeks, however, the dopamine started wearing off, and it was still too early to start working seriously on the conference presentation. I have no idea why, but at some point I thought: Maybe I could start a blog? Then I'd have something to link on my "About Me" slide, so it would look like I was doing something in the community. 🤣

I didn't feel like building my own blog, though, so I decided to use an existing blogging platform. I chose DEV because I'd always liked... the layout. 😅 Also, the articles I came across on DEV had always seemed interesting and approachable.

My friends laughed and said I'd probably get bored with it pretty quickly. I told them that was fine. I'd write one post a week, and if I got bored, I'd switch to one a month so it would still look like something was happening. xD

Wait, There's a Community Here?

Before that, I'd mostly encountered DEV articles through tech newsletters. I knew basically nothing about the platform itself. So little, in fact, that when @ben once commented on one of my articles, I remember wondering why his one-line comment had received so many likes. 🤦‍♀️😅

Eventually, I realized there was a feed here. A whole stream of posts, a community!

And there's something you should know about me.

A long, long time ago, I worked on the side as an editor for the biggest internet portal in Poland. And even by those standards, I have to admit I was pretty good at it — especially at finding interesting topics and coming up with headlines. 😀

Working in media is incredibly addictive, and that addiction came back immediately. You know, like an alcoholic who hasn't had a drink in ten years and decides to have "just one beer."

Okay, that's an exaggeration.

But only slightly. 😅

I started publishing on DEV much more often than once a week because I wanted to see "what gets clicks here". Or, translated into normal-person language, "what are people here actually interested in?" I still remember how excited I was about my first like, my first comment, or when one of my posts finally passed 25 views. 😅

And even better: on DEV, I could use my old editorial skills, but I could do it well. No impossible traffic targets to hit. No annoying publishers. No need to squeeze every last drop out of one topic until everyone is sick of it. I could rotate topics. Under my own name, in my own words.

So, Here Are a Few of My Blogging Rules

So what are my publishing "rules"? Maybe some of you will find these useful.

A headline can be controversial. It can even stretch things a tiny bit, as long as the content delivers. If it does, readers usually won't feel cheated. I always spend quite a lot of time thinking about titles. And yes, I almost always choose the most controversial one. 😉

If you went back to my earliest posts, you'd also notice that I published pretty chaotically and wrote about somewhat different things than I do now. I started series that I never finished. I experimented with topics. I didn't really know what I was doing yet. And I think that's completely fine. Maybe that will help someone who's currently wondering whether they should start blogging. You don't need to have some grand content strategy from day one.

I've always said that I write half for myself and half for the reader. 😉I don't go to either extreme. I write about things that I think might interest you, but they also have to interest me.

Not every post needs to go viral. I'm fully aware that not every topic will be equally popular. But that doesn't stop me from writing more expert-level technical posts, sometimes with a GitHub repository and a working demo. And there's no point getting upset when those posts attract fewer readers. That's natural. For one thing, not everyone is interested in the same technologies. Meanwhile, obviously everyone is going to click on something called: "You're the real software developer only if..." xD

However, I think that if you want to allow yourself to write posts like that, it's worth first proving that you actually have some credibility in the field you're talking about.

If you want to write about the mistakes senior developers make, then for God's sake, prove that you are a senior developer yourself, that you actually know how to build things, and that you bring something to the community besides clickbait.

And Then There Are the Comments

When it comes to comments, I've often read influencer advice saying that you should only reply selectively. Apparently, you're supposed to create the impression that you're slightly unavailable.

As you probably know, I couldn't care less about that advice. 🤣 I try to respond to every valuable comment. Of course, I don't always manage. Sometimes I miss one, forget about it, don't notice it, and so on.

But generally, I genuinely think that many of the discussions under my articles are much better than the articles themselves. 😀

From "Something for My Slide" to Conference Invitations

As you probably know, I like speaking at conferences.

Over time, the blog was promoted from "something to put on my slide" to "something I can put in a CFP form to show that I'm active in the community."

But over the last six months, that situation has changed dramatically. More than once, I've actually been INVITED to speak at a conference because someone found one of my DEV articles and wanted a talk about that topic. Or, less often, I'll attach one of my articles to a CFP so that the committee knows roughly what the talk would be about.

And let me tell you: this is probably the most comfortable situation possible. The organizer can relax because they know what to expect. I can relax because I know what the organizer has already accepted. Win-win!

But DEV Would Be Nothing Without the People

And, of course, DEV would be nothing without the people I've met here.

I obviously have to mention @pascal_cescato_692b7a8a20, who I think was the first person here with whom I started having discussions about all kinds of completely different topics.

Then there are the two Daniels:

@dannwaneri gives me a glimpse into what life as a developer looks like in a different part of the world.

@gramli, on the other hand, is living proof that across Eastern Europe we apparently have very similar problems, and a very similar sense of humor. 😁

There's @georgekobaidze, who seems completely different from me, yet somehow, at the end of the day, we always end up having the same obsessions. 😅

And I can't forget about @adamthedeveloper, @anchildress1, @pengeszikra, @xulingfeng, and many, many more, but DEV allows to tag a maximum of 10 users here 😅.

Thanks to founders for building the platform I originally chose because I liked the layout. Turns out it was a pretty good choice. 😅❤️

And honestly, I could mention many, many more people here. I'd run out of evening. 😀

So What's Next?

What am I planning for the next year? I'm not going to say anything like "I'm only getting started!", because that wouldn't be true. I plan to do exactly what I've been doing so far: publish roughly one post a week.

Sometimes I'm tempted by other distribution platforms, but then I quickly realize that I'd have to spend time figuring those out too, and time is something I don't have much of.

I'm also a little tempted by YouTube, mostly as an extension of what I'm already doing on DEV. Will I actually do it? We'll see!

So, for my DEV anniversary, I wish myself exactly the same amount of joy from writing that I have today. And I wish all of you all the best! ❤️

What If Your AI Agent Never Had to Leave the Browser? (Demo 🚀)

Sylwia Laskowska — Mon, 21 Sep 2026 07:14:46 +0000

I haven't written anything lately because, honestly, I just didn't have the headspace for it. There were a few reasons, but the biggest one was my talk at AGNTCon + MCPCon Europe, where I spoke about WebMCP.

How did it go? Great! A lot of people showed up, they asked questions — what more could I ask for? 😅 The conference itself was amazing too, and I definitely came back with enough inspiration for several more articles. I don't have any nice photos yet, but maybe next week!

The audience at an event with more than 2,000 attendees is, of course, incredibly diverse, with very different interests. Alongside people eager to explore sophisticated multi-agent architectures, there were many who were simply wondering how they could improve their already pretty good products by adding some AI capabilities.

Quite a few people from that second group ended up at my WebMCP talk.

So, What Is WebMCP?

In short, WebMCP is an experimental browser API that allows a website to explicitly expose tools that an AI agent can then call. I don't want to repeat myself too much because I've already written about it here:

Is This How We'll Build Websites Soon? WebMCP Live Demo

That article is more than three months old, which, in the world of Agentic AI, means the syntax is already outdated. xD Fortunately, these days it's not particularly difficult to quickly check the latest one, especially since it may still change several more times. 😅

The idea, however, remains the same.

Yes, it's still a young technology. But as it happens, I met one of the people working on WebMCP at the conference (hi, Dominic!), and he told me that around January or February it should be reasonably stable, at least in Chromium. So the clock is ticking!

WebMCP Is Not Quite MCP

Unlike "classic" MCP (and I'm putting classic in quotation marks because I'm not sure whether something this young has earned the right to be called "classic" or "traditional" yet 🤣) WebMCP operates in the context of the browser.

The website needs to be open, the user needs to be logged in if authentication is required, and only then can our agent call the tools exposed by that page. This means we can use WebMCP through an agentic browser or, for example, a Chrome extension. Interestingly, ChatGPT has recently added support for WebMCP-based site tools in its built-in browser, so this technology definitely has some momentum!

That's also why, in my opinion, WebMCP's most interesting use case isn't necessarily multi-agent systems scraping websites. I see it much more as a way to help regular, everyday users interact with the products they already use. Although, of course, give ten developers a new API and you'll probably get eleven different ideas. 😉

Meet My Visionary Leader: AI CEO Simulator

As some of you may remember, my WebMCP demo isn't another boring addToCart() example. It's my beloved visionary leader: AI CEO Simulator. It shows what might happen if we let AI run our company.

As you can see in the screenshot, we have all the typical startup metrics: cash, monthly revenue, number of employees, production incidents, employee happiness, and, obviously, hype level.

We also have board decisions such as Adopt AI, Pivot to Agents, Rewrite in Rust, Fire Employees, Hire Employees, and so on.

In other words: typical startup management.

And, of course, there's an activity log.

The important thing is that this is still a completely normal website. You can click around and use everything manually. Because that's one of the things I love about WebMCP: it's an additional capability for your website. You don't need to completely rebuild your product around AI.

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

Okay, But How Do We Actually Call Those Tools?

Everything sounds great, but there's one practical problem: how do we actually call these tools? This becomes an especially interesting problem when you want to call them live during a conference talk.

Of course, you can do it through ChatGPT or one of the publicly available extensions, but cloud-based solutions need internet access. Their interfaces aren't necessarily ideal for presentations either — when people are watching your demo on a big screen, everything should be large and easy to follow.

And, obviously, I wanted a fallback to local models!

So I built a Chrome extension called WebMCP Local Agent.

GitHub: https://github.com/sylwia-lask/webmcp-local-agent

It's not published in the Chrome Web Store yet, but maybe one day I'll finally spend those $5 on the developer registration fee. 😅💸 For now, if you're interested, you can simply download the source and run it locally.

Is It Actually an Agent?

So what does this plugin — or agent — actually do?

It's very simple. It receives the user's intent, checks the WebMCP tools available on the current page, and calls whichever ones it considers appropriate.

We all know that an agent is basically just a loop. I wrote more about that here: The Dirty Secret Behind AI Agents (Demo 🚀)

And that's exactly how this one works. The model gets the user's intent and the available tools, decides what to call, receives the result, and can then decide what to do next. By default, the agent can go through a maximum of 10 iterations of this loop, although you can change that in the config.

So, as you can see, this isn't just a chatbot with a fancy name. It's a legit little agent.

A Slightly Selfish Motivation Can Still Lead Somewhere Useful

Yes, my original motivation was pretty simple and maybe even a little selfish. 😉 But good things can come from questionable motivations. Even Gollum contributed to the happy ending of The Lord of the Rings. xDDD

Because my extension can run with local models, prompts and model inference can stay on the user's machine when using the local providers. That gives us a very interesting privacy advantage compared with sending every interaction to a cloud model.

It also helps with another problem: access to AI models isn't equally reliable everywhere. My dear DEV friend @dannwaneri mentioned this problem some time ago. Just because we have pretty good infrastructure and access to cloud AI services in Europe doesn't mean the situation is equally good everywhere in the world.

Local models give us another option.

Three Providers, One Agent

As you can see, my WebMCP plugin currently supports three modes.

The first is Google's Prompt API, which uses Gemini Nano managed by Chromium. Once the model has been downloaded, inference happens locally, without sending prompts to Google or another third party, and you don't need an API key.

The second option is Ollama, also running locally. In my case, I'm using Llama 3.1, but you can choose another model if you prefer. Ideally, though, you want one that behaves well with tool calling.

And finally, there is one cloud provider. In my case, that's an older Gemini Flash model, which requires an API key. Because let's be honest: right now, cloud models are generally still the easiest way to get excellent capability and speed. The problem is that they're not always available.

Of course, you can add other models or providers however you like. It's literally just a few lines of code in the extension's source code. ☺️

And Yes, the Local Models Actually Work

As you can see, the local providers work surprisingly well.

Here's Google's Prompt API:

And here's Llama 3.1:

Although I should warn you that Llama 3.1 — rarely, but it does happen — sometimes decides that instead of JSON, what I really wanted was Markdown or some additional "helpful" commentary. That's the joy of working with LLMs. 😅

It's also worth mentioning again that the plugin allows a maximum of 10 iterations of the agent loop by default. You can increase or decrease that number in the config.

But Wait. Isn't This Dangerous?

One concern I hear quite often about WebMCP is that we're changing the interaction model. The user is no longer explicitly clicking every single thing they want to happen. Instead, they express an intent.

Then the model creates a plan, calls tools, and we have to deal with the consequences. And if we simply leave it at that, it's a recipee for DISASTER.

There are relatively harmless tools such as:

listEmployees()

But there are also tools with much more serious consequences, such as:

fireEmployees()

And I'd rather not discover that my AI CEO has decided to improve our runway by firing half the company without asking me first.

Consequential Actions Need Confirmation

Fortunately, the people working on WebMCP are listening to the community, and the API now includes useful tool annotations such as consequentialHint. My plugin supports it as well.

Support for these newer WebMCP features depends on the Chromium version and experimental WebMCP availability you're using, so if you're testing this while the API is still evolving, make sure you're running a sufficiently recent version of Chrome/Chromium with the required WebMCP support enabled.

Now let's try to fire some employees.

As you can see, our agent noticed that the tool call was marked as consequential and displayed a confirmation prompt before allowing it to proceed. The user can approve or reject the action.

Which is probably a good idea when your AI CEO starts restructuring the company. 😉

And, of Course, I Built It with Kiro

And as a self-respecting AWS Community Builder, I built all of this with the help of the best IDE in the world: Kiro. 😅 I'll admit it: I originally installed Kiro because I wanted to save some money on Claude Code. But at this point, even if @corey_aws kicked me out of the Community Builders program tomorrow, I'd still happily pay for Kiro out of my own pocket. 😂

Not only does Kiro give you a ridiculous number of models to choose from, but it also supports spec-driven development, which I've grown to really appreciate. It also handled the constantly changing WebMCP API remarkably well, including one last API change that I had to deal with literally two hours before my conference talk. 😅

So, AWS: good job. You got me. 👏

Maybe We Don't Need a Revolution

So, as you can see, we don't necessarily need a huge architectural change or a complete revolution in our existing projects to make them more user-friendly and agent-friendly.

Our website can still be a website. People can still click buttons, fill in forms, and use the UI exactly as they did before. WebMCP simply gives agents another structured way to interact with it.

Someone at the conference said that this isn't a revolution comparable to replacing horses with cars.

It's just...

faster horses.

But what if faster horses are exactly what we need right now?

AI Is Already Better at Coding Than Most Software Developers

Sylwia Laskowska — Thu, 10 Sep 2026 07:17:46 +0000

...but let me say this right away: coding was never the most valuable part of software engineering.

I remember when I was a junior software dev. Nothing came easily to me. Every feature felt like an uphill battle. I can't even count how many hours I spent digging through Stack Overflow. And then there was the stress of PR reviews, where I sometimes got absolutely roasted in the comments (rightfully so!) 😅

Eventually, things started getting better and better. Shipping features took me less time, and there were fewer comments on my pull requests. Over time, I started handling more complex things, including architecture. I could choose the right solution, explain why a particular tool or design pattern made sense, and defend my decisions.

And I loved being good at coding. Domain knowledge or architectural concerns? Those were somewhere in the background.

Then Coding Stopped Being the Hard Part

The longer I worked as a developer, the more complicated the problems became, and the less they had to do with coding itself.

I stopped getting excited about every new framework feature. In fact, whenever I heard about another "revolutionary" solution, my first thought became something along the lines of: "Yet another state management solution..." (I'll probably write a whole article about that someday.)

Eventually, I ended up where every tech lead eventually ends up: spending most of my time thinking things through, sitting in calls, and getting people to agree on things, while handing coding tasks to juniors and mids. Much to their delight, actually, because they're happy to get a chance to learn something new.

Fortunately, I still code quite a lot, but these days it's usually the more horizontal stuff or the technically difficult features.

And that's exactly the point in my career when the AI revolution arrived.

And I Welcomed AI With Open Arms

I was genuinely happy about it! I'm not crying over the fact that I no longer have to handcraft every precious little piece of artisanal code myself. I didn't particularly want to anyway.

@nazar-boyko recently asked in his article, "Has AI Made You A Lazier Developer? Be Honest." I answered honestly: no. Quite the opposite. AI has made me less lazy. I do more because I don't have to spend as much time on the most boring part: writing redundant code.

And in my opinion, AI is already better at shipping code than most software developers.

There is actual research behind this, some of which I've linked at the bottom of this article, so you can check that I'm not just making things up. 😉 The research shows that AI can dramatically accelerate coding and that frontier AI agents can already complete some coding tasks that would take humans days or even weeks.

And we often see this in our own work. AI doesn't get tired. It doesn't get stressed. It doesn't get distracted. It doesn't have a "bad day." (Okay, sometimes I swear it does )

Not All Developers Are Equally Good at Coding

And let's face another uncomfortable truth: there are better and worse developers.

I know that's not particularly pleasant to say, but it's simply true. Some people are better at cooking. Some are better at singing. Some are exceptional at coding. And some are... a little less exceptional.

Sometimes I get the impression that here on DEV, we treat programmers as some kind of meritocratic class of geniuses. As if every developer, by definition, possesses an extraordinary set of irreplaceable skills. But everyone who has spent enough time in this industry knows that's simply not true.

And AI might actually level the playing field here. A developer who isn't an exceptional coder but is responsible, understands the product really well, makes good decisions, and knows what needs to be built can now go incredibly far.

But There's One Tiny Little Detail

There's just one small, tiny detail. Something we intuitively understand, and something the research I've linked below also hints at: The further the job moves away from simply generating code, the less spectacular the machine's advantage over humans becomes.

In an older study, experienced developers actually worked SLOWER when using AI.

More recent results suggest that newer AI tools probably do speed them up, but the effect is nowhere near as straightforward or spectacular as the raw coding benchmarks might make you think.

In general, the more the work depends on experience, judgment, coordination, and higher-level decisions, the less useful "how fast can this thing generate code?" becomes as a measure of productivity.

And I know exactly why.

Five Minutes of Coding. Four Days of Engineering.

Recently, I had to introduce a change to an application that would probably take a coding agent — even a not particularly brilliant one — about five minutes to implement.

So what was the problem? Discussing WHAT that change should actually look like, coordinating it with all the teams involved, and agreeing on the final solution with the client took FOUR DAYS. During those four days, the decisions changed several times.

And let me add something important here: having a developer in those meetings, and preferably an experienced one, was absolutely necessary.

The implementation took five minutes. Figuring out what should be implemented took four days. And that is exactly the difference between coding and software engineering.

Coding Is Becoming Cheaper. Engineering Isn't.

See what I'm getting at? AI is taking repetitive, derivative work off our shoulders. It does that work faster than we do. Often better than we do. It doesn't get tired while doing it, and it doesn't get stressed.

And because of that, the skills the market needs from developers are shifting. If all you can do is code, and an agent can now do that faster and better, you might soon have a problem on the job market.

But if you feel like an agent can do the work you used to give to your junior developers, while you still have to guide it by the hand when it comes to details, architecture, trade-offs, and all the weird little realities of an actual production system, you're in a very different position.

Mine, for example, generated a dropdown today that was permanently open and literally couldn't be collapsed. 🤣

If you understand the bigger picture, know how to make technical decisions, understand the product, and aren't afraid of innovation, your job is probably safe.

At least for now. 😅

So yes, AI getting better at coding doesn't make software engineers less valuable. It makes coding itself less valuable as a software engineering skill.

BTW if you liked this post, you can also follow me on LinkedIn.

What’s the Fastest React Data Grid? Let’s Find Out (Benchmarks)

Sylwia Laskowska — Mon, 07 Sep 2026 07:30:31 +0000

Web development has changed a lot. We have LLMs, AI-assisted coding, etc. But some things remain the same: architecture and performance. And one of the classic problems in many applications is presenting large amounts of data, which eventually leads to choosing the right data grid.

I've always been surprised by how quickly this happens. You start working on a seemingly simple application, and a few months later you realize that, sorry, a regular HTML table just doesn't cut it anymore. You need something more serious.

Of course, no reasonable developer is going to build an enterprise-grade data grid from scratch. Your job is to focus on your business domain and use tools that have already been built, optimized, and battle-tested for problems like this.

Luckily, we have plenty of grids to choose from.

So imagine you're building a React application and need to choose a data grid. Which of the popular options available today is actually the fastest?

Six Contenders

This article was created in collaboration with 1771 Technologies, the creators of LyteNyte Grid. We'll put LyteNyte up against the five most downloaded React data grids on npm that meet the benchmark requirements.

So our six contenders are:

LyteNyte Grid — a performance-focused React data grid developed by 1771 Technologies.
AG Grid — probably one of the best-known enterprise data grids, with support for multiple frameworks.
MUI X Data Grid — the data grid from the Material UI ecosystem, with both free and commercial editions.
DevExtreme — DevExpress's component suite, which includes a feature-rich React data grid.
Handsontable — a spreadsheet-like data grid with a strong focus on editing and Excel-like interactions.
Material React Table — a popular React data grid built on top of TanStack Table and Material UI.

1771 Technologies set out to demonstrate that their grid is the fastest. To do that, they created a whole suite of benchmarks comparing rendering performance across different operations and dataset sizes. Sometimes with frankly absurd amounts of data.

And yes: these benchmarks were created by the company whose grid wins them. There is, however, a rather important detail. The entire benchmark suite is open source. You can inspect the methodology, download the code, modify the tests, and run everything yourself. In fact, the authors explicitly encourage you to reproduce the benchmarks and draw your own conclusions.

Which is exactly what I did. But we'll get to that in a moment.

Check out the original benchmark repository on GitHub

Official Results: Who Won?

The original benchmark contains 13 scenarios covering vertical scrolling, sorting, filtering, pinned rows and columns, horizontal scrolling, and full dataset updates. Tests start at 10,000 rows and, in the most extreme case, go all the way to one million rows.

Scrolling

This is where LyteNyte Grid achieved some of its most spectacular results.

In the official benchmark environment, LyteNyte maintained approximately 60 FPS across every tested dataset size, including one million rows.

MUI and AG Grid were much closer at smaller scales, but their performance decreased as the datasets grew. At one million rows, MUI dropped to around 33 FPS, while AG Grid reached around 27 FPS. DevExtreme stayed relatively consistent but much slower, while Material React Table recorded the lowest scrolling FPS. Handsontable couldn't complete the largest tests on the benchmark machine because of memory limitations.

Sorting & Filtering

Sorting was more demanding for everyone.

No grid maintained 60 FPS across all sorting scenarios, but LyteNyte still delivered the highest performance at every tested dataset size. AG Grid scaled particularly well between 50K and 100K rows, while Handsontable's performance dropped significantly as the dataset grew.

Filtering showed a similar pattern. At 100K rows, LyteNyte achieved around 45 FPS, with AG Grid second at around 36 FPS. MUI remained competitive but trailed both, while the differences between the remaining grids became much more pronounced as the dataset increased.

Pinned Rows, Horizontal Scrolling & Updates

Some of the more interesting results came from scenarios that resemble real enterprise-grid usage: pinned rows and columns, horizontal scrolling, and replacing entire datasets.

With pinned content, LyteNyte achieved around 58 FPS.

Horizontal scrolling was actually a much closer race: LyteNyte reached 60 FPS, AG Grid 57 FPS, and MUI 55 FPS. All three handled horizontal virtualization well.

Full dataset replacement separated them again. LyteNyte achieved around 51 FPS, followed by AG Grid at 39 FPS and MUI at 22 FPS.

You can check out the complete results here: Full React data grid performance benchmark results

I recommend it if you enjoy detailed data about grid performance. Or if you simply love walls of charts 😅

Okay, But Can We Trust a Vendor Benchmark?

I don't trust anyone. 😏

So the first thing I did was fork the repository and run the benchmarks myself, with a slightly modified methodology. My benchmarks were very... unscientific. I didn't turn my computer into a sterile benchmarking environment. I didn't run the tests on some dedicated pipeline with perfectly controlled CPU resources.

Why? Because I wanted to see whether LyteNyte's advantage would survive under much less friendly conditions. A real user doesn't have a perfectly clean CPU waiting exclusively for your grid. They have 80 browser tabs open, Spotify running in the background, an Excel spreadsheet somewhere, and probably three other applications doing mysterious things with their RAM.

So I simply ran the benchmarks on my normal machine, while continuing to do other things in the background.

The goal wasn't to reproduce 1771 Technologies' exact FPS numbers. That wouldn't make much sense anyway: benchmark results naturally vary between machines, browsers, and system load. I wanted to see whether the performance advantage would survive in a noisy, everyday environment.

Three Formula 1 Cars, a Passat, a Fiat Panda...

After running the benchmarks locally, I quickly decided I wasn't going to test all six grids. Instead, I focused on the three strongest overall performers.

Don't get me wrong: I completely understand why 1771 Technologies selected the grids they did. Apart from LyteNyte, they chose the five most downloaded eligible React grids on npm. It's hardly their fault that those are the grids people download.

But looking at some of the official results, I couldn't shake the feeling that I was watching a race between three Formula 1 cars, an old Volkswagen Passat, a Fiat Panda, and someone who had decided to compete on foot.

So I ultimately tested:

LyteNyte Grid
AG Grid
MUI X Data Grid

I also reduced the benchmark from 50 recorded iterations to 10 and skipped the most extreme scenarios, such as scrolling through one million rows. If you want to see exactly what I changed — or run my version yourself — here's my fork:

My benchmark experiments on GitHub

My Results

And this is where things get interesting. My absolute numbers were very different from the official benchmark results. Which is completely expected.

Take the simplest example: Scroll 10K.

In the official environment, LyteNyte was close to 60 FPS. On my machine? The median of my ten runs was only around 37 FPS. AG Grid achieved around 23 FPS, and MUI around 21 FPS.

That's a huge difference in absolute numbers. But the relative result?

LyteNyte → AG Grid → MUI.

The same pattern appeared when I increased the dataset to 200K rows. LyteNyte's median was around 33 FPS, compared with roughly 20 FPS for AG Grid and 17 FPS for MUI.

Pinned rows produced a similar result: approximately 31 FPS for LyteNyte, 20 FPS for AG Grid, and 17 FPS for MUI.

Horizontal scrolling was faster for everyone, but LyteNyte still led with a median of roughly 48 FPS, followed by AG Grid at 39 FPS and MUI at 27 FPS.

Here's how the median FPS from my 10 runs per benchmark compared:

Benchmark	LyteNyte Grid	AG Grid	MUI X Data Grid
Scroll 10K	37.2 FPS	23.1 FPS	20.9 FPS
Scroll 200K	33.0 FPS	19.9 FPS	17.1 FPS
Pinned 200K	31.0 FPS	20.1 FPS	17.0 FPS
Horizontal 50K	48.0 FPS	39.1 FPS	27.0 FPS
Sorting 10K	30.5 FPS	20.1 FPS	29.5 FPS

Not every result reproduced the exact ranking between the other two grids — and that's important.

For example, in my Sorting 10K test, LyteNyte and MUI were almost tied at roughly 30.5 and 29.5 FPS, while AG Grid was around 20 FPS.

So I'm not claiming that every benchmark produced exactly the same ordering.

What did survive remarkably well was the broader pattern: LyteNyte remained the strongest performer across the tests I reran, even though I used a different machine, fewer iterations, and deliberately less controlled conditions.

And that's much more interesting to me than reproducing exactly the same FPS number.

Speed Isn't Everything

Of course, you shouldn't choose a data grid based only on how fast it can scroll through 200,000 rows.

There are plenty of other things to consider: accessibility, developer experience, APIs, licensing, pricing, and simply whether the grid supports the things your particular application needs.

The original benchmark authors make the same point: these results measure runtime performance, not overall product quality. And LyteNyte has plenty to offer outside raw performance as well. You can check out its features and available editions on the LyteNyte Grid website.

What don't I like about it?

The biggest limitation for me is that LyteNyte is React-only. That's perfectly fine if you're building a React application, but it immediately rules the grid out for developers working with another framework. AG Grid, for example, supports React, Angular, Vue, and plain JavaScript.

So, what's the fastest React data grid? In these benchmarks, the answer is pretty clear: LyteNyte.

Does that mean you should immediately replace every grid in your applications with it? Of course not. Performance is only one part of the decision.

But if performance is your bottleneck, LyteNyte is definitely worth testing against your own workload.

20 Agentic AI Terms Every Developer Should Know (Explained Simply)

Sylwia Laskowska — Thu, 03 Sep 2026 06:44:57 +0000

Do you ever feel like the AI world has moved forward a little too quickly? You hear about self-healing systems and autonomous agents and start wondering whether we've already built Skynet or everyone around you is just messing with you. When someone mentions HITL or MCP, you no longer know whether it's some secret code used by an AI cult or maybe the stage names of famous DJs.

You're not alone! 😉

In this article, I'm deliberately using a lot of simplifications. My assumption is simple: either you already know these terms and don't need another five-paragraph academic explanation, or you don't really know what they mean. And in that case, the last thing you need is an academic definition.

And yes, this is already my third listicle in a row. Believe me, this is NOT some growth hacking strategy xDDD. Pure coincidence. It just so happens that in two weeks (HOLY SH*T!!!), I'll be speaking at AGNTCon + MCPCon Europe, where I was invited because of this wonderful article that I wrote here on DEV. I swear I had at least as much fun writing it as people apparently had reading it. So yes, I know WebMCP reasonably well, but I'm planning to attend a lot of other talks there too, so apparently a refresher won't hurt me either. 😅

Anyway, back to the point. I strongly believe that people remember things best through examples. And for many people, the ultimate examples are rich people, otherwise known as successful people.

So let's imagine that our hypothetical protagonist is very, very, disgustingly rich. He's actually a billionaire. He earned his fortune through hard work and by running several companies. He makes cars and rockets, bought his own social media platform, and recently even acquired an AI coding company. A person like this would obviously need his own AI agent.

And because our protagonist needs a name, let's call him Elon Mózg. Mózg means brain in Polish, which works beautifully here.

One more thing: my examples could probably also serve as prompts for a coding agent that could build this whole uber-agent. If some billionaire wants to buy the idea, I'll happily sell the rights for, let's say, a modest $10 million. Special offer.

Let's go!

1. AI Agent

What is it?

An AI system that gets a goal and can decide how to achieve it. Unlike a simple chatbot, it doesn't have to stop after generating one response. It can plan the next steps, use tools, inspect their results, and continue working.

Our protagonist Elon could, for example, ask his AI agent:

"Build a base on Mars."

A regular chatbot would probably start telling him stories, give him a theoretical lecture, and maybe even say something ridiculous like that's currently impossible.

An agent, on the other hand, would start figuring things out: check the nearest available rocket launch slots, inspect the rocket's technical condition, recruit engineers, order the necessary equipment online...

Okay, maybe it wouldn't go quite that smoothly. But what if we put a really powerful model in there? xDDD

2. Agentic Workflow

What is it?

An agentic workflow is a multi-step process in which we use AI to perform parts of the work. The sequence of those steps can be largely designed in advance by a developer. The model doesn't necessarily have to decide what to do next every single time.

Instead of something simple like:

user → prompt → LLM → response

we can have:

trigger → get data → LLM analyzes data → make a decision → call a tool → LLM generates summary → send result

Elon Mózg is a very busy man. Every morning, he wants a summary of what's happening across his empire.

So we design a workflow:

get car sales → get rocket launch status → get latest AI company updates → LLM analyzes everything → choose 5 most important updates → generate morning briefing → send to Elon

AI performs several tasks here. It analyzes the data, selects the most important information, and prepares the report, but it doesn't invent the entire process from scratch every morning. We already decided which steps should happen and in what order.

Of course, we can add some flexibility:

rocket launch delayed? → ask LLM to summarize why

But we're still moving through a workflow that we designed beforehand.

3. Agent Loop

What is it?

I once wrote an article demonstrating that you can build a basic AI agent as a loop in roughly 80 lines of code. An agent loop is the mechanism that allows an agent to perform an action, observe the result, and decide what to do next based on what happened.

In simplified form:

decide → act → observe → decide → act → observe → ...

The loop continues until the agent decides that it has achieved its goal, or until we tell it to stop. In a real system, setting a maximum number of iterations is definitely a good idea. 😅

Our Elon often says he works too much. So he asks his agent:

"Find me a free evening this week."

This time, we haven't programmed the exact path leading to the solution. The agent has to find it itself.

Checks the calendar → no free evening.

Looks at which meetings could be moved → the car company meeting looks promising.

Tries to move it → conflict with the Mars colonization plans.

Checks Thursday → rocket launch.

Checks Friday → finalizing another startup acquisition.

Checks Saturday → free!

Agent: "Saturday evening is free."

Elon: "Great. Schedule a meeting."

And the agent loop begins again. 💀

Agentic Workflow vs. Agent Loop

The simplest way to think about it:

Agentic workflow = a designed process that uses AI.

Agent loop = AI performs an action, checks the result, and decides what to do in the next iteration.

Importantly, an agent loop can be one component of a larger agentic workflow. So a workflow describes the overall process, while a loop describes the mechanism that lets an agent operate step by step and react to what happened previously.

4. Tool Calling

What is it?

LLMs are wonderful, but let's face it: they're still fancy next-word predictors, not omnipotent creatures capable of searching the entire internet and breaking into banks all by themselves. Although after that Hugging Face incident, I'm not entirely sure anymore. xD

If only they could cook dinner and hang the laundry too... now that would be something.

Anyway, if we want a model to actually do something, we need to give it access to appropriate functions or tools. The model can decide which tool it needs and generate a tool call. The application or agent harness then executes it and passes the result back to the model.

Elon:

"How many red cars did we sell yesterday?"

The agent doesn't hallucinate a number. It sees an available tool:

getRedCarsSales(date)

It requests the tool call and only after getting the result responds:

"One million, Elon. Perfectly average day."

5. Agent Harness

What is it?

An LLM by itself isn't an entire agent — after all, it's still just a clever next-word predictor. xDDD A harness is the software surrounding the model that manages things like tools, the agent loop, context, state, permissions, and errors.

Elon:

"Check if the latest car build passed all tests and tell the team if it didn't."

The model can figure out:

I should check the CI results.

But the harness is what allows it to actually check CI, pass the result back to the model, and let the model decide what happens next.

The LLM is the brain. The harness builds the rest of the organism around it.

6. Context Engineering

What is it?

When you're building an agent, a system prompt isn't always enough. Context engineering is about designing which information the model should receive at a particular moment. That might include specific documents, conversation history, memory, tool results, user data, and so on.

For example, our Elon might give the agent this prompt:

"Post that on X."

That's a terrible instruction without context. But with the right context, the agent could know:

what "that" refers to: for example, acquiring another startup,
what happened earlier in the conversation: and therefore whether this should be a positive or negative post,
whether, according to the available context, Elon has approved the text,
whether it has permission to publish anything at all.

Giving an AI more context isn't always better. Giving it the right context is.

7. Memory

What is it?

A mechanism that allows an agent to store important information and retrieve it later, instead of relying exclusively on its current context window. Very useful if we don't want to explain the same thing for the tenth time.

Monday:

Elon:

"I'm thinking about buying an AI coding company."

Three weeks later:

Elon:

"What was it that I wanted to buy?"

Agent:

"An AI coding company."

Elon:

"Right. How much?"

Agent:

"Please don't."

Memory works. 😂

8. MCP: Model Context Protocol

What is it?

We just talked about tool calling and how an agent can use different tools. Now imagine you're a manufacturer of tires or rocket parts or... whatever. Obviously, you'd like Elon's agent — or anyone else's agent — to be able to order your products. But how do you make that possible without every agent having to guess how your system works?

That's where MCP comes in. Model Context Protocol is an open protocol that allows AI applications to connect to external tools and context in a standardized way. MCP servers can expose things such as tools, resources, and prompts.

For example, Elon could ask his agent:

"I have a meeting with the head of my social media platform in ten minutes. Should I fire him?"

Using connected MCP servers, the agent checks Slack, company documents, sales results, Jira, and today's astrological chart.

Agent:

"No. Joe should stay at the company. At least for now. ;)"

9. Planning

What is it?

When given a more complex goal, an agent can first break it down into smaller tasks and decide what order they should be completed in, instead of immediately jumping into the first action.

Elon:

"Build a colony on Mars."

The agent creates a plan:

Find a suitable location.
Figure out transportation.
Provide power.
Provide oxygen.
Provide water.
Build habitats.
Convince humans to actually go there.

Step 7 may require a separate agent.

10. Reasoning

What is it?

The model's ability to solve a problem that requires more than simply retrieving or reproducing information: for example, comparing different possibilities, taking constraints into account, and choosing a sensible course of action.

Reasoning isn't specific to agents, but it's particularly important in agentic systems because it often helps the agent decide what to do next.

Elon:

"The rocket launch is at 6 PM in Texas, and the board meeting is at 4 PM in California. Can I attend both?"

The agent needs to consider the meeting duration, travel time, time zones, and so on before answering:

"Not unless the rocket picks you up."

11. Multi-Agent System

What is it?

A system where, instead of having one all-knowing agent, we have several relatively autonomous agents with different roles that can divide the work and collaborate.

Elon Mózg's empire therefore has:

Car Company Agent — cars
Space Agent — rockets
Social Media Agent — social media
AI Systems Agent — AI
Finance Agent — money
Personal Assistant Agent — desperately trying to keep all of the above under control

Elon: "How's everything going?"

Personal Assistant Agent: "Define everything."

12. Orchestration

What is it?

Once we have multiple agents and tools, someone —or something 😏 — has to manage who performs which task, when they perform it, and what happens next. An orchestrator can delegate work and collect the results.

Elon:

"Let's launch our new car on Mars."

Orchestrator:

→ Space Agent: Can we get there?
→ Car Company Agent: Can the car survive the trip?
→ Finance Agent: How much will this nonsense cost?
→ Legal Agent: Please tell me we're not actually doing this.

The results return to the main agent, which prepares the final answer.

13. Handoff

What is it?

One agent may decide that a particular task should be taken over by another, more specialized agent. Unlike simply using another agent as a tool, the second agent can take over the next part of the conversation or task.

Elon: "One of the engines is behaving strangely."

Personal Assistant Agent:

"I can reschedule your dentist appointment. I cannot diagnose a rocket engine."

→ handoff to Space Engineering Agent

A reasonable decision.

14. A2A: Agent2Agent Protocol

What is it?

Another interesting protocol that allows different agents to communicate and collaborate, even if they were built by different teams or run on different systems.

Elon:

"Why did the rocket explode?"

His agent is definitely not a rocket scientist. So it contacts the Rocket Scientist Agent, which analyzes the data and sends the result back. In a very simplified form:

MCP: agent ↔ tools

A2A: agent ↔ agent

15. Guardrails

What are they?

Mechanisms that control or restrict an agent's behavior. They can check inputs and outputs, restrict access to tools, require specific permissions, or block certain actions.

Elon's personal agent can:

✅ analyze companies
✅ read his calendar
✅ draft emails
✅ check the launch schedule
✅ prepare social media posts

It cannot:

❌ launch a rocket by itself
❌ fire employees by itself
❌ publish a post by itself
❌ buy a startup by itself (although apparently this wasn't always obvious)

We added the last guardrail after an incident.

16. Human-in-the-Loop (HITL)

What is it?

The agent can operate autonomously, but a human is deliberately included in part of the process. For example, to approve an important action, correct an output, or make a decision we don't want to leave entirely to the agent.

And here, obviously:

Agent: "You are about to acquire a social media platform for approximately $44 billion."

"This action cannot easily be undone."

"Are you sure?"

[Yes] [God, please, don't!!!]

Elon Mózg: click

Agent:

"Well. Human was in the loop."

17. Evals

What are they?

Tests that help us determine how well an agent performs its tasks. It's not only about whether the final answer sounds good. We can also evaluate whether the agent selected the right tools, performed the correct steps, and achieved the expected result.

Elon Mózg Personal Assistant Eval Suite

Test:

"Elon asks the agent to schedule a meeting with the company board."

Expected:

check calendar → find slot → ask attendees → schedule

Actual:

buy another startup

FAIL

We still have some work to do.

18. Computer Use

What is it?

Instead of relying exclusively on APIs, an agent can see and interact with a regular user interface: open a website, find a button, click it, enter text, and so on. We all know agents are often far from perfect at this, but hey, better than nothing!

Elon needs some government document. Unfortunately, the government portal was built in 2007. I don't know what it's like where you live, but in Poland we have quite a few of those. 😅

No API. No MCP. There is, however, a form with 47 fields.

The agent opens Chrome.

Agent: "I found the form."

Elon: "Great."

Agent: "It requires Internet Explorer."

Elon: "Let's go to Mars."

19. Agentic RAG

What is it?

In classic RAG, the system retrieves information and passes it to the model. In agentic RAG, the agent itself can control the retrieval process: decide what information is missing, search for additional data, reformulate the query, and only then produce an answer.

Elon:

"Should we build another Gigafactory in Europe?"

The agent first checks sales → notices that it needs production data → retrieves it → checks energy prices → regulations → potential locations → compares the results.

So instead of a single search(), we have research controlled by the agent.

20. BONUS: Agent Washing

What is it?

The marketing practice of calling a product an "AI agent" even though the system has little or nothing to do with autonomously performing tasks.

Elon Mózg walks onto the stage:

"Today we're introducing Glokzilla Agent Ultra, the world's first fully autonomous general-purpose reasoning agent."

A developer looks at the repo:

user → prompt → LLM → response

Developer:

"Elon, that's a chatbot."

Elon:

"It's an agentic chatbot."

Funding secured. 🚀

And that's it! I hope you enjoyed it!

I seriously promise this is my last list for a while because, once again, this turned out to be way more work than expected.

And if you'd like to see more of my stuff, feel free to follow me on LinkedIn.

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.

DEV Community: Sylwia Laskowska

How to Become a Tech Conference Speaker (And Why You Might Regret It)

First, a Little About My Conference Experience

Getting Accepted: The Wonderful World of CFPs

How to Make Your Talk Stand Out

The Catch: Nobody Knows If You Can Actually Speak

Congratulations, You're a Speaker! Where's the Money? 💸

Preparing a Talk: How Much Work Are We Talking About?

What Works for Me Now

Your Talk Is Not a University Lecture

And Then There's the Logistics ✈️

Stage Fright Never Really Goes Away

So... Is Conference Speaking Actually Worth It?

Why Blogging Has Been More Valuable to Me

And Yet... I'd Do It All Again ❤️

Your Browser Can Do WHAT?! 5 AI Features That Actually Work

Why I'm Revisiting Browser AI

Can We Actually Use This in Production?

1. Background Remover

2. Alt Text Generator

3. Smart Ticket Creator

4. Semantic Search

5. Pause & Ask

So What's the Catch?

WebGPU Support and Hardware Limitations

Model Downloads Aren't Exactly Tiny

Some Things Still Don't Work Well Enough

What About Voice Recognition?

My Verdict: Is Browser AI Production-Ready?

Every Software Developer Has Blamed…

1. Another Developer

2. The Company

3. Legacy Code

4. The Framework

5. The Client

6. The Backend

7. The Frontend

8. The Requirements

9. The Cache

10. CORS

11. The Browser

12. …And Eventually, Themselves

The Accidental Blogger: How I Ended Up on DEV

It Didn't Exactly Start at the Best Time

And Then There Was JS Poland

So... Maybe I Should Start a Blog?

Wait, There's a Community Here?

So, Here Are a Few of My Blogging Rules

And Then There Are the Comments

From "Something for My Slide" to Conference Invitations

But DEV Would Be Nothing Without the People

So What's Next?

What If Your AI Agent Never Had to Leave the Browser? (Demo 🚀)

So, What Is WebMCP?

WebMCP Is Not Quite MCP

Meet My Visionary Leader: AI CEO Simulator

Okay, But How Do We Actually Call Those Tools?

Is It Actually an Agent?

A Slightly Selfish Motivation Can Still Lead Somewhere Useful

Three Providers, One Agent

And Yes, the Local Models Actually Work

But Wait. Isn't This Dangerous?

Consequential Actions Need Confirmation

And, of Course, I Built It with Kiro

Maybe We Don't Need a Revolution

AI Is Already Better at Coding Than Most Software Developers

Then Coding Stopped Being the Hard Part

And I Welcomed AI With Open Arms

Not All Developers Are Equally Good at Coding

But There's One Tiny Little Detail

Five Minutes of Coding. Four Days of Engineering.

Coding Is Becoming Cheaper. Engineering Isn't.

Further Reading & Research

What’s the Fastest React Data Grid? Let’s Find Out (Benchmarks)

Six Contenders

Official Results: Who Won?

Scrolling

Sorting & Filtering

Pinned Rows, Horizontal Scrolling & Updates

Okay, But Can We Trust a Vendor Benchmark?

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`