Yapay Zeka

I’m 16, self-taught, and currently studying for my AWS Solutions Architect Associate certification. Alongside the course, I’m building a production-grade AWS infrastructure from scrach and documenting the entire journey here

Why?

Honestly, because certs alone don’t porve you can build anything. I want something real to show for it, So writing infrastruction that reflects how things are done in production and not just dwelling inside tutorial hell. Writing about it publicly keeps me accountable.

What is my stack?

• Cloud: AWS
• Infrastructure as Code: Terraform (I decided to keep it modular with seperate dev and prod environments)
• CI/CD : Github Actions
• Containerization: Docker + Trivy (for container scanning)
• Application: A minimal PERN stack notes app

Heres what my folder structure looks like

aws-production-infra/
├── modules/ # reusable Terraform modules
│ ├── vpc/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ ├── outputs.tf
│ │ └── README.md
│ ├── ec2-asg/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ └── outputs.tf
│ ├── alb/
│ ├── rds/
│ ├── s3-cdn/
│ ├── iam/
│ ├── security/
│ └── monitoring/
├── environments/
│ ├── dev/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ ├── terraform.tfvars
│ │ └── backend.tf
│ └── prod/
├── app/
│ ├── Dockerfile
│ └── src/
├── .github/
│ └── workflows/
│ ├── terraform-plan.yml
│ └── docker-build.yml
├── docs/
│ ├── architecture.svg
│ └── cost-estimate.md
├── scripts/
│ └── destroy-expensive.sh
├── .gitignore
└── README.md


They key decision I did here is seperating the modules/ folder from environments/. Both environments call the same modules but with different variable values. Dev runs cheaper, single AZ resources purely for developing purposes while Prod runs Multi-AZ, larger instances in a more contained and secure setting.

What I’ve done so far

The folder structure is set up and the application code is in the repo. I vibe-coded the entire PERN app to save time, and honestly the infrastructure is what its all about.

My build order is

1. – Write all the terraform infrastructure first.
2. – Write the Dockerfile and get Trivy scanning running in CI
3. – Wire everything together with the GitHub actions deployment pipeline

Next post will cover building the VPC modules (building subnets, route tables, NAT gateway, and flow logs)

Repo is here if you want to follow along: https://github.com/KithupaG/aws-production-infra

Google’s latest announcements for agentic AI are more than just a new model. The release of Gemini 3.5 Flash and the Antigravity 2.0 development platform signals a shift from prompt-driven exploration to a more grounded, local-first engineering workflow for building agents. This matters because it changes the development loop from a slow, cloud-based iteration cycle to a faster, more tangible one on your own machine.

what changed: a fast model and a local orchestrator

Two main components define this shift. First is Gemini 3.5 Flash, a new model engineered for speed and efficiency in agentic workflows. It reportedly outperforms Gemini 3.1 Pro on most benchmarks while running significantly faster. This model is positioned as the high-speed engine needed for agents that must perform complex, long-horizon tasks with low latency.

The second, and more significant, piece is Antigravity 2.0. This is not just an API update; it’s a standalone desktop application designed to be a central hub for agent interaction and orchestration. The platform is designed for developers to take an idea and build a production-ready application. This local-first approach allows for managing multiple agents in parallel, scheduling background tasks, and integrating directly with tools like Google AI Studio, Android, and Firebase.

why it matters: from prompting to engineering

For the last couple of years, building with large models has felt like working through a keyhole. You write a prompt, send it to a remote API, and get a response. Building agents required stringing these calls together with scripts and cloud functions. It worked, but it lacked the immediacy of traditional software development.

Antigravity 2.0 changes this dynamic. By providing a desktop application and a command-line interface (CLI), it treats agent development less like prompt engineering and more like systems engineering. The ability to orchestrate and deploy agents that can execute tasks in parallel from your local machine is a meaningful change. It encourages you to think about agentic systems as a collection of specialized workers, not a single monolithic model. This move from a simple request-response model to a managed, multi-agent system is where the real productivity gains will come from.

getting started with the new stack

Developers can access Gemini 3.5 Flash through Google AI Studio and what Google is calling Managed Agents in the Gemini API. The managed agent approach aims to remove the friction of infrastructure setup by delivering the power of the Antigravity agent harness through the API.

For local development, the Antigravity CLI provides a more direct interface. While the exact commands are still being documented, one could imagine a workflow for deploying a managed agent looking something like this:

# Fictional CLI command based on described capabilities

