
The Hardest Part of Using AI
The article argues that the primary challenge in using AI is distinguishing between the ability to read code and the ability to generate it from scratch. It explains that programming proficiency often develops through an apprenticeship-like process where developers internalize specific paradigms and tacit knowledge from their early career experiences. This deep familiarity with a particular coding style makes developers resistant to critiques that challenge their foundational approaches, similar to how chefs specialize in distinct culinary traditions.
- ▪Reading code and writing code are distinct skills, and AI usage makes it difficult to differentiate between the two.
- ▪Developers often adopt a specific programming paradigm early in their careers, which becomes their professional trade and conceptual framework.
- ▪Critiques of a developer's chosen paradigm can feel personal because they challenge the tacit knowledge and problem-solving methods the developer has relied on for years.
- ▪University education provides foundational skills like algorithms and data structures, but practical experience determines how these are applied in specific domains.
- ▪The article uses a culinary analogy to illustrate that while basic skills are universal, the path to mastery varies significantly depending on the chosen specialization.
Hacker News (AI / LLM) files mainly under ai. We currently carry 7,767 of its stories.
Story provenance
Source · retrieval · rights · ranking — open for full record
inspect →
Story provenance
Attribution is not the same as permission. This drawer separates discovery metadata, excerpts, WeSearch-generated summaries, reuse status, and whether the publisher receives the visit. Nothing here claims a legal grant the publisher has not made.
Record
| Original publisher | MAKONEA |
| Canonical URL | https://www.makonea.com/en-US/casual/the-hardest-part-of-using-ai |
| Publication time | Wed, 07 Oct 2026 00:45:08 +0000 |
| Retrieval time | 2026-10-07T00:58:04.931Z |
| Last seen | 2026-10-07T00:58:17.998Z |
| Headline source | Publisher (no WeSearch rewrite) |
| Excerpt source | publisher body |
| Excerpt method | First ~120 words (~800 chars) of extracted publisher body, fair-use limited. |
| Summary | WeSearch · cerebras-chat (WeSearch summarizer) |
| Summary source text | contentText |
| Citation coverage | Summary is a WeSearch-generated derivative; primary citation is the original publisher URL. |
| Cluster | 937nIe_swmaY · 1 stories |
| Cluster logic | Grouped by semantic title/content similarity across sources within a rolling window. Same-publisher template collisions are excluded from coverage comparison. |
| Ranking reason | Story pages are not engagement-ranked. Hub feeds use recency, with optional source-diversified chronological ordering (cap consecutive stories per source). No personalized ranking. |
| Publisher visit | Yes — open original |
| Substitutes article? | No — link-out required for full text |
Rights status (four layers)
WeSearch handling by dimension
| Indexing | May the item be indexed (stored, ranked, made findable)? | Allowed |
| Snippet | May a short excerpt of the publisher's text be shown? | Allowed |
| AI summary | May WeSearch generate its own short summary of the article? | Limited |
| Retrieval / RAG | May the content be exposed for third-party retrieval-augmented generation? | Not asserted |
| Model training | May the content be used to train AI models? | Not asserted |
| Commercial reuse | May the content be reused commercially? | Not permitted |
Basis: Derived from the published RSS/Atom feed. Contact: [email protected]. Reviewed: 2026-07-24.
Opening excerpt (first ~120 words) tap to expand
The Hardest Part of Using AICasualThe Hardest Part of Using AIReading vs. WritingMakonea·Oct 7, 2026Updated Oct 7, 2026·21 min The hardest part of using AI is being able to understand code by reading it is different from being able to do that same modeling yourself starting from a blank screen and it becomes difficult to tell the two apart.I genuinely believe that reading code frequently leads to improvement. Read lots of good code. Absorb lots of good patterns. Do that long enough, and you start storing them like pattern matches. When you program for any length of time, you naturally come to recognize good code from bad. Most developers follow at least one programming influencer, or read posts by programmers like me, and those people tend to have preferred projects.
…
Excerpt limited to ~120 words for fair-use compliance. The full article is at MAKONEA.