As a developer, my friends and family alike have both naturally asked me something along the lines of: “Are you worried about AI taking your job?”
I rarely hear the same question from other developers, and I think there’s a good reason for that. These concerns often come from the news, where headlines monetize the fear and uncertainty associated with job loss.
I’m not trying to make light of a serious topic. I’ve personally experienced job loss within the last few years because of market uncertainty and an economic downturn. But there can be a significant difference between the headlines and what developers are experiencing in their daily work.
This is about my own experience with artificial intelligence and how I see it affecting the software industry, without the fearmongering.
AI has already changed how I work. I use it daily. But the more I use it, the more I realize that it accelerates the mechanical parts of the job while leaving many of the hardest parts firmly in human hands.
Where AI Genuinely Helps
AI tools have made me faster at the repetitive, structural parts of software development: scaffolding a new class, generating test skeletons, writing boilerplate, and whipping up prototypes.
These smaller tasks used to consume chunks of my day, not because they were particularly difficult, but because they were tedious. AI compresses that work significantly.
It has also shortened the feedback loop around syntax and API questions. Instead of digging through documentation, I can describe what I want and get a working starting point in seconds.
For completing familiar patterns, explaining unfamiliar code, and getting oriented in a new area of a codebase, AI is a massive productivity multiplier. Developers who learn to use these tools effectively have a significant advantage over those who don’t.
Where It Falls Apart: Business Logic, Client Communication, and Hidden Bugs
After using AI on production software, I quickly learned that it is confident, fast, and frequently wrong about the things that matter most.
In any sufficiently complex project, business logic can be shaped by years of accumulated rules. Some are well documented. Many aren’t. Models have a tendency to drift away from client expectations, requiring significant time and deliberate effort from a human to keep them on the rails.
I’ve given AI tools extensive context for tasks: schema definitions, anonymized example data, access to the relevant code, project documentation, and Markdown files containing additional guidance.
Sometimes the model produces something that compiles, passes every test, survives a surface level review, and is still wrong. A perfectly implemented misunderstanding. The agent produced something that was technically sound code, but it was built on an incorrect understanding of the problem.
Not wrong in an obvious way. Wrong in the way that only becomes apparent when you know that a particular value means something different in one context than it does in another. Or that a specific sequence of events implies an outcome that isn’t stored in any single field.
Much of that logic comes from institutional knowledge. Edge cases accumulate in conversations, past decisions, and experience that rarely make it into the model’s context window.
AI in Communication: Helpful, but Not Reliable
Code isn’t the only source of context available to AI tools. A modern development workflow can preserve and organize information from client conversations with surprisingly little manual effort.
Sample Workflow
A typical workflow might look like this:
- A meeting tool such as Granola, Fathom, or Otter captures a client conversation and creates a transcript.
- The tool generates a summary containing potential decisions, requirements, questions, and action items.
- A developer reviews that material and adds their own interpretation. A voice-dictation tool such as Wispr Flow can make this faster by turning spoken thoughts into written notes.
- The transcripts and notes are put into a knowledge base that the team can search later.
It’s an impressive workflow. A team can preserve client conversations without someone manually transcribing each meeting and organizing every note.
Opportunities for Misunderstanding
It also introduces several opportunities for a misunderstanding to slip through.
The transcription tool might get a domain specific term wrong or attribute a statement to the wrong person. The generated summary might turn an open question into an apparent decision. My own dictated notes might reflect what I thought the client meant rather than what they actually meant. When someone later searches the knowledge base, that interpretation may look like an authoritative requirement.
The person reading it may not know which sentences came directly from the client, which were generated by a meeting assistant, and which were someone else’s interpretation.
This doesn’t make transcription, summarization, or dictation tools bad. I find them extremely useful. With a good collection of recorded meetings and transcripts, they can find relevant information much faster than a human could – but they can also do so unreliably.
The most useful workflow preserves a path back to the source material. When a summary says, “The client confirmed X,” I should be able to open the recording, jump to that part of the conversation, and verify it myself. When my notes contain an interpretation rather than a direct decision, that distinction should remain visible.
AI can narrow several hours of conversation down to the few minutes that matter. The developer still confirms what was said, resolves any ambiguity, and decides how that information should influence the software.
The Client’s Perspective
Working at a consultancy makes all of this especially visible.
Our clients don’t hire us to type fast. They hire us because they have complex problems that require people who can listen, ask the right questions, and translate messy real-world requirements into working software.
AI doesn’t sit in a discovery meeting and notice that two stakeholders are describing the same feature differently. It doesn’t reliably push back when a requirement conflicts with an existing system constraint. It doesn’t build the trust that keeps a client relationship productive over months or even years of collaboration.
A significant part of professional software development isn’t writing code at all. It’s understanding what needs to be built, why it needs to work that way, and which tradeoffs are acceptable.
That work is conversational, contextual, and deeply human. Prompt engineering can support it, but it doesn’t remove the need for it.
What Is Changing?
In my own work, the use of AI has meant spending less time on mechanical coding and more time in a couple of distinct areas.
Owning the System
Someone still has to understand how the pieces fit together, what might break when something changes, and why a decision was made six months ago.
AI generates code within the context it has available. Developers maintain systems over time. That continuity is where reliability and trust come from.
Reviewing Critically
AI-generated code requires even more scrutiny than code you write yourself. Because you didn’t reason through every line as it was created, you don’t have the same implicit understanding of how the implementation arrived at its result.
The Bottom Line
AI is the most useful tool I’ve added to my workflow in years. It makes me faster at work I was already capable of doing, and it has increased the speed at which I can learn.
As implementation gets faster, recognizing and preventing perfectly implemented misunderstandings becomes an increasingly important part of the developer’s job.
Being a developer means serving clients, navigating ambiguity, and being held accountable for systems that affect people.
The developers who thrive won’t be the ones who prompt their way out of writing code. They’ll be the ones who stay organized and use these tools to spend extra time on the work that makes a larger impact.