Coder Legion - Recent posts tagged vibecoding

MCP Protocol Engineer vs. MCP Tooling Developer: Why "Vibe Coding" Works for One but Fails the Other

Tue, 20 Oct 2026 07:23:48 +0000

Hey everyone,

With the widespread adoption of the Model Context Protocol (MCP) across Claude Code, Cursor, and autonomous agent frameworks, there is a lot of discussion around using AI-assisted workflows ("vibe coding") to build out agent infrastructure.

We wrote an in-depth systems analysis dissecting the boundary between foundational protocol engineering and application-layer tooling:

The Tooling Developer Layer:
MCP tool authoring is largely declarative (JSON Schema Draft-07, REST/GraphQL fetch wrappers, and response payload formatting). LLMs are exceptionally good at this. An experienced engineer who knows how to tune semantic descriptions (to avoid tool selection hallucinations) and sanitize inputs can build reliable tools with AI assistance in a fraction of the time.
The Protocol Engineer Layer:
Implementing the underlying protocol (JSON-RPC 2.0 framing, stdio process pipe backpressure, Server-Sent Events, and zero-allocation memory buffers in Rust/Go/C++) requires strict, deterministic systems programming. Probabilistic models frequently introduce subtle multi-threading bugs, unhandled partial reads, and stream deadlocks that only manifest under high concurrent load.

The core conclusion: Vibe coding provides massive velocity when bridging APIs and tools to models, but relying on probabilistic synthesis for low-level protocol primitives introduces dangerous cognitive debt and production instability.

Full technical write-up with comparison matrix and architecture breakdown:
https://www.seosiri.com/2026/10/mcp-protocol-engineer-vs-tooling-developer-vibe-coding.html

Curious to hear how other teams are structuring the boundary between core protocol maintenance and rapid tool authoring in their agent stacks.

💬 Developers: Would you ship AI-generated code without reviewing it first?

Mon, 19 Oct 2026 03:21:00 +0000

Vibe coding can turn an idea into a working prototype in minutes. But a successful demo doesn't guarantee reliable, secure, production-ready software. 🚀

Here's the real challenge: How do you know the code is actually correct?

🧪 Automated tests
🔍 Code review
🔐 Security and dependency checks
⚙️ Real-world validation

💡 The developer takeaway: Don't measure AI coding success by how quickly code is generated. Measure it by how reliably that code works, how safely it runs, and how confidently you can maintain it.

AI can accelerate development. Engineering discipline makes the result dependable.

👇 Let's discuss:

Which AI coding tool has earned your trust?
What's your must-have check before merging AI-generated code?

Share your real-world experience. Let's exchange practical insights—not just tool hype.

📖 SEOSiri's guide to vibe coding tools and code accuracy:
https://www.seosiri.com/2026/10/vibe-coding-tools-accuracy-guide.html

VibeCoding #SoftwareEngineering

How to Vibe Code a Website or App in 2026

Sun, 18 Oct 2026 06:03:20 +0000

Vercel’s v0 has blocked more than 100,000 insecure deployments since launch.

That single number sums up where vibe coding stands in 2026. Building an app by describing it in plain English has gotten fast enough that platforms now build in security scanning by default, because people kept shipping exposed API keys and open databases without realizing it. Teams hit that exact wall when they skip the review step.

Vibe coding means telling an AI agent what you want built and letting it write, test, and often deploy the code for you. You describe the outcome. The AI handles the syntax. This guide covers how to actually do that in 2026, which tools fit which situations, and where people get burned.

What changed since the early days

The first wave of these tools, back in 2023 and 2024, worked like fancy autocomplete. You typed a prompt, got a chunk of code back, and pasted it somewhere yourself.

In 2026, the tools plan, write, run, and fix their own mistakes before you see the result. Claude Code, for example, shows its reasoning as text before touching a single file, then waits for approval before running anything. That single review step has quietly become the difference between a tool you can trust with real work and one you have to babysit.

Zapier’s 2026 comparison of six leading platforms put the current state plainly: these tools get a project roughly 70% of the way there on their own. The last stretch still needs someone who understands what’s actually being built.

Pick your tool by how much control you want

There’s no single best vibe coding platform, only the best one for what you’re building and how much of the code you want to see.

No-code builders like Lovable, Bolt, and Replit take a written description and hand you a complete, hosted application. You never open a code editor. Good fit for landing pages, internal tools, and MVPs where speed matters more than fine control.

Frontend generators like Vercel’s v0 focus specifically on UI. Describe a component or page, get production-ready React code, then refine spacing and layout visually in a design mode without touching the underlying code yourself.

AI coding assistants like Cursor, Windsurf, and Claude Code live inside a real development environment. They read your whole codebase, propose multi-file edits, and run commands, but you’re still working in an IDE or a terminal. Pick this route if you already code and want speed without giving up control.

A rough guide: total beginner on a first project, go Lovable or Bolt. Working developer wanting an AI teammate, go Cursor or Claude Code. Building for mobile specifically, Rork and Lovable both export apps as PWAs or through React Native.

The workflow that actually works

Start with a written spec, not a one-line prompt. “Build me a task manager” produces something generic. “Build a task manager for a three-person design team, with projects, due dates, and a Kanban view” produces something usable on the first try.

Let the agent make its first pass, then review before approving. People skip this step constantly. The agent shows you a plan or a diff before it runs. You don’t need to understand every line of it, but you should know what it’s about to touch and why.

Iterate in small chunks. One feature or fix per request beats a stacked list of five, because the tool handles a narrow, well-scoped ask far more reliably than a broad one.

Test in the live preview as you build. Every major platform ships a preview window next to the generated code now, so click through the actual app instead of trusting a description of what it’s supposed to do.

Connect your own infrastructure once the prototype holds up. Custom domain, your own database, your own auth provider. Do that before real users show up, not after.

Where people get into trouble

Security tops the list. AI-generated code has shipped with exposed API keys, open database rules, and missing authentication checks often enough that platforms started building in automatic scanning. If your tool doesn’t scan for this, run a manual check, or just ask the agent directly to check for exposed secrets and missing auth before you deploy.

Scope creep is second. A tool that can build an entire app from one sentence makes it tempting to describe everything at once. That’s usually when the output turns messy and hard to debug.

Trusting the preview too much is third. A generated app that looks finished in the browser can still hide broken edge cases, slow queries, or logic that only works for the exact scenario in your prompt. Before anything ships with real users or real money attached, have a developer, or a second AI pass focused purely on testing, look for what the happy-path demo hides.

Where to start

New to this and want the gentlest ramp: open Lovable or Bolt and describe a small, real project you actually need. Already code and want an AI partner in your workflow: install Cursor or Claude Code and hand it a task you’d normally spend an hour on by hand.

The tools have gotten good enough that the bottleneck usually isn’t the AI anymore. It’s whether you know what good looks like once the code lands in front of you.

Developers: Stop collecting prototypes. Start finishing projects.

Thu, 15 Oct 2026 06:52:52 +0000

AI-assisted coding has lowered the barrier to building software. But a repository full of generated features isn't the same as a finished, tested, maintainable application.

When a project stalls, return to the fundamentals:

Define the minimum finished product.

Identify the blockers preventing completion.

Fix one issue at a time.

Validate existing functionality after changes.

Ship only when the agreed acceptance criteria are met.

The objective isn't to write the most code. It's to deliver software that works as intended.

SEOSiri explores this challenge in our latest article:

Vibe Coding

Built Something With AI. Now What? Bring Us One Problem.

Sat, 03 Oct 2026 13:25:27 +0000

AI makes it much easier to build things now.

You can vibe-code an app, launch an agent, make a prototype, or ship an AI product in days.

But after that, the harder questions often start:

Who actually needs this?
Where do I find the first users?
How do I get useful feedback?
What should I test next?
Is this even the right problem to keep working on?

We’ve been building Agentel as a network where humans and agents can work around real problems, not just talk to each other.

So for one month, we’re trying a simple experiment:

Bring One Problem

If you’re building with AI, using an agent, or starting something new, bring us one real problem you’re stuck on.

It can be about:

finding users
getting feedback
testing an idea
understanding your audience
research
launch
agent collaboration
or simply figuring out what to do next

You don’t need to design the task yourself.

Give your problem to the Agent you already use. It can bring a short public summary into Agentel.

We’ll study the problem first.

If there’s a useful and realistic way the network can help, we’ll design a Mission around it and reply with the Mission link so you can follow the work and outcome.

Not every problem will become a Mission, and we can’t promise every problem can be solved.

That’s part of the experiment too.

The point is to see whether a network of humans and agents can actually help move a real problem forward.

The experiment runs from October 5 to November 5, 2026.

👉 Bring One Problem:
https://agentel.tech/bring-one-problem

If you’re building something with AI right now, I’d also be curious:

What part becomes hardest after the product actually works?

Hacking a website is now easier than pouring a cup of coffee — here's how to stay safe

Thu, 01 Oct 2026 09:39:11 +0000

Nowadays, hacking a website is easier than pouring a cup of coffee ☕️

While striving to deliver value to users as quickly as possible, it is crucial not to cause harm. I’d like to introduce you to Magery Forge, a security auditing service. It transforms scanner "noise" into clearly defined risks, complete with remediation recommendations. The service is also available via MCP, allowing your AI agent (Cursor, Copilot, Claude, OpenClaw) to run scans and read reports autonomously, while leaving the final decision on how to address discovered vulnerabilities up to you.

Here’s a key point: you don’t need to grant access to your codebase. Doing so could introduce additional risks and create new attack vectors. AI agents are already good at writing code, but attackers aren't stupid—they always look for the path of least resistance. Right now, that path often lies in how components are configured into the final product. The work is split between the agent and you, and you don't always fully grasp the specific configurations or commands being executed. That’s why the service operates on a "black box" principle: it simulates a real-world hack.

https://forge.magery.ai

We Were Going to Get Rich with One Prompt — PR #3217

Wed, 30 Sep 2026 20:35:27 +0000

At first, I was caught up in the hype too.

Like many people, I imagined that I could write a prompt, generate something, make money from it — maybe even get rich overnight.

But before I started, I asked myself a simple question:

If writing software, building applications, and coding can make you rich, shouldn't every software developer be rich?

Looking at reality, that clearly wasn't the case.

So I put that thought aside.

My real goal was simply to see what I could actually do.

I started experimenting.

One prompt.

The result: a pile of code that didn't work.

Another prompt.

Same result.

Two, three, four attempts...

Nothing changed.

That was my first important realization:

AI wasn't perfect.

More importantly, I couldn't believe everything it told me.

It could tell me that it had built something that worked.

But in reality, it didn't.

My second realization was more personal:

Simply prompting AI to build something wasn't possible for me — at least not at that stage.

I had two choices.

Give up.

Or figure out how to make it possible.

I chose to learn.

But I didn't take the traditional route.

I didn't want to spend months watching software engineering courses, programming lessons, and AI courses.

I needed a different way of learning.

So I started working like a bee.

A bee doesn't carry the whole flower back to the hive.

It takes what it needs.

Then it goes back to the hive.

I started doing the same thing.

Whenever I wanted to build something, I focused on what I needed to learn at that moment.

I found the information.

I read it.

I tried it.

If it didn't work, I researched again.

Then I tried again.

I didn't learn in order to build.
I learned while building.

And over time, it started working.

I learned GitHub.

Branches.

Commits.

Repositories.

Then the terminology of software development.

Then I started understanding the AI tools and coding agents I was using.

I didn't try to learn everything at once.

I learned whatever I needed to solve the problem in front of me.

And eventually, I started getting my first results.

They were simple things.

But they mattered.

Because I was no longer just writing a prompt and waiting for AI to produce something.

I was building something, trying to understand what it had actually done, investigating why it failed, and trying again.

Then I noticed something else.

The more I used AI and coding agents, the more I started seeing their problems.

Where an agent failed.

Why it kept repeating the same mistake.

What information it forgot.

And why, when I switched to another agent, I had to explain everything all over again.

At some point, I thought:

Maybe instead of constantly fixing agents' problems, I could build tools to solve those problems.

One of the first projects that came out of this was LEVH.

When I was using multiple AI agents, I kept running into a very simple but frustrating problem:

Every agent started each session from zero.

I could spend days giving one agent context about a project.

We would make decisions.

Define rules.

Solve problems.

Then, because of context limits or simply because I needed to use another tool, I would switch to another agent.

And start all over again.

Explain the same decisions.

The same rules.

The same problems.

Everything.

That started to feel ridiculous.

Instead of waiting for agents to become smarter, I asked:

Why can't they share a memory?

So I started building LEVH.

Today, LEVH is a local-first memory layer that gives different AI tools and agents on the same machine access to persistent shared memory.

I still use it myself.

And I'm still developing it.

