Guy Podjarny, Snyk and Tessl founder - The future of programming
Snyk and Tessl founder Guy Podjarny makes the case for spec-centric development: software whose durable source of truth is what it must do, while AI-generated code becomes a replaceable implementation.
Guy Podjarny founded developer-security company Snyk after selling Blaze to Akamai. His new company, Tessl, is exploring a more fundamental change to programming than adding a stronger assistant to today’s editor.
Guy maps AI products by the trust and behavior change they demand, explains why specifications could replace code as the canonical artifact, and considers the skills, control and open ecosystem developers will need in that world.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
How should founders map the opportunity for an AI product?
Think on two axes. One runs from attended work to autonomy: how much must a user trust the system before it creates value? The other measures how much the user must change an existing workflow. Low-change, low-trust assistants are easy to adopt because people can inspect each suggestion, but that accessibility also attracts intense competition and leaves existing distributors in a strong position.
Was Snyk an example of winning through low behavior change?
Yes. Snyk treated developer security as a developer-tool problem, integrating into the IDE and delivery pipeline rather than forcing developers into a security team’s workflow. It surfaced a problem in context and made the response easy. Coding assistants follow the same logic when they offer a small completion, test or fix that a developer can quickly inspect before accepting.
Where can an AI DevTool startup build a durable advantage?
An assistant inside an incumbent’s workflow must either develop hard-to-copy technology or gain distribution faster than that incumbent can catch up. Cursor made a bolder move by asking users to change editors, though its VS Code base creates another dependency. More disruptive workflows are slower to adopt because humans must relearn their work, but they can become more defensible once the change takes hold.
What is wrong with code remaining the source of truth?
Code accumulates years of requirements, migrations and accidental decisions, while documentation drifts because nothing forces it to remain current. A new human or model sees the finished house but cannot tell whether a pillar is structural, a curtain is precious or a sofa is arbitrary. Reverse-engineering intent from implementation is lossy, especially after the original decisions and prompts disappear.
What would spec-centric development change?
The canonical artifact would describe desired behavior and the validations that prove it, while generated code becomes disposable. If two implementations satisfy the same spec, a team could choose Python or JavaScript, AWS or GCP, low latency or low cost. The validation boundary also lets a model repair vulnerabilities or regenerate an implementation without silently changing the product’s essential behavior.
What should a software specification look like?
There will be many kinds, just as there are many programming languages. A mobile game, crypto contract, pacemaker and SaaS application need different forms, and composed systems may combine them. A spec could include prose, pseudocode, tests, design constraints or images. The craft is deciding which behavior must remain fixed and where the model has freedom to fill in details.
How can developers debug probabilistic implementation decisions?
The platform must expose which decisions came from the user and which the model inferred. A generated choice such as a red button may be irrelevant at first but should not randomly change during an unrelated edit. Recording those decisions gives humans something to inspect when a bug appears and gives future generations enough context to preserve compatibility while still allowing intentional flexibility.
What skills remain valuable when AI can generate applications?
More people will create software without today’s full development skill set, especially when the novelty lies in data, distribution or a niche rather than deep technology. They still need product judgment and must choose trade-offs such as simplicity versus extensibility. Expert developers will retain greater control over complex systems, while higher leverage raises what users expect and creates new layers of work rather than ending the craft.
Why must AI-native development remain composable?
A magical closed box makes it difficult for a specialist tool to improve one step of a larger process. Tessl wants a platform where testing, documentation, stack optimization and other specialist capabilities can plug into the whole. The methodology is larger than one company, so developers and tool builders need a community that can shape standards and preserve room for an ecosystem rather than a handful of systems that do everything.