DEV Community: Isah Alamin

I Was Tired of Explaining My Project to Every New AI Tab I Opened

Isah Alamin — Thu, 19 Mar 2026 21:20:56 +0000

This is a submission for the Notion MCP Challenge

What I Built

Let me describe something that happened to me and I am willing to bet it has happened to you too.

I was deep in a conversation with Claude. Twenty minutes in. I had explained my entire project, the stack, the decisions, the architecture. It finally got it. The momentum was real. The advice was flowing.

And then I needed to actually write the code.

I opened VS Code. I opened GitHub Copilot. And it hit me Copilot had absolutely no idea what Claude and I had just spent twenty minutes figuring out. Zero. I was back to square one. So I did what every developer does in that moment I started copying and pasting. Grabbing chunks of the Claude conversation, dumping them into Copilot, basically summarizing my own conversation to a completely different AI just to get it up to speed.

That is not a workflow. That is a tax. And I was paying it every single day.

The real problem is not that AI tools are not smart enough. They are brilliant. The problem is that they do not share memory. Each tool is an island. Claude does not know what Copilot knows. Copilot does not know what Claude knows. And you the developer are the only bridge between them. Manually. Every time.

I built the Notion Memory Engine to burn that bridge down and replace it with something permanent.

It is a system that turns Notion into a single shared brain for all your AI tools using Notion MCP. You finish a conversation in Claude, type @memory -create, and Claude writes the full context decisions, code snippets, next steps directly into your Notion database. Then you open VS Code, ask GitHub Copilot about the same topic, and it reads from that exact same Notion database and picks up right where Claude left off.

Same context. Different tool. No copy pasting. No starting over. No tax.

Video Demo

Show us the code

Bits232 / notion-memory-engine

A cross tool AI memory system using Notion MCP to save context in Claude, continue in VS Code Copilot. Built for the DEV.to x Notion MCP Challenge

🧠 Notion Memory Engine

One Notion workspace. Multiple AI tools. Zero context loss.

The Problem

You are deep in a conversation with Claude. Twenty minutes in. You have explained your entire project — the stack, the architecture, the decisions. The advice is flowing. The momentum is real.

And then you need to actually write the code.

You open VS Code. You open GitHub Copilot. And it hits you — Copilot has no idea what you and Claude just talked about. So you start copying and pasting. Grabbing context from one tab, dumping it into another. Summarizing your own conversation just to get a different AI up to speed.

This is the invisible tax every developer pays when working with multiple AI tools.

The Solution

The Notion Memory Engine turns Notion into a single shared brain for all your AI tools using the Notion MCP (Model Context Protocol).

Claude reads…

View on GitHub

The repo contains everything you need to replicate this from scratch:

system-prompt.md — the full protocol page to paste into Notion
notion-setup.md — how to set up your workspace
claude-setup.md — connecting Notion MCP to Claude
vscode-setup.md — connecting Notion MCP to VS Code Copilot
other-tools.md — extending to Cursor, Windsurf, Claude Desktop, and more

How I Used Notion MCP

Notion MCP is not a feature in this project. It is the entire foundation. Without it, none of this exists.

Here is exactly what it enables step by step:

1. Notion holds the System Prompt that gives Claude its behavior

The entire memory protocol, the rules, the commands, the safeguards lives inside a single Notion page called System Prompt. When you start a new conversation, you send Claude one message:

Please read my Notion page titled "System Prompt" and follow the protocol.

Claude reaches into Notion via MCP, reads that page, and responds with the initialization handshake:

🧠 Memory Engine Online
Ready for @memory commands.

That is it. The engine is live. And because the protocol lives in Notion, you can change Claude's behavior anytime just by editing a page — no code, no config files, no redeployment.

The System Prompt page — one Notion page that controls Claude's entire memory behavior

2. Claude saves your conversations directly into Notion on command

When you are deep in a conversation and want to preserve it, you type:

@memory -create medium

Claude looks at the entire conversation, generates a descriptive title, picks a category, writes a full technical summary with code snippets and next steps, and saves it into your Notion database through MCP. Live. While you watch.

Claude initializing after reading the System Prompt from Notion via MCP

