Your AI just passed every test. 100% coverage. Green checkmarks across the board. And it's all fake. CIO published a piece this week that names the problem nobody wants to talk about. They call it 'cardboard muffins': AI-generated code that hardcodes return values just to satisfy assertions. The tests pass. The pipeline is green. The business logic? Completely untested. This is the actual state of vibe coding in production right now. But the article goes further. It proposes something every engineering org needs to consider: a dual-track strategy. Track 1 (fast): Let people vibe code. Encourage it. Let PMs scaffold prototypes in an afternoon. But everything stays sandboxed. Disposable blueprints. Never touches production data. Track 2 (slow): When a prototype proves value, you start over. Not refactor. Not clean up. Rewrite from scratch with real engineers, strict type safety, and verified dependencies. The key insight? Never base the timeline of Track 2 on the velocity of Track 1. The article also coins 'slopsquatting' where AI hallucinates package names that attackers register with malware. Your coding agent installs it. No warnings. Root access handed to a cybercriminal. The new luxury in software development isn't speed. It's old-fashioned, boring determinism. #VibeCoding #SpecDrivenDevelopment #SoftwareEngineering #AIinSDLC #DevSecOps
PremKumar Duraisamy’s Post
More Relevant Posts
-
Start-ups are shipping faster than ever 🚀 But speed without validation = hidden risk ⚠️ AI-generated code may look correct… but underneath it can carry: 🔍 Logic gaps 🔐 Security vulnerabilities 💥 Edge-case failures The real issue? 👨💻 Developers focus on building ❌ Not breaking their own systems So problems show up only when: 👥 Real users interact 📈 Systems scale ⚡ Edge cases hit At 4emet 🧪 We don’t trust assumptions. We: 🧪 Test like real users 🔧 Break systems intentionally ✅ Validate AI + human code Before it reaches production. Instead of reacting later: 🚫 Avoid user complaints 🛡️ Protect your product 📊 Safeguard revenue In the AI era ⚡ It’s not just about building fast… 👉 It’s about shipping with confidence. 🚀 #AICodeRisk #SaaSGrowth #StartupLife #TestStrategy
To view or add a comment, sign in
-
You’re not just responsible for the code you write. You’re responsible for the code you accept. AI is writing more of your code - and it’s quietly increasing your risk. The recent Axios (v1.14.1 containing a Remote Access Trojan) exploit didn’t spread because engineers suddenly got worse. It spread because too many teams are operating without a defined process for what gets pulled into their systems. This is what “vibe coding” looks like in practice. A dependency gets upgraded - sometimes by a developer, sometimes suggested by a model. It’s the latest version. It installs cleanly. Nothing breaks immediately. So it ships. Sensitive systems don’t get exposed through complex attacks alone. They get exposed through small, unreviewed decisions that accumulate over time. The shift to agentic development has made this easier to miss. When you’re assembling code instead of writing it, decisions are happening faster - and often implicitly: - “Latest” becomes the default - Version history isn’t questioned - Security validation gets skipped Not because teams don’t care. Because the process isn’t there. Without that process, it doesn’t matter whether the suggestion came from a person or an AI. The outcome is the same. The teams that avoid this aren’t guessing. They’re deliberate: - Dependencies are pinned and justified - New versions are treated with skepticism, not assumption - Supply chain risk is continuously monitored, not periodically checked There’s nothing slow about that. It’s controlled. If your development lifecycle is becoming agentic, then your security model has to become just as intentional. You need a system that defines: - What gets introduced - How it’s evaluated - When it’s allowed to move forward Otherwise, you’re not really engineering your product - you’re curating it without oversight. This isn’t an argument against AI. It’s an argument against operating without discipline in an environment where decisions are happening faster than ever. What looks like speed on the surface is often just unreviewed risk underneath. And that doesn’t fail loudly. It fails later, when it matters. #agents #security #ai
To view or add a comment, sign in
-
🚀 Interesting Stuff — Week 14, 2026: Leaked Models, Harness Playbooks, and Agent Frameworks Going 1.0 A wild week in AI; from accidental leaks of Anthropic's most powerful model to production-ready agent frameworks shipping their 1.0. Here's the roundup: 🎓 Claude Skills & Cowork 101: Devi walks beginners through Claude Skills and Cowork Projects with a fun One Piece-themed demo. Two skills, two prompts, two polished outputs: the clearest on-ramp to Claude's skill system I've seen. ⚡ Claude Mythos Leaked: A CMS misconfiguration exposed Anthropic's draft announcement for Mythos, described as "a step change" above Opus with unprecedented cybersecurity capabilities. CrowdStrike dropped 7%. The question on everyone's mind: accident or strategic theatre? 🏗️ Anthropic's Harness Engineering Playbook: Joe Njenga distils Anthropic's two research papers into actionable guidance. The killer stat: same model, same prompt, but a three-agent harness produced a working 16-feature app where the solo agent produced a broken shell. The bottleneck isn't model capability: it's environment engineering. 🖥️ Claude Code Gets Computer Use: Anthropic ships screen control from the CLI. Claude can now open apps, click, type, and take screenshots on macOS with per-app approval, sentinel warnings, and a global escape key. Native app developers, take note. 🔧 Microsoft Agent Framework 1.0: A major architectural rethink: Foundry becomes the control plane, your app becomes the runtime consumer. Provider code extracted from core, unified model config, and a clean new naming convention. 📖 Read the full roundup here 👇 👉 https://lnkd.in/d8aVYPw5 #GenerativeAI #ClaudeCode #Anthropic #ClaudeMythos #HarnessEngineering #AIAgents #Microsoft #AzureAIFoundry #ComputerUse #DevTools #mvpbuzz
To view or add a comment, sign in
-
A recent article caught my attention: Anthropic built an AI model that can identify and exploit zero-day vulnerabilities across major operating systems and browsers—and they chose not to release it publicly because of the risk. That’s a pretty big shift. For years, we’ve treated AI as a productivity multiplier for developers. Now we’re entering a phase where it can also act as an autonomous attacker. What stood out to me isn’t just the capability—it’s the implication: We’re moving from a world where: 👉 Security is reactive (patch after discovery) To one where: 👉 Discovery and exploitation can happen at machine speed Which changes the game entirely. At scale, I’ve seen the real bottleneck isn’t finding problems—it’s fixing them fast enough. And that’s not just a technical problem. That’s ownership, prioritization, and org design. Curious how others are thinking about this—especially around: - shifting left on security - ownership of vulnerabilities across teams - and whether current SDLC practices can keep up with AI-driven discovery Feels like we’re going to need a different playbook.
To view or add a comment, sign in
-
Prediction: within 2 years, continuous AI-driven pentesting will be standard practice at every company shipping software. Here's why. Coding used to be the bottleneck. Then code reviews. Now, with AI writing and reviewing code faster than ever, the next bottleneck is security incidents. Teams are shipping faster than their security programs can keep up. Weekly deploys. Daily deploys. Sometimes multiple times a day. But pentests still happen quarterly — if you're lucky. That gap is where breaches live. The shift will look like this: → Pentesting becomes a background process, not a project. Like CI/CD but for security. → Findings get triaged and patched in the same cycle they're discovered, not months later. → Security teams move from reactive firefighting to proactive hardening. → Context-aware AI agents replace generic scanners. They understand your app's auth flows, business logic, and architecture. This isn't speculative. We're already seeing it at MindFort. Teams scheduling daily Turbo assessments alongside their deploy pipeline. Running Deep assessments weekly. Treating security testing like they treat their test suite — continuous and automated. The companies that figure this out first will have a real edge. Not just fewer breaches. Faster shipping, because security stops being the thing that slows you down.
To view or add a comment, sign in
-
This may be less about one person making a mistake and more about a new class of mistake: AI-accelerated software delivery creating failures that humans no longer fully track in real time. That is not an argument against AI-assisted development. It is simply the reality of acceleration. We should expect more incidents like this, and likely at a greater scale, until engineering practices, governance, and operational procedures catch up with the speed these tools enable. For now, step by step, people. Great profit comes with great risk, so make sure you manage it.
To view or add a comment, sign in
-
The AI Coding Revolution: Are You Racing Toward Innovation or Vulnerability? The era of manual coding is shifting. With industry leaders predicting near-full automation of software development within a year, we are entering a phase where code is no longer a slow, manual process, but an industrial output generated at scale by AI. While the world focuses on the massive leap in productivity, a critical question remains: Who will control the security and reliability of this flood of automated code? In a recent featured article on Geektime, our Head of R&D, Oz Moyal, breaks down the hidden risks of the automation revolution and why traditional security must evolve. Key Insights from the Article: · The Scale of Risk: When production speed increases tenfold, so does the exposure to vulnerabilities. With 40% of developers already integrating AI-generated code, the risk of misconfigurations and security gaps is real. · Structural Weakness: Overreliance on the same AI models and prompts can create "structural uniformity" - if an attacker understands the pattern, they can exploit it across the entire organization. · The Accountability Gap: When AI-generated code causes a breach, who is responsible? Organizations must proactively set standards for AI governance and deep-dive inspections. The Bottom Line: The future doesn’t belong to those who try to stop automation, but to those who master its control. The race is no longer just about speed - it’s about resilience and trust. At Armory Defense, we believe security must be embedded at the source, not added at the end. If AI is your production engine, it must also be your primary object of control. Read the full deep dive on Geektime here (https://lnkd.in/eDwqJznd) #AI #CyberSecurity #SoftwareDevelopment #Automation #ArmoryDefense #TechLeadership #AppSec #Innovation
To view or add a comment, sign in
-
-
We’re all rushing to build and integrate autonomous agents right now. But as software engineers, we're quickly realizing that giving these tools the keys to the castle without any security in place is a recipe for disaster. So, last week I was deep in a coding session with Claude, and it casually decided to flush my entire local database without permission. 🙃 Lesson learned the hard way: giving AI agents autonomy is amazing for productivity, but terrifying for system stability if you don't have strict guardrails. That’s exactly why the new Agent Governance Toolkit is probably the most important thing I've looked at this week. It shifts the conversation from just "getting the AI to do stuff" to actually putting a leash on it. Instead of crossing your fingers and relying on prompt engineering to keep the AI in line, this toolkit provides actual runtime security. It intercepts an agent's action before it executes something catastrophic (like, say, wiping a dev database). If you're designing systems right now, we have to start treating agent sandboxing, permission management, and deterministic policies as core architecture components, not just afterthoughts. Anyone else had a rogue AI moment recently? Let me know I'm not the only one. 👇 #SoftwareEngineering #AI #SystemDesign #AgenticAI #CyberSecurity #DeveloperLife
To view or add a comment, sign in
-
-
Your developers are shipping AI-generated code faster than ever. 📈 Very positive But can you answer these questions: 🍫 Was every AI-generated line reviewed before production? 🍫 Who approved it? 🍫 Which vulnerabilities were flagged and which were missed? Most enterprises can't. Because AI coding tools live on the developer's laptop. Governance and security live in your repositories. These two worlds aren't talking. The result? Code review times: ↗️ Pipeline failures: ↗️. Security backlog: ↗️ 💣💣 More code, faster ≠ better code, faster. The missing piece An orchestration layer that brings AI agents repo-side where every action is traceable, every policy enforced, every change auditable. I am curious : How are you enforcing your security and compliance standards on that code before it reaches production? #DevSecOps #agenticAI #AIorchestration #DuoAgentPlatform
To view or add a comment, sign in
-
-
Oh shit. I'd been moving fast. My goal was to mass-produce a framework of security scripts with as few prompts as possible. Minimal back and forth, maximum output. So when I finally stopped and actually read one of the templates we'd built together… no remediation. Anywhere. Just verification. Pass, fail, error. Clean little scripts that would dutifully tell you everything that was broken — and then politely leave you to deal with it. The same thing Wazuh was already doing. Right there on the dashboard. For free. Here's what happened. I'd been building this thing manually in one thread, switched to a new one to scale it up, and handed off the context with something along the lines of "take what we're doing here and bring it to the new thread." Confident. Breezy. Tragically vague. The handoff was relying far too heavily on memory and recall — which, if you work with these tools, you already know is a you problem, not a them problem. GPT didn't fail me. My instructions did. The good news? I caught it before it was truly catastrophic, rolled with it, and ended up building something better — a full validation and remediation framework that detects the issue, tracks it, and actually fixes it. The real takeaway wasn't about the scripts. It was the same lesson I keep relearning: when something goes wrong, the first question shouldn't be "why did this fail" — it should be "what did I do that contributed to it, and how do I not do that again?" That's what brought me to where I am today. Not avoiding mistakes, but actually sitting with them long enough to learn something. And yes — I used AI to help write this post about a mistake I made using AI. The irony is very much intentional. #SecurityAutomation #InfoSec #Wazuh #PowerShell #SecurityEngineerin
To view or add a comment, sign in
Zargo•1K followers
4dthe dual, track thing only works if you actually kill Track 1 code when it wins. most orgs patch the cardboard muffin instead of rewriting it, and suddenly production logic runs on hallucinated dependencies nobody fully understands. the speed advantage dies the moment you're maintaining something never built to last.