Hi lovely readers,

If you have spent any time online lately, you have probably seen the endless debates about which programming language you should learn next. Should it be Rust because everyone keeps saying it is the future? Should you stick with C# and .NET? Is JavaScript still worth it, or is it finally time to pick up Python because of all the AI tooling?

These are fair questions, and I love a good language debate as much as the next developer. But after spending the last couple of years watching how AI tools changed the way I actually work day to day, I have come to a slightly different conclusion. The most important language for a developer in the age of AI is not C#, JavaScript, or Rust.

It is English.

You are not writing code anymore, you are describing it

For most of my career, the gap between an idea in my head and working code was filled by me typing that code out, line by line. I knew the syntax, I knew the patterns, and the language I used to get from idea to result was C#.

That gap looks very different now. A large part of my day involves explaining what I want to an AI tool, reviewing what it gives back, and then explaining what was wrong or what I want changed. The bottleneck is no longer "do I know the syntax for this LINQ query." The bottleneck is "can I describe this problem clearly enough that something else can solve it."

That is not a coding skill. That is a communication skill.

If you ask a vague question, you get a vague answer. If you describe the wrong problem, you get a solution to a problem you do not have. The clearer you can express what you actually need, the better the result. And the language most of these tools were trained on, the language most documentation is written, the language most of the prompts and examples online use, is English.

I learned this the hard way in my second language

If you have read some of my other posts, you already know that English is not my first language. I am Dutch, and during university my teachers regularly pointed out how I would lose my train of thought halfway through a sentence. Writing clearly in a second language took me years of effort, which I learned mostly through blogging. That effort turned out to be one of the best investments I ever made, and I did not even realize it at the time.

When you work with AI tools, the quality of your output is tied directly to how clearly you can phrase things. A messy, half-finished thought gives you a messy, half-finished answer. A precise description, with the right context and the right constraints, gives you something you can actually use. The skill of taking a fuzzy idea and turning it into clear sentences is exactly the same skill I had been practicing for years without knowing how useful it would become.

So if English is not your first language either, I want to be honest with you. Yes, this puts a little extra weight on something that is already harder for us. But it is also a skill you can build, the same way you built your ability to read a stack trace or debug a null reference exception. It just takes practice.

Communication was always a huge part

Here is something that I think a lot of us already knew before AI made it impossible to ignore. The hardest parts of software development were rarely the code itself.

The hard parts were understanding what a stakeholder actually wanted instead of what they said they wanted. Writing a pull request description that your reviewer could understand without three follow-up messages. Explaining a technical decision to someone who does not write code. Leaving a comment that your future self would thank you for. Writing documentation that someone could actually follow.

All of that is language. All of that is the ability to take something complicated and make it understandable for another human being. AI did not create this skill, it just turned up the volume on how much it matters. The developers who can clearly explain a problem, give good context, and describe what "done" looks like are the ones getting the most out of these tools right now.

Reading is half of the skill

It is easy to focus only on the part where you describe what you want, but there is another half that matters just as much. You also have to read carefully.

AI tools are confident even when they are wrong. They will happily invent a method that does not exist, suggest a package that was deprecated years ago, or solve your problem in a way that quietly breaks something else. If you cannot read the answer critically and notice when something is off, you are going to have a bad time.

That critical reading is, again, a language skill. It is the ability to follow an explanation, spot the part that does not make sense, and ask a sharp follow-up question. The same way a good code reviewer reads a diff and immediately senses something is wrong, you now need to read generated answers the same way. The better you are at reading, the less likely you are to copy something into production that you did not actually understand.

Programming languages do not stop being important

I want to be clear, because I can already see the comments online. I am not saying you should stop learning programming languages, or that syntax no longer matters, or that you can ship software without understanding what the code does. You absolutely still need to understand your stack. You need to know enough to tell when an answer is nonsense, to debug the thing when it breaks at 4 PM on a Friday, and to make real decisions about architecture and trade-offs.

