[3Qs with Stan]: Guest David Proctor
Software Architect becoming ML Researcher & The Art of Vibe Coding. Why quantity beats quality, and why the best engineer might not know how to code.
Most podcasts are 45 minutes of fluff wrapping 5 minutes of insight. We skip the weather, the “how are yous,” and the generic bios.
Welcome to 3 Questions with Stan.
The rules are simple: I ask the guest three rigorous, tailored questions based on their actual work. They ask me zero to three questions back. We are done in 15 minutes.
For this episode, I sat down with David Proctor. David is a technologist who has led multi-billion dollar mergers, managed networks for major telcos, and once accidentally took down the internet in Los Angeles. He is not a traditional software engineer - and he thinks that is his superpower.
Here is what we uncovered.
1. Does Quantity Actually Beat Quality?
David started “The Algorithm” project with a controversial take: in the current AI landscape, quantity beats quality. I asked him if he still believes that generating massive volume is better than obsessing over perfection.
His answer? It depends on your goal.
If your goal is just reach (impressions), then yes—the law of averages wins. The more you put out, the more likely something sticks. But if your goal is deep engagement, quantity is just the top of the funnel.
Spiky Point of View:
Perfection is the enemy of the algorithm. Negative commentary generates responses. Responses boost impressions. If you are precious about every post, you are invisible. Quantity gets you the audience; quality keeps them.
2. The “Non-Developer” Advantage
David and I work in the same role, but I come from a software engineering background, and he comes from infrastructure and architecture. I asked if his lack of “pure” coding background is a hindrance or a help.
David argues it is a massive advantage because he solves problems for people, not for other engineers.
A pure developer might build a brilliant CLI tool that requires you to SSH into a server and edit a config file in Vim. David builds for the end-user who just wants a button. Because he doesn’t think like an “elite” coder, he doesn’t build elite-only solutions.
Spiky Point of View:
You can’t be the baker who rolls into a software shop and tells them how to code. But sometimes, a room full of software engineers will only see software engineering problems. You need someone who looks at the $2 billion merger and asks, “Why do we have two HR systems?” rather than “How do I refactor this code?”
3. The $4 Million Mistake (and the Value of Planning)
David has been building “The Algorithm” (an automated X/Twitter reply engine) for months, but it has faced scope creep and deployment issues. I asked him what he would do differently if he started today.
His answer was a masterclass in the difference between “Vibe Coding” and engineering.
He shared a story from his days at Verizon. He wrote a Python script to update routers. He tested it on 10. It worked. He tested it on 20. It worked. Then, he got cocky and ran it on 400 routers in Los Angeles at 2 AM.
He took down the internet for millions of people.
Spiky Point of View:
AI allows you to generate code incredibly fast, but it doesn’t give you memory or safety. I learned the hard way that you can script a solution in minutes, but you can also script a disaster in seconds. Planning isn’t just bureaucracy; it’s the difference between an update and an outage.
The Reverse Card: David Questions me
David turned the tables and used his three questions to challenge my perspective as a Software Engineer on the reality of “Vibe Coding.”
David’s Q1: The Hidden Danger of AI Code
The Question:
“When you look at AI-generated code, where does the real risk lie? Is it in the syntax, the prompter’s lack of knowledge, or security?”
My Answer:
It’s not bugs; it’s verbosity.
AI loves to add useless functions, over-commented fluff, and “hallucinated complexity.” In a 1,000-line file, 500 lines might be garbage. If you don’t clean it up immediately, the AI reads that garbage, thinks it’s important, and weaves it into the next iteration.
If you don’t prune the garden daily, the AI weeds will choke your logic. I run three separate cleanup queries after every generation just to keep the codebase sane.
David’s Q2: The Death of Syntax (Who Owns the Code?)
The Question:
“Do you think ownership shifts from who wrote the code to who can reason about it? If I can’t write it from scratch but I can debug it, am I the owner?”
My Answer:
A resounding YES.
Coding is art. It is about construction. If you can envision the system, structure the logic, and use AI to place the bricks, you are the architect. Syntax is just a barrier to entry that AI has removed.
We discussed how people like Jaime Alvarez (an Account Manager) are now effectively “Senior Engineers.” His curiosity drives him to build tools that would have required a whole team ten years ago.
Spiky Point of View:
I would hire a curious Account Manager who Vibe Codes over a 20-year Python veteran who has lost their drive. The future belongs to the curious, not the syntactically correct.
David’s Q3: How to Vibe Code Without Going Insane
The Question:
“Do you ever get so deep into a Vibe Coding project that, even though you ‘wrote’ it, you lose track of how it works? How do you prevent that?”
My Answer:
I never just “ask the AI to build it.” To keep control, I use a strict, three-tier hierarchy called Systems, Functions, and Actions.
1. Actions (Delegate to AI):
These are atomic tasks. “Fetch this URL,” “Call the OpenAI API,” “Parse this JSON.”
Status: 100% Delegated. AI handles these perfectly because they are isolated and stateless.
2. Functions (Partial Delegation):
A Function is a collection of Actions designed to achieve a specific task, like “Evaluate Competitors.” It takes an input (an idea), calls an Action (Search), calls another Action (Summarize), and returns an output (a Grade).
Status: Watched Closely. I might let AI stitch the Actions together, but I verify the logic.
3. Systems (NEVER Delegate):
A System is the high-level architecture that ties Functions together to achieve a goal (e.g., “The Idea Evaluation Engine”).
Status: Zero Delegation. I never let AI design the System.
The Takeaway:
If you ask an LLM to design a System, it defaults to verbosity. It creates useless connections and builds a “Frankenstein’s Monster” that looks like it works but is impossible to maintain. You must remain the Architect.
Watch the processed 25-minute session here: