At the same time, the engineering work has not disappeared; it has moved somewhere else. You are still responsible for the code. You still need architecture, tests, taste, and the ability to understand what is being produced. I would even say all of that matters more now, because generating a lot of code very quickly also means generating a lot of garbage very quickly if you don't know how to guide the process.

I am not trying to write a grand theory of AI here, only my honest view after using LLMs seriously for work projects and personal projects, and after pushing them further than I expected to push them.

Smart and dumb at the same time

The most frustrating part for me is how unstable the experience feels. You can ask a model to reason about a complex codebase, propose a structure, connect ideas that you had not connected, and sometimes it will one-shot something better than what you had in mind. Five minutes later, you ask it to do one tiny deterministic thing and it fails in the stupidest possible way.

I am not exaggerating here; for me, this has become the normal experience. It feels like working with something that can be one or two levels smarter than you in one moment, and completely unable to follow a simple instruction in the next one. It can design a decent architecture for a service, and then get stuck doing workaround after workaround for a small bug that you would have fixed manually in ten minutes.

For that reason, I don't like the simple question of whether AI is good or bad for coding; the answer depends too much on which part of the work you are looking at. In some dimensions it is very good, and in others it is absurdly bad. If you want to use it seriously, you need to learn where those borders are.

Prompting is not programming

One of the things I built during this period was an incident investigation bot. The idea was simple: given an alert, the bot should inspect metrics, logs, traces, dashboards, and downstream dependencies until it reaches a useful hypothesis about the root cause.

My main problem with LLMs in this kind of task is laziness. They tend to stop at the first plausible explanation. If an endpoint is failing because a downstream dependency is failing, the model will often say: "the downstream dependency is failing", and stop there. The problem is that a downstream failure is usually only the next node in the investigation, not the actual root cause.

A human keeps going to the downstream service, checks its logs, checks its traces, checks whether it has another downstream dependency, and keeps following the error until reaching a dead end, or at least until reaching the deepest useful explanation.

So I tried to encode that into the prompt. I described the investigation as a graph. Services are nodes. Signals are edges. A log, a metric spike, a span error, a dependency failure: all of those are edges that let you move to another node. The bot has to keep traversing the graph until the path stops being useful.

The bot got much better after that, although new problems appeared immediately. Sometimes it would over-traverse. Sometimes it would treat the deepest branch as the root cause, even when another branch was more directly related to the user impact. Sometimes fixing one failure mode in the prompt would break another one.

The strange thing with prompts is that they are not code and they are not deterministic. You cannot write a prompt the same way you write a function and expect the same input to always produce the same behavior. You are not programming a machine in the classical sense. You are shaping the behavior of a probability machine, and the more instructions you add, the more strange interactions you can create.

I don't think this problem is solved. If it were solved, prompt injection and jailbreaks would not exist in the way they exist today. A longer prompt is not necessarily better. Often, what you really want is a prompt that communicates the final objective clearly enough for the model to keep rediscovering the right behavior by itself. Finding that sentence is very hard.

Context is everything

The next thing I learned, or maybe relearned, was that context matters more than the prompt itself. The model answers your last message through everything around it: its weights, your prompt, the system instructions, and the whole current context of the conversation.

When the context is clean, it behaves better. When the context is full of trash, half-finished attempts, wrong assumptions, noisy tool outputs, and stale conclusions, it degrades.

Todo lists are one of the simplest ways I have found to control the behavior of an agent. The UI is cute, but the important part is the control mechanism behind it.

When I want an agent to do a big task, I don't just say "do it". I first ask it to plan with me, convert that plan into exhaustive checklist items, mark each item as done while it works, and continue until there are no checkboxes left. Small trick, big difference in behavior. The checklist prevents the model from stopping early, gives the agent a local memory of what it is doing, and gives me a way to inspect whether the plan is sane before the agent starts producing code.

