Connect with us:
Type something to search...
to navigateto selectESC to close

AI coding

Engineering
From DevSecOps to Agentic DevSecOps
By Lumia Labs/ On 01 Mar, 2026

From DevSecOps to Agentic DevSecOps

DevSecOps was built on a simple premise: integrate security into the way humans build software. But "everyone" now includes AI agents. They write code and merge pull requests. Your security model is still designed for humans. Redesigning security for agents is what we call Agentic DevSecOps. It changes how we think about identity, access control, verification, and accountability. DevSecOps assumed humans in the loop The whole point of DevSecOps was to make everyone own security by shifting security left and building it into development, so vulnerabilities got caught before they reached production. All of that assumed a human developer writing the code, understanding the intent, reviewing scan results, and making judgement calls about risk. The developers can use tooling like static analysis to flag potential issues but ultimately a human evaluates whether the flag is a false positive or a threat. A reviewer reads the diff and considers the broader implications. Sonar's 2025 survey found 42% of production code already involves AI, and that number is climbing. Once agents start opening PRs and merging their own code, none of these assumptions hold. What makes Agentic DevSecOps different Agentic DevSecOps means redesigning security for a world where AI agents write and ship your code. Who is the agent, and what can it do? In traditional DevSecOps, access controls are tied to human identities. When an AI agent opens a PR, whose permissions does it use? What should it be allowed to do? In our experience, most organizations run agents under a developer's personal credentials, which means the agent inherits permissions that were calibrated for a human's judgement, not an AI's. AI agents also pick their own dependencies. Veracode's research found 45% of AI-generated code contains vulnerabilities. An agent can introduce a dependency that's technically clean but architecturally wrong, or generate code that mimics a vulnerable pattern without triggering signature-based detection. Speed breaks the verification model AI agents can generate and ship code ten to a hundred times faster than humans. A 15-minute security scan works fine when developers push a few times a day. When agents push dozens of changes per hour, that scan becomes either a bottleneck that defeats the purpose of using agents, or gets bypassed "temporarily". Agents leave plenty of trail in commit messages and PR descriptions. But by the time a broken change surfaces in production, the agent has pushed dozens more commits on top of it. Finding the offending commits can be a big challenge, even when using agents. AI agents fail differently than humans The threat model for AI-generated code is different. Humans make predictable mistakes: forgotten input validation, copy-pasted insecure patterns, hardcoded credentials, shortcuts under pressure. A reviewer can spot these. AI agents generate code that looks correct, passes basic checks, and is subtly wrong. The code reads well, it just doesn't do what you think it does. New attack vectors are already showing up in agentic workflows: Prompt injection through code context An attacker embeds malicious instructions in a codebase comment or issue description. The AI agent reads that context, follows the instructions, and introduces a backdoor that looks like a legitimate code change. Researchers have already demonstrated that LLMs can be manipulated through their input context. An AI agent asked to add a feature might pull in a dependency that doesn't exist yet. If an attacker registers that package name first, the agent helpfully installs the malicious package. Agents that modify lockfiles as part of their workflow bypass these protections. Zero human eyes An AI agent writes the code, another reviews it, an automated pipeline deploys it. Nobody planned for a fully automated path to production, but the steps chain together into one. AI agents need API keys and service credentials to do their work. An agent that logs its full context, or that includes secrets in a commit message or PR description, can expose credentials in places your secret scanning doesn't cover. The more autonomous the agent, the more credentials it touches. Improving security Give agents their own identity Create dedicated service identities for AI agents with scoped permissions. An agent that writes code shouldn't be able to merge it. An agent that runs tests shouldn't be able to modify the test configuration. In practice, we still find most agents running under a senior dev's personal token with full repo access. Treat them like any other service account: minimal permissions and audited access. Layer your verification A single security scan isn't enough. Stack static analysis, semantic analysis, behavioral testing, and anomaly detection on the diff patterns themselves. AI-generated code has detectable patterns, use that to improve verification. Slow agents down on purpose Put limits on how fast agents can push changes, and build circuit breakers that pause activity when anomalies appear: unusual dependency additions or changes to security-sensitive files. Track provenance The EU AI Act's transparency obligations already cover AI-generated code in regulated industries, and enforcement is coming. Every change should trace back to who (or what) wrote it, what prompted it, what context the agent had, and what review it received. Build the audit trail now. Enforce human review where it matters Not every change needs a human reviewer. But changes to authentication, authorization, payment processing, data handling, and infrastructure do. Define your high-risk zones and hold that line, even when it slows things down. The organizational shift Agentic DevSecOps is an organizational problem as much as a technical one. Security teams need to understand how agents fail. Dev teams should treat agents like a new hire: set guardrails, supervise the output. Platform infrastructure has to account for non-human participants in the pipeline. Organizations that get this right can deploy agents aggressively because they've built the controls to match. The alternative is bolting agents onto pipelines designed for humans and patching gaps after each incident.Lumia Labs helps organizations build secure engineering practices for AI-augmented teams. If you're deploying AI agents in your development pipeline and want to get security right, we'd like to hear from you.

