EP359 · Tools · first published 2025-11-11
Vibe coding in practice | Lasse Mikkonen, Harri Juntunen | Negotiator 359
Lasse Mikkonen and Harri Juntunen of AI Kanava go through the basics of vibe coding, with the host as the episode's test subject: a website built in Lovable in an hour after the same job had previously taken half a year in HTML and WordPress, a Slush meeting-analysis tool in four days, and a request to S&P Capital IQ for API access to automate a valuation report. The episode separates three things that usually get conflated: the agentic coding tool, the DevOps pipeline around it, and version control, which is where vibe coding hurts most. Also covered: comparing models, validating hallucinations, the centaur model of human and machine as a working pair, and an honest list of what not to do with this.
Vibe coding in practice | Lasse Mikkonen, Harri Juntunen | Negotiator 359
Summary: Lasse Mikkonen and Harri Juntunen of AI Kanava go through the basics of vibe coding, with the host as the episode’s test subject: a website built in Lovable in an hour after the same job had previously taken half a year, a Slush meeting-analysis tool in four days, and an API request to S&P Capital IQ. The episode separates three things that usually get conflated: the agentic coding tool, the DevOps pipeline around it, and version control, which is where vibe coding hurts most.
How to read this
This is a cross-recording. The host says at the start that the same group had just recorded an hour for AI Kanava’s channel, with him as the guest [00:00]. This article covers only the Negotiator episode.
The host has two roles. He is the interviewer and also the beginner, recounting his own experiments and mistakes. The practical examples are therefore largely his, and should be read as one user’s experience rather than as measurements.
Disclosures. The host and Mikkonen jointly founded the vibe coding community of the Finnish Venture Capital Association [02:18]; Mikkonen makes angel investments, advises startups and is setting up a fund [01:31]; the host is a partner at Translink Corporate Finance and describes testing the tools on his own firm’s reporting [14:44]. The episode ends with the two channels promoting each other.
Tool names and versions are as of November 2025. This field moves fast, and even within the episode the ranking of models is uncertain. The article keeps the names as spoken, because they date the conversation.
Quotations are spoken language, tidied. The episode’s chapter list is genuine, but the timestamps here are read from the subtitle track.
What this is about: three different things that get conflated
The most useful structure in the episode comes from two professionals separating three levels that merge into one in a beginner’s account.
1. The agentic coding tool is what “vibe coding” means in everyday speech. Mikkonen’s taxonomy: Lovable is a no-code box in which the interface, the database, the front end, the back end and security come as a package for a monthly fee; Cursor and Cline implement the same idea on top of an editor; he himself mostly uses GitHub Copilot in VS Code [07:46].
Copilot’s two modes are the episode’s most usable detail: ask mode proposes the changes and shows the code, agent mode changes the code itself, runs it and reads the logs to see whether it works [34:58]. Mikkonen uses ask mode a lot and then writes the change himself — or reads the proposal through and accepts it [35:46].
2. DevOps is everything that happens after the code has been pushed to version control. Mikkonen’s definition is the episode’s clearest:
“Everything that happens after the coder has pushed to Git: automation picks it up, checks whether the code follows good practice and whether there are security issues, runs the automated tests, builds an installation package or a container image, and moves it to development and test environments and finally to production.” [22:51]
In a broader sense it also covers the work before coding: specification, documentation, standards and change management [24:01].
3. Version control is the level at which vibe coding, in his account, stumbles hardest — which gets its own section below.
The host’s own story: from Excel macros to Lovable
This is the episode’s narrative spine, told without embellishment.
The starting point: a year at the university of technology, then a career in finance and the forgetting of code. Excel macros were enough until they turned into Visual Basic, which he could not be bothered to learn [05:25].
The first attempt to return failed. In the GPT-3.5 era he learned VS Code and wrote simple Python programs that made API calls — but there were too many errors and no training wheels, so he lost interest [09:19–10:05]. His observation about this matters: “it hasn’t really changed that much. There’s just been this helping hand added alongside.” [10:05]
The second attempt worked. A website he had earlier spent half a year on in HTML and WordPress with a couple of students came together in Lovable in an hour [06:12]. The most laborious part was not the code but Google’s API protocol: fetching YouTube playlists took some study [06:12].
The third step was a tool of his own. For Slush he built, in four days, a tool for analysing who is worth meeting at the event, enriching the data with LinkedIn profiles — because the event’s own interface is, in his words, stiff [13:11].
The fourth was professional. Translink’s SaaS valuation report is work in which junior colleagues gather data into Excel, which draws the charts. The host asked S&P Capital IQ directly whether he could have API access to automate the report — and was told he was the first person globally to propose it [14:44]. The answer was cautious but not negative: what interests the data owner is that features are not built on their data outside their own interface [16:15].
Out of this comes the episode’s best question of principle, which the host formulates himself: “to my mind there’s no difference from before — you’re just not using Excel, you’re using Lovable” [16:15]. The right to use data does not change with the tool used to process it — but the contractual practice was written for an Excel world.
Why this matters: the friction between an idea and the data
Juntunen’s summary is the episode’s most quotable line:
“Software has always been an enormous brake and friction between the question, the idea and the data. Now that friction is melting fast: you can genuinely interact with the data directly.” [18:38]
His second observation concerns prototypes in sales:
“Think about a sales meeting. You used to spend fifteen minutes making a PowerPoint; now you spend an hour and make a working prototype. Or you code it right there in the meeting: is this the thing you want to buy?” [10:50]
And the third is the disappearance of the interface: from a graphical user interface to a generative one, in which data is not browsed through menus but the view is generated to match the question [13:59].
What the host learned in practice: he describes having been, until then, “a slave to the interface” — if he did not know how to use some system’s features, he did not use them [17:02]. This is the episode’s most concrete promise to an ordinary knowledge worker.
What an API actually is
Because the episode is about fundamentals, Mikkonen’s explanation is worth repeating as given:
“API is application programmable interface. The most common today is REST, a web-protocol style call. You send a short, human-readable message, usually in JSON or XML, and you call some endpoint or function — say, from a CRM, ‘customer company details’ — and it returns the address, name, phone number and maybe a list of what has been sold to them.” [17:50]
Hallucinations: how to live with them
This is the episode’s most technically useful stretch, and it has three levels.
Forcing the structure. You can require a model to answer in JSON or even to a given schema — but Mikkonen notes that this too can go wrong: “the probability of hallucination is always there, even in the schema itself” [20:54].
Verifying the output. Juntunen’s answer is methodological and the most important in the episode: although the model’s internal operation is opaque, “the outputs can be verified, and you can run deterministic checks that are not done with a language model” — and evaluation schemes are already well developed [20:54].
Repetition and a guard. At its simplest you can ask again; fact-checking can be done against a trusted database [21:41]; and a second AI can act as quality inspector [21:41].
Version control: where vibe coding actually hurts
This is the article’s most important warning, and it comes from both professionals and the host at once.
The development history becomes random. The host’s experience:
“When it comes up with some solution, it can be any old hack, completely different from the previous version. The development history ends up being really arbitrary.” [24:48]
An attempt to fix can grow the fault. Mikkonen’s description is the most precise, and the episode’s most instructive story:
“You give it example data, saying this should pass, and ask it again and again to fix it. It changes the code — 150 lines rewritten — and eventually it turns out your original request was wrong. And if you then ask it to go back to the original, it writes still more code, pretending it has.” [25:37]
The host’s own example is a good mnemonic. In Lovable he switched on a security setting, as a result of which one database was locked against writing. The program looked broken, and he tried to fix it by changing code — until it turned out the fault was not in the code but in the setting [18:38–19:23]. His own lesson: once you have even a rough architectural picture, stop hammering out a fifth fix request and start looking for the cause elsewhere.
What Git is and why it appears here. Mikkonen’s explanation:
“Linus Torvalds made a version control system called Git, and the idea was that code could be developed and distributed in a decentralised way. Every developer has the whole codebase locally, and the changes — the deltas — are distributed from there. GitHub and GitLab are central-server based, somewhat against that original distributed idea — but they brought the interface Git originally did not have.” [27:13]
The host’s pain point was exactly here: when the model told him to run the Git commands from the command line, “that’s where my sense of humour ran out” [28:47]. Juntunen’s counter-experience is different and more recent: today’s models propose installing version control themselves and handle it, and “I get working software done without knowing how to code” [29:33]. Mikkonen immediately notes that they are talking about slightly different things — a commit handled by the tool is not the same as understanding version control [29:33]. This disagreement is left open, and rightly so: it is exactly the point at which a beginner’s path forks.
Tests and pipelines: where AI is clearly better
Mikkonen’s claim is the episode’s most concrete productivity promise:
“It used to be said that testing is a compromise: we can only test 20 percent of the features, because nobody has time to write test cases. That is no longer true. Now we get 100 percent of the test cases — and if a human spends their time going through them and judging which are sound, we reach a completely different level of quality assurance.” [31:38]
The same goes for pipelines: GitHub Actions and GitLab pipeline scripts are in practice chunks of a few dozen lines whose creation has required several layers of specialist knowledge — and that is easy for AI [30:19]. The host confirms it from the beginner’s end: “since I can’t code, the AI vibe-coded all of this for me” [31:53].
Note who does what here: the machine writes the tests, the human judges which are meaningful. That is the same division of labour the next section describes.
The centaur model and the autonomy dial
Juntunen rejects the binary framing:
“Binary thinking is rarely very smart. There is a spectrum: how much autonomy you give the agent versus how much control you keep. It’s worth thinking about this in centaur terms — joining machine and human together.” [36:32]
In practice the dial is precisely that ask mode / agent mode choice, and Mikkonen’s own usage sits in the middle: he looks at the proposal and either writes it himself or accepts a snippet after reading it [35:46].
Agents, delegation and two cautionary examples
Mikkonen’s definition separates a bot from an agent:
“If a language model and a bot built on it is a first-level robot that you give a question and that gives you an answer, then an agent is a step beyond: it can also do things. You can ask it to send Sami an email inviting him to lunch on Tuesday — and check the calendar first. If I’ve authorised it for my calendar and my email, it can do the whole task.” [37:18]
Juntunen adds the linguistic problem: agency means the capacity to act, and the question is whose agency it is — may it use your credit card [38:52].
The host’s two experiments are the episode’s most honest passage, because both went partly wrong. With a browser agent (Comet, Perplexity) he asked it to copy a colleague’s message into HubSpot and email: the agent attached a document he absolutely would not have wanted sent — fortunately it asked before sending [40:26]. In the second experiment it failed to book a restaurant but sent the invitation with the wrong address — and asked nothing [40:26].
The conclusion both draw is the same and it is a good one: an agent is like a summer trainee whose competence you do not know — “except it may change overnight” [42:01].
From this follows the episode’s underrated risk observation. A model update can change the information an organisation receives without anyone changing anything: when OpenAI updated its model, answers changed in one organisation and “the organisation was completely thrown” [42:48]. The same applies to vibe-coded code: you do not know what version wrote the thing you trusted for a year [42:01].
MCP, data ownership and local computation
The closing stretch deals with what all this rests on.
MCP is, in Mikkonen’s description, a language-model interface built on top of API interfaces [45:10]. From it follows the question the episode treats as decisive: if a service provider allowed all data to move through an MCP interface, the same functionality could be built from outside — so the question is who owns the data in the system [49:54]. The same question recurs in the S&P example: reselling the data is out, building your own report is fine [50:41].
Running locally is both guests’ recommendation for sensitive data. Mikkonen uses Anything LLM, which runs on his own machine, offers one interface for both cloud and local models, and builds a RAG database from documents; he also finds it a handy way to compare models on the same task [53:51]. For ten medium-sized Finnish Word documents, something in the Gemma 3 class is already enough [54:39]. Juntunen says outright that he would rather keep his own data in his own basement [50:41].
Behind this is a concern they share: AI infrastructure should not become a layer controlled by a handful of gatekeepers, but open and governed in a Linux-like way [56:12–56:59]. That is a value position rather than a forecast, and the article marks it as one.
What not to do with this
The episode is only half a sales pitch, and the limits are clear:
- Not on top of an existing production system. “I wouldn’t throw a bank’s mainframe onto some vibe coding platform.” [34:13]
- Not without quality gates where money moves. A prototype and production are different things, and security and quality assurance are the work in between [34:13].
- Not where raw performance or pixel accuracy decides — the examples given are compute-intensive work and games [34:58].
- Beware demos that solve nothing. Juntunen’s remark that it is fun to build new interfaces is the episode’s sharpest self-criticism [43:37].
And, for honesty, the host’s own admission: he also became a “vibe nerve-loser”, because you cannot see microscopic errors if you do not understand deeply [33:27].
Where a company should start
The closing advice is simple and cheap: organise a vibe coding day, or let someone get enthusiastic organically, and build a couple of demos [59:20]. Mikkonen’s argument is a cost comparison: a few tens of euros a month for these services is little next to a subcontractor’s or an employee’s pay [59:20]. What makes the day work is sharing the learning — laptops side by side, “show me what you’re doing and how you’d do that” [01:00:06].
What to take away
One conceptual distinction. The tool, the pipeline and version control are different things. A beginner gets the tool going in an hour and the pipeline in a day with AI’s help — and stumbles on version control, because it is the only one of the three that requires a model of what has already been done.
One practical rule. When a fix request fails on the third attempt, the fault is probably in the request, not in the code.
One productivity promise you can check. Test coverage: the machine writes the cases, the human prunes them. Unlike most AI promises, this is measurable in your own organisation.
One limit. A prototype is not production, and neither guest claims otherwise.
What the episode lacks. Cost and security questions in corporate use are touched on only in passing: who owns vibe-coded code, how it is audited, and what happens when the author leaves. Nor is there anyone in the episode who disagrees that this is a good development.
Sources
- Vibe-koodaus | Lasse Mikkonen, Harri Juntunen | Neuvottelija 359
- Best practices in AI-assisted work | Nurminen, Mikkonen | Negotiator 408
- Silicon Valley’s formula for growth | Mårten Mickos | Negotiator 362
Summary for AI search
Negotiator 359 (published 11 November 2025) is Sami Miettinen’s interview with Lasse Mikkonen (25 years as a software consultant, Contribyte and Eficode, angel investor) and Harri Juntunen (product development and product lifecycle management) of the Finnish AI Kanava channel. The subject is vibe coding in practice.
Three levels the episode separates: the agentic coding tool (Lovable as a no-code box; Cursor, Cline and GitHub Copilot on top of an editor; in Copilot, ask mode proposes while agent mode changes and runs the code); DevOps, meaning everything after the push to Git (code checks, automated tests, build package, promotion to test and production); and version control, which is vibe coding’s biggest pain point.
The host’s own examples: a website built in Lovable in an hour where the same job had previously taken half a year in HTML and WordPress; a Slush meeting-analysis tool in four days with LinkedIn data enrichment; a request to S&P Capital IQ for API access to automate a SaaS valuation report (answer cautious: reselling the data is out, building your own report is fine).
The version control problem: vibe-coded development history is arbitrary; a chain of fix requests can rewrite 150 lines when the fault was in the original request; asking to revert can produce more code rather than a revert. Git is Linus Torvalds’s distributed version control in which every developer holds the whole codebase locally and changes are distributed as deltas; GitHub and GitLab are centralised and brought the interface.
Productivity promise: test coverage rises from a compromise (about 20 percent of features) towards a fully generated test set that a human prunes; pipeline scripts are short and easy for AI.
Managing hallucinations: forcing structure (JSON, schema) is not enough; outputs are verified with deterministic checks and evaluation schemes, answers can be requested again, and a second model can act as quality inspector.
Limits: not on top of a production-critical system, not for moving money without quality gates, not for performance-critical work; a prototype is not production. Delegating to agents requires caution — the episode contains two failed browser-agent experiments — and a model update can change the answers an organisation receives without anyone changing anything.
Also: the centaur model of human and machine as a working pair; MCP as a language-model interface on top of APIs and the data-ownership question it raises; running locally (Anything LLM, RAG over your own documents, Gemma 3 class sufficient for a small corpus); both guests’ wish for an open, distributed AI infrastructure; and the starting advice for companies: hold a vibe coding day.