Forem: Michal Pasierbski

Agents are the New Websites: The Evolution of the Software Engineer

Michal Pasierbski — Sat, 14 Feb 2026 09:38:02 +0000

For the last twenty years, the "Web Developer" was the protagonist of the tech industry. We mastered the DOM, wrestled with CSS frameworks, and perfected the art of the CRUD app.

But the wind has shifted.

The Era of "Too Easy"

Building a standard website has become a "solved" problem. Between low-code platforms and AI coding assistants, the barrier to entry has collapsed. If a prompt can generate a functional React component in three seconds, the value of the "builder" is no longer in the construction—it's in the architecture.

We've reached a point where the world doesn't need more pixel-pushers; it needs orchestrators.

The Market is Speaking (and it's loud)

This isn't just a hunch; it's reflected in the data. If you look at the recent analysis of engineering roles, the demand for traditional Frontend Engineers is shrinking.

As companies automate their interface layers, the "Front-end" is becoming a commodity. The premium salaries and the high-growth roles are moving "upstream." They are moving toward the systems that drive the interfaces. If your value is tied strictly to translating a Figma design into HTML/CSS, you are competing against a machine that doesn't sleep and costs pennies.

From UI to Agency

The website was a destination—a place where a human went to perform a task. The AI Agent is the evolution of that destination. Instead of a user navigating a menu to book a flight, an agent understands the intent and executes the workflow across multiple APIs.

Websites are passive containers.

Agents are active problem-solvers.

As engineers, our job is shifting from building the pages to building the brains. We are moving away from defining exactly how a button looks and toward defining how a system reasons, uses tools, and recovers from errors.

The Engineering Identity Crisis

I've felt it too. There's a comfort in the "Edit-Refresh" cycle of web dev. But as the "easy" parts of our jobs are swallowed by automation, we face a choice: stay in the shrinking space of interface implementation or evolve into Agentic Engineers.

This transition isn't just about swapping JavaScript for Python. It's a fundamental shift in how we think about:

Non-deterministic logic: Handling outputs that aren't always the same.
Tool-use: Teaching models to interact with the real world safely.
Reliability: Moving beyond "it compiles" to "it actually works."

Introducing: Practically Agents

I realized that while there are a million tutorials on how to "chat with a PDF," there is a massive gap in how to build production-grade agents. Most "Hello World" agent tutorials fail the second they hit real-world data or edge cases.

That's why I created Practically Agents. It's a resource designed for the engineer who is ready to move past the hype. We aren't just playing with prompts; we are building robust, scalable, and reliable agentic systems. It's the curriculum I needed for my own evolution to stay relevant in a changing market, and now it's here for yours.

The era of the website isn't over, but its reign as the "center of the universe" is. It's time to start building the agents that will run the world.

Originally published at https://practicallyagents.com/articles/agents-are-the-new-websites/

How to Pass Data from a Function Tool to State in ADK (Agent Development Kit)

Michal Pasierbski — Mon, 21 Apr 2025 16:16:25 +0000

What is ADK?

Google’s new ADK (Agent Development Kit) is an exciting step forward in building AI agents. Think of it as a framework for composing tools, states, and logic in a way that feels modular and powerful—kind of like LangChain or LangGraph, but backed by Google.

IMO it has lower learning curve than LangGraph while offering the same functionality, better local development tooling and straight forward deployment options to Agent Engine or Cloud Run (for details see docs).

What is state?

In ADK state is a mutable object shared between agents and tools. It holds all the data that flows through your agent’s workflow—like user inputs, intermediate results, or tool outputs.

How to set state from function tool?

It’s not clearly documented in the official docs, but thankfully the source code is well-structured and readable.

Source: https://github.com/google/adk-python/blob/1664b455627c01194a804b880d31bd2602e1a447/src/google/adk/tools/function_tool.py#L59

You can get hold of ToolContext object (which holds reference to the state object) by adding an argument named tool_context to your tool function signature - ADK will inject the value. For example:

from google.adk.agents import LlmAgent
from .prompt import system_prompt
from google.adk.tools import ToolContext

def save_prd(prd: str, tool_context: ToolContext):
    tool_context.state['prd'] = prd

agent = LlmAgent(
    name="product_owner",
    description="A product owner agent that is responsible for the product vision and strategy",
    model="gemini-2.0-flash",
    instruction=system_prompt,
    tools=[save_prd],
)

Dead simple Role-based access control in supabase

Michal Pasierbski — Tue, 22 Aug 2023 09:26:02 +0000

UPDATE: I got featured on Community Highlights!

// Detect dark theme var iframe = document.getElementById('tweet-1713963289544188065-477'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1713963289544188065&theme=dark" }

I shared this post 👇 and it gained more attention than I expected (considering my usual standards 😅). Here’s a breakdown of how everything comes together.

// Detect dark theme var iframe = document.getElementById('tweet-1693652730055680173-937'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1693652730055680173&theme=dark" }

1. Defining Roles

For a more human-friendly approach to referencing roles, you can create a custom enum type:

CREATE TYPE user_role AS ENUM ('spots_moderator', 'admin');

2. Setting Up the “user_roles” Table

The user_roles table allows us to link roles with users. To ensure the security of user_roles, enable Row-Level Security (RLS) and implement the policy:

To secure user_roles enable RLS (Row-level security) and add following policy auth.uid() = user_id

This policy grants authenticated users access to read the roles they possess.

Key points:

user_id references auth.users.id
The role is based on the user_role type (the enum type from step 1.)
RLS enables reading of roles owned by the user

3. Implementing Row-Level Security for Role-Specific Access

You can now control access to specific rows within a table, such as spot_proposals in this case, by users with particular roles. This is done by specifying the following RLS condition:

(auth.uid() IN ( SELECT user_roles.user_id
   FROM user_roles
  WHERE (user_roles.role = 'spots_moderator'::user_role)))

Key points:

user_roles has an RLS policy, allowing authenticated users to read their roles
The RLS policy on spot_proposals restricts access to specific roles, such as spots_moderator

This setup ensures a straightforward yet effective role-based access control mechanism in Supabase.

Looking for more Supabase content? Join me on Twitter for the latest updates, tutorials, and insights! Follow along to stay in the loop.

Dart: late + final = easy and safe caching

Michal Pasierbski — Sun, 08 Jan 2023 10:19:57 +0000

Let's say You have a Person class and You want to expose netWorth field.
There is a backend API to fetch it but it's pretty expensive.
Backend needs to call all associated bank APIs, convert currencies, calculate real estate values, etc.
Here's how to use new late variables feature to implement easy and safe caching.

Naive approach

We could start with super simple approach, i.e. fetch the value every time we use it.

class Person {
  Future<num> netWorth() => _fetchNetWorth();
}

// await person.netWorth()

Cache result

Instead of calling _fetchNetWorth every time we could call it only once and cache the results.

class Person {
  Future<num>? _fetchNetWorthFuture;

  Future<num> netWorth() {
    _fetchNetWorthFuture ??= _fetchNetWorth();

    return _fetchNetWorthFuture;
  }
}

// await person.netWorth()

There is an open question hanging in the air: why netWorth is Future<num> and not simply num?
We could have some initialization function that could resolve the future, right?

I'm not a fan of such initialization functions because it creates unnecesarry dependency that can quickly become unmanagable.

What if we have another field in the class that has to be fetched? We throw it in init function!

What if we need only one not the other? Should we have two init functions? Or maybe have some logic what to initialize?

Futures are cheap and I like the explicit contract that we expose. Consumer of our class knows from the get-go that this value has some cost.

Ok, now we cached the result (or rather Future of the result) so we don't make the expensive call again.
There is not much more we can do in terms of resource optimisation, but we can optimise the code a bit - we can get rid of the intermidiate _fetchNetWorthFuture variable.

late + final

With introduction of sound null-safty we got access to late keyword. late allows us to take responsibility of nullness of the value. It's like telling compiler "trust me, the value will be there when I use it".

The late modifier has some other special powers too. It may seem paradoxical, but you can use late on a field that has an initializer:
¹

Possibility to have initializer on late variables allows us to get rid of intermidiate _fetchNetWorthFuture variable.
Slapping final gives us compilte time guarantee that the variable will be assigned only once.

class Person {
  // Potentially expensive calculation.
  late final netWorth = _fetchNetWorth();
}

// await person.netWorth

This post was originally posted on my blog at stuffs.dev

https://dart.dev/null-safety/understanding-null-safety#lazy-initialization ↩

Free blog setup with GitHub and Hugo

Michal Pasierbski — Sat, 07 Jan 2023 21:34:26 +0000

I recently moved my blog from Wordpress hosted on DigitalOcean to Hugo hosted on GitHub pages. Here's how and why I did it.

Why?

Because I'm cheap and spending ~10$/month for a blog that gets close to 0 traffic and close to 0 attention from the owner hurts my onion hearth.

What's Hugo?

Hugo is a static site generator (SSG) written in Go. It's main strength is speed of generation, but I like it for other reasons:

Convention over configuration
"All you need" features out of the box
Maybe not the biggest but definitely high quality community
Easy to understand, no magic source code
Markdown 💖

Migrating content

Hugo content is written in Markdown so I had to transform it. And since my blog had at the time enormous amount of content, i.e. 2 posts, I did that manually using .

The easiest way is to simply open each blog post, inspect the source in Chrome, find the first wrapping dom node in the inspector, right click and select "Copy outerHTML". Paste result in to https://codebeautify.org/html-to-markdown and enjoy freshly baked Markdown.

If You need your old posts to appear under the same URL You can use aliases field in post frontmatter.

Hosting

GitHub distingushes 3 types of pages: personal, organization and project. Since it's a personal blog I followed the guidelines for that type. In this case GitHub requires that the repo must be named after the username, in my case https://github.com/pasierb/pasierb.
Side benefit of this naming scheme is that the repo's README becomes your profile README.

I was worried that I will need to learn GitHub Actions to run hugo build, but suprisingly once GitHub notices that the repo is a Hugo project I got predefined build configuration suggested and it works flowlessly (awesome job GH!).

Custom domain

To set up custom domain for GitHub Pages I had to verify that I own the domain, which boils down to setting some TXT record in DNS.

On thing that I noticed once the project was available at www.stuffs.dev is that assets are not loading and paths are wrong. Turns out that Hugo be default uses relative paths which is problematic since GH Pages uses username path prefix, e.g. pasierb.github.io/PASIERB.
In order for things to work correctly with path prefix I had to force Hugo to use absolute paths when generating HTMLs. Fortunately it's as easy as setting canonifyURLs = true in config.toml. That's it!

Conclusion

Moving everything took me probably less than 2h which I find a great result. Developer experience both on GitHub side as well as Hugo is top notch.
10$/month more in my pocket is also top notch 🤑.

Originially posted on my blog at www.stuffs.dev

How I got to Google as a self-taught software engineer.

Michal Pasierbski — Fri, 09 Sep 2022 20:27:24 +0000

Landing a SWE job at Google is no easy feat. Being self-taught seemingly hinders one's chances, but how about adding to it:

being thirty-something years old (closer to 40 than 30 😅)
having wife, small kid and a dog
being only source of income for family

FAANG interviews are notoriously difficult. Good news is that if I could do it, so can you! Here are some battle-tested tips how to prepare.

How to study

In my circumstances time I could spent on learning was pretty limited. Full time job, small kid, wife - there is not much time and energy left in a day.

I tried to do 8 hours on weekends and fail miserably because kid wants to play (and I want it to!), wife wants to go to IKEA (and I want it to!), dog wants to go for a walk (and... you guessed it).

I tried late nights after family goes to sleep and failed again. I would do some productive work for first hour and then sit for next 3 staring at the screen not even noticing that I'm just passing time and depleting myself from sleep.

What changed my approach was to stop thinking about prepping to "the interview" but rather to be better software engineer. From being goal oriented - passing the interview - to being process oriented - being better software engineer.

I would do 30-60 mins daily sessions and that was a game changer. Not only I had more energy for my family, but it also learned at higher pace. Having shorter sessions allowed me digest the material better, think about it throughout the day and make it stick to brain's long-term memory.

Know your basics

Think about it as your tools. You need to have them handy and know how to use them. In 30-40 mins that you have to solve a problem(s) there is no time to figure out how BFS, DFS, works - you HAVE TO have this knowledge available to you at will.

Must know topics IMO in no particular order:

Data structures:

Linked lists
Arrays
Maps
Sets
Trees / Graphs / Tries (this tend to very useful)
Heaps

Algorithms:

basic sorting algorithms
Dijkstra's algorithm - a lot of interview problems are some sort of variations
backtracking
dynamic programming
tree traversal (DFS, BFS)

Practice

I distinguish two phases of practice:

Basics
Problem solving

Basics

For basics there is not other way that just writing code. Once you understand basic concepts you need to be fluent in transcribing those ideas to code. Don't memorise implementation, understand well enough that you can implement it without effort.

The goal is to build ready to use mental blocks. If part of the problem is to traverse a tree you could say "I'm going to use breath-first-search, it's going to be O(n) time complexity" and focus on next part of the challenge.

You need to be ready to talk about details of implementation, but chances are that you won't need to write it down.

Problem solving

This might be a bit controversial, but I believe that you either know the solution or not. There is to little time to figure it out on the spot. This is where purposeful learning comes to play.

Start with easy problems, get comfortable. When it's getting to comfortable start moving to medium difficulty. Up the ante enough to keep you engaged but not discouraged. If you're stuck for more than 15 minutes, then just read the solution - that's how you learn!

Once you're fairly comfortable with coding up the solutions... stop coding. Solve it in your head and check answers in forums to verify. My rule of thumb was no more than 10 minutes per question. Again, if you can't solve it just lookup the solution, try to understand it and move on - chances are you will encounter this question again.

This approach should develop in You some intuition what data structures to use, what kind of algorithm problem lends itself to. You will rather not encounter the same question in the interview, but it might be similar.

During interview

Think out loud

Your thinking process matters. Your interviewer can't read your mind, read it to her. If you considering array, say it. If it's something You discard, explain why. This also allows your interviewer to push you in the right direction.

One thing to pay attention to is rambling. If you notice that your thoughts are chaotic and you interviewer is confused, stop for a second. Say that you need a minute to think and relax.

Explain your approach

Before You start writing code you have to have clear picture how to arrive at solution. Write down your algorithms in plain words and discuss it with your interviewer. I always ask directly "shall we proceed to coding?". Most interviewers will signal to you if she has some concerns and you should correct your approach first.

Use helper functions

Focus on high level solution first using helper functions and fill them out later. For example: if you have algorithms that need topological sort, just write it as you would have it - topologicalSort(items) - and tell your interviewer that you will implement it later. Here it's important that you know your basics and can identify time/space complexity for those helpers so interviewer feels confident that you know how to implement it.

It is possible that interviewer will get enough signals and you won't have to fill in those helper functions. The key point here is to have complete algorithm in time. Chances are that there is a follow up question and your helpers become irrelevant anyways.

Just try!

Let's face it, chances that you will nail it in first try are slim. Why not get some practice then? Apply early and see where you stand. Don't get me wrong - try your best, prepare like your life depends on it, but keep in mind that it may not be your last time applying ;) I applied to all FAANG companies and others known to have similar interview process, just to get some reps in. Even if you apply to company that is not you first choice you might ended up getting hard to reject offer (BTW that's how I ended up at Amazon in Berlin).

There is a lot of stress involved and you will forget about details so take notes about the process:

what questions were you asked
what worked and what not
what areas to focus next time

It will come handy next time, trust me.

Final thoughts

It's not easy, but it's doable. Treat it as a marathon, not a sprint. If you think about the whole thing as a means to become better software engineer, with a possible side effect of landing your dream job it will become easier and pay dividends in your career regardless of the outcome.

Resources

Grokking the Coding Interview: Patterns for Coding Questions - great place to start
LeetCode - hands down best practice platform
Abdul Bari's youtube channel - some more advanced topics for curious ones
AlgoExpert - easy to follow, worth the money

This article was originally published on my blog stuffs.dev