# Writing Published articles for Writing. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How To Write With An LLM DevFeed: [How To Write With An LLM]() Original publisher: [Read original article]() Author: Simon Willison Published: 2026-09-17T23:37:27Z Content type: article Language: en Sources: [Simon Willison's Weblog]() Topics: [Large Language Model](), [Generative AI](), [prompt]() Tags: [ai](), [ai-2-239](), [generative-ai](), [generative-ai-1-985](), [how-to](), [llm](), [llms](), [llms-1-951](), [prompt](), [thomas-ptacek](), [thomas-ptacek-21](), [writing](), [writing-34]() ### AI overview The article discusses using large language models as copyeditors rather than writing assistants. It describes a rule against adopting wording suggested by an LLM, while permitting uses such as fact-checking, spelling, grammar, and occasional thesaurus help. It also mentions a personal copyediting tool and a prompt for building one. ### Source excerpt How To Write With An LLM Thomas Ptacek on using LLMs as copyeditors, not as writing assistants: Rule Number One: You may not use a single word an LLM suggests to you. [...] I think that as a form of intellectual personal protective equipment you should adopt the rule that any specific turn of phrase an LLM suggests is off limits. Be strict about the rule! I won't let LLMs write content for my blog, but I use them for fact-checking, spelling and grammar and as an occasional thesaurus (see my proofreading prompt). The rule to never use a turn of phrase suggested by an LLM feels good to me. The text has that weird smell to it, and it's also a good principle to help stay disciplined. Later in this piece Thomas shows a screenshot of his personal LLM copyediting tool (see also this Twitter thread), and provides a prompt to help kickstart building your own. Tags: thomas-ptacek, writing, ai, generative-ai, llms ## Nail the Narrative DevFeed: [Nail the Narrative]() Original publisher: [Read original article]() Author: Martin Fowler (martin@martinfowler.com) Published: 2026-09-15T15:11:00Z Content type: opinion Language: en Sources: [Martin Fowler]() Topics: [structure](), [Software]() Tags: [design](), [presentation](), [speaking](), [structure](), [writing]() ### AI overview The article argues that presenters should develop a clear narrative before opening slide software. It recommends defining the central idea and audience, shaping a storyline, and creating a lightweight storyboard before designing slides. ### Source excerpt Sumeet Gayathri Moghe finds many folks building presentations get tangled in building slides without a coherent narrative. He advises distilling the big idea, visualizing the audience, and building a structured storyline. more... ## AI Can Help Write an Article, but It Can't Stand Behind It DevFeed: [AI Can Help Write an Article, but It Can't Stand Behind It]() Original publisher: [Read original article]() Author: Raluca Budiu Published: 2026-09-11T17:00:00Z Content type: article Language: en Sources: [NN/g latest articles and announcements]() Topics: [Artificial Intelligence](), [Generative AI](), [User experience (UX)](), [Microsoft]() Tags: [ai](), [ai-authored](), [ai-content](), [ai-editing](), [ai-writing](), [article](), [copilot](), [genai](), [generative-ai](), [microsoft](), [ux](), [writing]() ### AI overview The article explains that NN/G uses AI during its editorial process for writing clarity, formatting, and critique, while humans retain editorial judgment and responsibility for published content. It describes a rigorous review cycle involving topic selection, multiple revisions, and checks for logical coherence, UX accuracy, and copy. AI tools such as Copilot in Microsoft Word and Grammarly help make writing more concise and clear, especially for authors who are not professional writers or speak English as a second language. ### Source excerpt NN/G uses AI for clarity, formatting, and critique, but humans retain editorial judgment and responsibility for every article. ## Why I think we should write our own PR descriptions DevFeed: [Why I think we should write our own PR descriptions]() Original publisher: [Read original article]() Author: Ryan Chandler Published: 2026-09-10T12:15:00Z Content type: opinion Language: en Sources: [Laravel Blog]() Topics: [AI Bots](), [AI Chat]() Tags: [agents](), [claude](), [codex](), [developers](), [pull-request](), [review](), [writing]() ### AI overview The article argues that developers should write their own pull request descriptions even when AI agents implement most of a change. Writing serves as a checkpoint for understanding the change and gives reviewers human context beyond an agent-generated diff summary. ### Source excerpt Agents can write your PR descriptions, but they shouldn't. Here's why writing them yourself makes you a better engineer and a better teammate. ## Unpacking My Bags: How I Found Belonging, Scale, and Real-Time Networking at Cisco DevFeed: [Unpacking My Bags: How I Found Belonging, Scale, and Real-Time Networking at Cisco]() Original publisher: [Read original article]() Author: Altanai Bisht Published: 2026-09-10T12:00:13Z Content type: article Language: en Sources: [Cisco Blogs]() Topics: [WebRTC](), [networking](), [real-time](), [Open Source](), [Software](), [Machine learning]() Tags: [be-you-with-us](), [career-growth](), [engineering](), [lovewhereyouwork](), [networking](), [open-source](), [real-time](), [software](), [streaming](), [voice](), [we-are-cisco](), [wearecisco](), [webrtc](), [women-in-tech](), [writing]() ### AI overview Software engineer Altanai B. describes a non-linear career spanning startups, research and development, product engineering, streaming, telecoms, and Cisco. She reflects on her long-standing curiosity about how real-time networked communications work, including writing a WebRTC guide and building an open-source robot using edge machine learning. ### Source excerpt Software Engineer Altanai B. shares her non-linear career journey and how she finally found a place to unpack her bags and belong at Cisco. ## Why the Author Thinks LLMs Still Struggle with Writing DevFeed: [Why the Author Thinks LLMs Still Struggle with Writing]() Original publisher: [Read original article]() Author: Murat (noreply@blogger.com) Published: 2026-08-31T18:01:30Z Content type: opinion Language: en Sources: [Metadata]() Topics: [Artificial Intelligence](), [Large Language Model](), [Code](), [systems]() Tags: [ai](), [ai-writing](), [code](), [llm](), [writing]() ### AI overview The author argues that LLMs have become effective at generating code but still produce prose that feels formulaic, shallow, and inauthentic. The article attributes this gap partly to writing's subjective and difficult-to-verify nature, and argues that decent writers may remain relatively safe from AI disruption for now. ### Source excerpt Today, tech folk are scrambling to change their workflows to meet newly inflated 5X productivity quotas, while getting pummeled under the cognitive debt of agent-generated code. With every new model release, the gap is widening and humans are becoming more of a bottleneck in the loop, approaching closer to obsolescence as "coders". While the programmer's job description is getting completely refactored, writing remains surprisingly unaffected. LLMs have gotten very good at generating code, but I am appalled at the absolute shit they spew as prose. They always follow the same robotic cadence and cliches, and sprinkle the same tired vocabulary all around. They take my broken yet soulful writing and transform it into a plastic soulless word slop in the name of improving prose. Their writing communicates no actual understanding and insight. I think we are all developing a visceral ick reaction to AI writing. It is trapped in the uncanny valley, and it may be stuck there for a long time. I am increasingly convinced LLMs will not threaten decent writers anytime soon. My prediction rests on the three observations below. Tell me where my logic does not hold up. The plateau on prose The stuck-in-slop state of LLM writing is not from lack of trying. AI labs already tried hard on improving prose and hit a wall. LLM giants would have loved to ship better writing capability to conquer marketing, copywriting, and publishing at zero marginal cost. Look at image, voice, and heck video models. They got good quickly, because they can be scaled with more parameters and compute. Compared to their rapid progress, text models plateaued hard on expression, depth, and authenticity. I think it is wicked hard to bride the final 20% (also applies for image, voice, video models). Writing is a wicked problem In systems theory, a wicked problem is a problem that lacks a definitive formulation, a clear stopping rule, and an objectively correct solution. Writing is the ultimate wicked problem, bec ## The Complete Guide to Writing Effective Software Design Documents DevFeed: [The Complete Guide to Writing Effective Software Design Documents]() Original publisher: [Read original article]() Author: ERDINC MUTLU, PRINCIPAL ENGINEER @ TOPTAL Published: 2026-08-25T04:00:00Z Content type: article Language: en Sources: [Toptal Blog]() Topics: [Architecture & Design](), [Software Engineering](), [coding]() Tags: [architecture](), [design](), [documentation](), [guide](), [software-design](), [software-engineering](), [writing]() ### AI overview A practical guide to writing software design documents that translate high-level requirements into technical blueprints before implementation. It covers the purpose, structure, key sections, common pitfalls, and the role of design documents in creating shared understanding among project stakeholders. ### Source excerpt A software design document turns high-level requirements into a technical blueprint before coding starts. This SDD guide offers writing tips, explains key sections, and flags common pitfalls. ## Please Stop Authoring With Ai DevFeed: [Please Stop Authoring With Ai]() Original publisher: [Read original article]() Author: Author Published: 2026-08-22T01:00:31Z Content type: opinion Language: en Sources: [Posts on AlecStrong]() Topics: [Artificial Intelligence](), [coding]() Tags: [ai](), [coding](), [technical](), [writing]() ### AI overview The author argues that writing, especially technical writing, creates clarity, encourages empathy for readers, substitutes for conversation, and can help regulate emotions. They ask people to stop using AI to author their writing while accepting AI for research, coding, and communication. ### Source excerpt Please Stop Authoring With AI Written word - especially technical writing - has a few particular purposes I find really valuable; When you write something down it creates clarity. You're not just writing, you're reading, you're probably also speaking, you're doing a lot of thinking. The words are both your thoughts and a mechanism to do thinking. You probably reorganize, rewrite, if you're an expert you toil over your words anticipating how someone might interpret them wrong. ## Where I'm Writing Now: The Complete 14-Part BlocSignal Series on DEV.to DevFeed: [Where I'm Writing Now: The Complete 14-Part BlocSignal Series on DEV.to]() Original publisher: [Read original article]() Author: Randal L. Schwartz Published: 2026-08-10T16:00:59Z Content type: opinion Language: en Sources: [Flutter Community - Medium]() Topics: [Flutter](), [Dart](), [reactive](), [Dependency injection](), [OpenTelemetry](), [Web Development]() Tags: [bloc](), [blocsignal](), [dart](), [dependency](), [dev](), [developer-community](), [development](), [flutter](), [series](), [signal](), [state-management](), [tracing](), [writing]() ### AI overview The author announces that DEV.to and the Google Developer Experts organization on DEV.to are now the primary publishing hubs for new technical writing. The article presents a 14-part BlocSignal series covering Dart and Flutter state management, architecture, interoperability, dependency injection, tracing, and web development. ### Source excerpt If you've been following my articles here on Medium over the years, thank you! I wanted to share a quick update on where I'm primarily publishing my new technical deep dives, architectural guides, and Flutter/Dart tutorials. Going forward, my primary writing hub is DEV.to (@randalschwartz) and the official Google Developer Experts (GDE) organization on DEV.to. DEV.to provides a vibrant developer community, native Dart syntax highlighting, and a built-in Series feature that links connected articles into structured, multi-part curricula. ๐Ÿš€ The New Series: BlocSignal Architecture & Practice Over the last month, my team and I launched BlocSignal -- a production-grade state management framework for Dart and Flutter that bridges BLoC's enterprise discipline with Signals' 0ms synchronous reactivity. We've published a comprehensive 14-part series on DEV.to covering everything from core state machine philosophy and Riverpod/Provider interop to dependency injection, OpenTelemetry tracing, and Jaspr web development. Here is the complete roadmap of all 14 articles available to read right now on DEV.to: ๐Ÿ› 1. Core Architecture & Philosophy Introducing BlocSignal: Unidirectional Data Flow Meets Reactive Signals The origin story: bridging BLoC semantics with Rody Davis's signals v7 primitives for 0ms microtask queue latency. BLoC meets Signals: How to Pitch BlocSignal to Your Dev Leads How to navigate technical team reviews and explain the enterprise value of synchronous signal graphs. How We Achieved Full BLoC API & Protocol Parity in BlocSignal 0.2.0 A deep dive into BlocProvider, BlocBuilder, BlocListener, BlocConsumer, and context.select parity. Beyond ProviderNotFound: How BlocSignal Rethinks State Location and Synchronous Propagation Solving scope lookups and understanding why synchronous signal updates prevent frame tearing. From Raw Signals to BlocSignal: Taming Reactivity for Enterprise Scale How encapsulating signals inside Cubit/Bloc containers stops global signal "spagh ## Why I'm Writing Rachel's Ramblings DevFeed: [Why I'm Writing Rachel's Ramblings]() Original publisher: [Read original article]() Author: Rachel Laycock (rlaycock@thoughtworks.com) Published: 2026-07-28T12:32:00Z Content type: opinion Language: en Sources: [Martin Fowler]() Topics: [rachels-ramblings](), [Software]() Tags: [industry](), [leadership](), [rachels-ramblings](), [software](), [writing]() ### AI overview Rachel's Ramblings introduces a series in which Rachel shares early, imperfect thoughts about patterns and hypotheses she sees across clients, teams, and the software industry. ### Source excerpt TL;DR I have ideas. I haven't been writing them. That's about to change. I promise... myself. I've been thinking a lot about talent. Actually, I've been thinking a lot about thinking. And writing. Or more specifically, not writing. This really hit me earlier this year at the Future of Software conference. I was surrounded by people sharing their latest ideas and I had a slightly uncomfortable realization: I have my own. Not just opinions. Actual patterns. Hypotheses. Things I'm seeing across clients, across teams, across the industry that feel new or at least not well articulated yet in a way that a leader can think about and act upon in some way that can influence how they strategise and plan for the future. Because helping clients and other leaders internal and external to thoughtworks do this is actually a big part of what I do and without letting my northern humbleness get in my own way, I'm actually pretty good at it. If I wasn't I wouldn't be the global CTO of a future thinking tech org, you know the kind that has Martin Fowler as its Chief Scientist. A title I know he loves... Martin, by the way, is one of the people pushing me to do this, which is weird because on paper I'm his boss but I don't believe in the traditional idea of a boss anyway. I'm a strong believer in the servant leadership type but I'll save that for when I write about that. Anyway the point is for all the ideas I have and discussion I have I don't do a good job of writing it down. At best I'll stick it in a presentation deck when I'm forced to communicate with them in some forum or another. I hate decks and love writing so I'm obviously doing something wrong. So why haven't I been writing? It's easy to say I've been too busy. I don't have an easy job. It's a fun one but not easy. I also have two small children, 5 and 8. In case you are interested, I attempt to give as much time as possible to this busy job. And then I try to have a life. I'm also writing an epic world building sci-fi fantasy b ## Clear Writing and Credibility Matter More Amid AI-Generated Text DevFeed: [Clear Writing and Credibility Matter More Amid AI-Generated Text]() Original publisher: [Read original article]() Author: Gregor Ojstersek Published: 2026-07-24T19:09:49Z Content type: opinion Language: en Sources: [Engineering Leadership]() Topics: [Artificial Intelligence]() Tags: [ai](), [communication](), [writing]() ### AI overview The article argues that the rise of AI-generated text increases the importance of clear writing, credibility, and thoughtful communication. ### Source excerpt There is a flood of AI-generated text. That makes clear writing, credibility, and thoughtful communication matter more than ever. ## A fresh start for michaelcrump.net and a return to writing in public DevFeed: [A fresh start for michaelcrump.net and a return to writing in public]() Original publisher: [Read original article]() Published: 2026-07-22T20:30:14Z Content type: opinion Language: en Sources: [Michael Crump]() Topics: [Website](), [GitHub Pages](), [Development](), [Tooling]() Tags: [development](), [github-pages](), [public](), [writing]() ### AI overview The author introduces a newly simplified michaelcrump.net, built with static pages, a small stylesheet, and GitHub Pages. The site will share practical notes about software development, developer tools, AI, and ongoing experiments. ### Source excerpt A fresh start for michaelcrump.net and a return to writing in public. ## A return to two-pizza culture DevFeed: [A return to two-pizza culture]() Original publisher: [Read original article]() Author: werner@allthingsdistributed.com (Dr. Werner Vogels) Published: 2026-06-30T14:00:00Z Content type: article Language: en Sources: [All Things Distributed]() Topics: [amazon](), [Code]() Tags: [amazon](), [organizational](), [posts](), [process](), [product](), [writing]() ### AI overview The article revisits Amazon's two-pizza team model, emphasizing small autonomous teams, end-to-end ownership, rapid reversible decisions, experimentation, and customer-focused product development through the Working Backwards process. It also explains how organizational growth, service dependencies, and approval cycles can reduce delivery speed. ### Source excerpt What made the Quick desktop team successful is the same thing that has always produced the best work I've seen at Amazon: a small group of people who trusted each other, owned the problem end-to-end, and acted on their conviction. ## Meeting Notes - A Free Desktop App for Tracking 1:1s DevFeed: [Meeting Notes - A Free Desktop App for Tracking 1:1s]() Original publisher: [Read original article]() Author: Dean Hume Published: 2026-06-29T10:16:48Z Content type: article Language: en Sources: [Dean Hume]() Topics: [App](), [meetings](), [Local-First](), [asr](), [Whisper](), [Open Source](), [Markdown]() Tags: [app](), [autosave](), [desktop](), [free](), [meetings](), [notes](), [offline](), [on-device](), [open-source](), [recording](), [speech-to-text](), [technical-leadership](), [technical-program-manager](), [whisper](), [writing]() ### AI overview The article introduces Meeting Notes, a free, open-source Windows desktop app for organizing 1:1 notes by person. It supports topic tags, Markdown, autosave, voice recording, and offline speech-to-text using Whisper, with data and audio kept on the device. ### Source excerpt Meeting Notes is a free offline desktop app for 1:1s. Organise notes by person, tag topics, and transcribe meetings on-device with Whisper. ## Logic for Programmers extra credits DevFeed: [Logic for Programmers extra credits]() Original publisher: [Read original article]() Author: Hillel Wayne Published: 2026-06-02T14:48:48Z Content type: article Language: en Sources: [Newsletter feed for Hillel Wayne's Newsletter]() Topics: [Math and Logic](), [Concurrent Programming]() Tags: [book](), [concurrent](), [math](), [writing]() ### AI overview The author announces four supplementary pieces for Logic for Programmers covering concurrent-process orderings, first-order logic and sets of functions, Liskov's history rule in subtyping, and orders on sets. The supplements contain roughly 2,000-3,000 words of math content and may be less polished than the book. ### Source excerpt So I said there wasn't a proper newsletter this week, since I'm in Budapest prepping for a conference. But I still got a thing for y'all. There's a lot of interesting topics I wanted to cover for Logic for Programmers, but the book is dense enough as it is and many of these were too tangential or technical to fit in well. So I've been writing some supplements and uploading them here. I've got four so far: How we compute the number of orderings of multiple concurrent processes How first-order logic can quantify over "a set of functions", what a "set of functions" looks like, and how functions can be defined in terms of sets (plus a bit on currying and type theory) Barbara Liskov's "history rule" in subtyping Total and partial orders on sets. Now I'm going to caveat that these were written off the cuff and haven't gone through the obsessive editing of the book itself, so they may be rough and there might be errors in them. Still, it's like 2-3000 words of math content, so hopefully covers not having a proper newsletter this time. Seeya next week! ## Knowing about things is cheaper than knowing things DevFeed: [Knowing about things is cheaper than knowing things]() Original publisher: [Read original article]() Author: Hillel Wayne Published: 2026-05-28T16:03:01Z Content type: article Language: en Sources: [Newsletter feed for Hillel Wayne's Newsletter]() Topics: [math](), [Programming](), [Learning]() Tags: [learning](), [math](), [programming](), [writing]() ### AI overview The article argues that programmers benefit from broad exposure to many areas of mathematics and other knowledge, while only needing to study topics in depth when they are relevant to their domain. It distinguishes mathematics useful to all programmers from fields useful mainly to particular programmers, and recommends introductory resources and conference videos for broad learning. ### Source excerpt Short one this week because I'm way behind on book and conference prep. Last week a LinkedIn Influencer wrote about how math has nothing to do with programming, so I spite-wrote a rejoinder about how math is necessary to program (just try to write software without knowing arithmetic!) and man I forgot how much spite can fuel writing. Maybe I should go back to Twitter (absolutely not). But it got me thinking about the difference between "all programmers can benefit from learning math" and "all programmers need to learn math". I simultaneously believe three things: There is some math, like arithmetic (incl. arithmetic of booleans, sets, functions, etc), that is useful to all programmers. The remaining fields aren't useful to most programmers. Every programmer works in a domain where there is at least one branch of math that would benefit them to learn. (2) means that if get a group of 100 software engineers and teach them something like algebra or calculus, you can't expect it to be applicable for more than 3 or 5. Whereas if you teach something like shell scripting or regular expressions it'd be useful to at least, like, 50. So no field of math has a good RoI for the average programmer. (3) means that each of those 100 developers could, on their own, find a field of math that is useful to them. In order to do that, though, they need to roughly know what the fields are, what the big ideas are, and where they might be useful. It is more useful to teach them about many fields than to teach them any one specific field in-depth. I think that's generally true with most areas of knowledge! Getting basic exposure to something takes a lot less time and effort than learning it in-depth. If you're specifically trying to learn things that will be useful to your work1, you only want to go in-depth on topics you know will be helpful. But you won't know the topic is helpful (or even that it exists) unless you know the very basics already. So it makes sense to get broad exposure to ## LLMs changed writing. But our submission processes haven't caught up. DevFeed: [LLMs changed writing. But our submission processes haven't caught up.]() Original publisher: [Read original article]() Author: Mike Yerou Published: 2026-05-28T12:55:38Z Content type: opinion Language: en Sources: [Rock and Null]() Topics: [LLMs](), [Artificial Intelligence](), [Requirements]() Tags: [ai](), [artificial-intelligence](), [communication](), [evaluation](), [llms](), [optimize](), [submission](), [thoughts](), [writing]() ### AI overview The article argues that LLMs have changed how people create, communicate, and evaluate written information, while many submission and proposal processes still assume that long documents reflect substantial human effort. It recommends prioritizing clarity, concise summaries, key decisions, tradeoffs, and actionable information over document length. ### Source excerpt LLMs are changing how we write, communicate, and evaluate information, but many submission and proposal processes are still designed for a pre-AI era. If AI generates documents and is later summarized by AI, maybe it's time to optimize for clarity, bullet points, and essence instead of length. ## Stop Writing RFCs Like Mystery Novels: Why the Best Design Docs Start with the Conclusion DevFeed: [Stop Writing RFCs Like Mystery Novels: Why the Best Design Docs Start with the Conclusion]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-05-17T00:00:00Z Content type: opinion Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Documentation](), [Requirements](), [Latency](), [Network](), [Back end](), [structure]() Tags: [architecture](), [backend](), [communication](), [conclusion](), [context](), [database](), [docs](), [documentation](), [how-to](), [latency](), [network](), [rfc](), [systems-design](), [writing]() ### AI overview The article argues that RFCs and architecture documents should begin with the conclusion and proposed architecture. It says burying key design decisions in background material overloads reviewers' working memory, encourages superficial approval, and can hide important network and latency risks. ### Source excerpt Reviewers pipeline like CPUs. Hide the proposed architecture on page seven and they load context with no index to file it under, saturate working memory, then skim and rubber-stamp. Invert the structure: conclusion, architecture diagram, hardware and latency impact, then background and rejected alternatives last, so reviewers spend their attention interrogating your network boundaries instead of solving a literary puzzle. ## Why Fidelitas.io Is Starting a Technology Blog in 2026 DevFeed: [Why Fidelitas.io Is Starting a Technology Blog in 2026]() Original publisher: [Read original article]() Author: fidelitas.io Published: 2026-05-12T07:00:00Z Content type: opinion Language: en Sources: [fidelitas.io]() Topics: [Programming](), [Tooling](), [incident](), [Command-line interface](), [RSS Feed]() Tags: [blog](), [cli](), [incident](), [meta](), [monitoring](), [programming](), [programming-blogs](), [rss](), [software-craft](), [technology](), [writing]() ### AI overview The author introduces Fidelitas.io, a new technology blog intended to publish candid field notes, tooling reviews, deep dives, and occasional essays based on software engineering work. The site will have no business model, tracking, newsletter, or advertising incentives, and will offer RSS subscriptions. ### Source excerpt Why I'm starting another technology blog in 2026, and what I'm hoping to do differently this time. ## How to prepare presentation for a Conference DevFeed: [How to prepare presentation for a Conference]() Original publisher: [Read original article]() Author: Tom Published: 2026-05-04T00:00:00Z Content type: tutorial Language: en Sources: [Tomasz Gฤ…gor]() Topics: [.NET Conf](), [Tool]() Tags: [career-growth](), [communication-skills](), [conference-preparation](), [conference-presentation](), [how-to](), [narrative-throughline](), [pitching](), [presentation](), [presentation-design](), [public-speaking](), [storytelling](), [structure](), [writing]() ### AI overview A practical guide to preparing conference presentations by starting with a clear pitch, developing a narrative throughline, structuring the story, prioritizing clarity, and using slides as visual support. ### Source excerpt Learn how to build impactful conference presentations by focusing on storytelling, narrative throughlines, and audience experience rather than just slides. ## Writing with ChatGPT DevFeed: [Writing with ChatGPT]() Original publisher: [Read original article]() Published: 2026-04-10T00:00:00Z Content type: article Language: en Sources: [OpenAI News]() Topics: [ChatGPT](), [Prompt Engineering]() Tags: [chatgpt](), [communication](), [content](), [generate](), [how-to](), [openai-academy](), [prompt-engineering](), [review](), [workflow](), [writing]() ### AI overview Learn how ChatGPT can help draft, revise, and refine workplace writing while preserving clarity, tone, audience awareness, and intent. The article presents a practical Plan -> Draft -> Revise -> Package workflow and emphasizes providing context, constraints, format, and targeted feedback. ### Source excerpt Learn how to use ChatGPT for writing to draft, revise, and refine content with clear structure, tone, and intent. ## Using projects in ChatGPT DevFeed: [Using projects in ChatGPT]() Original publisher: [Read original article]() Published: 2026-04-10T00:00:00Z Content type: tutorial Language: en Sources: [OpenAI News]() Topics: [ChatGPT](), [spaces](), [Availability]() Tags: [availability](), [chatgpt](), [how-to](), [memory](), [openai-academy](), [spaces](), [work](), [writing]() ### AI overview This guide explains how Projects in ChatGPT organize chats, files, instructions, and related context in dedicated spaces for ongoing work. It covers creating projects, adding materials, moving existing chats, inviting collaborators when available, workspace-level management for Enterprise customers, and project-only memory. ### Source excerpt Learn how to use projects in ChatGPT to organize chats, files, and instructions, manage ongoing work, and collaborate more effectively. ## Learn ChatGPT workflows for marketing teams DevFeed: [Learn ChatGPT workflows for marketing teams]() Original publisher: [Read original article]() Published: 2026-04-10T00:00:00Z Content type: tutorial Language: en Sources: [OpenAI News]() Topics: [ChatGPT](), [data]() Tags: [analysis](), [chatgpt](), [communication](), [content](), [creativity](), [efficiency](), [launch](), [marketing](), [openai-academy](), [performance](), [review](), [speed](), [strategy](), [testing](), [workflows](), [writing]() ### AI overview Practical guidance for marketing teams using ChatGPT across campaign planning, content creation, messaging, testing, launches, and performance analysis. It emphasizes iterative collaboration, faster workflows, clearer communication, and human review of accuracy and final decisions. ### Source excerpt Learn practical ChatGPT workflows for campaign planning, research, content creation, and performance analysis, with next steps for business teams. ## ChatGPT for customer success teams DevFeed: [ChatGPT for customer success teams]() Original publisher: [Read original article]() Published: 2026-04-10T00:00:00Z Content type: article Language: en Sources: [OpenAI News]() Topics: [ChatGPT](), [Messaging]() Tags: [chatgpt](), [churn](), [communication](), [content](), [customer](), [executive](), [learn](), [onboarding](), [openai-academy](), [product](), [reduce](), [research](), [tool](), [work](), [writing]() ### AI overview This article explains how customer success teams use ChatGPT to manage account context, improve customer communication, standardize recurring workflows, and support onboarding, renewals, escalations, and executive check-ins. ### Source excerpt Learn how customer success teams use ChatGPT to manage accounts, improve communication, reduce churn, and drive adoption and renewals. [Next page]()