DEV Community: David Kljajo

Stećak Oracle: Exploring Medieval Stone Monuments with Sanity and Gemini

David Kljajo — Sat, 19 Sep 2026 16:22:13 +0000

I decided to build something around a subject that is very close to where I live: stećci, the medieval tombstone monuments found across Bosnia and Herzegovina and neighboring countries.

The result is Stećak Oracle, a small knowledge-driven web application that combines Sanity, Next.js, and Google Gemini.

The idea is simple:

Store structured historical information in Sanity, then let an AI model answer questions using that information as its knowledge base.

This project was built for the Sanity Challenge.

The idea

Stećci are medieval tombstones found across Bosnia and Herzegovina, Croatia, Montenegro and Serbia.

There is a huge amount of historical information around them, but I wanted to approach the subject from a developer's perspective.

Instead of building another static website with paragraphs of text, I wanted to experiment with a small structured knowledge system.

The application would contain:

individual stećak records
locations
historical periods
descriptions
inscriptions
motifs
historical context
documented sources

Then I wanted to put an AI interface on top of that data.

That became Stećak Oracle.

Why Sanity?

The first important decision was how to structure the information.

I didn't want everything to be stored as one large JSON document or hardcoded directly into the application.

Sanity was a good fit because I could create actual content types and relationships between them.

The main content model became:

Stećak
 ├── Motifs
 ├── Sources
 └── Historical information

Motif
 ├── Description
 ├── Interpretations
 └── Interpretation caution

Source
 ├── Title
 ├── URL
 ├── Publisher
 ├── Type
 └── Notes

This also made the project more interesting from a development perspective.

The AI doesn't have to be the source of truth.

Sanity is the structured knowledge layer.

Gemini is the generation layer.

The content model

I created three main document types in Sanity.

Stećak

A stećak contains information such as:

name
slug
location
region
historical period
description
inscription
motifs
historical context
sources

For example, one of the records is:

Stećak Radimlja — Vojvoda Vlatko Vuković

with Radimlja near Stolac as the location.

Motif

Motifs are separate documents because the same motif can appear on multiple monuments.

For example, the project contains a Sword motif.

But there is an important detail here.

I didn't want to tell the AI that a particular interpretation is an absolute historical fact.

So the motif also contains an Interpretation Caution field.

That allows the application to distinguish between documented information and interpretation.

Source

Sources are separate documents as well.

For the initial dataset I used institutional information from the UNESCO World Heritage Centre, including the Stećci Medieval Tombstone Graveyards entry.

This gives the application a simple evidence layer rather than treating AI-generated text as the source itself.

Building the frontend

The frontend is built with Next.js and TypeScript.

The application has several main areas:

/
├── Home
├── /stecci
├── /stecci/[slug]
├── /motifs
├── /sources
└── /oracle

The homepage retrieves the current number of records directly from Sanity.

That means the statistics are not hardcoded.

If I add another stećak or source in Sanity, the application can reflect that change.

Stećak detail pages

Each stećak has its own dynamic page.

For example:

/stecci/stecak-radimlja-vojvoda-vlatko-vukovic

The page retrieves the document from Sanity using its slug.

It also dereferences related motifs and sources.

This was useful because the frontend doesn't need to duplicate the actual content model.

Sanity remains responsible for the data.

Adding the Oracle

The final piece was the AI interface.

The Oracle page allows a user to ask a question about:

stećci
motifs
history
documented evidence

For example:

What does the sword motif on the Radimlja stećak represent?

The frontend sends the question to a Next.js API route.

The basic flow is:

User
  ↓
Oracle UI
  ↓
Next.js API route
  ↓
Sanity
  ↓
Knowledge base
  ↓
Gemini
  ↓
Answer

Connecting Gemini

I initially experimented with the Anthropic API.

The API itself worked, but I didn't have API credits available, so I decided not to add another paid dependency to the project.

I switched to Google Gemini through the @google/genai package.

The application uses an environment variable for the API key:

GEMINI_API_KEY=...

The key is stored in .env.local and is excluded from Git.

The actual API request is made server-side through the Next.js API route.

This is important because the API key should not be exposed in browser-side JavaScript.

The important part: grounding Gemini with Sanity

This is probably the most important technical part of the project.

I didn't want to simply send the user's question to Gemini and display whatever it returned.

Instead, the API route first retrieves the knowledge base from Sanity.

Conceptually:

const knowledgeBase = await getKnowledgeBase()

The query retrieves:

Stećci
Motifs
Sources

including their relationships.

The resulting data is then serialized and included in the Gemini prompt.

The model receives something conceptually like:

Here is the knowledge base from Sanity:

{
  "stecci": [...],
  "motifs": [...],
  "sources": [...]
}

You are the Stećak Oracle...

Answer this question clearly and carefully:

[user question]

I also explicitly tell the model:

- Do not invent historical facts.
- Distinguish documented facts from interpretation.
- If the available information is insufficient, say so.
- Keep the answer concise.

For a small dataset like this, sending the complete knowledge base is simple enough.

