AI Took the Fun Part of Coding. Humans Still Have to Set Up the Environment.

Every software engineer knows the joke.

The hardest part of building software is often not building the software.

It is getting the environment to work.

You sit down excited to implement something. Then reality shows up. The Node version is wrong. The Python virtual environment is broken. Docker is using the wrong architecture. The .env file is missing. The database seed script is outdated. The local service depends on another service that nobody mentioned. The README says one thing, Slack says another, and CI is failing for reasons that appear to be spiritual.

Then, eventually, after enough trial and error, the environment works.

And suddenly engineering becomes fun again.

You can write code. Run tests. Refactor. Build features. Try ideas. See progress.

For a long time, this was one of the basic emotional truths of software engineering: the fun part starts only after the tedious environment work is done.

Now AI coding agents are here.

They can write code. They can edit files. They can inspect repositories. They can run commands. They can generate tests. They can refactor modules. They can explain unfamiliar code. They can open pull requests.

At first glance, it feels like they should finally eliminate the boring parts of engineering. But the funny thing is this: the agent gets to do the fun part. The human still has to set up the environment.

Only now, the environment is not just a local dev setup. It is permissions, tool interfaces, sandboxes, repo instructions, guardrails, secrets boundaries, CI gates, evaluation criteria, approval flows, observability, and rollback paths.

In other words, the tedious work did not disappear. It became harness engineering.

The old environment setup problem

Before AI agents, an engineering environment had a familiar shape. A human developer needed to know how to install dependencies, run the app locally, configure secrets, seed test data, run unit tests, run integration tests, deploy safely, debug common failures, and follow the team's code structure.

This work was rarely glamorous, but it was extremely important. A good environment made engineers faster. A bad environment made every small change feel expensive.

That is why strong engineering teams invested in setup scripts, Docker images, internal CLIs, CI pipelines, onboarding docs, deployment templates, test frameworks, and paved roads.

The goal was always simple: make the right thing easy, and make the dangerous thing hard.

That was true when the worker was human. It is even more true when the worker is an agent.

The new environment is built for agents

When an AI coding agent works inside a repository, it also needs an environment. But the shape of that environment is different.

A human engineer can rely on memory, judgment, social context, and common sense. A human can ask a teammate, notice when something feels risky, or decide not to run a suspicious command. An agent needs more explicit boundaries.

It needs to know which files are safe to edit, which commands are allowed, which commands require approval, which tests prove the change worked, which documentation it should read first, which secrets it should never touch, which external systems it can call, which tools are available, what done means, what dangerous means, and when it should stop and ask a human.

This is not just prompting. This is engineering.

That is the new environment setup. Not just: can the app run? But: can an agent safely work here?

The agent gets the fun part

There is something absurd about this.

For years, engineers imagined that AI would remove the tedious parts of software development. Then AI arrived and started doing the most visibly fun part: writing code.

The agent gets to implement the feature. The human gets to configure the permissions.

The agent gets to refactor the module. The human gets to define which tests actually matter.

The agent gets to generate the pull request. The human gets to create the CI gate that decides whether the pull request is safe.

The agent gets to explore the codebase. The human gets to write the repo instructions so the agent does not wander into the wrong part of the system.

The agent gets to move fast. The human gets to make sure it does not move fast in the direction of production secrets.

So maybe the future of engineering is not simply that AI will write the code. Maybe the more accurate version is that humans will build the environment where AI can safely write code.

That sentence is less glamorous. But it may be more true.

The boring work became more important

The tedious setup work used to be annoying because it blocked human productivity. Now it blocks both human and agent productivity.

If your repository has unclear setup instructions, weak tests, fragile CI, undocumented conventions, and messy secrets management, an AI agent will not magically turn that into a high-trust engineering system. It may make the mess worse, faster.

A coding agent in a poorly prepared repository is like a junior engineer with root access, no onboarding, and unlimited confidence.

The better the harness, the more autonomy you can give the agent. The worse the harness, the more babysitting you need.

That means the value is shifting. In the old world, great engineers were valuable because they could navigate messy environments and still ship. In the agentic world, great engineers will also be valuable because they can turn messy environments into structured, safe, agent-ready systems.

That includes writing clear repository instructions, exposing safe tools, limiting dangerous actions, defining meaningful test gates, creating repeatable workflows, designing approval boundaries, adding observability, protecting secrets, packaging context in a controlled way, and making the system understandable to both humans and agents.

This is not busywork. This is leverage.

Prompting is not enough

A lot of early AI development advice focused on prompting. Better prompts. Better examples. Better context. Better system instructions.

That matters. But prompting is only one layer.

A great prompt cannot compensate for a repository with no reliable tests. A great prompt cannot protect secrets if the tool permissions are too broad. A great prompt cannot make a deployment safe if there is no approval workflow. A great prompt cannot create observability after the agent has already made a confusing set of changes. A great prompt cannot define what correctness means for your business domain.