For very long sessions, the plan becomes even more important. The model needs to compact its context from time to time, and before doing that it should write back the important findings, decisions, open questions, and completed work into the plan. After compaction or restart, the plan becomes the brain of the session. The agent wakes up again, reads the plan, and remembers who it is. I know this sounds ridiculous, but after using it for long-running tasks it becomes very clear why it works.

Tools are a way of protecting context

The context window is precious, and filling it with garbage makes everything worse. Tools matter so much for exactly this reason.

If an agent needs to rename a symbol, I don't want it reading the whole file as text, generating the whole file again, and hoping that the patch applies. I want it to use an LSP, the same way my editor does: ask for the symbol, rename it, inspect references, and move on.

Something similar happens with MCPs. I know MCP sounds new, but in my head MCP is basically SOAP for LLMs. SOAP was this old way of exposing self-documented APIs through XML. MCP is a way of exposing tools to an LLM with enough structure that the model can discover what exists, understand the input schema, and call the right method.

For me, the useful part of MCP is very boring: the model can interact with the world without needing the whole world copied into the prompt. The most useful tools are often tiny utilities built specifically to reduce context waste, not huge integrations. For the incident bot, traces were a good example. A trace can be massive: thousands of lines of JSON, spans, attributes, metadata, timestamps, and repeated fields. But for an investigation, the first useful thing is often much smaller: which spans are in error, how the error propagated, and which service boundaries are involved.

So I built a small utility that takes the raw trace JSON and produces a compact ASCII tree of the error path. Instead of giving the model 12,000 lines of JSON, I give it a few lines that show the shape of the failure. If it needs more detail, it can inspect the original span later.

That utility is boring, but it made a huge difference, because good agent tooling is often about the shape of the information more than about the amount of information.

The model can raise your level, but it cannot replace your taste

My current mental model is that an LLM can raise you one or two levels in an area. If you are a 2 out of 10 in something, maybe with an LLM you can produce something that looks like a 3 or a 4.

The usefulness has a dangerous side: if you are bad at judging the result, you will still produce bad work, only now it will look better to you than what you could have produced alone.

If you don't know Terraform, the model can generate Terraform for you. But you still need to know enough to recognize duplication, bad abstractions, broken state assumptions, weird module boundaries, and hidden operational risk. If you don't know Go, the model can generate Go for you. But you still need to know enough to recognize bad error handling, confused ownership, unnecessary interfaces, leaky abstractions, and tests that don't actually test anything.

The model does not remove the need for expertise; it amplifies the expertise you already have, and I started using multiple conversations against each other because of this. One agent writes the code. Another agent reviews it harshly. Another one checks it against my guidelines. Another one tries to simplify it. Sometimes I ask the same model to behave as if the previous output was produced by a very dumb AI and it has to find everything wrong with it.

Surprisingly, this works quite well. I don't think the model becomes more truthful because of this. I think the role and the context change the distribution of the answer. If you ask it "is this good?", it will often be too nice. If you ask it for a harsh code review and tell it to assume the code was generated by a lazy AI, it finds much more. A bit stupid, but useful.

Speed creates a new problem: understanding

The first versions of some of my projects appeared absurdly fast. In the past, speed was mostly limited by typing, searching, boilerplate, and the time needed to discover APIs. With LLMs, that part almost disappears.

The bottleneck moves to understanding what now exists. You can wake up with thousands of lines of code that were generated while you were sleeping, which is impressive and dangerous for exactly the same reason.

If something breaks, your first instinct may be to ask the agent for one more fix, and after that another one, and after that another one. At some point you are not engineering anymore. You are prompting around a codebase you don't understand.

A strong test suite saves you there. If you use AI to move faster, you should also use AI to create more tests than you would have written manually. Every bug found should become a test. Every weird piece of business logic should have comments and regression coverage. Every refactor should be backed by something stronger than "the agent says it is fine".

Refactoring helps with the same problem. An LLM will usually not stop and say: "dude, this code is becoming horrible, let's clean it up". If you ask it to add a feature, it will add the feature on top of the current state. It will try to reach the end result, because that is what you asked for.

