DEV Community: Tahirih Jaliri

I Tried NotebookLM as a Study Tool and It's Actually Changed How I Learn

Tahirih Jaliri — Sun, 07 Jun 2026 23:24:14 +0000

A few months ago, I started preparing for the TOEFL iBT while also deep-diving into Clean Architecture patterns and AWS services, just trying to level up professionally. I had documents everywhere: PDFs, Google Docs, random notes, YouTube links saved in tabs I'd never revisit. Sound familiar?

That's when I gave NotebookLM a real shot. Not just a quick try, I mean, actually building a workflow around it. And I'm genuinely surprised by how much it's helped me.

Let me share what I found.

What is NotebookLM, really?

NotebookLM is Google's AI-powered research assistant. The core idea is simple: you upload your sources (PDFs, Google Docs, web links, slides), and then you can chat with them. Ask questions, request summaries, generate study guides, and every answer cites your actual source material.

The key thing that differentiates it from something like ChatGPT: it doesn't hallucinate from general knowledge. It only uses what you gave it. Every response links back to the specific chunk of your document that supports it. For studying, this is huge.

What I actually used it for

1. Digesting dense content faster

I uploaded my TOEFL reading practice materials and course notes into a notebook. Instead of re-reading everything, I just asked:

"What are the key arguments in this passage and how do they connect?"

Or:

"Give me 5 questions I should be able to answer after reading this material."

It turned passive reading into active interaction. The difference in retention was noticeable.

2. The Audio Overview feature (this one surprised me)

This is NotebookLM's most viral feature, and honestly, the one I was most skeptical about. It generates a podcast-style conversation between two AI hosts discussing your uploaded content. We're not talking text-to-speech monotone. These "hosts" actually build on each other's points, ask clarifying questions, and even push back on ideas.

I started listening to my study material on walks and commutes. My brain processed things differently when I heard information presented as a conversation rather than reading it cold. For complex technical topics like architecture patterns, it helped me identify which parts I hadn't really understood, because the hosts' explanations would either click or they wouldn't.

You can also customize the format: choose between Deep Dive, Brief, Critique, or Debate formats, select the length, and even join the conversation interactively to ask follow-up questions mid-podcast.

3. Leveling up on architecture and cloud (with a curiosity-first approach)

Dense technical content, AWS whitepapers, Clean Architecture docs, and design pattern articles, is exactly where my focus tends to drop. Not because the topics aren't interesting, but because passive reading doesn't give my brain enough to hold onto.

I started applying what I'd call a curiosity-driven study approach: instead of reading top to bottom, I'd open NotebookLM and start with questions I was genuinely curious about before trying to "study" the material properly.

Things like:

"Why would someone choose this architecture over a simpler one?"
"What are the real tradeoffs of this AWS service vs the obvious alternative?"
"Where do most people get this wrong in practice?"

That shift from passive reader to active questioner changed how I engaged with the content. NotebookLM handles the heavy lifting of finding answers across multiple sources, so I could stay in curiosity mode instead of getting stuck hunting for the right paragraph.

I also used it to:

Generate an outline to understand the big picture before going deep
Spot contradictions or gaps between different sources I was referencing
Create a FAQ with questions I'd likely struggle to answer, and then study those specifically

It's not about delegating the thinking it's about having a smart thinking partner that keeps your curiosity engaged even when the material is dense.

Key advantages that actually matter

✦ Source-grounded answers
Unlike general LLMs, responses are anchored to your documents. You can trace every claim back to its origin. This matters when you're studying for something that requires accuracy.

✦ Multiple input types
You can upload PDFs, paste web links, connect Google Docs and Google Drive files. Your notebook becomes a unified knowledge base across formats.

✦ Mind Maps (newer feature)
The Studio panel now includes an interactive Mind Map feature useful for visualizing connections between concepts across sources. Great for systems thinking.

✦ It's free
The base version is genuinely useful. The Plus tier (via Google Workspace) adds more notebooks, higher source limits, and more Audio Overview generations per day.

✦ No hallucinations from outside context
This can also be a limitation depending on your use case, but for studying, it's a feature. The tool stays in its lane.

Can it connect with Notion?

Short answer: not natively (yet). NotebookLM connects with Google Workspace, Docs, Drive, Slides, but there's no official Notion integration.

However, there's a simple workaround that works well:

Export your Notion page as a PDF, Markdown, or plain text file
Upload it directly into NotebookLM as a source
Now you can query your Notion content with AI

This is especially useful if you already use Notion for documentation or structured notes. Export → Upload → Query. The workflow is lightweight and transforms your static notes into a conversational knowledge base.

Some people go further and combine both tools deliberately: research in NotebookLM, refine and organize in Notion AI. It's not seamless automation, but for knowledge workers it genuinely saves time.

What I'd improve

It's not perfect. A few things I've run into:

No native integrations beyond Google ecosystem: the Notion workaround requires manual steps
Context is notebook-scoped: you can't easily query across multiple notebooks at once
The free tier limits Audio Overviews: if you use it heavily, you'll hit the cap
Mobile experience is still catching up: some features are desktop-first

