#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.)