antigravity agents:deploy --name="daily-report-agent" 
  --model="gemini-3.5-flash" 
  --trigger="schedule --cron='0 9 * * *'" 
  --task-file="./tasks/generate_report.json" 
  --tools="google.workspace.sheets,google.workspace.docs"

This workflow, combining a powerful local CLI with cloud-managed execution, feels much closer to modern DevOps practices than the ad-hoc scripting that has characterized agent-building to date. Google AI Studio is also getting more integrated, with a new feature to export entire projects to Antigravity for local development and production deployment with a single click.

the takeaway for builders

This year’s I/O updates are a clear signal that the infrastructure for building AI agents is maturing. The focus is shifting from the raw capability of a single model to the developer experience of building, testing, and deploying robust, multi-agent systems. We’re moving from an era of AI that assists you to one where agents can independently navigate complex tasks across an entire workflow.

For engineers in the space, the message is clear: the tooling is catching up to the ambition. It’s time to start thinking about agentic workflows not as a series of prompts, but as engineered systems that you can build and control from your own machine.

Sources

• Google I/O 2026 Developer Highlights

If you use more than one AI coding tool — Claude Code, Cursor, Copilot, Windsurf — you’ve probably hit this:

You ask one to build a feature. It does something reasonable. You ask another to extend it. It contradicts the first. You ask a third to clean up. Now you have three different interpretations of what the system should do.

This isn’t a bug in any of the tools. It’s a missing source of truth.

What I built

A Claude skill called spec-driven-development that generates three files before any code is written:

requirements.md  — what the system must do (REQ-xxx IDs, acceptance criteria)
design.md        — how it will be built (data models, endpoints, file structure)
tasks.md         — atomic ordered steps, each linked to a requirement

Then it generates matching AI config files for every tool you use:

CLAUDE.md                          ← Claude Code reads this automatically
.cursorrules                       ← Cursor
.windsurfrules                     ← Windsurf
.github/copilot-instructions.md    ← GitHub Copilot
.aider.conf.yml                    ← Aider

Each config file contains the same Universal Instruction Block — identical constraint rules pointing every agent at the same spec files. They can’t drift because they all defer to the same authority.

The session continuity problem

There’s a fourth file: CONTEXT.md. It’s a session journal. When your context window fills and you start a fresh Claude Code session, Claude reads CONTEXT.md first and announces:

“Session 4 resuming. Last session we completed TASK-005 (JWT middleware). Active task is TASK-007 — POST /tasks implementation. Ready to continue.”

No re-explaining. No lost context. Just continuation.

It works for existing codebases too

If you already have code but no specs, the retrofit workflow reverse-engineers them from what you describe. Fields that weren’t explicitly confirmed get marked [TO VERIFY]. The first phase of tasks.md is always “Spec Verification” — tasks that confirm the spec actually matches the live code before any new work starts.

How I validated it

I didn’t just ship it and hope. I built a proper test suite:

Phase 2A — Static assertions (67 checks)
A Python script that checks SKILL.md and reference files for structural correctness. Runs in GitHub Actions CI on every push.

Phase 2B — Behavioral tests (15 prompts)
Run in a live Claude Code session. For each prompt, Claude simulates a full response before looking at the assertions — blind evaluation. Tests include “continue where we left off” (CONTEXT.md present) and “what are we working on?” (CONTEXT.md absent).

Phase 2C — Generation quality (53 checks)
Three full end-to-end flows: greenfield project, retrofit codebase, cross-AI configuration. Claude Code generates real files, a Python checker validates every file. These run in CI against committed fixtures.

Total: 135 assertions. All passing. CI is green.

The test suite ships with the skill. Every future change must pass before merging.

What I still need

The 135 assertions were written by me, so they test what I anticipated. What they don’t test: a stranger saying “help me get organised” or “scaffold me a project” — phrasing I didn’t think of.

That’s the beta.

I’m looking for 5 testers:

All you do is use it naturally on your real work and file GitHub Issues when something doesn’t work. One issue per problem. Include the exact phrase you used — that’s the most valuable data.

Repo (MIT): https://github.com/FredAntB/Spec-Driven-Development

Open an issue titled [Beta] I'd like to test and describe which profile fits you. I’ll get back to you within 24 hours.

This is a submission for the Google I/O Writing Challenge

I had barely caught up from my email backlog and the disorienting reality distortion field as a City known as Las Vegas for Google Next when Google I/O creeped up.

So once again I found myself in a middle seat on a 777 with spotty WiFi headed to the Mecca of all things tech for Google IO 2026.

Mountain View is in many ways more dangerous than Vegas. With Vegas- the gaudiness is front and center- but Silicon Valley the danger is much more subtle.