Claude confirming it saved the conversation context directly into Notion

3. The entry appears in Notion instantly

Switch to Notion right after and the new entry is already there — title, category, and the full technical content Claude just wrote.

The entry Claude just created — structured, searchable, permanent

4. All connected AI reads from the same database

This is the moment the whole system clicks.

Every AI connects to the same Notion workspace through its own independent MCP connection. It has never seen your Claude conversation. It does not know your project. But when you ask it:

"What do we have saved about our project in Notion?"

It reaches into the same database, finds Claude's entry, and responds with full context ready to continue exactly where you left off. Two completely separate AI tools. One shared brain.

VS Code Copilot reading the same Notion database — no copy pasting, no context loss

Updating the memory after working in VS Code, the same entry in Notion now reflects the latest progress

5. The Unique Title Rule keeps your database clean automatically

Before Claude creates any new entry, it searches the database for a matching title. If one exists, it stops and asks:

"Memory 'Django Auth Setup' already exists. Update instead? (yes/no)"

No duplicates. No clutter. The database stays organized without you doing anything.

The four commands

Command	What it does
`@memory -read [Title]`	Load a specific entry back into Claude's context
`@memory -create short/medium/full`	Save conversation at your chosen detail level
`@memory -update`	Append new progress to an existing entry
`@memory -search [keyword]`	Search all entries by keyword with previews

Why This Matters Beyond the Demo

I want to be direct about something.

Most people treat AI context loss as an inconvenience. I started treating it as a systems problem and once you see it that way, the solution becomes obvious. You do not fix memory loss by trying to make each AI tool smarter in isolation. You fix it by giving all the tools a shared external memory they can all read from and write to.

Notion with MCP is that memory layer.

What makes this different from other memory solutions is that it is tool-agnostic. It does not matter which AI tool you use. If it supports MCP, it connects to the same brain. Today it is Claude and VS Code Copilot. Tomorrow you add Cursor, Windsurf, or the Claude Desktop app and they instantly have access to every conversation you have ever saved. The more tools you connect, the more powerful the system becomes, and you do not have to change anything.

I built this because I was genuinely tired of being the memory layer myself. Every time I switched tools, I was the one bridging the gap — manually, repeatedly, forever. The Notion Memory Engine means I never have to do that again.

And neither do you.

Built for the DEV.to x Notion MCP Challenge. Full setup guide and repo above, replicate it in under 30 minutes.

If your code starts with Give me a variable...' you are the problem.

Isah Alamin — Thu, 05 Feb 2026 09:46:49 +0000

Every era of programming has introduced a new layer of abstraction. First, we abstracted the hardware. Now, with AI, we are abstracting the logic itself. We're not just coding at a higher level we're operating in a new meta language.

I want you to look at these three lines.

MOV AX, 0x2A
int result = 42;
"Give me a variable with the answer to life."

Each line does roughly the same thing. But the journey each one takes to become something a CPU understands is a map of our entire industry, and it shows where we're headed next.

I'm worried about the third one. I think it's creating a new kind of developer one who is fast, efficient, but ultimately fragile. Let me explain.

Layer 1: Talking to the Metal

The first line is Assembly. There is almost zero abstraction. You are moving a literal value (0x2A, which is 42) into a specific register (AX) on the CPU. The compilation chain was beautifully simple:


Your Brain -> Assembly -> Machine Code

To do this, you had to understand the machine. You thought about memory addresses, registers, and clock cycles. There was no hiding.

Layer 2: The Great Abstraction

Then came high-level languages like C. The second line, int result = 42;, was a revolution. It let you think about ideas (an integer variable) instead of hardware (a CPU register).

The compilation chain got longer:


Your Brain -> C Code -> Compiler -> Assembly -> Machine Code

And with it came the first great debate. The assembly programmers saw it coming. "This will make weaker developers!" they argued. "You're losing the connection to the machine! You won't understand what's really happening!"

They weren't wrong. I'm living proof. I can write Python and JavaScript all day. I don't truly know how memory is allocated. I've never manually managed a heap. An entire layer of understanding was traded away for a massive explosion in what we could build. We exchanged depth for breadth, and it worked... until you hit a bug that existed in that hidden layer and you had no tools to find it.

