My bias up front: I really like using agents. A big part of my day is interacting with them, mostly Codex, Claude, OpenCode, or Cursor, and I feel lucky to be working in this period. There is something a little surreal about describing what you want to a machine and watching it do a real chunk of the work well. But I also try not to fall for every hype cycle, or every “it’s over, AI can do everything” post on X.

The Main Thing That Changed

For me, the big change isn’t that agents started reading files, editing code, and running tests. That was already happening in early 2025 with Cursor and Claude Code. It’s that they got good at the longer work.

Until late 2025, agents were mostly useful for contained problems: small changes, debugging, refactors, tests, explaining a chunk of code. On longer or more complete tasks they would drift, lose context, get stuck, or need constant steering.

Around November and December that shifted. The strongest models of the wave landed close together—Opus 4.5 and GPT-5.1, followed by the GPT-5.x-codex and Opus 4.x lines—and the tools caught up at the same time. Not perfect, but good enough to plausibly:

  1. read a larger part of the codebase,
  2. understand enough project context,
  3. make a bigger change,
  4. run commands,
  5. run tests,
  6. read the errors,
  7. try again,
  8. and then show a diff for a human to review.

It doesn’t mean the output is automatically good, or that the agent understands the product or the history of the codebase the way a person does. But the tool is no longer just helping with typing. It’s participating in more of the work loop.

One funny effect: a strong new model feels magical for a few days or weeks, then we get used to it, treat that level as the default, and immediately push it harder. The magic fades even though the capability is genuinely much higher than before. There are also quality swings. Sometimes a model or tool feels worse for a while and it’s not obvious why—a model change, a harness bug, infrastructure, cost optimizations, or just the task exposing weaknesses. Both are reasons I try not to overreact to one week of hype, or one week of complaints. The baseline keeps moving, and our expectations move with it.

The Tools Are Changing, but the Loop Is Starting to Stick

The product names change fast. Some people use Claude Code, some Codex, some Cursor, some OpenCode. I don’t think the exact tool matters much right now. The best one today might not be next month. But the workflow is starting to look familiar:

  1. Give the agent a clear goal.
  2. Give it enough context.
  3. Let it inspect the project.
  4. Let it make a change.
  5. Let it run tests or tools.
  6. Review what it did.
  7. Keep, adjust, or throw away the result.

That loop feels more durable than any single tool. The clear-goal part still matters a lot. The clearer the goal, the better the result. But the review part matters just as much. Most tools have a built-in review command now, or you can just say “please review this change.” I use that a lot. It is not a replacement for my own review, but it is a useful extra pass.

This is also why I’m less interested in memorizing every new feature name. Skills, subagents, memory, automations, MCP servers, repo instructions: they can be useful, but the point isn’t to collect terminology. Honestly, for most of my day-to-day work now I just talk to the agent. I’m rarely reaching for a special feature.

Skills are a good example. They matter most when:

  • I want the agent to work in an area I’m less familiar with, frontend or design work, for example,
  • it needs to work with something new that’s probably not in its training data,
  • or I have a repeated workflow that’s annoying to prompt every time.

Using a skill doesn’t automatically make the result better. For reviewing a PR, committing, pushing, or opening a PR, I usually don’t feel one is necessary. A simple prompt is enough.

MCPs are similar. Some are genuinely useful. Context7—an MCP that can search and pull the latest library docs into context—has been the most useful for me, mostly because it stops the agent guessing at outdated APIs. But I’m careful with MCPs that wire up a lot of tools or APIs. For important work I’d rather be certain and secure than hand the agent a pile of tools where I don’t fully know what’s happening behind the scenes.

The point is more basic:

Can the agent get the right context, do something useful, get feedback, and leave behind work a human can understand and trust?

If yes, the tool is useful. If not, the feature name doesn’t matter much.

Why Coding Was One of the First Big Use Cases

One useful framing from Andrej Karpathy is this: coding gives AI systems a lot of feedback.

Code can be run. Tests pass or fail. Type checkers and linters complain. Logs and errors give concrete signals. A diff can be reviewed. A UI can be opened in a browser. A script can be run again.