Programming languages are still the thing the machine runs. But English has quietly become the thing you use to get there. One does not replace the other. They sit next to each other, and right now, a lot of developers are not putting enough effort into the second one.

How to actually get better at it

The good news is that this is a skill you can practice, and you probably already have the perfect tools for it.

Write more. Write blog posts, write detailed pull request descriptions, write proper commit messages, write documentation for the thing you just built. Every time you force yourself to explain something clearly in writing, you are training the exact muscle that makes you better at working with AI.

Pay attention to your prompts. When you get a bad answer, do not just try again with the same vague request. Ask yourself what context was missing, what you assumed the tool already knew, and how you could have phrased it more precisely.

And if English is not your first language, do not let that stop you. Read in English, write in English, and let yourself be a little uncomfortable while you improve. I promise it gets easier, and it pays off in more ways than you expect.

That's a wrap!

Thanks for reading! If you have thoughts, disagree with me, or want to share your own experience, feel free to leave a comment or reach out on my socials. I am always happy to talk about this stuff.

You open a document, download it, make a quick edit, and upload it back. A few hours later, someone else edits a different copy. Now there are multiple versions, conflicting changes, and no clear source of truth.

This download edit, and reupload cycle feels normal, but it quietly breaks document processes in modern applications. For developers building React apps, the real issue isn’t how users behave. It’s that editing still happens outside the application.

The solution is Syncfusion^® React DOCX editor that keeps editing entirely inside the application, no downloads, no stray copies, no round-trip HTML conversions that break Word formatting.

In this post, you’ll learn:

• Challenges with file-based document processes (download, edit, and reupload)
• How in-browser DOCX editing works
• Key features of a React DOCX editor
• Integration basics and real-world use cases

Why file-based DOCX processes break modern apps

At first glance, file-based processes seem simple: download, edit, and upload. In practice, they introduce friction at every step.

• Version confusion
  Every download creates a new copy. Teams quickly lose track of which version is current.
• Security risks
  Files move to personal devices, emails, or external drives. Once they leave your app, control is gone.
• Formatting issues
  When documents are edited across different tools, layouts break, especially with complex tables or page structures.
• Operational overhead
  Comparing versions, merging edits, and fixing formatting takes time that should never be spent.
• Poor user experience
  Switching between tools interrupts processes and slows down simple changes.

These issues aren’t edge cases; they’re structural problems caused by file-based editing.

How in-browser DOCX editing works

The core limitation of most browser-based editors is how they handle DOCX files.

The problem with HTML-based editing

Many editors convert DOCX files to HTML, allow editing, and then rebuild the DOCX file on export.

That conversion step introduces:

• Layout inconsistencies
• Broken tables
• Lost formatting
• Pagination issues

Native DOCX editing approach

In contrast, native in-browser DOCX editing works directly with the document model.

• No format conversion: Edits apply directly to the DOCX structure.
• Page-level accuracy: Margins, headers, and pagination remain consistent.
• Reliable output: What you see during editing matches the exported file.
• Efficient handling: Large documents stay responsive with virtualization.

This architectural difference is what determines whether an editor preserves fidelity or breaks it.

Tips: Keep documents in SFDT during the drafting phase to speed up and improve efficiency. Export to DOCX at milestones: final approval, regulatory submission, or external distribution. This approach preserves fidelity at every stage without unnecessary format conversions during the active editing cycle.

Essential features for a production-ready React DOCX Editor

A usable editor isn’t just about typing text. Production applications require a combination of editing, collaboration, and control.

Collaboration

• Track changes for reviewing edits
• Inline comments and threaded discussions
• Real-time co-editing with a shared document state

Security and control

• Role-based access (view, edit, approve)
• Protected regions for sensitive sections
• Audit logs for compliance and traceability

Document management

• Autosave to prevent data loss
• Version history for rollback
• Approval processes for structured reviews

Export and integration

• Accurate DOCX export
• PDF generation for sharing or archiving
• API and webhook support for backend integration

These capabilities turn document editing into a controlled, scalable process inside your app.

Syncfusion React DOCX Editor with native in-browser editing

Our React DOCX editor is a production-ready document editing tool that directly edits documents in the UI, rather than relying on file handling.

With a native DOCX editor integrated into the app:

• Documents stay centralized
• Edits happen instantly
• Formatting remains consistent
• Users don’t leave the application

This approach replaces fragmented processes with a single, controlled editing experience.

It provides additional capabilities like:

• Native DOCX rendering: Applies Word rules directly (styles, tables, pagination) for accurate WYSIWYG output
• Framework support: Ready-to-use npm components for React, Angular, Vue, and JavaScript
• Flexible deployment: Supports cloud, on-premises, and hybrid setups with self-hosted APIs

Integrating Syncfusion DOCX Editor into a React App

The following walkthrough covers the complete setup, from installing the package to embedding a working editor into your React application.

1. Set up your React project

Use create React App or Vite to initialize your project:

npx create-react-app syncfusion-doc-editor
cd syncfusion-doc-editor

2. Install Syncfusion Document Editor

npm install @syncfusion/ej2-react-documenteditor

3. Import required Styles

Add the following to your index.css to ensure proper styling:

@import '../node_modules/@syncfusion/ej2-base/styles/material.css';
@import '../node_modules/@syncfusion/ej2-buttons/styles/material.css';
@import '../node_modules/@syncfusion/ej2-inputs/styles/material.css';
@import '../node_modules/@syncfusion/ej2-popups/styles/material.css';
@import '../node_modules/@syncfusion/ej2-lists/styles/material.css';
@import '../node_modules/@syncfusion/ej2-navigations/styles/material.css';
@import '../node_modules/@syncfusion/ej2-splitbuttons/styles/material.css';
@import '../node_modules/@syncfusion/ej2-dropdowns/styles/material.css';
@import "../node_modules/@syncfusion/ej2-documenteditor/styles/material.css";

4. Embedding the DOCX Editor component

Create a new file named DocumentEditor.js inside the src folder and add the following code:

import * as React from 'react';
import { DocumentEditorContainerComponent, Toolbar } from '@syncfusion/ej2-react-documenteditor';

DocumentEditorContainerComponent.Inject(Toolbar);

function App() {
    return (
        <DocumentEditorContainerComponent 
            id="container" 
            height={'590px'} 
            serviceUrl="https://document.syncfusion.com/web-services/docx-editor/api/documenteditor/" 
            enableToolbar={true}
        />
    );
}

export default DocumentEditor;

Note: Syncfusion uses SFDT (Syncfusion Document Text) format for efficient document rendering and editing. In the example above, we load a document using SFDT to initialize the editor.

5. Use the component in App.js

Import and use the DocumentEditor component in your App.js file:

import React from 'react';
import DocumentEditor from './DocumentEditor';

function App() {
  return (
    <div className='App'>
      <DocumentEditor />
    </div>
  );
}

export default App;

6. Run your application

Start the application using the start script.

npm start

Curious about implementing a DOCX editor in your React app? Check out the official documentation for a complete step‑by‑step integration guide and get started in minutes.

Real-world use cases

• Legal and contracts: Teams collaborate on contracts with track changes and audit logs, avoiding confusion from email-based revisions.
• Human resources: Templates stay consistent while allowing controlled edits, eliminating formatting issues in offer letters and documents.
• Healthcare and compliance: Sensitive documents remain inside secure systems with full audit trails, supporting regulatory requirements.
• Financial services: Reports stay centralized, with clear version history and controlled approvals.
• Education: Course materials maintain structure while enabling safe customization without repeated rework.

Explore the endless possibilities with Syncfusion’s outstanding React UI components.

Try It Free

Conclusion

Thank you for reading! The download, edit, and reupload cycle introduces hidden costs, version confusion, formatting drift, security gaps, and wasted time.

Moving DOCX editing into the browser addresses the root cause. Documents stay in one place, edits remain consistent, and processes become faster and easier to manage.

For React applications, in-browser DOCX editing isn’t just a convenience; it’s a shift toward more reliable, scalable document experiences.