Layer 3: Abstracting the Thinker

Now we're here. The third line isn't code; it's a description of intent. "Vibe coding." The AI takes your vibe, interprets it, and writes the high-level code for you.

The chain is now fundamentally different:


Your Vibe -> AI -> Python/JS -> (Compiler/Interpreter) -> Assembly -> Machine Code

We've added a new, fundamental layer: Natural Language to Code. We're no longer just abstracting the machine; we're abstracting the logical thinking itself. The AI is doing the step-by-step translation from human problem to formal solution.

This is the progression: Assembly -> High-Level -> Natural Language. Each step made us more powerful and took us further from the core truth of the machine.

My Fear: The Rise of the Prompt Technician

The old debate is back, but the stakes are higher. High-level languages risked creating developers who didn't understand the hardware. AI powered development risks creating developers who don't understand the software.

Can you debug a block of AI-generated code when it has a subtle logic error the AI didn't catch?
Can you optimize an algorithm you didn't design?
Can you explain why a solution works, not just that it does?

Or have you become a prompt technician skilled at negotiating with a black box, but unable to build or repair the machinery inside it?

This Isn't About Stopping Progress

I'm not saying "turn off the AI." That's impossible and foolish. The shift from Assembly to C was inevitable and good. The shift to AI is the same.

The question is one of consciousness. The developers who thrived in the C era weren't the ones who forgot assembly existed; they were the ones who knew when to drop down a level. They understood the model beneath the abstraction.

Our job now is to build that same awareness. Use AI to generate the first draft, to explore ideas, to handle boilerplate. But then own the second draft.

Read the code it writes. Tear it apart. Rewrite it. Ask "why" until you understand. If you don't, you've just outsourced your core competency. Speed is not a substitute for understanding.

We're standing at the newest layer of abstraction. Let's use it to climb higher, not to forget the ground we're standing on.

What do you think? Has the abstraction ever bitten you? How do you make sure you're still the engineer in the room?

My Coding Attention Span Is Gone. Is AI to Blame?

Isah Alamin — Wed, 14 Jan 2026 14:00:42 +0000

The Journey That Was

A few years ago, building the frontend for my app was a journey. I'd sit down, get into the zone, and wrestle with the code. There was frustration, sure, but there was also a deep, electric excitement when it finally came to life. I wasn't just building a feature; I was learning, problem-solving, and growing.

Today, I can't do that anymore.

The New Reflex

I can't sit down and write code for a side project or even a crucial piece of work without immediately reaching for AI. My first thought isn't "How do I solve this?" It's "What prompt do I write?"

It feels like a superpower has been grafted onto my workflow. But lately, I've started asking a terrifying question: Is this power making me weaker?

Here's My Confession

1. I've lost the ability to just... start.

The blank editor window now induces anxiety, not possibility. My reflex is to populate it instantly with an AI generated scaffold. The act of creation has been outsourced.

2. My "debugging patience" has evaporated.

Staring at an error for 15 minutes? Unthinkable. I paste it, get the fix, and move on. I get the "what," but I'm losing the "why." That deep, structural understanding that comes from the struggle is gone.

3. My most improved skill isn't coding—it's prompting.

I'm a more efficient manager of an AI, but I fear I'm becoming a less competent engineer.

4. And here's the weirdest side effect: I feel stagnant.

This was my original worry. I'm moving faster than ever, but I feel like I'm running in place. I'm not pushing my own boundaries; I'm just instructing something else to do it. The fatigue I feel isn't the deep burnout from intense focus—it's the shallow exhaustion of constant context-switching and prompt-tweaking.

The Paradox

It's a paradox: the tool designed to eliminate friction and blockers might be creating the biggest blocker of all—a stunted, impatient, and dependent developer brain.

I'm not saying AI is bad. It's revolutionary. But like any powerful tool, it demands intentional use. Right now, I'm on autopilot, and it's leading me straight into a skill ceiling.

I Suspect I'm Not Alone

So I'm putting this out there to our community:

