I spend most of my time explaining to an agent what I want, why I want it, and what constraints matter. I give exact descriptions when needed, plus links to the right docs. Sometimes those docs are full of typos, and that is OK. Then I review what comes out. For a huge part of my day-to-day engineering work, this is simply faster.
And if we are honest, in most systems, the Pareto rule applies.
For 80% of what we build, I do not care that much whether the agent used map or a for loop, OOP or functional style, or some "very elegant" abstraction. Is it an API endpoint? A DB query? A CRUD flow? Fine. What I care about is the output. Is it correct? Is it safe? Can we ship it?
It is also very likely I will not be the one maintaining that code. Another agent probably will.
Now, this only works if your engineering basics are strong. Actually, they need to be stronger than before. Tribal knowledge does not work with agents starting fresh on each run.
Because "English is my new programming language" does not mean "standards do not matter anymore." It means standards and guardrails matter so much more.
You need CI/CD that blocks bad changes. You need tests: unit, integration, end-to-end. You need gradual rollouts, smoke tests, monitoring, alerting. You need pull request review. You need context awareness on the scope of the change and the criticality of what you touch.
And locally, you need fast feedback loops: linter, formatter, fast builds. Shift-left has never been this true. If feedback is fast, the agent iterates fast and can run its loop locally.
Very capable. Very fast. Sometimes impressive. Still not autonomous in the way people fantasize about. I would trust a good intern to implement a lot when motivated. I would absolutely not skip reviewing their changes. Same here.
If the intern breaks production, blame the game, not the player. Same for code created by an agent, in my opinion.
Review is still a thing. Maybe the thing nowadays. We spend more time writing specs and reviewing PRs, and I still do not think we have reached a turning point where we can skip checking generated code for production-scale projects.
When things go wrong, you need to know the structure of the codebase and where to look. Maybe this is just engineering curiosity, maybe it is risk management, probably both. But the day prod is down and Claude plus OpenAI are down too, you still need to fix it yourself.
During review, I am not only checking low-level style comments like "you used let instead of const" or "careful, you mutate state here."
What I really want to check is whether we are using current best practices. Is this API using the new decorator the team agreed on? Is ownership clear? Is observability in place? Are we respecting patterns we know scale in production? Is this internal and low risk, or is this critical path code where every generated line deserves deeper review?
And when I find myself repeating these rules, questions, and comments, that is usually a signal: write them down.
That is why skills (like Claude Skills) are a big deal.
Skills are how standards get distributed: how to create a service, define ownership, model a domain, and speak business language in the codebase. Less tribal memory, less repeating yourself in PR comments, more consistency by default.
Same story for documentation.
To code well in this era, good documentation is not "nice to have." It is core infrastructure. API specs, READMEs, architecture docs, sharp examples, and links to the few pages that actually matter. What I think is core to good AI-driven development:
README.md (for your developers too!) - Here I would expect to find the getting started instructions, a summary of the project, and links to relevant docs.AGENTS.md - Keep it very short here. Only give the big lines (main tech, quick repo structure). I like Matt Pocock's approach here: https://www.aihero.dev/a-complete-guide-to-agents-md
"The ideal AGENTS.md is small, focused, and points elsewhere. It gives the agent just enough context to start working, with breadcrumbs to more detailed guidance." Matt Pocock.
Skills - Basic AI skills on how to work with your repo and your libs: what you expect for commits, pull requests, testing, and ways of working with specific libs. If you work with Cloudflare, add their skills to your repo! That'll enable anyone working with the repo to produce less garbage.Type-safe schemas - If you use end-to-end type-safe schemas to build your clients and backend APIs, agents usually work better with that than with API specs. But you should still generate OpenAPI specs from the schemas, for instance. And make it clear with a skill that this is automated.Tests - Tests are documentation. Get powerful smoke/e2e tests and you'll save yourself a lot of headaches when shipping faster. Regression is your biggest enemy here; you don't want to break existing flows by adding new features. Again, it's nothing new in our SDLC world.Without that, you spend the same amount of time re-explaining your system to the agent as you would with a junior engineer. Again and again and again.
The thin line now is deciding what should be a skill, what should be a README, and what should just be a code comment.
Explaining a task to an agent feels a lot like leaving instructions to myself for one month later (I am pretty sure you know that comment you left somewhere in the codebase and you stumble into it from time to time, thanking your past self for clearly describing what the issue was 😅).
I know I will forget context. The agent never had it. So I need clear explanations of what should be done, how to do it, and where the source of truth lives.
It is funny when you think about it. We used to say good engineering practices were documentation, tests, and clear code comments. Now we are saying it again like it is brand new.
In the end, using AI agents feels a lot like scaling your engineering team. In the past, if your team grew x10, you needed more process, more test coverage, and better documentation. Working with agents feels very similar, just faster.
So yeah, my new programming language is English.
Not because code disappeared into a black box. Because the highest leverage moved one level up: from typing instructions for computers to writing intent and constraints for systems that generate implementation.
And in that world, the teams that win are not the teams that type fastest. They are the teams that specify clearly, review rigorously, and document like context is always missing.