For a much larger project, I would definitely replace this with retrieval of only the most relevant documents.

A real example

I tested the Oracle with:

What does the sword motif on the Radimlja stećak represent?

The response used the information stored in Sanity.

It identified the sword as a recurring figural motif and, importantly, preserved the caution around interpretation.

The answer did not present the interpretation as an absolute fact.

That distinction was intentional.

Historical subjects are a good example of why an AI application should be careful about the difference between:

documented information

and

interpretation

Why this approach?

One thing I wanted to avoid was building a generic chatbot and simply giving it a historical theme.

The interesting part of the project is the relationship between the CMS and the AI model.

The architecture is closer to:

             ┌───────────────┐
             │     User      │
             └───────┬───────┘
                     │
                     ▼
             ┌───────────────┐
             │    Next.js    │
             │    Frontend   │
             └───────┬───────┘
                     │
                     ▼
             ┌───────────────┐
             │  API Route    │
             └───────┬───────┘
                     │
             ┌───────┴────────┐
             ▼                ▼
      ┌────────────┐   ┌────────────┐
      │   Sanity   │   │   Gemini   │
      │ Knowledge  │──▶│    AI      │
      │   Base     │   │            │
      └────────────┘   └──────┬─────┘
                              │
                              ▼
                       ┌────────────┐
                       │   Answer   │
                       └────────────┘

Sanity provides the structured information.

Gemini turns that information into a natural-language answer.

Next.js connects everything together.

What I learned

The project ended up teaching me a few things that were more interesting than I expected.

1. Structured data matters

It is tempting to start an AI project with only a prompt.

But once you have structured content, relationships and sources, you can build something much more controlled.

The content model became just as important as the AI integration.

2. AI needs boundaries

For historical information, I don't want the model to confidently invent an interpretation.

That's why the knowledge base includes fields such as:

Interpretations
Interpretation Caution
Sources

The application can then give the model some context about how information should be treated.

3. A small dataset is enough to prove the concept

I didn't need hundreds of monuments to build the first version.

Two stećak records, a motif and documented sources were enough to demonstrate the architecture.

The important part was making the entire pipeline work.

4. Keep the architecture simple first

For this challenge, I intentionally didn't build a complicated vector database or RAG pipeline.

The dataset is small enough that retrieving the complete knowledge base is reasonable.

If the project grows, the architecture can evolve.

What I would improve next

There are several things I would add to a future version.

Better retrieval

Instead of sending every Sanity document to Gemini, I would retrieve only the documents relevant to the question.

For example:

Question
   ↓
Search Sanity
   ↓
Relevant stećak
Relevant motifs
Relevant sources
   ↓
Gemini

That would scale much better.

More stećci

The obvious next step is a larger dataset covering more locations across Bosnia and Herzegovina and the wider region.

Better source presentation

The next version could show sources directly underneath individual claims or sections of an answer.

That would make the evidence trail more visible.

Images

The current version is deliberately data-first.

I didn't have a suitable image collection for every monument, so I chose not to invent one or fill the application with unrelated images.

A future version could add properly sourced photographs and image metadata to the Sanity model.

Search and filtering

I would also add:

location filtering
region filtering
historical period filtering
motif filtering
full-text search

That would make the knowledge base useful even without the AI interface.

github repo:https://github.com/dkljajo/Ste-ak-Oracle-frontend-and-Gemini-integration

Technology stack

The current version uses:

Next.js
TypeScript
Tailwind CSS
Sanity
Google Gemini
@sanity/client
@google/genai
Git / GitHub

The application is intentionally small.

There is no separate backend service.

The Next.js API route handles the server-side Gemini request and retrieves the Sanity data.

Project structure

The important parts of the repository look roughly like this:

stecak-oracle/
├── studio/
│   ├── schemaTypes/
│   │   ├── stecak.ts
│   │   ├── motif.ts
│   │   └── source.ts
│   └── sanity.config.ts
│
└── web/
    ├── app/
    │   ├── api/
    │   │   └── oracle/
    │   │       └── route.ts
    │   ├── motifs/
    │   ├── oracle/
    │   ├── sources/
    │   └── stecci/
    └── lib/
        └── sanity.ts

This separation also makes the architecture easy to understand:

studio/
    → content model and Sanity configuration

web/
    → application and AI interface

Final result

Stećak Oracle started as a simple idea:

What if I could combine a structured historical knowledge base with an AI interface?

The final application is still small, but the complete pipeline works:

Sanity
  ↓
Structured historical knowledge
  ↓
Next.js
  ↓
Gemini
  ↓
Grounded answer

And that's what I wanted to demonstrate with this project.

Not a generic chatbot.

Not an AI that simply talks about stećci.

A small application where the content has structure, sources and relationships, and where the AI uses that content to generate an answer.

What's next?

There is a lot of room to take this further.

I would like to expand the dataset, improve retrieval, add properly sourced images, expose citations more clearly, and eventually turn the Oracle into a more complete exploration tool for stećci.