Have you felt your own attention span for deep coding work shrink?
Do you miss the "deep flow" state, or has AI replaced it with something more frantic?
Most importantly: How are you fighting the brainrot? How do you balance the insane leverage of AI with the need to keep your own skills sharp and your curiosity alive?

My Small Rebellion

I'm starting small. I'm trying "no-AI" coding hours. I'm forcing myself to read the official docs again. I'm building a tiny, stupid project with no goal other than to remember what it feels like to think for myself.

This isn't a rant against AI. It's a plea for awareness. Let's talk about the cost of the shortcut before we forget what the long road even feels like.

Damn. I'm cooked. I couldn't even have written this post without ChatGPT 💀
.

Building my MVP: Glyph — Your AI-Powered Writing Assistant

Isah Alamin — Sun, 04 Jan 2026 13:58:34 +0000

This is a submission for the DEV's Worldwide Show and Tell Challenge Presented by Mux

What I Built

I built the MVP of my startup called Glyph.

Glyph is a word editor with an AI assistant that can:

Write for you from scratch
Edit text however you like
Answer questions about what you're writing
Let you write yourself if you prefer

You can also upload videos (like meetings or lectures) and get a clean transcript right in the editor.

My Pitch Video

Demo

Live Demo: https://glyph-ochre.vercel.app

Test Credentials for Judges:

Email: test@glyph.com
Password: GlyphTest2026

📝 Important Demo Notes for Judges:

For the best experience, please use a desktop or laptop browser.
The video-to-text feature requires a direct, public URL to a video file (e.g., .mp4, .mov).
- It does not support: YouTube links, private videos, or files behind authentication.
To make testing easy, here are a few sample video URLs you can use:
1. http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/WeAreGoingOnBullrun.mp4
2. https://commondatastorage.googleapis.com/gtv-videos-bucket/sample/SubaruOutbackOnStreetAndDirt.mp4

The Story Behind It

As a student and developer, I constantly write blogs, emails, assignments, documentation. I also worked at a company where I dealt with a lot of typing, and I knew how stressful it was. I've felt the frustration of the blank page, the inefficiency of jumping between research tabs, and the time lost manually transcribing meeting notes.

You spend hours typing and thinking: "What word comes next? Where should this punctuation mark go?" It's hard figuring out what words come after the next word, where to put punctuation marks.

I've always wanted something to help something accessible I could use without installing, that was affordable and actually solved my problem. Many experiences like this led me to creating Glyph.

It is my solution to make writing faster, less stressful, and more focused on ideas rather than mechanics.

Technical Highlights

Glyph is a full-stack web application built for clarity and speed.

Frontend: A responsive interface built with vanilla HTML/CSS/JavaScript, using TipTap as the core rich-text editor for a smooth, native writing feel.
Backend: Django handles API logic, user session management, and orchestrates between services.
AI Engine: For this MVP, I'm using the Groq API with the Llama 3 model. I prioritized cost efficiency by using a lightweight LLM that handles basic text operations well. This keeps the app free for users while we validate the concept. We can easily swap to GPT-4 or Claude for production if needed.
Video Intelligence: This is where Mux shines. The backend uses the Mux Video API and its AI-powered auto-captioning to asynchronously process uploaded videos, returning clean, structured transcripts directly into the Glyph editor.

The Vision: This MVP validates the core workflow. The roadmap includes more advanced AI models, real-time collaboration, image-to-text analysis, and deeper document management features.

Use of Mux (Additional Prize Category Participants Only)

Mux was the MVP behind my MVP (pun intended 😄). I used it for the video-to-text feature — and this is definitely a feature I'm keeping.

How It Works:
When you upload a video in Glyph, here's the code that makes it work:

# Create a Mux asset with auto-generated English captions
create_payload = {
    "input": [
        {
            "url": video_url,
            "generated_subtitles": [
                {
                    "language_code": "en",  # English captions
                    "name": "English CC"
                }
            ]
        }
    ],
    "playback_policy": ["public"]
}

# POST to Mux API
create_response = requests.post(
    'https://api.mux.com/video/v1/assets',
    headers=headers,
    json=create_payload
)

I integrated the Mux Video API to handle the entire "video-to-document" pipeline:

A user provides a public video URL in Glyph.
My Django backend creates a Mux Asset with a request for auto-generated captions (generated_subtitles).
I listen for the video.asset.track.ready from Mux to know when the transcript is ready.
Once ready, my backend fetches the plain-text transcript from Mux and injects it as a beautifully formatted draft into the user's Glyph editor.

Why This Matters:

This isn't just a transcript feature. Here's how it blends perfectly with Glyph's AI writing tools:

📝 Blog from Video: Record a product demo → Get transcript → Ask Glyph "Turn this into a blog post" → Publish in minutes.

🎓 Research Made Easy: Have a 2-hour lecture recording? Get the transcript → Ask "Summarize key points" → Use Glyph to expand into research notes.

💼 Meeting Magic: Team meeting recorded → Get action items → Use Glyph to draft follow-up emails and project plans.

✍️ Content Repurposing: Podcast episode → Transcript → Glyph helps turn it into tweets, LinkedIn posts, and newsletter content.

Why This Blends Perfectly with Glyph:

Most tools stop at transcription. Glyph makes the transcript actionable. You can:

Immediately edit it with AI commands

Ask questions about specific parts

Transform it into any format you need

All within the same clean interface

The Experience:

Building this was remarkably straightforward. Mux's documentation is clear, their APIs are intuitive, and it fits perfectly into a user-friendly flow. What could have been a complex, weeks-long integration was up and running in a matter of days, allowing me to focus on the unique user experience Glyph provides around that transcript. This feature is a core part of Glyph's value proposition and wouldn't be in this MVP without Mux.

Shoutout to Mux!

A Personal Note: If Glyph resonates with you, I'd be incredibly grateful if you joined the waitlist via the link on the login page. Your interest helps guide what I build next. Feel free to reach out here on DEV with any questions or feedback!

I Taught Postgres to Fight Hackers - And It Worked (Agent Auth)

Isah Alamin — Mon, 10 Nov 2025 04:32:52 +0000

This is a submission for the Agentic Postgres Challenge with Tiger Data

What I Built

Okay, let's be real, what I built is a little bit crazy. But when the challenge said "build something that makes us say 'I didn't know you could do that!'", I went all in.

Here's the problem that keeps developers up at night: user input is terrifying. You build a nice little form, users type into it, and suddenly you're dealing with SQL injection, credential stuffing, and attacks you didn't even know existed.

You try regex rules, you try validation, but it's like playing whack-a-mole with hackers. What about the attacks nobody's seen before? The ones that slip through every known defense?

That's where Agent Auth comes in. I built an AI security guardian that watches over your input fields like a hyper-vigilant bouncer. It's like having a security expert manually checking every single user input before it hits your database, except this expert never sleeps, never gets tired, and learns from every attack attempt.

The lightbulb moment? Imagine if you could personally vet every form submission. You'd catch everything, right? That's the magic we're bringing to the digital world.

Demo

See the Code: Github Repository
Watch it in Action: Video demo
Test the Site: Live Link

How I Used Agentic Postgres

I dedicated significant time to exploring the full range of Agentic Postgres capabilities. I experimented with the Tiger CLI for deployment workflows and tested the MCP server for potential AI model integration. While these tools showed promise for different use cases, I ultimately focused on pg_text_search as the foundation for my security solution because it offered the most practical and performant approach for real-time threat detection.

The Technical Architecture

pg_text_search: As the First Line of Defense
I chose pg_text_search over traditional regex patterns because it operates at the database level with significantly better performance characteristics, it is like Where regex requires complex pattern matching that scales poorly with rule complexity, pg_text_search uses optimized text indexing that maintains consistent performance even as the threat database grows. it is like writing so little to catch so many, whereas normally you write so many to catch so little. This meant I could implement comprehensive security checks without introducing latency into the authentication flow.

Timescale Postgres as the Security Brain:
The database serves as the central intelligence hub. By leveraging Timescale's performance optimizations, the system maintains historical context about attack attempts while providing the real-time processing speed needed for authentication security.

