#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

1. **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."
2. **Seniority = risk reduction.** The senior's real product is judgment: preventing expensive mistakes and catching dangerous agent actions.
3. **The enterprise-harness market is wide open.** Someone will make money providing compliant, centrally managed AI tooling for large regulated teams.
4. **Relationships are the last non-commoditized asset.** When skill and online presence are equalized by AI, in-person trust becomes the scarce, decisive edge.
5. **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.)