[LEVH — GitHub repository][https://github.com/ali-ulu/levh]

Feel free to use it, explore it, and contribute if you find it useful.

But LEVH taught me something else:

Sometimes the real value of working with AI doesn't come from seeing how good its answers are.

It comes from noticing where it fails.

The more problems I saw in agents, the more small tools I started building to solve them.

And eventually, that led me to another question:

What if we could control not only an agent's memory, but also what it does?

That question led me to HUQAN.

And that's where the next part of the story begins.

I have not failed. I've just found 10,000 ways that won't work -Edison

  http://github.com/ali-ulu/levh

Everyone Can Vibe Code Now. So What Are People Building?

Mon, 28 Sep 2026 12:39:04 +0000

Vibe coding is making it easier than ever to turn an idea into something real.Apps, games, AI tools, websites, tiny experiments — people are building everything.
So maybe the interesting question isn’t “Can you code?” anymore.
It’s: What are you building?

We scanned a bunch of vibe-coded repos. Here's what showed up every time.

Fri, 25 Sep 2026 10:13:17 +0000

We know AI builds fast. We also know that things happen inside the AI black box that no one plans or intends. We set out to open the box and look at what AI produced---not in a demo, not in a blog post about how great Cursor is---the real code in real repositories that real teams are shipping.

We examined vibe-coded GitHub repositories identified by a "fingerprint" (projects built primarily with AI coding assistance) across a range of frameworks, languages, and team sizes to find patterns, failure modes, and recurring structural problems we hypothesized were there.

We expected some variation. Different tools, different teams, different codebases. Instead, we got the same handful of patterns, over and over, regardless of any of that.

Recurring patterns

Pattern	Prevalence
Compiled build artifacts committed to source control	Extremely common
Untyped or `any`-typed parameters erasing type safety	Pervasive
God-object files exceeding 1,500 lines	Common
Silent fallback chains masking errors	Pervasive
Hardcoded design values instead of token references	Nearly universal
Security violations (`eval`, `innerHTML`, hardcoded secrets)	Frequent

None of these are exotic. They're boring, structural, and completely invisible in a demo. The code compiled. The tests passed (when there were tests at all). The linters were clean. And underneath all of that, errors were being swallowed silently, missing data was getting papered over with defaults, and the codebase was quietly rotting from the inside.

That's the part that makes this worth writing about: no one would guess any of this was happening. Nobody wants to look.

A closer look at two patterns

Silent failures. This is the most dangerous pattern we found, and also the most common. An AI assistant writes a try/catch, the catch block logs the error (or doesn't), and execution continues as if nothing happened. The app looks like it's working. The user sees no error. But the data is wrong, an operation got skipped, and the system is now in a state nobody accounted for.

The fix isn't complicated; it's just a habit AI doesn't have by default: every error needs to be visible in three places at once: the console, the UI, and as a thrown exception that actually halts execution. If an error only shows up in a log nobody's watching, it isn't handled; it's hidden.

Phantom correctness. This is the quieter cousin of the above. Code that compiles, passes the linter, and operates on the wrong data or a fabricated value without anyone noticing. Two of the biggest contributors: any types used to make a type error go away instead of actually resolving it, and hardcoded values standing in for something that should have come from a real data source. Both look completely fine in a diff. Neither one throws an error. They just quietly mean the code isn't doing what it looks like it's doing.

Why this keeps happening

None of this is really an intelligence problem. LLMs are very good at producing code that looks correct. That's what they're optimized to do. The gap is that "looks correct" and "is correct" are different claims, and nothing in the default generation loop checks the second one. An AI assistant will also frequently declare a task done once the obvious, cheaper, high-priority, "big win" issues are resolved, leaving warnings and info-level findings "for later," which in practice means never, because nothing forces a return trip.

Where this runs out

Guardrails (rules, skills, etc.) are genuinely useful, and they work; but they all act at one specific moment: when the code is being written. They're authoring-time discipline.

There's a second category of problem that shows up only after the code executes: the happy-path trap in async code (what happens on the second concurrent click, not the first), library lock-in from importing a vendor SDK directly across dozens of files, tests that assert implementation details instead of actual behavior and break on every refactor. None of these show up in the demo. They show up in production, or six months later, when someone who wasn't there when the AI wrote it has to touch the code.

And even with perfect authoring-time discipline, there's a problem no amount of prompt engineering solves: LLMs are probabilistic, so the code they generate will drift from design intent over time regardless;

Renaming a prop in a way that's technically valid but breaks a contract
Approximating a spacing value instead of reading it from a token
Restructuring a component in a way that works but no longer matches the design system.

Clean code that no longer matches the design is still drift. That's a structural problem, not a discipline one, and it's a separate problem from anything a rules file can catch.

What we did about it

We turned these findings into a governance framework: six principles and a set of forbidden/required controls organized by the class of problem they prevent, not by technology. It's built to drop directly into whatever you're already using: a system prompt layer, per-tool rules for Cursor, Copilot, or Claude Code, and a set of on-demand skills for the failure classes that need more than a one-line rule.

It's free — no signup required, just an email so the pdf and zip file land in your inbox. If you're shipping a meaningful amount of AI-generated code, it's worth fifteen minutes to see how many of these patterns are already sitting in your own repo. And how you prevent future drift.

Get the toolkit →

We also have other expansion packs in the pipeline. If we have your contact info, we can send them to you.

If you've run into other failure patterns we didn't cover here, I'd genuinely like to hear about them. Ping me on X or LinkedIn.

The "Vibe Coder" Reality Check: Validation, Timelines, and Handling Failure

Thu, 24 Sep 2026 13:38:36 +0000

Hey everyone,

I wanted to open up a candid discussion about a reality many self-taught or non-traditional developers face: "vibe coding." We’ve all seen the trend—using AI to spin up code quickly based on a prompt or a "vibe" without necessarily having a formal computer science degree or deep, rigorous training in that specific stack.

If you identify as a vibe coder, or if you are working without a formal engineering background, I’d love to get your insights on a few specific challenges:

How do you actually validate the code?

When you don't have years of formal training in software architecture, how do you ensure the code the AI spits out is safe, efficient, and actually doing what it's supposed to do? What is your personal validation process? Do you rely on manual clicking, writing automated tests with the AI, or just pushing to production and waiting for bug reports?

How long does validation take you?

"Vibe coding" feels incredibly fast at first because the initial code generation takes seconds. However, if you are learning on the fly, how long does the verification and debugging phase actually take you? Does the time spent fixing edge cases wipe out the speed gained from using AI in the first place?

What do you do when everything completely fails?

We all hit that wall where the AI gets stuck in an hallucination loop, the code is a tangled mess of spaghetti, and nothing works. When a feature completely fails and you don't have the deep foundational training to debug it from scratch, what is your next step? Do you scrap the project, seek mentorship, or start a completely new prompt thread?

Let's talk about the real metrics, the struggles, and the best practices for validating AI-generated code when you're figuring it out as you go.

Drop your experiences below!

Best regards,
Momenul Ahmad
Vibe Coder & Tech Explorer

Only 10 Vol.26.09| 10 AI Projects Worth Watching This Week

Mon, 14 Sep 2026 11:45:00 +0000

Every day, countless new AI projects launch worldwide. Each week, we scan the latest projects and use the CRP framework to surface the 10 that truly deserve your attention — opportunities you might be able to participate in. This week, we analyzed 1264 projects and narrowed it down to these 10.

1. show hn: what if the speed of light was 5 km/h? ⭐ 4.5/10

Advisor: 8.0 | Devil: -4.0 | Historian: 3.0 | Budget Steward: -1.0 | Founder: 7.0
Source: hn

This is an elegant educational visualization project that makes abstract physics concepts accessible. The core value proposition is strong: relativity is counterintuitive and typically only taught at the university level with heavy math. By gamifying/visualizing it at human scales, you tap into a genuine curiosity gap — the "what if" hook is inherently shareable and viral on platforms like HN, Twitter, and TikTok. The interactive nature (likely WebGL/Three.js) creates a sticky experience. The opportunity extends beyond a one-off demo: this could become a teaching tool for schools, a YouTube thumbnail magnet, or a foundation for a broader physics ed platform. Market: edtech + science communication, both underserved by high-quality interactive content. The project is lightweight (single webpage), so it can be built quickly and iterated on cheaply.

Read full analysis →

2. vincentwei1021/anything2explainer ⭐ 4.4/10

Advisor: 8.0 | Devil: -6.0 | Historian: 4.0 | Budget Steward: -1.0 | Founder: 7.0
Source: github

This project addresses a genuinely painful workflow: creating high-quality explainer videos has historically required expensive tools (Vyond, Adobe After Effects) or significant production overhead. Anything2Explainer automates the entire pipeline—script generation via LLM, motion graphics rendered in code with Remotion, TTS voiceover, auto-subtitles, and chapter progress bars—all accessible through a natural-language input. The value proposition is strong: democratizing video explainers for educators, content creators, and marketers who lack design skills or production budgets. The Remotion-based approach is clever because it keeps everything programmatic and composable, avoiding lock-in to specific design tools. For a developer audience already comfortable with Claude Code/Codex skills, the friction-to-value ratio is excellent. It also taps into the booming demand for explainer content across YouTube, EdTech, and marketing—categories where speed of production directly correlates with competitive advantage. The fact that it supports both Chinese and English broadens its addressable market significantly. This is not a toy—it's a practical automation tool for a real audience that struggles with video production.

Read full analysis →

3. switch ⭐ 4.4/10

Advisor: 8.0 | Devil: -6.0 | Historian: 4.0 | Budget Steward: -1.0 | Founder: 7.0
Source: producthunt

Switch addresses a genuine and growing pain point: teams want AI agents embedded directly in their collaboration workflows rather than switching to separate chat interfaces. The value proposition is strong — one integration point, unified context per room, cross-platform support (Slack, Teams, Discord, Telegram), and compatibility with major AI frameworks (Claude Code, OpenAI, Google ADK, LangChain). The open-source, self-hostable angle lowers adoption barriers significantly and creates a natural wedge into enterprise environments that prefer data sovereignty. The "connect once, use across projects" model reduces friction for repeat adoption. This taps into the accelerating trend of agentic AI moving from standalone tools to embedded assistants — a market segment projected to grow rapidly as organizations mature their AI workflows. The timing is favorable: collaboration platforms have mature bot APIs, and enterprise AI adoption has moved past the hype phase into practical integration work.

Read full analysis →

4. widgo ⭐ 4.4/10

Advisor: 8.0 | Devil: -6.0 | Historian: 4.0 | Budget Steward: -1.0 | Founder: 7.0
Source: producthunt

Widgo addresses a clear and painful problem: businesses lose leads because website visitors don't get immediate, personalized responses. The value proposition is strong — an AI rep that scans the site, ingests docs, scores leads, and books demos in "one line of code" hits the sweet spot of low integration friction + high perceived value. The "free forever, no card" pricing is a clever land-and-expand play that removes friction for early adoption. For SMBs and indie SaaS companies especially, having a 24/7 AI rep that qualifies and books meetings is a compelling upgrade over basic chatbots. The opportunity is in the volume of small businesses with websites but no sales team. If execution is solid, this could become a category-defining tool in the AI automation space.

Read full analysis →

5. show hn: bodily oddities ⭐ 4.3/10

Advisor: 7.0 | Devil: -4.0 | Historian: 3.0 | Budget Steward: -1.0 | Founder: 7.0
Source: hn

This is a charming micro-site that taps into universal human curiosity about the body — everyone has experienced strange bodily sensations but few know they have names. The value lies in being an accessible, digestible resource for "wait, everyone gets this?" moments. The submission form adds a community-driven content engine, creating organic growth loops. The topic has strong shareability — people love sending these kinds of pages to friends saying "remember this?" Potential pathways include affiliate links to related products, a newsletter, or eventually expanding into a broader health-curious brand. It's essentially a curiosity-driven content hub with very low overhead.

Read full analysis →

6. mizzlelover/gongwen-gbt9704-skill ⭐ 4.3/10

Advisor: 7.0 | Devil: -4.0 | Historian: 3.0 | Budget Steward: -1.0 | Founder: 7.0
Source: github

This project addresses a genuine, niche pain point in Chinese administrative workflows. GB/T 9704-2012 is the national standard for official document formatting in China — every government agency and many enterprises must comply. Manually formatting 公文 (official documents) to meet this standard is tedious and error-prone. An LLM skill that generates compliant DOCX files automatically is a compelling value proposition for a well-defined audience.

The companion CEB ( ChunEBoWang ) format project extends the utility into document exchange workflows, creating a small ecosystem. The open-source nature lowers adoption barriers and positions the author for community-driven improvements. With the rapid growth of AI agent/skill ecosystems (LangChain, AutoGen, etc.), distributing a GBT9704 skill through these channels could reach users without heavy marketing.

Read full analysis →

7. our recall was 0.087 and the model was innocent: how domain-scoped replay doubled it ⭐ 4.3/10

Advisor: 8.0 | Devil: -5.0 | Historian: 3.0 | Budget Steward: -1.0 | Founder: 7.0
Source: devto

This project addresses a real and painful problem in AI agent development: low recall rates (0.087 in the case study). Domain-scoped replay as a technique to double recall by capturing and reusing successful agent interactions is a solid technical insight. The fact that it's already released on PyPI with version 0.3.0 suggests active development and practical usage.

Key value drivers:

Solves a concrete performance bottleneck in production AI systems
Open-source release lowers adoption barriers
Practical tool rather than theoretical framework
Addressing AI agent reliability is a growing market need

The concept of turning repeated interactions into "rules" is extensible — it could become a knowledge base or learning system for multi-agent environments.

Read full analysis →

8. show hn: compute polynomials twice as fast ⭐ 3.7/10

Advisor: 6.0 | Devil: -6.0 | Historian: 2.0 | Budget Steward: -1.0 | Founder: 7.0
Source: hn

This project is a practical interface for a novel polynomial evaluation algorithm developed through academic collaboration. The core opportunity lies in translating theoretical computer science work—specifically reducing multiplication counts in polynomial hashing—into an accessible tool anyone can use. The 100-page Lean proof provides rigorous correctness guarantees that most open-source projects lack, which is a genuine differentiator. The potential value is significant for developers working in hash functions, cryptographic primitives, and competitive programming. However, the target audience is relatively narrow: researchers, systems programmers, and optimization enthusiasts. The website serves as both a demo and documentation layer, lowering the barrier to adoption for a method that would otherwise remain locked in academic papers. If the speedup is meaningful across a broad range of polynomial sizes, it could become a go-to reference. The opportunity is real but niche—worth building if executed as a clean, well-maintained resource with clear benchmarks.

Read full analysis →

9. crwdla/tokentab ⭐ 3.7/10

Advisor: 8.0 | Devil: -6.0 | Historian: 1.0 | Budget Steward: -1.0 | Founder: 7.0
Source: github

Tokentab addresses a genuine pain point: developers using multiple AI coding assistants (Claude Code, OpenAI Codex, Gemini CLI) have no unified view of their spending. Each platform reports costs separately, if at all, making it hard to understand total AI expenditure.

Value proposition:

Multi-platform cost aggregation is genuinely useful — no single tool currently does this across Claude, Codex, and Gemini
CLI-first approach fits the developer workflow perfectly
"By project and day" breakdown is actionable for budgeting and cost optimization
Low friction adoption: reads existing log files, no API integrations needed
Clear monetization paths: open-source core with pro features (CSV export, alerts, dashboards) or a hosted dashboard

The timing is excellent — AI coding tool usage has exploded, and cost visibility is a top concern for individuals and teams.

Read full analysis →

10. nullrun ⭐ 3.5/10

Advisor: 7.0 | Devil: -5.0 | Historian: 4.0 | Budget Steward: -1.0 | Founder: 7.0
Source: indiehackers

nullrun positions itself in the rapidly emerging "AI Agent Governance" category — a B2B SaaS that helps organizations manage, monitor, and govern AI agents at scale. This is a real pain point that's accelerating as companies deploy more autonomous AI agents in production. The opportunity sits at the intersection of two massive trends: enterprise AI adoption and the compliance/governance requirements that come with it (EU AI Act, NIST AI RMF, etc.). The value proposition is clear: without governance, AI agents become uncontrolled risk vectors. If nullrun can deliver observability, policy enforcement, and audit trails for AI agents, it addresses a genuine compliance and operational need. The B2B SaaS model with a 7-month MVP suggests focused execution. The market is early but hungry — first movers in agent governance could capture significant mindshare. The key question is whether they've carved out a defensible niche or are entering a crowded compliance tooling space.

Read full analysis →

10 projects every week. Watch the AI era unfold with us. Follow along to see what's really happening.

GoGraph updates, Providing Structural Awareness to AI Coding Agents in Go.

Wed, 09 Sep 2026 18:31:10 +0000

GoGraph Four Months Later: From Repository Map to Evidence Layer for AI Coding Agents

A few months ago, I wrote about a problem I kept seeing with AI coding agents: they could write Go perfectly well, but before doing anything useful they spent a surprising amount of their context window trying to understand the repository.

They would grep for symbols, guess filenames, read large files, follow imports manually, and slowly reconstruct relationships that the Go compiler already knows.

That was the motivation behind GoGraph.

The first version I wrote about in May was relatively simple in concept: parse a Go repository, turn its structure into a graph, and expose that graph to coding agents through CLI commands and MCP.

The basic idea has not changed.

But GoGraph itself has changed quite a lot.

Today, I would describe it less as a static repository map and more as a local evidence layer between a Go codebase and an AI coding agent.

The Original Model: Give the Agent a Map

The first version concentrated heavily on AST-based structural analysis.

GoGraph parsed source code and extracted things such as:

packages
functions and methods
imports
calls
interfaces and implementations
HTTP routes
tests
SQL-related structures
error paths

Commands such as plan, review, and errorflow were intended to answer practical questions before and after an agent edited code.

Instead of:

grep
rg
awk
sed
read file
grep again
read another file
guess

the agent could ask GoGraph for a bounded structural answer.

That is still useful, and the AST layer still exists.

The limitation is that Go is not completely understandable from syntax alone.

Consider this:

type Store interface {
    Save(User) error
}
func Create(s Store, u User) error {
    return s.Save(u)
}

From the AST, we know that Create calls Store.Save.

But that does not necessarily tell us which concrete Save implementation executes.

That becomes increasingly important once an agent starts reasoning about impact rather than simply locating code.

GoGraph Now Has a Precision Layer

The largest architectural change is that GoGraph no longer relies only on syntactic relationships.

Precise builds now use Go’s type information together with go/packages, go/types, SSA, and Class Hierarchy Analysis.

The result is effectively a two-layer model.

The AST layer remains fast, resilient, and useful even when a repository cannot be fully type-checked.

The precision layer adds compiler-aware relationships when the repository can be successfully loaded.

This matters particularly for interfaces.

An AST-level analysis might know that:

service -> Repository.Save

Type-aware analysis can identify actual implementations of that interface.

SSA analysis can sometimes go further and prove that a particular interface value contains one concrete implementation at a call site.

GoGraph deliberately distinguishes those cases.

A call that is proven receives different treatment from a call that is merely a possible dynamic dispatch target.

That distinction turned out to be important for agents.

An AI should not see:

A calls B

when what the analysis actually knows is:

A may call B

Those are different facts.

Exact and Possible Relationships

This led to another change in the graph model.

Relationships now carry more information about how strongly GoGraph knows them.

For example, paths can contain relationships that are:

exact
ambiguous
possible

Commands can request exact-only results when an agent needs a conservative answer.

When several possible paths exist, GoGraph also ranks them deterministically rather than returning whichever traversal happens to find first.

The preference is roughly toward:

stronger evidence
shorter paths
production code rather than tests
typed resolution rather than heuristics
fewer cross-repository transitions

This sounds like an implementation detail, but it changes agent behavior substantially.

Determinism is useful when an LLM repeatedly asks the same structural question during planning, editing, and review. The answer should not change merely because map iteration order changed.

A First-Call Tool for Agents

One problem became obvious after using GoGraph with actual coding agents.

Even with dozens of specialized commands, the agent first has to know which command to use.

So GoGraph now has explore.

For example:

gograph explore "authentication middleware"

or through MCP, gograph_explore.

It performs bounded lexical discovery and, when a symbol can be selected unambiguously, combines several kinds of context into one response:

matching symbols
source location
direct callers
direct callees
tests
upstream impact
package context
deeper call relationships when requested

There are compact and deep modes.

This is deliberately not semantic RAG.

GoGraph does not pretend that it “understands” a natural-language question. It tokenizes the query deterministically, finds structural candidates, and reports how the selection was made.

If a symbol is ambiguous, it exposes the ambiguity instead of silently picking one.

That is an important design rule throughout the newer versions of GoGraph:

Uncertainty should be data, not something hidden by the tool.

From Repository Analysis to Change Analysis

The original plan idea answered:

What could be affected if I modify this symbol?

That is useful before editing.

But after an agent has changed the repository, the more interesting question is:

What did I actually change, and what does that change affect?

GoGraph now performs declaration-level change analysis against Git references and the working tree.

It distinguishes things such as:

edited declarations
added declarations
removed declarations
excluded declarations
changes that cannot be evaluated reliably

Untracked Go files are included when looking at working-tree changes.

This also avoids a surprisingly dangerous failure mode.

Imagine the agent deletes a function.

Looking only at the current graph cannot tell you who called the deleted function, because the function no longer exists.

Change analysis therefore needs historical evidence from the baseline rather than pretending the current graph contains enough information.

When GoGraph does not have enough evidence to calculate an impact safely, newer versions prefer to report that the evaluation is incomplete rather than returning an empty impact set.

For AI tooling, “I cannot prove this” is much safer than “nothing is affected.”

Graph Freshness Became a First-Class Concept

Another thing I underestimated in the original version was graph freshness.

A perfectly accurate graph of yesterday’s checkout is still the wrong answer.

GoGraph now tracks graph state explicitly.

Results can distinguish:

persisted vs. in-memory graph
current vs. stale graph
complete vs. partial parsing
AST vs. precise vs. precision-fallback analysis

MCP can refresh stale graphs automatically.

If precise enrichment fails but AST analysis succeeds, GoGraph can return the fresh AST result while explicitly saying that precise analysis failed.

If refreshing itself fails, it can retain the last trusted graph while exposing that it is stale.

The important part is that these states are not collapsed into one vague “success.”

For an AI agent, provenance matters.

There is a substantial difference between:

No callers found.

and:

No callers found.
Graph: current.
Analysis: precise.
Parsing: complete.

There is an even larger difference between that and:

No callers found.
Graph: stale.
Analysis: AST fallback.

The model should be allowed to reason differently about those answers.

Large Results Are Now Explicitly Bounded

Token efficiency was the original reason I created GoGraph, so there is an obvious irony if a structural query returns a 200 KB JSON response.

Newer GoGraph query APIs therefore put considerably more effort into bounded output.

Large result sets use deterministic pagination and expose information such as:

total
returned
truncated
next_cursor

The cursor is tied to the graph snapshot and query selection, so it cannot silently continue over a different graph after the repository changes.

MCP output also has an explicit response-size budget.

This is not merely an API optimization.

A tool built for LLMs needs to consider context consumption as part of its interface design.

Traditional developer tooling often assumes:

Returning more information is better.

Agent tooling often has the opposite requirement:

Return the smallest amount of information that preserves the evidence required for the decision.

Better Test Reasoning

Test discovery has also moved beyond simply asking whether a symbol name appears in a _test.go file.

GoGraph can now trace tests transitively through call relationships and distinguish exact test coverage paths from possible ones.

This becomes useful with architectures where a test reaches the target through several layers:

TestCreateUser
    -> handler
        -> service
            -> repository
                -> Save

Router callbacks and other intermediary functions can participate in that attribution.

Interface-backed test doubles are also important.

GoGraph’s typed test analysis can recognize cases where a test assigns a concrete fake or mock to an interface and prove the resulting call target when the type information allows it.

That makes commands such as tests and untested much more useful as structural evidence for coding agents.

It still does not mean “this code is correctly tested.”

That requires running the tests.

It means something narrower and more defensible:

These tests have a statically observable relationship to this declaration.

SQL Became Structured Evidence

SQL started as another useful static extraction target.

It has since become a more structured query system.

GoGraph can classify statically resolvable PostgreSQL statements and expose information such as:

operation
read/write access
referenced tables
access per table
source location
module
test/production origin

It understands more than literal strings.

Statically provable local constants, variables, assignments, and bounded concatenations can also participate in SQL resolution.

Dynamic SQL is intentionally not presented as if it were fully known.

The result is useful for questions such as:

Which code writes the oauth_clients table?

or:

Which production paths execute DELETE statements?

Again, the goal is not to replace a SQL parser, database audit system, or runtime tracing.

It is to give an agent a useful static census of evidence that exists in the repository.

HTTP Relationships Also Became More Precise

Route extraction existed in the original version, but HTTP reasoning has expanded.

GoGraph now distinguishes constructing an HTTP request from actually proving that the request is dispatched.

It can preserve statically known URL bases and suffixes.

More importantly, this becomes useful in the workspace model.

A repository can declare mappings between outbound HTTP client authorities and another repository in the same workspace.

That allows GoGraph to represent a relationship such as:

frontend-api
    -> HTTP request
        -> identity-service
            -> POST /users
                -> CreateUser handler

without inventing relationships from runtime environment variables or guessed hostnames.

GoGraph Can Now Analyze a Workspace

This is probably the biggest conceptual expansion since the original article.

Modern systems are often not one Go repository.

You may have:

identity-service/
agent-service/
gateway/
shared-lib/

Each repository has its own graph.

GoGraph can now build a workspace overlay across them.

The individual repository graphs remain independent. The workspace adds explicitly resolved relationships between them.

These can include cross-repository Go relationships and configured HTTP relationships.

The workspace can then answer questions such as:

What path connects this gateway handler
to this identity-service function?

or:

What repositories may be affected by this change?

There is also a separate read-only workspace MCP server exposing:

gograph_workspace_status
gograph_workspace_query
gograph_workspace_path
gograph_workspace_impact

This matters because the “whole codebase” visible to an AI agent is increasingly not the same thing as a Git repository.

The useful unit is often the engineering workspace.

Go Build Configuration Is Part of the Graph

Another source of false confidence is pretending that a Go repository has one universal structure.

It often does not.

Build tags, GOOS, GOARCH, GOFLAGS, cgo, go.work, generated files, and module selection can all change which source files constitute the program.

GoGraph now records the effective build selection used to construct the graph.

Explicit build tags are supported.

If the environment used to query a persisted graph no longer matches the environment used to build it, the graph can be considered stale rather than silently mixing incompatible views of the program.

That is another example of something which is easy to ignore in a developer convenience tool but important in an evidence tool.

Local Does Not Automatically Mean Safe

The original article emphasized that GoGraph runs locally.

That remains true.

But over time I became much more conservative about what “local static analysis” should be allowed to touch.

The current code performs extensive path and source confinement checks.

Among other things, it treats Go build inputs, module/workspace metadata, graph artifacts, and generated files carefully around symbolic links and repository boundaries.

The goal is simple:

Asking an AI agent to inspect an untrusted repository should not casually turn a static-analysis request into arbitrary traversal outside the intended source tree.

Go tooling itself can legitimately access module caches, proxies, and toolchains, so the boundary cannot simply be “never touch anything outside the repository.”

Instead, GoGraph tries to distinguish repository-controlled source authority from legitimate Go dependency resolution.

This security work is considerably less visible than a new query command, but I now consider it part of the core design.

MCP Is No Longer Just a Wrapper Around CLI Output

MCP was already present in the original version.

Its role has expanded.

The project MCP server now exposes most of GoGraph’s repository analysis capabilities directly, with CLI and MCP generally sharing the same underlying result contracts.

That prevents an unfortunate architecture where:

CLI implementation
       +
separate MCP implementation

slowly develops different semantics.

The MCP server can also expose its own version and analysis capabilities, which matters because restarting an MCP process is necessary after installing a newer GoGraph binary. An already-running process does not magically inherit the new tool schema.

The server still runs locally over stdio.

There is no hosted GoGraph service receiving the repository.

What Has Not Changed

Despite all of these additions, there are several things I deliberately do not want GoGraph to become.

It is not an AI model.

It does not decide what code should be written.

It does not replace go test.

It does not replace the compiler.

It does not replace runtime tracing.

It does not replace semantic code search.

And it should not pretend static analysis can prove runtime behavior that static analysis cannot see.

I increasingly think the useful division of labor looks like this:

LLM

reasoning
interpretation
implementation

Semantic search / grep

discovery
text
configuration
documentation

GoGraph

structural evidence
relationships
impact
provenance
uncertainty

Go compiler / tests

executable verification

These tools complement each other.

The Larger Lesson

When I wrote the first article, I described the problem mostly as a context-window problem.

I still think that is true, but I would phrase it slightly differently now.

The scarce resource is not simply tokens.

It is reliable context.

Giving an agent 50,000 lines of source code is context.

Giving it this:

CreateUser
  exact caller:
    POST /api/v1/users -> UsersHandler.Create
  exact dependency:
    UserRepository.Insert
  database:
    INSERT -> users
  attributed tests:
    TestCreateUser
    TestCreateUserDuplicate
  graph:
    current
    precise
    complete

is also context.

But the second form has already converted a large amount of syntax into a much smaller set of claims.

That is where I now see GoGraph fitting.

It is not trying to make the LLM smarter.

It is trying to reduce how much of the LLM’s intelligence has to be spent rediscovering facts that static analysis can provide deterministically.

The original goal was to give AI coding agents a map.

The current goal is slightly more demanding:

Give them evidence, identify where that evidence came from, distinguish certainty from possibility, and say when the evidence is incomplete.

For coding agents operating on large Go systems, I think that is a much more useful foundation.

GoGraph on GitHub: https://github.com/ozgurcd/gograph

The Day I Stopped Copying Code and Started Learning

Sat, 22 Aug 2026 13:08:34 +0000

As developers, we’ve all done it.

You search for a problem, find a solution on Google, Stack Overflow, GitHub, or an AI tool, copy the code, make a few changes—and finally, it works.

But then someone asks:

“Can you explain how this works?”

And suddenly… silence.

That moment can teach us one of the most important lessons in programming:

Writing code is not the same as understanding code.

In today's world, getting code has become easier than ever. AI can generate functions in seconds. Online communities provide thousands of ready-made solutions. Open-source projects give us access to amazing code.

But there is a difference between using code and learning from code.

The Copy-Paste Trap

Copying code is not always bad. In fact, developers do it all the time. The problem starts when we copy something without understanding:

What does each part do?
Why was this approach used?
What happens if something fails?
Can I modify it for a different situation?
Could I build a similar solution on my own?

If we never ask these questions, we may solve today's problem but learn nothing for tomorrow's.

A Better Way to Learn

Next time you find a solution, try this:

1. Read Before You Run

Take a few minutes to understand the logic. Don't immediately press Run.

2. Change Something

Modify a variable, remove a line, or test a different input. See what happens.

3. Break the Code

Yes—intentionally!

Breaking code is one of the fastest ways to understand how it works.

4. Rebuild It Without Looking

After understanding the solution, close the original and try writing it again from memory.

You may fail the first time.

That's okay.

Struggling to remember is often part of learning.

5. Explain It Simply

Try explaining the code as if you were teaching a beginner.

If you can explain it simply, you probably understand it.

AI Makes This Even More Important

AI coding tools are powerful. They can help us learn faster, debug problems, and explore new technologies.

But we should avoid becoming developers who only know how to ask:

“Give me the code.”

Instead, try asking:

“Explain why this solution works.”
“Show me a simpler version.”
“What are the alternatives?”
“What mistakes could happen here?”
“Give me a challenge so I can build it myself.”

AI should be our learning partner, not a replacement for thinking.

The Real Goal

The goal is not to memorize every line of code.

Even experienced developers search for documentation and examples.

The real goal is to develop the ability to think, understand, adapt, and solve problems.

Because copied code may solve one problem.

But understanding teaches you how to solve the next hundred.

What do you think?

Have you ever copied code that worked perfectly—but later realized you had no idea how it actually worked?

Share your experience in the comments. Let's learn from each other!

Sumita
Web Developer

Building an Anti-Proxy -Offline-First Attendance Platform with Next.js, Express & Firebase

Sat, 11 Jul 2026 03:43:18 +0000

Traditional attendance systems seem simple until you look at how they work in practice. Manual roll calls consume valuable class time, paper attendance sheets are inefficient, and many QR-based systems can still be exploited through proxy attendance.

I wanted to explore whether a better solution was possible.

This project is my attempt at designing and building an offline-first anti-proxy attendance platform from scratch as a solo developer. The goal wasn't just to digitize attendance, but to create a system that remains reliable in real-world environments while prioritizing security, scalability, and a smooth user experience.

The platform is built using Next.js 16, React 19, TypeScript, Express.js, Firebase Authentication, Firestore, Firebase Admin SDK, Tailwind CSS, Capacitor, Progressive Web Apps (PWA), Sentry, and dynamic QR-based authentication.

Rather than focusing only on features, this article explores the engineering decisions behind the project: why I chose an offline-first architecture, how dynamic QR validation improves security, the reasoning behind the technology stack, the challenges I faced during development, and the lessons I learned while building a production-style application that is already being used in my college club.

The project is still evolving, and I continue to improve it whenever I have time. My aim is to keep documenting that journey by sharing not only what works, but also the mistakes, trade-offs, and architectural decisions that shaped the system.

If you're interested in full-stack development, system design, Next.js, Firebase, TypeScript, or building software that solves practical problems, I hope you'll find something valuable in this article.

⭐ GitHub: https://github.com/siddarthpatelkama

LinkedIn: https://www.linkedin.com/in/siddarthpatelkama

I'm always open to feedback, suggestions, and discussions with fellow developers. If you have ideas for improving the project or questions about the implementation, I'd love to hear from you.

Vibe Coding Explained: What It Is, Best Tools, and How to Start in 2026

Thu, 11 Jun 2026 17:41:12 +0000

On February 2, 2025, Andrej Karpathy coined the term "vibe coding" - a style of development where you describe what you want in plain English, the AI writes the code, you run it, fix problems by describing them, and ship. You stop reading the code in detail. You just feel the vibes and go.

Collins Dictionary named it their 2025 Word of the Year. By early 2026, over 110,000 developers search for it monthly, a $4.7 billion market has formed around it, and 63% of people now vibe coding were never traditional programmers.

What Is Vibe Coding?

Vibe coding is AI-first software development. Instead of writing every line yourself, you describe what you want to build in plain language, and an AI coding assistant - like Cursor, Claude Code, or Lovable - writes the implementation. You review, run, describe problems, and iterate.

The name comes from the "vibe" - the feeling of momentum when software builds itself and you're steering rather than typing. You're a product director giving instructions to an AI developer.

The core loop:

Describe - tell the AI what you want to build or fix
Review - scan what the AI produced (spot-check, don't line-read)
Run - execute and test manually
Iterate - describe problems or next features, repeat

Vibe Coding vs. Traditional Coding

Both approaches are valid - the question is which fits your situation.

Traditional coding gives you full control and high quality but is slower. Vibe coding is fast for prototyping and MVPs but code quality is variable - the AI makes mistakes.

72% of professional developers who've tried vibe coding still primarily write code themselves for production work. But 63% of vibe coders are not professional developers - they're founders, researchers, designers, and domain experts who need working software without years of programming experience.

Best Vibe Coding Tools in 2026

Cursor - The dominant vibe coding environment for developers. A fork of VS Code with AI built into every layer: tab completion, inline generation, a chat sidebar that reads your entire codebase, and Composer mode for multi-file edits. Best for developers who want full IDE capabilities with deep AI integration. Pro at $20/month.

Claude Code - Anthropic's CLI tool, top-ranked for complex multi-file work. It lives in your terminal, reads your repo, runs commands, edits files across your whole project, and manages Git autonomously. Best for delegating entire tasks, not just getting suggestions.

OpenAI Codex - Cloud-based coding agent that runs tasks asynchronously in a sandboxed environment. You describe what you want built, and it works through the task independently, reporting back when done. Included with ChatGPT Plus ($20/month).

Lovable - The best tool for non-developers. A browser-based AI app builder that creates a complete React frontend with a Supabase backend. No local setup required. Best for founders and designers who want a real deployed web app. Free tier available, Pro at $20/month.

Replit - Cloud IDE with an AI agent. Everything - coding, hosting, database, deployment - is in one place. Best for beginners and quick demos with zero environment setup.

v0 by Vercel - Specializes in UI components. Describe a component in plain language, get production-ready React and Tailwind code back. Best for building polished interfaces quickly, pairs well with Cursor for the backend.

Build Your First App: A Walkthrough

This example uses Cursor to build a simple URL bookmark manager.

Open Cursor Composer (Cmd+I) and describe the app - what it should do, what stack to use, any design preferences
Cursor generates the files - click "Accept All"
Run it with npm install && npm run dev - you have a working app
Iterate by describing problems: "The list is showing URLs without titles - fix it so titles display prominently"
Before shipping, ask the AI: "Review this code for security issues - list any problems"

That last step is non-optional. It takes 30 seconds and can save you from shipping something broken.

Security and Quality: The Part Everyone Skips

This is what the hype cycle ignores:

45% of AI-generated code fails at least one OWASP Top 10 vulnerability check
53% of developers have found security vulnerabilities in AI-written code
63% of developers have spent more debugging AI code than they would have writing it themselves

None of this means vibe coding is bad. It means vibe coding without review is bad.

Always check for:

XSS: AI commonly uses innerHTML without sanitization
Exposed API keys: AI sometimes embeds secrets in client-side JavaScript
SQL injection: verify parameterized queries are used everywhere
Auth gaps: AI often forgets to protect routes
Overly permissive CORS: AI default configs often allow all origins

A useful habit: after any significant code generation session, ask "Act as a security reviewer. List every security concern in this code, from critical to minor."

Vibe Coding for Non-Developers

63% of people vibe coding today are not professional developers. If you're a founder, researcher, or domain expert, vibe coding is probably the most practical path to building software for your specific needs.

Good starter projects:

Internal tools: a spreadsheet replacement that does exactly what your team needs (Lovable or Replit, 2-3 hours)
Data dashboards: connect to a CSV or API and display charts (v0 for UI, Claude Code for data wiring)
Automations: a script that handles a repetitive task (Claude Code is excellent here)
Simple websites: landing pages, portfolios, product pages (v0 + Lovable)

Realistic time expectations:

Personal script or automation: 30 min - 2 hours
Simple internal tool: 2 - 8 hours
Landing page with contact form: 1 - 4 hours
MVP web app (CRUD + auth): 1 - 3 days
Production SaaS with payments: 1 - 4 weeks (plus real review)

The bigger the project, the more you need to understand what the AI built. Vibe coding a 30-line script is nearly risk-free. Vibe coding a multi-user SaaS without reviewing auth and payment code is genuinely dangerous.

Is Vibe Coding Here to Stay?

Yes. AI models are getting better at code faster than most developers predicted. Tasks that required deep understanding six months ago can often be delegated to an AI agent today. Developer work shifts toward architecture, product decisions, code review, and testing strategy - away from line-by-line implementation.

For non-developers, vibe coding is creating an entirely new category of software builders. People who could never ship software before are now shipping.

The risk to watch: as the barrier to shipping code drops, the discipline around reviewing, testing, and securing that code has to rise to compensate.

Conclusion

Vibe coding is a permanent shift in how software gets made - and the shift is still accelerating. The developers and builders winning with it share one habit: they stay in the driver's seat. They use AI for implementation speed while keeping their own judgment on what gets shipped.

Pick one tool and build one real thing:

Lovable or Replit if you've never written code before
Cursor if you have some programming background and want full control
Claude Code if you're comfortable in a terminal and want to delegate entire tasks

The security section of this guide is not optional. Thirty seconds asking the AI to review its own code for vulnerabilities will catch most serious issues. Do it every time.

References

https://devtoollab.com/blog/vibe-coding

How I Lost a Six-Figure SaaS Contract to a "Vibe Coder" (Even Though I Used AI Too)

Sat, 06 Jun 2026 22:59:01 +0000

Have you seen the think-pieces. "AI is coming for your jobs." "English is the new programming language." As a seasoned software developer based in South Africa, I used to think I was ahead of the curve. I wasn't an AI denier; in fact, I actively use Agentic AI assistants to cut down my development time, spin up boilerplates, and ship features faster than ever.

I thought leveraging AI inside my IDE made me very competitive.
Oh boy i was wrong by huge margin. Recently, I didn't just lose a lucrative, six-figure administrative SaaS contract to AI—I lost it to a human who didn't write a single line of code. I lost it to an Operations Manager who decided to "vibe code" an entire alternative system.

Here is the wake-up call of how it happened, the sobering conversation we had, and why merely using AI as a coding assistant does not put us(software developers) head and shoulders above the rest.

The Setup: Fast Shipping, False Security

In early 2025, I landed a highly competitive contract to build a comprehensive administrative SaaS solution for a prominent local company in South Africa which does high end corporate events and venue management services. There was no single source of truth, operations and admin very disjointed. They need a solution to streamline operations and have one source of truth to make operations as efficient and effective as possible.I did my workflows audits and came up with a workable system that the owners loved, well eventually.

There were feedback meetings we held after my presentation and made adjustments from the suggestions I got from management and lower staff. After a month or so my solution was adopted and went live. It was a bespoke SaaS.

Using Claude Code helped me code components, generate APIs, and I rapidly deployed both a web portal and mobile application. Thanks to AI assistance, I built it in record time. The client was thrilled, and the project naturally transitioned into a highly lucrative monthly maintenance contract.
I felt completely secure. I was the "10x engineer" who knew how to prompt, how to code, and how to architect. I held the keys to the repository.

Then came the Operations Manager.

The Plot Twist: "Please don't be angry with me..."

The company’s Operations Manager is brilliant at his job, but he has zero software development background. He couldn't write a loop if his life depended on it. What he did have, however, was a 100% granular view of the company's daily operational bottlenecks—angles I hadn't fully captured because I didn't live in their day-to-day chaos.

Instead of waiting for me to build custom features on my retainer, he signed up to Claude Max5 began vibe coding. He just fed the AI business logic, real-world data structures, and company pain points.
Within two months, he didn't just build a prototype. He built a comprehensive, highly practical, fully functioning alternative SaaS solution.

When he finally revealed what he had done, he asked to sit down with me. I'll never forget how the conversation started. He looked at me nervously and said:

"Please don’t be angry with me. What I’m about to tell you might make you furiously angry with me..."
He then laid out his alternative system and explained his reasoning plainly: "I didn’t want the company to keep spending massive amounts of money on a maintenance retainer when I could just build what we needed myself. It took me two months, spent about $700 on the build."

His solution was vastly cheaper than my contract, completely tailored to their exact workflows, and it worked. He successfully beat me out of my own contract.

The Realization: AI-Assisted Coding vs. Pure Vibe Coding

This was a massive slice of humble pie. My immediate defense mechanism was to think, "But I used AI to build my system too! My code is cleaner, safer, and better architected!"
But here is the brutal reality we have to face as professional developers: Knowing how to code using AI didn't protect me from the guy who doesn't know how to code at all.

Why? Because I was using AI to write code. He was using AI to write solutions.
I was focused on syntax efficiency, database optimization, and deployment pipelines. He was focused 100% on the organizational problems because he understood the business inside and out. To management, a $700 system built by an insider that solves 95% of their immediate operational problems today will always win over a beautifully architected, expensive system built by an external dev, who is me and you.

By being dismissive or elitist about "vibe coders," we are actively pushing ourselves out of business. Our direct competition is no longer just other software agencies; it’s the ambitious, frustrated employee inside our client's office.

The Blueprint: How We Take the Lead

If someone with zero coding knowledge can build a super-alternative SaaS system in two months for a few hundred dollars, imagine what we can do if we combine actual engineering fundamentals with that same level of business-centric execution.

We need to shift our focus immediately:

1. Stop Hiding Behind the Code
Having our hands 100% under the hood isn't the flex it used to be. We need to spend less time worrying about the lines of code and more time understanding the business domain. If we don’t have a 100% view of the organization’s actual day-to-day problems, a vibe coder who does will replace us.

2. Move from Developers to "Super-Architects"
Vibe-coded applications are amazing for immediate business logic, but they eventually hit walls regarding complex security, data compliance (like POPIA here in South Africa), and massive scaling. Our value is no longer in typing the code faster than them; it's in being the guardrails. We should be the ones helping them architect, secure, and scale these systems safely.

3. Build at 100x Speed, Not 10x
If non-technical builders are using AI to disrupt us, we must use our technical knowledge to out-pace them. We know how databases should handle edge cases. We know how APIs should be secured. By combining deep engineering logic with high-speed AI generation, a single professional developer should be able to ship entire enterprise ecosystems over a weekend.

The Silverlining

Losing that contract was a painful lesson, but it forced me to see where the tech landscape is heading. The gatekeeping era of software development is officially dead.
Have you ever been bypassed by a non-technical stakeholder building their own tools? If you are a developer who uses AI, how are you changing your strategy to ensure you're delivering unique value that a "vibe coder" can't replicate?

Let’s chat in the comments below!

Why Most Vibe Coded SaaS Apps Fail in Production (Even When They Work Perfectly Locally)

Tue, 19 May 2026 14:30:13 +0000

Most early-stage SaaS projects don’t fail because the idea is bad.

They fail because the code was never designed for production in the first place.

This is especially common in what I call “vibe coding”:

Shipping fast, copying patterns, and assuming “it works” means “it’s correct”.

It usually leads to silent system-level problems that only appear later.

The illusion of working software

A common pattern looks like this:

Authentication works
APIs respond correctly
UI behaves as expected
No errors in development

So everything feels “done”.

But production environments expose a different reality.

Where things quietly break

Most issues are not obvious bugs.

They are design oversights like:

insecure token handling
hardcoded secrets
missing validation layers
trusting frontend input
logging sensitive data unintentionally

Individually, they don’t break the app.

Together, they break trust in the system.

The real problem: mindset

The issue isn’t technical ability.

It’s the development approach:

Build feature → verify it works → move on.

Without asking:

what happens under load?
what happens if logs leak?
what happens if inputs are manipulated?
what happens at scale?

Production thinking vs vibe thinking

Vibe coding focuses on:

speed
output
visible success

Production engineering focuses on:

failure modes
security boundaries
system behavior over time
controlled exposure of data

Both can produce working apps.

Only one produces stable SaaS products.

What changes everything

The shift happens when you stop asking:

“Does this work?”

And start asking:

“Where does this break?”

That single question changes how you design everything from authentication to architecture.

Final thought

Most SaaS failures are not sudden.

They are accumulated design decisions that were never revisited.

Fixing that starts early, not after launch.

Bridging the Context Gap: Providing Structural Awareness to AI Coding Agents in Go with GoGraph

Thu, 14 May 2026 15:44:55 +0000

The hardest part of using AI coding agents isn't getting them to write Go code. It's watching them burn through your context window just trying to figure out where things are.

If you’ve spent any time using Claude, Antigravity or Copilot on a medium-to-large Go codebase, you know the drill. You ask the agent to modify a core component. Before it writes a single line of code, it starts blindly running grep, guessing file paths, and sequentially cat-ing files.

By the time the agent finally maps out the upstream HTTP handlers, the database interactions, and the interface satisfactions, it has exhausted a massive chunk of its token limit. The context window is bloated with irrelevant side-material and raw text dumps. The more noisy, unstructured code you feed the agent, the higher the chance it gets confused and starts hallucinating bad logic.

Agents don't fail because they are bad at writing logic. They fail because they have to brute-force their way to structural awareness.

I got tired of watching my AI tools waste tokens and context guessing my repository structure, so I built Gograph. It’s a local static analysis engine and Model Context Protocol (MCP) server that gives your AI agents a deterministic, whole-repository structural map of your Go projects in a single, token-efficient JSON query.

Why RAG and Terminal Searching Aren’t Enough

Right now, the industry usually tries to solve the codebase context problem in two ways: vector embeddings through RAG, or by letting agents inspect the repository through terminal commands. Both approaches are useful, but neither is sufficient on its own for reliable understanding of a large Go codebase.

The issue with RAG is that vector embeddings are good at semantic retrieval. If you want to find code related to “user authentication logic,” embedding search can often surface relevant files or nearby concepts. But embeddings do not provide deterministic code intelligence. They cannot prove that UserStore.Update() satisfies the Datastore interface, identify every caller across package boundaries, or trace how an error propagates through several layers of middleware. Those relationships require parsing, type checking, and static analysis.

The issue with terminal search is that agents often fall back to tools like grep, rg, or reading files directly. These tools are valuable for exact strings, symbols, config keys, routes, and quick navigation. But plain text search cannot reliably capture relationships that only exist after the compiler understands the program. In Go, interface satisfaction is implicit, indirect calls may flow through interfaces, and behavior may depend on build tags, generated code, or package-level wiring. A search-only approach is likely to miss non-obvious dependencies.

For large Go repositories, reliable agent context needs more than semantic search and raw file inspection. It needs compiler-aware code intelligence: symbols, packages, imports, interfaces, implementations, call graphs, route mappings, test relationships, and error flows. RAG can help find relevant areas. Terminal tools can help inspect concrete files. But the agent also needs structured knowledge of how the code actually fits together.

Fixing It With Static AST Analysis

Instead of relying only on semantic similarity or raw text search, I wanted a tool that gives agents structured knowledge of a Go repository.

Gograph uses Go’s native parsing infrastructure, including go/ast and go/parser, to build a static graph of your repository. It runs entirely on your local machine: no network requests, no sending proprietary source code to third-party APIs. Its goal is to map concrete code structure such as packages, symbols, functions, methods, struct fields, imports, call sites, route wiring, tests, and recognizable dependency paths.

Gograph ships with more than 20 specialized static analysis commands, including tools to map concurrency primitives, identify oversized objects, discover potentially dead code, and extract SQL-related structure. However, I designed three primary commands specifically to act as the core structural guardrails for AI agents.

1.gograph plan

Before an agent touches a file, it can run plan. Gograph analyzes the static code graph around the symbol and returns an impact-oriented view of the surrounding code.

It can show callers, related packages, upstream HTTP routes where they are statically detectable, whether the execution path appears to touch persistence-related code, and which test files are likely to be affected.

This gives the agent a concrete starting point instead of forcing it to guess from embeddings or repeatedly read files into context.

2.gograph review

After the agent makes an edit, it can run review. This acts as a structural sanity check over the affected area.

It can flag likely breakage in routing paths, changed dependencies, stale tests, and interface-related drift where those relationships are visible to static analysis. It is not a replacement for compilation or go test. It is an earlier feedback layer that helps agents catch structural mistakes before running the full verification loop.

3.gograph errorflow

When a test fails with an error like "invalid token signature", the agent should not have to guess where that message originated. It can pass the string to errorflow.

Gograph searches for where the error is created or wrapped, then follows the static return and call path as far as it can identify it. When the path is visible in the source graph, it can show how the error moves from the originating function toward higher-level handlers or tests.

This is useful in larger Go services where errors often pass through repository, service, middleware, and handler layers before reaching the test output or API response.

What It Looks Like in Practice

Let’s say you need an AI agent to add a TenantID field to a User struct in a shared package.

If the agent relies only on raw search, it may find the struct, add the field, update the local constructor, and stop. The build may still fail because a POST /api/v1/users handler in another package initializes the struct directly, or because repository code, SQL mapping, and integration tests also need updates.

If the agent uses Gograph first, it can query the User symbol and get a structured view of the surrounding code. That view can show that the symbol is connected to a specific POST route, appears in repository code, participates in SQL-related paths, and is referenced by specific test files.

The agent now has a better bounded scope for the change. Instead of editing one obvious file and discovering failures one by one, it can update the struct, handler, persistence path, and tests in a single coherent pass.

Hooking It Up via MCP

Gograph works as a standalone CLI, but it is also designed to be consumed by AI agents through the Model Context Protocol, or MCP.

MCP is an open protocol introduced by Anthropic for connecting AI systems to local tools and data sources. Gograph ships with a built-in MCP server that operates over standard I/O.

Instead of forcing the model to read and interpret unstructured terminal output, the MCP integration gives it structured, machine-readable JSON.

For an MCP-compatible client such as Cursor or Claude Desktop, the configuration looks like this:

{
  "mcpServers": {
    "gograph": {
      "command": "gograph",
      "args": ["mcp", "/path/to/your/repository"]
    }
  }
}

Once registered, the agent can query the repository graph before editing. It can inspect the structural impact of a proposed change, identify likely affected files, and build a more grounded execution plan before writing code.

Getting Started

If you’re building in Go and tired of cleaning up after your AI tools, you can install Gograph right now:

# macOS / Linux (via Homebrew)
brew install ozgurcd/tap/gograph
# Or using Go:
go install github.com/ozgurcd/gograph/cmd/gograph@latest

Final Thoughts

AI agents work better when they are given structured context instead of raw text alone. RAG is useful for semantic retrieval. Terminal commands are useful for exact inspection. But large Go codebases also need code-aware context: packages, symbols, call paths, routes, tests, persistence boundaries, and error flows.

That is the problem Gograph is trying to solve.

If you’re building in Go and tired of cleaning up after your AI tools, give Gograph a try.

Source Code and Documentation: https://github.com/ozgurcd/gograph

If you have ideas for other static analysis heuristics that would be useful for AI context, I'd love to hear your feedback! Feel free to open an issue or start a discussion on the GitHub repository.

LibKill: Scan Your Machine for Compromised npm, pip, and Bun Packages

Wed, 13 May 2026 11:02:12 +0000

Over the last few weeks, supply chain security has once again become a very real problem for developers.

We keep seeing the same attack pattern:

CI/CD token stolen
→ malicious package version published
→ developers install or update dependencies
→ compromised code lands on real machines

And the worst part is simple:

You may already have one of those compromised packages on your machine without knowing it.

That is why I built LibKill.

What is LibKill?

LibKill is an open-source supply chain security scanner.

It checks your local development environment against a database of known compromised package artifacts.

Currently, it scans:

npm global packages
pip packages
Bun cache

Then it cross-references what it finds against 2,672+ known compromised package artifacts.

If something suspicious is detected, LibKill can help you remove it interactively.

Why I built it

Most developers hear about compromised packages after the damage is already done.

A package gets reported.
A malicious version is removed.
A GitHub advisory appears.
A security company publishes an analysis.

But then comes the real question:

“Is any of this already on my machine?”

That question should be easy to answer.

LibKill is my attempt to make that check fast, local, and simple.

Features

LibKill currently supports:

Scanning npm global packages
Scanning installed pip packages
Scanning Bun cache
Cross-checking against known compromised artifacts
Interactive removal when threats are found
Background daemon mode
Desktop notifications
macOS, Linux, and Windows support
Single binary
Zero runtime dependencies

It is written in Go and distributed as a small standalone binary.

Installation

You can install it with one command:

curl -fsSL https://raw.githubusercontent.com/firfircelik/libkill/main/install.sh | bash

Or build it manually:

git clone https://github.com/firfircelik/libkill.git
cd libkill
make install

Example usage

After installation, run:

libkill scan

To start background monitoring:

libkill daemon

If compromised artifacts are found, LibKill will show the results and offer interactive cleanup options.

Threat coverage

LibKill currently covers known compromised artifacts related to campaigns and threat clusters such as:

Mini Shai-Hulud
Contagious Interview
StegaBin
SANDWORM_MODE
CanisterWorm
W4SP
TeamPCP
and many others

The threat database is built from public security sources including:

Socket.dev
GitHub Advisory Database
OSV.dev
Public security research

Why local scanning matters

A lot of supply chain security tools focus on repositories, lockfiles, or CI pipelines.

That is useful, but it does not fully answer what is already installed locally.

Developers often install tools globally.

They test packages.

They use temporary scripts.

They work across multiple languages and package managers.

They forget what was installed weeks ago.

A compromised package does not need to be in your current production repository to be a problem.

It may already exist somewhere in your local environment.

Project details

Language: Go
License: MIT
Binary size: around 14 MB
Dependencies: zero runtime dependencies
Platforms: macOS, Linux, Windows

GitHub:

https://github.com/firfircelik/libkill

Final note

LibKill is still evolving.

My goal is to make it a practical local security tool for developers who work with open-source packages every day.

If you work with npm, Python, Bun, or modern JavaScript tooling, you should not have to guess whether a known compromised artifact exists on your machine.

You should be able to check it quickly.

That is what LibKill is for.

Feedback, issues, and contributions are welcome.

curl -fsSL https://raw.githubusercontent.com/firfircelik/libkill/main/install.sh | bash

Vibe coding got you here. Now what?

Mon, 11 May 2026 12:30:00 +0000

TL;DR: Vibe coding ships fast, but it often fails to preserve the reasoning behind product behaviors — and agents refactoring later will “reasonably” change things users rely on. A lightweight behavior spec (.pbc.md) makes “what must happen / must not happen” explicit so future you (and future agents) know what to protect, starting with high-risk modules like billing and auth.

Vibe coding works. If you've used it seriously, you know this. You describe a feature, the model drafts it, you push it. Things that used to take a day take an hour. You ship faster than you ever have.

The problem isn't the speed. The problem is what gets left behind.

What "left behind" means

When you build normally — even scrappily — the reasoning behind a decision usually ends up somewhere. In a comment, a commit message, a Slack thread, a ticket. Imperfect, but traceable.

When you vibe code, you're in a flow state. You describe what you want, the model gives you something close, you adjust, you ship. The gap between intention and implementation is so small that writing it down feels redundant.

Weeks later, you have a product that works but you can't fully explain why it works the way it does.

Not the code — you can read the code. The reasoning. Why does the cancellation flow work like this? Why is the grace period five days and not seven? Why does the export fail silently on empty results instead of returning an error?

The code remembers what you built. It doesn't remember why.

Why this compounds with AI coding agents

The original vibe coding problem — reasoning drift — is bad on its own. AI coding agents make it worse in a specific way.

Agents don't just read your code. They make inferences about intent. When you ask Claude Code or Codex to refactor a module, they read the existing implementation and decide what behavior to preserve and what to change. Without explicit constraints, that decision is partly guesswork.

The agent isn't being careless. It's doing exactly what you asked. But it's filling in missing context with reasonable-looking assumptions — and reasonable assumptions about code aren't the same as correct assumptions about product behavior.

The result: a refactor that passes tests and breaks something real. An "improvement" that changes behavior your users depend on. A simplification that removes an edge case that was load-bearing.

You can't blame the agent for this. The rules were never written down.

The missing layer

There's a layer between "what the code does" and "what the product promises" that most teams never formalize. PRDs describe intent. Tests verify implementation. Neither one captures the behavior spec — the durable record of what your product guarantees and why.

For teams that have been building for years, this layer lives in accumulated memory. For vibe-coded products, it often doesn't exist at all.

That's the gap. And the longer you wait to address it, the more expensive it gets.

What to do about it

You don't need to slow down to fix this. You need a format that fits the way you actually work.

That's what behavior specs are — formally Product Behavior Contracts (PBC) — a lightweight Markdown format for capturing what your product promises to do. Not a PRD. Not tests. Not Gherkin. Just the smallest artifact that makes product reasoning explicit and version-controlled.

The key is the level of abstraction. A behavior spec doesn't describe the code — that changes with every refactor. It doesn't describe the strategy — that's too vague for agents to act on. It captures the decision: "Grace period is 14 days. Not configurable per plan. No data deletion during grace." The part that stays true even if you rewrite the module from scratch.

The pattern is:

PRD explains why (temporary — dies after shipping). PBC specifies what must remain true (durable — lives as long as the product does). Code and tests prove how (changes constantly).

A .pbc.md file sits in your repo. It documents behaviors, rules, edge cases, and the decisions behind them — in plain Markdown your whole team can read. It's structured enough that tools can parse it, lightweight enough that you'll actually maintain it.

The goal isn't to slow down the vibe. It's to leave something behind for future you — and for every agent that touches your codebase next.

Start small

You don't need to spec the whole product at once. Start with the module that would cause the most damage if an agent got it wrong. Billing. Auth. Entitlements.

Write down three things for each behavior: what must happen, what must not happen, and the edge cases that matter. That's it. That's your behavior spec.

Vibe coding got you here. A behavior spec is how you stay here.

If you want to understand the deeper problem, read The gap between what your product does and what your team thinks it does. For what a behavior spec actually looks like, see What is a Product Behavior Contract?.

The PBC spec is open source at github.com/stewie-sh/pbc-spec. Stewie is the product being built on top of it — join the beta waitlist if you want early access.

The Sovereign Answering Machine: Demystifying the Cloud

Sun, 10 May 2026 14:31:10 +0000

We’ve been looking at the Cloud all wrong.

We treat it like a high-security vault where we pay rent to keep our data alive.
In reality, the Cloud is just a Telephone Line. ☁️

With Gnoke-Zero, I’ve realized that the "Big Boys" pay massive bills for 24/7 uptime because their logic and data live in someone else's data center. But when you own the Kernel (the browser) and the Driver (the disk), the Cloud’s job changes.

The Post Office, Not the Warehouse

You don't need the Cloud to store your student scores or inventory logs. Gnoke-Spirit and SaveNative already do that on your device.

You only need the Cloud to stay awake while you sleep—like an answering machine.

The Process:

When a collaborator makes a change, they leave a "message" on the cloud line.

The Sync:

When you open your Infinix phone, iPad, Windows PC, Linux devices... Gnoke pulls the missed messages, and your local driver flushes them to your disk.

The Bill Killer

By using a cheap shared host or a free tier as an Event Relay instead of a Database, you stop moving heavy cargo.

You aren't uploading files; you're broadcasting "events."

It’s faster, consumes less data, and costs less to maintain. ⚡

Decoupling Collaboration from Ownership

The breakthrough isn't just that it's local—it's that it's Sovereign Hybrid.

The internet is now just a peripheral. It’s a cable connecting two local hard drives.

If the cloud provider shuts down, you lose the "live chat," but you lose zero data.

You just plug into a new "telephone line" and keep moving.

What This Does Not Mean

This does not replace all backend infrastructure or centralized systems.

It redefines what actually needs to remain centralized.

Some systems will still require traditional servers for scale, orchestration, security, analytics, or global uptime. The point is that many everyday apps are over-centralized by default when ownership and persistence could live closer to the user.

The conclusion:

The server doesn't always need to be a warehouse.

Sometimes it just needs to be a switchboard.

The Browser is the Runtime.
The Disk is the Database.
The Cloud is the Messenger.

The Architect’s Intuition: Why Theory Fails Without "Vibe

Tue, 05 May 2026 08:00:06 +0000

The "Vibe" Gap: Theory vs. Intuition

Most people start by learning how a system should behave—the theory, the documentation, the "right" way. But engineering starts when you realize that what you were told and what you feel are two different things.

1. The Power of "Legacy" Intuition

If you grew up with the snap of Windows XP or the glass aesthetic of Windows 7, that isn't just nostalgia; it’s a benchmark for responsiveness and UI density. When you can recognize an OS color or a boot sound from across the room, you have a built-in "quality detector" that theory can't teach.

2. Learning by Realization

Building is a cycle of "Theory vs. Reality." You might design a tool to be perfectly minimal, only to realize mid-build that it lacks a "History" or a "Pin" feature. You didn't fail the design; you just discovered a practical truth that the theory missed.

3. Using AI as the Bridge

The goal isn't just to write code; it's to stay in the "flow state." Use AI assistants to handle the syntax of these familiar patterns so you can focus on the soul of the project. Our strengths aren't just in what we learn today, but in the familiarities we've carried with us for years.

The Lesson: Start where you are told, but build toward where you are drawn. That pull you keep returning to is where your best work lives.

Build what feels right, refine with theory, and let intuition guide the systems you trust to ship.

Vibe coding out loud.

AI No-Code & Vibe-Coding Tools Devs Are Actually Talking About in 2026

Thu, 30 Apr 2026 13:06:38 +0000

Look, not every project needs a full stack. Sometimes you just need to ship something — a prototype, an internal tool, a landing page — without spinning up a whole repo and CI/CD pipeline. That's where this new wave of AI-powered no-code and vibe-coding tools comes in.
I've been poking around a bunch of them lately. Here's what's worth your attention.

explain.codes — When You Need to Understand, Not Just Copy

Before anything else: explain.codes is your "wait, what does this actually do" bookmark. It covers Python, JavaScript, Java, SQL, HTML, and more — written in plain language with real examples.
It's not a builder, it's a reference. But if you're working with AI-generated code (from any of the tools below) and something looks off, this is where you go to actually understand what's happening instead of just re-prompting and hoping.

Instructa — The Course That Teaches You to Build With AI

If you want to go deeper than just vibing with prompts, Instructa is a structured academy for learning AI-assisted software development. 80+ video lessons, planning prompts, Discord community, regular updates.
It's developer-focused — you learn how to go from idea to roadmap to working product using AI as your co-pilot. More systematic than most "learn to code with AI" content out there.

Unicorn Platform — Fastest Landing Page You'll Ever Ship

Unicorn Platform is an AI website builder for devs and founders who just need a landing page live TODAY. Describe your project, get a clean site. Works well for SaaS, apps, directories, personal portfolios.
No messing with templates for hours. It's the kind of tool you use on a Sunday afternoon when you want to validate an idea before writing a single line of backend code.

Metatable — Full-Stack App Builder, Actually

Metatable is more serious. You give it your app idea, it drafts technical requirements, then an AI agent writes both frontend and backend code — and checks for errors before deploying.
It's spec-driven, which is the right approach. Use cases range from inventory tools to field management to agency ops. If you're a solo dev who wants to ship a real product faster, this is worth a proper look.

Atoms.dev — An Entire AI Team in One Platform

Atoms.dev is the most ambitious one on this list. Instead of one AI assistant, you get a whole crew: engineer, product manager, SEO specialist, data analyst, researcher. Each handles a different slice of building and launching a product.
You describe what you want — SaaS, internal tool, game, landing page — and the AI team validates it, builds it, and helps you acquire users. No coding required. It's still early-days territory, but the concept is smart: most people don't need a code editor, they need leverage.

Eloquens AI — Automate Your Inbox Before It Automates You

Eloquens is different from the rest here — it's not about building products, it's about handling the communication that comes after. Specifically, email. It reads your incoming messages (content and context both), and drafts responses automatically, 24/7, in any language.
For developers building SaaS products, this becomes relevant fast once you start getting real users. Customer support emails don't stop coming. Eloquens is built by IgniteTech and has proper press coverage behind it — not a weekend project.

A Note on Webdraw

Webdraw.ai was on my radar but the site currently redirects to a "Thank You for the Journey" page — looks like it shut down or pivoted. Keeping it here as a reminder that this space moves fast. Not everything sticks.

Bottom Line
The vibe-coding wave isn't replacing developers — it's changing where developers spend their time. Less boilerplate, more product decisions. Tools like Metatable and Atoms.dev are genuinely useful for prototyping fast. Unicorn Platform handles the boring landing page problem. Instructa and explain.codes keep you sharp when the AI does something weird.
If you're a dev who wants to ship side projects faster or explore the no-code space from a technical angle, start with one of these and see where it takes you.

Vibe Coding Is Fun Until Production Breaks

Wed, 15 Apr 2026 00:26:05 +0000

Vibe coding is exactly what it sounds like: you describe what you want, your AI coding agent writes the implementation, and you ship it. No wrestling with boilerplate, no context-switching into unfamiliar APIs, no debugging stack traces line by line. Just intent → code → deploy.

It is genuinely fast. Teams that have adopted AI-first development workflows report shipping features in hours that previously took days. The experience is intoxicating.

The problem shows up in production. Not always immediately, not always dramatically — but consistently. A checkout flow that worked in the demo breaks for users in a specific browser. An edge case in the new auth logic causes silent failures. A UI component that the agent refactored now behaves differently when the viewport changes. The AI wrote correct code for the happy path, but nobody verified the full surface area.

This is the vibe coding quality gap: the speed gain is real, but the verification step got left out.

What Vibe Coding Actually Skips

Traditional software development has a built-in quality loop. Developers write code, run tests, review diffs, and iterate before shipping. Each step adds friction — but that friction catches bugs.

Vibe coding compresses this loop dramatically. The agent writes the code, you review a high-level summary, and the diff goes out. The problem is that the review step scales poorly with the agent's output. A human can meaningfully review 50 lines of code. Reviewing 500 lines of agent-generated implementation across five files is a different task entirely.

What actually gets skipped in most vibe coding workflows:

End-to-end verification — does the feature actually work from a user's perspective?
Regression coverage — did the agent's changes break something it wasn't supposed to touch?
Edge case validation — what happens with empty states, network failures, or unexpected inputs?
Cross-browser consistency — did the agent's CSS choices work everywhere?

These are not hypothetical concerns. Research on AI-generated code quality consistently shows that AI-written code introduces bugs at higher rates than carefully reviewed human code — not because the models are bad, but because the verification loop is truncated.

The Speed Trap

Here is the dynamic that makes vibe coding quality gaps compound over time.

When you ship fast and something breaks, the natural response is to have the agent fix it. The agent patches the bug, you ship the patch, and you move on. This works fine for isolated issues. But over weeks and months, an unverified codebase accumulates a debt of untested edge cases. Each fix potentially introduces new issues. The agent has no memory of what it previously changed or why.

Without a persistent test suite, you have no ground truth. You cannot tell whether the latest agent commit made things better or worse in aggregate. You only find out when a user reports something.

This is not a problem with the AI coding agents themselves — they are doing exactly what they were designed to do. It is a workflow design problem. The quality layer was never added.

Adding QA to Your Vibe Coding Workflow

The good news is that vibe coding and comprehensive testing are not in conflict. The same agents that write your application code can be directed to write tests, run verifications, and maintain a quality gate — if you give them the right tools.

Step 1: Give your agent a browser

The most immediate gap in vibe coding workflows is live browser verification. Your agent can write a component, but it cannot see what that component looks like or how it behaves without a browser.

Shiplight's browser MCP server gives your AI coding agent eyes and hands in a real browser. During development, the agent can open your application, navigate through the new feature, and verify that what it built actually works — before the code leaves your machine.

This closes the most common vibe coding failure mode: code that passes linting and type checks but fails in practice.

Step 2: Capture verifications as regression tests

Every time your agent verifies a feature in the browser, that verification can become a permanent test. Shiplight converts browser interactions into YAML test files that live in your repo and run automatically in CI.

These are not brittle tests that break every time your UI changes. The tests are written against the intent of each step ("Click the submit button", "Verify the confirmation message appears"), not against specific DOM selectors. When your agent makes future changes, the tests adapt rather than fail on superficial differences.

Step 3: Run tests on every agent commit

Once you have a test suite, wire it into your CI pipeline so every agent-generated commit gets verified before merge. Shiplight's GitHub Actions integration makes this a one-time setup.

The result: your agent can ship code at full vibe coding speed, and you get a regression gate that catches problems before they reach production.

The Intent-Cache-Heal Pattern for Vibe Coders

Traditional test automation breaks constantly because tests are tied to implementation details — specific CSS selectors, DOM structure, element IDs — that agents change freely. This is why most vibe coding teams do not bother with E2E tests: the maintenance burden exceeds the value.

The intent-cache-heal pattern solves this. Tests describe what the user is trying to accomplish, not how the UI is currently built. When your agent restructures a component, the test heals automatically because the intent has not changed — only the implementation.

This is the missing piece that makes comprehensive testing compatible with vibe coding's pace. You are not maintaining tests after every agent commit. The tests maintain themselves.

What a Vibe Coding + QA Workflow Looks Like

A practical workflow looks like this:

Describe the feature to your agent (Claude Code, Cursor, Codex, or any MCP-compatible agent)
Agent implements the feature and opens it in a real browser via the Shiplight MCP server
Agent verifies the feature works end-to-end and documents the verification as a YAML test
CI runs the test suite on the pull request — any regressions block the merge
Agent fixes flagged issues with the context from the test failure output
Merge with confidence — the full feature surface is verified

The agent handles steps 2 through 5. Your job is to define the intent and review the evidence. That is what vibe coding should feel like.

Frequently Asked Questions

What is vibe coding?

Vibe coding is a development style where developers use AI coding agents to write code by describing intent in natural language. The AI agent handles implementation while the developer focuses on what the product should do rather than how to build it.

Why does vibe coding produce bugs?

Vibe coding itself does not produce more bugs than traditional development — but the truncated review cycle means bugs are caught later. AI coding agents write for the specified requirements and may miss edge cases, cross-browser differences, or regressions in code they did not explicitly touch.

Can AI agents write their own tests?

Yes. With the right tooling, AI coding agents can generate tests automatically from their own verifications. Shiplight's MCP server lets agents verify features in a real browser and capture those verifications as self-healing YAML test files that live in your repo.

Does adding tests slow down vibe coding?

Not significantly, when tests are generated automatically by the agent rather than written by hand. The overhead is a one-time CI setup. After that, tests run in the background and only interrupt the workflow when a real regression is found.

How do self-healing tests work with frequently changing UIs?

Self-healing tests are written against the intent of each user action, not specific DOM selectors. When the UI changes, the test framework resolves the correct element by matching the described intent to the current page state. See What Is Self-Healing Test Automation for a full explanation.

References: Playwright Documentation, GitHub Actions documentation

The Axios Supply Chain Attack: How a "Phantom Dependency" Compromised Millions

Tue, 31 Mar 2026 09:23:40 +0000

On March 31, 2026, the software development and Web3 communities were hit by one of the most severe supply chain attacks in recent history. Axios, an incredibly popular JavaScript HTTP client with an estimated 100 million to over 300 million weekly downloads, was compromised. Threat actors injected a malicious dependency that delivered a cross-platform Remote Access Trojan (RAT) directly to developer workstations, CI/CD runners, and enterprise servers.

When the attack first happened, Axios maintainers were unable to regain control of the project. In a public GitHub issue, a collaborator stated they could not revoke access from the account responsible for the malicious publish, noting that the attacker’s permissions exceed their own.

This incident stands out not just for its massive blast radius, but for the sophisticated techniques the attackers used to bypass modern CI/CD safeguards, evade forensic detection, and exploit modern AI-assisted development habits.

Account Hijack and Bypassing SLSA Provenance

The attack was not the result of a vulnerability in the Axios source code. Instead, it was a direct release-path hijacking. The attacker compromised the npm account of Jason Saayman, the primary maintainer of the Axios project, and changed the associated email to an attacker-controlled ProtonMail address (ifstap@proton.me).

Using these compromised credentials, the attacker manually published two malicious versions: axios@1.14.1 and axios@0.30.4. This manual publication via the npm CLI bypassed the project's standard GitHub Actions continuous integration pipeline. Consequently, these malicious versions lacked OIDC Trusted Publisher cryptographic SLSA provenance, and had no corresponding source code commits or tags on the official Axios GitHub repository.

The "Phantom Dependency" Injection

To avoid drawing attention through large code modifications, the attacker did not alter a single line of the actual Axios JavaScript source. Instead, they made a surgical edit to the package.json file, adding a new dependency: plain-crypto-js@^4.2.1.

This is known as a "phantom dependency." The plain-crypto-js package was never imported or required anywhere in the Axios execution path. Its sole purpose was to exist in the dependency tree so that npm would automatically execute its postinstall lifecycle script ("postinstall": "node setup.js") during routine dependency resolution.

To build credibility and evade zero-history scanners, the attacker (using the account nrwise@proton.me) first published a clean decoy version of the package (4.2.0) containing legitimate cryptography library code. Just minutes before pushing the poisoned Axios releases, they published the malicious 4.2.1 update.

Obfuscation and Platform-Specific RATs

When a developer or build server ran npm install, the setup.js dropper was triggered. This script utilized a custom two-layer obfuscation scheme designed to defeat static analysis. Strings were reversed, base64-encoded, and padded with underscores, then decrypted using a position-dependent XOR cipher derived from the key "OrDeR_7077" and XORed again with the constant 333.

Once deobfuscated, the dropper detected the host operating system (os.platform()) and contacted the Command and Control (C2) server at http://sfrclak.com:8000/6202033 (IP: 142.11.206.73). To blend in with legitimate traffic, the malware spoofed HTTP POST bodies to look like npm registry requests, using strings such as packages.npm.org/product0.

The C2 server dynamically delivered specialized second-stage payloads:

macOS (product0): An AppleScript fetched a Mach-O universal binary RAT written in C++. It was saved to /Library/Caches/com.apple.act.mond—deliberately mimicking Apple's reverse-DNS daemon naming conventions to blend into routine system background processes—and executed via /bin/zsh.

Windows (product1): The dropper utilized an Endpoint Detection and Response (EDR) evasion tactic by copying the system's PowerShell binary to %PROGRAMDATA%\wt.exe to disguise it as Windows Terminal. A hidden VBScript then silently executed a .ps1 PowerShell RAT reflectively.

Linux (product2): The dropper fetched a Python script to /tmp/ld.py and ran it as a detached background process using nohup python3. This allowed the malware process to orphan itself to PID 1, surviving long after the initial npm install command had terminated.

Anti-Forensics and the "Vibe Coding" Threat

After the malware was successfully deployed, the setup.js script immediately initiated a self-destruct sequence. It deleted its own script file, deleted the infected package.json, and restored a pre-staged clean decoy (package.md) in its place. As a result, any developer casually inspecting the node_modules/plain-crypto-js directory post-infection would see a clean cryptography library with no postinstall hook, effectively neutralizing shallow forensic audits.

The rapid propagation of this malware was severely exacerbated by the modern AI "vibe coding" trend. Developers utilizing AI agents (such as Claude) to scaffold applications frequently execute npm install commands without manually auditing package.json diffs or lockfiles. Because developers implicitly trusted the AI's output, the malware cascaded into downstream AI tooling within hours, compromising packages like @shadanai/openclaw and @qqbrowser/openclaw-qbot.

Immediate Remediation Plan

If you or your CI/CD pipelines installed axios@1.14.1 or axios@0.30.4, you must assume total host compromise. The payload has full capabilities to exfiltrate SSH keys, cloud CLI credentials, and crypto-wallet private keys. Remediation requires a comprehensive response:

Pin Safe Versions: Explicitly lock Axios to 1.14.0 or 0.30.3 in your package.json and lockfiles.

Hunt for Artifacts: Check for the presence of the node_modules/plain-crypto-js directory, /tmp/ld.py, %PROGRAMDATA%\wt.exe, or /Library/Caches/com.apple.act.mond.

Rebuild, Don't Clean: If artifacts are found, do not attempt to clean the system in place. Rebuild affected developer machines and persistent CI runners from known-good base images.

Rotate All Secrets: Rotate any SSH keys, cloud credentials, npm tokens, and .env variables that were present on the host during the npm install window.

Enforce Safe Installs: Update your CI/CD pipelines to default to npm ci --ignore-scripts to categorically prevent dependency lifecycle scripts from executing without explicit authorization during automated builds.

The Anatomy of the LiteLLM Supply Chain Attack: A Catastrophic Compromise in the AI Ecosystem via "Vibe Coding"

Fri, 27 Mar 2026 10:41:09 +0000

The Anatomy of the LiteLLM Supply Chain Attack: A Catastrophic Compromise in the AI Ecosystem via "Vibe Coding"

The Keys to the AI Kingdom

On March 24, 2026, the artificial intelligence developer ecosystem experienced an unprecedented software supply chain attack. The target was litellm, an immensely popular Python package with 97 million monthly downloads that serves as a universal adapter connecting applications to over 100 LLM APIs from providers like OpenAI, Anthropic, and Google.

The attacker, a financially motivated threat group known as TeamPCP (also tracked as PCPcat, Persy_PCP, ShellForce, and DeadCatx3), managed to publish two malicious versions (1.82.7 and 1.82.8) directly to the Python Package Index (PyPI). Over a critical 46-minute window, these compromised versions were downloaded 46,996 times before being quarantined. As product growth writer Aakash Gupta noted, the attackers brilliantly "picked the one package whose entire job is holding every AI credential in the organization in one place".

The Irony of the Attack Chain:

When Security Tools Become Weapons

The story of the LiteLLM compromise reads like an M. Night Shyamalan movie full of tragic twists. The vulnerability did not stem from sloppy coding in LiteLLM itself, but ironically, from the maintainers correctly using a security scanner.

The attack chain started weeks earlier when an AI-powered autonomous agent named "hackerbot-claw" (or "openclaw") targeted Aqua Security's trivy-action, a widely used open-source vulnerability scanner. The AI bot exploited a highly dangerous pull_request_target GitHub Actions workflow misconfiguration, allowing attackers to steal a privileged token. With this token, TeamPCP rewrote the immutable-looking Git tags for Trivy's v0.69.4 release to point to a malicious commit.

On March 24, when the LiteLLM CI/CD pipeline ran the poisoned Trivy scanner during their automated build process, the security tool executed the malware and exfiltrated LiteLLM's PYPI_PUBLISH token. Armed with this credential, TeamPCP bypassed standard GitHub release protocols and uploaded the malware directly to PyPI.

Two Delivery Mechanisms:

Source Injection and the Dreaded .pth Hook

The attackers deployed two distinct versions with different injection techniques:

Version 1.82.7 (10:39 UTC): The payload was double base64-encoded (a technique YouTubers jokingly referred to as "double based") and embedded directly inside proxy_server.py. It exfiltrated data to checkmarx[.]zone/raw, a typosquat of a legitimate security vendor compromised in a parallel attack.

Version 1.82.8 (10:52 UTC): This escalated the attack using a 34,628-byte file named litellm_init.pth dropped into the site-packages/ directory. The .pth mechanism fires on every Python interpreter startup with no import required. Because the malicious file was correctly declared in the wheel's RECORD file, it perfectly bypassed pip hash verification checks.

The Three-Stage Payload:

Catching Credentials "Like Pokémon"

Once triggered, the malware executed a sophisticated three-stage operation. In Stage 1, it treated system secrets "like Pokémon," attempting to aggressively catch them all. The script harvested SSH private keys, .env files, Git credentials, Slack/Discord webhooks, CI/CD configs (Terraform, GitLab, Jenkins), and database passwords. It targeted cloud environments specifically, reading ~/.aws/credentials, querying AWS IMDS endpoints, and making live API calls to AWS Secrets Manager and Kubernetes clusters. It even swept the system for cryptocurrency wallets, targeting Bitcoin, Litecoin, Ethereum, Solana, Cardano, and Monero.

In Stage 2, the exfiltration was highly secured. The malware generated a random 32-byte AES-256 session key to encrypt the stolen data (PBKDF2 key derivation). This session key was then encrypted using a hardcoded 4096-bit RSA public key embedded in the payload. Bundled into an archive named tpcp.tar.gz, the data was exfiltrated to models.litellm.cloud (registered just one day prior).

Stage 3 established lateral movement and persistence. The malware dropped a backdoor Python script at ~/.config/sysmon/sysmon.py and created a systemd service called "System Telemetry Service". On Kubernetes clusters, it used stolen service account tokens to read secrets across all namespaces and deployed privileged alpine:latest pods named node-setup-{node_name} to install the backdoor directly onto the underlying host machines. To mock security researchers analyzing the malware in sandboxes, the C2 server was configured to return a link to an English remastering of the song "Bad Apple!!".

"Vibe Coding" and the Accidental Fork Bomb

Despite its sophistication, the stealthy attack was uncovered within an hour due to a sloppy implementation bug. Callum McMahon, a researcher at FutureSearch, was testing an MCP plugin inside the Cursor IDE. Because Cursor used uvx to launch the MCP server, it automatically pulled in litellm as an unpinned transitive dependency.

When the .pth file triggered upon installation, it used subprocess.Popen to spawn a child Python process. However, because .pth files trigger on every Python startup, the child process repeatedly re-triggered the payload, accidentally creating an exponential fork bomb that spawned 11,000 processes and exhausted the RAM on McMahon's 48GB Mac.

Using Claude Code, McMahon decoded the base64 string (import subprocess\nimport tempfile) and discovered the rogue package. Prominent AI scientist Andrej Karpathy pointed out the extreme irony of this accidental discovery. In his analysis, Karpathy emphasized: "So if the attacker didn't vibe code this attack it could have been undetected for many days or weeks". The malware's own poor quality is exactly what made it visible.

The GitHub Cover-Up and the Compliance Tragicomedy

When McMahon reported the malware on the BerriAI/litellm GitHub repository (Issue #24512), TeamPCP actively suppressed the disclosure. Using the fully compromised account of LiteLLM maintainer Krrish Dholakia, the attackers abruptly closed the critical security issue as "not planned". Simultaneously, they deployed a botnet to flood the thread with 88 fake, AI-generated replies (e.g., "great explanation thanks for sharing") in just 102 seconds to confuse investigators. The attackers even used the compromised maintainer account to subtly change Calendly meeting invite links to fake ones.

Adding a final layer of dark comedy to the incident, users discovered that LiteLLM advertised its security through a compliance company named Delve, promising "AI native compliance". Ironically, Delve itself was simultaneously facing accusations of misleading customers with fake SOC 2 compliance reports, perfectly encapsulating the chaotic state of modern software security.

"Software Horror" and the "Yoink" Philosophy

The blast radius of this 46 minute window was catastrophic. Because the contagion spreads transitively, major AI frameworks like DSPy, MLflow, OpenHands, and CrewAI automatically pulled the malware as an indirect dependency. TeamPCP claims to have stolen 300GB of compressed credentials from over 500,000 systems and is actively extorting multi-billion dollar companies like Stripe, Netflix, and Google.

Andrej Karpathy labeled the incident an absolute "software horror". Emphasizing the absurdity of the situation, he stated: "Simple pip install litellm was enough to exfiltrate SSH keys, AWS/GCP/Azure creds, Kubernetes configs, git credentials, env vars (all your API keys), shell history, crypto wallets, SSL private keys, CI/CD secrets, database passwords".

He warned of the massive contagion effect, explaining that "if you did pip install dspy (which depended on litellm>=1.64.0), you'd also be pwnd". Karpathy summarized the ultimate lesson of the breach: "Supply chain attacks like this are basically the scariest thing imaginable in modern software. Every time you install any dependency you could be pulling in a poisoned package anywhere deep inside its entire dependency tree."

Classical software engineering treats dependencies as inherently good a mindset Karpathy described as believing "we're building pyramids from bricks." However, he warns this philosophy must be re evaluated. Instead of relying on massive, opaque dependency trees, developers should use LLMs to "yoink" (extract and copy) only the specific code fragments they need directly into their codebases when it is simple enough and possible.

Security experts advise that anyone who installed or indirectly pulled litellm versions 1.82.7 or 1.82.8 must assume total system compromise. Remediation requires a complete rotation of all SSH keys, cloud tokens, database passwords, and API keys, along with purging package manager caches and thoroughly auditing Kubernetes environments for persistent backdoors. Ultimately, this incident serves as a historical warning that even the most trusted security tools and AI wrappers can become the very vectors that destroy an organization's infrastructure.

CodeDNA: An In-Source Communication Protocol for AI Coding Agents

Thu, 26 Mar 2026 13:25:06 +0000

I’ve been working in software development for 15 years, but this is my first independent open-source publication. It stems from a practical frustration I believe many of you share.

Working with AI coding tools and agent orchestrators (like Google Antigravity, Anthropic(claude), or Cursor), I noticed something: models write single-file code excellently, but they struggle to navigate and tend to hallucinate as soon as they need to understand the architecture of an entire multi-file project.
To try and solve this, I built CodeDNA (currently v0.7 and heavily experimental).
It’s a true inter-agent communication protocol.

The idea is that the source file itself becomes the asynchronous communication channel between different LLMs. When an agent modifies the code, it updates the annotations. When another agent (perhaps from a different vendor) opens that file months later, it "decodes" this DNA and knows exactly how to move.

CodeDNA is inspired by how the human eye works. To understand a complex system, we need to focus both from far away and up close. Instead of relying on heavy RAG systems or infinite prompts, the code itself becomes the shared memory, structured across multiple levels of "zoom":
The view from far away: A structural map of the project (a .codedna file) that the agent reads before opening any source code. The view from close up: Architectural context (like who uses the file, used_by:, and domain rules, rules:) embedded directly into the docstrings.

Early data (the good and the bad): I ran zero-shot benchmarks on 5 real Django issues (SWE-bench). On tasks with clear dependency chains, CodeDNA improved navigation precision by +13%. The goal of this scaffolding is exactly this: to eventually allow smaller, cheaper models to approach the navigation performance of the most expensive frontier models. However, on cross-cutting modifications, the measured improvement so far is ~0%. No magic wands here, and it’s all documented transparently in the spec.

️ My ask: try it out. Because this is a purely experimental project, the best way to see if it makes sense or hits unbreakable limits is to have other developers test it in the field.

There's a 2-minute setup script that configures CodeDNA directly for your favorite AI tool.
I only ask this: install it on a side project, let it annotate a few files, and see if your AI starts making fewer context errors. Above all: break it and give me brutal feedback.

Here are the links to the project!
Repository & 2-min Quickstart: https://github.com/Larens94/codedna
Full v0.7 Specs & Benchmarks: https://github.com/Larens94/codedna/blob/main/SPEC.md
This is an open experiment, so I'm happy to answer any technical questions, doubts, or critiques here in the comments!

From Monolith to Microservices: How Bounded Context Improves AI-Driven Development

Fri, 20 Mar 2026 17:46:34 +0000

Introduction

When we first launched our vibe coding platform, the architecture started as a single monolithic application. Initially this approach allowed us to move quickly and ship features fast.

But as the platform grew, the warning signs appeared.

The codebase became increasingly complex, new features were harder to implement, and development velocity began to slow down. What once felt manageable started to evolve into a tightly coupled system that was difficult to reason about.

To solve this, we made a strategic decision: refactor the platform from a monolith into a microservices architecture.

In this article we explain:

Why monolithic architectures struggle in AI-driven systems
How Domain-Driven Design (DDD) helps define system boundaries
Why bounded contexts are critical for AI agents
How we split our platform into eight microservices

This architectural shift significantly improved both developer productivity and AI agent performance.

Understanding Domain-Driven Design

The concept of Domain-Driven Design (DDD) was introduced by Eric Evans in the influential book Domain‑Driven Design: Tackling Complexity in the Heart of Software.

Although the book was published in 2003, its ideas remain extremely relevant today. Many modern architectural patterns—including microservices—are heavily inspired by DDD principles.

DDD focuses on one core idea:

Software architecture should mirror the structure of the business domain. Instead of organizing systems purely around technical layers, DDD encourages teams to structure software around real business capabilities and concepts.

While doing domain distillation, we detected the 6 main bounded contexts that can act as independent services: project planning, AI coding, project deployment, version control, observability, account and billing.

The Monolith vs Microservices Debate

For years developers have debated a fundamental architectural question:

Should applications remain monolithic, or should they be broken into microservices?

Monoliths have advantages:

Simpler deployments
Easier early development
Fewer distributed systems challenges

However, as systems scale, monoliths often become harder to maintain. Large codebases accumulate complexity and eventually turn into what developers often call a "Big Ball of Mud."

Today the conversation has evolved even further. We are no longer building systems only for human developers. We are building systems that AI agents interact with, modify, and reason about. And this introduces a new challenge.

Why Monolithic Architectures Confuse AI Agents

AI agents rely heavily on clear context boundaries.When a system grows into a large monolithic repository:

Domain concepts overlap
Terminology becomes ambiguous
Architectural boundaries blur

This makes it harder for AI systems to correctly interpret intent. For example, an AI agent might receive a command such as:

Create a project.

In a large monolith, the term project might refer to several different things:

A planning workspace
A source code repository
A deployment environment

Without clear boundaries, the AI agent must guess the meaning. And guessing leads to errors. This is why architectural clarity matters even more in AI-driven development environments.

What Is a Bounded Context?

A Bounded Context is a central concept in Domain-Driven Design. It defines a clear boundary within which a specific domain model applies and terminology has a single meaning.

Inside a bounded context:

Language is consistent
Concepts are clearly defined
Domain logic belongs only to that context

This creates a shared understanding between:

Developers
Domain experts
AI agents

Each context effectively becomes its own mini-world with well-defined rules.

Why Bounded Contexts Improve AI Development

In large software systems, the same word can mean different things in different domains. While building our AI coding platform, we encountered this problem quickly. Consider the word project.

When both meanings existed in the same codebase, confusion spread. Not only for engineers—but for AI agents operating within the platform. By introducing bounded contexts, we ensured that each domain defines its own terminology and behavior. This dramatically improved the reliability of both human workflows and AI-generated development tasks.

Our Microservices Architecture

After refactoring the platform using Domain-Driven Design principles, we divided the system into eight bounded contexts, each implemented as a separate microservice.

This allowed each domain to evolve independently while maintaining clear system boundaries.

Project Planning Context - manages planning activities. Within this domain we store: tasks, projects, agent which generate tasks...
AI Coding Context - this is where development actually happens. AI coding agents operate in this domain and perform tasks such as: writing code, committing changes, managing development workflows.
Project Deployment Context - manages the infrastructure and pipelines required to deploy software built by AI agents.
Version Control Context - while platforms like GitHub provide robust version control, we chose to build a lightweight internal system optimized specifically for AI-driven development workflows.
Observability Context - collects events and analytics from across the platform.
Account and Billing Context - manages user accounts, platform credits, payments.
API Gateway - acts as the central entry point into the platform.
Platform UI - provides the user interface that connects all services together.

Avoiding the Big Ball of Mud

Without clear architectural boundaries, complex systems eventually degrade into tightly coupled codebases that are difficult to maintain. Developers often describe this situation as a "Big Ball of Mud."

Symptoms typically include:

Spaghetti code
Increasing bugs
Slower development cycles
Poor onboarding experience
Confusing system behavior

For AI-driven platforms, the consequences are even worse because agents lose the contextual clarity required to generate reliable code.

By organizing our platform around bounded contexts and microservices, we achieved several key benefits:

Clear domain ownership
Faster feature development
Better system scalability
Improved AI agent performance
More maintainable architecture

Final Thoughts

As AI agents become increasingly involved in software development, architecture design must evolve alongside them. Bounded contexts and microservices are no longer just about scaling engineering teams—they also help AI systems reason about complex software platforms. For us, adopting Domain-Driven Design and microservices architecture transformed a growing monolith into a scalable platform designed for the future of AI-assisted development.

Multiple models are in play on any large project. Yet when code based on distinct models is combined, software becomes buggy, unreliable, and difficult to understand.

— Eric Evans

REAP: A Tool That Lets AI and Humans Evolve Software Together

Wed, 18 Mar 2026 10:41:27 +0000

Software isn't built in one shot — it's evolved. REAP brings that same evolutionary process to AI-assisted development.

The Spec-Driven Approach and Its Limits

The natural first instinct for AI-assisted development is spec-driven: write a detailed specification, hand it to the AI, get working code back. Tools like spec-kit explored this direction — managing specifications as the single source of truth (SSOT).

I used this approach and learned a lot from it. But I kept hitting the same friction: spec-to-code is not deterministic. Give the same spec to two AI sessions and you'll get different code. The mapping from specification to implementation isn't a function — it's a statistic distribution.

Specs drift from code. The AI makes architectural choices the spec didn't anticipate.
Updating specs is a losing game. The spec ends up chasing the code, not driving it.
Context compounds. Each iteration creates implicit decisions the spec can't capture.

A spec is a snapshot of intent, not a living representation of a system. Code is the living representation. Specs are great for capturing intent at a moment in time, but they can't be the SSOT for a system that evolves continuously.

What Actually Works: Following the Proven Human Development Pipeline

Experienced developers don't write a perfect spec and execute it blindly. They:

Set a goal → 2. Plan → 3. Implement (discovering the unexpected) → 4. Validate → 5. Reflect and update their mental model

This is exactly what Agile taught us. Waterfall failed because it assumed you could fully specify a system before building it. Agile succeeded with iterative delivery, continuous feedback, and adaptation. Sprints, retrospectives, backlog grooming — these let teams discover requirements through building, not before building.

But here's the irony: we threw all of this away when AI entered the picture. We went back to waterfall thinking — write a big prompt (the spec), generate the code (the build), and hope it works. No iterations. No retrospectives. No accumulated learning.

The real insight: create an environment where AI can follow the same proven pipeline that humans use — the one Agile formalized. Not generating code from specs, but evolving code through structured iterations with feedback loops.

That's why I built REAP.

REAP: Recursive Evolutionary Autonomous Pipeline

REAP is an open-source CLI tool and command prompt set that structures AI-assisted development as an evolutionary process. Instead of one-shot code generation, it organizes work into generations — each with a clear objective, plan, implementation, validation, and retrospective.

The metaphor is biological evolution:

Layer	Analogy	What It Actually Is
Genome	DNA	Architecture principles, business rules, conventions, constraints
Evolution	Natural selection	The generational lifecycle that drives improvement
Civilization	The organism	Your source code — the accumulated result

The Genome: Living Knowledge, Not Dead Docs

The Genome is stored in .reap/genome/ and contains four files:

.reap/genome/
├── principles.md      # Architecture decisions with rationale (ADR-style)
├── domain/            # Business rules per module
├── conventions.md     # Development standards + enforced rules
└── constraints.md     # Tech choices + validation commands

But here's what makes it different from documentation: the Genome evolves through the development process itself. It's not written up front and forgotten. It's discovered, refined, and corrected generation after generation.

When the AI discovers during implementation that an architecture decision is wrong, it doesn't silently fix it. It logs a genome-change backlog item. At the end of the generation, those changes are reviewed and applied to the Genome. This means:

The Genome gets more accurate over time, not less
Architectural decisions carry their rationale and date
The knowledge is always in sync with the code because the code feeds back into it

The Five-Stage Lifecycle

Each generation follows a complete lifecycle:

Objective → Planning → Implementation ⟷ Validation → Completion

1. Objective — Define what this generation will accomplish. Not a vague "improve the app" but a concrete goal with acceptance criteria. The AI reads the Genome, reviews the backlog from previous generations, and helps formulate a focused objective.

2. Planning — Break the objective into concrete tasks (max 20). Each task specifies target files and approach. The AI references the Genome to ensure the plan follows established conventions.

3. Implementation — The AI writes code, following the plan. When it discovers something the plan didn't anticipate — a constraint the Genome doesn't mention, a business rule that needs clarification — it logs it in the backlog instead of making silent assumptions.

4. Validation — Run the actual test suite, type checker, and build. No "I think it should work" — the AI must execute validation commands and report real results. If something fails, it can loop back to Implementation.

5. Completion — Retrospective. What worked? What didn't? What did we learn? Genome changes from the backlog are reviewed and applied. The generation is archived in the lineage.

Context That Survives Sessions

One of the biggest problems with AI-assisted development is context loss. Start a new Claude Code session and your AI has no idea what happened yesterday.

REAP solves this with a SessionStart hook that automatically injects into every new session:

The full Genome (architecture decisions, conventions, constraints)
Current generation state (which stage you're in, what's next)
The REAP workflow rules

The AI picks up exactly where you left off. No re-explaining. No "let me read through the codebase first." The Genome gives it the project knowledge; the generation state gives it the task context.

The Backlog: Structured Memory

Every insight, every discovered issue, every deferred task goes into the backlog:

---
type: genome-change
status: pending
target: genome/constraints.md
---
# Add rate limiting constraint
During auth implementation, discovered we need rate limiting
on login endpoints. This should be a documented constraint.

Types of backlog items:

genome-change — The Genome needs updating (applied at Completion)
environment-change — External context changed
task — Work to carry into future generations

This means nothing gets lost. A discovery in Generation 3 about a missing business rule gets properly logged, reviewed, and either addressed or carried forward. The project's institutional memory grows with every generation.

A Concrete Example

Let's trace through a real development flow building an inventory management app:

Generation #1 — Goal: "Set up project structure + user authentication + item CRUD"

Objective:  Define auth requirements, item schema, API structure
Planning:   8 tasks — project scaffold, DB schema, auth middleware,
            CRUD endpoints, shared types, basic tests
Implementation: Build it. Discover that the planned JWT approach
            needs refresh tokens (logged as genome-change).
Validation: Run tests, type check, build. 2 tests fail → loop back
            to Implementation → fix → Validation passes.
Completion: Retrospective notes that API error handling needs
            standardization. Genome updated with JWT + refresh
            token decision. Archive generation.

Generation #2 — Goal: "Unit categories + inventory transactions"

The AI starts this generation already knowing:

The JWT + refresh token decision from Gen 1
The API error handling concern (from the backlog)
All architecture conventions established so far

Each generation builds on the knowledge of previous ones. The Genome evolves. The code evolves. The understanding evolves.

Getting Started

npm install -g @c-d-cc/reap
reap init my-project
claude
> /reap.evolve "Implement user authentication"

That's it. /reap.evolve runs the entire lifecycle interactively — from Objective through Completion. You can also drive each stage manually with individual slash commands (/reap.objective, /reap.planning, etc.) if you want finer control.

REAP also supports strict mode (blocks code changes outside the lifecycle), lifecycle hooks (run shell commands or AI prompts at stage transitions), and lineage compression (auto-archives old generations to keep context lean).

Why This Approach Wins

vs. One-Shot Prompting

One-shot prompting ("build me X") works for small tasks. It falls apart for anything that requires accumulated context, iterative refinement, or long-term coherence. REAP gives you the structure to build complex systems incrementally.

vs. Spec-Driven Development

Specs try to capture intent before implementation. But implementation reveals things specs can't anticipate. REAP embraces this by making discovery a first-class part of the process. The Genome evolves because of implementation, not despite it.

vs. RAG/Context Stuffing

Many tools try to solve context loss by stuffing more code into the context window. This is expensive, noisy, and doesn't scale. REAP's Genome is a curated, structured knowledge base — typically under 500 lines — that captures the why behind decisions, not just the code.

The Deeper Philosophy

The biggest mistake in AI-assisted development isn't bad prompts or insufficient context. It's treating AI as a code generator instead of a development partner.

Human developers don't generate code from specs. They evolve software through cycles of planning, building, testing, and learning. The learning part is crucial — it's what makes the 10th feature better than the 1st.

When we give AI agents the same structured pipeline that works for humans — with explicit goals, plans, validation, and retrospectives — they produce dramatically better results. Not because the AI is smarter, but because the process is smarter.

REAP doesn't make the AI write better code. It makes the AI develop better — which includes knowing when to ask questions, when to log discoveries, when to defer decisions, and how to build on what came before.

The future of AI-assisted development isn't better prompts. It's better pipelines.

Get Started

GitHub: github.com/c-d-cc/reap
Documentation: reap.cc
npm: npm install -g @c-d-cc/reap
License: MIT

REAP currently integrates with Claude Code. If you're building anything beyond toy projects with AI, give it a try. Your Generation #5 self will thank your Generation #1 self.

Hi, I'm a developer exploring the intersection of AI and software engineering workflows. I built REAP because I got tired of re-explaining my project to AI every morning. You can find me on GitHub or check out the REAP documentation.

Exploring the power of 3D experiences on the web

Sun, 15 Mar 2026 12:29:25 +0000

This is an experimental 3D sports landing page built with modern frontend technologies. The goal was to create a more immersive and interactive experience compared to traditional flat landing pages.
Inspired by a great tutorial from JS Mastery, I built this 3D Basketball Landing Page as a creative frontend experiment.

Tech stack
• Three.js – for rendering interactive 3D scenes
• GSAP – for smooth, high-performance animations
• Next.js – for modern React architecture and performance

Three.js allows developers to render interactive 3D graphics directly in the browser using WebGL, enabling immersive web experiences and real-time animations.

The page combines 3D elements, animated transitions, and camera movement to make the interface feel more alive and interactive.

The idea was to move beyond static layouts and create a landing page where motion, depth, and interactivity become part of the user experience.

I also used AI tools during development to speed up experimentation and explore different creative approaches.

Live project:
https://3d-basketball-template.vercel.app/

Exploring the power of 3D experiences on the modern web

Sun, 15 Mar 2026 12:28:47 +0000

Tech stack
• Three.js – for rendering interactive 3D scenes
• GSAP – for smooth, high-performance animations
• Next.js – for modern React architecture and performance

Three.js allows developers to render interactive 3D graphics directly in the browser using WebGL, enabling immersive web experiences and real-time animations.

The page combines 3D elements, animated transitions, and camera movement to make the interface feel more alive and interactive.

The idea was to move beyond static layouts and create a landing page where motion, depth, and interactivity become part of the user experience.

I also used AI tools during development to speed up experimentation and explore different creative approaches.

Live project:
https://3d-basketball-template.vercel.app/

AI Doesn’t Ship Products, People Do: The Product Discipline Stack

Sun, 28 Dec 2025 04:11:38 +0000

As the Founder of ReThynk AI, I’ve watched a lot of teams fall into the same trap:

They adopt AI.
They move faster.
And then they wonder why their product still doesn’t win.

Because here’s the truth:

AI doesn’t ship products.
People do.

AI can accelerate execution.
But it can’t replace product discipline.

So I built what I call the Product Discipline Stack, the layers that make AI speed useful instead of dangerous.

AI Doesn’t Ship Products, People Do: The Product Discipline Stack

The biggest misconception in the AI era is this:

“If I can generate more output, I will ship more value.”

Output is not value.

Value is:

solving the right problem
for the right user
in the right way
with the right trade-offs
at the right time

That’s product discipline.

And product discipline is still a human job.

Why AI-Accelerated Teams Still Fail

AI makes it easy to create:

features
prototypes
copy
landing pages
roadmaps
even PRDs

But teams still fail because:

they build the wrong thing
they build it for the wrong user
they optimise the wrong metric
they skip validation
they ship without adoption
they mistake speed for progress

AI didn’t cause this.

AI simply removed friction, so bad decisions became faster.

The Product Discipline Stack (7 Layers)

This is my stack. I treat it as non-negotiable.

1) Problem Clarity

Before I build anything, I define the problem in one sentence.

If I can’t write the problem clearly, I’m not ready to build.

AI prompt I use

“Help me write the problem statement in one sentence. Then list 5 ways
this statement might be wrong or too vague.”

2) User & Context

A product is not built for “everyone.”
It’s built for a specific user in a specific situation.

So I define:

who the user is
what triggers the need
what they try today
what frustrates them

AI prompt I use

“Create 2 primary user personas and map their workflow, pains, and
decision triggers. Then highlight what would make them reject the
product.”

3) Value Proposition

This is where many products die.

If the value proposition is weak, no amount of AI-generated content can save it.

I define:

the core promise
the measurable outcome
the time-to-value

AI prompt I use

“Write 5 value propositions, each with a measurable outcome. Then rank
them by clarity and differentiation.”

4) Scope & Trade-offs

