DEV Community: Judah Dasuki

Understanding RAG: When AI Needs to Open a Book Before Answering

Judah Dasuki — Sat, 24 Oct 2026 06:04:55 +0000

Exploring Retrieval-Augmented Generation (RAG), how it works, and why giving AI access to the right information can be more useful than relying solely on what it already knows.

Generative AI · Applied AI · Software Engineering

Have you ever asked ChatGPT a question and received an answer that sounded incredibly convincing, only to discover later that it was completely wrong?

What's interesting is that AI can explain something with remarkable confidence, even when the information isn't accurate.

At first, I thought the solution was simple: just use a smarter or newer AI model.

But as I started learning more about Generative AI, I realized the problem wasn't that straightforward.

There's a difference between an AI that's good at generating answers and an AI that actually has the right information to answer a question.

That's when I came across an approach called Retrieval-Augmented Generation, or simply RAG.

AI Is Smart, but It Doesn't Know Everything

Imagine having a really smart employee.

They understand many subjects, can explain complicated concepts, and are great at solving problems.

But there's one limitation: they don't know everything about your company.

For example, let's say you ask:

"How many days of annual leave are employees entitled to under our company's latest policy?"

That employee might understand general labor regulations. However, they wouldn't necessarily know your company's internal policies, especially if those policies were updated last week.

The same thing happens with Large Language Models (LLMs).

Models like GPT learn patterns, concepts, and information during training. However, that knowledge doesn't automatically include private company documents, internal policies, or information that became available after their training data was collected.

When a model doesn't have enough information, it may sometimes generate an incorrect answer that still sounds perfectly reasonable.

This phenomenon is commonly known as hallucination.

So, what if we could give AI the company's policy documents before asking it to answer?

That's essentially where RAG comes in.

So, What Exactly Is RAG?

RAG is an approach that allows an AI-powered application to retrieve relevant information from external sources before using that information as additional context to generate a response.

The concept was introduced in a 2020 research paper by Patrick Lewis and his colleagues.

The name might sound complicated, but we can break it down into three simple parts:

Retrieval: Find information relevant to the question.
Augmentation: Add that information to the context provided to the AI.
Generation: Generate an answer using the question and the additional context.

Think of it like taking an exam.

There are two kinds of exams: closed-book and open-book.

In a closed-book exam, you rely entirely on what you've studied and remembered.

In an open-book exam, you're allowed to look things up before answering.

RAG works on a similar principle.

The difference is that the AI doesn't magically know where every piece of information is stored. The application we build is responsible for finding and providing the relevant information.

And here's something important:

RAG doesn't mean retraining the AI model.

We're not permanently adding new knowledge to the model. We're simply giving it additional reading material when it needs it.

How Does RAG Actually Work?

Let's use a simple example.

Imagine we're building an internal chatbot that helps employees find information from company documents.

The company has several documents covering things like annual leave, reimbursement policies, and work-from-home guidelines.

One day, an employee asks:

"How many days of annual leave do I get?"

A simplified RAG process would look something like this:

1. The employee asks a question.

The application receives the question about annual leave.

2. The system searches for relevant information.

Instead of immediately asking the LLM to generate an answer, the application searches the company's knowledge base.

3. The system retrieves relevant content.

It finds a section of the company's leave policy that says:

"Permanent employees are entitled to 12 days of annual leave per year."

4. The information is provided to the LLM.

The application sends both the employee's original question and the retrieved policy information to the model.

5. The LLM generates an answer.

Using the supplied context, the model might respond:

"According to the company's leave policy, permanent employees are entitled to 12 days of annual leave per year."

The policy and numbers above are fictional examples.

Pretty straightforward, right?

But there's an interesting question.

How does the application know which part of the company's documents is relevant to the employee's question?

That's where things get a little more technical.

How Does RAG Find the Right Information?

Let's say the company has 500 PDF documents.

Obviously, sending all 500 documents to the AI every time someone asks a question wouldn't be a great idea.

It would be inefficient, expensive, and potentially exceed the amount of information the model can process in a single request, commonly known as its context window.

Instead, a typical RAG system prepares documents so they can be searched efficiently.

There are a few important concepts behind this.

1. Chunking: Breaking Documents into Smaller Pieces

Imagine having a 300-page book.