Instead of Neon lights there are always pitfalls like the next performance-maxxing Founder bro that wants to do a 9-9-6 for the startup because of his Tik-Tok Feed.

In this era of the AI Job Apocalypse – I am surprised it hasn’t morphed into 12-12-7 – with DNA testing Gattica style- but I am sure that it is coming.

I digress.

So Google I/O is in full swing. The first job at any Google event is decoding the symbols on your badge. One of the key benefits of the GDE program is early access and preferred seating.

This doesn’t sound like much but it gets you into to the massive Keynotes and if you get there early – a great seat.

I had pretty much figured out the “E” on the badge was early access – but it took some asking around to figure out what the other symbols were. Don’t trust the first guy you ask- they are usually temp staff just on hand for the big event.

Main Keynote

So somehow by sheer luck and grit- I ended up front row for the Keynote with a swarm of my fellow GDES. I guess the early bird gets the worm sometimes.

I am surprised my phone battery held up as I kept posting pics almost unedited to my Linked In feed.

The first thing that jumped out was numbers. Mind boggling numbers.

AI is mainstreaming new numerical terms. A Quadrillion Tokens?

You bet!

Maybe that will be enough for a tank of gas in the post apocalypse.

What followed was a non-stop barrage of new stuff:

• Gemini 3.5: the latest family of models–starting with Gemini 3.5 Flash.

• Gemini Omni: Nano Banana on steroids

• Google Antigravity: One platform to rule them all!

• Gemini Spark: Your very own corporate Open-Claw.

Probably the biggest impact for me personally was the sun-setting of Gemini CLI. I am a huge stan. But I get it. Why support two tools when one can do the job?

Dev Keynote

After scrounging for some chocolate chip cookies and more coffee- I finally had a chance to install the Antigravity CLI.

Before the keynote started I had the whole thing working end-to-end on my Chromebook. Definately some growing pains – but there is a transition period to get the Gemini CLI configs moved over.

What followed was a barrage of product announcements and Live demos.

The presentations were definitely more cohesive- as it seemed like a bigger picture was coming together across the entire Google Tech stack. It still wasn’t there but you could see palpable progress.

Then the real IO started.

Wandering around the Shoreline campus running into friends – old and new. Some that I had met only virtually and some from previous wanderings.

This is where the real discussions got interesting. I found the dialogues revolving around key themes.

Google Books / Aluminum OS / Android / Chrome OS Flex. There are so many goals with this one- I hope it can hit all the marks.

Gemma4. The whole family of models have been running like a champ.

A2A. For now- but cross agent and cross cloud are going to drive new protocols.

Looker MCP. I can finally do Looker!

Oauth. You can’t do much without it- but so complicated!

What’s next?

Day 2.

More sessions and an NVidia Event.

Maybe if I ask really nice I can get some more GPU credits. They never last.

Glassmorphism in 2026: Designing Stunning Frosted Glass Elements with Pure CSS

Grab a coffee and get comfortable. Let us talk about UI depth. You know that visual fatigue we all get from flat, boring rectangular blocks? Users feel it too. For years, designers have wanted to bring real-world textures into digital interfaces. Enter Glassmorphism—the frosted glass effect that blends your UI panels smoothly into the background, creating a high-end, premium feel. It is not just a trend that refused to die; in 2026, it is a fully mature, production-ready styling standard.

In this quick article, we will break down how to implement a high-performance, accessible, and breathtaking frosted glass effect using pure, modern CSS without breaking your layout or killing your frame rates.

How We Suffered Before

If you were building interfaces a few years ago, achieving a frosted glass look was absolute torture. Do you remember the hacks? We had to:

• Duplicate the background image, apply a heavy CSS blur filter to it, position it absolutely behind the content card, and manually align the coordinates. One pixel of misalignment, and the illusion was completely shattered.
• Use heavy JavaScript libraries to calculate container positions on scroll and dynamic canvas-based blurs. This was a nightmare for performance, leading to laggy scrolling and massive battery drain on mobile devices.
• Resort to static pre-rendered blurred background images, which made responsive layouts and dynamic themes practically impossible.

It was messy, hard to maintain, and a nightmare for accessibility. Fortunately, those dark days are long gone.

The Modern Way in 2026

Today, the frosted glass effect is incredibly clean and native. We rely on the highly optimized backdrop-filter property. This property applies graphic effects—such as blurring or color shifting—to the area behind an element.

To make the glass effect look truly premium, you need a precise combination of four CSS ingredients:

