Five Ways AI has Changed the Way I Work as a Software Engineer in Six Months
More code, less collaboration, with a touch of guilt.
Six months ago, I started really incorporating AI into my day-to-day job as a software engineer. At first, I was just posting code snippets into the ChatGPT chat, but over the past couple of months I’ve been using Copilot’s CLI heavily.
It’s incredible how quickly it changed how I work — for the better and worse.
#1: I push more code
This one is obvious: I’m pushing more code. Features and updates that I used to estimate as two or three days now get merged into our main branch in one.
This doesn’t necessarily mean we’re getting more features into production, though. Features still have to be QA’d. We’re also still limited by our users, and making sure our releases don’t interrupt their work. But, when we are releasing new features, there has been more of them at once.
We’re able to prototype features more easily, too. If someone has an idea, we can throw something together far quicker than we used to. This allows us to churn through possible paths over the course of an afternoon, instead of a back and forth that might have taken days previously.
Here’s a great example: I was working with my product manager on an issue with a printed version of a report that required a ton of tedious print-specific CSS rules.
With AI, we made a variety of adjustments to the final printed product in about an hour, and got way further than we could have otherwise. He had a vision of how things should look, and I could actively show him what the changes looked like in minutes instead of working around the intricacies of the code myself.
#2: I’m less afraid of throwing away code
Speaking of prototyping, as a team, we’re now less afraid of committing to work that might get thrown out. Before, we had to worry about if we were committing to work that we might not keep.
Like most teams, our capacity isn’t infinite. Losing a couple days of work on something we didn’t need, or ended up not wanting could seriously hurt our ability to deliver on time.
It was a balance between whether it was worth it to put a developer on a feature we weren’t sure about versus putting their effort into other things we were more sure about.
Of course, it doesn’t eliminate the need for critical consideration of work completely. We still have to be concerned that AI will get our code base into a state that’s hard to come back from. Likewise, we make sure we’re not making irreversible changes to our database. And prioritizing meaningful work for our stakeholders doesn’t go away. But it’s a lot less of “Can we risk doing this?” and a lot more of “Let’s give it a try.”
As a developer, this is a great feeling. It’s liberating to know that I wasted a few credits versus an entire afternoon trying out a new layout on a page. The gears in my head start turning, and I can work through it without the disappointing thought of “I don’t have time for that.”
#3: I’m collaborating with my fellow devs less often
I’m the lead developer for my team, and I spend a good amount of time in meeting with product owners and stakeholders. I used to spend a good bit of time with the other developers on my team discussing approaches. Since we’ve all become accustomed to using AI, though, I can tell their collaboration has shifted from working with their fellow developers to working with their AI agents.
This isn’t necessarily a bad thing. Every developer — from our most junior to our most senior — are able to be more independent and self-sufficient. They can be less afraid to make small code mistakes. They don’t necessarily have to come to me to figure out an issue.
But, I do think the longer we go down this path, the less collaborative we will become. Where we gain efficiencies, we lose connection with our team members. There are far less opportunities to fall into an interesting conversation about some code or a different technology.
Many companies cited collaboration as a reason to have people come back into the office. Being in the office, they said, was a great way to spur ideation. Isn’t it kind of strange that those same companies are now trumpeting AI without the consideration that we’re becoming isolated to our chat windows, and have simply stopped talking to our coworkers as a result?
#4: Expectations have shifted
Thanks to AI, it’s a lot harder to say, “I don’t know” when talking about something in software development. You are expected to have the knowledge because it’s expected that AI will. I used to value people who were willing to admit they didn’t know something but had the desire to learn it.
Now, it feels like that isn’t an acceptable response. No one has actually said that to me, so maybe this is just a personal issue I have to get over. There’s a certain level of guilt, or shame, or something I feel knowing that I could prompt my AI agent and just avoid saying that. Even asking questions from people who might have more experience than me prompts a moment of, “Should I be asking them this?”
But that kind of misses the entire point of software development. When people think you can get whatever answer from AI, you stop learning. You stop growing as a developer. When you have a question, you are just relying on the AI to do your job instead of learning from experience. Learning takes more time than prompting AI, but it also builds stronger employees at the same time. When you spark a conversation with another human, you never know the connection someone else may help you make, or the idea they could plant in your mind.
I’m lucky to work in a company that still values the learning portion of software development. There are many companies and industries where not knowing something and working on learning it is seen as a weakness. In software engineering, there is still value in saying, “I don’t know, but I will find out.” AI can either replace the second part, or make it easier.
#5: Keeping your skills sharp is a lot harder
But what about the things you used to know?
Anyone who has worked with AI for any length of time knows one thing: AI isn’t (yet) a silver bullet for everything. There are a ton of things it still struggles with. I frequently run into things where Claude, or Codex, or Copilot, just spirals and I have to undo everything it tried and then go fix it myself.
At the same time, anyone who has worked in software development for any amount of time also knows that building software is a muscle that quickly atrophies when it’s not worked.
AI lets you get away with not flexing that muscle. We get better at this through repetition. When we let AI step in for us, we lose the repetitive part. You get out of the mindset of working in code everyday, to just relying on AI to do the heavy lifting. You become completely disconnected from what’s going on in the code base — and when something goes wrong, it’s harder to reason about a solution.
A lot of the time, the only muscles you’re working when using AI are those related to planning and code review. While valuable, those alone won’t build good software.
So, how am I breaking that cycle? Well, first, I try not to have AI do everything for me. I’ve found there are certain things AI will struggle on, and that I can just do quickly without prompting. This keeps me engaged in the code base, and makes sure I’m not completely forgetting what’s going on.
I think it’s also important to have personal projects where you’re trying new things. AI can be great for this, but you also want to make sure you’re thinking through the solutions and what makes good software yourself, too.
It’s important to remember that even though AI is becoming increasingly powerful, helpful, and useful, it’s still a tool. A tool is worthless without someone who knows how to use it. While it has changed the way I’ve worked, I also want to make sure the only changes it makes to the way I think are positive.