Our experience as techs will always be helpful to knowing what to ask and how to structure the questions.
Yep. It's the living embodiment of this quote, which has been a favorite of mine for many years now:
Most problems precisely defined are already partially solved.
~ Harry Lorayne,
Memory Makes Money
It's also an example of the oft-repeated-among-techs: They don't pay me to push buttons, they pay me because I know exactly which buttons to push, and in what order.
One of the things I'm trying to teach on other venues is "the right way" to prompt AI chatbots to get the information you want. If you're overly broad in your prompt you generally get nothing useful, and if you're overly specific, you often miss what you might need but hadn't thought about.
--------------
Real Aside, but definitely connected to the above.
A few weeks ago on Substack, Taylor Arndt made this blog post:
Everybody Is Vibe Coding. Here Is What That Does to Accessibility, and What to Actually Do About It.
Very shortly afterward, Brian Hartgen made a post taking this article to task, obliquely:
https://leaseysocial.com/@brian/116811322825683619
Now, in Mr. Hartgen's article, he uses this as an example of a vibecoding prompt (which it's not, this is a specification, and your average "vibecoder" would not understand even half of it):
=============
Requirements:
* Use a GUI toolkit that exposes standard native Windows controls well to screen readers.
* Avoid custom-drawn controls where possible. Use normal edit fields, buttons, radio buttons, check boxes, combo boxes, list boxes, and static text labels.
* Structure the interface so my screen-reader reads clean, concise control labels without unnecessary container verbosity.
* Every edit field, button, list, check box, radio button and combo box must have a clear accessible name.
* Do not rely on visual position, colour, icons, mouse hover text or images to convey important information.
* Keep keyboard access central:
* logical tab order
* reliable Alt-key shortcuts where appropriate
* Enter, Escape, Delete, and arrow-key behaviour should feel natural
* focus should move predictably and never jump unexpectedly
* every important feature must be usable without a mouse
* Make sure focus does not land on controls that cause my screen-reader to read large blocks of text unless that is explicitly desired.
* Prefer plain headings over verbose container labels if group boxes cause repeated speech.
* Make status messages short, useful and not repetitive.
* When a task completes, fails or needs attention, present that information in a way my screen-reader can discover reliably.
* Avoid constantly updating text on screen if it causes my screen-reader or Braille display to refresh unnecessarily.
* When using list views or tables, make sure column headings are meaningful and that row navigation is predictable.
* If the application contains a message composition area or large edit field, make sure cursor movement with the arrow keys and Control+arrow keys remains responsive.
* Do not trap the keyboard. I must always be able to tab away, press Escape where appropriate, or close the window with standard Windows commands.
* Use standard Windows dialogs where possible for opening files, saving files, choosing folders and confirming actions.
* Persist user data in a simple editable format such as JSON when that makes sense.
* Include error handling which gives the user understandable messages rather than technical tracebacks, unless I specifically ask for diagnostic information.
* Include a small Help or keyboard commands section within the app.
* When implementing shortcuts or accessibility behaviour, explain the reasoning briefly.
* After each major change, review the application from the point of view of a blind keyboard user and tell me what accessibility risks remain.
* Where possible, suggest a simple manual test plan I can use with my screen-reader and Braille display.
End of suggested prompt.
=============
I find it infuriating when those who should know better try to take what vibecoding is, just based on what's out there, and say that all AI-assisted code generation is vibecoding. These two things are not one and the same.
Hartgen gives a perfect example of how someone who actually has a programming background should prompt if they want very specific things out of AI-code generation. He gives a specification, for all practical intents and purposes. He isn't vibecoding.
He knows
exactly how to prompt, where most people playing with vibecoding have no idea how to prompt, how to evaluate the code generated, or how to optimize and/or fix errors.
