HomeBlogAchievements
AIDeveloper ExperienceCareer AdviceProductivity

How AI is changing the way I work as a developer

Noé Tatoud·February 24, 2025
How AI is changing the way I work as a developer

Six months ago, I wrote maybe 80% of my code by hand. Today, that number is closer to 20%. And I think I am a better developer for it.

Who I Am

I have two years of professional experience as a web developer, and a master's degree that I completed mostly without AI. I've always been the kind of person who loves writing code. The kind who would spend hours on a tricky problem just for the satisfaction of solving it myself, feeling like I'd genuinely learned something in the process.

So believe me when I say this is not an easy shift for me at all. Which is why I wanted to share my view on this subject, hoping it would help some fellow junior developer go forward.

When I first started using AI, I treated it as a peer. I'd ask it to challenge my opinions and decisions. I'd turn to it when I was stuck on a hard problem or wanted to move faster, but I would never blindly copy-paste code.

That's changed... and I think for the better.

How I work now

I generate code, but I still own it

Most of my code is now generated through coding agents. Tools like Claude Code helping me through most of my work. But here's the distinction I want to emphasise: Not writing code doesn't mean not owning the code. I still review every output carefully, the same way I'd review a colleague's pull request. The authorship model has shifted, but the accountability hasn't.

I also use agents for a first pass on code review. They catch the silly mistakes: typos, formatting issues, obvious logic errors, so that when I ask a colleague to review my work, their attention goes toward the things that actually matter.

It frees up headspace for higher-value work

This is perhaps the biggest shift. I used to spend roughly 60% of my time writing code and maybe 20% actually thinking about the problem. Those numbers have flipped. When an agent is running a task, I'm not sitting idle. I'm writing specs for the next piece of work, diving deeper into business logic, or thinking through constraints that no AI is going to figure out for me: What are the DX painpoints we could not address until now ? What part of our workflow could we improve ?

Testing matters more than ever

When you're not writing every line yourself, tests become your safety net and your specification. But not just any tests. You have to be clever about what you test. The goal isn't coverage for coverage's sake. It never was. It's writing tests that actually validate behaviour and catch the kinds of mistakes agents are prone to making.

In practice, this has changed my approach in a few ways. I now try to write tests before generating code, so the agent has a clear target to hit. I lean more on integration-level tests rather than just unit tests, because agents can produce code that works in isolation but breaks in context.

I'm less afraid of breaking things

Want to change a function signature that's used everywhere in the codebase? That used to be a mountain of work: find every call site, update them all, hope you didn't miss one. Now it can be done in minutes. AI has dramatically lowered the cost of large-scale refactoring, which means I'm more willing to improve the codebase instead of working around its flaws.

There's a broader point here: AI lowers the cost of doing things the right way. Technical debt becomes cheaper to pay off, so there's less reason to accumulate it. That refactor you've been putting off for months? It's now an afternoon's work, not a sprint-long commitment.

I still read the docs

Even with AI, I make a point of reading documentation, or at the very least, asking the AI to point me to the relevant docs when it does something I don't fully understand. Understanding why something works a certain way is just as important as getting it to work.

My setup

For those curious about the specifics, here's what my daily toolkit looks like:

Claude Code is the engine. It's Anthropic's command-line coding agent. I use it for generating code, running first-pass reviews, and working through implementation tasks. I define the constraints, it executes, and I review the output.

Conductor is what ties it all together. Built by Melty Labs, it's a Mac app that lets you run multiple coding agents in parallel, each in its own isolated copy of your codebase. Think of it as a dashboard for your AI team: you can see what each agent is working on, review their diffs, and merge changes. All without the agents stepping on each other's toes. It's what makes the "work on specs while the agent codes" workflow actually practical.

Zed is my editor. It's built from scratch in Rust, so it's blazingly fast and lightweight, which matters when your workflow is mostly reviewing and editing code rather than writing it from scratch. Its built-in AI features (inline transformations, an agent panel, edit predictions) make it a natural fit for quickly reviewing and refining what the agents produce.

What I'm watching out for

I don't want to make it sound like it's a perfect way of doing things. There are real risks to this way of working, and I think about them often.

Skill atrophy is the one that keeps me up at night. Am I losing the ability to debug deeply because I let agents handle it? I try to stay sharp by occasionally working through problems manually. Not because it's efficient, but because it's exercise. The same way a pilot still needs to know how to fly without autopilot.