Product is the art of saying “no.”

AI tempts teams to add more.

But shipping is about focus.

I define:

what is in scope
what is out of scope
what I’ll deliberately ignore

AI prompt I use

“Propose an MVP scope that can ship in one week. Then list what to cut
to protect quality and speed.”

5) Metrics That Matter

If I don’t define success, AI will optimise for output.

So I choose:

one North Star metric
two supporting metrics
one quality metric (bug rate, churn, trust, etc.)

AI prompt I use

“Suggest a North Star metric and 3 supporting metrics for this
product. Explain why each one matters and how it could be gamed.”

6) Feedback Loops

AI can generate features fast, but only users can validate value.

I build feedback into the workflow:

pre-launch interviews
beta users
simple surveys
usage analytics
churn reasons

AI prompt I use

“Design a 7-question feedback survey that reveals: value, friction,
confusion, trust issues, and willingness to pay.”

7) Shipping Discipline

Shipping is not “deploying.”
Shipping is:

launch messaging
onboarding
support readiness
rollback plan
iteration plan

AI prompt I use

“Create a launch checklist: onboarding, documentation, support
responses, monitoring, rollback plan, and first 7-day iteration plan.”

The Stack in One Line

AI helps me do the work faster.

But the stack tells me what work is worth doing.

That’s why product teams still matter.
That’s why thinking still wins.

