Module 5: Q&A Discussion Board

3 unread replies. 3 replies.

Use this Q&A discussion board to share your insights and post your questions as you engage with the material from this module. Feel free to engage in a healthy discussion with your peers.

It is not mandatory to participate in this discussion and there is no grade associated with it.

To make this most useful for all participants:

Bookmark this page and return to it often during this module.
Search for your topic first (use the search box below).
If someone has asked a similar question, respond to that particular thread to keep the conversation contained. This will allow your fellow classmates to spot specific topics more easily and offer their insights.
Create a new thread if your question has not been addressed.
Start your post with a brief subject statement that specifies the topic or problem.

Examples:

Assignment 1.2, Question 3
Installing X issue
Sharing an interesting article about X

Post questions and topics related to this module’s content and be as specific as possible when referring to programme content or learning activities.

Example: In Video 3 at 4:10

Reply! Share your thoughts and insights.

Reply to Module 5: Q&A Discussion Board

Collapse Subdiscussion Edoardo Bertolani
Edoardo Bertolani

Local: Aug 6 at 12:50pm<br>Course: Aug 6 at 2:20pm

Coming from banking, I realised we already trust APIs every day for payments, foreign exchange, credit cards and account information. What AI changes is not the API itself but the ability to orchestrate many APIs together autonomously.

Manage Discussion Entry

Go To Topic
Coming from banking, I realised we already trust APIs every day for payments, foreign exchange, credit cards and account information. What AI changes is not the API itself but the ability to orchestrate many APIs together autonomously.

Reply to Comment (2 likes)
Attach

Cancel
Collapse Subdiscussion Geoff Tan
Geoff Tan

Local: Aug 7 at 10:08pm<br>Course: Aug 7 at 11:38pm

Vibe Coding: Building Beyond the Pain Point I believe building apps through vibe coding depends significantly on how we frame and articulate the requirements. The choice of words, prompts, and instructions can influence the outcome considerably. However, identifying the pain point, APIs, API keys, and technical requirements are only part of the equation. The underlying architecture and technical approach are equally important. More importantly, the actual user need and market demand ultimately determine whether the application has real value. In other words, being able to build an app is one thing; building the right app for the right need and the right market is another.

Manage Discussion Entry

Go To Topic
Vibe Coding: Building Beyond the Pain Point

I believe building apps through vibe coding depends significantly on how we frame and articulate the requirements. The choice of words, prompts, and instructions can influence the outcome considerably.

However, identifying the pain point, APIs, API keys, and technical requirements are only part of the equation. The underlying architecture and technical approach are equally important. More importantly, the actual user need and market demand ultimately determine whether the application has real value.

In other words, being able to build an app is one thing; building the right app for the right need and the right market is another.

Reply to Comment
Attach

Cancel
- Collapse Subdiscussion Davide Silva
  
  Davide Silva
  
  Local: Aug 8 at 2:57am<br>Course: Aug 8 at 4:27am
  
  Thank you Geoff for your comment, especially the last sentence, which makes a nice hook for my comment. You refer to "build it right" concept which makes me remember a book I red few years ago, named "Build the right it" (The Right It - ALBERTO SAVOIA), written by a former Google engineer. The book title summarizes the main point: before building something in the right way, it is important to build the "right it"; in other words, before investing a lot of capital and energy in building something, it would be advisible to double-check that what we want to build is the right "it", the right "one", the one for which people are willing to pay. Thus he invented the topic of "pretotype" (no typo, it's really pr"e"totype) where the suffix "pre-" explains what he means: a "pretotype" comes before the usual "prototype", it has to be as cheap and as basic as possible, to test whether people would be interested in buying it. In case of positive feedback, it would be worth to move to the prototype and then, in case of positive feedback, go full throttle with the initiative. And this is the context where I see vibecoding a lot. It's a fast and cheap way to build "pretotypes" of more complex web sites, web/mobile apps or IT applications. It helps business people (and IT people too) in focusing business ideas and potential solutions much better and in faster ways than in the past. Thus it facilitates requirements definition and following submission to fully-fledged IT departments for agile or waterfall developments. In other words, vibecoding mainly is -so not exclusively - a fast prototyping tool. To make the conversation a bit spicy ... so I do not understand WHY so many people are saying IT developers are not required anymore. If vibecoding doesn't (yet) build enterprise-grade systems, we still need full IT departments with solution architects, developers, testers, application managers, and so on so forth
  
  Manage Discussion Entry
  
  Go To Parent
  
  Thank you Geoff for your comment, especially the last sentence, which makes a nice hook for my comment.
  
  You refer to "build it right" concept which makes me remember a book I red few years ago, named "Build the right it" (The Right It - ALBERTO SAVOIA Links to an external site.), written by a former Google engineer. The book title summarizes the main point: before building something in the right way, it is important to build the "right it"; in other words, before investing a lot of capital and energy in building something, it would be advisible to double-check that what we want to build is the right "it", the right "one", the one for which people are willing to pay. Thus he invented the topic of "pretotype" (no typo, it's really pr"e"totype) where the suffix "pre-" explains what he means: a "pretotype" comes before the usual "prototype", it has to be as cheap and as basic as possible, to test whether people would be interested in buying it. In case of positive feedback, it would be worth to move to the prototype and then, in case of positive feedback, go full throttle with the initiative.
  
  And this is the context where I see vibecoding a lot. It's a fast and cheap way to build "pretotypes" of more complex web sites, web/mobile apps or IT applications. It helps business people (and IT people too) in focusing business ideas and potential solutions much better and in faster ways than in the past. Thus it facilitates requirements definition and following submission to fully-fledged IT departments for agile or waterfall developments. In other words, vibecoding mainly is -so not exclusively - a fast prototyping tool.
  
  To make the conversation a bit spicy ... so I do not understand WHY so many people are saying IT developers are not required anymore. If vibecoding doesn't (yet) build enterprise-grade systems, we still need full IT departments with solution architects, developers, testers, application managers, and so on so forth
  
  Reply to Comment
  Attach
  
  Cancel