For now, I'm happy that the basic idea works end-to-end.

Project

The source code is available on GitHub:

Stećak Oracle — Sanity + Next.js + Gemini

https://github.com/dkljajo/Ste-ak-Oracle-frontend-and-Gemini-integration

Built for the Sanity Challenge

This project was built as my submission for the Sanity Challenge.

The challenge gave me a good excuse to combine several things I've been learning and working with: cloud technologies, application development, structured content, APIs and AI.

More importantly, it gave me a reason to build something connected to the history and culture of the region I live in.

That was the part I enjoyed most.

Conclusion

Stećak Oracle is a small project, but it brought together several technologies that I wanted to understand better.

Sanity handles the content.

Next.js handles the application.

Gemini handles the natural-language generation.

And the interesting part is what happens between them.

The result is a simple example of how a structured CMS can become the foundation for a grounded AI application.

Thanks for reading.

If you have ideas for improving the project, I'd be interested in hearing them.

I Built an AI Assistant for the Most Legendary Car in the Balkans

David Kljajo — Thu, 02 Apr 2026 04:09:36 +0000

This is a submission for the DEV April Fools Challenge

🚗 Golf 2 AI Assistant™

The first AI that thinks like a Balkan driver

What I Built

While the world is busy building AI for self-driving cars, I asked a more important question:

What if AI behaved like someone who refuses to sell their Volkswagen Golf Mk2?

So I built Golf 2 AI Assistant™ — a completely useless (but highly accurate) AI that:

ignores real data
gives confident but questionable advice
and always knows “a better way”

This is not artificial intelligence.
This is artificial Balkan intelligence.

Demo

🎬 Imagine this scenario:

You:

“Navigate to city center”

AI:

“Ma znam ja bolji put.”

What happens next:

You go through 3 random villages
You stop for coffee you didn’t plan
You question your life decisions

You arrive 30 minutes late.

AI:

“Eto vidiš, stigli smo.”

Code

function navigate(destination) {
  console.log("Ma znam ja bolji put.");

  const route = Math.random() > 0.5
    ? "prečica"
    : "duži ali sigurniji put (nije)";

  if (route === "prečica") {
    delay(30); // minutes
    stopAt("kafana");
  }

  return "Stigli smo nekako.";
}

function detectProblem(issue) {
  return "Ma nije to ništa.";
}

function fuelCheck(level) {
  if (level > 0) return "Ima još, ne brini.";
  return "Kako sad 0?!";
}

How I Built It

Tech stack:

TrustMeBro.js
LocalKnowledge v1986
console.log() for all outputs
Zero APIs, zero validation

Training data:

Balkan forums
YouTube comments
Unverified advice from relatives

Model accuracy: ❌
Model confidence: ✅ 100%

Features

🧔 Ćale Mode

Ignores GPS
Uses landmarks like “kod stare pumpe”

🚬 Kafana Mode

Suggests coffee every 5 minutes
Navigation becomes emotional

🧢 Majstor Mode

“Ma može još.”

All problems are temporary
Nothing is urgent
Everything lasts “još 10 godina”

🚔 Police Detection

“Ovdje uvijek stoje.”

(They don’t.)

🪑 Smart Parking™

Reserves parking using a virtual chair

Prize Category

Community Favorite

Because:

If you’re from the Balkans, this is not satire — it’s documentation
If you’re not, this is a cultural experience

Also, this project is spiritually aligned with Top lista nadrealista:
slightly absurd, deeply accurate, and completely unnecessary.

Final Thoughts

We don’t need smarter AI.

We need AI that:

insists it’s right
refuses better solutions
and somehow still gets the job done

If this gets enough love, I’ll ship:

Veza Mode™ (skip traffic via “connections”)
Remote Majstor API™ (“udari malo tu i radiće”)

Built with ❤️, stubbornness, and zero documentation.

Core Event-Driven Concepts - project 3

David Kljajo — Tue, 31 Mar 2026 06:04:42 +0000

Week 5 — Core Event-Driven Concepts

Learn (Day 1–2)

Understand:

🔹 SQS
Message queue
Stores tasks until processed
One consumer processes message
🔹 SNS
Pub/sub system
Sends same message to multiple subscribers
🔹 EventBridge
Smart event router
Filters and routes events based on rules

Extend Your Existing App (Day 2–3)

Start from your Phase 2 API (Orders or Users system).

Modify:

Instead of:
API → DB only
Now:
API → DB + Event Published

Example event:

{
"eventType": "ORDER_CREATED",
"orderId": "123",
"userId": "abc",
"timestamp": "..."
}

Add EventBridge (Day 3–4) Create: EventBridge Event Bus (custom bus) Flow: Order Lambda sends event → EventBridge Rule:

Route based on:

eventType = ORDER_CREATED

Create First Consumer (Day 4–5) Lambda: Email Simulation

Triggered by EventBridge

Does:

Logs email message like:

"Email sent to user for order 123"

👉 This simulates async email system

📅 Week 6 — Scale with SQS + SNS