Engineering
AI Might Be Making Your Team Worse
By Lumia Labs/ On 30 Jan, 2026

AI Might Be Making Your Team Worse

We've started to see reduced learning in AI-assisted development. A developer finishes a feature in half the usual time. The code works, the PR gets merged, everyone's happy. Except that same developer can't debug the same code without AI help. They shipped the code, but they didn't learn anything. They're fully relying on AI to help them. This week we came across research that puts data behind what we've been observing. Anthropic published a study called "How AI Impacts Skill Formation" that provides evidence for something engineering leaders have been quietly worrying about: AI coding tools can impair programming skill development. Anthropic's research Researchers ran a controlled experiment with developers learning Python Trio, an asynchronous programming library. They chose Trio specifically because it requires understanding new concepts like structured concurrency, not just Python syntax. Half the participants had access to AI assistance, half didn't. The results were pretty interesting: the AI group scored 17% lower on knowledge assessments, a 4.15-point gap on a 27-point quiz with a substantial effect size (Cohen's d = 0.738). Debugging questions showed the largest difference between groups, the skill that matters most when something breaks in production. The AI group encountered far fewer errors during the learning process. The median AI-assisted participant hit 1 error compared to 3 for the control group. On the surface that sounds like a benefit, but errors are how developers learn. RuntimeWarnings, TypeErrors, the frustration of debugging: these moments force you to understand how code works. The AI removed the struggle, and with it, the learning. AI usage patterns One of the more useful parts of the research was identifying six distinct patterns in how developers use AI, with dramatically different learning outcomes. Three patterns correlated with poor learning (quiz scores between 24-39%):AI Delegation: Handing everything to AI for code generation Progressive AI Reliance: Starting by asking questions but gradually delegating all the actual coding Iterative AI Debugging: Using AI to fix bugs without trying to understand why they happenedThree patterns preserved learning even with AI assistance (quiz scores between 65-86%):Generation-Then-Comprehension: Generating code but then asking follow-up questions to understand it Hybrid Code-Explanation: Requesting both code and explanations together Conceptual Inquiry: Only asking conceptual questions, then writing the code yourselfWhat is interesting to us is that developers learn when they are mentally engaged with the problem. The high-scoring patterns all have something in common: the developer kept thinking. They used AI to help them understand rather than to avoid understanding. Implications The first is what happens to your senior engineer pipeline. Junior developers traditionally build expertise through struggle: debugging, making mistakes, developing intuition for why things fail. If AI shortcuts this process for an entire generation of engineers, organizations may find themselves with fewer people capable of growing into senior technical roles. Another effect is the lack of in-depth knowledge about frameworks and programming languages that developers work with. When AI becomes the default way to learn new technologies, teams can accumulate technical dependencies without building the deep understanding needed to maintain and evolve those systems. We've seen this already with teams that adopted frameworks quickly using AI assistance but now struggle to debug issues or make architectural changes because nobody truly learned the underlying technology. This matters especially in safety-critical domains. Security, infrastructure, financial systems all require people who can review code, not just accept what AI generates. You can't effectively review code for a library you've never really learned yourself. The human oversight that makes AI-assisted development safe depends on humans who understand what they're overseeing. We've written before about research showing experienced developers were 19% slower when using AI on real-world tasks. When you add reduced debugging ability to that picture, the long-term productivity costs start looking more significant than the short-term speed gains. What we think organizations should do The research isn't an argument against AI coding tools. We use them ourselves (a lot!). It's an argument for being intentional about how they're used, especially when learning is part of the goal. Make understanding part of code review. Ask developers to explain how their code works. The high-performing AI interaction patterns in the study all involved seeking explanations, and code review can reinforce the same habit. Recognize when learning mode is different from production mode. There's a real difference between using AI to ship a feature in a technology you know well versus using AI to learn something new. Organizations that acknowledge this distinction can adjust expectations accordingly. When someone is learning, slower is often better. Keep some productive struggle in the process. When developers are learning new technologies, consider limiting AI assistance or focusing it on explanation rather than code generation. Working through problems yourself is slower, but you keep what you learn. Watch for signs of dependency. Developers who can't explain code they wrote, who struggle to debug without AI assistance, or who seem stuck on technologies they've supposedly been using for months. These are early signals that skill formation isn't happening. Invest in real understanding, even when it's slower. Code that nobody truly understands is technical debt, even if it works. Making time for developers to build expertise in critical systems pays off when those systems need to evolve or when something goes wrong. AI-enhanced productivity is not a shortcut to competence AI coding tools offer a bargain: faster output today in exchange for potentially reduced capability tomorrow. For experienced developers working in familiar domains, that trade-off might work out fine. For developers learning new technologies, or for teams building systems that will require deep expertise to maintain, the cost may be higher than the benefit. The researchers put it directly: "AI-enhanced productivity is not a shortcut to competence." We think that's the right framing. Organizations that treat AI tools as a shortcut to competence may eventually find themselves with teams that can generate code but struggle to understand it, exactly when understanding matters most. AI is here to stay. Let's use it to make engineering teams stronger over time.We help organizations build sustainable engineering practices. If you're thinking through AI adoption and want to talk about maintaining team capability while capturing productivity gains, we'd like to hear from you.

Engineering
Who's Reviewing Your AI-Generated Code?
By Lumia Labs/ On 24 Jan, 2026

Who's Reviewing Your AI-Generated Code?

96% of developers believe AI-generated code isn't functionally correct. Yet only 48% say they always check AI code before committing. The gap between what developers believe and what they do defines the state of AI coding in 2026. We're building systems on a foundation that the software developers themselves don't trust, and roughly half aren't verifying before it hits production. These findings come from Sonar's 2026 State of Code Developer Survey, covering 1,100 developers. Looking at other research from METR, CodeRabbit, and Veracode, and our experience with development teams using AI, we see some challenges. AI coding is now the default 72% of developers who've tried AI tools now use them daily or multiple times daily. GitHub Copilot leads adoption at 75%, followed closely by ChatGPT at 74%, Claude at 48%, and Gemini at 37%. Cursor, which barely existed two years ago, is now at 31%. The code itself tells the story: 42% of production code now includes significant AI assistance. That's up from 6% in 2023. Projections suggest 65% by 2027. Developers use corporate-approved AI tools, but 35% of developers (also) use personal accounts! That means a third of your team might be feeding proprietary code into AI systems that you don't control. The verification gap Back to that 96% figure. Developers have seen where AI goes wrong: hallucinated functions, subtle logic errors, the security patterns that look right but aren't. Almost everyone understands the problem. Yet verification is inconsistent. Often code is not properly reviewed before it hits production. The Sonar survey found that while 95% of developers spend at least some effort reviewing AI output, the distribution varies widely. 59% rate that effort as "moderate" or "substantial." And that remaining 5%? They're shipping AI code with minimal or no review at all. When LLMs can generate more code faster, teams should focus on reading and reviewing that code. 38% of developers say reviewing AI code takes more effort than reviewing human code. Only 27% say it takes less. For many teams, the time saved on writing is being eaten by review overhead. Or worse, skipped entirely. What we see in practice is that a lot of junior engineers don't even read their own pull requests anymore. Quality concerns External research confirms that AI code has quality concerns. CodeRabbit's 2025 analysis found AI-generated code has 1.7x more issues than human-written code. Veracode's 2025 GenAI Code Security Report found that 45% of AI-generated code contains vulnerabilities. When asked about their concerns, developers ranked them this way:AI code that looks correct but isn't reliable: 61% Exposure of sensitive data: 57% Introduction of severe security vulnerabilities: 44%AI writes code that's subtly wrong in ways that are hard to catch during review, especially the kind of rushed review that happens when teams are shipping fast. AI effectiveness When asked where AI tools are most effective, developers state:Creating documentation: 74% Explaining and understanding existing code: 66% Generating tests: 59% Assisting in development of new code: 55%AI works best on tasks that are well-defined, have clear success criteria, and don't require deep business context. LLM generated documentation often does not catch the 'why' behind the code. Where AI struggles are architectural decisions, business logic, security in context, and long-term maintainability. These require understanding the broader system, the organization's constraints, and consequences that extend beyond the immediate task. With larger context windows and improved models these problems could improve in the future. Smart teams are deploying AI strategically. They know where the AI helps them, but they're not expecting it to replace thoughtful engineering. Agents 64% of developers have now used AI agents like Claude Code. 25% use them regularly. The top use cases are creating documentation (68%), automating test generation (61%), and automating code review (57%). Agents represent the next step: autonomous systems handling entire workflows with less human oversight. But the same trust issues that plague AI code generation get amplified when agents operate independently. Questions engineering leaders should be asking: What guardrails exist for agent actions? How do we audit what agents are doing? What's our rollback strategy when agents make mistakes? AI productivity Does AI make developers more productive, or do they only feel more productive? The average time developers spend on tedious tasks is 10 hours per week. This hasn't decreased despite widespread AI tool adoption. What's changed is the composition of that time: Developers now spend it reviewing AI-generated code instead of writing code themselves. The math doesn't always add up. If AI makes code generation faster but review takes as long or longer, where's the net gain? More code means more PRs, and then review becomes the bottleneck. Quality issues surface later in the pipeline. Time "saved" on writing gets spent on debugging and fixing. METR's 2025 randomized controlled trial found that experienced developers were actually 19% slower when using AI tools on real-world open source tasks. Productivity is hard to measure objectively, but it is not always true that AI makes developers more productive. Measure your full delivery cycle and pick meaningful metrics. What engineering leaders should do Acknowledge the trust gap. Your developers don't trust AI output. Build processes that account for this. Don't assume AI equals automatic productivity gains. Mandate verification standards. If only 48% always check AI code, make checking mandatory. Automated quality gates for AI-generated code. Enhanced review for AI-assisted commits. Improve pre-commit checks, the more you can catch automatic, the better. Address shadow AI. 35% using personal accounts is a governance problem. Provide approved tools with enterprise controls, and create clear policies. If you have approved tools, don't limit them for cost saving reasons, because that will drive people to use personal accounts. Measure what matters. Track end-to-end delivery time, not just coding speed. Monitor code quality metrics over time. Watch for increases in post-deployment issues. Right-size expectations. AI excels at documentation, test generation, and code explanation. It struggles with reliability, security, and architecture. Prepare for agents. If your team is using agents, governance frameworks need to be in place now. Audit trails and rollback capabilities are non-negotiable. The organizations that will thrive are the ones that adopt AI thoughtfully: realistic expectations, solid verification, clear governance.Lumia Labs helps organizations build software that works. If you're navigating AI tool adoption and want a technical perspective grounded in 25 years of enterprise experience, we'd like to hear from you.

Engineering
The Hidden Costs of Vibe Coding
By Lumia Labs/ On 08 Jan, 2025

The Hidden Costs of Vibe Coding

The demo was impressive. A developer typed a prompt, and within seconds, working code appeared. The team lead smiled. Finally, a way to ship faster. Six months later, that same team is drowning in technical debt they can't explain, debugging code nobody fully understands, and wondering why their "accelerated" project is now three months behind schedule. We've seen this play out. According to MIT's GenAI Divide report, 95% of enterprise AI pilots fail to deliver rapid revenue growth or measurable cost savings. More striking: 42% of companies abandoned most of their AI initiatives in 2025, more than double the abandonment rate from 2024. So what's happening? And more importantly, how should technical decision makers evaluate AI coding tools before adoption? The Flow-Debt Trade-off AI coding tools excel at one thing: generating plausible code quickly. That speed feels like productivity, but it isn't always. The pattern we've seen repeatedly goes like this: initial development velocity spikes, developers report feeling more productive, and early features ship fast. Then the problems start appearing. The generated code works, but it carries hidden assumptions: database queries that scan full tables, authentication flows that skip edge cases, API contracts that assume sunny-day scenarios only. Each piece makes sense in isolation, but together they create a system that gets harder to change with every addition. Researchers call this the flow-debt trade-off: the seamless experience of generating code creates an accumulation of technical debt through architectural inconsistencies, security gaps, and maintenance overhead that only reveals itself later. No architecture, no context The same patterns show up again and again in AI-generated code, all stemming from the same limitation: AI tools optimize for the immediate task, not the system as a whole. Architecture decisions get flattened. The AI doesn't see your deployment constraints, your team's operational capacity, or your three-year roadmap. The result is often monolithic structures that work fine initially but resist scaling individual components independently. Database queries go unoptimized. Generated code frequently uses ORM patterns that hide inefficient queries. Things work fine with 1,000 records. At 100,000 records, response times spike. At a million, the system becomes unusable during peak load. Error handling stays shallow. AI generates the happy path well. It's less consistent with failure modes, retry logic, circuit breakers, and graceful degradation. Systems built this way work until something goes wrong, then fail in unpredictable ways. Security gets surface treatment. Input validation appears, but business logic vulnerabilities slip through. Authorization checks exist, but privilege escalation paths remain. The code looks secure without being secure. Observability is an afterthought. Logging statements appear, but structured logging for production debugging is rare. Metrics, traces, and alerting configurations are usually missing entirely. Best practices If you're using AI coding tools (and most teams are), here's how to get the benefits without the debt: Measure total cost, not initial velocity. Track time spent debugging AI-generated code, refactoring architectural decisions, and addressing security findings. Compare against the time saved during generation. Run your security review unchanged. Don't reduce scrutiny because the code "came from AI." If anything, increase it. Generated code often passes cursory review while hiding subtle issues. Assess architectural coherence at milestones. Regularly examine whether the codebase still follows your intended patterns. Drift happens fast with generated code because each snippet optimizes locally, not globally. Keep doing pull request reviews. Code review matters more with AI-generated code, not less. If you're the one creating the PR, review your own code before asking others to look at it. The AI wrote it, but you're responsible for it. Plan for refactoring cycles. AI-assisted codebases typically need more aggressive refactoring than traditionally developed ones. Budget for this upfront. Keep humans on critical paths. Authentication, authorization, payment processing, and data handling warrant extra scrutiny regardless of how the initial code was written. The companies getting it right The organizations succeeding with AI coding tools share common patterns: they treat generated code as a starting point rather than a finished product, maintain strong architectural oversight, and invest in code review practices that catch the systematic issues AI introduces. They also recognize that developer productivity and system quality are different metrics. Optimizing for one at the expense of the other creates problems that take years to resolve. We've spent 25 years building enterprise systems. The fundamentals haven't changed: good architecture enables teams to move fast without breaking things. AI tools don't change this equation. They just make it easier to skip the foundational work that pays off later. If you're evaluating AI coding tools, start with contained experiments. Measure outcomes over months, not days. And bring architectural thinking to the conversation before you have thousands of lines of generated code that nobody fully understands. The technology is genuinely useful, and finding the balance requires the kind of judgment that can't be automated.Lumia Labs helps organizations build scalable systems and improve existing codebases. If you're navigating AI adoption and want a technical perspective, we'd like to hear from you.