As of writing this, in October 2026, software engineering has undergone a rapid change. The forefront of software engineers are seemingly burning multiple top-tier AI subscriptions every week, while a lot of devs really aren’t using all of this much yet.

A lot of that seems te be due to the tooling and methodology around agentic tools. As you adopt AI tooling more, it will show pain points. These 10 factors are a start to avoiding the most common ones.

1. Visual Tool, Multiple Threads

Claude Code in the command line was nice in December 2025, when we were doing a single conversation at a time, maybe two if you were feeling fancy, and dragging screenshots to your agents was ‘advanced’. Today TUIs don’t cut it. Use a harness suitable for many parallel threads, like Codex Desktop, T3 Code, or Claude Desktop.

2. Worktrees by default

All work should happen in a Git worktree or equivalent set-up. In much the same way that developers don’t work on one shared network drive containing all the code, your agents should not do this either. Every conversation should get their own worktree, and it should automatically copy over all relevant config files, set up dependencies, and so on. It should require zero effort or thought to use a dedicated worktree.

3. Connected to your issue tracker

Issues should not be copy-pasted back and forth. Connect your harness to Linear, Jira, or whatever you use to track issues. Use a plugin/connector/MCP, it does not matter. This allows you to pass a ticket number and have the agent fetch all relevant details from the issue, including screenshots, discussions, and links to other relevant issues.

Write access is not strictly necessary, but I would recommend it. If an agent comes up with a good finding, it is incredibly useful to tell it ‘this is out of scope for this ticket, but file a new one’. Automatically updating the status of tickets to in progress at the start of a conversation has been quite useful for me as well.

4. Connected to Version Control

Why would you write a commit message for code you didn’t write? Why would you open a PR for code you didn’t write? Your agent should be filing PRs, not you. You may want to add strict guidelines (a skill perhaps?) on what you want PR descriptions to look like though.

5. CI and Code Review

Your agents should automatically iterate on results of CI pipelines and code review, whether by human or bot. While you may want some human review in this stage, you should not be prompting the agent to ‘look at the comments on the PR and tell me what you propose to do about them’, that bit should go automatically. Filing a PR + following up on anything that happens automatically after filing should always go together.

6. Your tools are your agents tools

Your agent should have access to anything you have access to. Linting, typechecking, running unit tests, integration tests, e2e tests, everything. If you can run it, the agent should be able to run it.

7. Browser

Point 6 really should include the browser, but I’d like to make this a separate point to really drive it home. Your agent should have access to a browser, and should be able to spin up the application to test it in the browser as if they were an end user.

8. Screen Recording

Any PR filed by an agent should contain screen recordings of any user facing change, ideally in before and after videos. Do not become your agents tester. Have it test the code and demonstrate it to you.

9. Skills

You should develop your own skills for anything repetitive or where you notice the agent delivers inadequate work. Think of skills a natural language functions or instructions with a specific trigger condition. The agent can trigger them automatically based on the description of the skill. Skills can also be nested. You are a software engineer, skills are just functions, you’ll figure it out.

10. Retrospective

You should regularly review your agent conversations and fix common problems. This can be in project setup, tooling, or by adding docs or skills to guide agents towards correct behavior.