The first wave of AI coding tool adoption is producing a paradox inside engineering organizations. The teams that have invested in clear standards, rigorous review habits, and deep domain understanding are accelerating. The teams that have not are shipping code faster while accumulating fragility. The gap between those two outcomes depends on whether the engineers using the tools have the judgment to evaluate what comes back, and whether the organization around them has built the guardrails that make that judgment visible.
Melonie Miller is a Software Engineer at HST Pathways, a healthcare software company serving ambulatory surgery centers and surgical hospitals across the US. Her work centers on distributed systems and application engineering inside a regulated healthcare environment, where reliability and correctness carry more weight than speed. Miller started her career at a pivotal moment, graduating into the workforce just as GitHub Copilot was being released, which gives her a unique vantage point on how AI coding tools shape engineers from their first days on the job.
"AI exposes both your good habits and your bad habits. You're going to have some people that don't review well or skim the surface of reviews. Now it's exacerbating that wound," she says. The implication is that AI coding tools do not create good or bad engineers. They make the existing variance louder, which means the organizational response has to focus on the conditions that produce judgment in the first place.
The cleanest test of engineering capability still happens during incidents, and AI doesn't change that. The middle-of-the-night outage is the moment where systems intuition, tech stack familiarity, and domain knowledge actually decide whether the team can recover. "When it's 4 a.m. and everything's down and clients can't log in, AI is not going to save you. You're going to have to understand what tech stack you're on, what your domain is, and how things are configured," Miller says.
In her view, the foundational work of becoming a good engineer still has to happen, and the organizations that use AI to bypass that work end up with teams that can't operate when the tools fail. The early-career stakes are particularly high, because the habits engineers build in their first years shape everything that follows.
One highly useful posture Miller takes with AI tools is treating them as a senior engineer she can interrogate without taking the real seniors' time. Her own early use of Cursor focused on understanding the architecture she was working inside. "I would use Cursor to map out diagrams of the system. 'Explain the authentication mechanism here. Explain how this printing service works.' I started asking it to do architectural reviews. That skyrocketed my career, being able to sit there over and over again in my first year of development work, instead of going to the senior engineer, bugging him, taking away his time," she shares.
The reframe matters because it inverts the most common failure mode. Junior engineers under throughput pressure use AI to ship faster without understanding what they shipped. Engineers using AI as a learning tool develop architectural intuition faster than they otherwise would, and they arrive at senior-level system thinking earlier in their careers. Miller poses an important question for juniors. "Are you being prompted to think with discernment and think with that system-level approach that has to be developed naturally?"
The organizational response to AI's exposure of habit gaps is to make standards explicit. Miller describes a deliberate shift toward writing down expectations that used to live as implied team knowledge. "We need to set up specs where these rules are baked into our AI agents. We're in healthcare, so we have a lot of compliance rules. Our Augment rules, our Claude rules, design standards, syntax requirements, all of those are outlined. The moment we see something isn't done a certain way, we add the rule."
Visible standards solve a problem that used to live in tribal knowledge. New engineers can see what good looks like instead of having to infer it from code review comments. AI agents can be configured against the same standards, which means the guardrails apply consistently regardless of who is generating the code or how senior they are. "It's better enforcement for engineers to be able to see those rules and say, 'Oh, it's written down. This is how everyone wants things set up. This is how I should name things,'" she explains.
Miller says the limits of current AI coding tools are sharpest in two places: anything requiring meaningful indentation or visual styling, and any task that requires understanding code outside the immediate file in context. "Getting AI to understand infrastructure as code is fairly difficult. AI doesn't have eyes. It's obviously not great at making things look good. It also struggles with complex production issues, especially as we're moving legacy systems into this AI-native development workflow."
Legacy code bases compound the problem. Healthcare software companies running 15 years of code have hundreds of thousands of lines that were never written with AI consumption in mind, with sparse comments and decade-old decisions that even human engineers struggle to parse. "We're having to go piece by piece and make sure those systems are understandable. The level of understanding that things exist outside of the question I asked, it's not there yet." The temporary nature of that limitation matters. Context windows are expanding, multi-repo awareness is improving, and the workflow of feeding AI specs about how products relate to each other is becoming standard. The teams that invest in that scaffolding now will reap the compounding benefit later.
Miller's closing assertion runs back to where engineering value will actually accumulate. AI is absorbing the language-level work, which means the differentiating skill becomes everything AI cannot do: understanding stakeholders, anticipating future business needs, and identifying integration risks before they appear in tickets. "What has shaped my career the most is business-level understanding," she says, "understanding what the needs are before they're even specified. I can go into a code base and say, this is going to be a problem. I don't need a customer to explain it to me because I know that it's coming." She sees the role of a software engineer becoming more people-facing, not less. The engineers who will matter most are the ones who can move between product strategy conversations and architectural reviews fluidly, because the unique value sits in the connection between those two layers.
The same posture shows up at the infrastructure level. Miller's team has invested heavily in cross-functional standardization, unifying naming conventions, AWS resource patterns, and integration specs across products. The standards feed back into the AI tooling, which means new work inherits the consistency by default rather than relying on individual engineers to remember it. "That by itself has eliminated so many cross-product pain points and really sped up our ability to integrate our products," she says.
The throughline across all of it is that AI rewards organizations that have already done the hard work of building judgment, standards, and business fluency, and exposes the ones that haven't. For engineers like Miller who started their careers alongside these tools, the lesson is clear: the technology is a multiplier, not a substitute, and what it multiplies is whatever was already there.