If someone asks about annual leave, you wouldn't hand them the entire book and expect them to read everything.

You'd find the relevant page or paragraph.

That's essentially the idea behind chunking.

Large documents are divided into smaller pieces of information called chunks.

However, smaller doesn't always mean better.

If we split a paragraph in the wrong place, we might lose important context.

On the other hand, if a chunk is too large, it might contain lots of unnecessary information.

So, how we divide documents actually matters.

2. Embedding: Turning Text into Numerical Representations

Once documents are divided into chunks, we can use an embedding model to convert each piece of text into a numerical representation.

Why numbers?

Because computers can compare these numerical representations to estimate how closely related two pieces of text are in meaning.

For example, consider these two sentences:

"How many vacation days do employees get?"

"Annual leave entitlement for staff members."

They use different words, but they're talking about nearly the same thing.

Embeddings can help a system recognize this relationship without relying entirely on exact keyword matches.

3. Vector Search: Finding Relevant Information

Those numerical representations can be stored in a database or search index that supports vector similarity search.

When a user asks a question, the question is also converted into an embedding.

The system compares that embedding with the stored document embeddings to find the most relevant chunks.

Then, the original text from those chunks is passed to the LLM as context.

One thing worth mentioning: RAG doesn't always require a vector database.

Traditional keyword search or a combination of keyword and vector search, often called hybrid search, can also be used.

The goal is the same: retrieve information that's actually useful for answering the question.

Does RAG Completely Eliminate AI Hallucinations?

Unfortunately, no.

This was one of the most interesting things I learned.

Initially, I assumed that giving an AI the correct documents would automatically produce correct answers.

But that's not always how it works.

Imagine asking someone to answer a question using a reference book.

Several things could go wrong.

They might open the wrong page.

They might find the correct page but misunderstand the explanation.

Or the book itself might contain outdated information.

The same problems can happen in a RAG system.

For example, imagine an employee asks about the company's leave policy for 2026, but the retrieval system returns a document from 2024.

The AI might generate an answer that accurately reflects the retrieved document.

However, that answer could still be wrong because the information is outdated.

This means the quality of a RAG system doesn't depend entirely on how powerful the LLM is.

It also depends on the quality of the data, how documents are prepared, how relevant information is retrieved, and how the model is instructed to use that information.

RAG can help reduce hallucinations, but it doesn't eliminate them.

And that's an important distinction.

When Should We Use RAG?

As a web developer, I find RAG particularly interesting because it allows us to connect the capabilities of LLMs with data that already exists inside an application.

For example, a company with hundreds of internal documents might want to build a chatbot so employees don't have to search through them manually.

A software engineering team might want an assistant that can answer questions about API documentation, system architecture, or deployment guidelines.

A customer support application could retrieve product documentation before answering customer questions.

These are situations where having access to external information can make AI significantly more useful.

But here's the thing.

Not every AI application needs RAG.

If we're building something that improves grammar, rewrites sentences, or generates creative ideas, retrieving documents might not provide much value.

RAG also introduces additional complexity.

We need to prepare and maintain our data, manage a search index, handle document updates, and retrieve information when it's needed.

All of these can affect application complexity, cost, and response time.

So instead of immediately asking, "Can we use RAG for this project?"

I think a better question is:

"Does our application actually need to retrieve external information dynamically to produce useful answers?"

If the answer is yes, RAG might be a good fit.

If not, adding RAG could simply make the system more complicated than necessary.

RAG Isn't the Only Approach

After learning how RAG works, I started thinking about a few other questions.

What if the documents aren't that large?

What if users repeatedly ask questions about the same information?

Do we really need to search for relevant documents every single time someone asks a question?

These questions led me to another approach called Cache-Augmented Generation (CAG).

While RAG focuses on retrieving relevant information when it's needed, CAG explores the idea of preparing context ahead of time and reusing it through caching mechanisms.

Both approaches have their own benefits, limitations, and trade-offs.

And I think comparing them is interesting because it's not simply about choosing which technology is better.

It's about understanding how different approaches fit different data characteristics and application requirements.

That's what I plan to explore in the next article.

Final Thoughts

Learning about RAG changed the way I think about building AI-powered applications.

Previously, I tended to assume that the quality of an AI application mostly depended on the model behind it.

A smarter model should produce better results, right?

Well, not necessarily.