Add SQS for Reliable Processing (Day 1–2) Use case:

Order processing queue

Flow:

EventBridge → SQS Queue → Lambda Consumer

Why:

Ensures no event is lost
Can retry automatically

Add SNS for Fan-out (Day 2–3) Use case:

One event → multiple systems

Flow:

Order Created → SNS Topic
↓ ↓ ↓
Email Analytics Logging

Each Lambda subscribes to SNS topic.

Build 3 Async Consumers (Day 3–4)

Create Lambdas:

📧 Email Service Lambda
📊 Analytics Lambda
🪵 Logging Lambda

Each one:

Triggered by SNS or SQS
Runs independently

Observability (Day 4–5)

Use:

CloudWatch logs
Event tracing

Check:

Event delivery
Lambda execution logs
Queue processing
🧠 Final Architecture (What you’ve built)

You now have:

🚀 Event-driven system:
API creates order
Event published
Multiple services react independently
🧩 Final Outcome Statement

After this phase, you can confidently say:

“I design event-driven systems using AWS services like SQS, SNS, and EventBridge to build scalable, decoupled architectures.”

AWS Serverless API Project Plan 2

David Kljajo — Tue, 31 Mar 2026 06:02:10 +0000

AWS Serverless API Project Plan
🎯 Goal

Convert your existing API into a fully serverless backend using:

AWS Lambda
Amazon API Gateway
Amazon DynamoDB
AWS IAM

Deploy using:

AWS SAM or Serverless Framework
📅 Week 3 — Foundations + First Serverless API

Learn (Day 1–2)

Focus only on what you need:

What is AWS Lambda (event-driven functions)
How API Gateway routes HTTP requests
DynamoDB basics (tables, items, keys)
IAM roles (what permissions Lambda needs)

👉 Key understanding:

API Gateway → triggers Lambda → reads/writes DynamoDB

Setup AWS Environment (Day 2) Create AWS account (if not already) Install: AWS CLI Node.js or Python runtime AWS SAM CLI (recommended) Configure CLI: aws configure
Build First Minimal Serverless API (Day 3–4) Create: 1 Lambda function: helloAPI 1 API Gateway route: GET /hello Flow:

Client → API Gateway → Lambda → Response

Outcome:

You successfully deploy your first serverless endpoint.

Add DynamoDB (Day 5) Create table:

Example:

Table: Users
Partition key: userId
Update Lambda:
Write a simple item into DynamoDB
Return stored data
📅 Week 4 — Full CRUD Serverless API

Build Full CRUD API (Day 1–3)

Create endpoints:

Method Route Action
POST /users Create user
GET /users/{id} Get user
PUT /users/{id} Update user
DELETE /users/{id} Delete user

Each endpoint = Lambda function OR single Lambda with routing logic.

IAM Roles (Day 3–4)

Give Lambda permissions:

Read/write DynamoDB
Basic execution logs (CloudWatch)

Learn:

Least privilege principle (only required permissions)

Deploy Using SAM or Serverless Framework (Day 4–5) Option A: AWS SAM (recommended) template.yaml sam build sam deploy Option B: Serverless Framework serverless.yml serverless deploy
Testing + Debugging (Day 5)

Test with:

Postman / Insomnia
AWS logs (CloudWatch)

Fix:

Permission errors
API route issues
DynamoDB key mismatches
🧠 Final Outcome (What you should be able to say)

After completing this phase, you can confidently say:

“I build and deploy serverless APIs on AWS using Lambda, API Gateway, and DynamoDB with proper IAM roles and infrastructure-as-code tools like SAM.”

Mini E-Commerce API (FastAPI + JWT) - project 1

David Kljajo — Tue, 31 Mar 2026 05:58:17 +0000

🚀 Project: Mini E-Commerce API (FastAPI + JWT)
🎯 What you’re building

A backend system with:

Users (auth system)
Products (CRUD)
Orders (user purchases)
JWT authentication
Clean architecture (like real production APIs)
🧱 Tech Stack
Python 3.11+
FastAPI
SQLAlchemy (ORM)
SQLite (start) → PostgreSQL later
JWT (python-jose)
Passlib (password hashing)
📁 Clean Project Structure (IMPORTANT)
app/
├── main.py
├── core/
│ ├── config.py
│ ├── security.py
│
├── database/
│ ├── db.py
│
├── models/
│ ├── user.py
│ ├── product.py
│ ├── order.py
│
├── schemas/
│ ├── user.py
│ ├── product.py
│ ├── order.py
│
├── routes/
│ ├── auth.py
│ ├── users.py
│ ├── products.py
│ ├── orders.py
│
├── services/
│ ├── user_service.py
│ ├── product_service.py
│ ├── order_service.py
│
├── dependencies/
│ ├── auth.py

This structure alone already makes your project look “production-grade”.

