Vaibhav, an engineer at CodeWalnut, spoke with Ben Sheridan-Edwards, CTO of CodeWalnut, about the shift from writing code to orchestrating agents, the discipline that separates product engineers from feature-factory workers, and why he still blocks PRs that do not meet the bar. Ben opened up about his own agentic workflow, how he defends his team against unreasonable deadlines, the trap of overengineering that most mid-level engineers fall into, and what a junior developer today should actually be doing to grow. This is the full conversation, lightly edited.
👋 Meet Ben Sheridan-Edwards:
Setting The Room
Ben has shipped 5,000+ changes in the last year. Roughly ten times what he shipped the year before. He does this while running a fleet of nine agents, reviewing PRs from his phone on walks, and still finding time to tell his engineers to slow down.
The interesting thing is not the number. It is that none of it looks like the AI-slop everyone else is producing. Every PR arrives with proof, and his judgment sits at the merge button, not at the keyboard.
Which naturally leads to the question every engineer is quietly asking right now: if agents are doing the writing, what is left for the humans? This conversation is about what Ben's answer looks like in practice.
Who Is Ben Sheridan-Edwards
Ben is the CTO of CodeWalnut. He leads technical strategy across the engineering team, sets the architecture and code review standards, and pushes hard on AI-assisted workflows that raise delivery speed without lowering the quality bar. He is also the creator of Style Proof, a deterministic visual regression tool that gives engineers the confidence to merge agent-written PRs without manual visual comparisons.
Where CodeWalnut Sits
CodeWalnut is a product engineering studio built for the AI-native era. The team ships across the full stack for enterprise clients in the US, UK, and India, using agentic engineering practices.
But CodeWalnut is not just a build shop. The same team that ships production software also runs community masterclasses on agentic AI and delivers corporate training programs.
The through-line across all of it is product ownership. Engineers here are hired and grown to think like product engineers, not feature-factory workers, and to defend a code quality bar that has been built up PR by PR over years. That combination, real shipping, real teaching, real conviction, is what Ben has been building.
The Gospel According To Ben
1. Product Engineering
"A product engineer has a blend of taste, which is hard to teach."
- Product engineers own the full lifecycle, from managing friction points to merging the final PR with high aesthetic taste.
- True ownership allows engineers to challenge product requirements to ensure the best outcome for the user.
2. Agentic Engineering
"Agentic engineering is a proof problem, not a prompting problem."
- Shift judgment from the keyboard to the PR by using evidence and audit trails to validate agent output.
- Focus on orchestration rather than syntax; fundamentals like SOLID and DRY remain essential for well-designed systems.
3. Release Confidence
"A release-confidence bar turns agent output into shippable software."
- Automated quality gates like Style Proof and end-to-end tests provide the certainty needed to merge code without manual visual comparisons.
4. Engineering Culture
"Deliver your best work when you are happiest, calmest, and not under delivery pressure."
- Protect the team from unreasonable deadlines to maintain high velocity and avoid the cycle of rework.
- Maintain a nimble codebase by fighting unnecessary complexity and choosing the smallest, most maintainable solutions.
5. High Standards and Continuous Growth
"Confusion is the prerequisite to learning. Do not be afraid of that."
- Juniors should focus on out-questioning AI and understanding the 'why' behind technical principles.
- Foster a culture where the best ideas win regardless of seniority, and every PR approval is a step toward growth.
The Conversation, In His Own Words
Q: What does a product engineer actually look like to you, versus a developer?
Ben: A developer builds working software from a ticket. I expect product engineers to deeply care about the user experience, spending time on micro-interactions and friction points. This requires a blend of taste and design understanding to solve problems with minimal friction.
Ownership is essential. Engineers must identify problems, draft briefs, and write behavioral tests. We are seeing a convergence where product managers become more technical and engineers more product-focused.
Q: Can you walk through how you actually go from idea to production using agentic engineering?
Ben: Agentic engineering turns ideas into specs, evidence, and PRs. The critical layer is the proof. Quality gates allow us to merge agent-written code into production with high confidence because the evidence is visible and touchable.
It is about creating a factory where judgment is applied at the right time—at the PR level, backed by all necessary proof, rather than being a bottleneck during creation.
I prioritize protecting my team from unreasonable timelines. I have pushed back on Friday afternoon requests for Monday morning deliveries to ensure our environment supports the best people.
Quality work happens in a calm environment. Rework is the biggest detriment to velocity, so we value our engineers and protect them from the fight-or-flight responses that lead to cutting corners.
Q: What happens to engineers whose whole identity was being a React or Java expert, now that AI can write decent code in any framework?
These skills remain valuable but at a different layer of abstraction. We have moved from coding syntax to a prompting and orchestration layer. It is like the shift from C to JavaScript.
Architecting solutions still requires understanding frameworks, as you cannot orchestrate what you do not know exists. Success now depends on diagnosing problems and orchestrating solutions rather than memorizing syntax.
Q: How do you personally keep up with new AI tools released every single day?
Ben: Your attention is the bottleneck. I look for tools that decouple inputs from outputs and compound my productivity. Benchmark what works, but step away when overwhelmed; no one can keep up with everything.
Right now I am looking for things that decouple my inputs from my outputs. What compounds your workflow. If I can find one tool that makes me 10 percent more productive, and that gains compound over time, that is what I am looking for. I am never going to keep up with everything, neither are you. All I can do is benchmark tools, see what is working, see what is not. If you find yourself overwhelmed, go touch grass, go for a walk, put yourself away from your phone.
Q: Where is the line between scalability and overengineering?
Ben: Overengineering is costly to maintain. Aim for the smallest codebase possible; it is easier to maintain and more nimble for future migrations. Build only what you need right now.
Flexibility you don't need is just unused complexity. Source control allows us to rewrite later if needed. A lean codebase remains the most maintainable over time.
Q: How does a junior developer signal expertise without having to talk about it?
Ben: Signal expertise through principles. Understanding the 'why' separates those who just implement from those who understand value. Curiosity and asking deep questions are what make engineers thrive.
We let the best ideas win regardless of seniority. Anyone can challenge me as CTO. Focusing on winning ideas is what makes us a great company.
Closing Thought
The clearest thread across everything Ben said is that speed on its own is not the point. Anyone can move fast with an agent. What matters is whether you can defend what got shipped, whether your team was healthy while shipping it, and whether the engineer who wrote the prompt actually understood the output.
For juniors, the takeaway is simpler than it sounds: slow down, question everything, learn the principles, and stop being afraid of confusion. That is the job.
If you want to trade notes with Ben on agentic engineering, product ownership, or how CodeWalnut thinks about AI-native workflows, reach out to him on linkedin or at ben@codewalnut.com.
When to Hire CodeWalnut?
