Real Alpha
Try Pro free

Knuckle Up with Nakul · 4 min · May 19, 2026

AI writes most code, but Decagon engineers remain accountable

Ashwin Sreenivas · Co-Founder & CTO, Decagon

AI tools write most of Decagon's code, but engineers must understand and defend what they ship.

In this episode

Full analysis
  1. 2:13Customer pain should shape the product before strategy4 min
  2. 13:09Decagon accepts coordination costs to preserve speed4 min
  3. 40:01Most AI companies need product-minded FDEs3 min
  4. 7:57Decagon brings engineers into customer sales and support5 min
  5. 25:52Decagon uses bar raisers to protect its hiring bar3 min
  6. 31:18AI writes most code, but Decagon engineers remain accountable4 min
  7. 35:05AI shifts engineers toward judgment and EPD leaders toward alignment5 min
  8. 57:19Decagon fine-tunes smaller models for specific customer tasks3 min
“you are responsible for the code you push and you should be prepared to defend it”
Ashwin Sreenivasat 32:26 · Knuckle Up with Nakul
32:26

Takeaways

  1. Engineers can choose among several coding agents.
  2. An engineer remains accountable for each AI-written change.
  3. Security controls include code checks and regular penetration tests.

About this segment

AI tools write most of Decagon's code, but engineers must understand and defend what they ship. The company supports them with agent-ready code, automated checks and layered security reviews.

Ashwin Sreenivas

Ashwin Sreenivas is cofounder and CTO of Decagon.

Co-founded Decagon, the conversational AI platform valued at $4.5B, after building Helia, which Scale AI acquired.

  • Nakul Mandan, Host · Host, Knuckle Up with Nakul

    General partner at Audacious Ventures; his show goes deep with founder CEOs on how they build.

From “The AI founder advice you won’t hear on X | Ashwin Sreenivas (Co-Founder at Decagon)”, May 19, 2026. Watch the full episode

Answers “Which jobs will AI replace, and which are safe?” See all 132 answers

Answers “Will AI replace software engineers?” See all 40 answers

Answers “Are AI agents ready for real work?” See all 104 answers

Transcript

Transcribed by machine (Whisper) from the episode’s audio, so a word may be off here and there.

  1. 31:25

    At this point, are your engineers even writing code at all? Yeah, it's a great question. I think I would say at this point, the vast majority of code that is written is written by, you know, Cloud Code, Cursor, Cognition, Devon. But we still expect our engineers to understand what was written and essentially sign off on it and saying, hey, I pushed this PR. I'm fine with it. Right now, we want to give them all the support around that.

  2. 31:54

    So, for instance, we've spent a lot of time investing in how do we set up our code base to be easy to use AI with. How do we create good documentation in the code base? How do we split it up in a way that the agents can understand? How do we create good, you know, Cloud MD files if you're using Cloud Code, for instance, so that as an engineer picking it up, you can get started very quickly. Similarly, on the review and testing side, we've invested a lot in saying, how can we find issues very quickly?

  3. 32:18

    How can we automate checking for style issues and structural issues and things like that and security issues, of course. But we still expect the engineer to be responsible. We say, hey, use all the tools you have available so that you can move faster. but at the end of the day, you are responsible for the code you push and you should be prepared to defend it rather than saying, oh, you know, the AI agent wrote it.

  4. 32:39

    That's all I know. Do you mind sharing whatever you can on what's the engineering stack at DecaCon now in terms of course, like, yeah, what AI tools that you guys are using? So interestingly enough, we subscribe to all of them at this point because engineers have their preferences on what they would like to use. So we have some engineers that use Cloud Code. We have some engineers that use Devon. We have some engineers that use cursor and we have some engineers using codecs.

  5. 33:05

    And we are fine with whatever they want to use because ultimately we use this as a, we view this as an accelerant to building. And so we're not opinionated on what they use. So the things that we do on the EPD org to help is, number one, making sure that the code base is well set up initially to be able to work with these kinds of agents. and number two, ensuring that everything downstream can handle now the increased rate at which PRs have created like testing, reviews and things like that that would otherwise become bottlenecks.

  6. 33:38

    But in terms of the tools themselves, we actually partner with all of those folks. Testing, security, enterprise readiness of the code. At this pace of code gen, and you guys are selling to some of the largest organizations in the world. These people probably have low tolerance for customer support or you're giving them something that deals with their customers. So have there been some fuck-ups in the journey?

  7. 33:59

    Have there been areas where you're like, guys, we need to be really, really strong on this. We can't just adopt AI. On the security side, we've been very, very tight. Kind of no issues there. Because again, from the very early days, right from day one, we're like, we work with extremely large enterprises that are trusting us with extremely sensitive pieces of data. So even from the very early days, security was always like very tightly maintained.

  8. 34:23

    And the way that we actually go about operationalizing this is several fold. One is ensuring that your coding practices itself make it hard to mess up. So for instance, requiring that when you create a new route and you automatically add an authorization tag, it just does all the best practices for you. So it's kind of essentially we make it harder to mess up on the security side. Second, a lot of our PRs explicitly look for certain kinds of security issues.

  9. 34:51

    Third, we have an application security team in-house that's constantly doing pen tests, that's constantly doing reviews on any changes to anything sensitive. And fourth, we're getting pen tested externally all the time. So really something would have to go through lots of misses for there to be any kind of impact. How does the IC engineering role change in these,