Syncfusion DOCX Editor delivers this model for for React, Angular, Vue, and JavaScript, with the collaboration tools, compliance features, and integration flexibility that production document processes require. The result is faster editing cycles, fewer support tickets, stronger compliance posture, and document processes your users can actually trust.

Try the React DOCX Editor live demo to see its native editing in action.

Browse the documentation to check API reference, integration guides, and starter samples.

If you’re a Syncfusion user, you can download the setup from the license and downloads page. Otherwise, you can download a free 30-day trial.

You can also contact us through our support forum,  support portal, or feedback portal for queries. We are always happy to assist you!

For about two years, the unit of work with a coding agent was the prompt. You wrote a good one, you gave it enough context, you read what came back, and you wrote the next one. The agent was a tool, and you were holding it the entire time, one turn after another.

That part is ending. Addy Osmani, a director of AI at Google Cloud, has a name for what replaces it, and I have not stopped thinking about it since: loop engineering. You stop being the person who prompts the agent. You design the loop that prompts it for you.

In my phrasing: you stop being the thing that runs, and start designing the thing that runs. The leverage moves up a layer. What I want to do here is take an honest look at the pieces, and at the part nobody automates.

The leverage moved up a layer

The people building these tools have already made the jump. Peter Steinberger has been posting it as a monthly reminder.

Boris Cherny, who heads Claude Code at Anthropic, says the same thing about his own job. He does not prompt Claude anymore. He has loops running that prompt Claude and decide what to do next, scanning the issue tracker, the team chat, and the timeline for what to build. “My job is to write loops.”

A loop is a goal that prompts itself. You set the purpose, and the system keeps iterating until it’s met. In practice it finds the work, hands it out, checks the result, writes down what got finished, and decides the next thing, then it pokes the agent instead of you. You build that small system once and let it run.

Look closer, and a loop is really two loops nested. The inner one does the work against a spec. The outer one decides what the work should be: it watches an issue tracker, an error feed, a changelog, then writes the next spec and hands it down. Most people are still running that outer loop by hand, in their head, and calling it a backlog.

The part that surprised me is that this is barely a tooling problem anymore. A year ago a loop meant a pile of bash you wrote and maintained forever. Now the pieces ship inside the products, and the same shapes show up in Claude Code and in Codex. Osmani puts loop engineering one floor above the harness, the context and tooling you wire around a single agent. I wrote about that harness a couple of weeks ago. The loop is the thing that runs on top of it: it runs on a timer, it spawns helpers, and it feeds itself.

The five pieces, and the one that holds them together

Strip loop engineering down and you get roughly five building blocks, plus one place to remember things. Both Claude Code and Codex have all five now. The names differ here and there; the capability is the same.

1. Automations are the heartbeat. They are what make a loop an actual loop and not one run you did once. A prompt or command on a cadence, a scheduled task, a hook that fires at a point in the agent’s lifecycle, or a job on CI that keeps running after you close the laptop. Discovery and triage run themselves, and the findings that matter come to you.
2. Worktrees keep parallel from turning into chaos. The second you run more than one agent, the files start colliding. Two agents writing the same file is the same headache as two engineers committing to the same lines with nobody talking first. A git worktree is a separate working directory on its own branch, so one agent’s edits cannot touch another’s checkout.
3. Skills are intent, written down. An agent starts every session cold and fills any hole in your intent with a confident guess. A skill is that intent written on the outside: the conventions, the build steps, the “we don’t do it like this because of that one incident,” recorded once where the agent reads it every run. Without skills, the loop re-derives your whole project from zero every cycle.
4. Connectors let the loop touch your real tools. Built on MCP, they let the agent read the issue tracker, query a database, hit a staging API, or drop a message in chat. This is the difference between an agent that says “here is the fix” and a loop that opens the pull request, links the ticket, and pings the channel once CI goes green.
5. Sub-agents keep the maker away from the checker. The model that wrote the code is far too generous grading its own homework. A second agent with different instructions, and sometimes a different model, catches the things the first one talked itself into. Worktrees and a cold-context reviewer are two pieces I have written about before, back when the question was running agents in parallel without them trampling each other.