So you need to explicitly ask for refactoring passes. Ask it to find duplication. Ask it where responsibilities are leaking. Ask it which abstractions are fake. Ask it what can be deleted. Ask it where the tests are too coupled to implementation details.

For me, one of the best uses of AI is doing the boring cleanup that everybody knows should happen and nobody wants to spend a week doing. Before AI, large refactors often died because they were too annoying. After AI, the annoying part is much smaller. The refactor still needs review and tests, of course, although the cost of attempting it is lower.

Incident investigation is mostly graph traversal

The incident bot made me realize something obvious: when we investigate production issues, we are usually navigating a graph.

You start with an alert. That alert points to a service, an endpoint, a queue, a database, or some business metric. In practice, that becomes your first node.

From there, you look for signals: logs, metrics, traces, deployment events, saturation, dependency errors, feature flags, configuration changes. Each signal gives you an edge to another node.

You follow the edge and now you are in another service, another dependency, another metric, another part of the system. You repeat the process until you reach something that explains the impact well enough.

Thinking like this helped me write a better prompt, although it also made something else painfully clear: we only need this kind of bot because our observability is not good enough.

If traces were complete, consistent, and connected across services, many investigations would be much easier. You would open the trace, follow the failing span, and see the path. But in real systems, traces are not always connected. Logs don't always have the right attributes. Metrics don't always share the same labels. Dashboards are sometimes empty, misleading, duplicated, or owned by nobody. Some services follow OpenTelemetry conventions. Others don't. Some dependencies are visible. Others disappear at the boundary.

The bot has to compose a picture from broken pieces, which can be useful, but it is still a symptom. An AI incident bot is only as good as your telemetry. If the telemetry lies, the bot will reason from lies. If the traces are disconnected, the bot will invent bridges or stop too early. If ownership is unclear, the bot will not magically know who should act. If alerts are noisy, it will waste time on noise. A better bot can help, but the real fix is better observability.

Token usage is part of the design

Long conversations are expensive, not only in money but in attention. Every time you send a new message, the system has to process the relevant context again. Caching helps, but cache can break. Tool outputs, timestamps, changed messages, and client behavior can all make the provider recompute more than you expect.

Shorter sessions sometimes work better because long sessions, while useful for some work, also accumulate dirt.

For small tasks, I prefer starting fresh. For big tasks, keep a plan file, compact aggressively, and make sure the durable memory is outside the chat. The source of truth should be the plan, the tests, the code, and the documentation, not the chat itself.

The model can talk to itself for a while, and that can improve the answer. Reasoning tokens exist because of that. But there is a sweet spot: more thinking does not always improve the result, and faster answers are not automatically better either.

The useful question is less "how do I make the model faster?" and more "what is the minimum reasoning path that still gives me a good answer for this task?"

Sometimes you want the model to think deeply; other times you want a small deterministic edit and nothing else. The skill is knowing which mode you are asking for.

So, should we use AI to code?

Yes, but not as a replacement for engineering. Use it to move faster. Use it to explore. Use it to generate tests. Use it to refactor boring code. Use it to critique your own work. Use it to build small tools that would otherwise not exist. Use it to turn vague ideas into prototypes. Use it to make yourself more ambitious.

Just don't use it as an excuse to stop understanding. The worst version of AI-assisted programming is a developer prompting changes into a codebase they no longer understand, trusting green tests that don't mean much, and accumulating abstractions that nobody would have written by hand.

The version that makes sense to me is the one where the developer still owns the architecture, still owns the trade-offs, still reads the important parts, still writes or reviews the tests, still simplifies, still deletes, still asks whether the thing should exist at all.

The code may be generated by the model, but the responsibility is still yours. Maybe I have not written a line of code in five months, but I have been coding in another place: in the architecture, in the prompts, in the tools, in the tests, in the refactors, in the shape of the context, and in the taste required to decide when the machine is right and when it is just confidently producing slop.

