{"slug": "how-can-writers-benefit-from-ai-agentic-revolution", "title": "How can Writers Benefit from AI Agentic Revolution", "summary": "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.", "body_md": "Roberto Penco, PhD\n\nAgentic 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.\n\n**AI Writing Is Part of a Longer History**\n\nMany 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.\n\nBut the history of writing is also the history of tools entering the process.\n\nBefore 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].\n\nThen 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.\n\nThat 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.\n\nLarge 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].\n\nAt this point, one distinction matters. Chatbot-based AI-assisted writing and SDA are not the same thing.\n\nChatbot 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.\n\nSDA 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.\n\nThis 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.”\n\nThat 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.\n\nThis 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.\n\nBut here is the danger: a computer that accepts natural language is still not human.\n\nEngineers 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.\n\nThat 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.\n\nNor 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].\n\nI 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.\n\nMy answer is Specification-Driven Authoring.\n\nThe 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.\n\n**What Specification-Driven Authoring Means**\n\nSpecification-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.\n\nThat 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.\n\nIn ordinary prompting, the writer might say:\n\nWrite an article about the future of writing with AI.\n\nThe 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.\n\nIn SDA, the writer and AI first build a shared document that answers questions such as:\n\n- Who is this article for?\n\n- What problem is it trying to solve?\n\n- What is the central claim?\n\n- What should the article not claim?\n\n- What sources are required?\n\n- Which claims are facts, interpretations, or original proposals?\n\n- What figures are needed?\n\n- What tone should the article use?\n\n- What workflow should the AI follow?\n\n- What counts as done?\n\nOnly after that specification is mature does the writer approve it for article production.\n\nidea -> specification -> approval -> outline -> draft -> review -> revision -> final article\n\nThe 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.\n\n**The Specification Is the Source of Truth**\n\nIn SDA, the specification is the contract between human intent and AI output.\n\nIt does not need to be complicated. A useful article specification can include:\n\n- **Purpose: **why the article exists.\n\n- **Target reader:** who should benefit from it.\n\n- **Core thesis:** the main argument.\n\n- **Article balance:** how much space each part should receive.\n\n- **Voice:** personal essay, practical guide, technical tutorial, or another mode.\n\n- **Claims:** what the article wants to say.\n\n- **Evidence rules:** which claims need external sources.\n\n- **Open questions:** what is still unresolved.\n\n- **Image plan:** what each figure should explain.\n\n- **Publishing constraints:** publication guidelines, style requirements, and reference format.\n\n-**Workflow rules:** how the AI should ask questions, edit files, save versions, and produce drafts.\n\nThis 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.\n\n**The AI Has Roles, but the Writer Keeps Authority**\n\nIn SDA, the AI can do many useful things:\n\nBut these are supporting roles. The writer remains the author.\n\nThe 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.\n\nThis 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.\n\n**SDA Separates Types of Claims**\n\nOne of the biggest risks of AI writing is unsupported confidence.\n\nA 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:\n\nThis 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.\n\nThe point is not to eliminate original thought. The point is to stop factual claims, interpretations, and inventions from wearing the same costume.\n\nSDA 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.\n\n**SDA Has Several Flows**\n\nFrom one angle, SDA is a conversation flow:\n\nAI asks -> writer answers -> AI proposes -> writer approves -> AI edits\n\nFrom another angle, it is a production flow:\n\nspecification -> research plan -> sources -> outline -> draft -> review -> revision -> final\n\nFrom a third angle, it is a control flow:\n\nhuman intent -> explicit specification -> reviewable AI work -> human approval\n\nFrom a fourth angle, it is a safety flow:\n\nclaim -> source check -> citation or reframe -> version save -> final review\n\nThese flows are useful because different problems appear at different moments.\n\nIf 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.\n\nSDA is not meant to make writing mechanical. It is meant to make collaboration with AI legible.\n\n**A Practical Setup for Writers**\n\nThere should be a dedicated writing application that does all of this out of the box.\n\nA 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.\n\nBut until that application exists, we can borrow the developer workflow and translate it into writer language.\n\nThe setup I am suggesting is:\n\nThis is not the only possible setup. Future articles will explore other variants. For now, it is a practical path that you can use today.\n\n**Set Up the Workspace on Windows**\n\nThis 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.\n\nThe 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.\n\n**1. Install VS Code**\n\nDownload VS Code from the official [download page](https://code.visualstudio.com/download):\n\nChoose 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].\n\nRun the installer and accept the normal defaults. When it finishes, open VS Code from the Windows Start menu.\n\n**2. Install Codex from the VS Code Extensions Button**\n\nIn 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].\n\nOpenAI’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.\n\n**3. Create a GitHub Account**\n\nOpen a browser and go to the [GitHub signup page](https://github.com/signup):\n\nCreate 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].\n\nFor 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.\n\nThis 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.\n\n**4. Create the Writing Folders in Windows Explorer**\n\nNow use Windows File Explorer, not a terminal.\n\nThe folder structure should begin like this:\n\n**5. Add the SDA Skill File**\n\nBefore asking Codex to set up the project, put the reusable SDA workflow file into the root `Writing` folder.\n\nThis article’s project repository contains the reusable file [17]. Go to [my GitHub repository](https://github.com/erobpen/Writing).\n\nFind `SDA_SKILL.md`. Save or copy it into the `Writing` folder, beside the `Name of your Article` folder.\n\nOne 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`.\n\nThe `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.\n\nThis 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.\n\nThis 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.\n\n**6. Open the Writing Folder in VS Code**\n\nNow return to VS Code.\n\nVS Code should show `SDA_SKILL.md` and the `Name of your Article` folder in the file explorer on the left.\n\nInside VS Code, create the first specification file:\n\n**7. Give Codex the Setup Prompt**\n\nAt this point, the writer has done the Windows tasks. Now Codex can do the technical setup.\n\nOpen 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.\n\nRead SDA_SKILL.md and the article folder “Name of your Article”.\n\nI am a writer, not a developer.\n\nPlease set up this Writing folder for Specification-Driven Authoring.\n\nFirst, check that “Name of your Article/00_SPEC.md” exists.\n\nIf it does not exist, create it.\n\nThen set up Git versioning for this Writing folder.\n\nUse writer-friendly language:\n\n- Save Version = create a local Git checkpoint\n\n- Compare Versions = show what changed\n\n- Restore Previous Version = recover an older checkpoint, but only after asking me\n\n- Publish Backup to GitHub = push a saved version to GitHub\n\nIf Git is missing, explain what is missing and ask me before installing or changing anything.\n\nIf GitHub setup requires a repository or login, guide me step by step in the browser.\n\nDo not draft the article yet.\n\nAfter setup, ask me one focused question to start the specification.\n\nThis 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.\n\nIf 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.\n\n**8. What Success Looks Like**\n\nWhen setup is complete, the writer should be able to use ordinary commands in conversation with Codex:\n\nLater, after the specification is approved, the article folder can grow into:\n\nName of your Article/\n\n| — 00_SPEC.md\n\n| — 01_RESEARCH_PLAN.md\n\n| — 02_SOURCES.md\n\n| — 03_OUTLINE.md\n\n| — 04_DRAFT.md\n\n| — 05_IMAGE_PROMPTS.md\n\n| — 06_EDITORIAL_REVIEW.md\n\n| — 07_REVISION_PLAN.md\n\n| — 08_FINAL.md\n\n` — Images/\n\nThe 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.\n\nThis 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.\n\n**Use the SDA Workflow**\n\nOnce the setup exists, the daily workflow is not technical. It is editorial.\n\nOpen the article folder in VS Code. Ask Codex to read the reusable SDA workflow and the article specification. Then follow this loop:\n\nread specification -> ask one question -> writer answers -> propose edit -> writer approves -> edit specification -> Save Version\n\nThe “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.\n\nThe 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.\n\nRepeat this until the specification is strong enough.\n\nThen the writer explicitly approves the specification for article production. At that point, the AI can create:\n\nThis 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.\n\n**Use Writer-Friendly Versioning**\n\nDevelopers say “commit,” “diff,” “restore,” and “push.” Those words are useful, but they are not necessary for writers.\n\nWriters can use clearer commands:\n\n**Save Version** means create a local checkpoint. Use it after important decisions, specification changes, drafts, reviews, and final revisions.\n\n**Compare Versions** means inspect what changed. This is how the writer checks whether the AI changed only what was approved.\n\n**Restore Previous Version** means recover an earlier checkpoint. This should require explicit confirmation because it can replace current work.\n\n**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.”\n\nThis 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.\n\n**Verify Claims Before Publication**\n\nSource verification should be part of the workflow, not an afterthought.\n\nFor each substantive claim, ask:\n\nIf 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.\n\nThe 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.\n\n**Review Against the Specification**\n\nAfter the draft exists, do not only ask, “Is this good?”\n\nAsk:\n\nThe specification becomes the ruler. The draft is measured against it.\n\nThat is the core discipline of SDA.\n\n**What This Changes**\n\nThe usual fear is that AI will replace the writer. SDA points in another direction.\n\nIt treats AI as a powerful assistant, but it also gives the writer a structure:\n\nThis 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.\n\nSDA adds the boundary back.\n\nIt 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.\n\nThat is not cheating. That is a writing process.\n\n**Conclusion**\n\nThe 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.\n\nBut that collaboration needs discipline.\n\nThere 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.\n\nI 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].\n\nSo 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.\n\nBut 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.\n\nThat 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.\n\nSpecification-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.\n\nThis 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.\n\nThe 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.\n\nUntil then, we can borrow the developer workflow and make it humane for writers.\n\n**References**\n\n[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)\n\n[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/)\n\n[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)\n\n[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)\n\n[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/)\n\n[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/)\n\n[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)\n\n[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)\n\n[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/)\n\n[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)\n\n[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)\n\n[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)\n\n[13] Microsoft, “Source Control in VS Code.” [https://code.visualstudio.com/docs/sourcecontrol/overview](https://code.visualstudio.com/docs/sourcecontrol/overview)\n\n[14] Microsoft, “Installing Visual Studio Code on Windows.” [https://code.visualstudio.com/docs/setup/windows](https://code.visualstudio.com/docs/setup/windows)\n\n[15] OpenAI, “Codex IDE extension,” ChatGPT Learn. [https://learn.chatgpt.com/docs/codex/ide](https://learn.chatgpt.com/docs/codex/ide)\n\n[16] OpenAI, “Codex CLI,” ChatGPT Learn. [https://learn.chatgpt.com/docs/codex/cli](https://learn.chatgpt.com/docs/codex/cli)\n\n[17] R. Penco, “Writing” project repository. [https://github.com/erobpen/Writing](https://github.com/erobpen/Writing)\n\n[18] Git, “Install for Windows.” [https://git-scm.com/downloads/win](https://git-scm.com/downloads/win)\n\n[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)\n\n[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)\n\n[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)\n\n[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)\n\n[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/)\n\n[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/)\n\n[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)\n\n[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)\n\n[27] OpenAI, “Introducing ChatGPT,” Nov. 30, 2022. [https://openai.com/index/chatgpt/](https://openai.com/index/chatgpt/)\n\n[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.", "url": "https://wpnews.pro/news/how-can-writers-benefit-from-ai-agentic-revolution", "canonical_source": "https://pub.towardsai.net/how-can-writers-benefit-from-ai-agentic-revolution-5f9761839f27?source=rss----98111c9905da---4", "published_at": "2026-07-26 19:01:01+00:00", "updated_at": "2026-07-26 19:32:55.084167+00:00", "lang": "en", "topics": ["artificial-intelligence", "generative-ai", "ai-tools", "ai-agents", "large-language-models"], "entities": ["Roberto Penco", "OpenAI", "ChatGPT", "GPT-3"], "alternates": {"html": "https://wpnews.pro/news/how-can-writers-benefit-from-ai-agentic-revolution", "markdown": "https://wpnews.pro/news/how-can-writers-benefit-from-ai-agentic-revolution.md", "text": "https://wpnews.pro/news/how-can-writers-benefit-from-ai-agentic-revolution.txt", "jsonld": "https://wpnews.pro/news/how-can-writers-benefit-from-ai-agentic-revolution.jsonld"}}