Siperb Director Conrad De Wet shares his insights on the question: “What is AI doing to code development?”
In this interview-style Q&A, Conrad explains why AI is rapidly reducing the cost of producing “working code” — and why the real competitive advantage is shifting to system design, operational knowledge, reliability engineering, and security judgement. The discussion covers technical debt signals, modern code review in the age of AI-generated PRs, non-negotiable guardrails, and what remains human-led in real-time communications systems.
These engineering realities are central to building and operating secure, reliable communications platforms such as Siperb.
Key takeaways
- The moat shifts from writing code to operational consequences: reliability, security posture, failure recovery, and product insight.
- AI increases velocity most where judgement is weakest: boundaries, state transitions, retries, and “looks right” abstractions.
- Code review becomes intent and risk-led, with stronger invariants and clearer ownership norms.
1) If AI makes “working code” cheap, what becomes the moat?
Question: If AI keeps lowering the cost of producing “working code”, what becomes the real moat in software—architecture, product insight, data, distribution, or something else? Why?
Answer:
As AI drives the cost of producing working code toward zero, the moat shifts away from code and toward consequences. Architecture still matters, but not as a diagram or pattern library. It matters as accumulated decision-making: understanding why systems are shaped the way they are, which constraints are fundamental, and which are historical.
Product insight becomes more valuable because AI doesn’t feel friction or user pain; it only approximates it. In real-world systems like communications platforms, the true moat is operational knowledge—knowing how things break under load, how failures cascade, and how to design for recovery instead of ideal conditions.
2) When does “AI velocity” turn into technical debt?
Question: Where have you personally seen AI increase velocity but decrease quality—and what signals tell you the trade-off has flipped into technical debt?
Answer:
I’ve seen AI dramatically speed up development in areas like glue code, refactors, and integration layers, but quality often erodes quietly. The problem is that AI tends to produce code that is locally correct but globally incoherent.
The signals appear when the codebase grows faster than shared understanding, when tests validate behaviour but not intent, and when engineers hesitate to delete or modify things they didn’t fully reason through. Once the team starts navigating around the code instead of thinking with it, the velocity gains have already turned into debt.
If you want a crisp definition teams can align on, Martin Fowler’s explanation of technical debt is a practical reference point.
3) What does good engineering judgement look like in the AI era?
Question: In a world of AI-generated patches and PRs, what does “good engineering judgement” look like—and how do you test for it when hiring?
Answer:
Good engineering judgement is the ability to reject plausible solutions. AI is excellent at producing code that looks right, so judgement shows up in knowing why something shouldn’t be done, even if it works.
It’s the ability to explain long-term consequences, hidden trade-offs, and future constraints. When hiring, I test this by asking candidates to critique existing systems rather than build new ones. If someone can reason clearly about risk, trade-offs, and evolution without immediately reaching for new code, that’s a strong indicator of judgement.
4) Which bugs will increase with AI coding assistants?
Question: What categories of bugs do you expect to increase because of AI coding assistants, and what should teams do to defend against them?
Answer:
AI tends to increase bugs at the boundaries: timeout handling, retries, partial failures, and state transitions in asynchronous systems. Security issues can also increase when abstractions are trusted too easily, and semantic bugs become more common when code does the wrong thing very efficiently.
The defence isn’t more linters or more tests, but stronger invariants. Explicit state machines, protocol assertions, and designing systems where illegal states are hard to represent become increasingly important.
For a widely used baseline you can map to policies and SDLC controls, see the NIST Secure Software Development Framework (SSDF).
5) How should we redefine code review when a model is a co-author?
Question: How should we redefine code review when the author is partly a model—do we review the code, the prompt, the tests, the intent, or all of the above?
Answer:
Code review has to shift toward intent. The most important question becomes why the change exists and how it aligns with the system’s direction, not just whether the code is correct.
Prompts matter, but understanding the problem being solved matters more. In practice, this means fewer line-by-line comments and more design-level review checkpoints, even for small changes. AI makes change cheap, but it makes loss of coherence expensive.
6) What guardrails are non-negotiable?
Question: If we treat AI like a junior developer that never sleeps, what are the non-negotiable guardrails you would put in place?
Answer:
AI should never own threat modelling, dependency policy, or release decisions. Humans must remain responsible for security posture, blast radius, and failure modes.
Releases should be gated by observed behaviour in real environments, not just passing tests. AI doesn’t worry, and worrying is still a critical engineering skill.
For an operations-first reliability playbook, Site Reliability Engineering (SRE) is an excellent foundation.
7) What does “ownership” mean when AI wrote most of the code?
Question: What does “ownership” mean when AI wrote 60–80% of the implementation? Who is accountable, and how do you enforce that accountability culturally?
Answer:
Ownership becomes outcome-based, not authorship-based. If your name is on the service, you own uptime, security, and maintainability regardless of how the code was produced.
Culturally, this requires creating an environment where engineers feel safe deleting AI-generated code they don’t understand. If nobody feels confident owning a piece of code, it shouldn’t ship.
8) Which skills matter most over the next 24 months?
Question: How do you see AI shifting the balance between “writing code” and “designing systems”? Which skills will matter more in the next 24 months?
Answer:
Writing code is rapidly losing its status as the primary differentiator. Designing systems is becoming more valuable.
Skills like protocol literacy, failure modelling, observability design, cost-aware architecture, and knowing when to delegate to AI versus when to intervene will matter far more. The best engineers will increasingly act as editors of systems rather than producers of code.
9) How do you choose between multiple “passing” implementations?
Question: If AI can produce multiple competing implementations instantly, how do you decide which one is right beyond “it passes tests”?
Answer:
I look for the implementation that fails most clearly, explains itself best, limits future damage, and aligns with operational reality. Passing tests is necessary, but predictable failure and explainability are what make systems sustainable.
10) In real-time comms systems, what will AI accelerate vs remain human-led?
Question: Looking at systems like Siperb—real-time communications, protocols, security, and reliability—what parts will AI genuinely accelerate, and what parts remain human-led?
Answer:
AI will accelerate things like boilerplate protocol handling, codec negotiation logic, tooling, and documentation.
The parts that remain human-led are failure handling in real networks, security decisions, trust boundaries between systems, and incident response. AI can help write SIP routing logic, but deciding where media must terminate for security, compliance, or observability is still a human judgement shaped by experience.
If you’re building browser calling or real-time communications into an existing stack, Siperb’s WebRTC softphone platform is designed around the operational realities discussed here—protocol boundaries, security posture, and recoverable failure.
Leave a Reply