🔐 Features Breakdown
👤 Auth System
Register user
Login user
Password hashing (bcrypt)
JWT token generation
Protected routes
🛍️ Products (CRUD)
Create product (admin only)
Get all products (public)
Get single product
Update product (admin only)
Delete product (admin only)
🧾 Orders
Create order (user)
View own orders
Admin sees all orders
🔑 Core Learning Flow (build in this order)
STEP 1 — Setup
pip install fastapi uvicorn sqlalchemy passlib python-jose
STEP 2 — Run FastAPI

app/main.py

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def root():
return {"message": "API is running"}

Run:

uvicorn app.main:app --reload
STEP 3 — Add Database

Create SQLAlchemy models first (User, Product, Order)

STEP 4 — Auth (MOST IMPORTANT)
Register endpoint
Login endpoint
JWT token creation
Middleware to protect routes
STEP 5 — Products CRUD

Build full CRUD using:

routes
services layer (important for clean code)
STEP 6 — Orders System
User creates order from product
Reduce stock
Save order history

🚀 I Built a Netflix-Style AWS Learning App (V2) — Because Memorizing Isn’t Enough

David Kljajo — Mon, 30 Mar 2026 11:24:21 +0000

Most people prepare for the AWS Solutions Architect Associate (SAA) exam the same way:

They grind hundreds of practice questions.

I did that too.
And somewhere along the way, I realized something important:

👉 You don’t fail because you don’t know AWS services
👉 You fail because you don’t think like an architect

That realization changed everything.

📸 A Netflix-style AWS learning experience

💡 The Problem With Traditional Prep

Most SAA prep tools focus on:

memorizing service features
recognizing patterns in questions
eliminating wrong answers

That works… to a point.

But the real exam doesn’t test memory. It tests:

decision-making under constraints
understanding trade-offs
choosing the best solution, not just a correct one

And that’s where most people struggle.

🎬 So I Built Something Different

AWS SAA AI Coach — V2

Instead of another quiz app, I built a Netflix-style learning experience that trains how you think — not just what you know.

The idea was simple:

What if learning AWS felt like watching a series…
where each “episode” builds your architectural thinking?

🧠 How It Works

You choose your path:

📺 Learning Series

Learn like episodes — simple, structured, guided.

📈 Beginner → Advanced

Gradually move into real architectural challenges.

📝 Exam Mode

A full SAA-style simulation experience.

Then you pick a topic (or go “Mixed”, just like the real exam), and the app gives you:

a realistic AWS scenario
four possible answers (A / B / C / D)

📸 A realistic AWS scenario with multiple-choice decisions

Once you answer, you instantly get:

✔ whether you’re correct or not
📖 a concise explanation
⚖️ the trade-offs (cost, scalability, reliability)
🎯 the key takeaway

📸 Instant feedback with explanations and architectural trade-offs

🔥 What Makes It Different

This is not:

a quiz generator
a memorization tool

This is about thinking like an architect.

Every question:

uses multiple AWS services
reflects real-world business scenarios
includes realistic distractors (just like the exam)

⚡ What’s New in V2

I rebuilt a lot based on feedback and my own learning experience:

🎬 Learning Series — Netflix-style structured teaching
🧠 Scenario-first design — closer to the real exam
⚡ Faster, punchier explanations
🎯 Cleaner UX — click → answer → feedback

🧩 Example of the Mindset Shift

Instead of asking:

“What does S3 do?”

The app pushes you to think:

“Given cost constraints, high availability, and unpredictable traffic —
what’s the best architecture using S3, CloudFront, and maybe Lambda?”

That’s the real skill the exam is testing.

💭 Why I Built This

Because AWS SAA is not about knowing services.

It’s about:

making trade-offs
choosing the best possible solution
thinking in systems and architectures

I couldn’t find a tool that truly trains that — so I built one.

🎥 Demo

Here’s a quick demo of the app:

https://youtu.be/JCqOgLgkwR0

🙌 I’d Love Your Feedback

If you’re preparing for SAA — or already certified — I’m really curious:

👉 What was the hardest part of the exam for you?
👉 Was it specific services… or decision-making?

Also happy to share more about:

how I design the scenarios
how the AI generates explanations
what I’d improve in V3

If you want to see the original discussion and comments:

👉 https://www.linkedin.com/feed/update/urn:li:activity:7444140894670290944/

Thanks for reading 🙏

I Built a Netflix-Style AI App to Study AWS (And It Actually Works)

David Kljajo — Fri, 27 Mar 2026 23:30:52 +0000

Studying for the AWS Solutions Architect Associate exam felt… repetitive.

I was going through practice tests, selecting answers, checking results — but something was missing.

I wasn’t actually learning.

Most platforms tell you if you’re right or wrong, but they don’t really help you understand why. And after a while, it just becomes passive memorization.

So I thought:

What if learning AWS felt more like Netflix… and less like a textbook?

🧠 The Idea

Instead of static quizzes, I wanted something interactive.

Something where:

each question feels like a small “episode”
you pause and think before answering
and then get a clear explanation, like a post-scene breakdown

That’s when I decided to build a simple AI-powered learning app using AWS PartyRock.

⚙️ What I Built

