What Daghan Altas's Path From Meraki Firewalls to Semgrep Product Reveals About Betting on the Models
AI made writing code fast, and it made finding vulnerabilities fast for attackers and defenders alike. Engineering leaders now have to decide where limited budget and talent go when many of the obvious AI investments patch a model weakness that the next release will erase. The harder question is which bets keep paying off as the models improve, and which part of the delivery pipeline now sets the pace?
Daghan Altas is Head of Product at Semgrep, a code security company, and he has moved between product and revenue roles for most of his career. At Cisco Meraki, he created the MX firewall and SD-WAN gateway product line. He joined Semgrep in 2018 and served as Chief Revenue Officer, growing sales from zero to the mid-$20 million ARR range by his account, before returning to product. He also holds graduate degrees in microelectronics from McGill and data science from UC Berkeley.
On Episode 14 of TechPod Talks, Stephen Koza, CEO of EverOps, opens with a claim Daghan knows is unpopular in his own industry. Human pull request review has become a bottleneck. Stephen worked alongside Daghan at Meraki, and he presses him on why a security leader would argue for less human review, how Semgrep decides what to build when every model release moves the ground, and where a team that feels behind on AI should start. The full episode also covers product-market fit and the move from sales back to product.
Read on for the test Daghan uses to decide which AI investments earn a place on the roadmap, and what it means for how you staff code review, security, and AI adoption.
The Positive Slope Test Separates Durable AI Bets From One-Year Products
Daghan's first filter for any AI initiative is whether it gets more valuable as the models get better. He traces the idea to years of listening to podcasts from AI lab leaders, where most of the content was ordinary and every so often a real signal slipped out. The signal he kept was a warning about products built to cover for what today's model does poorly.
"If your value proposition is 'AI does this, but it's terrible at that, so I'm going to go fix that,' you're giving yourself a one-year life. The next model is going to fix that."
Semgrep turned that warning into an internal equation. Daghan describes it as the derivative of Semgrep's value over the derivative of AI, and the requirement is that the result stays positive, so each unit of model improvement should make Semgrep more valuable to customers. The original product focused purely on detection, and as the models improved, it looked less and less valuable, which put the company on a negative slope. Fixing the slope meant choosing work where today's model gets the team only 80% of the way there, because those projects gain value with every release.
For a CTO weighing build versus buy, the same test sorts a roadmap quickly. Work that patches a model gap is a short-lived asset, while work that feeds, directs, or verifies model output compounds. Daghan is candid that the test can misfire. Semgrep stayed out of some markets it expected AI to absorb, and he says players in those markets are still growing 100% to 200%. His advice is to apply the test with a lot of humility and revisit each call as the models move.
Attackers Gained the Same AI Speed, So Defense Now Runs on Closing the Loop
Language models made detection easier for everyone, Daghan says, and that cuts both ways. The capability that helps a defender find flaws also helps an attacker find exposed secrets, supply chain weaknesses, and code vulnerabilities. Once both sides can find the same problems, the advantage goes to whoever finishes the work that follows a finding.
He describes the change in timelines bluntly. Security teams could once log findings in a backlog, route them through a ticketing system, and work through them at their own pace. Today the target compresses from two months to two weeks to closing everything the same day, and detection is a small piece of that work. The questions that matter sit downstream of the scanner.
"How do you close 10,000 tickets? What is the triaging process? What is the remediation process? What is the proof of work process?"
Those questions belong on a VP of Engineering's security scorecard. Daghan argues that attackers already have the velocity and that defenders are not fast enough yet, so the goal is closing the entire defense loop, reporting and proof of work included, as fast as possible. He frames the proof step as the one leaders skip. When someone says a malware issue is done, the organization should be able to show how it knows and how fast it got there. Measuring time from finding to verified fix turns that framing into a budget decision, and triage, remediation, and evidence deserve the same funding as the scanner.
Organizational Context Is What Makes a Precise Model Useful
Daghan splits model performance into two measures that go back to cancer screening and radar: precision and recall. Precision asks how many flagged issues are real, and recall asks how many real issues got flagged. His illustration is a model that reports ten vulnerabilities, nine of them true, for 90% precision. If the code actually holds 90 vulnerabilities, recall is 10%, and 81 stay hidden. He says models are very good on precision and still struggle with recall, though he expects that to improve.
The larger gain comes from context. Semgrep builds an organizational picture for each customer that spans every code base, how those code bases relate, how the business works, and how the threat models connect. With that picture in place, Daghan says the models do a phenomenal job. Semgrep's program analysis, tools, and databases all exist to serve the model at the heart of detection, which he summarizes as working for the models. DORA's 2025 research lands in a similar place, finding that AI acts as an amplifier of an organization's existing strengths and weaknesses.
The investment implication is less glamorous than a new model subscription. Daghan's data science training at Berkeley taught him that most of the work is getting clean, ground-truth data into the system, and that the inference part is easy. For an engineering leader, that points spending toward ownership maps, dependency graphs, and written threat models that tell a model how the pieces connect. Those assets raise the ceiling on every model the team adopts next, which makes them a textbook positive slope bet.
Secure by Design Shrinks the Loop Before the First Finding Appears
The fastest way to close the defense loop is to generate fewer findings, and Daghan argues that many organizations secure software after it ships when they could design it correctly from the start. He uses a civil engineering comparison. A team that builds a bridge as beautiful as the Golden Gate and then insists on x-raying it for cracks before the first car crosses should have made those calculations before construction began. He credits tier one, tech-forward teams at companies like Google and Facebook with building this way, and he sees others spend an extraordinary amount of time securing code after it has been built.
Injection flaws are his proof. Daghan points out that the category has sat in the OWASP Top 10 for roughly a decade, that the secure design techniques to prevent it are well understood, and that teams still ship it. The OWASP Top 10 for 2025 still ranks injection fifth, reports that every application in its data was tested for some form of it, and counts more than 14,000 SQL injection CVEs. His conclusion is that:Â
"The solution is more cultural than technical."
That makes secure by design a leadership decision. Engineering leaders set the defaults every team inherits, from approved libraries and templates to the patterns code review expects to see. Those defaults decide which vulnerability classes never reach the backlog. A paved road approach to platform consolidation gives those defaults a home, so the secure path is also the fastest path for a developer shipping on a deadline.
Human Pull Request Review Is the Weakest Control in an AI Pipeline
Daghan agrees that writing code stopped being the constraint and that verification took its place. He compares the debate over AI code review to self-driving cars. He drives a Model Y with full self-driving and trusts it more than himself, because it never gets distracted or has a bad day. The objection he hears most about automated review rests on the wrong comparison.
"People compare AI to a godlike sort of god-tier code review. People forget that you're comparing AI to a human."
That human now receives pull requests from AI bots that can run 9,000 lines across 25 files. Daghan cites studies in which reviewers handed known-vulnerable code without warning found about 3 of 50 vulnerabilities, roughly 7%, and reached about 40% when told to look carefully. Independent research points the same way. In a 2022 ICSE study of 150 developers, reviewers told to focus on security were eight times more likely to detect a vulnerability, and only 3% of the uninstructed group found one of the two planted flaws.
Daghan keeps humans on architectural threat modeling and strategic direction, such as a change that moves a product off protobufs or off Kubernetes. Those exceptions should be flagged and read by a person. For everything else, he says "the vast majority of day-to-day code should just fly through your AI system," and the organization will be better off. The leader's job is to write the exception policy, define what an architectural change looks like, and measure automated review against the human baseline it replaces.
AI Fluency Compounds When Leaders Protect the Hours and Concentrate the Talent
Engineering organizations have the best chance of fast AI progress, Daghan says, and he sees it inside Semgrep when he compares engineering with go-to-market. AI thrives on data, verification loops, and context, and engineers already work with all three. Pulling context together is mostly data engineering, which is familiar ground for an engineering team and hard for most other functions.
For teams that feel behind, his prescription is practice. People should clock at least eight hours a week of solid, hands-on AI work, roughly 15% to 20% of their working time, and start with simple tasks. The common failure is attempting something fancy on day one, such as automating an entire recruiting workflow, before anyone has built a sense of what the tools can do. He puts it in kitchen terms, telling Stephen that the way to become a great Italian chef is to get into the kitchen and start with an omelet. Once people gradually build up their AI mileage, they develop a taste for what is possible, and the progress starts to accelerate.
"Don't peanut butter your talent on this. If you have five or six people in an organization who are doing it the right way, put them all in the same team. Let them rip."
Concentration creates critical mass. Daghan says a team like that builds momentum, attracts people who want to join it, and starts laying the foundations for how the rest of the company should work. For a VP of Engineering, that is a staffing decision to make this quarter, and it is the one most likely to turn the rest of this agenda into practice.
How to Apply These Frameworks This Quarter
- Run the positive slope test on the AI roadmap: List every AI initiative and mark whether it patches a current model weakness or gains value with each model release. Buy or sunset the first group, and put engineering time into the second.
- Measure the full defense loop: Report time from finding to verified fix, with triage, remediation, and proof of work tracked as separate stages so the slowest one is visible to leadership.
- Write the exception policy for human review: Define the triggers that route a pull request to a person, such as platform migrations, protocol changes, and threat model changes, and let automated review own everything else behind measured quality gates.
- Fund the context layer: Assign owners for service catalogs, dependency graphs, and written threat models, because that context lifts every model the team adopts.
- Form one concentrated AI team: Move your five or six strongest AI practitioners into a single team, and protect eight hours a week of hands-on AI time for everyone else in engineering.
Daghan's focus on verification extends the argument in our Orchestrate, Verify, Repeat article, which looks at the leader's role once AI writes most of the code. For the budget conversation that follows, security earns its budget when it speaks the language of revenue.
Partner with EverOps to Build a Pipeline That Improves as the Models Do
The AI investments that last are the ones that get more valuable with every model release, and the same logic applies to how an organization verifies, secures, and ships code for a VP of Engineering or CTO, turning into concrete work. Sort the AI roadmap by slope, redesign code review around an exception policy, instrument the defense loop from finding to verified fix, and build the organizational context that lets models perform.
EverOps embeds senior engineers inside your organization to own that work alongside your team. The AI Opportunity Assessment ranks your AI use cases with ROI projections, so the positive slope bets rise to the top. The AI Adoption TechPod places a forward-deployed AI engineering team inside your organization, giving you the concentrated group Daghan describes. The Cloud-to-Code Interoperability Assessment finds where code slows between commit and production, and our Security and Compliance practice builds secure defaults into the platform.Â
To start with the bottleneck that matters most to your team, reach out to our team.
Keep up with TechPod Talks
TechPod Talks brings engineering and technology leaders together for candid conversations about the platforms, teams, and decisions behind modern software. Subscribe on Apple Podcasts, Spotify, YouTube, or the EverOps podcast page.
Connect with Daghan Altas on LinkedIn and follow EverOps on LinkedIn for clips and episode announcements.
Frequently Asked Questions
What is TechPod Talks?
TechPod Talks is the EverOps podcast hosted by CEO Stephen Koza. It features candid conversations with the leaders building what's next in software, platforms, and security. Episodes are written for VPs of Engineering, CTOs, and the directors and senior managers who work with them.
What topics does Episode 14 cover?
Episode 14 features Daghan Altas, Head of Product at Semgrep. He and Stephen discuss product-market fit at Meraki and his move from Chief Revenue Officer back to product. Most of the conversation covers the betting on the models framework, secure by design, and closing the defense loop at attacker speed. They also cover the case for automating most pull request reviews and how organizations that feel behind should start with AI.
Who is Daghan Altas?
Daghan Altas is Head of Product at Semgrep, a code security company. He previously served as Semgrep's Chief Revenue Officer, and at Cisco Meraki he created the MX firewall and SD-WAN gateway product line. He holds graduate degrees in microelectronics from McGill and data science from UC Berkeley.
What is the betting on the models framework?
Betting on the models is Daghan's test for AI investments. A product or project should gain value with every model improvement, which he describes as a positive slope. Work that compensates for a current model limitation risks a one-year shelf life, because the next model release may close the gap.
Should AI replace human pull request review?
Daghan argues that automated review should handle the vast majority of day-to-day code, with humans reading flagged exceptions such as architectural changes and threat modeling decisions. He points out that human reviewers catch a small share of known vulnerabilities, so the right comparison for AI review is the human baseline.
How does this episode connect to EverOps' work?
EverOps helps engineering organizations turn AI adoption and delivery modernization into measurable outcomes. The AI Opportunity Assessment prioritizes AI use cases, the AI Adoption TechPod embeds a forward-deployed AI team, and Platform Engineering and CI/CD work remove the verification bottlenecks that slow code between commit and production.
