Peggy Lo：我的麻瓜 AI Coding 之路

1. In one sentence

A humanities-background mother working in a four-person foundation secretariat used the early-morning hours before her daughter woke to break bookkeeping checks, form filling and administrative support into thirty-odd little helpers with AI — and closed with a sharp observation: for the people at the bottom of an organisation with the most drudgery, AI coding is a tool for moving up.

2. The session

Peggy introduces herself as a card-carrying humanities person who joined a corporate foundation (organisation name unverified) five years ago, working in its secretariat. She describes the foundation's mission — changing teaching behaviour through grant design — as noble, but says the nobility sits on top of a daily grind of fiddly administration and odd jobs. She now manages over a hundred schools, and where she used to check each teacher's grant progress carefully before replying whenever one asked over LINE, at scale that became completely unsustainable.

Case one: the bookkeeping helper

She used ChatGPT to help build a lookup site where a teacher enters their name and the last four digits of their ID to see the progress of every grant under the whole programme. Behind it are just the three Google Sheets she was already maintaining — change the sheet once and the site's data updates automatically. She asked all the teachers to stop coming to her on LINE and to use the system instead.

Case two: the repetitive form-filling helper (a Computer Use agent)

With limited resources, the foundation is stuck using an externally built system that has been abandoned by its maintainers, in which the only way to edit sponsorship data is opening each record one at a time via a pencil icon, because the bulk import function that should be in the top right corner broke long ago and nobody can fix it. She set up a Docker environment on her own machine and wrote code driving a Computer Use agent (a technique she noted had been introduced in Wisely Chen's earlier session), letting the agent identify the pencil position on screen itself and complete hundreds of operations. Her own mouse never moved on screen; the agent did all of it. She required the agent to report each completed record into a status column in a spreadsheet, and deliberately slipped in fake data that does not exist in the system as a test — and without being told how to classify errors, the agent judged for itself and wrote "not found", which struck her as rather clever.

Case three: the multi-role helper

With only four people in the foundation's secretariat, she often has to step into different roles: she used Windsurf to automate cropping speaker photos into circles, which she used to do one at a time in PowerPoint; Google Forms cannot be closed automatically at a set time, so where she used to set a stack of phone alarms to remind herself to close registrations on time, she switched to Apps Script closing them automatically and stopped needing alarms; she also built an Outlook helper for customised customer service emails, and used something scraper-like to research how other foundations do things. Over the past six months her GitHub history shows roughly one new tool every week or two, thirty-odd helpers in total, all actually used in her work.

From "doing as told" to "growing hands and feet"

She splits her own growth into several stages:

• Splitting up the tests: at first she was very obedient and did whatever GPT said, but GPT habitually puts testing in the last step, so she would follow along with no idea whether she had done it right until the final test failed — extremely hard to debug. She later formed the habit of asking GPT to break development into smaller stages, each with a testable point, even if the stage is just building an API, so she can confirm the direction is right.
• Version control: she started with a homespun version control system in ChatGPT's sidebar, creating a conversation for each finished stretch and annotating it with a number and something like "runs smoothly, well done"; to find an old version she copied the last version out of that conversation. She later moved to Cursor, and an engineer friend suggested she learn git commands, but she could not remember them — then discovered Cursor understands plain language, so now she just says "save me a new branch" and leaves the rest of the commands to Cursor.
• Using APIs: the bookkeeping helper needs the Google Sheets API to read the spreadsheet data, but she says outright that Google Cloud Platform's API management interface is complex enough to get lost in. Her trick is "screenshot and paste" — when GPT says to generate a particular API credential and she cannot find where to click, she screenshots it, and GPT pinpoints exactly where to click. Her first ever API key took more than ten screenshots before GPT walked her to it.

She estimates these "growing hands and feet" stages cover about eighty per cent of a muggle's needs, with the remaining twenty per cent taken to the AI reading group the conference runs, to ask real engineers. Engineers usually will not debug it for her; they teach her strategy-level things instead, like "run this test first to determine whether it's a permissions problem or something more complex", or the idea of using batch processing to save on API costs. That got her thinking: could the AI itself teach her that higher-level strategy, rather than her passively accepting the development steps it hands out? So she started asking Cursor: "We've already discussed the requirement, but are there development decisions you could talk through with me as well?" Once she asked that, Cursor began raising things it had never brought up before — whether a feature should use a decorator or modify the API directly, how the two differ, how to think about the trade-off. She typically spends at least thirty minutes to an hour patiently asking Cursor to explain each piece of jargon in plain language. Once she got that far, she found she could start pushing back on Cursor, pointing out where it was inventing things, and Cursor would concede that "the muggle is right".

The development document: a compass for a muggle and an AI

As the discussions with the AI grew, she found her own memory insufficient, so she asked the AI to build a "development document" before writing a single line of code, recording every decision they reached together: what the final output is, the development principles she cares about (staged development, testability), the development order agreed, the file structure, and every design decision. That document became the shared language between her and the AI — whenever she opens a new conversation and Cursor has no memory of the last one, she has Cursor read the development document first and then ask what to do next; and when a new decision is made mid-development, she has Cursor go back and update the document, so the reasoning behind that decision can be reused indefinitely. She describes the document as a compass: even lost in a complex development stage, she can ask Cursor "tell me where we are in the development document". She says AI coding used to be ninety per cent debugging, and is now ninety per cent discussion and writing documents — more tiring, but it lets her build more complex, reusable projects.

Three detours

• Paying for an automation tool too soon: she once subscribed to Zapier, and never opened it again a month after discovering AI coding. Her reasoning: AI coding relies heavily on debugging, and GPT is very good at languages like Python — but if you get stuck in Zapier and screenshot the problem to GPT, it usually answers badly; and as long as she can state the requirement clearly, AI will generally just write the feature for her, with no need for an off-the-shelf Zap. Her advice: if you judge that you will end up doing AI coding anyway, subscribing to a paid automation service is worth thinking twice about.
• Learning upstream material: last year she took NTU professor Hung-yi Lee's introduction to generative AI, taking Friday afternoons off to attend in person rather than watching replays. She describes the course as "I set out to learn reading and accidentally learned papermaking" — the content leans toward the principles of model training, closer to the topics of the developer conference, an excellent course but not one that teaches AI coding. She later found Andrew Ng's AI Python course and realised there is a spectrum in teaching AI coding too: at one end, finish and immediately solve a work problem; at the other, learn the nature of a programming language (variables, for loops). Ng's course leans toward the latter. She invested many weekends following along on variables and for loops without ever feeling the connection to a work problem, and now advises that if time is limited and you want to solve a work problem immediately, picking a concrete problem and building it is by far the most efficient route; if you are a student, or already have AI coding experience and want to take on harder problems, coming back to courses like these is more appropriate.

A muggle's map, and traffic lights for picking a problem

She put together a map of muggle tools: online document tasks go to Google Apps Script as Vivi introduced earlier; a front-end web requirement goes to Hugging Face Spaces with no deployment; local documents go to Cursor; web page operations go to browser developer tools; repetitive operations needing judgement go to Computer Use; and if you have information security rules because you work in a corporate foundation, fall back to VS Code, saving locally, and managing secrets through environment variables and gitignore. She says the hardest part of any tool is working out what it does and does not cover, so before using any of them for the first time she asks an engineer friend to spend ten minutes explaining what it can and cannot do — and once she has a sense of the boundary, the rest is hammering away at it with GPT.

She also offered a set of "muggle traffic lights" for picking a problem, using the bookkeeping helper's five steps (receive the paper receipt, key it into the company system, send the paper to finance after manager approval, confirm the posting date and enter it in a spreadsheet, notify over LINE). Technically: as long as it stays inside a single Google-ecosystem spreadsheet, it is green and can be done directly with Apps Script; anything involving Excel or the Office ecosystem needs a local editor (Cursor, say) and is amber — she advises beginners to leave it alone; anything involving a company's own internal system with its own API rules or IT policies is red, and should be left alone rather than crossing an organisational line. On communication, you have to assess who you cannot move (finance colleagues who must follow an existing process, say) as red, and who you can (teachers outside the organisation willing to change their habits) as green. Her bookkeeping helper happens to sit in the doubly green zone technically and communicatively, which is why she thinks it genuinely went into service.

Two layers of meaning in AI coding for her

At the foundation she has also tried bringing AI to teachers, along two paths: adoption in their subject (adding AI to English and mathematics) and adoption around the edges (using AI coding to reduce administrative load). Tracking it, she found what teachers were genuinely willing to try was mostly the administrative side; her reading is that adoption in one's own subject meets more inherent resistance, whereas plenty of teachers will throw up their hands and say "I'm terrible at admin, AI please save me". Her advice, if anyone in the room is responsible for AI adoption inside an organisation: pushing the core work matters, but "using AI coding to cut administrative load" can serve as a supporting side quest, and it has a chance of becoming the breach that lowers the organisation's overall resistance to AI.

For the second layer, she says that as an NGO worker joining a foundation, she wanted resources to reach every individual teacher rather than stopping at the school level — which vastly increased her administrative load and had her boss regularly reminding her that "there are only four of us in this foundation, please simplify your grant model". But over these months of working with AI coding, she finds she less often has to use the "not enough people" line NGO workers habitually reach for as grounds for discounting the service. AI coding has become the backing behind putting her ideas into practice and making the service finer-grained.

She closed by admitting she was one of the few speakers that day who is not a founder or a chief executive, just an officer in a corporate foundation's secretariat, and that going on stage made her anxious. But she turned the position around: when you are the lowest in an organisation with the most manual drudgery in your hands, that is precisely the ideal seedbed for growing a new skill like AI coding — or, more bluntly, her boss probably can no longer learn AI coding, because there is simply no use case. She therefore thinks AI coding carries a certain flavour of class mobility.

3. Figures and cases

• Over a hundred grant-receiving schools under her management.
• GitHub history over the past six months shows roughly one helper every week or two, thirty-odd in total, all actually used at work.
• The "growing hands and feet" stages — splitting up tests, version control, using APIs — cover an estimated eighty per cent of a muggle's needs.
• Her first ever API key took over ten screenshots for GPT to walk her to; she typically spends thirty minutes to an hour going through the jargon in a development document one term at a time.
• AI coding used to be ninety per cent debugging; it is now ninety per cent discussion and writing the development document.
• The foundation's secretariat has a headcount of four.

4. Lines worth keeping

• "AI coding, for me, isn't about becoming an engineer; it's about letting a muggle take part in the development conversation."
• "Lately I seem to reach less often for the 'not enough people' line we NGO workers always have to hand, as grounds for discounting my service."
• "Your boss and mine probably can't learn AI coding any more, because there's simply no use case."
• "The lower down you are and the more drudgery you have, the better the seedbed for growing AI coding skills."
• "AI coding actually carries a certain flavour of class mobility."
• "What I set out to learn was reading, but I seem to have accidentally learned papermaking."

5. Tools and terms mentioned

ChatGPT, Cursor, Git, Google Sheets, Google Apps Script, Hugging Face Spaces, Windsurf, Computer Use, Docker, VS Code, an Outlook helper, Zapier, decorators, batch (API batch processing), Hung-yi Lee's introduction to generative AI, Andrew Ng's AI Python course.

6. Wider observations

Peggy's methodology is more systematic than Vivi's: she separates tactical abilities (splitting up tests, version control, using APIs) from strategic ones (the development document, getting the AI to teach strategy), which gives a clear sense of the path and explains how she got from a bookkeeping helper all the way to something as complex as a Computer Use agent. What stands out most is the class-mobility argument at the end: she connects two apparently unrelated details — "there are only four of us in the foundation" and "my boss can't learn AI coding" — to point out that the people at the bottom with the most drudgery have both the most motivation and the most room to grow this new skill. It is interesting to hear that against 海馬's session: one is the most junior officer in an organisation, the other the youngest member of a family, and both trained themselves up in the gaps nobody else would bother pointing AI at, on a large volume of small repetitive tasks.

7. Sources