End note

I just wanted to add that, depending on the day, I feel bullish or bearish on AI: https://notas.grod.es/the-rain-spell. Some days I feel excited about the future we are building with it, and other days I feel honestly depressed about it. I am still not convinced about what that future will look like, or even whether at some point I will decide to reject AI completely and go back to writing all code by myself.

Why autovacuum can unexpectedly take this lock

PostgreSQL autovacuum is a background process which performs maintenance operations on database tables. You can think of it as a job that starts running based on some heuristic (which can be configured) and executes the VACUUM command on a table. My understanding was that VACUUM was safe to run online, that it wouldn’t cause any outage in production as it doesn’t acquire an AccessExclusiveLock. I frequently check this website to learn which locks are acquired by each PostgreSQL command. And it shows that plain VACUUM normally obtains a ShareUpdateExclusiveLock.

But there is one specific case where VACUUM (and consequently the autovacuum process too) will acquire an AccessExclusiveLock:

The standard form of VACUUM removes dead row versions in tables and indexes and marks the space available for future reuse. However, it will not return the space to the operating system, except in the special case where one or more pages at the end of a table become entirely free and an exclusive table lock can be easily obtained. docs ref

When VACUUM truncates empty pages

If you are deleting old records from a table, leaving empty pages (pages with only dead tuples) at the end of your table (physical position in disk), VACUUM will obtain an AccessExclusiveLock on that table, if it can obtain it immediately. It will then truncate those empty pages to free up some disk space.

This is exactly what happened to me as we were running a job that was migrating old records to cold storage and deleting them afterward from the table. This generated the perfect scenario for AutoVacuum to lock the table for a while and cause a production outage.

Solutions

Preventing the lock with vacuum_truncate=false

Since PostgreSQL 12, it is possible to configure the VACUUM command to disable the truncation behavior by defining the following setting on a per-table basis:

ALTER TABLE
	my_table
SET
	vacuum_truncate=false,
	toast.vacuum_truncate=false;

If you are running VACUUM manually instead of AutoVacuum, you can parameterize the command itself:

VACUUM (TRUNCATE FALSE) my_table;

Although you will want to free up that disk space at some point. If you are still afraid of AccessExclusiveLock you can execute an online (concurrent) table rewrite with pg_repack.

Use TRUNCATE, if your data model allows it

Another solution is to execute the TRUNCATE command (instead of DELETE) when removing the data you are migrating. This will acquire an AccessExclusiveLock and free up disk space immediately.

This is not a drop-in replacement for DELETE, though. TRUNCATE removes all rows from a table (or from a partition, if you are truncating partitions), so this only makes sense if your data model lets you isolate old data cleanly. For example, old data could live in partitions, and then you can truncate whole old partitions instead of deleting millions of rows from the middle of a table.

I haven’t tried it yet in this exact setup, but it should be very fast to execute when the operation is scoped to an old partition or a temporary/staging table. The AccessExclusiveLock still exists, but it is explicit, predictable, and hopefully short-lived. In my case VACUUM started to truncate millions of rows as a side effect of a normal maintenance operation, which seems to have locked the table long enough to trigger our on-call monitors.

Community notes

It seems like this truncation shouldn't be a big problem in many setups, and some people have pointed out that this post might be exaggerated or too alarmist. However, there have been other responses explaining that when streaming replicas are in place, they might exacerbate the issue. The standby has to replay what happened on the primary. If replaying the truncation conflicts with queries running on the standby, it has to either delay WAL replay or cancel the conflicting queries.

Except if you have streaming replicas. The problem then is that replicas MUST replay the truncation, so either replication blocks or the replica needs to kill any blocking queries. Hot Standby Feedback does NOT do anything to alleviate this either.

Jim Nasby @ LinkedIn

When I encountered this years ago it was exacerbated by the use of read replicas. The vacuum process has no way of knowing that it's blocking a query on the read replica.

ICThat @ Reddit

