15 KiB
#ai #interview #development #webinar
Sebastian Interview — Conclusions & Insights
Participants: Sebastian (founder of Virtido, a ~11-year-old software outsourcing/engineering company) and Eugene (the interviewer — a computer-vision & embedded/firmware developer, content creator, and builder of his own AI "harness"). Length: ~56 minutes · Topic: How AI is reshaping software engineering — teams, tooling, careers, enterprise reality, and business development. Context: Appears to be a pre-webinar conversation. Casual, candid, two practitioners comparing notes.
Sourcing note: Built from an automatically generated (Whisper large-v3) and speaker-diarized transcript. Quotes are lightly cleaned for readability and obvious speech-to-text errors are corrected (e.g. "Claude Code," "COBOL," "RAG," "Virtido"). A few rapid-crosstalk moments may be mis-attributed.
Executive Summary
The debate is over whether AI can write software — it can. The whole game is now how you use it. That single shift cascades into everything else in the interview:
- Teams shrink and roles merge. The 8-person scrum team collapses to 2–3 people who share coordination and agent-wrangling.
- Tooling becomes personal ("bring your own harness") — except where it can't. Individual developers get maximum leverage from custom harnesses on top of Claude Code; regulated enterprises can't allow that, which creates a real business opportunity.
- The value of pure coding skill collapses; the value of judgment, ownership, and relationships rises. Claude "levels" a 20-year veteran and a fresh grad to similar output — so the differentiator moves to understanding problems and, above all, human connection.
- The durable human skills are product ownership and real-world networking. These are the two things AI doesn't commoditize.
Who's Who
| Sebastian (SPEAKER_01) | Eugene (SPEAKER_00) | |
|---|---|---|
| Role | Founder/owner of Virtido, a software outsourcing company | Hands-on developer & content creator; the interviewer |
| Vantage point | Running a services business, client/compliance/sales lens | Building tooling, embedded/firmware & computer vision, individual-leverage lens |
| Signature stance | "Bring-your-own-harness won't survive enterprise; connections win business" | "Build your own harness; get closer to the client's real problem" |
| Notable work | 11 yrs in business, 10–15 engineers on big teams, enterprise clients | Custom Claude-Code harness, projects like insin (apt-get-style edge updater) & Keller |
Key Themes & Insights
1. The question changed: not "can AI code?" but "how do you use it?"
The cost of writing code trends toward zero, so the leverage moves entirely to how AI is directed.
"It's not a question if AI can write software anymore — it's just a question of how you use it."
2. Team structure collapses from ~8 people to 2–3
No more scrum master + PM + requirements engineer + a big dev team. Instead: one coordination/ownership role plus one or two people managing coding agents, sharing responsibilities.
"Teams will be two or three people and they will share these roles… one person with a coordination role and one or two who manage the coding agents. That's it."
3. "Bring your own harness" — but it hits a wall in the enterprise
Eugene's thesis (echoed by many practitioners he cites): every developer should build a personal harness on top of Claude Code because knowing every detail makes it far more effective. He demoed his own: a Telegram-like UI with one agent per project, inter-agent messaging, per-agent memory, and a "done thinking" signal so you don't babysit the console. Tools referenced: Conductor (isolates a git worktree per chat, automates PRs/merges), plus "open clock, Hermes, paperclip."
Sebastian's crucial counterpoint: this does not scale to large or regulated organizations. Compliance and liability make ad-hoc, per-developer setups impossible.
"From a compliance perspective I can guarantee you that bring-your-own-harness will not be the way forward… it has to be a company-managed resource. We cannot let everyone pick their own setup."
→ Business opportunity identified: scalable, manageable, company-standard harnesses for larger engineering teams. Sebastian explicitly frames this as "the interesting market."
4. Enterprise reality is far more locked-down than the indie world
Sebastian's biggest clients: engineers can't use their own laptops — only a centrally managed VM, zero ability to install their own tools. Reference points: a Roche SAP transformation ran ~1,200 engineers for years; banks first banned AI outright and are now cautiously adopting it "because it's just so good."
5. Seniors are now more valuable; juniors are being squeezed out
Counter-intuitively, AI has raised demand for seniors and made juniors "completely irrelevant" in the market, even though a junior + Claude could in theory produce the same output.
- Why seniors win: 20 years of experience = knowing where things typically go wrong, so you don't let the AI make those mistakes. "AI does the same mistakes humans do because it's trained on our mistakes."
- The junior risk (a security argument): the habit of clicking "yes… yes… allow for all future" is how "API keys are leaked, databases get dumped or deleted." A junior can't evaluate a 250-line bash script; a senior at least could.
"Give a junior fresh out of university access to this almighty Claude and then access to the codebase — they will [wreck] it in two days."
6. Ownership & product thinking is the durable human skill
The recurring "profile picture" story: an engineer implemented "change your photo," ticked every acceptance criterion, but shipped it ugly (visible in the corner) because they never looked at the actual result. That's the absence of ownership.
- Ownership = putting yourself in the user's/customer's shoes and understanding what they'll expect — a mindset/personality trait, not a task list.
- Reframe the work: stop thinking "what needs to be done" (tickets); start thinking "what problem needs to be solved."
"No one ever needed a programmer… people have problems that you are solving."
- AI forces the issue: if you don't understand what to build, "you will simply not be an engineer anymore" — or you get closer to the product and the software gets better (product-wise, if not always technically).
7. The planning/waterfall debate: coordination overhead can exceed the work
A colleague (Daniel) floated returning to waterfall. Sebastian disagrees — with AI, "we don't have time for planning." Concrete evidence:
- On a small two-person project (each ~1 day/week), Sebastian is faster alone: the effort to synchronize who-does-what and how-it-integrates exceeds the speed of just prompting it himself.
- Printer anecdote: a new printer had to work in 2 days via an unfamiliar direct-printing protocol in Java (which he'd never written). Explaining it to a remote engineer wouldn't have made the deadline; he went on-site and Claude Code solved it in ~30 minutes. His edge wasn't coding — it was knowing how to instruct and verify the result.
8. Connections are everything — the standout insight
Eugene's core unsolved problem (stuck ~6 months): how to build a professional network. The framing that lands:
- Claude levels pure programming skill. 20 years of experience vs. a fresh grad, same Claude subscription → similar output. The only real differentiator becomes the ability to communicate with clients and understand their problems.
- Real, in-person connection is the one thing AI can't commoditize — and it gets more valuable as AI floods everything else. Soon you won't be able to tell bots from humans on LinkedIn, or even on a phone call. "In 10 years… zero" ability to tell.
- What actually works for winning business: showing up in person 2–4 days/week (business lunches, networking events, conferences, open days). What doesn't: sales agencies, cold calling, email marketing, LinkedIn campaigns, content, SEO — "Big zero." Every real long-term customer came through personal network.
"The only way to get a real connection is to stand face to face in the same room with someone, shake their hand, and have a conversation."
- Mechanics of a connection: it forms not on the first meeting but when you meet the same person in different circumstances → recognition value → trust → referrals. ("Oh, there's this guy, Eugene — I met him a couple of times, he's real, I trust him.")
- Be memorable in your humanness: lead with something human (renovating a house, two kids, a cat, a dog) — not "I run a software company," which everyone forgets. Because everyone now uses the same AI tools, everything online looks identical; humanity is the differentiator. (Virtido's playful
humans.verti.com/ "human badge on LinkedIn" is a riff on exactly this.)
9. Decouple identity from profession (the philosophical turn)
Older generations tie identity to their job ("I am a doctor"). As many professions collapse into "prompt the AI," they'll lose obvious societal value. The advice: learn to separate who you are from what you do professionally, or "we will feel worthless in a couple of years."
"Fundamentally I'm Eugene — I'm not a programmer. But I need to work on that."
10. AI's value extends well beyond programmers
Non-technical, high-leverage uses discussed: profile ~2,000 LinkedIn/HR contacts into Obsidian, build RAG/search over your own collected information, spot who's hiring and pitch as a contractor. "You can put your whole life into a RAG." You don't need to be a programmer to benefit.
11. Two smaller-but-sharp side points
- Open source will grow because of AI. When writing code costs ~nothing and most code isn't high-value, people will give it away. (Eugene's more cynical read: OSS is largely marketing; every OSS dev cites The Cathedral and the Bazaar.)
- Legacy/hobby niches persist. A few holdouts survive (e.g., COBOL engineers in banks — no training data for AI), plus people who code for the love of it "like driving an old-timer car" — but not where time, quality, and money matter.
- On outsourcing economics (opening exchange): great engineers exist everywhere (India has as many as Ukraine/Russia); the problem is that a low-cost expectation selects for bad code. Pay $10k/month and you get excellent people; an $800/month hire won't beat a good, well-paid engineer.
Points of Tension / Disagreement
- Personal vs. company-managed harness: Eugene champions bring-your-own; Sebastian says compliance kills it at scale (and that gap is the business).
- Planning: Daniel (absent) wants waterfall back; Sebastian says coordination overhead now outweighs the work itself.
- Open source motivation: Eugene sees it mostly as marketing/"gambling for questionable results"; Sebastian expects more OSS as code becomes nearly free to produce.
- Networking channels: Eugene is invested in LinkedIn/articles; Sebastian bluntly calls online outreach a "waste of time" versus in-person.
Standout Conclusions
- Move up the value chain — from writing code to owning outcomes. The engineer's job is shifting from "produce the solution" to "understand and frame the problem, then direct and verify the AI."
- Seniority = risk reduction. The senior's real product is judgment: preventing expensive mistakes and catching dangerous agent actions.
- The enterprise-harness market is wide open. Someone will make money providing compliant, centrally managed AI tooling for large regulated teams.
- Relationships are the last non-commoditized asset. When skill and online presence are equalized by AI, in-person trust becomes the scarce, decisive edge.
- Protect your identity. Tie your sense of self to who you are, not a job title that AI may hollow out.
Memorable Quotes
- "It's not a question if AI can write software anymore — it's just a question of how you use it."
- "No one ever needed a programmer… people have problems that you are solving."
- "Give a junior… access to this almighty Claude and then access to the codebase — they will [wreck] it in two days."
- "The only way to get a real connection is to stand face to face in the same room with someone, shake their hand, and have a conversation."
- "We tried sales agencies, cold calling, email marketing, LinkedIn campaigns, content, SEO. Zero. Big zero… Every real long-term customer has come through [personal network]."
- "We need to learn to decouple our identity from the thing we do professionally."
Actionable Takeaways
For Eugene (his stated problem — building a network):
- Reallocate time from LinkedIn posts/articles to recurring in-person events (aim for the same circles repeatedly to build recognition value).
- Prepare a memorable, human self-introduction that isn't your job description.
- Treat the network as the moat, not the code — the coding is already commoditized.
For engineers generally:
- Practice product ownership: always look at the actual result a user sees, not just the acceptance criteria.
- Shift vocabulary from "tasks/tickets" to "problems and desired outcomes."
- Build (or learn) a harness for personal leverage — but expect a company-standard one at any regulated employer.
- Read what you approve. Don't reflexively "allow all"; that habit is a security incident waiting to happen.
For businesses / founders:
- The compliant enterprise-harness space is an underserved market.
- Assume digital outreach converges to noise; invest in face-to-face relationship-building as the durable channel.
Open Questions Raised (Unresolved in the Interview)
- How does AI actually transform huge enterprise programs (the ~1,200-engineer, multi-year kind)? Sebastian is candid that he doesn't know.
- How do you unify wildly different personal workflows into one company process? (Eugene and his collaborator spent a month and couldn't.)
- Concretely, how does an individual engineer build a connections network from a standing start? (Sebastian offers principles; the step-by-step remains open.)