How can Writers Benefit from AI Agentic Revolution

Agentic AI offers writers a new form of leverage through Specification-Driven Authoring (SDA), a workflow that keeps the writer in control while structuring AI collaboration for planning, drafting, verifying, revising, and managing articles, according to Roberto Penco, PhD. Penco distinguishes SDA from chatbot-based writing, describing it as the next step in AI-assisted writing where the assistant works beside article files rather than replying in a chat window.

Roberto Penco, PhD Agentic AI gives writers a new kind of leverage: not just a chatbot that suggests paragraphs but an assistant that can help plan, draft, verify, revise, and manage an article beside the files themselves. This article shows how writers can benefit from the AI agentic revolution through Specification-Driven Authoring, a practical workflow that keeps the writer in control while making AI collaboration structured, reviewable, and useful. AI Writing Is Part of a Longer History Many writers are curious about AI but also uneasy about what it changes. That unease is reasonable: writing is personal work, and the tools we use can shape how our ideas appear on the page. But a tool does not automatically remove authorship. What matters is how the writer uses it, reviews it, and remains accountable for the final text. But the history of writing is also the history of tools entering the process. Before large language models, before autocomplete, before spellcheckers, before text editors, before computers, there were typewriters. Before typewriters, there were pens and paper. Each tool changed what writing felt like and what writers could do. The typewriter turned handwriting into machine-produced characters and became part of a much larger shift in office and document work 1 . Word processing later changed the surface of writing again: text could be edited, moved, deleted, copied, searched, formatted, saved, and revised in ways that were impossible or painful on paper 2 . Then writing assistance became part of the software itself. Spellcheckers and grammar checkers made correction a normal feature of the writing surface 3 . AutoCorrect went further by changing text while the writer was still typing 4 . It is fair to understand these tools as part of the broader language-modeling tradition. Even when a particular implementation uses dictionaries, rules, or typo tables, the task can still be framed as modeling which words or sentences are likely and which corrections are plausible. Russell and Norvig place language models inside natural-language processing, and Jurafsky and Martin describe n-gram language models as a foundational way to estimate likely word sequences 5 , 6 . These tools did not remove the writer. They changed the writer’s environment. That is also how I understand Specification-Driven Authoring. Using SDA is not the same as pressing a button and receiving a finished article. It is closer, in spirit, to using a spellchecker, grammar checker, autocorrect, or autocomplete: the tool lowers friction and increases capability, but the writer still has to think, choose, revise, verify, and take responsibility. A spellchecker can catch a mistake, but it cannot decide what you mean. SDA can organize an AI-assisted writing process, but it cannot replace the writer’s intent. Large language models are different in scale and behavior, but they are not the first language models to enter writing. What changed with systems such as GPT-3 was not the basic idea that language can be modeled. What changed was scale, generality, and interface: a model could now respond to natural-language instructions and examples across many tasks 7 . At this point, one distinction matters. Chatbot-based AI-assisted writing and SDA are not the same thing. Chatbot writing is prompt-and-response assistance. The writer asks ChatGPT or another chatbot for an outline, paragraph, rewrite, summary, title, or critique, then copies, edits, accepts, or rejects the result. That was already a major disruption. OpenAI introduced ChatGPT on November 30, 2022, as a conversational model that could answer follow-up questions and interact through dialogue 27 . For many people, that was the moment LLMs became visible as writing tools. SDA is the next step: agentic AI writing. The assistant is not only replying in a chat window. It works beside the article files. It reads the specification, proposes edits, creates or revises documents, tracks sources and images, and helps save versions. OpenAI’s Codex IDE documentation describes Codex as working beside open files and letting users review changes in the editor 15 . That changes the unit of collaboration. The unit is no longer only a prompt, a paragraph, or a response. The unit becomes the writing workflow. This is why I think SDA may be as disruptive for writing practice as ChatGPT was for public awareness of LLMs. ChatGPT made conversational AI writing feel accessible. Agentic SDA makes the whole authoring process programmable, inspectable, reviewable, and reusable. It moves AI from “help me write this paragraph” toward “help me run this writing process.” That is why I do not see AI-assisted writing as a sudden moral rupture. I see it as a new stage in a long movement from physical writing tools to software writing tools, from software writing tools to language-aware writing tools, and from language-aware tools to agentic assistants that can participate in planning, drafting, checking, and revising. This connects to an even older goal in computing: communicating with computers in a way that feels closer to communication with another person. In 1960, J. C. R. Licklider described “man-computer symbiosis” as a cooperative relationship in which humans would set goals and criteria while computers performed routine work needed to prepare for insight and decision 8 . That idea sounds surprisingly modern. In good AI-assisted writing, the writer sets the purpose, audience, thesis, sources, constraints, and quality standard. The machine helps organize, draft, compare, check, and revise. But here is the danger: a computer that accepts natural language is still not human. Engineers know this from long experience. They have spent decades communicating with computers through formal languages, commands, APIs, schemas, tests, and version-control systems. Natural language makes some of that power easier to reach, but it can also make the machine feel more understanding than it is. For non-engineers, this can be both liberating and confusing. The interaction looks like conversation, but the system does not share human responsibility, context, or intent. That is why the future of writing cannot be simply “ask AI to write.” That is too loose. It gives the model too much room to invent the article’s purpose, choose the argument, smooth over weak claims, and sound confident where the writer has not yet decided. Nor do I think the answer is to treat every suspicious sentence as evidence of guilt. OpenAI itself discontinued its AI text classifier in 2023 because of low accuracy, and the original announcement warned that AI-written text cannot always be reliably detected 9 . In a recent video, Max Kotin makes a similar public argument from a writer’s perspective: the text should be judged by its quality, not by a witch hunt around whether AI was used 10 . I agree with that direction. The question that matters most is not whether a tool was used. Writers have always used tools. The better question is whether the writer remains responsible for the text. My answer is Specification-Driven Authoring. The rest of this article follows that path. Part 2 What Specification-Driven Authoring Means defines SDA as a theory of AI-assisted writing: specification first, draft second, review always. Part 3 A Practical Setup for Writers turns the theory into a Windows tutorial with VS Code, Codex, GitHub, and writer-friendly versioning. Part 3A Set Up the Workspace on Windows shows setup. Part 3B Use the SDA Workflow shows daily use. What Specification-Driven Authoring Means Specification-Driven Authoring, or SDA, is a writing process in which the writer and AI first create a specification for the article before generating the article itself. That sounds simple, but it changes the relationship between writer and assistant. A prompt asks for output. A specification defines the conditions under which the output can be judged. In ordinary prompting, the writer might say: Write an article about the future of writing with AI. The model can produce something plausible from that. It may even produce something polished. But it has to guess the audience, structure, argument, level of detail, sources, tone, and boundaries. In SDA, the writer and AI first build a shared document that answers questions such as: - Who is this article for? - What problem is it trying to solve? - What is the central claim? - What should the article not claim? - What sources are required? - Which claims are facts, interpretations, or original proposals? - What figures are needed? - What tone should the article use? - What workflow should the AI follow? - What counts as done? Only after that specification is mature does the writer approve it for article production. idea - specification - approval - outline - draft - review - revision - final article The most important word is approval. The writer does not hand the article to the machine and hope for the best. The writer defines the standard first. The Specification Is the Source of Truth In SDA, the specification is the contract between human intent and AI output. It does not need to be complicated. A useful article specification can include: - Purpose: why the article exists. - Target reader: who should benefit from it. - Core thesis: the main argument. - Article balance: how much space each part should receive. - Voice: personal essay, practical guide, technical tutorial, or another mode. - Claims: what the article wants to say. - Evidence rules: which claims need external sources. - Open questions: what is still unresolved. - Image plan: what each figure should explain. - Publishing constraints: publication guidelines, style requirements, and reference format. - Workflow rules: how the AI should ask questions, edit files, save versions, and produce drafts. This matters because prose can become convincing too early. A fluent paragraph can make an unfinished idea feel finished. A specification slows the process down at the point where slowness is useful: before the first full draft. The AI Has Roles, but the Writer Keeps Authority In SDA, the AI can do many useful things: But these are supporting roles. The writer remains the author. The writer decides what belongs in the specification. The writer approves changes. The writer accepts or rejects the draft. The writer is accountable for the final article. This is also why SDA is different from ghostwriting. The AI is not secretly replacing the author. The process is visible, structured, and reviewable. The writer’s intent is recorded before the article exists. SDA Separates Types of Claims One of the biggest risks of AI writing is unsupported confidence. A model can produce a sentence that sounds true even when the evidence is weak, missing, outdated, or invented. SDA reduces that risk by separating claims into categories: This distinction is important. Not every sentence needs the same kind of evidence. “VS Code has built-in Git support” should be sourced from VS Code documentation 13 . “Writers need gentler language for version control” can be framed as this author’s argument. “SDA is a proposed workflow” can be presented as an original proposal and then demonstrated through the project repository. The point is not to eliminate original thought. The point is to stop factual claims, interpretations, and inventions from wearing the same costume. SDA also helps with publication rules without making the article feel tied to one journal. A specification can store the target publication’s requirements, such as reference style, image captions, alt text, originality rules, and draft format, before drafting starts. Those requirements become part of the article process rather than a final scramble. SDA Has Several Flows From one angle, SDA is a conversation flow: AI asks - writer answers - AI proposes - writer approves - AI edits From another angle, it is a production flow: specification - research plan - sources - outline - draft - review - revision - final From a third angle, it is a control flow: human intent - explicit specification - reviewable AI work - human approval From a fourth angle, it is a safety flow: claim - source check - citation or reframe - version save - final review These flows are useful because different problems appear at different moments. If the article feels vague, return to the specification. If the AI changes something without approval, compare versions. If a claim has no source, reframe it as interpretation or remove it. If the draft is polished but wrong, review it against the specification. If the writer is afraid of losing a good version, save a version before experimenting. SDA is not meant to make writing mechanical. It is meant to make collaboration with AI legible. A Practical Setup for Writers There should be a dedicated writing application that does all of this out of the box. A non-developer writer should not have to assemble a coding editor, an AI agent, Markdown files, Git, GitHub, image prompts, and citation tracking just to write an article with discipline. The need for such an application is one of the conclusions of this project. But until that application exists, we can borrow the developer workflow and translate it into writer language. The setup I am suggesting is: This is not the only possible setup. Future articles will explore other variants. For now, it is a practical path that you can use today. Set Up the Workspace on Windows This tutorial gives one concrete Windows path for non-developer writers. Future articles can cover variants: macOS, WSL, Codex CLI 16 , GitHub CLI, private repositories, and purpose-built writing applications. For now, assume Windows, VS Code, the Codex extension, Windows File Explorer, a GitHub account, and one reusable SDA workflow file. The reader should not need to understand PowerShell, terminal commands, or Git syntax. The setup below uses ordinary Windows actions first. Codex will handle the Git side later, after the writing folder exists. 1. Install VS Code Download VS Code from the official download page https://code.visualstudio.com/download : Choose the Windows User Installer unless you have a reason to install for every user on the machine. Microsoft recommends the user setup for most people because it does not require administrator permissions and supports smoother background updates 14 . Run the installer and accept the normal defaults. When it finishes, open VS Code from the Windows Start menu. 2. Install Codex from the VS Code Extensions Button In VS Code, install Codex from the Extensions view. Microsoft documents that VS Code extensions can be installed directly from the Extensions view, opened from the Activity Bar or with Ctrl+Shift+X on Windows 21 . OpenAI’s Codex IDE documentation describes using Codex beside open files and reviewing changes in the editor 15 . The VS Code Marketplace page describes the extension as a Codex panel that can use context from open files and selected code 19 . For this writing workflow, that means Codex can read the specification, propose edits, create files, and let the writer review changes in place. 3. Create a GitHub Account Open a browser and go to the GitHub signup page https://github.com/signup : Create a free personal account and verify your email address. GitHub’s own account-creation documentation says that a verified email address is needed for basic GitHub tasks such as creating a repository 22 . For this tutorial, the writer does not need to understand repositories yet. The simple idea is this: GitHub will be the backup location. Later, when Codex sets up versioning, it can guide the writer through creating or connecting the repository. This SDA setup can work without Git, but I recommend Git for stronger version control and for collaboration when more than one person works on the same document. 4. Create the Writing Folders in Windows Explorer Now use Windows File Explorer, not a terminal. The folder structure should begin like this: 5. Add the SDA Skill File Before asking Codex to set up the project, put the reusable SDA workflow file into the root Writing folder. This article’s project repository contains the reusable file 17 . Go to my GitHub repository https://github.com/erobpen/Writing . Find SDA SKILL.md . Save or copy it into the Writing folder, beside the Name of your Article folder. One simple way is to open SDA SKILL.md on GitHub, copy its full text, create a new file named SDA SKILL.md in the Writing folder, paste the text, and save it. The exact method matters less than the result: the file must be named SDA SKILL.md , and it must sit directly inside Writing . The SDA SKILL.md file in my repository is the version I have written for my own writing process. It is a starting point, not a law. You can edit it, simplify it, expand it, or create a different SDA SKILL.md that fits your genre, publication style, research needs, language, and preferred way of working with AI. This is important. SDA SKILL.md tells Codex how to work: ask one focused question, update the specification first, save versions, verify sources, prepare images, and keep the writer in control. This skill file SDA SKILL.md is not perfect, and improving it deserves an article of its own. Even in this basic form, however, it is already far better than using AI without any SDA structure at all. 6. Open the Writing Folder in VS Code Now return to VS Code. VS Code should show SDA SKILL.md and the Name of your Article folder in the file explorer on the left. Inside VS Code, create the first specification file: 7. Give Codex the Setup Prompt At this point, the writer has done the Windows tasks. Now Codex can do the technical setup. Open the Codex sidebar and paste this prompt. If you did not name your folder exactly Name of your Article , replace that phrase with your folder’s real name before sending. Read SDA SKILL.md and the article folder “Name of your Article”. I am a writer, not a developer. Please set up this Writing folder for Specification-Driven Authoring. First, check that “Name of your Article/00 SPEC.md” exists. If it does not exist, create it. Then set up Git versioning for this Writing folder. Use writer-friendly language: - Save Version = create a local Git checkpoint - Compare Versions = show what changed - Restore Previous Version = recover an older checkpoint, but only after asking me - Publish Backup to GitHub = push a saved version to GitHub If Git is missing, explain what is missing and ask me before installing or changing anything. If GitHub setup requires a repository or login, guide me step by step in the browser. Do not draft the article yet. After setup, ask me one focused question to start the specification. This prompt tells Codex to do the work that writers should not have to learn first: local version history, GitHub backup, and the translation between Git commands and writer-friendly commands. Git is still the engine underneath, and GitHub still stores repositories and revision history 11 , 12 . If Codex later asks to connect the folder to a GitHub repository, it is applying the remote-repository workflow GitHub documents for connecting local work to GitHub 20 . But the writer interacts with those tools through the four writing actions. If Codex says Git is missing, let Codex guide the next step. If a manual download is needed, use the official Git for Windows page 18 . If Codex asks permission for a technical action, read the explanation. If the action matches this setup goal, approve it. If unsure, ask Codex to explain it in plain language first. 8. What Success Looks Like When setup is complete, the writer should be able to use ordinary commands in conversation with Codex: Later, after the specification is approved, the article folder can grow into: Name of your Article/ | — 00 SPEC.md | — 01 RESEARCH PLAN.md | — 02 SOURCES.md | — 03 OUTLINE.md | — 04 DRAFT.md | — 05 IMAGE PROMPTS.md | — 06 EDITORIAL REVIEW.md | — 07 REVISION PLAN.md | — 08 FINAL.md — Images/ The root SDA SKILL.md defines the reusable process. Each article folder has its own 00 SPEC.md . The 00 prefix is not magic. It simply keeps the specification first in the folder, where both writer and AI can find it. This article’s project repository is public so readers can go deeper into the specification and article-production files 17 . I also plan to preserve the project chat as Markdown, so the process can be studied rather than hidden. Use the SDA Workflow Once the setup exists, the daily workflow is not technical. It is editorial. Open the article folder in VS Code. Ask Codex to read the reusable SDA workflow and the article specification. Then follow this loop: read specification - ask one question - writer answers - propose edit - writer approves - edit specification - Save Version The “one question” rule matters. If the AI asks ten questions at once, the writer has to become a project manager. SDA works better when the assistant identifies the single most important unresolved issue and asks about that. The writer answers in natural language. The AI then proposes the exact change to the specification. The writer approves, rejects, or revises the proposal. Only after approval does the AI edit the file. Repeat this until the specification is strong enough. Then the writer explicitly approves the specification for article production. At that point, the AI can create: This is the practical difference between SDA and one-shot prompting. The AI is not asked to invent everything from a vague instruction. It is asked to execute a documented authorial plan. Use Writer-Friendly Versioning Developers say “commit,” “diff,” “restore,” and “push.” Those words are useful, but they are not necessary for writers. Writers can use clearer commands: Save Version means create a local checkpoint. Use it after important decisions, specification changes, drafts, reviews, and final revisions. Compare Versions means inspect what changed. This is how the writer checks whether the AI changed only what was approved. Restore Previous Version means recover an earlier checkpoint. This should require explicit confirmation because it can replace current work. Publish Backup to GitHub means push saved work to the remote repository. It is the difference between “saved on this machine” and “backed up outside this machine.” This translation matters because the goal is not to turn every writer into a developer. The goal is to democratize the part of agentic AI that developers already benefit from: structured files, iterative changes, reviewable edits, source control, and recoverable versions. Verify Claims Before Publication Source verification should be part of the workflow, not an afterthought. For each substantive claim, ask: If no source is found, that does not automatically mean the idea is wrong. The world is a large place, but sometimes a writer may be first to name a process in a particular way. In that case, the article should say so honestly. Original ideas are allowed. Unsupported factual certainty is the problem. The same applies to images. If images are generated, they should be stored one image per file in the article’s Images/ folder. Captions, source notes, and alt text should be prepared before publication. This follows the same principle as the rest of SDA: make the hidden process visible enough to review. Review Against the Specification After the draft exists, do not only ask, “Is this good?” Ask: The specification becomes the ruler. The draft is measured against it. That is the core discipline of SDA. What This Changes The usual fear is that AI will replace the writer. SDA points in another direction. It treats AI as a powerful assistant, but it also gives the writer a structure: This structure is especially important for non-engineers. Engineers already live inside structured communication with computers. They use commands, formats, repositories, tests, and review processes. Natural language makes computers easier to approach, but it can also make the workflow feel less bounded than it should be. SDA adds the boundary back. It says: yes, talk to the AI in natural language. But do not let the conversation dissolve authorial responsibility. Put the decisions in a specification. Make the AI propose changes. Approve them. Save versions. Check sources. Review the draft against the intent. That is not cheating. That is a writing process. Conclusion The future of writing is not just better autocomplete. It is not just chatbots in the margin. It is the gradual transformation of writing into collaboration between human intention and machine assistance. But that collaboration needs discipline. There is real resistance to AI-assisted writing, and sometimes that resistance is correct. LLMs can generate a lot of fluent nothing: generic text, weak claims, fake confidence, and what people now call AI slop 10 . A bad article does not become good because a human typed every word, and a useful article does not become useless because AI helped the writer organize it. The only serious path is to judge the work, the process, the sources, and the responsibility behind it. I also do not want to pretend that tool evolution is painless. My parents were translators and court interpreters, and I also worked as a court interpreter earlier in life. In my own family, translation was a skilled and respectable profession. I saw that profession pressured over time: first by computer-assisted workflows and market changes, later by machine translation, and now by AI. Google describes Translate as beginning as an AI experiment in 2006, using statistical machine learning and language models, before a major shift to neural networks in 2016 23 . Translation researchers have described how machine translation changes the translator’s work toward checking, evaluating, and monitoring output rather than simply translating from a blank page 24 . A recent INSEAD working paper even uses Google’s neural translation rollout in 2016–2017 as evidence of reduced human translation transactions in an online labor market 25 . So yes, I understand why people are worried. I have seen a profession close to my family lose some of its old status and pricing power. Many other professions have similar stories, and AI is accelerating the pattern. But history also teaches caution in the other direction. Technological progress can hurt individuals and professions while still producing broad social benefits, and it can produce risks alongside benefits 26 . Fighting the existence of the tool rarely works. The better question is how to shape the tool, who gets access to it, what standards surround it, and whether ordinary people can use it without being exploited or misled. That is why AI-assisted writing matters. It can empower people who are not native speakers. It can help people who are not naturally fluent writers. It can help domain experts share knowledge that might otherwise remain trapped in notes, conversations, or unfinished drafts. Some of those people will have something useful to say. Society benefits when more of that knowledge becomes readable. Specification-Driven Authoring is one attempt to find the middle path. If writers simply ask for drafts, they risk getting fluent prose without enough authorship. If they reject all AI assistance, they may miss a tool that can help them think, organize, verify, and revise. SDA is a way to use the tool while keeping intent, judgment, evidence, and responsibility visible. This article presents my current practical version: VS Code, Codex, Git, GitHub, Markdown, and a specification-first workflow. It is not the final answer. Future articles can explore different setups, different tools, and the deeper question of what it means to communicate with computers in natural language. The long-term need is clear: writers should have an application built for this. It should include SDA, AI collaboration, source tracking, image handling, version history, review, and publishing support out of the box. Until then, we can borrow the developer workflow and make it humane for writers. References 1 S. R. Murray, “The Development of the Automatic Writing Machine: The Typewriter,” Encyclopedia.com. https://www.encyclopedia.com/science/encyclopedias-almanacs-transcripts-and-maps/development-automatic-writing-machine-typewriter https://www.encyclopedia.com/science/encyclopedias-almanacs-transcripts-and-maps/development-automatic-writing-machine-typewriter 2 Computer History Museum, “Software and Languages,” Timeline of Computer History. https://www.computerhistory.org/timeline/software-languages/ https://www.computerhistory.org/timeline/software-languages/ 3 Microsoft Support, “Check spelling and grammar in Office.” https://support.microsoft.com/en-us/office/check-spelling-and-grammar-in-office https://support.microsoft.com/en-us/office/check-spelling-and-grammar-in-office 4 Microsoft Support, “Add or remove AutoCorrect entries in Word.” https://support.microsoft.com/en-US/Word/add-or-remove-autocorrect-entries-in-word https://support.microsoft.com/en-US/Word/add-or-remove-autocorrect-entries-in-word 5 S. Russell and P. Norvig, Artificial Intelligence: A Modern Approach, 4th ed. Pearson, 2020. https://aima.cs.berkeley.edu/ https://aima.cs.berkeley.edu/ 6 D. Jurafsky and J. H. Martin, Speech and Language Processing, 3rd ed. draft. https://web.stanford.edu/~jurafsky/slp3/ https://web.stanford.edu/~jurafsky/slp3/ 7 T. B. Brown et al., “Language Models are Few-Shot Learners,” arXiv:2005.14165, 2020. https://arxiv.org/abs/2005.14165 https://arxiv.org/abs/2005.14165 8 J. C. R. Licklider, “Man-Computer Symbiosis,” IRE Transactions on Human Factors in Electronics, vol. HFE-1, pp. 4–11, March 1960. https://groups.csail.mit.edu/medg/people/psz/Licklider https://groups.csail.mit.edu/medg/people/psz/Licklider 9 OpenAI, “New AI classifier for indicating AI-written text,” Jan. 31, 2023. https://openai.com/index/new-ai-classifier-for-indicating-ai-written-text/ https://openai.com/index/new-ai-classifier-for-indicating-ai-written-text/ 10 M. Kotin, “Nobody Can Spot AI in Writing, Actually,” YouTube, published July 17, 2026. https://youtu.be/tze93ItrA9k?is= uXCf1vGT5lslqgR https://youtu.be/tze93ItrA9k?is= uXCf1vGT5lslqgR 11 S. Chacon and B. Straub, Pro Git, “About Version Control.” https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control 12 GitHub Docs, “About repositories.” https://docs.github.com/en/repositories/creating-and-managing-repositories/about-repositories https://docs.github.com/en/repositories/creating-and-managing-repositories/about-repositories 13 Microsoft, “Source Control in VS Code.” https://code.visualstudio.com/docs/sourcecontrol/overview https://code.visualstudio.com/docs/sourcecontrol/overview 14 Microsoft, “Installing Visual Studio Code on Windows.” https://code.visualstudio.com/docs/setup/windows https://code.visualstudio.com/docs/setup/windows 15 OpenAI, “Codex IDE extension,” ChatGPT Learn. https://learn.chatgpt.com/docs/codex/ide https://learn.chatgpt.com/docs/codex/ide 16 OpenAI, “Codex CLI,” ChatGPT Learn. https://learn.chatgpt.com/docs/codex/cli https://learn.chatgpt.com/docs/codex/cli 17 R. Penco, “Writing” project repository. https://github.com/erobpen/Writing https://github.com/erobpen/Writing 18 Git, “Install for Windows.” https://git-scm.com/downloads/win https://git-scm.com/downloads/win 19 Visual Studio Marketplace, “Codex — OpenAI’s coding agent.” https://marketplace.visualstudio.com/items?itemName=OpenAI.chatgpt https://marketplace.visualstudio.com/items?itemName=OpenAI.chatgpt 20 GitHub Docs, “Managing remote repositories.” https://docs.github.com/en/get-started/git-basics/managing-remote-repositories https://docs.github.com/en/get-started/git-basics/managing-remote-repositories 21 Microsoft, “Extension Marketplace,” Visual Studio Code Docs. https://code.visualstudio.com/docs/configure/extensions/extension-marketplace https://code.visualstudio.com/docs/configure/extensions/extension-marketplace 22 GitHub Docs, “Creating an account on GitHub.” https://docs.github.com/en/get-started/start-your-journey/creating-an-account-on-github https://docs.github.com/en/get-started/start-your-journey/creating-an-account-on-github 23 R. Yao, “Celebrating 20 years of Google Translate: Fun facts, tips and new features to try,” Google Blog, Apr. 28, 2026. https://blog.google/products-and-platforms/products/translate/fun-facts-google-translate-20-years/ https://blog.google/products-and-platforms/products/translate/fun-facts-google-translate-20-years/ 24 J. DeCamp, “The Impact of Advances in Neural and Statistical MT on the Translation Workforce,” Proceedings of AMTA 2018, vol. 2: MT Users’ Track, pp. 234–243. https://aclanthology.org/W18-1918/ https://aclanthology.org/W18-1918/ 25 E. D. Yilmaz, I. Naumovska, and V. A. Aggarwal, “AI-Driven Labor Substitution: Evidence from Google Translate and ChatGPT,” INSEAD Working Paper, 2023/24/EFE. https://www.insead.edu/faculty-research/publications/working-papers/ai-driven-labor-substitution-evidence-google-translate https://www.insead.edu/faculty-research/publications/working-papers/ai-driven-labor-substitution-evidence-google-translate 26 M. Roser, “Technology over the long run: zoom out to see how dramatically the world can change within a lifetime,” Our World in Data, Feb. 22, 2023. https://ourworldindata.org/technology-long-run https://ourworldindata.org/technology-long-run 27 OpenAI, “Introducing ChatGPT,” Nov. 30, 2022. https://openai.com/index/chatgpt/ https://openai.com/index/chatgpt/ How can Writers Benefit from AI Agentic Revolution https://pub.towardsai.net/how-can-writers-benefit-from-ai-agentic-revolution-5f9761839f27 was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.