That’s not a small thing, and it’s why coding moved early. From what I can tell, a lot of the recent progress came from making models better at tasks where they can try something, get feedback, and improve. Coding has many ways to verify the work, and that seems to be one reason agents got much better at longer tasks. It is also a place where developers and companies were willing to pay, so it makes sense that a lot of effort went there.

I think this applies outside engineering too. Agents are more useful when the work has:

  • clear inputs,
  • clear constraints,
  • good examples,
  • and some way to check the output.

For marketing that might be source material, brand guidelines, and human review. For design, existing components and product constraints. For product work, customer context and explicit tradeoffs. The less verifiable the task, the more careful we need to be.

One thing worth saying plainly, though: for anything that touches customers, data, security, billing, or a codebase we have to maintain, “the AI made it” is not an explanation. A person still owns the outcome. The agent can do more of the execution, but it doesn’t take responsibility.

What I Think Is Actually Useful

After using these tools a lot, these are the patterns I think are worth keeping.

Context Matters

Agents are very sensitive to context. Obvious, but it’s one of the most practical points. A coding agent works better when the repo has good setup instructions, clear test commands, examples of existing patterns, and conventions that are easy to find. This is whereAGENTS.md, repo instructions, or reusable prompts earn their keep.

But I’m skeptical of huge auto-generated instruction files. If they’re too long, vague, or just repeat the obvious, they become noise. The useful version is boring:

  • here’s how to run the tests,
  • here are the local setup gotchas,
  • here are conventions we care about,
  • here are things that shouldn’t be changed casually,
  • here’s how to verify a change.

That helps agents, but it helps people too.

Agents have also gotten much better at picking up patterns from the existing code. Often “look at the existing code and follow the same patterns” is enough, and not every preference needs to be written down. The balance I’ve landed on is to document the non-obvious things and let the agent infer the obvious ones from the code.

Verification Matters More

If agents make execution faster, verification matters more, not less.

For code, I keep asking:

  • What did you run?
  • What failed before?
  • What passes now?
  • What did you manually inspect?
  • Is this small enough to review?
  • Do I understand the code well enough to own it?

I read the code, run it, and ask the agent to review its own work too, and sometimes a second agent or model reviews the first. Useful, but still not the same as me understanding the result.

For non-code work the same questions apply: what sources were used, what assumptions were made, what needs human review, is it factual, does it match the product? Not the exciting part of AI tooling, but the important one. Faster output only helps if we can still trust it.

Human Judgment Moves Up a Level

The interesting question isn’t “can AI write code?” It can, and pretty often the code is very good. The better question is: what does the human need to be good at now?

My current answer:

  • defining the right problem,
  • giving useful constraints,
  • knowing what good looks like,
  • reviewing tradeoffs,
  • spotting bad assumptions,
  • protecting maintainability,
  • and communicating clearly with other people.

For engineers, this means thinking more from a product angle. If agents take some of the manual coding, then just doing “the coding part” isn’t enough. We need to understand why we’re building something, what it solves, and what tradeoffs we’re making.

I don’t think roles are disappearing, but the boundaries are blending. Engineers can think more about product, PMs and designers can prototype directly, and others can build their own internal tools. Not everyone replacing each other, just the tools expanding what each person can explore.

The typing might get cheaper. The judgment does not.

Maintainability Is Still a Risk, but It Is More Nuanced

The scary failure mode isn’t one bad piece of code. That’s usually catchable. It’s slowly accumulating things nobody really understands: abstractions that pass tests but don’t fit the system, a prototype that looks convincing but ignores edge cases, scripts that work once and then nobody can maintain.

But this is more nuanced than “all code must be perfectly maintainable.” I recently had a small Slack discussion about this and agreed with parts of both sides. For some areas, like data storage, infrastructure, permissions, billing, and core backend logic, I still assume the changes we make today will matter next year. They’re hard to reshape later and mistakes get expensive. For other areas, like a landing page, a throwaway prototype, a small internal tool, or some isolated logic, the tradeoff is different. If AI makes those cheap to change later, it’s okay to be more relaxed.