RAG shows that the quality of an AI system also depends on how we provide information to that model.

Even a powerful model can produce a poor answer when the context is wrong.

On the other hand, giving a model access to relevant, well-organized information can significantly improve its chances of generating a useful response.

As a software developer, this idea feels surprisingly familiar.

We're already used to building systems that retrieve data, process it, and return useful results to users.

RAG brings a similar pattern into Generative AI, with the LLM acting as a component that interprets context and generates natural-language responses.

Ultimately, building an AI application isn't just about making a model capable of answering questions. It's also about making sure the model has the right information to answer them.

And for me, that's one of the most important lessons from understanding RAG.

References & Further Reading

Lewis et al. (2020) — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
Microsoft Learn — Retrieval-Augmented Generation and Indexes
Microsoft Architecture Center — Design and Develop a RAG Solution

This is the first article in my RAG vs. CAG exploration series, written from the perspective of a software developer learning more about Generative and Applied AI.

Understanding Tokenization: AI Doesn't Actually Read Text the Way We Do

Judah Dasuki — Tue, 20 Oct 2026 08:51:05 +0000

Notes from a full-stack developer exploring Generative AI.

Lately, I've been spending some time learning about Applied AI and Generative AI.

Coming from a full-stack web development background, I initially thought building AI-powered applications wouldn't be that different from integrating any other API.

You send a request, the model processes the input, and you get a response.

And technically, that's true.

But the more I learn about how Large Language Models (LLMs) work, the more I realize there's a lot happening behind the scenes before a model generates an answer.

One of the first concepts that caught my attention was tokenization.

It sounds pretty straightforward at first. But as it turns out, tokenization plays an important role in how language models process text, handle context, and even how much it costs to use them.

AI Doesn't Read Sentences Like Humans Do

When we read a sentence like:

I'm currently learning about Generative AI.

Our brains naturally recognize the words and understand the meaning behind the sentence.

But an LLM doesn't process raw text in quite the same way.

Before the model can work with the text, it goes through a process called tokenization.

In simple terms, tokenization is the process of breaking text into smaller units called tokens.

Here's where it gets interesting: one token doesn't necessarily mean one word.

A token can represent an entire word, part of a word, punctuation, or even individual characters, depending on the tokenizer being used.

For example, a tokenizer might break this sentence down like this:

Input:

I love programming!

Illustrative tokenization result:

["I", " love", " programming", "!"]

Notice how spaces can actually be part of a token.

With some tokenizers, "love" and " love" may even have different token IDs.

So tokenization isn't simply splitting a string by spaces like we might do with string.Split().

There's more going on under the hood.

Why Does AI Need Tokens in the First Place?

One question I had while learning about this was:

Why can't the model just read the text directly?

The answer comes down to how computers process information.

Language models operate on numerical representations, not words as we see them on a screen.

That means text needs to be converted into something the model can process mathematically.

At a high level, the process looks like this:

Text → Tokens → Token IDs → Embeddings → Model

Let's use the same example:

I love programming!

After tokenization, each token gets mapped to a number called a token ID.

Something like this:

Token	Token ID
`I`	40
`love`	1842
`programming`	9265
`!`	0

These IDs are just examples, not actual values from a specific tokenizer.

The token IDs are then used to look up numerical representations called embeddings.

These embeddings are vectors of numbers that the neural network can work with.

One important distinction here:

A token ID doesn't represent the meaning of a word.

It's simply a numerical identifier.

The richer representation comes from embeddings and how the model processes those representations in relation to the surrounding context.

This was one of those concepts that made me realize how different language processing is from traditional application logic.

Tokenization Also Helps Explain Why AI Sometimes Struggles to Count Letters

Have you ever asked a chatbot something like:

How many times does the letter "r" appear in "strawberry"?

For humans, this seems like a ridiculously simple question.

But language models haven't always been reliable at answering questions like this.

One reason is tokenization.

A model doesn't necessarily receive every individual letter as a separate unit. A word like "strawberry" might be represented by a few tokens, each containing multiple characters.

So the model isn't automatically working with a character-by-character representation.

Of course, tokenization isn't the only reason an AI might get this wrong.

The model's learned patterns, reasoning capabilities, and access to external tools also play a role.

More capable models can often answer these questions correctly, especially when they use additional reasoning or tools to verify the result.

