All posts

How AI changed software development workflow

Is coding with LLMs easier, more demanding or just different? My personal feelings about it.

Rafal Graniczny8 min read
How AI changed software development workflow

More than a year ago, I was traveling from Poland to Croatia. My fiancee, who was to become my wife in 3 days, was driving and I was coding the whole day in the car, trying to finalise a critical feature that only I could do in my team. It needed to be finished, otherwise the company would probably fail. I spent around 20 hours purely on coding and testing. Finally I made it, demo was successful and we are still alive

At that time I was using Windsurf, powered by Claude, but the feature was so complex that AI couldn't do it, it failed to understand the problem, clueing around, and finally not helpful at all.

I’m far from being an AI hype fanboy, trying to stay somewhere in the middle, but the honest truth is that today, with AI, I would finalise this feature in an hour.

Old lovely world

I've been a software developer for around 10 years now. I’m building web apps. Around 1 year ago my flow for building new feature was:

  • Get requirements from product team - help them out with technical part, give some tips and thoughts;
  • Create short jira ticket without much of the description;
  • Plan work;
  • Code;
  • If some unseen obstacles came - discuss with product
  • Finalise code and test locally
  • Create pull request
  • Wait for all checks to go green
  • Ask for code review
  • Work with pull request if anything comes from code review
  • Merge
  • Check if everything is deployed and stable
  • Track QA flow and potentially rework something if QA finds anything
  • work done, present on demo

(Ofc, this flow depends on the project and team, but in a shortcut, it looked like this.)

If I could guess how much time I spent purely on coding when AI was not helpful at all, I would say 35%. When I look back, I see that I spent a lot of time on requirements gathering, code reviews, testing not only final outcome, but testing during the coding process, writing tests (this is a big one) and ofc - debugging (which I loved and I was good at).

Brand new world

I remember while I was still using Windsurf, then Cursor, I was still coding, but then Claude Code came, Sonnet and Opus 4 started to really make a difference. Models understood more, did less mistake, finally it was better to prompt then to fix issues on your own. After a while models also got better in debugging, throwing all of the fancy commands, understanding code better, having bigger contexts, prompts no longer need to be super specific, they can find staff and they can ask you questions that are meaningful.

With that all under consideration I think from around July / October 2025 I haven’t written a single line of the code.

This way of working is still new and we are still figuring it out, but atm my flow looks like:

  • Get requirements from product - it’s still here, but I see that product people are also using AI a lot, they don’t have technical questions any longer, requirements are already done taking our current codebase under consideration, they are basically ready for AI to implement
  • Create Jira tickets with Claude Code (Atlasian MCP - if your not using it yet, than start, really)
  • Start Claude Code, create a worktree if I work on several things at once.
  • Ask Claude Code to check ticket and plan implementation, I pick effort level on basis of task complexity
  • Iterate on the plan
  • Accept the plan and decide if to use agents for it, or plain claude code is enough.
  • Go through code, see what exactly was changed, think if it suits our architecture, basically do code review.
  • Ask CC for changes if needed.
  • Test work manually (all tests already ran by CC after implementation)
  • Ask CC to fix, change things that are not working or I don’t like
  • Final CR on newest changes
  • Ask Claude to create PR
  • Wait for checks and for AI code review
  • Ask Claude to check and fix issues found by AI code review tool
  • Push the code and wait for checks
  • Ask for Code Review of the team
  • Ask Claude to check if anything comes from people (which is a super rare thing atm)
  • Merge
  • Check if everything is deployed and stable
  • Track QA flow and potentially rework something if QA finds anything
  • work done, present on demo

(Again, this flow depends on many things, it looks like this for me now)

Hot take after I wrote this: new flow is spaghetti. It’s a lot more complex than it was before, a lot more checks, pitstops, it's basically managing an engineer standing over him/her and showing with your finger what to do.

Then vs Now

Aren’t differences obvious? Let’s try to summarize them:

  1. Time spent actually coding: ~35% of my time before. Now? Zero. Literally.
  2. Debugging: Gone.
  3. Writing tests: Used to eat up a huge chunk of time. Now it's just... done in seconds.
  4. Jira tickets: Before — a few lines, no description. Now — full specs, written by Claude. Wild.
  5. Code reviews from teammates: Still exist on paper. In practice, almost nothing comes back. Either we're all getting better or nobody has time to argue with AI.
  6. Complexity of the flow: Here's the irony — the new flow is objectively more steps. More checkpoints, more back-and-forth, more "wait, let me verify this". It's not simpler. It's faster, but not simpler.
  7. My role: Shifted from engineer to something between a tech lead, a product manager and a very picky QA. I'm not building anymore — I'm directing, reviewing, deciding.
  8. The vibe: Before felt like craftsmanship. Now feels like managing a very fast, very confident intern who occasionally hallucinates.

Is it all good or bad? I don’t know, some people claim to know that, but I don’t think they really do, what do you think?

What I see happening

First of all, features feel cheap now. For both stakeholders and for engineers. Looking at the flows comparison, it’s not true. Changing threads in your head all the time, doing 3 features at once, it’s super exhausting work, yet, not so satisfactory - as you feel you did nothing, so it can create an imposter syndrome in your head.

Engineers are losing track of what is in the code. Spikes for checking what is in the code is another thing that I’m seeing atm. Code review now should be focused on understanding how a new feature is composing into the whole architecture, but, who has power to switch threads even more into another AI job, you reviewed your agents already right?

We ship more, but we understand less. We are not learning so much any more. Back in the days, engineering managers / CTOs were also not coding much, but they were coding their own projects after hours, they were taking heavy tasks, basically they were not learning so much as juniors or mids, but still on track. Now you're a manager of your AI agent, after hours you’re manager of another AI agent. Getting dopamine shots after a feature is working like a charm after 2 lines prompt - but your brain rots, sorry.

What we can do about it

I think we need to realise that AI hype bros are not right, at least not atm. AI won’t do everything, it is helping a lot, but it’s also creating new challenges. So at the end of the day stay positive: without you nothing would happen, you delivered things, it’s your work, not AI’s work.

Another thing is that anti AI bros are also not right. Not all projects need perfect architecture, not all projects need that developers working on them know everything that is in the code. Not all projects will collapse if we partially lose track of following architecture decisions. Don’t be delusional, at the end it’s about money, not about code quality and beautiful architecture.

Finally, we need to understand: coding is no longer deep focus, zen, 8h full into the code job. We need to make peace with ourselves, so that this time will not come back. You need to be a manager, architect and QA now - it’s ugly true. You need to learn to maneuver in this environment, find your joy in doing it and at the end of the day be happy with the outcome.

So my final take is: be flexible, be in the middle, listen and learn, we all are still figuring it out.

Rafal Graniczny

Written by

Rafal Graniczny

Founder, Reviewsaur

Building Reviewsaur so engineering teams actually understand the code they ship — not just rubber-stamp it.

Keep reading

Reviewsaur quizzes reviewers on the PR diff before they can merge — no more rubber-stamp approvals.

Get started — free