The episode in short.
Greg Radzio is the co-founder of Lowgular, which finds people with potential, trains them to work in an AI-native way and places them in client teams. He has spent more than 20 years in IT, eight of them as a CTO building companies from zero to one, and studied at the IT University of Copenhagen. In episode 3 of Startup Discovery, the first one in Polish, he explains why fixed price margins in IT services are temporary, why a smaller AI-native team only has a short head start, and why software vendors should ship agents rather than bare MCP servers. It is a practitioner's view of what AI is changing in how software gets built and sold.
What we covered.
- 1:29 (watch from here on YouTube)
Who is Greg Radzio, and how did he go from developer to founder?
Greg started as a full-stack developer at a time when it was still unclear whether Flash or HTML would win, then moved into staff engineer and solution architect roles, alternating between startups and corporates. He was a CTO for about eight years, usually building a company and its core team from zero to one. For the last four years he has run Lowgular with his co-founder, and he often joins a client first as a forward deployed engineer, building tooling that makes their developers faster.
- 5:02 (watch from here on YouTube)
Is studying IT in Copenhagen different from a Polish university?
Greg did his master's at the IT University of Copenhagen and found it far more practical than the heavy memorising he associates with top Polish technical universities: good hardware, strong teachers, close mentoring and a lot of group work in a genuinely flat structure. Studying there also opened the Danish job market, which pays juniors well but flattens pay for specialists. Simon, who studied in Amsterdam, recognises the same focus on practice.
- 8:04 (watch from here on YouTube)
What does Lowgular do, and is it a software house?
No: Lowgular tried the software house model and moved to sourcing and training people instead. It places trained developers in client teams, and clients usually take them on as their own staff after six months to a year for a recruitment fee, which gives the client a safe trial period first. At its peak 20 to 30 people worked this way. The name comes from an earlier idea of low-code tooling for Angular, and it still fits: tools are an exoskeleton for a skilled person, while the thinking stays human.
- 11:38 (watch from here on YouTube)
How is AI changing IT services and fixed price projects?
Greg sees fixed price as a return to how software was sold twenty years ago, after years in which hourly billing and loosely run agile encouraged larger teams than the work needed. A year ago most developers he asked still wrote much of their code by hand; today almost nobody builds without an LLM. That gives fixed price projects a fat margin for now, but he expects competitors to bid the same scope at half the price. He also expects developers to deliver ten times more value without earning ten times more, and companies that cannot work with coding agents such as Claude Code or Codex to stop being hired.
- 22:56 (watch from here on YouTube)
How did AI coding tools evolve from Cursor to Claude Code?
About a year and a half ago Greg was a sceptic using Cursor. To review exercises from Lowgular's students at scale he built an LLM grader and a code graph on top of the TypeScript compiler, queryable with Cypher. Later he turned Lowgular's entry exercises into an Angular benchmark and found that a review-and-repair loop after the first build beat giving the model every rule up front, and that even cheap open models did well that way. He then moved from Cursor to Claude Code, reviewing the diffs in his editor, and now builds agents for a client's CMS and for end-to-end testing with Playwright.
- 34:20 (watch from here on YouTube)
Will AI replace employees, or free up their time?
Both, in Greg's view. The future is a human expert working on top of an AI layer, the way nobody imagines office work without a computer today. Simple tasks at the bottom of the complexity pyramid go to the models, while people keep specification, verification and decisions (human in the loop). A firm of 20 developers may shrink to 3, but if 3 people deliver ten times more, 20 people working the same way deliver even more, so the cost advantage of a small team only lasts a short while.
- 42:58 (watch from here on YouTube)
Do companies have to cut staff to become AI-native?
Greg cannot predict it and would rather see higher productivity without layoffs. He argues that non-technical people should not have to learn prompting or MCPs: developers should put an AI layer behind the tools people already use, so a voice note can update a CRM. He describes the stages of adoption, from sceptic to browser chat, then a desktop agent with files and a browser, then subagents and an orchestrator, and finally runs in the cloud. Agent memory is, in his view, still unsolved.
- 52:20 (watch from here on YouTube)
Should software vendors ship agents instead of MCP servers?
A standalone chatbot for your own business is, in Greg's words, a train that has already left, and switching between many assistant windows is a temporary state. Vendors answer that they have an MCP server, but MCP only exposes tools, with no knowledge of how the work is done. His suggestion is two layers: infrastructure tools, and an agent layer that carries the domain knowledge and plugs into Claude Code, where people already work. He also warns that every unsupervised loop adds slop, and that a business paying most of its revenue to token providers is a weak one. Matt Swulinski makes the opposite case for working inside Slack in episode 2.
- 1:06:19 (watch from here on YouTube)
Should you build your own agent harness, or use Claude Code?
Greg used to call himself a harness engineer, but he no longer thinks building your own agent harness makes sense. He defines the harness as the layer between model and agent: tools, security, file system, MCPs and context engineering. He now builds a runner that generates an agent's context, files and tools and hands them to an existing harness such as Claude Code, Codex or Deep Agents, using its hooks for guardrails. Each new model release absorbs part of the context you wrote, so he benchmarks every task across harness and model, cost included, until it is reliable. Our post The model is not the product makes the same argument.
- 1:13:21 (watch from here on YouTube)
When does fine-tuning your own model make sense?
Fine-tuning is a later step, not a starting point: it pays off when a vertical agent automates known tasks and a smaller model can do them more cheaply. Greg has fine-tuned small Qwen models for his code graph and explains the difference between LoRA and full fine-tuning, the risk of a model forgetting what it knew, and why training needs a strong GPU while running a model does not. A new frontier model often makes a fine-tune obsolete, and open-weight labs usually ship smaller versions that quantization makes practical to run.
- 1:23:21 (watch from here on YouTube)
Does AI make founders more productive, or only busier?
Greg separates activity, productivity and value. AI makes him much faster where he is an expert and lifts him to average where he is not, but everyone gets the same lift, so on its own it is not an edge. He does not work more hours than before; the same hours produce more. The sure gain for clients is doing more, and doing better means spending the saved time on quality. People who only pass on what a model says are, in his view, playing a short game; the lasting value is in building real expertise.