Still, I think this is a great example of something that's easy for humans but not necessarily straightforward for an AI model.

And sometimes, the opposite is also true.

Tokens Aren't Just About Text Processing. They're About Cost, Too.

This is where tokenization becomes especially relevant for developers building applications with LLM APIs.

When working with these APIs, you'll frequently come across terms like:

Input tokens: The tokens sent to the model, including instructions, user messages, and additional context.
Output tokens: The tokens generated by the model as part of its response.
Context window: The amount of context a model can handle within a single processing sequence, subject to model-specific input and output limits.

Why does this matter?

Because LLM API usage is generally priced based on the number of tokens processed, although input, output, and cached tokens may have different rates.

Imagine we're building an AI-powered customer support feature.

Every time a user sends a message, our backend might assemble several pieces of information:

A system prompt containing the chatbot's instructions.
Previous conversation history.
The user's latest question.
Additional documents or relevant information.

All of that consumes part of the model's available context.

Now imagine sending the entire conversation history with every request, even when most of it is no longer relevant.

The result?

Potentially higher costs, slower processing, and less room for the information that actually matters.

This is where I started realizing something important:

Prompt engineering isn't just about writing better instructions. It's also about managing the information we send to a model.

And that becomes an engineering problem, not just a writing problem.

The Language We Use Can Affect Token Count

Here's another interesting thing I learned.

Two sentences with the same meaning, written in different languages, don't necessarily produce the same number of tokens.

For example:

I want to learn programming.

and

Saya ingin belajar pemrograman.

Both sentences communicate roughly the same idea, but their token counts may differ depending on the tokenizer.

Why?

Because tokenizers are built around patterns found in the text data used to develop them.

Common character sequences may be represented as single tokens, while less common sequences might need to be broken into smaller pieces.

As a result, token efficiency can vary across languages.

Does that mean we should always use English to save tokens?

Not necessarily.

Token count matters, but so does the quality of the instructions and whether the model responds appropriately to the user.

If token efficiency is a concern, the better approach is to measure it using the actual tokenizer associated with the model we're using.

Rather than assuming one language will always be cheaper.

Why Should a Full-Stack Developer Care About This?

At first, I thought tokenization was something mainly relevant to machine learning engineers.

But the more I explored Applied AI, the more I realized that understanding these fundamentals can help us make better engineering decisions.

We don't need to build our own tokenizer to integrate an LLM into an application.

But knowing how tokens work becomes useful when designing features that involve large amounts of text.

Let's say we're building an application that reads and summarizes documents using AI.

The simplest approach might be to extract all the text from a document and send it directly to the model.

That might work for a short document.

But what happens when the document contains hundreds of pages?

Suddenly, we have several things to think about.

1. Managing the context window

We need to make sure the amount of information we're sending stays within the model's limits.

2. Splitting documents into chunks

Instead of sending everything at once, we can divide documents into smaller sections.

But chunking isn't as simple as splitting text into equal-sized pieces. Important context might be lost when related information ends up in separate chunks.

3. Controlling costs

More input tokens and longer generated responses can mean higher API costs.

For a feature used by thousands of users, small inefficiencies can become significant.

4. Retrieving only relevant information

Not every piece of information needs to be included in every request.

With techniques like Retrieval-Augmented Generation (RAG), we can retrieve relevant parts of a document before passing them to the model.

Tokenization doesn't solve all these problems by itself.

But understanding tokens makes it much easier to see why these problems exist in the first place.

What I Took Away From Learning About Tokenization

Learning about tokenization changed the way I look at LLM APIs.

Previously, I approached them like most backend services:

Send a request, receive a response, and integrate the result into the application.

Now I'm starting to realize that building AI-powered applications also requires understanding how the model receives, represents, and processes information.

Tokenization is only a small part of the overall LLM architecture.

But it's connected to several important concepts: embeddings, context windows, text processing, API costs, and the efficiency of AI-powered systems.

And the more I learn, the more I realize that building with Generative AI isn't just about successfully calling a model.

The real challenge is designing systems that provide the right context, generate useful responses, and remain efficient as they scale.

That's why I think understanding fundamentals like tokenization matters, even if our goal isn't to become an AI researcher.

Sometimes, being a better AI application developer starts with understanding what actually happens before the API returns a response.

