What Actually Changes When You Build With Coding Agents (4 Shifts I Wish I'd Known Sooner)

Sanjay T — Fri, 08 May 2026 15:56:52 +0000

I spent a chunk of weekends over the past year using coding agents as my primary engineering partner, building a full-stack enterprise app end-to-end. Spring Boot on Java 21. React 19. PostgreSQL. Playwright tests. Jenkins CI/CD. The whole thing layered the way you'd build any serious system: framework utilities first, reusable component library, UI shell, then product pages on top.

The app itself wasn't the point. I built it because I wanted to know, at a practitioner's level, what actually changes when you work this way — not what the demos and quick-takes claim.

What I learned was different from what I expected. It isn't that coding gets faster. The work itself becomes a different kind of work. Below are the four shifts I'd want to give my past self if I could rewind to day one. If you're starting out with these tools, or you've hit a ceiling with them, this is where I'd put your attention.

1. Stop tweaking prompts. Start curating context.

Like most people, I started by typing prompts, accepting output, fixing what was broken. Repeat. Modest gains, all proportional to how carefully I phrased the request.

Then I noticed something. My best sessions weren't the ones with the cleverest prompts. They were the ones where I'd invested time upfront making sure the agent understood the project — its conventions, its patterns, the decisions we'd made and the ones we'd deliberately rejected. When that context was rich, even lazy prompts produced excellent results. When it was thin, no amount of clever phrasing saved the output.

The lesson, eventually:

The leverage isn't in the prompt. It's in what the agent knows before you prompt it.

This is the mental model shift I think every engineer needs to make. Move from prompt engineering — getting better at asking — to context engineering: curating what the agent has in front of it when you ask. Different discipline, way more compounding payoff.

Practical tip: Next time you catch yourself tweaking a prompt for the third time, stop. Open CLAUDE.md (or AGENTS.md, whatever your tool calls it) instead and add what's missing. The agent was never going to give you what you wanted until you gave it something it didn't already have.

2. Treat the agent as a new team member, every session

Years of onboarding engineers into codebases they didn't know taught me one thing: the onboardings that went well were the ones where the codebase itself taught the new hire. Clear entry docs. Explicit conventions. Notes on patterns we'd tried and discarded. Tests that showed intent. The knowledge didn't live in one person's head — it was embedded in the project.

A coding agent is, every session, effectively a new team member. It knows the language. It doesn't know your project. Unless you've written down what makes your project yours, it'll default to generic patterns that may or may not match what you want.

So I keep a file at the root of every project written for agents. I think of it as the project's constitution: what we build, what we don't, how we do it, and the hard-won lessons that shouldn't have to be re-learned. Every time the agent does something I wouldn't have done, I don't just fix the output. I add a note to the file so it doesn't make the same choice tomorrow.

A trimmed example of what mine end up looking like:

# CLAUDE.md (excerpt)

## Patterns we use
- Server components for data fetching; client components only for interactivity
- All API responses go through the response envelope in `lib/api/envelope.ts`

## Patterns we've deliberately rejected
- No global state libraries. We tried Redux and Zustand; both became debt
- No barrel files. They break tree-shaking in our bundler

## Hard-won lessons
- Date arithmetic always uses date-fns in UTC. Raw JS Date is banned at the boundary
- Never catch and swallow errors in the data layer. Let them bubble; the API layer formats them

That one habit is worth more, over time, than almost any other practice I've adopted. Every correction compounds. The knowledge doesn't forget the way team memory does.

3. Never let the agent write code without a plan

This is the discipline I almost didn't learn, and the one I'd push hardest.

Most of us learned to write code the way we think — fluidly, iteratively, refactoring as we go. That mode does not translate to working with an agent. If I let the agent start writing before we'd agreed on an approach, I ended up reviewing output I didn't actually want. By the time the code was in front of me, the wrong turn had already been taken — and reversing it cost more than planning properly would have.

The discipline I settled into: the agent researches the codebase, proposes an approach, I mark what's off or missing, we iterate until the plan is solid, and only then does any code get written. It feels slower at the start of a task. It's meaningfully faster by the end. And it keeps me — the human with the judgment — making the architectural calls, rather than discovering after the fact that the agent quietly made them for me.

A related tip: delegate outcomes, not keystrokes.

"The CI is failing — figure out why and fix it"

produces much better results than

"change line 42 to use a map"

The first is how you'd talk to a capable teammate. The second is how you'd talk to a dictation machine. These tools reward the first kind of delegation.

4. Invest in the environment the code is produced in

This took the longest to articulate but turned out to be the biggest leverage point.

When you put software in front of real users, you learn quickly that quality isn't about writing great code once. It's about the system you build around the code — the tests that run on every change, the type checks, the linters, the validation hooks, the review workflows. These don't write code. They make sure the code you produced actually works, reliably, over time.

A coding agent makes this lesson impossible to ignore. A model doesn't produce the same output twice. That isn't a flaw; it's the nature of how these models work. The most effective response is to invest in the environment around the model until its variability stops mattering:

Tests that fail loudly on every change
Type and schema checks that run automatically
A second agent reviewing the first
Browser automation that exercises the UI end-to-end

When those guardrails are in place, the agent doesn't have to be perfect. It needs to be capable of iterating against objective feedback — and it is, reliably.

I've come to think of this as the engineer's new core craft: designing the environment code is produced in, rather than producing the code itself. It doesn't look like coding. It looks like plumbing. But with agents in the loop, this is where quality comes from. Investing in it is the biggest leverage point I've found.

The shift nobody talks about enough: recovering from a bad run

One thing I want to flag specifically because it changed how I work more than I expected: the agent will go off-track sometimes. Hallucinated APIs. Quietly invented architecture. Scope creep. Self-contradiction late in a long session.

When it happens, most people either let the run continue and hope it self-corrects (it usually doesn't) or scrap the work entirely (often unnecessary). Neither is right. There's a real skill — recognizing drift early, deciding between surgical correction and full restart, writing redirect prompts that actually work, salvaging the good parts of a bad run — and it's the part of working with agents that almost no public material covers.

I learned it the hard way and put a full lab on it in the workshop below.

The workshop, in case it helps

I wanted my team to get to these ideas faster than I had, so I turned what I'd learned from the weekend builds into a 2-day hands-on workshop and put it on GitHub:

github.com/ssthakuraa/claude-code-workshop

It's built around the actual full-stack app I described above, not toy examples. 13 progressive labs covering CLAUDE.md foundations, plan mode discipline, skills and slash commands, context management, the full hooks surface (all six event types), recovery from bad agent runs, delegated review with fresh context, parallel sessions with git worktrees, verification loops, Playwright and database MCP integrations, CI/CD with permissions, enterprise governance, and a release-style capstone that ties everything together.

Open. Free. Fork it, use it, adapt it. If it helps you skip a few of the false starts I had, it'll have been worth building.

Closing

I don't claim any of this is fully figured out. I'm still refining my own practices, and I expect the specifics to keep evolving as the tools do.

But the broad direction feels clear. The job is being quietly redesigned — and not, I think, into a worse version of itself. It's shifting toward more of what engineering was always supposed to be about: judgment, design, taste, review, craftsmanship around the systems we build. Less mechanical output. More of the thinking.

If you're navigating the same transition, I'd be glad to compare notes in the comments.

DEV Community: Sanjay T