DEV Community: Sylwia Laskowska

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.

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

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

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

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

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

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

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

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

So let me take you back to 2017.

Welcome Back to 2017

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

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

export class

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

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

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

Future-proofing matters.

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

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

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

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

The Problem With Angular's Early i18n

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

<h1 i18n>Hello</h1>

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

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

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

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

Elegant. Simple. Maybe fifteen lines of code.

The Patch Update

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

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

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

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

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

Time for Some Digital Detective Work

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

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

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

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

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

Nope. Everything is exactly where it should be.

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

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

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

Solving the Mystery

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

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

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

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

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

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

The Fix

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

Its name?

fi18n.

I know. Peak engineering creativity. 😂

Were We Terrible Engineers?

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

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

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

And eventually... it did.

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

Why This Bug?

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

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

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

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

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

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

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

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

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

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

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

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

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

...and suddenly everything falls apart.

Just like our little i18n attribute did.

The Real Lesson

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

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

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

BUT!

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

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

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

The Dirty Secret Behind AI Agents (Demo 🚀)

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

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

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

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

Do We Really Need a Framework?

Let's get to the point.

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

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

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

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

Here's the repository:

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

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

Meet Steve

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

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

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

Or when you have empty diff:

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

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

"An Agent Is Just a While Loop"

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

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

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

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

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

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

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

How Does the Agent Actually Work?

It's much simpler than you might think.

Step 1: Send the prompt and available tools

We send two things to the model:

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

Here's what the request looks like:

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

Step 2: Wait for the model's response

The model can respond in one of three ways:

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

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

For example, we might receive:

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

Step 3: Execute the tool locally

Now it's our application's turn.

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

The tools available in this demo are:

getDiff
getFile
listFiles

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

Step 4: Repeat until the model is done

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

There's one more important detail, though.

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

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

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

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

What's next?

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

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

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

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

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

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

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

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

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

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

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

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

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

Epilogue: An agent written by another agent

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

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

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

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

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

Final Thoughts

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

So...

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

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

8 Things Developers Confidently Explain After Watching One YouTube Video

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. LLMs are just autocomplete

Or, if you prefer another popular version:

"They're just stochastic parrots."

"They're not creative."

"They don't really understand anything."

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

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

But then again... neither do most humans.

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

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

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

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

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

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

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

4. AI agents are just a while loop

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

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

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

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

5. WebAssembly is always faster

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

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

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

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

6. Unit tests are our golden ticket

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

Or... maybe not.

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

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

7. Let's just add RAG

Yeees...

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

8. Microservices / Microfrontends are the only good architecture

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

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

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

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

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

What's Next for AI?

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

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

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

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

Four years that changed everything

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

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

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

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

Where do developers fit in?

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

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

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

Changes, changes...

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

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

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

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

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

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

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

So... what happens next?

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

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

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

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

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

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

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

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

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

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

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

But both the ecosystem and the ECMAScript standard keep evolving.

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

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

So, what do we get in ECMAScript 2026?

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

1. Map.prototype.getOrInsert() / Upsert

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

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

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

const opinions = new Map();

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

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

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

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

With ES2026, things become much nicer:

const opinions = new Map();

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

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

console.log(opinions);

We also get a computed version:

const opinions = new Map();

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

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

2. Iterator.concat()

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

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

What is an iterator?

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

For example:

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

const iterator = posts.values();

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

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

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

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

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

const iterator = endlessHotTakes();

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

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

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

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

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

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

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

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

Now we can combine them elegantly:

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

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

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

3. Array.fromAsync()

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

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

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

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

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

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

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

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

const takes = await Array.fromAsync(opinions);

console.log(takes);

And you can even map values immediately:

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

console.log(comments);

Pretty convenient.

4. Math.sumPrecise()

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

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

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

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

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

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

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

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

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

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

5. Error.isError()

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

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

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

  console.log(
    e instanceof Error
  );
}

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

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

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

console.log(
  strangeThing instanceof Error
);

// false

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

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

// true

Simple and beautiful.

6. Base64 for Uint8Array

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

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

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

btoa("JavaScript was a mistake.");

When dealing with binary data, things quickly became ugly:

const bytes = new Uint8Array(buffer);

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

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

Now we can simply write:

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

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

const base64 =
  bytes.toBase64();

console.log(base64);

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

7. JSON.parse Source Text Access

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

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

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

const data = JSON.parse(json);

console.log(data.followers);

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

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

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

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

    return value;
  }
);

console.log(data.followers);

No more accidental corruption of giant numbers.

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

Bonus: The Great Absentees

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

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

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

Temporal API

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

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

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

console.log(date);

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

Or perhaps you've experienced everyone's favorite:

const today = new Date();

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

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

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

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

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

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

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

Instead of:

const now = new Date();

we get things like:

const now = Temporal.Now.instant();

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

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

And suddenly everything becomes much more explicit.

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

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

Explicit Resource Management (`using`)

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

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

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

const webinar =
  createAIAgentsWebinar();

try {

  webinar.start();

}
finally {

  webinar.close();

}

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

With using, cleanup happens automatically when leaving the scope:

using webinar =
  createAIAgentsWebinar();

webinar.start();

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

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

Uff...

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

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

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

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

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

DEV Community: Sylwia Laskowska

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?

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

My Results

Speed Isn't Everything

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

1. AI Agent

2. Agentic Workflow

3. Agent Loop

Agentic Workflow vs. Agent Loop

4. Tool Calling

5. Agent Harness

6. Context Engineering

7. Memory

8. MCP: Model Context Protocol

9. Planning

10. Reasoning

11. Multi-Agent System

12. Orchestration

13. Handoff

14. A2A: Agent2Agent Protocol

15. Guardrails

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

17. Evals

18. Computer Use

19. Agentic RAG

20. BONUS: Agent Washing

10 Git Commands You’ll Wish You Knew Earlier

1. & 2. git merge vs git rebase

Merge

Rebase

And what about conflicts?

3. git commit --amend

4. git push --force-with-lease

5. git rebase -i

pick

reword

edit

squash

fixup

drop

6. git stash

git stash list

git stash show

git stash apply

git stash pop

7. git cherry-pick

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

git reset --soft

git reset --mixed

git reset --hard

9. git reflog

10. git revert

7 Productivity Tips That Sound Wrong (But Actually Work)

1. Do Less Than You Could

2. Don't Work on Weekends

3. Plan Your Week in Advance

4. Set Embarrassingly Achievable Goals

5. Deliver Only What You're Asked For

6. Know What “Done” Means Before You Start

7. Reply to Small Things Immediately

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

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

What Do We Actually Know So Far?

So... How Does This Watermark Actually Work?

Is Claude the Only Model Watermarking Text?

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

3. `git commit --amend`

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

5. `git rebase -i`

`pick`

`reword`

`edit`

`squash`

`fixup`

`drop`

6. `git stash`

`git stash list`

`git stash show`

`git stash apply`

`git stash pop`

7. `git cherry-pick`

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

`git reset --soft`

`git reset --mixed`

`git reset --hard`

9. `git reflog`

10. `git revert`

Explicit Resource Management (`using`)