Navigating Cross-Platform Development: A Comparative Analysis of React Native, Xamarin, Flutter, and Electron

Judah Dasuki — Wed, 28 Feb 2024 13:38:55 +0000

Introduction

In the realm of cross-platform development, the choice of framework and tools plays a pivotal role in determining the success of a project. With a multitude of options available, developers often face the challenge of selecting the most suitable framework that aligns with their project requirements. In this article, we'll conduct a comprehensive evaluation of four popular cross-platform development frameworks: React Native, Xamarin, Flutter, and Electron. By weighing their pros and cons in terms of performance, scalability, and ease of maintenance, we aim to provide developers with valuable insights to facilitate informed decision-making.

React Native

React Native, backed by Facebook, has gained widespread popularity for its ability to build native-like mobile applications using JavaScript. Its key features include:

Pros
Rapid development with hot reloading for quick iterations.
Access to a vast ecosystem of JavaScript libraries and components.
Near-native performance through platform-specific components.
Cons
Limited access to native functionalities, requiring third-party modules for complex features.
Performance overhead due to JavaScript bridge for native interactions.
Challenges in maintaining consistency across different platforms.

Xamarin

Developed by Microsoft, Xamarin allows developers to create cross-platform applications using C# and .NET. Its strengths and weaknesses include:

Pros
Full access to native APIs and functionalities, enabling seamless integration with platform-specific features.
Code sharing capabilities up to 90%, reducing development time and effort.
Robust performance comparable to native applications.
Cons
Steeper learning curve for developers unfamiliar with C# and .NET.
Limited community support and fewer third-party libraries compared to other frameworks.
Platform-specific bugs and inconsistencies may arise.

Flutter

Flutter, an open-source UI toolkit by Google, empowers developers to create natively compiled applications for mobile, web, and desktop from a single codebase using Dart. Its merits and drawbacks include:

Pros
High-performance rendering with its own rendering engine, Skia.
Hot reload functionality for real-time updates and rapid prototyping.
Comprehensive widget catalog and customizable UI elements.
Cons
Smaller ecosystem compared to more established frameworks.
Limited native functionalities and platform-specific integrations.
Potential challenges in integrating with existing native codebases.

Electron

Electron enables developers to build cross-platform desktop applications using web technologies such as HTML, CSS, and JavaScript. Its features and limitations comprise:

Pros
Wide compatibility across major operating systems, including Windows, macOS, and Linux.
Familiar web development tools and workflows for front-end developers.
Extensive community support and a plethora of third-party plugins.
Cons
Higher memory consumption and performance overhead compared to native applications.
Lack of access to low-level system APIs may hinder performance optimization.
Security vulnerabilities due to the use of web technologies for desktop applications.

Conclusion

In conclusion, each cross-platform development framework offers a unique set of advantages and challenges. The decision-making process should be guided by factors such as project requirements, developer expertise, and long-term scalability. While React Native excels in rapid prototyping and community support, Xamarin stands out for its seamless integration with native platforms. Flutter boasts high-performance UI rendering and hot reload functionality, while Electron provides a familiar web development environment for building desktop applications. By carefully evaluating the pros and cons of each framework, developers can make informed choices that align with their project goals and objectives, ultimately leading to successful cross-platform development endeavors.

This is why you don't use
in React again

Judah Dasuki — Thu, 27 Apr 2023 06:16:06 +0000

Hey, if you happen to be a React developer, you might find it helpful to use the trusty <div> tag when you need to wrap an element, especially if you're looking to create or return multiple elements in a component's return statement.

` endraw tag" width="736" height="676">

But sometimes you might not even need to use the <div> tag in React, which can actually just take up space in the DOM. However, we still end up using it to wrap multiple elements into one, especially when returning from a component.

Good news though, React 16.2 introduced a new feature called React Fragment that can help you avoid unnecessary <div> tags.

So, React Fragment works just like the <div> tag works. You can wrap or group elements in React Fragments.

` endraw tag" width="736" height="628">

Or you can simplify your syntax by writing Fragments shorthand tag (<> </>) instead of <React.Fragment></React.Fragment>.

