My vote is for the learn to code approach.
At the beginning the biggest risk is not writting terrible code you will regreat having written, let alone give maintance. The biggest risk is making something nobody wants.
From my experience, the biggest issue comes after you get enough traction/money/funding to hire a team. This is where things can get really bad, when the founder thinks he actually knows how to solve CS problems, and says things like: "This Machine Learning thing is not that hard: I wrote the landing page for the startup in 3 hours without any programming knowledge".
Hubris is one dangerous trait that will get anyone in trouble. Founders, due to their natural Reality Distortion Field[1], can be a victim of it[2].
Kent Beck, creator the agile methodology XP, discussed some of this in his The Flight of a Startup[3]
[1] http://www.startuplessonslearned.com/2010/09/visionarys-lame...
[2] http://blog.paulbiggar.com/archive/why-we-shut-newstilt-down...
I can't find the link but I also read about Jobs going on a tirade to his employees about some aspect of Objective-C while at Apple.
Another case supporting him as a technical cofounder(although not a programmer) is when he worked at Atari on 'Breakout'. From wikipedia: "The same year, Alcorn assigned Steve Jobs to design a prototype. Jobs was offered US$750, with an extra $100 each time a chip was eliminated from the prospected design. Jobs promised to complete a prototype within four days. Jobs noticed his friend Steve Wozniak—employee of Hewlett-Packard—was capable of producing designs with a small number of chips, and invited him to work on the hardware."
Jobs may not have done the job himself but he was clearly working in a technical position at the time.