My honest take

If you're a developer who learns by reading documentation, research papers, or technical articles. NotebookLM is worth building into your workflow. It doesn't replace your thinking, but it removes a lot of the friction between having information and actually understanding it.

The Audio Overview alone changed how I use commute time. And for technical talks or study sessions where I need to synthesize across many sources quickly, it's become the tool I reach for first.

Try uploading your next RFC, architecture doc, or study material and just... talk to it. The bar for getting value out of it is surprisingly low.

Have you used NotebookLM in your dev workflow? I'd love to hear what's worked (or hasn't) for you in the comments.

Vibe Coding Meets Spec-Driven Development: The Best of Both Worlds

Tahirih Jaliri — Tue, 26 May 2026 22:54:18 +0000

Stop choosing between speed and structure, you don't have to.

The Tension Every Developer Feels

If you've been coding with AI assistants lately, you've probably experienced both extremes.

On one side: vibe coding, you open a chat, describe what you want in plain English, and let the model run. It feels like magic. You ship fast, you stay in flow, and the dopamine hits are real.

On the other side, there's a nagging feeling. The codebase starts to drift. A component does three things it shouldn't. A bug appears that you swear you didn't introduce. You ask the AI to fix it, and it breaks something else. The vibes turn chaotic.

Enter Spec-Driven Development (SDD), the idea that before you write (or generate) a single line of code, you write a specification: a clear, structured document that defines what you're building, why, and how it should behave. It's not a new concept, but it's having a renaissance in the age of AI coding.

The good news? You don't have to pick one. In fact, combining them is arguably the most productive way to build software today.

What Is Vibe Coding, Really?

The term was popularized by Andrej Karpathy in early 2025: "There's a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

It's characterized by:

Prompt-first, code-second thinking
High iteration speed
Minimal upfront planning
Trusting the model to fill in the blanks

Vibe coding shines for prototyping, exploration, and solo projects where speed matters more than maintainability. It's a legitimate and powerful workflow, but it has a ceiling.

What Is Spec-Driven Development?

SDD is the practice of writing a machine-readable (and human-readable) specification before implementation begins. A spec typically includes:

Goal: What problem are we solving?
Scope: What's in and what's explicitly out?
Functional requirements: What should the system do?
Non-functional requirements: Performance, security, scalability constraints
Data models / API contracts: The shape of the data
Acceptance criteria: How do we know it's done?

In an AI-assisted workflow, the spec becomes the single source of truth you feed into every prompt. Instead of re-explaining context each time, you anchor the model to a document it can reference.

Why Each Approach Alone Falls Short

Vibe Coding Without Specs

You: "Build me a user authentication system"
AI: *generates 300 lines of code*
You: "Actually add role-based access control"
AI: *refactors half the codebase*
You: "Wait, why is the session logic in the component?"
AI: "Good point, let me move it..."
You: *three hours later, untangling spaghetti*

Without a spec, the AI optimizes for your last message, not your actual goal. Every new prompt is a new negotiation with the model, and context drift is inevitable.

Spec-Driven Without the Vibe

Heavy specification processes can kill momentum. Writing a 10-page PRD before you know if an idea even works is a trap. You over-engineer requirements for problems you haven't validated. The spec becomes a bureaucratic artifact nobody reads.

The Hybrid Workflow: Spec First, Vibe Fast

The sweet spot is a lightweight spec that guides rapid AI-assisted implementation. Here's how it works in practice:

Step 1: Write a Minimal Viable Spec (MVS)

Before touching any AI coding tool, spend 15–30 minutes writing a short spec. It doesn't need to be formal, a markdown file works perfectly.

# Feature: User Authentication

## Goal
Allow users to register, log in, and manage sessions securely.

## Scope
- IN: Email/password registration, JWT sessions, logout
- OUT: OAuth, 2FA (next iteration)

## Data Model
User { id, email, passwordHash, createdAt, role: "user" | "admin" }
Session { token, userId, expiresAt }

## API Contracts
POST /auth/register  → { token, user }
POST /auth/login     → { token, user }
POST /auth/logout    → { success: boolean }
GET  /auth/me        → { user }

## Acceptance Criteria
- Passwords hashed with bcrypt (min 12 rounds)
- JWT expires in 7 days
- Invalid credentials return 401, never expose which field failed
- Logout invalidates the token server-side

That's it. Two hundred words that prevent hours of confusion.

Step 2: Use the Spec as Your Prompt Foundation

Every AI prompt now starts with context from the spec:

Given this spec: [paste relevant section]

Implement the POST /auth/register endpoint. Use bcrypt for 
hashing and return a signed JWT. Follow the data model defined above.

The model is no longer guessing your intent, it's executing against a contract.

Step 3: Vibe Within the Spec's Boundaries

Once the structure is in place, let the vibes flow. Need to add error handling? Optimize a query? Style a component? You can move fast because the foundation is solid. The spec sets the walls; the vibe coding furnishes the room.

Step 4: Update the Spec When Requirements Change

This is the discipline that separates good hybrid workflows from bad ones. When scope changes (and it will), update the spec first, then regenerate or refactor the code. Don't let the spec become stale documentation, it's a living contract.

Step 1: Edit spec.md → add OAuth section
Step 2: Prompt AI with updated spec section
Step 3: Let it implement

A Practical Example: Building a Task Manager

Let's say you want to build a simple task manager. Here's how the hybrid approach plays out:

Pure vibe approach:

"Build a task manager with React and Node"

You'll get something, but what database? What auth? What data model? You'll spend the next hour correcting assumptions.

Hybrid approach:

Write a 10-minute spec:

# Task Manager MVP

## Stack: React + Express + SQLite (simple, no Docker needed)
## Auth: None for MVP (single user, local app)

## Data Model
Task { id, title, status: "todo"|"in_progress"|"done", createdAt }

## UI Requirements
- List view grouped by status
- Add task via inline input
- Drag or click to change status
- No delete (archive instead)

## Out of Scope
- Multi-user, tags, due dates, notifications (v2)

Now your AI prompts are laser-focused:

"Using this spec, generate the Express API with SQLite. Only implement the endpoints needed for CRUD on tasks."

The result? Clean, predictable code that matches what you actually want.

Tools That Make This Workflow Shine

The spec-then-vibe approach pairs beautifully with AI tools that support long context or file-based prompting:

Claude: excellent at reasoning over long specs and maintaining consistency
Cursor / Windsurf: load your spec as a project rule or context file
GitHub Copilot Workspace: spec-to-code is literally the core feature
Claude Code: ideal for feeding specs through the CLI and maintaining context across sessions

The key is making your spec accessible to the AI at all times, not just in the first prompt.

When to Use Each Mode

Situation	Recommended Mode
Exploring a new idea	Pure vibe, validate fast
Building a feature in a production codebase	Spec first, always
Solo weekend project	Light spec (30 min max)
Team collaboration	Full spec with acceptance criteria
Debugging / fixing issues	Vibe with the existing spec as context
Greenfield product	Spec-driven from day one

The Mindset Shift

The biggest change isn't technical, it's philosophical. Vibe coding tempts you to treat the AI as an oracle: just ask and receive. Spec-driven development reminds you that you are still the architect. The AI is an extraordinary executor, but it needs direction.

When you combine both, you get something powerful: the speed of vibe coding without the chaos, and the structure of specs without the bureaucracy.

Think of it this way: specs are the map, vibe coding is the engine. You can drive fast, but you still need to know where you're going.

Getting Started Today

Next time you start a feature, write a 15-minute spec in markdown
Include: goal, scope boundaries, data model, and acceptance criteria
Paste the relevant section into every AI prompt
Update the spec before you update the code when things change
Ship fast within those boundaries

You'll be surprised how much less time you spend fixing AI hallucinations, and how much more time you spend shipping things that actually work.

Have you tried combining vibe coding with specs? What's your workflow? Drop a comment below, I'd love to hear how others are navigating this.

Exploring the Pros and Cons of Standalone Components in Angular

Tahirih Jaliri — Thu, 09 Nov 2023 23:41:26 +0000

Web development has made incredible progress over the years. I still recall the days when I development on JQuery and things often felt chaotic. With the advent of reactive programming and new development paradigms, it has become significantly more straightforward for developers to craft code that is not only cleaner but also more sustainable and scalable.
Angular, with its comprehensive toolkit, empowers developers to build dynamic and scalable web applications. Among its arsenal of features, standalone components stand out as a versatile tool for code organization. In this article, we'll dissect the advantages and disadvantages of integrating standalone components into your Angular projects.

Advantages:

1. Reusability and Modularity:

Standalone components encapsulate specific functionalities, promoting reusability. This modularity allows developers to integrate components seamlessly across various parts of the application or even across distinct projects.

2. Easy Maintenance:

Isolating functionality within standalone components simplifies maintenance and updates. Changes or bug fixes in one component do not affect others, reducing the risk of unintended consequences.

3. Clear Separation of Concerns:

Standalone components adhere to the Single Responsibility Principle (SRP), focusing on specific tasks or features. This promotes a clear separation of concerns, making code more organized and easier to understand.

Disadvantages:

1. Potential Overhead:

In smaller applications, the use of standalone components might introduce unnecessary complexity. The overhead of creating and managing numerous components can outweigh the benefits.

2. Communication Overhead:

While standalone components promote isolation, they may require additional effort to communicate with other parts of the application. This can lead to increased complexity in managing state and passing data between components.

Standalone components in Angular are a powerful tool for building modular and maintainable applications. By understanding their benefits and potential drawbacks, developers can leverage them effectively to create robust and scalable projects. Remember, the key lies in striking a balance and applying them judiciously according to the specific needs of your application.
Have you had the chance to dive into Standalone components? What are your thoughts on this approach?