Once you know about this particularity of VACUUM, it is trivial to avoid it in the future. Interestingly enough, I had never heard about this specific behavior before, and my understanding was that VACUUM was "safe to run but doesn’t recover disk space" and VACUUM FULL was the heavy, dangerous, full-locking, version of it.

Turns out VACUUM can be dangerous too.

I thought that writing yet another terminal utility with Rust that does network requests would be a good introduction to Rust async programming.

Rust's standard library provides the Future trait to represent asynchronous computations, but it does not provide an async runtime. Futures do not execute by themselves and you need something to poll them to further advance their execution. That's what async runtimes do and, for the moment, the std lib does not provide one. It has been left to the community to implement it. I've chosen tokio since it is the most used one and I have no preference or idea about what I need.

But I had one thing clear, the only things that my TUI has to do is:

1. Read from stdin.
2. Do a network request.
3. Write to stdout.

It is little work, very simple, the only extra work we could add here is to take into account that once you receive a response from the request you have to deserialize the response into memory. Since Rust is known for its performance I wanted to write this TUI around the idea of limiting it to a single thread. I don't want the tokio runtime to have to handle thread synchronization, for this simple task a single thread should be more than enough and still provide a non-blocking interface to the user. Tokio provides a macro that you can use on your functions that unwraps into a runtime initialization: #[tokio::main]

And it has variants to specify things like the number of threads to use, or like in my case, if you want to only use the current thread: #[tokio::main(flavor = "current_thread")]

Small caveat: using the current_thread runtime means that Tokio's scheduler runs tasks on the current thread. It does not necessarily mean that the entire process will never use helper threads. For example, depending on how you read from stdin, Tokio may still use blocking work behind the scenes.

I wanted to first set up a test playground to get a grasp of really how Rust and tokio work to see how I could write an app with them.

This piece of code just defines an imaginary UI that has a draw method that is very demanding and panics if has elapsed more than 200ms since the last time that it has been called.

use std::time;

struct UI {
	last_draw: time::Instant,
}

impl UI {
	fn default() -> UI {
		UI {
			last_draw: time::Instant::now(),
		}
	}

	fn draw (&mut self) {
		let now = time::Instant::now();
		assert!(
			now.duration_since(self.last_draw).as_millis() <= 200,
			"It has been too long since last draw!"
		);
		self.last_draw = now;
	}
}

Then we define a method that will simulate the network request, it has 3 sleep calls of 100ms each, so we will have to be sure that our UI::draw method gets called at least in the middle of some of these sleep.

async fn network_request() {
	println!("sending HTTP request...");
	tokio::time::sleep(time::Duration::from_millis(100)).await;
	println!("deserializing JSON...");
	tokio::time::sleep(time::Duration::from_millis(100)).await;
	println!("some more sleep...");
	tokio::time::sleep(time::Duration::from_millis(100)).await;
}

And in my first attempt, I failed shamefully. In my incorrect mental model, I thought that in some way, once it reached one of the await within network_request it would somehow halt execution there and continue with the next loop to keep calling ui.draw().

#[tokio::main(flavor = "current_thread")]
async fn main() {
	let mut ui = UI::default();
	loop {
		ui.draw();
		network_request().await;
	}
}

Now I see how blind I was, here the async primitive just allows us to write asynchronous logic in a synchronous-looking way. By awaiting network_request directly inside the loop, I am waiting for that future to finish before drawing again. The sleeps themselves are non-blocking, but there is no other branch in this program that keeps drawing the UI while the request future is pending, so the UI is not drawn for ~300ms and it panics.

Because I wasn't understanding why it wasn't working I decided to look at what other TUIs were doing, but surprisingly I haven't found any Rust file containing "current_thread" and "tui" (I am writing the TUI with tui-rs and wanted to see how to integrate it with single-threaded tokio).

But after reading a little bit I've understood that I need to offer the tokio runtime a chance to work on multiple tasks to intersperse them.