Over-trust is another trap. Agents produce confident, plausible code that can be subtly wrong. I've caught bugs that looked perfectly reasonable at first glance: correct syntax, sensible variable names, coherent logic but that handled an edge case in exactly the wrong way. The review step isn't optional; it's the whole point.

The dependency question is worth asking too. If the tools disappear tomorrow, or the pricing changes dramatically, how quickly could I revert to my old workflow? I think the answer is "fairly quickly" (I would still have to deal with the feeling of being absurdly slow...), but only because I built foundational skills before relying on AI.

Which brings me to my advice for people earlier in their careers or just finishing their studies.

Advices for students and junior developers

If you're early in your career, the landscape has shifted, and it's worth thinking about what that means for you. Here's the uncomfortable truth: a lot of what junior developers traditionally did (writing straightforward CRUD endpoints, building simple components, fixing well-scoped bugs) is exactly the kind of work AI handles best. These were the tasks that got you your first job and helped you learn the ropes. That entry point is narrowing, and the bar for what makes a junior developer valuable is shifting fast. I dont pretend I've got it all sorted out, but I think I can come in with a few tips to help!

Ask yourself: what can I bring that an AI can't?

AI can write code. It can write it fast, and often it can write it well. So the question becomes: what's your edge? The answer lies in everything around the code: understanding the problem, communicating with stakeholders, making judgment calls under uncertainty, and building trust with your team.

Soft skills matter more than ever

Communication, collaboration, empathy, the ability to navigate ambiguity. These have always been important, but they're becoming the primary differentiator. The developer who can translate a vague business need into a clear technical plan is more valuable than the one who can write a perfect algorithm from memory.

Be proactive

The era of waiting for a senior to hand you a ticket, working on it, and waiting for the next one is over. Take initiative. Propose improvements. Identify problems before they're assigned to you. AI has compressed the execution cycle, which means the bottleneck has shifted from "can you build it?" to "do you know what to build and why?"

Use AI to go deeper, not just faster

It's tempting to use AI purely as an accelerator. get the code out the door quicker, move on. But the real leverage is in using it as a learning tool. Ask it to explain why it made certain choices. Ask it to show you alternatives. Use it to explore areas you wouldn't have had time to explore otherwise.

Challenge senior decisions

This might feel uncomfortable, but it's important. AI gives you access to information and perspectives that used to require years of experience to accumulate. Use that to have informed opinions. Go deeper into your subjects. In a healthy work environment, a well-reasoned challenge from a junior developer is a sign of growth, not insubordination.

What to avoid

But there's a tension here I want to be honest about: if you use AI to skip the struggle phase entirely, will you develop the intuition needed to review AI output effectively? I don't think the answer is to avoid AI. That is not an option anymore. But I do think you need to be intentional about when you let the tool do the work and when you push through the difficulty yourself. The struggle isn't the point, but the understanding that comes from it is.

Key Takeaways

If you take one thing from this post, let it be this: AI changes how you work, not whether you need to think.

Here's what I'd recommend, regardless of your experience level:

  1. Review AI output like you'd review a colleague's PR. Never merge what you don't understand.
  2. Write tests before you generate code. They're your specification and your safety net.
  3. Invest the time you save into thinking. Specs, architecture, business logic: that's where your value compounds.
  4. Refactor more often. The cost of doing things right has dropped dramatically. Use that.
  5. Stay curious. Read the docs, understand the why, and keep building foundational skills even when the tools make it easy to skip.

Where this is heading

I started my career believing that writing code was the craft. I still believe that! But I've come to understand "writing code" more broadly. It includes knowing what to build, why to build it, and how to verify it's right. I let go off the act of typing characters into an editor, to fully focus on what matters: The thinking behind it.

AI hasn't replaced me (yet). It has compressed the parts of my job that were mechanical and expanded the parts that require judgment. I spend less time fighting syntax and more time understanding systems. Less time on boilerplate and more time on architecture. Less time alone with my editor and more time with my team.

I don't know exactly where this goes. But I know that the developers who will thrive are the ones who treat AI as a shift in how they work, not a replacement for what they do.

Let's connect

Built with React, TanStack & Tailwind

© 2026 Noe Tatoud. All rights reserved.

HomeBlogAchievements