Then the sixth thing: memory. A markdown file, a Linear board, a state file, anything that lives outside the single conversation and holds what is done and what is next. It sounds too dumb to matter, and it’s the whole game. The model forgets everything between runs, so the memory has to live on disk, not in the context window. The agent forgets. The repo does not.

What makes a loop hold together

A loop running unattended is also a loop making mistakes unattended. The one thing that keeps it honest is verification, and verification needs an oracle, something outside the model that returns a hard yes or no. Passing tests, a clean build, a green pipeline, a real production signal. Without an oracle, the loop compounds confidently wrong work, faster than you can read it.

The cleanest version of this already ships in the tools. Claude Code’s /goal keeps working across turns until a condition you actually wrote holds, something like “every test in auth/ passes and lint is clean,” and after every turn a separate, faster model reads the transcript and decides whether you are there yet. The agent that wrote the code is not the one that grades it. That is the maker-and-checker split applied to the stop condition itself. Codex’s /goal reaches the same finish line a different way: the agent audits its own work against the evidence before it can call the goal done.

What the loop still won’t do for you

The loop changes the shape of the work. It does not take it off your desk. And a few things get sharper as the loop gets better, not softer.

Verification is still on you. The split reviewer is what makes “it’s done” mean something, but “done” is a claim, not a proof. Your job is still to ship code you confirmed works, which is harder to remember when the diff arrived while you were at lunch.

The bill comes in two currencies. Tokens and attention. A single unattended run can burn through millions of tokens, and that is only worth it when the tokens buy something worth more than they cost. The quieter trap is the second currency: memory is what lets a loop compound over time, and slop compounds right alongside it. A loop pointed at a vague goal does not get tired and stop. It gets faster.

Your understanding rots if you let it. The faster the loop ships code you did not write, the wider the gap between what exists in the repo and what you actually understand. A smooth loop grows that gap faster, not slower, unless you read what it made. The comfortable posture, where you stop having an opinion and take whatever the loop gives back, is the risky one. Two engineers can build the exact same loop and get opposite results, one moving faster on work they understand deeply, the other avoiding the work entirely. The loop cannot tell which one you are.

When the loop reaches production

Most of this thinking grew up around application code, where a bad run costs you a revert. When the loop reaches into infrastructure, the blast radius is a production outage rather than a revert, and the verification bar has to rise to meet it. The upside is that infrastructure hands the loop a better oracle than application code does. A plan diff is deterministic and machine-readable, a policy check returns a hard verdict, and drift and cost are numbers you can put a threshold on. A reviewer, whether human or agent, can read the change cold, with no memory of the prompt that produced it. That cold-context check is exactly what an unattended loop needs, and it’s the reason an infrastructure loop can be built to hold together while you sleep. Pulumi Neo reasons over the state graph directly, so the checker grounds every claim in what the change actually does, not in what the writer says it does.

Where to start

Pick the loop you can actually trust first. In order:

1. Start where “done” is unambiguous. CI triage, dependency bumps, a flaky-test hunt, a failing job you keep re-running by hand. Loops need an oracle, so begin where the oracle already exists.
2. Write the memory file before the loop. One markdown file, or a board. What is done, what is next, what was tried and failed. This is the spine, and everything else hangs off it.
3. Split the checker from the maker. Use /goal with a verifiable condition, or a second agent with its own instructions. Never let the agent that did the work be the one that decides the work is finished.
4. Cap it, then read everything. A max-iteration count, a token budget, a teardown step. Run it once, end to end, then read every line it shipped. The first run is the measurement, not the payoff.

Then look at what you built. You designed it once, and it ran without you steering each step. That is the real shift. But the leverage only holds if you wire the loop like an engineer, not like someone looking for permission to stop thinking. Read what it ships. Keep an opinion. Judgment is the one part that does not move up a layer.

The loop will do the typing. The thinking is the work.