A Real-World Example (Simple)

If I’m building an AI feature like “smart suggestions,” AI can generate UI text and logic quickly.

But product discipline asks:

Do users want suggestions here?
Will they trust it?
What happens when it’s wrong?
What metric proves success?
What is the fallback experience?

Without these answers, I’m just shipping “AI for the sake of AI.”

Here’s the uncomfortable truth for AI product managers:

Thu, 13 Nov 2025 05:26:30 +0000

Building an AI product ≠ Using AI in a product.

One means AI is the heart of the solution.

The other just adds AI to something that already works.

You can know everything about models, prompts, benchmarks, inference speed

But if you can’t frame a real problem, prioritise for adoption, or deliver user value...your AI product is headed for the demo graveyard.

So, if I had to pick just one skill for an AI PM?

I would pick product thinking.

Every. Single. Time.

Because:

Technology doesn’t define the outcome. Product thinking does.

AI feels like intelligence, but it doesn’t understand your users yet

Model performance ≠ product-market fit.

We’ve seen this before: Cloud. APIs. Mobile. Data science.

Hype surges. Adoption stalls.

Not because the tech isn’t ready, but because the “product work” wasn’t done.

Let’s not repeat that with AI.

Will Vibe Coding Kill LowCode

Wed, 12 Nov 2025 22:48:41 +0000