I created a Netflix-style AI AWS SAA Coach that:

Generates AWS exam-style questions
Supports beginner and intermediate levels
Lets you answer in a real exam-like flow
Gives instant explanations after each answer
Helps you learn from mistakes instead of just scoring

The goal was simple:
👉 turn passive studying into active learning

🎥 Demo

I recorded a short walkthrough showing how it works in practice:

👉 https://www.youtube.com/watch?v=cMg6FF2ZbmQ

📸 How It Looks

💡 What I Learned Building This

This project made me realize something important:

Learning cloud concepts isn’t just about information — it’s about interaction.

When you:

think before answering
see immediate feedback
understand mistakes

You remember things much better.

🚧 It’s Still a Beta

Right now, the app focuses on:

beginner
intermediate questions

But after sharing it and getting feedback, one thing became clear:

👉 The AWS SAA exam is heavily based on real-world, multi-service scenarios

So the next step is to expand this into:

advanced-level questions
scenario-based challenges
multiple AWS services combined (VPC + S3 + Lambda, etc.)

Basically:

more real exam-style thinking

🚀 What’s Next

I want to evolve this into something that:

simulates real AWS exam scenarios
adapts to your weak areas
and keeps the “interactive learning” feel
🙌 Would Love Your Feedback

This started as a small experiment, but I think the idea has potential.

If you’re preparing for AWS SAA or working with AWS:

👉 What topics or scenarios did you find most challenging?

🍿 Final Thought

What if learning complex topics didn’t feel like studying…

…but more like watching and interacting with a series?

