I’ve noticed something interesting around all the conversations on AI these days. The issue isn’t necessarily new, but I guess I now finally have an opinion on it since I live in both worlds.
If you follow technology, it’s obvious now that many software engineers speak openly about handing over their coding tasks to AI agents. And most of them are praised for that move. On the other hand, writers who use similar AI tools to draft their prose usually get a vastly different response. They actually face harsh and sometimes nasty criticism. Why the difference? Both groups use AI technologies, yet the social judgment for each runs in radically different directions. Sure, the two crafts share some things in common, but they certainly aren’t exactly the same and comparing the two is difficult. So, does the disparate reaction really represent a double standard? Let’s see.
How Developers Worked Before AI
Go back. Picture how developers built software before AI. Roughly speaking, they started with a problem, broke it into pieces, and thought through the architecture before typing any code. They chose data structures, wrote functions, planned testing, and reviewed edge cases with team members. When the code failed they read the errors, found the bugs, and fixed them. They reviewed their own work and asked colleagues for reviews as well. Every choice in the finished code passed through the developer, the team, and various systems. Human judgment stayed right at the center. The process was slower by today’s standards, but that slower pace often forced developers to think carefully about what they were building before anything integrated into the final product and shipped to customers.
How AI Changed the Developer’s Process
Compare that older process with how many developers work today with AI. They still start with a problem and break the work into pieces. The difference now, though, is that they write detailed prompts into an AI system instead of writing their own code. A prompt can name the files, state the tech stack, describe the desired behavior, and list any constraints. An AI tool then produces a draft, sometimes across many files that touch many parts of the system. Developers review the output, run the tests, fix errors, update the code, and tighten the result. They iterate with the AI as needed by refining prompts or making direct edits to the code themselves. For routine tasks such as boilerplate, tests, or simple refactors, the AI seems to save time.
Moving up to more complex logic or significant architectural decisions, developers still largely do much of the thinking and remain responsible for the final code. But recently the job has shifted significantly toward directing multiple AI systems up front and verifying outputs at the end. Of course, careful review remains essential for serious work. This is generally described as managing agents, and it’s characterized as a sign of technical sophistication. But a smaller group of developers say they now rarely open the generated files at all because they believe the systems are reliable enough. That more extreme group sometimes draws criticism within engineering teams if developers can’t explain or fully own the result. Nevertheless, this trend toward the edge continues and seems to be increasing. Will it mark the new standard in the years to come? There are good arguments on both sides.
How Writers Used to Work Before AI
Now let’s shift to writers. They went through something similar to engineers but on their own, much longer timeline. For them the old way meant research, outlining, interviewing, drafting, and editing using their own editorial or manual tools. Writers wrestled with ideas for days or even longer before they carefully crafted concepts or scenes onto the page. They revised their text, cut what didn’t work, and sharpened what did. This iterative process could go on for quite some time during the drafting process. Aside from formal copy editing that came later, the voice on the page belonged exclusively to the writer because every word was crafted by hand.
How AI Changed the Writer’s Process
Modern AI systems changed all of that. Writers can now hand an AI their rough notes, ask for some background research, and get a full draft back in mere minutes. That may be an oversimplification, but it’s not that far off. From there they can edit to whatever degree they want to make sure that more of their own voice survives from the original AI-generated text. So, the starting point for writers has moved from a blank page to a rough draft or even sometimes a seriously advanced machine-generated draft extremely quickly. That shift is similar to a developer’s starting point moving from a blank file to a block of generated code that just works as specified.
Reactions to the Two Fields Split Radically
The two examples above aren’t exhaustive or even totally parallel, of course. Developers are much more used to automated systems that aid in building software, whereas writers have not traditionally had tools capable of generating substantial amounts of finished prose immediately. Here’s where the paths split significantly. It’s not really in the work itself but instead in how the world responds to the work and the behavior of the people initiating the work.
When developers say their agents wrote most or all of their code, people in the field and observers online often call it efficient and innovative. Companies hold it up as the future because faster delivery requiring lower headcount translates into competitive advantages in the marketplace. That argument is pervasive right now. And engineers who still code everything by hand often hear that they’re falling behind the times. So the bias toward using AI is the clear standard for software development.
However, if writers say the same thing the reaction totally flips. If writers brag that AI drafted a chapter, even one rewritten by hand many times, readers and critics immediately express outrage. Editors ask questions they’d never ask developers. Some publications ban the practice outright. Many schools do as well. The finished piece gets picked apart for tells, real or imagined, in a way finished code rarely does.
To give just a small example of how fast this issue changed on the tech side and how it still lags on the editorial side, check this out. We were told at my last job just last year that we were forbidden to use AI for anything, and then just a year later, virtually overnight, we were required to use AI for pretty much everything. Rapid changes in strategy like that is normal for tech. The editorial community, however, still grapples with even touching AI for any of their tasks.
Why the Judgment Differs
Part of this disparity comes from how each field values quality work. Computer code has a clearer set of qualifications. It runs or it doesn’t. It passes the tests or it doesn’t. Users either get what they need or they don’t. But prose has no such test. Readers respond to the human voice and the sense that a particular writer shaped those particular words. And that feeling seems pretty sensitive. If readers and editors learn that a machine had a hand in the editorial process then the literary spell breaks, even when the finished text shows no obvious signs of having been produced by a computer.
There’s another piece to this puzzle, though. Code has always been written primarily for a machine to execute. A developer might read it later, but the first audience was the compiler. Success meant the machine did what it was told to do. Prose never worked that way. It was generally written by one person for another person. It only started drifting toward a machine audience recently, first for search engine optimization and now for AI systems that write, summarize, and reuse text.
That difference in history helps explain part of the discomfort readers feel when they consume AI content. Writers may not realize this but engineers using AI agents are actually extending a close relationship with machines that already existed. Developers have always used the latest tools to help in the code writing process. But writers leaning on AI are now altering a world that used to belong almost entirely to readers. And readers can feel that shift even when they can’t always name it clearly.
The tools themselves are also at different stages. AI coding assistants have become reliable enough for real production work on many routine tasks and even some advanced ones. But the ways developers can test and evaluate generated code are often more concrete than the ways writers can evaluate the quality of generated prose. That line for writers seems more distinct and rigid. For now, anyway.
Internal Standards in Software
But even inside the software industry a version of this line already exists. Programmers who let agents generate code without closely reading or understanding it are often described as vibe coders, and plenty of other engineers still push back hard against the practice. For them their standard sounds a lot like the one writers get held to.
If you review what the AI produced, test it, and can explain how it works, that counts as real development no matter how much the AI contributed. If you can’t do any of that, though, it doesn’t count. Writers face nearly the identical test. The difference is where the line sits and how easily it’s moved. Inside engineering, plenty of AI use still clears the bar and earns credit. But in writing, even heavily revising an AI draft, it seems that writers can’t clear the line at all, at least not in the eyes of the people judging the finished product.
That explanation only goes so far, though. It doesn’t fully account for why engineers who fail their own field’s test, the ones who openly say they barely glance at the code, sometimes still receive praise for their candor or for embracing the future. Writers would likely face a much different reaction for the same admission. So although the work has moved in the same direction in both fields, the judgment certainly hasn’t.
Where Pride in Craft Can Move
None of this is new to developers. Long before AI, many engineers took real pride in writing their own code, not just in what it did. They argued over whose solution was cleaner. They refused to publish something messy. An ugly or inefficient implementation was an embarrassment even when it worked. They took pride in authorship with the same instinct that drives writers to protect phrases, sentences, and characters. The difference between the fields was never that developers lacked that instinct. It’s that the instinct had somewhere else to go once AI arrived. And this is a subtle point that the editorial community doesn’t get yet.
For many developers, though, the code was always a means to an end. The real deliverable was a working system, and the code was the best available way to produce that system. Pride in the craft and the outcome pointed at the same target for a long time, so nobody had to choose between them. AI broke that link. Once a working system could exist without hand-written code underneath it, the pride had somewhere to move. It shifted up a level to the architecture, the judgment behind what got built, and the skill in directing agents to write the code. The identity didn’t disappear. It just relocated to a layer AI hasn’t fully reached yet. It remains to be seen how developers will react when AI can cover the entire process, perhaps writing machine code directly, and enabling non-coders can produce the exact same output as the engineers. Some say we’re getting close to that reality right now.
Why Writers Have Less Room to Move
For now, though, writers don’t seem to have an equivalent layer to retreat to, and the reason is structural. Developers hide code behind a working system that the user never sees. That’s by design. Two completely different codebases can produce an identical experience. The code, no matter how it was written, sits quietly behind a layer of insulation.
But prose has no such layer. A reader doesn’t experience some abstracted effect that the sentences produced somewhere upstream. A reader experiences the sentences themselves directly as a new world gets created in their minds as their eyes scan the text. Change the words and you’ve changed the actual thing being read and the world that’s being created. The sentence is often the product in a way code usually isn’t. So there’s no equivalent shift available for most writers. Will that change as readers grow used to AI-generated text? And what happens when AI agents can craft long works directly in a specific writer’s voice without any human or machine detection?
Markets and social pressure reinforce these views for now. Software users and companies primarily care whether the system works, how much it costs, and what value it produces. But many readers of prose still treat the human relationship with an author and the sense of a particular mind behind the words as part of what they are buying. Countless readers return to text over and over again simply to experience the pleasure of how specific passages are crafted. Authenticity is not only a timeless cultural preference here. It’s part of the product itself for a large share of the writing market.
Copyright and the Writer’s Dilemma
There’s another structural difference that writers face and developers largely don’t. That’s copyright. For a writer, publishing text that contains significant AI-generated material creates a genuine legal and commercial question. Under current United States copyright law, purely AI-generated expressions aren’t protected simply because a human prompted the system. Although a larger work can still receive protection when a human author contributes sufficient expressive elements, this line will surely be tested in courts at some point as the things blur. For now, humans at publishing institutions are making those judgments through various editorial policies.
Regardless, this distinction is still uncomfortable for many people. A writer who generates a chapter and publishes it essentially unchanged may have little or no copyright claim to the AI-generated expression itself. But a writer who uses AI as a starting point and then substantially rewrites the material may have a stronger claim to the human-authored portions. The machine can make the work easier to produce while making the boundary around authorship harder to define. This is one reason the reaction to AI-assisted writing may not rest entirely on questions of linguistic purity. There’s a real intellectual property question here.
But developers face copyright and licensing questions as well, although they often differ from the problem writers face. The code engineers ship usually lives inside a broader intellectual property framework involving employers, contracts, proprietary software, or Open Source licenses. A developer may need to worry about whether AI-generated code resembles existing copyrighted code or incorporates material subject to a particular license. But the question of whether the developer personally authored the expressive work is usually less immediate. For writers, though, the words themselves are the product, so the copyright question is personal and potentially significant.
Patents and the Developer’s Emerging Concern
Writers aren’t the only ones with legal exposure, though. AI may complicate the situation for developers too. Developers who work on genuinely novel inventions have another issue to consider. And that’s patents. AI-generated code doesn’t automatically create a patent problem, though. The question isn’t simply who typed the code. Patent law is concerned with the invention and with who actually conceived it. The United States Patent and Trademark Office’s current guidance says the same inventorship standard applies whether or not AI was used. AI can assist a human inventor, but only natural persons can be named as inventors.
That creates an interesting problem. Suppose developers know what they want to build and use AI to implement a technical solution they had already conceived. That’s one thing. But then suppose developers give the AI a problem and the AI comes back with the novel mechanism that actually makes the invention work. They may have directed the system, but direction alone doesn’t necessarily establish inventorship. The important question is whether they made the required contribution to the claimed invention.
An AI-heavy development process could eventually create a strange reversal. Developers may end up with more efficient code and a better product but less certainty about whether their contribution was sufficient to establish inventorship of the underlying technology. Here’s where AI could actually earn its characterization as true artificial intelligence.
There’s another issue too. Developers working on potentially patentable inventions need to be careful about what they put into external AI systems. The problem is broader than trade secret law. Developers can have contractual or employment confidentiality obligations even when the information does not qualify as a trade secret. Patent law also depends heavily on novelty and timing, and public disclosure can lead to consequences that vary by jurisdiction.
The safest approach isn’t just to ask whether the AI wrote the code. It’s to keep track of what the human actually conceived, what the AI contributed, and where the confidential invention details were sent. This can get complicated jet fast as AI becomes pervasive and handles more and more complex computer science tasks.
So, although not exactly the same, patents can be a useful counterweight to the copyright comparison. Developers may not have the same immediate authorship problem as writers have, but they aren’t completely outside the intellectual property problem either. The legal question has simply moved to a different layer.
Institutional Rules Differ Too
Institutional rules and agreements reinforce the disparity between writers and developers as well. Publishing contracts, academic policies, and editorial standards still treat AI contributions as something that must be disclosed or even banned outright. But software employment contracts and Open Source development practices treat AI assistance as ordinary tooling with far fewer formal restrictions.
There’s yet another wrinkle in the rules game. International regulations. The European Union is beginning to treat transparency around AI-generated content as a regulatory issue. The EU AI Act’s transparency obligations under Article 50 began applying on August 2, 2026. Among other things, the rules require certain AI-generated or manipulated text published for the purpose of informing the public about matters of public interest to be identified as artificially generated or altered. There are exceptions, though, including situations involving human review or editorial control. So this is not a blanket requirement that every article or book touched by AI carry a label.
That’s interesting within the context of the difference between writers and developers. A person reading an article may have an interest in knowing whether the words were generated by a machine, particularly when the article is intended to inform the public. A person using a piece of software, however, generally has no comparable expectation that they should be told whether an AI agent wrote some or all of the underlying code. The EU rules could therefore suggest a broader distinction between AI used to build something and AI used to produce the thing that another person consumes directly.
The EU is also putting copyright obligations directly on providers of general-purpose AI models. Those providers must have policies for complying with EU copyright law and must publish a sufficiently detailed summary of the content used to train their models. The relevant obligations for general-purpose AI providers began applying in 2025 with the European Commission asserting enforcement powers over those obligations in August 2026. At present, most major model providers are complying or plan to comply, but what happens if they don’t? xAI, which produces Grok, currently isn’t complying, so the issue may result in fines or court cases. There’s a long history of US-based computer companies paying massive fines to the EU for other regulations that have resulted in disputes in international trade with strong statements of protest coming from the Trump Administration.
Even this issue is still developing. Different countries will continue to approach AI, copyright, patents, and disclosure differently. It’s probably too early to tell whether these regulations will create a permanent distinction between writing prose and writing code, or whether that line will blur as AI becomes a normal part of both professions.
What the Split Inside Software May Suggest
Although software has generally embraced AI, not every developer makes the shift easily. The ones who built their identity on demonstrating individual skill, the tightest solution, or the best line of code still feel a loss that looks somewhat like what writers feel. For them the code was never just a means to an end. It was closer to the point itself.
Both fields also worry about the next generation. In software the fear is that junior developers will never build the necessary skills to understand, debug, or design complex systems. In writing the fear is the loss of voice, critical judgment, research skills, and the long apprenticeship of craft. Watching some developers relocate their pride with ease while others struggle to let go of authorship suggests the split may run through personal temperament more than through the profession itself. Writers may be looking at a preview of their own future in that split with some finding a new place to put their pride and others not finding one at all.
Maybe there’s another difference that will become more important over time. Software has always been layered. A developer can move from writing machine instructions to designing systems, then to architecture and product decisions, and eventually to deciding what problems are worth solving in the first place. Writing has layers too, but the final expression remains exposed text. An author can move toward research, structure, editing, or directing AI, but eventually the reader still encounters the words. If those words can be produced almost entirely by a machine, the question of what exactly the writer contributes becomes harder to quantify.
And that may be where the real long-term divide appears. The question may not ultimately be whether AI is allowed in either profession. It may be whether each profession can establish a new definition of meaningful human contribution and quality of work.
There’s no obvious answer yet. Things will remain messy for a while. The technology is moving too quickly and the law is now moving along with it. The European rules are only beginning to take effect, the copyright questions are still being worked out, and patent authorities will have to apply old concepts such as inventorship to a technology that didn’t exist when those concepts were created. It may be that the differences between writers and developers become smaller over time. Or the legal and cultural systems may end up reinforcing the differences.
For now these are just some questions worth watching. Maybe the honest answer to the original question about the double standard is that there really isn’t one. Or maybe it’s just not a clear enough distinction and over time the external reaction to both fields will simply diminish. Code was mostly judged by outsiders on results, while prose was generally judged on the process and on the sense of a specific person laboring over every single word. AI didn’t create that asymmetry. It just made it impossible to ignore. Who knows how this will turn out.
