"I think there is a real need for a book on actual vibe coding: helping people who are not software developers—and who don’t want to become developers—learn how to use vibe coding techniques safely, effectively and responsibly to solve their problems.
This is a rich, deep topic! Most of the population of the world are never going to learn to code, but thanks to vibe coding tools those people now have a path to building custom software.
Everyone deserves the right to automate tedious things in their lives with a computer. They shouldn’t have to learn programming in order to do that. That is who vibe coding is for. It’s not for people who are software engineers already!
There are so many questions to be answered here. What kind of projects can be built in this way? How can you avoid the traps around security, privacy, reliability and a risk of over-spending? How can you navigate the jagged frontier of things that can be achieved in this way versus things that are completely impossible?
A book for people like that could be a genuine bestseller! But because three authors and the staff of two publishers didn’t read to the end of the tweet we now need to find a new buzzy term for that, despite having the perfect term for it already."
https://simonwillison.net/2025/May/1/not-vibe-coding/
#AI #GenerativeAI #LLMs #Chatbots #SoftwareDevelopment #Programming #VibeCoding
Coding is not the complex part, code is basic logic applied and becoming familiar with documentation - the hard parts of a coding project are not the code but everything surrounding it - collaboration, budget, trust, policies, acceptance criteria, etc
All of those are distinctly human problems and are inherent to any project - coding or not.
In my opinion, as an experienced software engineer who has delivered many projects on both simple and complicated code bases, is that the code is always the easy part, almost the reward to be able to do - once completing/advancing all the other parts of the human problems of a project.
There is no ai that can or should tell you what is acceptable, or how you should collaborate with your friends or partners, or who and how to trust, etc
@[email protected] Tell me about. I'm not a professional developer but more of a technical writer. As someone who has been in charge of reviewing and editing documentation explaining the functional requirements of a moderately complex project, I found it extremely difficult to get both the product and development sides in agreement.
I agree with on where the difficult part is, I think a book would be better served on educating product teams about development and vice versa, of which its a populated field - I think the dichotomy develops from the two different perspectives required for each skill
Product teams most abstract goal is to identify a solvable problem Development teams most abstract goal is to solve an identified problem
And the communication failures and difficulties appear when product teams are not able to communicate their problem, or the development teams do not believe the problem is solvable as is.
^ not to mention to internal team issues such as different product stakeholders not internally agreeing on what the problem is or how its described - or development teams not internally agreeing on their solution and architecture
In this style, there is a natural antagonism which between the two mindsets
There is plenty of literature about how product teams should define problems and determine if they're solvable
There is plenty of literature about how development teams can solve problems and designs
But yet the tensions and difficulties and slowdowns still occur - even on teams where product owners and developers are closely collaborating
I don't think ai will help - even if the dev teams were all regretfully wiped out and it was just product stake holders describing identified problems to an ai hoping for valid solutions, they would be just as slow if not more since those product stakeholders lack the solving perspective and intuition and they lose their collaboration partners who can fill and interpret gaps gracefully.
I do believe that creating things, identifying and solving problems, will always be fundamentally hard and time consuming
People discover this themselves when they try to pick up a side project and realize identifying and describing the problem just to themselves is quite hard, and then transcribing that problem into a solution - with code or not - is equally as hard even if they have a good grasp of whatever technology they're employing
A person armed with ai but no experience in identifying and describing a problem, nor with solving problems - will struggle to inform the ai, will likely identity an unsolvable problem, and will not be able to distinguish an acceptable solution from an invalid one