At Axuall, we know that our value as a workforce intelligence company built on a national, real-time provider data network, depends entirely on the quality and integrity of our code. While many healthcare vendors tout AI as a vague strength, they struggle to articulate its actual impact on their solutions. Our competitive edge lies in the rigorous application of AI within our engineering culture.
Read on to learn how our Chief Technology Officer, Michael Hawkins, explains how we’ve moved past the skepticism surrounding AI-assisted development and made it a core part of building production software. This commitment to cutting-edge engineering ensures the Axuall platform remains the most secure, efficient, and scalable solution on the market, equipping healthcare executives and staffing leaders with the unmatched data they need to meet patient demand, improve efficiencies, and reduce provider burnout.
By Michael Hawkins, Chief Technology Officer at Axuall
For the past decade, engineering teams have benefited from steady, incremental improvements in developer productivity. We have seen better IDEs, better frameworks, better CI/CD pipelines, and better testing tools. However, nothing in that time has come close to the impact of AI-assisted development. Over the last 18 months, our engineering team has used AI coding tools not as a novelty, not as a side experiment, and not just for prototypes, but as a core part of how we build production software. The results have been undeniable. Yet if you read social threads and comment sections, you will still see the same dismissive reactions:
“Mixed results. Useful for POCs, but I would not trust it in production.”
“Fine if you do not care about maintainability, efficiency, or security.”
“It is a shortcut that creates more mess than it solves.”
These statements might have been understandable when coding LLMs first appeared. They are no longer grounded in reality. The truth is simple: AI-assisted coding works in production when paired with a strong engineering culture and a modern SDLC. Teams that refuse to embrace it are falling behind, and they are doing so quickly.
From Skepticism to Curiosity to Culture
When we began our AI journey, I did not mandate a single tool or a single approach. Instead, I gave the team the freedom to experiment and to choose what worked best for their workflow. GitHub Copilot, Cursor, Claude Code, and other emerging agents were all on the table. Early reactions were cautious. Some feared the narrative that AI would replace developers. Others assumed it would create more friction than value. But with space to explore and permission to experiment, something important happened. Skepticism turned into curiosity, and curiosity turned into adoption. Today, AI is part of nearly every sprint. It is not a sidecar. It is part of the engine.
One truth became clear very early: AI is not going to take your job. But someone who uses AI might.
AI’s Real Strength: Raising the Floor of Engineering
There is a misconception that AI’s primary value is speed. Yes, it makes developers faster, but that is not the headline. The bigger story is this: AI raises the baseline quality of what an engineer can deliver.
In our experience, AI consistently helps developers:
- Handle edge cases they might not otherwise consider
- Produce richer unit tests
- Follow established architectural patterns with more consistency
- Navigate unfamiliar areas of the codebase without interrupting another engineer
- Reduce cognitive load while working across a large system
It is also important to be clear on one point. AI is a force multiplier, not a substitute for skill. It does not turn weak engineers into strong ones. Instead, it amplifies existing expertise. Senior engineers get dramatically better output from AI because they know how to evaluate results, guide solutions, and define quality. AI rewards craftsmanship. The more you know, the more AI can accelerate you.
AI reduces friction. It reduces rework. It reduces the mental tax of complexity. This has an outsized impact on the final product.
No, AI Code Is Not “Too Risky” for Production
The most common critique I still hear is: “I would not put AI-generated code in production.” My response is straightforward: Why is AI-written code any different from human-written code if it goes through the same engineering pipeline?
We do not allow human developers to bypass:
- PR reviews
- Quality checks
- Automated tests
- CI/CD gates
- QA validation
So why assume AI must be held to a different standard? Bad code should never be deployed, whether written by a junior engineer, a senior engineer, or an LLM. The SDLC is the great equalizer. If your development process cannot catch flaws from AI-assisted code, then the problem is not AI. The problem is your SDLC.
Prompting, Scoping, and Reality
Can AI write an entire application from a single prompt? Yes, it can. Will the result be good? No, it will not. However, when scoped effectively, AI is exceptional:
- For functions, AI writes them faster and often cleaner than humans
- For complete features, AI can perform extremely well with the right prompting and guardrails
- For large refactors, AI is outstanding, especially in well-patterned codebases
Many skeptics fail because they try one vague prompt, get mediocre output, and conclude that AI cannot do real work. Prompting has become the new version of Google-Fu. If you cannot articulate a problem clearly, your results will be mediocre. AI can only implement the clarity you provide.
Beyond Code Generation: AI Across the SDLC
Our team has gone well past the idea of AI as autocomplete. Today, AI participates across the development lifecycle. For example:
- We use Cursor rules and project context to enforce architectural patterns
- MCP and CLI automation to manage Jira, run tests, and validate UX
- Figma integrations to assist with front-end work
- Playwright with AI to perform automated UX testing
- PR review assistance that catches bugs and logic flaws
- Product teams that use AI to write clearer epics, user stories, and quick POCs
We have even run experiments where an AI agent was prompted to grab the next Jira ticket and resolve it. And it succeeded. This is no longer about assistive code suggestions. This is a transformation of the entire ecosystem of software delivery.
The Productivity Trap
Have we seen story cycle times cut in half? Not yet. That is also the wrong metric. We have seen meaningful gains in areas that matter more:
- Increased test coverage
- More robust handling of edge cases
- Fewer interruptions and less context-switching
- Faster onboarding for new engineers
- Fewer late discoveries of missing logic
- Better PR conversations focused on design rather than syntax
So yes, AI makes teams more productive. But its most meaningful impact is quality and completeness, not raw speed. AI raises the floor while also helping teams reach higher.
The Risk of Waiting
Coding agents are improving at a pace that is difficult to overstate. The gap between teams that embrace AI and teams that do not will grow quickly. Waiting for perfection is a losing strategy. Refusing to adopt AI now is like asking your team to work in a plain text editor with no autocomplete or IntelliSense, while competitors use a modern IDE.
Final Thought
After 18 months, I am convinced of this: AI-assisted development is not a fad, a shortcut, or a party trick. It is the future of professional software engineering. The craft is evolving, and the role of the engineer is evolving with it. Teams that embrace AI will build better software, deliver more value, and innovate faster.
AI is not replacing developers. It is amplifying them.