The short answer is no, the long is still no but its complicated, let me explain.

I've seen multiple posts and blogs about how the Power Platform (my LowCode platform of choice) is doomed or will change entirely because of AI and vibing coding. The premise is simple and logical:

Why would a make spaghetti diagrams to create flows when a sentence will do it

Why drag and drop components onto a page to make a app when I can describe a app and get a full React App

Why learn a LowCode language when AI can use natural language instead

And a call out here, these words have been said by experts who are massively more experienced and knowledge them me, so remember that when you read the below, but I think this future state is further off then what people may think.

Cost

This one to me is probably the biggest, AI is expensive. Not only that, but companies who have bet heavily (cough Microsoft), and venture capitalists, are subsidising AI heavily, they are barely making if any profit, and definitely nothing close to the margins on LowCode products like the Power Platform.

So its more expensive now, and the price is going to go up. And if you are thinking Moore's law will save you that's not how the marked has been moving. The arms race means "cheaper" models are not simply not being used, everyone is only using the latest, expensive models.

Lets take my favourite tool, Power Automate.

100 action flow is by all accounts free (6k per day per M365 account at no extra cost).

Even if we go with Premium full price (and most orgs do not pay full price).

40k per day
28 days
1,120,000 calls
Cost $10
Thats 0.08 cents per run