Strategic AI Integration with Groq:
For cases that require deeper analysis, the system escalates to Groq AI. This isn't a replacement for the database-level protection but rather a specialized tool for analyzing novel or sophisticated attacks that don't match known patterns. The AI component focuses on understanding intent and context rather than simple pattern matching.

Why This Architecture Matters

The decision to build around pg_text_search was deliberate. Database-level security provides several critical advantages:

Performance: Security checks happen where the data lives, eliminating network latency

Consistency: The same security logic applies regardless of how data is accessed

Maintainability: Security rules are centralized rather than scattered across application code

Scalability: The system can handle increased load without degrading security coverage

I did explore using database forks for creating isolated testing environments where suspicious inputs could be safely analyzed. While the concept showed promise for advanced threat research, I prioritized building a robust production-ready solution first. The fork capability remains an area for future enhancement, particularly for organizations needing sandboxed security testing.

This architecture represents a shift from treating the database as passive storage to making it an active participant in application security. The result is a system that gets smarter over time while maintaining the performance characteristics needed for production authentication systems.

Screenshot from App

Why Choose Agent Auth
Demo Page
Testing Normal Input
Testing Malicious Input
Malicious Input Blocked
Normal Input Allowed

Overall Experience

Building with Agentic Postgres was equal parts exciting and challenging. The documentation was solid, but I found myself wishing for more real-world examples of these features in production environments.

What surprised me was how natural it felt to make the database more active in its own defense. It's not just sitting there waiting to be attacked anymore.

The biggest challenge was balancing performance with security. Every millisecond counts in authentication flows, so I had to be smart about when to use the heavier AI analysis versus the faster pattern matching.

Important Security Notice & Future Roadmap

Current Testing Considerations

Please note: During testing and demonstration, I strongly recommend not using real login information. The current implementation uses public AI services for threat analysis, and while I've implemented basic security measures, this version is designed for evaluation and development purposes.

Security Evolution Plan

Looking ahead, I'm planning several key security improvements:

Local AI Processing: Future versions will move sensitive analysis to locally-hosted models, keeping credential validation entirely within your infrastructure. This eliminates external data exposure while maintaining the intelligent threat detection capabilities.

Enhanced Data Handling: I'm implementing proper data anonymization techniques where only pattern signatures (not actual credentials) are processed by external services.

Zero-Trust Architecture: The system will evolve to include strict access controls, comprehensive audit logging, and encrypted data handling throughout the security pipeline.

Why This Matters

I believe in being transparent about security limitations while demonstrating the potential of the technology. The current implementation shows what's possible with Agentic Postgres, while the roadmap addresses the practical security concerns that would be essential for production deployment.

This approach allows developers to experiment with the concept while understanding the security considerations involved in building AI-enhanced authentication systems.

What Next

I'm treating this as version one. There's so much more to explore:

Proper sandboxing with database forks for safe attack analysis

Community-driven threat intelligence sharing

Fine-grained controls for different security levels

Better transparency about what the system is detecting and why

I'd love feedback from other developers - especially about the security implications and what features would actually be useful in real projects.

This feels like the beginning of making databases active participants in their own security rather than passive targets.

Conclusion

This challenge pushed me to think differently about what databases can do. Agentic Postgres isn't just about storing data - it's about making data work smarter. I'm excited to keep refining this approach and seeing how the community builds on these ideas.

Thanks to Tiger Data for the inspiring challenge!

Meet Bugsy, Your AI Web Bug Hunter

Isah Alamin — Sat, 30 Aug 2025 01:19:57 +0000

This is a submission for the AI Agents Challenge powered by n8n and Bright Data

What I Built

Meet Bugsy — my AI-powered bug hunter. Bugsy works as an ethical agent that scans websites for common security exposures and gently waves a red flag when it finds something risky.

Think of it as a tireless security intern who never sleeps, never complains, and always documents what it finds.

The goal? To give developers and site owners an extra set of AI eyes to spot things like:

🔑 Leaky environment variables

🗝️ Accidentally exposed API keys

⚠️ Security misconfigurations

📂 Sensitive data accidentally exposed in public files

This is not about attacking systems — it’s about raising awareness and improving security hygiene in a world where even the smallest mistake can snowball.

Demo

Demo Video

n8n Workflow