The hard part is knowing which bucket you’re in. My view isn’t “optimize for maintainability at all costs,” it’s:

  • be strict where the blast radius is high,
  • be flexible where the work is isolated or cheap to replace,
  • and don’t confuse a convincing agent-generated result with something you understand well enough to own.

Done should mean we understand it enough for the level of risk it carries.

What This Could Mean in Practice

I do not think we need a big AI process around this. That would probably become outdated quickly too. But a few habits seem worth considering:

  • If an agent helped with meaningful code, include the evidence in the PR: tests run, screenshots if relevant, logs, manual checks, and anything that still needs review.
  • Keep generated changes small enough to review.
  • Be stricter for data, infrastructure, billing, security, and high-blast-radius work.
  • Be more flexible for isolated, low-risk, or throwaway work.
  • For generated research, summaries, or copy, include the sources and say what was checked.
  • Keep project instructions short and high-signal.
  • Share useful workflows when they teach something reusable.
  • Be careful with output that looks polished but has not been verified.

The goal is not to slow people down. It is to make faster work still understandable and reviewable.

A Few Things From My Own Workflow

This is not meant as a recommendation that everyone copy my workflow. It is just what has been working for me.

For the past few months, Codex has been my main daily driver for work. I also keep using Claude, OpenCode, Cursor, and occasionally newer or open models, sometimes for work and sometimes just to compare.

I also think it is important to keep trying new tools and models. When I joined my current company last June, I was comfortable with Cursor chat, autocomplete, and copy-pasting context between ChatGPT, Claude, AI Studio, and my editor. That worked well enough at the time. But the workflow changed quickly once Claude Code, Codex CLI, OpenCode, and newer models became useful. If I had stayed too comfortable with one setup, I think I would have missed a lot.

I try not to judge new tools only from benchmarks or social media. If a new model or harness looks comparable to the best ones, I would rather try it on real work for a couple of days. That is usually the only way to learn where it is actually good or annoying.

The most useful workflow habit for me has been using another agent or another model as a reviewer. For bigger tasks, I often have one agent do the main work and another one critique it. This has helped me catch weak assumptions, unclear specs, and mistakes before I share the result with others.

I also use speech-to-text more than I expected. These models are very good at understanding messy input, so I worry less about perfect wording and more about explaining the goal, constraints, and context.

The last thing I keep in mind is session length. The tools have improved a lot with larger context windows and context compaction, but long sessions can still degrade. Sometimes starting fresh is still the right move, even if it is annoying.

My Takeaway

I expect more work to happen through agents in the background, and not just coding. I think we will see more agents helping with prototypes, QA, data analysis, internal tools, documentation, content workflows, and product exploration.

Even with all this change, I think the important questions will stay pretty stable:

  • Did we give the agent the right context?
  • Is there a way to verify the output?
  • Is a human still responsible for the result?
  • Can other people understand and maintain what was produced?
  • Is this strict enough for the risk level?
  • Did we share anything useful that others can learn from?

For me, that is the part worth paying attention to. The specific tools will keep changing, probably very quickly. But context, verification, human judgment, maintainability, and shared learning feel like the parts that are starting to stick.

Appendix: A Few More Workflow Details

These are more specific and more likely to change, so I would not treat them as the main point of the write-up.

  • Tool and model differences still matter. I mostly use Codex for work right now, but I still compare it with Claude or OpenCode and newer models. Different models have different strengths. At the moment I find Claude stronger for UI, design, and styling work than the GPT models, but that can change quickly.
  • I like visual apps for some work. Lately I prefer desktop-style apps over pure CLI or TUI flows for longer sessions. It is easier for me to see ongoing sessions, switch between them, and reason about what is happening.
  • Parallel agents are useful, but not magic. I often use one agent to draft a tech spec or implementation and another model to critique it. The second model gives a fresher perspective than asking the same model to review itself, but I still need to review the final result.
  • Context length still matters. Bigger context windows and compaction help a lot, but long sessions can still get worse over time. A summary pasted into a fresh session helps, but it can still lose details.
  • Search quality varies by tool. Codex and ChatGPT have been good for web research in my experience, and Context7 has been useful for current developer docs. Some harnesses can fetch URLs but do not have real web search by default, so it is worth knowing what the tool is actually doing.