In the previous example, I was only driving a single future. But if we generate 2 async branches, one for the interface and the other to handle requests, the tokio runtime will be able to run them concurrently.

#[tokio::main(flavor = "current_thread")]
async fn main() {
	tokio::join!(
		async { // interface
			let mut ui = UI::default();

			loop {
				ui.draw();
			}
		},
		async { // network requests
			loop {
				network_request().await;
			}
		}
	);
}

Here tokio::join! is running the provided async blocks and waiting for them to finish before exiting. It is important to understand that join! is not spawning independent Tokio tasks here. It multiplexes those async branches inside the same task, which is exactly the kind of thing I wanted for this experiment: concurrency without parallelism. Although the previous snippet doesn't work, since the interface loop is not asynchronous so it is not giving a chance to the network task to execute, so we need a wait to "turn it into async" and stop it.

The first thing that came to my mind was just to use tokio::time::sleep (tokio provides async std lib alternatives) but it seemed seedy to me, I just needed a semantic to specify that I want to stop the current execution of the task to run other possible concurrent tasks. I found tokio::task::yield_now and it looked exactly what I was looking for but the truth is that it didn't work for this experiment. The interface branch was in fact stopping, but the runtime was free to poll the interface branch again instead of executing the request branch, so the behavior looked the same as not using it. After reading the docs, this is not something you should build correctness on: Tokio does not guarantee the exact scheduling order after yield_now. Then I also found consume_budget and It looked like a good candidate, unfortunately, it didn't work either, anyhow it exists under an unstable-feature flag, and if you have to access unstable features when learning a new tool it is probably because you are not approaching it in the way that it was intended.

I also tried tokio::time::interval and tick events to provide something like a refresh rate. This is probably the more semantic primitive for a UI refresh loop, but in my experiment I still managed to miss the deadline sometimes and the draw call panicked because it was called too late. I probably had some blocking work or some wrong assumption in my mental model somewhere.

async { // interface
	let mut interval = tokio::time::interval(
		time::Duration::from_millis(100)
	);
	loop {
		interval.tick().await;
		ui.draw();
	}
}

After feeling defeated I ended up including the async sleep call and everything worked

async { // interface
	loop {
		ui.draw();
		tokio::time::sleep(
			std::time::Duration::new(0, 0)
		).await; // I am ugly but I do work.
	}
}

Being a little more practical, both tasks will need to access the UI state, so I'll need to share the UI instance between them, since Rust needs to guarantee safe memory access on compile time, it is not that easy to share memory between different parts of your code for newcomers.

I've found the following repository which contains a very good decision tree to determine which memory primitive to use for a given case.

Encapsulating our UI instance in a std::cell::RefCell will do the trick and will allow us to access it in both async branches and even mutate it. This works here because I am not spawning real independent Tokio tasks and I am not holding the mutable borrow across an .await. If I moved this to tokio::spawn, this would become a different problem and RefCell would not be enough by itself.

#[tokio::main(flavor = "current_thread")]
async fn main() {
	let ui = std::cell::RefCell::new(UI::default());

	tokio::join!(
		async {
			loop {
				ui.borrow_mut().draw();
				tokio::time::sleep(
					time::Duration::new(0, 0)
				).await;
			}
		},
		async {
			loop {
				network_request().await;
				ui.borrow_mut().value += 1;
			}
		}
	);
}

This is how I ended up organizing my TUI code which can be viewed at github, it has an abusive usage of unwrap but I just wanted to get it done within the weekend. I would love to hear about how I could improve it and if I've had some misconceptions in my mental model of how Rust and async work.

“Any website should always display the same content for a given URL, regardless any previous state”
― Someone with common sense

I can think of some exceptions, like session or browser preferences, that can make differ the content between users, but It should be true for each single user experience.

This is something important to have in mind when building Single Page Applications.

A common mistake I’ve encountered many times during development is when a page displaying a results view, offers filters to adjust the search. Once the users starts tweaking with those filters the results update but the URL keeps the same inducing a URL-State desynchronization, so if the user tries to reload the page or shares the URL, the web page will not display the filtered results. This is because the developer has directly updated the app state instead of use a router to keep the URL in sync with it.

