The Old Rules Still Apply: Why Software Engineering Discipline Matters More in AI Engineering

I have been building software for more than 20 years. Most of that time I was at Kitware, working in open-source medical imaging alongside communities like the Insight Toolkit (ITK) and 3D Slicer, and on a long list of medical software projects. I picked up engineering habits there that I still use.

Today I work as an AI engineer, and lately I keep hearing that AI is now so good at implementation that the old software engineering principles no longer apply. Why write tests, specs or design documents when a model can generate a working feature in minutes?

I disagree. When implementation becomes cheap, the parts that were never about typing code become the whole job. Knowing what to build, and knowing whether what you built actually works, matter more now than they ever did.

In this post I walk through the practices I believe separate a strong AI-native engineer from someone who is vibe coding: evals and guardrails, specifications and intent, and the deep domain relationships that make both possible. It builds on themes from my earlier posts, Not everything needs an agent and Agentic AI is coming to the SaMD lifecycle.

Evals are the new tests

In the projects I grew up in, testing was not optional. Code was built and tested every night across many operating systems and compilers, and the results went to a shared quality dashboard that anyone could see (3D Slicer's CDash dashboard still works this way). A red dashboard was everyone's problem.

That mindset has a name: test-driven development, popularized by Kent Beck. Define what correct looks like first, then write the code that gets you there.

In AI engineering, the same idea is called evals. Anthropic's own guidance opens with it: "Building a successful LLM-based application starts with clearly defining your success criteria and then designing evaluations to measure performance against them" (Anthropic docs). Hamel Husain says it directly: unsuccessful AI products "almost always share a common root cause: a failure to create robust evaluation systems" (Your AI Product Needs Evals). Start with the evals is what I hear from almost every team that ships.

An eval set does for an AI system what a test suite does for traditional code:

• It turns a vague goal ("the assistant should give good answers") into concrete, checkable cases.

• It tells you whether a prompt change, a model upgrade or a new retrieval step made things better or worse.

• It lets you move fast without breaking what already works.

The difference is that AI systems are probabilistic. The same input can produce different outputs, and "correct" is often a judgment, not an exact match. That makes evals harder to build than unit tests. You still need them.

Guardrails are closely related. In medical software we designed for patient safety from the start, and we never trusted a component just because it usually worked. Guardrails are those checks for AI: input validation, output filters, policy checks, human-in-the-loop gates and fallbacks when the model is uncertain. I wrote about what that looks like for regulated medical software in Agentic AI is coming to the SaMD lifecycle. Guardrails are part of the system's design, not something bolted on after a bad demo.

When an AI can write the implementation for you, the eval set becomes the most valuable code you write.

Specs and intent are back

Specs are coming back too. People now talk about spec-driven development (SDD) and intent-driven development (IDD) as if they were new ideas. When GitHub released its open-source Spec Kit, it described the shift this way: "We're moving from 'code is the source of truth' to 'intent is the source of truth'" (GitHub blog, Sept 2025).

In medical software, specs never went away. At Kitware we built IEC 62304-compliant development processes to support FDA 510(k) submissions, where documented requirements and traceability are required. What has changed is the reader. A spec used to be written mostly for other engineers. Now it is also written for an AI agent that will do much of the implementation. An agent is fast and tireless, but it only builds what you describe. A vague spec gives you vague software, just faster.

A good spec or intent document answers the questions an implementation cannot answer for itself:

• Who is this for, and what problem does it solve for them?

• What does success look like, and how will we measure it?

• What must never happen?

• What are the constraints: regulatory, clinical, performance, cost?

Those questions line up closely with evals and guardrails. The spec says what we intend; the evals check that we got it; the guardrails protect against what must never happen. They are three views of the same understanding.

You can't write intent without knowing the domain

A model can't do this part. To write a good spec, you have to understand the domain deeply, and that understanding comes from relationships with the people who live in it.

In medical imaging, those people were clinical researchers: clinician scientists who knew the clinical problems and the image data, working next to engineers who could turn algorithms into usable tools. Some of the most important engineering work came from talking with them, learning how they actually worked and what they actually needed.

The 3D Slicer community built this into its culture with Project Week, a recurring week-long hackathon where the goal is to make progress on real projects rather than report on them. Engineers, researchers and clinicians spend the week in the same room, and it’s easier to understand a problem when the person who has it is next to you.

Today we’d call that intent discovery. We were not guessing what clinicians wanted. We were learning it directly, refining it together, and testing it against their reality. That is exactly the input a modern spec or intent document needs, and exactly what an AI agent cannot invent on its own.

Project Week 44, Gran Canaria, January 2026. Photo: NA-MIC Project Week.

Why forward-deployed engineering took off

I don't think it's a coincidence that the forward-deployed engineer (FDE) delivery model has become so popular in AI. Andrew Ng describes an FDE as "an engineer who is embedded within a client organization to help customize solutions" (Andrew Ng, DeepLearning.AI, May 2026). Palantir popularized the role, and AI companies including OpenAI and Anthropic now hire for it to turn frontier models into production systems for enterprises (Semafor, July 2025).

An FDE sits with the people doing the work, watches where things break, and learns the intent and the spec firsthand instead of reading about it in a ticket. That is the Project Week model, applied to enterprise AI. Being embedded is how you find out what "good" means for this customer, which edge cases matter, and which failures are unacceptable. In other words, it is what you need to write good specs, real evals and real guardrails.

The embedded engineer learns from the customer's world, writes that understanding down as specs, evals and guardrails, lets AI agents implement against them, and feeds real use back into the loop.

This is the difference between building something useful and vibe coding. Vibe coding produces software that might solve a hypothetical problem. Embedded, domain-informed engineering produces software that solves a real problem for real people, and you can prove it, because your evals were written from what you learned in the room.

What a strong AI-native engineer actually does

If you want to get good at this, here's where I would start.

1. Start with evals. Before writing a prompt or wiring up an agent, write down the cases that define success and failure. Run them on every change.

2. Design guardrails up front. Decide what must never happen and build the checks that enforce it, just as you would for any safety-critical component.

3. Write the spec, even when the AI writes the code. Capture intent, constraints and success criteria clearly enough that an agent and a teammate would build the same thing.

4. Get close to the domain. Spend time with the people who will use what you build. Go to their meetings, sit in their workflows, run your own version of a project week.

5. Keep the feedback loop tight. Treat evals like a nightly dashboard: visible, shared, and taken seriously when they go red.

None of these are new. They are the same habits that made long-lived open-source projects like ITK and 3D Slicer trustworthy, adapted for systems where the implementation is increasingly written by a model.

The old rules still apply

AI writes code faster, but good software still needs the same things. Test-driven development lives on as evals and guardrails. Careful specification lives on as spec-driven and intent-driven development. And the relationships we built with clinical researchers at hackathons and project weeks live on in every embedded engineer learning a customer's real problem.

If anything, these practices matter more now. When implementation is cheap, the scarce skills are knowing what to build and proving that it works. That is what traditional software engineering was always about, and it is what keeps AI systems working after the demo.

The views, opinions, and technical perspectives expressed in this article are entirely my own and do not represent, reflect, or imply the positions, strategies, or endorsements of my employer or any organization I am affiliated with.

Sources

1. Andinet's Tech Blog: Not everything needs an agent and Agentic AI is coming to the SaMD lifecycle.

2. Insight Toolkit (ITK) and its CDash dashboard.

3. 3D Slicer and NA-MIC Project Week, including Project Week 44, Gran Canaria 2026.

4. Test-driven development, Wikipedia (Kent Beck, Test-Driven Development by Example).

5. Anthropic, Define success criteria and build evaluations.

6. Hamel Husain, Your AI Product Needs Evals.

7. Den Delimarsky, Spec-driven development with AI: get started with a new open source toolkit, GitHub Blog, Sept 2, 2025, and Spec Kit.

8. Andrew Ng, Forward Deployed Engineers and the Future of AI Engineering, DeepLearning.AI, May 29, 2026.

9. Reed Albergotti, How a generic-sounding tech job will transform AI, Semafor, July 11, 2025.