n8n workflow

Technical Implementation

Bugsy was built inside n8n, designed as a careful and ethical agent:

System Instructions: The agent is explicitly instructed to act only as a security scanner, focusing on detection and reporting (never exploitation).

Model Choice: gpt-oss-20b — chosen for its balance of reasoning ability and lightweight contextual memory.

Memory: Short-term memory for scanning logic, with no sensitive data retention.

Tools & Nodes:

Bright Data Verified Node → safe, compliant web data collection

Custom Logic Nodes → analyze response patterns, detect risky strings (e.g., AWS_SECRET_KEY=...)

Markdown/HTML Report Generator → produce clean, developer-friendly summaries

Bright Data Verified Node

This was the heart of the project. The Bright Data Verified Node acted like a seatbelt and airbag, ensuring Bugsy only interacted with public, accessible data — never crossing ethical or legal lines.

Journey

I started with a simple idea: what if an AI agent could act like a friendly security sidekick?

The biggest challenge was balancing power with responsibility. A scanner can easily become too aggressive or invasive, but Bugsy needed to be effective and ethical.

Highlights along the way:

Writing strict guardrails in the system prompt so Bugsy never attempts exploitation.

Leveraging Bright Data’s verified infrastructure for compliance and peace of mind.

The thrill (and mild panic 😅) when Bugsy actually discovered a live API key — which we responsibly reported to the site owner.

What I learned

security is often about small cracks in the wall that are easy to overlook. Bugsy shows that AI can help catch those cracks before someone malicious does.

Impact

For Developers → A safety net to catch mistakes before code goes live.

For Companies → Reduced risk of data leaks and misconfigurations.

For the Community → Promotes ethical AI use in cybersecurity.

Bugsy doesn’t replace professional security audits, but it provides a first line of defense — a friendly assistant to raise early red flags.

Challenges Faced

Ensuring scans remained ethical and non-invasive.

Balancing false positives vs. false negatives — tuning detection patterns so Bugsy isn’t too noisy.

Integrating n8n logic flows with AI reasoning while keeping performance fast.

What’s Next

Bugsy is just the start 🚀. Planned next steps:

Add scheduled scans with email/slack notifications.

Expand detection rules to cover CORS misconfigurations, directory listings, and metadata leaks.

Build a developer dashboard where reports can be stored, tracked, and prioritized.

Experiment with multi-agent collaboration (one agent scans, another verifies).

Closing Thought

Bugsy embodies the idea that AI can be a force for good in security. Instead of exploiting weaknesses, it shines a light on them — giving developers the chance to fix issues before they cause harm.

I Built a Movie Plot Finder Using Kiro

Isah Alamin — Wed, 16 Jul 2025 23:16:02 +0000

What I Built

For the Code with Kiro Hackathon, I created a fun and practical tool: a Movie Plot Finder where users can just type a vague movie description — like a scene, character, or event — and get actual movie recommendations instantly.
All powered by AI.

The Problem

We've all had those moments:

"What was that movie where a guy wakes up on a loop and keeps reliving the same day?"

Or:

"I saw a movie years ago — a spaceship crew finds aliens inside a mysterious egg."

Google often fails with vague memories. Most search engines need exact titles, actor names, or keywords.
I wanted to fix that.

How Kiro Changed My Dev Flow

Normally, I’d spend hours setting up:
React + Tailwind config
State management
API boilerplate
Routing
Layouts and CSS
With Kiro, all of that was instantly scaffolded. That saved me at least 5–7 hours of setup.
I could focus on the logic and UX, rather than wiring everything from scratch.

What I’d Improve Next

With more time, I’d add:
A memory/history of previous searches
Allow filtering by genre, year, or actor
Use smarter models for more accurate results
But even as-is, it’s already helping friends identify old movie titles they forgot!

Final Thoughts

Kiro honestly changed how I approach rapid development. Instead of wasting time on boilerplate, I could iterate quickly and focus on value.
If you haven’t tried it, go to kiro.dev and give it a prompt. You might just build something amazing in 10 minutes.

Post title

Isah Alamin — Wed, 16 Jul 2025 09:44:44 +0000

This is the content