Full project: [https://github.com/dkljajo/aws-saa-ai-coach-partyrock]

Building My First Generative AI Journey with Kiro

David Kljajo — Sun, 22 Mar 2026 00:49:55 +0000

Originally published on Builder AWS by David Kljajo

I explored Generative AI by building real projects instead of just reading tutorials. Using Kiro, I experimented, iterated, and learned how to turn ideas into interactive outputs. This story shares my process, lessons learned, and my personal journey with screenshots along the way.

🚀 My Builder Journey into Generative AI

I didn’t start with a clear plan — I just knew I wanted to understand how Generative AI actually works beyond the hype.

At first, things were confusing. There were too many tools, too many tutorials, and a lot of theory that didn’t translate into real skills. Instead of trying to learn everything, I focused on building something small and practical. That’s when I started using Kiro.

🛠️ What I Built

Using Kiro, I explored how to:

Ask better prompts
Structure ideas into usable outputs
Turn concepts into something interactive

I experimented with different approaches, tested what worked, and improved step by step. It wasn’t perfect, but it was real progress.

📸 My Process (Screenshots)

🧠 Questions I Asked Kiro

Kiro Answer 1 (Career-Focused)

Question: What is the most practical GenAI certification path in 2026 if I want to build real-world projects and not just pass exams?

Answer from Kiro:

Foundations (free): DeepLearning.AI, LangChain Academy
Pick 1 Cloud Cert: AWS AI Practitioner, Google GenAI Engineer, or Azure AI-102
3 Real Projects:
- RAG chatbot
- AI agent with tools
- Full-stack AI product
Showcase: GitHub + live demos — projects > certs

Kiro Answer 2 (Learning + Strategy)

Question: Design a step-by-step roadmap to become certified in Generative AI, including free resources, hands-on projects, and how to stand out to employers.

Answer from Kiro:

Weeks 1-2: Learn AI basics & GenAI landscape
Weeks 3-6: Core stack: Python, LangChain, OpenAI API
Weeks 5-8: Build RAG chatbot
Weeks 8-14: Pass cloud cert
Weeks 12-20: Build AI agent + full-stack AI product
Ongoing: Post projects, contribute to open source, polish GitHub & LinkedIn

🧩 The Core Philosophy

Certifications alone won't get you hired or make you effective. The winning combo is: free/cheap foundational certs + cloud cert for credibility + a portfolio of 3 deployed projects.

Phase 1 — Foundation (1-2 months, mostly free)

DeepLearning.AI short courses — prompt engineering, LangChain, RAG, agents. Free, practical, 1-2 hours each
LangChain Academy — free, hands-on agent building
Fast.ai Practical Deep Learning — model-level understanding
Tools to get comfortable with: Python, LangChain/LangGraph, OpenAI/Anthropic APIs, vector DBs (Chroma, Pinecone, Weaviate), HuggingFace

Phase 2 — One Cloud Cert (pick based on your target job)

Target	Cert
AWS shops	AWS AI Practitioner → AWS ML Specialty
Google/GCP	Google Cloud GenAI Engineer
Microsoft/enterprise	Azure AI Engineer Associate (AI-102)
Vendor-neutral	IBM AI Engineering Professional (Coursera)

Phase 3 — The 3 Portfolio Projects That Actually Matter

RAG chatbot — ingest PDFs/docs, answer questions, deploy using LangChain + Chroma + frontend (Streamlit/FastAPI)
AI agent with tools — searches web, runs code, calls APIs (LangGraph/CrewAI)
Full-stack AI product — real use case, auth, deployed URL (AI assistant, code reviewer, domain Q&A)

Each project should have a GitHub repo, live demo, and write-up.

What to Skip

Generic "AI for everyone" certs with no coding
Paying for bootcamps before trying free resources
Chasing every framework — pick one (LangChain or LlamaIndex) and go deep

Realistic Timeline

Months	Focus
1-2	DeepLearning.AI courses + first RAG project
3-4	Cloud cert prep + agent project
5-6	Full-stack project + polish portfolio + apply

Stage-by-Stage Guide

Stage 1 — Get Your Bearings (Weeks 1-2, free)

3Blue1Brown Neural Networks series
DeepLearning.AI: Generative AI for Everyone
Read: “Attention Is All You Need” abstract + plain-English explainer

Stage 2 — Learn the Core Stack (Weeks 3-6, free)

DeepLearning.AI short courses
LangChain Academy — Introduction to LangGraph
HuggingFace free courses — NLP + Agents
Tools: Python, LangChain, OpenAI/Anthropic SDK, Chroma/FAISS, Streamlit, FastAPI, Docker basics

Stage 3 — First Real Project (Weeks 5-8)

Build a RAG chatbot with minimal stack: LangChain + Chroma + OpenAI API + Streamlit + deployed (Railway/Render free tier). Push to GitHub with README.

Stage 4 — Pick One Cloud Cert (Weeks 8-14)

AWS-heavy companies → AWS Certified AI Practitioner → ML Specialty
Google/GCP roles → Google Cloud GenAI Engineer
Enterprise/Microsoft → Azure AI Engineer Associate (AI-102)
Vendor-neutral → IBM AI Engineering Professional (Coursera)

Stage 5 — Build Remaining Portfolio Projects (Weeks 12-20)

Project 2 — AI Agent with Tools (multi-step tasks, research agent, uses LangGraph/CrewAI)
Project 3 — Full-stack AI Product (real use case, auth, live URL, FastAPI + React/Next.js + Supabase + Vercel/Railway)

Stage 6 — Stand Out to Employers (Ongoing)

LinkedIn posts, dev.to/Hashnode articles for projects
GitHub: pinned repos, clean READMEs, live demos
Open source contributions
Resume: projects > certifications, quantify impact

Certs get you past ATS filters; your portfolio gets the interview; your ability to explain projects gets the offer.

Originally published on Builder AWS

Building My First Generative AI Journey with Kiro

David Kljajo — Sun, 22 Mar 2026 00:49:55 +0000

Originally published on Builder AWS by David Kljajo

🚀 My Builder Journey into Generative AI

I didn’t start with a clear plan — I just knew I wanted to understand how Generative AI actually works beyond the hype.

🛠️ What I Built

Using Kiro, I explored how to:

Ask better prompts
Structure ideas into usable outputs
Turn concepts into something interactive

I experimented with different approaches, tested what worked, and improved step by step. It wasn’t perfect, but it was real progress.

📸 My Process (Screenshots)

🧠 Questions I Asked Kiro

Kiro Answer 1 (Career-Focused)

Question: What is the most practical GenAI certification path in 2026 if I want to build real-world projects and not just pass exams?

Answer from Kiro:

Foundations (free): DeepLearning.AI, LangChain Academy
Pick 1 Cloud Cert: AWS AI Practitioner, Google GenAI Engineer, or Azure AI-102
3 Real Projects:
- RAG chatbot
- AI agent with tools
- Full-stack AI product
Showcase: GitHub + live demos — projects > certs

Weeks 1-2: Learn AI basics & GenAI landscape
Weeks 3-6: Core stack: Python, LangChain, OpenAI API
Weeks 5-8: Build RAG chatbot
Weeks 8-14: Pass cloud cert
Weeks 12-20: Build AI agent + full-stack AI product
Ongoing: Post projects, contribute to open source, polish GitHub & LinkedIn

🧩 The Core Philosophy

Certifications alone won't get you hired or make you effective. The winning combo is: free/cheap foundational certs + cloud cert for credibility + a portfolio of 3 deployed projects.

Phase 1 — Foundation (1-2 months, mostly free)

DeepLearning.AI short courses — prompt engineering, LangChain, RAG, agents. Free, practical, 1-2 hours each
LangChain Academy — free, hands-on agent building
Fast.ai Practical Deep Learning — model-level understanding
Tools to get comfortable with: Python, LangChain/LangGraph, OpenAI/Anthropic APIs, vector DBs (Chroma, Pinecone, Weaviate), HuggingFace

Phase 2 — One Cloud Cert (pick based on your target job)

Target	Cert
AWS shops	AWS AI Practitioner → AWS ML Specialty
Google/GCP	Google Cloud GenAI Engineer
Microsoft/enterprise	Azure AI Engineer Associate (AI-102)
Vendor-neutral	IBM AI Engineering Professional (Coursera)

Phase 3 — The 3 Portfolio Projects That Actually Matter

RAG chatbot — ingest PDFs/docs, answer questions, deploy using LangChain + Chroma + frontend (Streamlit/FastAPI)
AI agent with tools — searches web, runs code, calls APIs (LangGraph/CrewAI)
Full-stack AI product — real use case, auth, deployed URL (AI assistant, code reviewer, domain Q&A)

Each project should have a GitHub repo, live demo, and write-up.

What to Skip

Generic "AI for everyone" certs with no coding
Paying for bootcamps before trying free resources
Chasing every framework — pick one (LangChain or LlamaIndex) and go deep

Realistic Timeline

Months	Focus
1-2	DeepLearning.AI courses + first RAG project
3-4	Cloud cert prep + agent project
5-6	Full-stack project + polish portfolio + apply

Stage-by-Stage Guide

Stage 1 — Get Your Bearings (Weeks 1-2, free)

3Blue1Brown Neural Networks series
DeepLearning.AI: Generative AI for Everyone
Read: “Attention Is All You Need” abstract + plain-English explainer

Stage 2 — Learn the Core Stack (Weeks 3-6, free)

DeepLearning.AI short courses
LangChain Academy — Introduction to LangGraph
HuggingFace free courses — NLP + Agents
Tools: Python, LangChain, OpenAI/Anthropic SDK, Chroma/FAISS, Streamlit, FastAPI, Docker basics

Stage 3 — First Real Project (Weeks 5-8)

Build a RAG chatbot with minimal stack: LangChain + Chroma + OpenAI API + Streamlit + deployed (Railway/Render free tier). Push to GitHub with README.

Stage 4 — Pick One Cloud Cert (Weeks 8-14)

AWS-heavy companies → AWS Certified AI Practitioner → ML Specialty
Google/GCP roles → Google Cloud GenAI Engineer
Enterprise/Microsoft → Azure AI Engineer Associate (AI-102)
Vendor-neutral → IBM AI Engineering Professional (Coursera)

Stage 5 — Build Remaining Portfolio Projects (Weeks 12-20)

Project 2 — AI Agent with Tools (multi-step tasks, research agent, uses LangGraph/CrewAI)
Project 3 — Full-stack AI Product (real use case, auth, live URL, FastAPI + React/Next.js + Supabase + Vercel/Railway)

Stage 6 — Stand Out to Employers (Ongoing)

LinkedIn posts, dev.to/Hashnode articles for projects
GitHub: pinned repos, clean READMEs, live demos
Open source contributions
Resume: projects > certifications, quantify impact

Certs get you past ATS filters; your portfolio gets the interview; your ability to explain projects gets the offer.

Originally published on Builder AWS

DEV Community: David Kljajo

Stećak Oracle: Exploring Medieval Stone Monuments with Sanity and Gemini

The idea

Why Sanity?

The content model

Stećak

Motif

Source

Building the frontend

Stećak detail pages

Adding the Oracle

Connecting Gemini

The important part: grounding Gemini with Sanity

A real example

Why this approach?

What I learned

1. Structured data matters

2. AI needs boundaries

3. A small dataset is enough to prove the concept

4. Keep the architecture simple first

What I would improve next

Better retrieval

More stećci

Better source presentation

Images

Search and filtering

Technology stack

Project structure

Final result

What's next?

Project

Built for the Sanity Challenge

Conclusion

Tags

I Built an AI Assistant for the Most Legendary Car in the Balkans

🚗 Golf 2 AI Assistant™

The first AI that thinks like a Balkan driver

What I Built

Demo

Code

How I Built It

Features

🧔 Ćale Mode

🚬 Kafana Mode

🧢 Majstor Mode

🚔 Police Detection

🪑 Smart Parking™

Prize Category

Final Thoughts

Core Event-Driven Concepts - project 3

AWS Serverless API Project Plan 2

Mini E-Commerce API (FastAPI + JWT) - project 1

app/main.py

🚀 I Built a Netflix-Style AWS Learning App (V2) — Because Memorizing Isn’t Enough

💡 The Problem With Traditional Prep

🎬 So I Built Something Different

AWS SAA AI Coach — V2

🧠 How It Works

📺 Learning Series

📈 Beginner → Advanced

📝 Exam Mode

🔥 What Makes It Different

⚡ What’s New in V2

🧩 Example of the Mindset Shift

💭 Why I Built This

🎥 Demo

🙌 I’d Love Your Feedback

👉 https://www.linkedin.com/feed/update/urn:li:activity:7444140894670290944/

I Built a Netflix-Style AI App to Study AWS (And It Actually Works)

Building My First Generative AI Journey with Kiro

🚀 My Builder Journey into Generative AI

🛠️ What I Built

📸 My Process (Screenshots)

🧠 Questions I Asked Kiro

🧩 The Core Philosophy

Phase 1 — Foundation (1-2 months, mostly free)

Phase 2 — One Cloud Cert (pick based on your target job)

Phase 3 — The 3 Portfolio Projects That Actually Matter

What to Skip

Realistic Timeline