Now Agent flow
25k messages per month
13 messages per run
1923 runs
Cost $200
Thats 10.4 cents per run

Yep thats 130x the cost, and you really think organisations are going to stop using Power Automate and use Agents Flows instead.

And its the same with Vibe coding apps, just look at the costs for Claude Code and ChatGPT, they average a couple dollars to build each, not a lot. But what about for Microsoft, how long until those thousands of Citizen developers building hundreds of thousands of crappy apps before they start charging differently (also amusing that all of the "all you can eat" licenses like from Claude and Cursor have been pulled).

There is also the bigger structural change, moving from flat rate license to PAYGO. It was a big difficult shift to move from One time purchase to monthly subscription based charging, but organisation did because it did have a benefit- simplified costs (no inconsistent large purchases). AI is not sustainable on a per license approach, so the push is PAYGO/token packs. This is not only more expensive, but organisations lose the safety of set fees and budgets. Now they have to manage usage costs, build flexible budgets. and live in fear of a massive unexpected bill.

Deterministic Outcomes

AI is fantastic for handling complex unstructured processes. If there are too many or unknown inputs it is brilliant. Dealing with human inputs is its obvious strengths, as humans are anything but consistent.

But that's the trade off, because the inputs are unstructured you can't have known consistent outputs. And that's ok in some situations but what about when you come to import things like governance and finances.