Next I’m going to show some examples written using Vue and Vue Router

Warning: all this gists has been written directly from medium, I cannot assure they run without errors but I think that they capture the idea

Bad implementation

<template>
  <div>
    <ul>
      <li v-for="item in results" :key="item.id">
        {{ item.name  }}
      </li>
    </ul>

    <Checkbox v-model="filters.isNew" />

    <Pagination v-model="page" />
  </div>
</template>

<script>
export default {
  name: 'ResultsPage',
  data: () => ({
    results: [],
    page: 1,
    filters: {
      isNew: false
    }
  }),
  watch: {
    page (page) {
      this.fetchResults({ page })
    },
    filters: {
      deep: true,
      handler (filters) {
        this.fetchResults({ filters })
      }
    }
  },
  created () {
    this.fetchResults()
  },
  methods: {
    async fetchResults ({ filters = this.filters, page = this.page }) {
      const { data: results } = await SomeApiCall({ filters , page })
      this.results = results
    }
  }
}
</script>

Here we can see how the inputs Checkbox and Pagination are updating the data properties directly and then the watchers of them trigger the fetch of new results without updating the URL.

It’s wrong.

Good implementation

<template>
  <div>
    <ul>
      <li v-for="item in results" :key="item.id">
        {{ item.name  }}
      </li>
    </ul>

    <Checkbox
      :value="filters.isNew"
      @input="$router.push({ query: { ...$route.query, isNew: String($event) }})"
    />

    <Pagination
      :value="page"
      @input="$router.push({ query: { ...$route.query, page: $event }})"
    />
  </div>
</template>

<script>
export default {
  name: 'ResultsPage',
  beforeRouteEnter (to, from, next) {
    next(vm => {
      vm.page = Number(to.query.page || 1)
      vm.filters.isNew = to.query.isNew === 'true'
      vm.fetchResults()
    })
  },
  async beforeRouteUpdate  (to, from, next) {
    this.page = Number(to.query.page || 1)
    this.filters.isNew = to.query.isNew === 'true'
    await this.fetchResults()
    next()
  },
  data: () => ({
    results: [],
    page: 1,
    filters: {
      isNew: false
    }
  }),
  methods: {
    async fetchResults () {
      const { data } = await SomeApiCall({
        filters: this.filters,
        page: this.page
      })
      this.results = data
    }
  }
}
</script>

On this example we use the navigation guards provided by Vue Router to hook into the cycle of the router so we can get the query params and sync our data with them

Even we could go further with it and get rid of the data properties to only use the params provided by the route so we don’t need to sync anything, like is shown in this last gist

<template>
  <div>
    <ul>
      <li v-for="item in results" :key="item.id">
        {{ item.name  }}
      </li>
    </ul>

    <Checkbox
      :value="$route.query.isNew === 'true'"
      @input="$router.push({ query: { ...$route.query, isNew: String($event) } })"
    />
    <Pagination
      :value="Number($route.query.page || 1)"
      @input="$router.push({ query: { ...$route.query, page: $event } })"
    />
  </div>
</template>

<script>
export default {
  name: 'ResultsPage',
  beforeRouteEnter (to, from, next) {
    next(vm => { vm.fetchResultsFromRoute(to) })
  },
  async beforeRouteUpdate  (to, from, next) {
    await this.fetchResultsFromRoute(to)
    next()
  },
  data: () => ({
    results: []
  }),
  methods: {
    async fetchResultsFromRoute ({ query: { isNew = false, page = 1 } = {}) {
      const { data } = await SomeApiCall({
        filters: { isNew: isNew === 'true' },
        page: Number(page)
      })
      this.results = data
    }
  }
}
</script>

This way the browser will keep track of any changes on the state of the page and the user will have full functionality on Back/Forward actions and a fully shareable URL