` endraw tag" width="736" height="628">

React.Fragment is a feature in React that allows you to group a list of children elements without adding extra nodes to the DOM. Here are some benefits of using React.Fragment:

Cleaner Code: Using React.Fragment helps to keep your code clean and concise, especially when rendering multiple elements. It allows you to avoid adding unnecessary parent elements to your component tree.
Improved Performance: As React.Fragment does not create any additional DOM nodes, it helps to reduce the number of nodes in the rendered HTML, thereby improving the performance of your React application.
Flexibility: React.Fragment is flexible and allows you to group any number of elements without any restrictions. This makes it easy to compose components that are flexible and easy to maintain.
Compatibility: React.Fragment is supported by all major web browsers and can be used in any React project without any compatibility issues.
Accessibility: Using React.Fragment can improve the accessibility of your React application by reducing the number of nested elements in the DOM, which can be a challenge for screen readers and other assistive technologies.

Great news for React developers! React.Fragment is a fantastic feature that allows you to group a list of children elements together without adding extra nodes to the DOM. This amazing feature provides numerous benefits, such as improving performance, increasing flexibility, enhancing accessibility, and keeping your code clean and concise. By using React.Fragment, you can simplify your syntax and boost the efficiency and accessibility of your React applications. This feature is especially handy when working with multiple elements in a component's return statement, and you can choose to use the <React.Fragment></React.Fragment> syntax or the shorthand tag (<> </>). Overall, React.Fragment is a super helpful feature that can optimize your React development experience. Happy hacking!😉

Axios: The Game-Changer of JavaScript Libraries - Prepare to be Amazed!

Judah Dasuki — Wed, 26 Apr 2023 22:16:45 +0000

Are you tired of dealing with complicated HTTP requests in your JavaScript application? Look no further than Axios, the game-changer of JavaScript libraries. Axios makes it easy to send asynchronous HTTP requests and handle responses in a streamlined way. Get ready to be amazed by this fantastic library!

What is Axios and what problem does it solve?
How to install Axios in your application?
Using Axios to make HTTP requests and handle responses.
Interceptors and other useful features of Axios.
Comparing Axios to other popular JavaScript libraries for HTTP requests.

What is Axios and what problem does it solve?

Axios is a lightweight and easy-to-use JavaScript library that simplifies HTTP requests in your application. It allows you to send and receive data from a server or API, without the need for complicated boilerplate code. Axios provides an elegant and intuitive way to handle asynchronous requests, making your code cleaner and more maintainable.

How to install Axios in your application?

Installing Axios in your application is a breeze. Simply use npm or yarn to add it as a dependency:

npm install axios

yarn add axios

Once installed, you can import Axios into your code and start using its powerful features.

Using Axios to make HTTP requests and handle responses.

Making HTTP requests with Axios is a straightforward process. You can use the axios.get, axios.post, axios.put, and axios.delete methods to send requests to a server or API. For example, to get data from an API, you can use the following code:

axios.get('https://api.example.com/data')
  .then(response => {
    console.log(response.data);
  })
  .catch(error => {
    console.error(error);
  });

Axios also makes it easy to handle responses. You can use the then method to handle a successful response and the catch method to handle an error. The response object contains information about the response, such as the data and status code.

Interceptors and other useful features of Axios.

Axios provides several useful features, such as interceptors, which allow you to modify requests and responses globally. You can use interceptors to add headers, handle errors, or perform other actions before a request is sent or after a response is received. Here's an example of how to add a custom header to all requests:

axios.interceptors.request.use(config => {
  config.headers.Authorization = 'Bearer token';
  return config;
});

Axios also provides a built-in mechanism for cancelling requests, which is useful when a user navigates away from a page before the request has completed.

Comparing Axios to other popular JavaScript libraries for HTTP requests.

Axios is not the only JavaScript library for handling HTTP requests. Other popular libraries include Fetch and jQuery. While each library has its own strengths and weaknesses, Axios stands out for its simplicity, ease of use, and powerful features.

Fetch is a built-in API for making HTTP requests in modern browsers, but it lacks some of the features provided by Axios, such as interceptors and request cancellation. jQuery is a popular library that provides a wide range of features, but it can be bloated and difficult to use for simple HTTP requests.

In conclusion, if you're looking for a powerful and easy-to-use JavaScript library for handling HTTP requests, look no further than Axios. With its elegant syntax, useful features, and streamlined approach, Axios is the game-changer you've been waiting for. Give it a try and prepare to be amazed!