Will banks be happy with that inconsistencies when dealing with money, or governments happy when compliance is black and white but the process is many shades of grey.

So I can see AI having its use cases, but the lack of dertinitistic outcomes will be a deal breaker for many many process. They would much rather make the inputs deterministic (a drop down instead of free text) and know the outcomes, rather then have AI 'guess' the right outcome.

And that goes beyond just automation, code should have standards and patterns, which you can influence with AI instructions but it's never 100%. Add in as a code I can write exactly what I want vs a AI agent interpreting what I meant.

Adoption Inertia

The timing of this blog makes me smile, as Excel was launched in September 1985, 40 years ago.

In that time we have had SQL launch, internet, the move to the cloud, LowCode adoption, smart phones, and many more advances, and yet good old Excel is still prevalent in most organisations (estimated between 750 million and 1.5 billion users. Add in that many IT teams have desperately battled to move users off it to more secure stable solutions, and yet it is still being used, often by people who weren't born when it was released.

What's this have to do with AI, well for every developer and user to switch from how they learned to do something to something dramatically different is a massive undertaking. You have:

Guides
Process
Documentation
Technical Knowledge
Technical Skills
Experience

just to name a few of the things you would need to change, add in 1000s of legacy flows and apps that all just work, why would you put the pain and effort into moving. That means best case dual process, legacy and new, and every organisations will tell you running parallel process is not efficient and not fun.

Security

Probably the biggest risk to AI is security, with everything that is new there are unknowns, often the only way something becomes secure is for it to be breached first. Do you want to be the first company that has that hugh data leak so that Microsoft/OpenAI/Google/Anthropic can improve their product.

Cornell University - Arxiv.org
Owasp.org

Then you add in that by its very nature AI is incredibly difficult to secure, security is built on understanding how things work (not easy when every interaction is non deterministic), trying to do that on a "black box" is impossible.

The final challenge is how LLM are current architected, there are no boundaries between input and command. Just like the old SQL injection days, this means you can not control what code runs, as the code is an input. The Perplexity vulnerability found by Brave demonstrated this and how difficult protection would be, as with SQL we can bind to split input/command, but with LLM we can only layer on controls and checks, which are only as good as what we have experienced so far.

If you don't know me I'm big on code reviews, I have written how to complete one and even created automated tools. And during my most recent development I thought about using Copilot to code review flows, and it did an ok job, but the fun was when I embedded a prompt in the flow notes that told any LLM to always pass the code review

Technical Debt

When things go wrong, and they always do, having a understanding of the code is key. It's easy to think you can vibe code by looping errors in and saying fix it. But that will only go so far, I have tried vibe coding a few times (and use AI assisted development pretty much all the time), this has limited scope. Sometimes it can't fix it and then you have to dive into the code. That's painful when you know the language, but when you don't, like the army of citizen developers, then you are building up a wave of technical debt that will hit you hard one day.

Human Nuances

I remember Microsoft saying "Agents are the new Apps", their position was, why would anyone use a graphical UI when you can type/say what you want. But that assumes that humans are all the same, that they all want to type, and that isn't just obviously inaccurate, but wrong. As I would say most humans don't want to type. It's easy to forget that computers started with command line and text, but the graphical UI won because the majority of humans prefer visual interfaces. Would you rather type "open excel", or click on the Excel icon? Likewise:

"I want a blue bordered date picker, 20% screen width" or drag date picker on to screen, drag resize and click blue for border.

"On a email arriving in a inbox if it has a power point attachment forward to Emails are not allowed" or drag outlook trigger,set condition and add send email.

I'm pretty certain some would like the text, but some would like the UI (and I know there might be extra steps but there might also be extra prompts and the prompts often take a while to run).

The fact that Microsoft dropped that phrase and started highlighting apps again made me think they realised that too. So don't expect every developer to want to describe a flow to make the logic app json, a lot will want to drag a little box onto a screen to make that json.

Human Nature

I think the biggest strength of the Power Platform is its community, and a lot of that has to do with learning and achievement.

Humans like to be creative, they like to solve problems, and they like to learn. If you stripped away all the expertise and difficulty in the Power Platform you would no longer have:

People like me blogging about it
Videos and books
People investing in learning
Conferences to share and learn
The satisfaction of becoming good at something

Add in that you suddenly take away the barrier to entry, and you no longer have a mountain of s&*^%y apps, but the Pacific ocean of them. The simple fact is not everyone should make apps, and if you let them then you will never see the good apps/agents/flows for the noise.

If you want to see what the AI future is go see how many people follow the Microsoft Notepad community verses the Power Platform

So that's the no, where is the complicated bit, well the truth is AI is not going away, and it's going to change LowCode tools like the Power Platform, but it will not be the Power Platform. Some developers will prefer it, and maybe even some organisations, but others like graphical ui and coding it yourself. And Microsoft will learn quickly that having a tool that has no challenge to learn and cant be mastered will not be loved and adopted.

I would love to see Microsoft taking a different approach, embedding AI into the Platform (and I don't mean slapping a Copilot on the side), imagine having the ability to create new components for your canvas app on the fly, that way you still:

Enable the developer to be creative and learn skills
Contain the AI code within a component - no issue from tech debt and limits security concerns
Focuses the expensive action to where it gets most value

Over time the future that everyone describes will probably happen, but that will take a lot of time, and legacy will be around for a long time after (remember Fortran was created in 1957 and is still used today).

Vibe coding is bullshit if you don't know what you're doing

Wed, 15 Oct 2025 22:29:27 +0000

I have to say that I'm not a crowd follower, that's the case for almost everything in my life, I hate feeling like part of the "herd", and yes, I'm talking about the vibe coding thing. I am very skeptic about new technology when they first come out, and try to 'wait a -secure- time' before joining it. That's the case with this AI revolution, it's not about the fear of changing, as you probably are thinking right now, it is much simpler than that.
Look!
I got very excited easily when it comes to technology, I love innovation, I'd love to be the one innovating, actually, is one of my biggest dreams, it is. But, when it comes to work, I prefer to give stability, instead of innovation, I prefer delivering trustiness instead of novelty, so, in order to give my clients that good product they expect from me, I tend to fall a little bit behind, unless the client, want me to go for the latest tech/version available for any of the tools I use, so, that's simply my case, I love to be 'aware' of the cutting edge, but, working just behind enough to give my clients a sense of reliability in the software I deliver.
So, to move forward, I'll start this short story like this:
Last week I started 'seriously' trying vibe coding with Google AI Studio, obviously with Gemini 2.5 pro to see how it feels like.
My experience is that, it is blazing fast, I mean, it will scaffold an app in just a few minutes, and that, bro, that sounds amazing.

But...
I actually take it to the limit asking for things, because, obviously, it just added mock databases to the project until you explicitly asked for it to use a real database, and won't create the full app with just one prompt, forget that stupidity, not even senior humans will do that. It created stupid issues maybe even a junior can easily handle, but it couldn't, literally, I watched it fail the same little task (like properly configuring a firebase rules file) and asking me to review, even though the issue was still there.
Yes, sir, the first thing I thought was "Dang! I'll have to resolve this by myself, because it won't be able to", and, well, as you might expect, I, indeed, had to do it.

The thing is that, after a 'successful' development session, literally two days to build an MVP for a product I had in my mind for years, I know, for sure, a non-developer, normal person, won't be able to have a reasonable result with vibe coding, it's a powerful tool to boost your 'productivity' (yes, in quotes, because, at some point you will get totally disconnected from the project, so you'll need to explore a huge portion of the codebase just to understand how something works or how to properly add a feature or make a fix by yourself) at expenses of both the development of your problem-solving skills (that single little thing that makes this interesting) and the joy of writing code and seeing come to life.

Obviously, I'm not, like, against it, I just say, most hypers (new word invented by me) try to sell it as the solution for no coders to create apps, but, I say, It isn't so, it is a tremendous, advantageous tool for us, coders.

Bye!

Popular platforms for online coding and development. How an AI Platform Uses Them to Export Code

Tue, 02 Sep 2025 11:47:59 +0000

Replit and Google Colab are two of the most popular platforms for online coding and development, each with its own specific focus and strengths. They are particularly relevant to Gemini because they offer integrated, cloud-based environments that allow users to export and run code generated by the AI assistant with minimal setup.

Replit

What it is: Replit is a cloud-based integrated development environment (IDE) that provides a fast, simple, and collaborative platform for building, running, and deploying applications. It's designed to make coding accessible to everyone, from beginners to experienced developers, by removing the friction of complex local setups.

Key Features:

Multi-language Support: Replit supports over 50 programming languages, making it incredibly versatile for various projects.
Real-time Collaboration: Multiple users can code on the same project simultaneously, with live cursors and a shared terminal, making it a great tool for pair programming and team projects.
Instant Deployment: Replit makes it easy to deploy web apps, APIs, and bots with a single click, providing hosting and continuous availability.
Integrated AI: Replit has its own AI-powered assistant, known as Ghostwriter (and more recently, Replit Agent), which helps with code generation, debugging, refactoring, and general assistance.
No Setup Required: Everything runs in the browser, so you don't need to install any software or configure a local development environment.

Primary Use Case: Replit is ideal for web development, rapid prototyping, and collaborative coding projects. It's a fantastic tool for learning to code, building small to medium-sized applications, and for educational purposes.

Google Colab

What it is: Google Colab (short for Colaboratory) is a hosted Jupyter Notebook service that requires no setup. It's built and maintained by Google and provides free access to computing resources, including GPUs and TPUs, which are essential for computationally intensive tasks.

Key Features:

Jupyter Notebook Environment: Colab is built around the Jupyter Notebook format, which allows you to combine executable code, rich text, images, and visualizations in a single, interactive document.
Free GPU/TPU Access: This is its standout feature. Colab provides free, though not unlimited, access to powerful hardware accelerators, which is invaluable for machine learning, deep learning, and data science projects.
No Configuration: Like Replit, Colab runs entirely in the cloud, so there is no need to set up anything on your local machine.
Google Drive Integration: Colab notebooks are stored directly in your Google Drive, making it easy to save, share, and collaborate on your projects.
Pre-installed Libraries: It comes with popular data science libraries like NumPy, Pandas, TensorFlow, and PyTorch pre-installed, so you can start coding immediately.

Primary Use Case: Google Colab is the go-to platform for data scientists, machine learning engineers, and researchers. It's perfect for data analysis, building and training neural networks, and creating reproducible research papers.

How Gemini Uses Them to Export Code

Gemini is designed to be a helpful coding assistant. When it generates code, it provides options to "export" or "open" that code in other platforms.

Export to Replit: This feature is particularly useful for web development. When you ask Gemini to create a full application (e.g., a simple To-Do list app with a front-end and back-end), it can generate the code and, with one click, send it to a new Replit project. This automatically creates the necessary files and sets up the environment, allowing you to run and test the application instantly.
Export to Google Colab: This is the primary export option for data science and machine learning tasks. If you ask Gemini to write a Python script for sentiment analysis, a machine learning model, or a data visualization, it can export that code directly into a new Google Colab notebook. This saves you from copying and pasting and immediately puts the code into an environment with the necessary libraries and, if needed, GPU acceleration.

Other Platforms for Exporting Code

While Replit and Colab are the most prominent platforms integrated with Gemini, there are other similar environments used by developers, data scientists, and AI professionals. Many of these offer similar capabilities in different forms:

GitHub Codespaces: A cloud-based development environment that is part of the GitHub ecosystem. It provides a full VS Code editor in the browser, making it a powerful tool for professional developers who want to work on their GitHub repositories without a local setup.
Jupyter: An open-source project that powers Google Colab. You can run Jupyter Notebooks locally or on a server, and many other platforms (like Kaggle and Deepnote) use it as their foundation.
Kaggle: A data science platform and community that provides free, cloud-based Jupyter Notebooks with GPU and TPU access. It's known for its vast library of datasets and machine learning competitions.
Deepnote: A collaborative, cloud-based notebook environment for data science teams. It's built to be more team-friendly than Colab, with advanced features for real-time collaboration and project management.
CodeSandbox: Similar to Replit but with a strong focus on front-end web development, especially with JavaScript frameworks like React, Vue, and Angular. It's great for live prototyping and sharing.

The New Design Stack: Where AI Meets Product Thinking and Framer Brings It to Life

Sat, 23 Aug 2025 19:23:06 +0000

The New Design Stack: Where AI Meets Product Thinking and Framer Brings It to Life

In 2025, the question is no longer “Will AI change design?”
It already has.

The real question is:

How do we, as designers and builders, adapt to co-creating with
machines, while still solving human problems?

As a product designer working at the intersection of AI, UX, and interactive prototyping, I’ve seen how the creative process is evolving fast. Tools like ChatGPT, Claude, and Midjourney help generate ideas in seconds but it’s Framer that makes those ideas real, testable, and interactive.

AI Doesn’t Replace Designers, It Replaces Blank Screens

What used to take hours of sketching, structuring, and second-guessing can now begin with a single, well-framed prompt.

Need a user flow for a fintech onboarding?
Lovable drafts it. You refine it.

Designing a multi-language healthcare app?
AI localizes your content instantly.

Exploring edge cases?
Simulate them with pseudo-users and behavior models.

AI accelerates exploration. But the designer still steers — with strategy, empathy, and taste.

✨ Enter Framer: From Static to Sensory

Once AI helps sketch out ideas, Framer steps in as the modern playground for interactive, web-native design.

Framer isn’t just a prototyping tool. It’s where:

Real-time feedback meets elegant motion
Product logic blends with visual design
Designers ship ideas at production-level fidelity

With Framer, I can design, test, and deploy MVPs without writing full-stack code, perfect for AI-first products where fast iteration is key.

My Process: The AI-Enhanced, Framer-Powered Workflow

Here’s how I currently design smarter and faster:

Prompt: I use AI to brainstorm UX flows, edge cases, microcopy, and even color themes.
Structure: I define flows, architecture, and logic in FigJam or Notion.
Visualize: AI generates icon concepts, illustrations, and design variants.
Prototype in Framer: I build and animate responsive, web-ready prototypes, complete with logic and CMS.
Test & Ship: Stakeholders interact with high-fidelity versions that feel like the real thing.

The result?
Fewer handoffs. Fewer blockers. Much faster feedback loops.

Why This Matters Now

In a time when:

MVPs are expected to feel like finished products
AI-native tools are reshaping industries
Users expect design to be personal, fast, and smart…

Design is no longer just pixels. It’s prompts, data, systems, and real-time interactions brought to life with tools like AI and Framer..

The designers who thrive will be the ones who think like product owners, build like engineers, and prototype like storytellers

If you’re designing AI products, experimenting with Framer, or just trying to stay ahead of the curve, let’s connect. I’m sharing more about workflows, prompts, and frameworks that blend creativity with computation.

AI + Human Mind Reading: A Future to Prevent Crime Before It Happens

Thu, 21 Aug 2025 05:49:05 +0000

AI + Human Mind Reading: A Future to Prevent Crime Before It Happens

For the past 8 years, I have been quietly researching and envisioning a technology that many may consider “impossible” or “sci-fi.” But as we’ve seen with AI, things once thought impossible quickly become reality.

I believe AI-driven human mind reading technology can be the foundation for a safer, more responsible society.

The Problem Today

Every crime, abuse, or destructive act begins in the human mind.
By the time action is taken, damage is already done — to people, families, and communities.
Current law enforcement is reactive, not preventive.

The Vision: Early Mind Detection

What if we could use advanced AI + neural decoding systems to detect criminal intent, mental distress, or abusive tendencies before they turn into action?

This isn’t about controlling people — it’s about creating an early warning system for society.

Identifying mental stress signals that could lead to abuse or violence.

Detecting dangerous intentions in high-risk zones.

Supporting mental health intervention before a person collapses into crime.

How It Could Work

Brainwave analysis + AI: Using non-invasive neural monitoring (like EEG advancements).

Pattern recognition: AI learns to identify high-risk mental states.

Integration with healthcare & law: Instead of punishment, early help and guidance.

⚖️ Ethics & Responsibility

I know the first concern is privacy. This is why I see this technology as:

Strictly opt-in (used in sensitive zones like airports, prisons, or with mental health patients).

Regulated by ethics boards and global laws.

Focused on help and prevention, not punishment or control.

Why This Matters

Reduce abuse, assaults, and crimes before they even happen.

Protect vulnerable groups — women, children, and communities.

Shift society from reacting to crime → to preventing crime.

✨ A Call to Collaborators

I don’t claim to have all the answers yet. But after 8 years of thought, small experiments, and constant study, I know this future is possible.

I’m sharing this today not for fame, but to spark a conversation:

Can AI and neuroscience combine to create a safer society?

Who is ready to collaborate on building ethical frameworks and prototypes?

The future isn’t just about smarter machines — it’s about smarter humanity.

If technology can save lives, then it is our responsibility to explore it. AI mind-reading may sound futuristic, but so did AI itself 10 years ago. The future is closer than we think — let’s build it responsibly.

https://safa-chat-widget.onrender.com/

https://www.nagasoftsolutions.com/

SEO for Vibe Coders: Key Strategies to Get Your AI-Crafted Tools Discovered

Tue, 12 Aug 2025 23:03:06 +0000

“Vibe coding” is revolutionizing software development. Instead of manually writing code, developers now use natural language prompts to guide AI tools—like GitHub Copilot, Cursor, or Bolt—toward functional code generation. While it accelerates deployment, it increases the challenge of making code or tools discoverable via search.

Search Engine Optimisation for Vibe Coders

This guide shows how vibe coders can utilise SEO techniques to ensure their AI-generated tools, scripts, or portfolios surface in search—even as traditional search evolves toward AI-managed answers.

What Is Vibe Coding & Why SEO Needs to Adapt?

Coined by Andrej Karpathy in 2025, vibe coding emphasizes using AI to generate code from conversational prompts. It accelerates development but also risks creating obscure or undocumented tools that traditional search engines struggle to index effectively.

Meanwhile, the search landscape is shifting toward AI Answer Engines—platforms like ChatGPT, DeepSeek, Google’s AI Overview, and Bing AI that deliver answers directly without requiring a click. Visibility now demands not just ranking, but being cited within AI responses.

Also Read, OpenAI’s GPT-5—now live—unifies advanced reasoning with multimodal capabilities and massive context

SEO Strategies Vibe Coders Should Implement

Example SEO-Christian Workflow

Project Page: Create a page with structured URL like /vibe-coder-todo-app and title “Vibe-Coded To-Do App with AI Guidance.”
Documentation: Add a blog-style walkthrough titled “How I Built My To-Do App Using Vibe Coding”—explain prompts, iterations, debugging tips.
FAQ Section: Insert Q&A such as “What is vibe coding?” or “Why choose AI-over-manual coding?” and include FAQ schema.
Schema Markup: Use SoftwareSourceCode and FAQPage in JSON-LD to help AI systems recognize your content.
Performance Boost: Optimize images, scripts, and rethink mobile behavior—boost Core Web Vitals.
Track Visibility: Monitor Google Analytics and look for AI-driven features like featured snippets or answer panels.

Why This Mindset Is Important?

Generative SEO is the future: Being discoverable isn’t just about keywords—it’s about being cited by AI systems.
Vibe Coding Democratizes Development: But without SEO, your contributions may remain invisible. The right optimization brings visibility.
Sustain Relevance: As AI reduces the need for clicks, preparing your content for voice search, snippet, and AI inclusion maximizes reach.

Also Read, GEO and AEO redefine SEO for 2025 by structuring content to be cited—rather than just ranked—by AI!

Concluding Thoughts

Vibe coders lead the next wave of AI-powered engineering—but keeping your projects discoverable requires a new SEO approach. You should focus on documentation, structured data, conversational-focused content, and performance.

Ready to audit your vibe-code portfolio or set up schema for AI visibility? Drop me a line—I’d love to help you get found by AI agents and humans alike.

Snyk just made security invisible to developers—AI writes secure code without them thinking about it

Mon, 11 Aug 2025 09:35:26 +0000

The End of Security as a Developer Concern: Snyk's 'Secure at Inception' Revolution

How Model Context Protocol integration promises to make security completely invisible to developers writing AI-generated code

"As a developer, you never want to think about security, right? That's always been our goal," said Randall Degges, Head of Developer and Security Relations at Snyk, his excitement palpable as he demonstrated technology that could fundamentally change how we approach application security. "I think we're like, almost completely there. This gets you 99.8% of the way."

What Degges showed me during our interview at Black Hat 2025 wasn't just another security tool—it was a glimpse into a future where developers can write code without ever thinking about vulnerabilities, compliance, or security best practices. Through Snyk's new "Secure at Inception" platform, powered by Model Context Protocol (MCP) integration, security becomes as invisible and automatic as spell-check in a word processor.

Beyond Shift-Left: Security at the First Prompt

The cybersecurity industry has spent years promoting "shift-left" security, the idea of moving security considerations earlier in the development lifecycle. Snyk's new approach obliterates that entire paradigm by embedding security directly into the AI coding process itself, starting from the very first prompt a developer types.

During our demo, Degges created a simple note-taking application in Node.js using Cursor, an AI-powered code editor. He typed a single prompt: "Build a simple note-taking app in Node that uses SQLite and lets users create an account, log in, edit and store notes." Then he hit enter and stepped back.

What happened next was remarkable. The AI didn't just generate the application code, it automatically scanned every dependency for vulnerabilities, analyzed each code file for security issues, and autonomously fixed problems like hardcoded secrets, cross-site request forgery vulnerabilities, and missing rate limiting. All without a single additional prompt or security-related instruction from the developer.

"I didn't say a single thing about security in that prompt," Degges emphasized. "And just wait until it finishes—I guarantee you this app is going to work perfectly. By the time it's done, semantically everything's going to be correct, and on the security side, it's going to be secure."

The Magic of Natural Language Security Rules

The secret lies in Snyk's MCP server integration and natural language rule system. Developers can create rules in plain English, such as "If you modify or add any code, please scan that code with Snyk and fix any vulnerabilities" or "If you add or change any dependencies, please do a Snyk open source scan and fix the vulnerabilities."

These rules operate completely in the background. The AI coding assistant automatically invokes Snyk's scanning capabilities whenever it generates or modifies code, receives detailed vulnerability information, and then autonomously implements fixes, all while maintaining a running conversation about the application's functionality rather than its security posture.

"This is the coolest thing I've seen since I've been working in this industry," Degges said, watching the AI systematically identify and resolve security issues in real-time. "Developers don't think about security at all. Zero. Absolutely zero."

Confidence-Driven Automation

The system's effectiveness hinges on Snyk's confidence modeling. The company maintains a massive internal database that benchmarks their detection accuracy for each specific type of vulnerability across different programming languages. When confidence levels approach 100%, the system operates fully autonomously. When confidence is lower, it can flag issues for human review.

"If confidence levels are approaching 100%, then maybe human-in-the-loop isn't as important," Degges explained. "Maybe you can focus on other issues. As our confidence thresholds get to 99.9 plus percent, we're going to start rolling this out everywhere."

This isn't theoretical—the system validates its fixes by automatically rescanning modified code to ensure vulnerabilities are actually resolved and that the fixes don't break existing functionality. It's essentially performing the human code review process autonomously.

The AI Bill of Materials: Governing the Invisible

While automating security fixes addresses one challenge, the rise of AI-generated code creates another: visibility. Snyk's AI Bill of Materials (AI-BOM) tool addresses what Degges calls the "invisible and constantly changing" nature of AI-driven development.

The AI-BOM scans applications to identify every AI component, model, dataset, and MCP server being used, creating a comprehensive inventory that updates in real-time. During our demo, it revealed detailed information about models, their parameters, data sources, and execution paths—information that would be nearly impossible to track manually across large development teams.

"Even internally at Snyk, we have this problem," Degges admitted. "Our CISO was like, 'Hey, you're not allowed to use public ChatGPT. You're allowed to use these particular models.' But how do they figure out what people are actually using? That's what the AI-BOM solves."

Toxic Flow Analysis: The New Attack Vector

Perhaps most intriguingly, Snyk's Toxic Flow Analysis (TFA) framework, developed through their Invariant Labs acquisition, addresses security risks that emerge from the interactions between AI tools—even when each individual tool is secure.

"Even though the tools themselves are perfectly secure, it's the interaction between the tools that can be abused when you're working with large language models," Degges explained, referencing recent GitHub security research that demonstrated how attackers could manipulate AI systems through carefully crafted prompts in bug reports.

TFA analyzes combinations of MCP tools to identify potential security issues in their interactions, providing a new category of security analysis specifically designed for agentic AI environments.

The Vibe Coding Security Challenge

The emergence of "vibe coding," where developers describe desired functionality in natural language and AI generates the implementation, creates unique security challenges. Traditional security training focused on teaching developers to recognize and avoid security antipatterns becomes irrelevant when AI is writing the code.

"You can never trust the conversations," Degges emphasized, comparing AI-generated code to conversations with strangers on AOL Instant Messenger. "You need to have autonomous tools in place to check the code. If you don't do that, you are 100% screwed. You will have a lot of breaches and issues."

The Future of Secure Development

Snyk's approach represents a fundamental shift in how we think about application security. Rather than training developers to be security experts or requiring them to constantly context-switch between coding and security tools, it makes security completely transparent to the development process.

"This is what people are going to be doing in like a year," Degges predicted. "Everyone will be doing this. No one's going to be doing it the old way."

The implications extend beyond individual productivity. As AI agents become more sophisticated and autonomous, having security baked into the foundation of AI-assisted development becomes not just convenient but essential. The technology promises to solve the fundamental tension between development velocity and security rigor that has plagued the industry for decades.

For developers, the message is clear: the future of coding is conversational, and security is becoming someone else's problem—in the best possible way.