Home-Cooked Software and Barefoot Developers

Original Article ↗ Hacker News Discussion ↗

Enthusiasm for “home‑cooked,” local‑first software and so‑called “barefoot developers” collides here with skepticism about how many people actually want or are able to build their own tools. Commenters debate whether AI code generation and LLM “consultants” can really empower non‑programmers, or whether proven paths like spreadsheets, approachable scripting environments, and open‑source culture are more realistic foundations for end‑user programming. Many like the vision of small, locally meaningful apps outside Big Tech’s cloud platforms, but doubt it will scale beyond a motivated minority or avoid simply adding new layers of complexity and dependency.

Overall Reception of the “Home‑Cooked / Barefoot Developer” Vision

  • Many experienced developers found the vision emotionally resonant, seeing it as a return to early web / microcomputer eras where individuals built small, bespoke tools.
  • Others argue this already exists: huge amounts of ad‑hoc scripts, internal tools, and niche apps never seen publicly.
  • Some doubt the premise that most software is mega‑corp, cloud‑scale; they see plenty of small shops and hobbyists already filling long‑tail needs.

Local‑First Software & Platform Centralization

  • Strong support for local‑first as a way to reduce dependence on cloud giants and app stores, and to give users more ownership and resilience.
  • Critiques of app stores and centralized web: they push users to bloated, winner‑take‑all apps and “dead” software that can’t be shaped or shared.
  • Examples raised: single‑file local/web hybrids (TiddlyWiki, Decker), self‑hosting platforms, IPFS‑synced tools.

LLMs, Autocoding, and “Barefoot Developers”

  • Optimists see LLMs as “consultants” or junior devs: speeding up glue code, boilerplate, homelab scripts, small apps, even for non‑engineers.
  • Skeptics say LLMs conflict with local‑first ideals, encourage shallow understanding, and require more expertise to safely detect hallucinations and bad designs.
  • Concern that juniors will become dependent on AI, lack deep skills, and be locked into corporate AI platforms they don’t control.
  • Several note that LLMs often confidently produce plausible but broken or invented APIs; debugging and design still demand real expertise.

Will Non‑Programmers Actually Build Software?

  • Repeated argument: most people don’t want to think hard about computers; they use only a tiny fraction of Excel, ignore existing OSS, and avoid learning.
  • Counterpoint: problem is cultural and UX, not human capacity. Past eras (BASIC, early PCs) showed many ordinary users programming when tools were visible, bundled, and approachable.
  • No‑code/low‑code history is cited: powerful tools (Access, spreadsheets, Google AppScripts, AppSheets, etc.) enabled some “folk developers,” but did not cause mass democratization.

Open Source, Tooling, and Missing Pieces

  • Some criticize the article’s lack of focus on open source and open standards as essential for shared, small‑scale tools.
  • Others say license matters less than deployability and maintenance: many OSS apps are too complex for non‑technical users to install and keep running.
  • Multiple commenters argue that better, fun, extensible spreadsheet‑like or VB/HyperCard‑style environments might be more pivotal than LLMs alone.