Prompting tells the agent what you want. Harness engineering defines what the agent can access, what it can change, what it must verify, what it must not do, when it needs approval, how humans inspect what happened, and how the system recovers when something goes wrong.

That is a different level of problem. It is less like writing a clever instruction. It is more like designing a safe operating environment.

Agent-ready will become an engineering quality

Today, we describe codebases as maintainable, testable, observable, secure, modular, or well-documented. Soon, we may also describe them as agent-ready.

An agent-ready codebase has qualities like clear setup instructions, predictable build commands, reliable test coverage, documented architecture, scoped modules, safe local development defaults, strong CI validation, clean secrets handling, clear ownership boundaries, machine-readable conventions, permission-aware tooling, and useful examples of common changes.

The interesting part is that these qualities do not only help agents. They help humans too.

This may be one of the most useful side effects of AI coding tools: they expose the mess that humans have been tolerating.

If your repository is confusing for an agent, it is probably confusing for a new engineer. If your test process is unclear for an agent, it is probably unclear for your team. If your deployment process is too dangerous for an agent, it may already be too dangerous for humans. If your documentation is not good enough for an agent to follow, it may not be good enough for onboarding either.

AI does not just automate engineering work. It reveals the hidden cost of bad engineering environments.

The new platform engineering

This is why platform engineering may become more important, not less.

A good internal developer platform used to help humans ship software faster. A good agent-ready platform will help both humans and agents ship software safely.

That platform may need to provide standard repo instructions for agents, approved tool integrations, permission templates, sandboxed execution environments, secure access to internal documentation, CI/CD gates designed for agent-created changes, audit logs of agent actions, cost controls for model and tool usage, policy checks before deployment, and evaluation suites for common engineering tasks.

This is not just an AI tooling problem. It is a platform problem.

The companies that benefit most from AI coding agents may not be the companies that simply buy the best model. They may be the companies that build the best operating environment around the model.

The real product opportunity

This creates an interesting product opportunity. If humans are still responsible for the tedious part, then there is value in making that tedious part easier.

The product does not need to be a better coding agent. There are already many people building that. The more interesting wedge may be: make the human's boring setup work easier.

Imagine a tool that scans a repository and answers: is this codebase ready for AI agents?

It could check whether the repo has agent instructions, whether setup commands are documented, whether build and test commands are reliable, whether dangerous commands are protected, whether secrets are isolated, whether tool permissions are too broad, whether CI checks are strong enough, whether ownership boundaries are clear, whether examples exist for common tasks, whether there are evals for agent-generated changes, whether approval flows are defined for risky operations, and whether agent actions are observable.

The output could be an Agent Readiness Report.

Not just another code quality report. A report focused on whether an AI coding agent can safely and effectively work inside the repository.

This could start as something simple: a CLI, a GitHub Action, a generated AGENTS.md, a Claude Code, Codex, or Cursor readiness checklist, a permission audit, a CI/test gap report, or a harness improvement plan.

Over time, it could become more powerful: repo readiness scoring, permission templates, sandbox policies, MCP/tool interface validation, CI recommendations, agent action logging, team dashboards, compliance reports, and enterprise governance workflows.

The product would not sell magic. It would sell something more practical: less human pain in preparing the environment where AI can actually be useful.

That feels like a real problem. Because the more companies adopt coding agents, the more they will discover that agent productivity depends on harness quality.

The real irony

The first wave of AI coding made people ask whether AI will replace software engineers.

But maybe a better question is: who will build the environment where AI can safely do engineering work?

Because that environment will not build itself.

Someone still has to define the permissions. Someone still has to design the tools. Someone still has to write the tests. Someone still has to create the guardrails. Someone still has to protect the secrets. Someone still has to decide what done means. Someone still has to clean up the messy repository so the agent can work productively.

That someone is still an engineer. The work is just moving up a level.

Conclusion

AI agents are changing software development, but they are not eliminating the boring parts. They are changing where the boring parts live.

Before, environment setup meant getting a human developer ready to code. Now, harness engineering means getting an AI agent ready to code safely.

The agent may get to write the feature. But humans still have to prepare the workspace, define the boundaries, build the validation system, and make sure the whole thing does not go off the rails.

So yes, AI may take over more of the coding. But for now, the funniest truth is this: the agent gets the fun part. The human still has to set up the environment.

And maybe that is where the next wave of engineering value will be created. Not in asking whether agents can code, but in building the harness that makes their coding trustworthy.

Agent readiness scanner

I am exploring the idea of an Agent Readiness Scanner: a lightweight tool that reviews a repository and reports how ready it is for AI coding agents across setup, permissions, test gates, secrets hygiene, documentation, and guardrails.

If your team is adopting Claude Code, Codex, Cursor, or internal coding agents and discovering that the hard part is not the model but the environment around it, I would love to compare notes. You can also read QRUV's broader AI Production Readiness checklist, review related services, or contact QRUV directly.