Make some edits.

Signed-off-by: Danila Fedorin <danila.fedorin@gmail.com>

content/blog/pdf_flashcards_llm/index.md

@@ -254,22 +254,12 @@ With LLMs, I was able --- allowed? --- to view things more so from the
 end-user perspective. I didn't know, and didn't need to know, the API
 for `PyMuPDF`, `argostranslate`, or `spaCy`. I didn't need to understand
 the PDF format. I could move one step away from the nitty-gritty and focus
-on the 'why' and the 'what'.
+on the 'why' and the 'what', on the challenge of what I wanted to accomplish.
-
+I wrestled with the inherent complexity and
-The boundary between 'manual' and 'automatic' was not always consistent.
+avoided altogether the unrelated difficulties that merely happened to be
-Though I didn't touch any of the PyMuPDF code, I did need to look fairly
-closely at the logic that classified my squiggles as "underlines" and found
-associated words. In the end, though, I was able to focus on the core
-challenge of what I wanted to accomplish (the inherent complexity) and
-avoid altogether the unrelated difficulties that merely happened to be
 there (downloading language modules; learning translation APIs; etc.)
 
-This was true even when I was writing the code myself. Codex created the
+By enabling me to do this, the LLM let me make rapid progress, and to produce
-word-highlighting utility in one shot in a matter of seconds, saving
-me probably close to an hour of interpreting the algorithm's outputs
-while I iterated on the proper heuristic.
-
-By enabling me to _do_, the LLM let me make rapid progress, and to produce
 solutions to problems I would've previously deemed "too hard" or "too tedious".
 This did, however, markedly reduce the care with which I was examining
 the output. I don't think I've _ever_ read the code that produces the
@@ -279,17 +269,8 @@ I think that this has to do, at least in part, with different views
 on code as a medium.
 
 #### The Builders and the Craftsmen
-AI discourse is nothing new; others before me have identified a distinction
+There are two perspectives through which one may view software:
-between individuals that seems to color their perspective on LLMs. Those
+as a craft in and of itself, and as a means to some end.
-that appreciate writing software as a craft, treating code as an end
-in and of itself (at least in part), tend to be saddened and repulsed by
-the advent of LLMs. LLMs produce "good enough" code, but so far it
-lacks elegance, organization, and perhaps, care. On the other hand,
-those that treat software as a means to an end, who want to see their
-vision brought to reality, view LLMs with enthusiasm. It has never been
-easier to make something, especially if that something is of a shape
-that's been made before.
-
 My flashcard extractor can be viewed in vastly different ways when faced
 from these two perspective. In terms of craft, I think that it is at best
 mediocre; most of the code is generated, slightly verbose and somewhat
@@ -305,7 +286,7 @@ capable of being any combination of these two camps at any given time. Indeed,
 different sorts of software demand to be viewed through different lenses.
 I will _still_ treat work on my long-term projects as craft, because
 I will come back to it again and again, and because our craft has evolved
-and to engender stability and maintainability.
+to engender stability and maintainability.
 
 However, I am more than happy to settle for 'underwhelming' when it means an
 individual need of mine can be addressed in record time. I think this
@@ -332,7 +313,7 @@ the number of features it provides. Suppose also that individual users
 leverage only a small subset of the software's functionality. From these
 assumptions it would follow that individual programs, made to serve a single
 user's need, would be significantly less complicated than the "whole".
-By definitions, these programs would also be better tailored to the users'
+By definition, these programs would also be better tailored to the users'
 needs. With LLMs, we're getting to a future where this might be possible.
 
 I think that my flashcard generator is an early instance of such software.
@@ -373,7 +354,7 @@ if I had to give a rough heuristic, it would be problems that:
 * __have relatively low stakes__, again, because LLMs are not perfect,
   and nor is (necessarily) one's understanding of the problem.
   * e.g., it's OK if I miss some words I underlined; my cash flow
-  charts only give me an impression of my spending;
+    charts only give me an impression of my spending;
   * I recognize that moving files is a potentially destructive operation.
 
 I dream of a world in which, to make use of my hardware, I just _ask_,
@@ -393,12 +374,17 @@ to hit the ground running, to know what to ask and to help pluck out a particula
 solution from the space of various approaches. I think that this greatly
 accelerates the effectiveness of using LLMs compared to non-technical experts.
 
+For another, the boundary between 'manual' and 'automatic' is not always consistent.
+Though I didn't touch any of the `PyMuPDF` code, I did need to look fairly
+closely at the logic that classified my squiggles as "underlines" and found
+associated words. It was not enough to treat LLM-generated code as a black box.
+
 Another advantage software folks have when leveraging LLMs is the established
 rigor of software development. LLMs can and do make mistakes, but so do people.
 Our field has been built around reducing these mistakes' impact and frequency.
 Knowing to use version control helps turn the pathological downward spiral
 of accumulating incorrect tweaks into monotonic, step-wise improvements.
-Knowing how to construct a test suite and thinking about edge cases cap
+Knowing how to construct a test suite and thinking about edge cases can
 provide an agent LLM the grounding it needs to iterate rapidly and safely.
 
 In this way, I think the dream of personal software is far from being realized