• Backdrop Filter: The core engine. We use backdrop-filter: blur(16px); to diffuse whatever is behind our card.
• Translucent Background: A highly transparent background color (typically a white or dark RGBA/HSLA fill with 0.1 to 0.35 opacity) to act as the glass surface.
• A “Specular Highlight” Border: A thin, semi-transparent border to simulate the reflecting edge of real glass.
• CSS Variables: For ultimate scalability. If you want to keep your UI theme highly maintainable while swapping colors on these glass surfaces, you should definitely read about Why Variables (CSS Variables) Are the Foundation of Scalable Design.

To make these animations truly butter-smooth and type-safe, we can combine our glass transition with the @property rule. Check out our guide on Strict Typing of CSS Variables with the @property Rule to see how to animate custom gradients behind your glass panels.

Ready-to-Use Code Snippet

Here is a complete, production-ready, pure CSS glassmorphic card component. Just drop it into your project and watch the magic happen.

<!-- HTML Structure -->
<div class="glass-container">
  <div class="glass-card">
    <h3>Premium Glassmorphism</h3>
    <p>This is a modern frosted glass card built with pure CSS. Notice how perfectly it blurs the colorful background shapes behind it.</p>
    <button class="glass-btn">Explore More</button>
  </div>
</div>

<style>
/* Interactive styling background to show off the glass blur */
.glass-container {
  position: relative;
  display: flex;
  justify-content: center;
  align-items: center;
  min-height: 400px;
  background: radial-gradient(circle at 20% 30%, #ff4b5c 0%, transparent 40%),
              radial-gradient(circle at 80% 70%, #1e90ff 0%, transparent 45%),
              #111318;
  padding: 2rem;
  border-radius: 16px;
  overflow: hidden;
}

/* The magic Glass Card */
.glass-card {
  --glass-bg: rgba(255, 255, 255, 0.08);
  --glass-border: rgba(255, 255, 255, 0.15);
  --glass-blur: 16px;

  position: relative;
  width: 100%;
  max-width: 400px;
  padding: 2.5rem;
  border-radius: 24px;
  background: var(--glass-bg);
  border: 1px solid var(--glass-border);
  color: #ffffff;
  
  /* Applying the magic glass blur filter */
  backdrop-filter: blur(var(--glass-blur));
  -webkit-backdrop-filter: blur(var(--glass-blur)); /* Safari compatibility */
  
  /* Smooth scale-up and shadow transition */
  box-shadow: 0 8px 32px 0 rgba(0, 0, 0, 0.3);
  transition: transform 0.3s ease, box-shadow 0.3s ease;
}

.glass-card:hover {
  transform: translateY(-4px);
  box-shadow: 0 12px 40px 0 rgba(0, 0, 0, 0.45);
}

.glass-card h3 {
  font-size: 1.5rem;
  margin-top: 0;
  margin-bottom: 0.75rem;
  font-weight: 600;
  letter-spacing: -0.5px;
}

.glass-card p {
  font-size: 0.95rem;
  line-height: 1.6;
  color: rgba(255, 255, 255, 0.8);
  margin-bottom: 1.5rem;
}

/* Styled glass button */
.glass-btn {
  background: #ffffff;
  color: #111318;
  border: none;
  padding: 0.75rem 1.5rem;
  border-radius: 12px;
  font-weight: 600;
  cursor: pointer;
  transition: opacity 0.2s ease;
}

.glass-btn:hover {
  opacity: 0.9;
}
</style>

Common Beginner Mistakes

While the modern glass effect is incredibly simple to implement, many developers still trip over these classic pitfalls:

• Setting the Opacity to 0: If you set your card’s background to rgba(255, 255, 255, 0), the glass effect completely vanishes. You need at least a tiny bit of color fill (e.g., 0.05 or 0.1) so the browser’s rendering engine can layer the glass texture properly over the background.
• Forgetting Safari Compatibility: Apple invented this style, but Safari still requires the prefix -webkit-backdrop-filter to render the blur smoothly. If you forget this prefix, iOS users will see a standard, flat grey box.
• Accessibility Issues (Contrast Ratios): White text on a light glass container over a dynamic background is a nightmare for users with visual impairments. Make sure to keep your background tinted dark enough (or light enough, if using dark text) and test your contrast ratios under different background states.

Wrap your CSS properly, avoid these silly mistakes, and you will easily deliver an interface that looks sleek, futuristic, and professional.

🔥 We publish more advanced CSS tricks, ready-to-use snippets, and tutorials in our Telegram channel. Subscribe so you don’t miss out!