Software Engineer (Agentic Development)

You’d join a small in-house engineering team working on an established production codebase, reporting to a hands-on CTO who writes and reviews code - not a manager who used to.

For a mid-level engineer, that combination is hard to find: real ownership of systems in daily use, plus direct access to someone who knows them thoroughly.

What you’ll do

• Take business-level goals - sometimes quite big-picture - and drive them to working, shipped software
• Decompose broad requirements into work an agent can actually execute well
• Direct agentic tooling through implementation, iterating as you learn what the requirement really was
• Design and run the verification loop. Most of the checking is done by agents - iterative passes that review the code, write documentation from it, and cross-check each other. Your job is building that loop, deciding what it has to catch, and judging whether its output can be trusted.
• Review the approach, scan the diff. The cheapest place to catch a problem is in the proposed solution, before it’s built - that’s where we want your attention. You’ll still look over what comes out, scanning for anything that seems off, but not auditing it line by line.
• Read closely where mistakes are permanent - schema changes, migrations, anything touching how data is stored. Everywhere else, don’t slow down to read it all.
• Test heavily. Agents make tests cheap, so there’s rarely a reason not to have them. The judgment isn’t whether to test - it’s whether the tests assert the right behavior. A large green suite that mirrors the implementation instead of the requirement is worse than no tests, because it locks in a bug and looks like proof.
• Refine requirements collaboratively as they take shape. Requirements here are a starting point, not a specification - we expect to learn during implementation and change direction.
• Diagnose and fix production issues
• Take part in code review in both directions - reviewing others’ work as well as having yours reviewed
• Document what you learn as you learn it

Engineering judgment, earned the hard way. You need to have written and debugged a lot of code in your career - that’s how you learn to recognize a bad architectural direction the moment you see one proposed, and to know which mistakes are cheap to fix and which are permanent. We’re not asking you to use that experience to type, and we’re not asking you to read everything. We’re asking you to catch the wrong approach before it gets built., * Deep understanding of the system, without reading all of it. Your main intervention point is the proposed solution, not the finished diff. You need to know how things work well enough to spot when an approach cuts against the grain - and to say so before it’s implemented.

• Real production experience with React, Node and TypeScript - enough to evaluate a proposed approach quickly and judge whether it fits
• Real care with data. Schema design, migrations and SQL are the one place we do want you reading closely and slowly. Everywhere else you can move fast; here, mistakes are expensive or impossible to undo.
• Demonstrated experience driving agentic tooling on real work - not experiments
• Well-calibrated skepticism. You’ve been burned by confidently wrong output and it changed how you work - including a healthy wariness about agents that mark their own homework.

Implementation-level defects - race conditions, unhandled errors, missed edge cases - are the loop’s job to catch, not yours to find by reading. Your experience of those bugs is what tells you to make sure the loop is looking for them.

• Comfort with ambiguity and iteration. Requirements will arrive incomplete and change as we learn.
• Clear writing. Specification is the primary skill here.
• Willingness to ask why. We want design decisions questioned - politely, with reasoning, but out loud.
• Comfortable on a small team, and comfortable being mentored

Nice to have

• Healthcare software, or another regulated domain
• Experience as an early engineer somewhere
• Product instincts - you’ll help decide what “done” means, not just build to a spec
• Experience maintaining and extending existing systems, not just greenfield
• Some infrastructure and deployment capability

No computer science degree required. No audiology experience required.

Pulled from the full job description

• Health insurance
• Paid time off
• Vision insurance
• Dental insurance, Arrow Audiology - Springfield, MO Full-time · On-site $85,000 - $105,000 a year, Health, dental, vision, & PTO

Arrow Audiology is an equal opportunity employer. We consider all qualified applicants without regard to race, color, religion, sex, sexual orientation, gender identity, national origin, age, disability, veteran status, or any other protected characteristic.

Pay: $85,000.00 - $105,000.00 per year

Benefits:

• Dental insurance
• Health insurance
• Paid time off
• Vision insurance

Arrow Audiology operates retail audiology clinics and provides audiology services to ENT practices. We build and run our own clinical and business operations software - the systems our clinicians and front-office staff use every day to see patients and run the business.

That software isn’t a side project. It’s how the company works, and it’s built in-house.

Read this part first

We develop AI-first. You would not be writing code by hand.

Agents write the code here. Your job is judgment:

• Knowing what to ask for, and how precisely to ask for it
• Knowing what to look for in what comes back
• Knowing when the output is plausible and wrong
• Knowing when to iterate and when to throw it away and restart

If you love the craft of writing code by hand and that’s what you want to spend your day doing, this will frustrate you and you should skip it. If you’ve been working this way already and want to do it somewhere fully committed to it, keep reading., Small team, on-site in Springfield. Your work will be reviewed closely while you’re ramping, which some people find supportive, and some find claustrophobic.

The codebase has consistent patterns and very little accumulated archaeology - once you understand how it thinks, a lot of it becomes predictable. There’s also documentation we’d like you to help improve.

The work is used by clinicians with patients in the room. Reliability matters more than elegance here.

And to say it once more, because it’s the thing most likely to be a mismatch: you would not be writing code by hand. If that’s a loss rather than a relief, this isn’t your job.