A teammate that writes code for the whole company
A coding agent is software that takes a request in plain words, changes the code to meet it, runs the project’s checks and hands back the change for a person to approve. It works in the same places your team already does, the repository, the issue tracker and the team chat, and it keeps going until the change is ready to review or it needs an answer.
The first wave of coding tools helped one developer type faster. The shift now is that the agent works for everyone who needs something changed. A growth lead asks for a new landing page. A product manager asks why a signup step loses people. An operations lead asks for a report the finance team needs every Monday. Each request reaches the same agent, and each comes back the same way, as a reviewed change rather than a promise.
That is what makes it a company tool and not only a developer tool. The person who knows what is wanted can ask for it directly, and the engineer who owns the code stays the one who says yes.
Who asks it for what
The easiest way to see how a coding agent fits an enterprise is to follow the people who talk to it in a normal week.
| Who asks | A typical request | What comes back |
|---|---|---|
| Developer | “The export job times out on large accounts. Find why and fix it.” | A change with the cause explained, a test that reproduces the timeout, and the fix |
| Head of engineering | “Upgrade the payments library across our services and tell me what breaks.” | One pull request per service, the failures it found and fixed, and the ones that need a decision |
| COO | “Add a weekly report of refunds by region to the admin dashboard.” | A new page in the internal tool, with a preview link to check the numbers against finance |
| Growth lead | “Build a landing page for the spring campaign from this design.” | The page in the marketing site, matched to the design, with a preview to click through on a phone |
| Product manager | “Users drop off at step three of onboarding. Find out what is happening.” | A short report from the logs and analytics, then a proposed fix as a separate change |
| Marketer | “Change the pricing page copy and add the new plan to the comparison table.” | The copy change, a screenshot of the new table, and a note on any page that links to the old plan |
Two things stay the same across every row. The person asking does not need to know where the code lives. And nothing they asked for goes live until someone who owns that code has read it and approved it.
One request, start to finish
Here is how a single request travels, using the growth lead’s landing page.
- The request arrives. The growth lead writes in the team’s Slack channel, with a link to the design file. The agent replies within a minute that it is on it, so nobody wonders whether it was seen.
- It becomes a ticket. The agent files the work in the issue tracker, with the design link and what done looks like, so the request has an owner and a history.
- It reads the project. It finds how the marketing site builds its pages, which components it already has and how other campaign pages were done.
- It builds on a branch. It writes the page on its own branch, away from the live site, reusing the site’s components rather than inventing new ones.
- It checks its own work. It runs the site’s tests and build, opens the page in a browser at desktop and phone widths, and compares it with the design.
- It opens a pull request. The change goes up for review with screenshots, a preview link and a short note on what it could not confirm.
- People review it. The growth lead clicks through the preview and asks for a different headline in the same thread. The agent makes the change and posts a new preview. An engineer reads the code and approves.
- It ships. A person merges the change, and the page goes live through the normal release.
You asked
Can you build the spring campaign landing page from this design?
The hero, the three plan cards and the signup form.
The agent replied
The page is up for review with a preview link and screenshots at
desktop and phone width. It reuses the site's plan cards and form.
The design shows a video in the hero that is not in the file, so I
used the still image for now. Tell me where the video lives and I
will add it.How it differs from other coding tools
Coding help has come in waves. Each one moved a little more of the task from the person to the software, and the latest one opened it to people who do not write code at all.
| Autocomplete | Chat assistant | Coding agent in the editor | Cloud coding agent | |
|---|---|---|---|---|
| Tools you may know | GitHub Copilot completions, Tabnine | ChatGPT, Claude | Cursor, Claude Code | Devin, Factory, OpenAI Codex |
| Who uses it | A developer | Anyone, with a developer to paste the code | A developer at their desk | Anyone on the team, through chat or a ticket |
| What you give it | The line you are typing | A question about code | A task in the code open in front of you | A task in plain words, from anywhere |
| What it gives back | The next few words of code | An answer or a snippet | Edits in your editor | A tested pull request with a preview |
| Who runs the checks | You | You | The agent, on your machine | The agent, in its own sandbox |
| Where it works | Your editor | A chat window | Your laptop | Its own cloud machine, with your tools connected |
None of these replace the person who understands the product. They change where that person spends their time. With a cloud coding agent, more of it goes to deciding what to build and reviewing what came back.
The connections it works through
A coding agent is useful in proportion to what it can reach. In an enterprise that means a short list of systems, each with a clear job.
| Connection | Example tools | What the agent does with it |
|---|---|---|
| Code hosting | GitHub, GitLab, Bitbucket | Reads the code, works on branches, opens pull requests and answers review comments |
| Issue tracker | Linear, Jira | Picks up assigned tickets, files new ones for requests from chat, and links each change to its ticket |
| Team chat | Slack, Microsoft Teams | Takes requests where people already ask, says it is on it and posts the result in the same thread |
| Continuous integration | GitHub Actions, CircleCI | Runs the checks on every change and fixes what fails before a person looks |
| Preview hosting | Vercel, Netlify | Gives every change a link a non-engineer can click through before approving |
| Error and log monitoring | Sentry, Datadog | Reads the error behind a bug report, reproduces it and fixes the cause rather than the symptom |
| Design files | Figma | Reads the frame a change should match and checks the result against it |
| Product analytics | PostHog, Amplitude | Answers questions about how a feature is used before anyone proposes changing it |
| Documentation | Notion, Confluence | Reads the decisions and conventions a change has to respect |
How to put the connections to work
Start with code hosting, the issue tracker and team chat. Those three let people ask, let the work be tracked and let changes be reviewed. Add continuous integration and preview hosting next, because they are what let someone other than an engineer judge a change. Monitoring, design files and analytics come after, and each one makes the agent’s work closer to what the person meant.
Keep every connection as narrow as the job allows. The agent needs to read logs, not change the production database. It needs to open pull requests, not merge them. It needs a test payment account, not the real one.
Where enterprise coding agents are heading
The products built for large companies show where this is going. Two of the best known are Devin from Cognition and Factory, and they converge on the same set of features.
- Work arrives from where the team already is. Both take tasks from Slack, Microsoft Teams, Linear or Jira and return pull requests to GitHub or GitLab. A ticket in, a reviewed change out, is the shape enterprises are buying.
- Each task runs in its own sandbox. Devin runs every session in a virtual machine Cognition hosts, with its own browser and terminal. Factory runs shell commands locally and offers managed cloud machines and an operating-system sandbox. Either way, the agent never works on the live system.
- Autonomy is a setting, not a leap of faith. Factory sets autonomy levels from off to high, with a blocklist of destructive commands no level can run. Approvals become something an admin configures once, not something each user remembers.
- Specialist agents take on whole stages. Factory ships agents for code review, security review, QA and incident response, and Devin offers automated pull request review and scheduled automations. The coding agent becomes several agents, each owning one step of the release.
- Long tasks are planned, then split. Factory’s Missions plan a feature in milestones and hand them to coordinated workers. This is how a migration across many services gets done without one person driving every step.
- Enterprise controls are standard. Single sign-on, audit logs, admin controls and certifications like SOC 2 are table stakes. Devin offers deployment inside a customer’s own cloud network on its enterprise plan, and Factory can run fully air-gapped with EU data residency.
- The model is a choice. Factory routes each task across models from several providers and lets customers bring their own keys. Buyers increasingly expect not to be locked into one model maker.
For a buyer, the lesson is that the agent itself is only part of the product. What makes it safe for a large company is the sandbox it works in, the approvals an admin can set, the record it keeps and the place it runs.
What it needs from you
A coding agent is only as good as the setup around it. Four things make the difference.
A clear request
The agent works from what you write. “Make checkout better” gives it nothing to finish. “Customers in Canada see the US shipping rate, and they should see the Canadian one” gives it a goal and a way to test it. Write the request the way you would brief a contractor you have never met, with a link to the design, the ticket or the error where there is one.
Access to the project and nothing more
The agent needs to read and change the code, and run it somewhere safe. It does not need the keys to your payment account, your customer database or production. Give it a sandbox, test accounts and read-only access to logs, and keep everything else out of reach.
Automatic checks
Tests are how the agent knows it is done. A project with good tests lets the agent catch its own mistakes before anyone sees them. A project with no tests leaves the agent guessing, and leaves your reviewers to find the problems later. Many teams find the agent’s first useful job is writing the tests a project never had.
A person who reviews
Someone has to read the change before it goes live. That is human-in-the-loop review in its simplest form. For a change to code, that person is the engineer who owns it. For a change a non-engineer asked for, the person who asked checks the preview, and the engineer checks the code. Both sign off before it ships.
Where coding agents go wrong
Coding agents are useful and fallible. Knowing the usual failures makes them easier to manage.
- They solve the wrong problem. A vague request leads to a confident change that fixes something nobody asked about.
- They pass the tests and miss the point. If the tests do not cover the real problem, the agent can make them pass without fixing anything a customer would notice.
- They change too much. Asked to fix one button, an agent may tidy up a dozen files nearby. Each extra change is one more thing to review.
- They make things up. An agent may use a setting or a library function that does not exist in your project. Good checks catch this. A weak review does not.
- They reach too far. Given wide access, an agent can change things outside its task, like a settings file or the list of software the project depends on.
Each of these has the same fix. Narrow the request, keep the access small, write tests that describe what a customer sees and read the change before it ships.
Where to start
Pick one team and one kind of request that piles up. In many companies it is the marketing site, where small copy and page changes wait weeks for an engineer, or the internal tools, where operations has a list of reports nobody has time to build. Connect the agent to that one repository, the issue tracker and the team’s chat channel, and let the people who usually wait ask it directly.
Watch three things for a month. Did requests come back as changes people could review? Did reviewers approve them with light edits, or rewrite them? Did the people asking get what they meant without an engineer translating? If the answers are good, add the next repository and the next team.
A coding agent does not remove the need for judgment. Someone still decides what to build, checks that the change is right and owns what happens when it goes live. The agent takes the typing, the searching and the trial and error, for everyone in the company who needs something changed. That is what any agent is for. It carries a task to the point where a person can say yes or no, and it waits for that answer.
