Every engineer at Indexnine now works with AI agents.
We asked ourselves the obvious question, the one every engineering team faces today: If agents write the code, what do engineers stand for?
As we tried to answer that, our first conclusion was that engineers now matter more, not less.
You’ve seen the headlines about AI replacing junior developers, of course—but those headlines can’t lead to the conclusion that engineers have no purpose. That would be to confuse coding with engineering. When code generation becomes cheap, the human decisions around the code become more valuable.
We learnt this when we tried spec-driven development (SDD) on brownfield systems— and watched it break down. In a brownfield system, much of the real behaviour resides in existing code, undocumented edge cases, and past decisions—none of which a specification can fully capture.
Specifications and context are necessary inputs, of course. But as we found, treating them as substitutes for engineering judgement doesn’t work.
Using agents as specification executors works for greenfield demos and simple scopes, but it doesn’t hold up as systems age. When code is generated as fast as it is today, the codebase drifts into a fragile state. It becomes increasingly difficult to change safely.
Engineers prevent that decay.
They do more than that, of course. We wrote down our complete answer—five convictions—to what an engineer today stands for.
I call it a creed, and I mean the word literally. It’s a set of beliefs you don’t keep renegotiating. I’m saying “This is what it means to be an AI-native engineer at Indexnine.”
One: System Design
When agents build components, we make the decisions.
Engineers have always had to make architectural decisions. But when agents build the components, it becomes our primary job. We need to decide: What should exist? What are the trade-offs? Where are the system boundaries?
An agent builds what you ask it to, instantly and without objection. That kind of blind obedience is a problem. Ask the agent to write a parser for sensitive data and it will just do it. This saves time, of course, but the hard part is to ask: Should that data live in your system at all? What would it cost you if there were a breach?
Engineering was always about making decisions—but it’s even more so now that AI writes the code.
Two: Taste
Agents generate code. We enforce code quality.
Is it elegant? Is it maintainable? Is it efficient?
There are a hundred ways to write a single feature. AI, unfortunately, often chooses a poor one. It over-engineers solutions, or produces tangled code that can’t be understood later—which means it’s hard to maintain it, which in turn means it’s a liability.
Taste and judgement are now essential because AI output looks clean and passes tests, but one engineer with an agent can now write code faster than anyone can read it. There’s a growing gap between how much code your system holds and how much of it anyone understands. This technical debt compounds until a small change breaks the system in ways nobody can explain.
AI agents never ask whether their work is good. Our engineers ask the question for everything they generate.
Three: Context Management
Agents hallucinate. We build guardrails by providing specifications, context, constraints, examples, and architectural decisions.
The quality of the agents’ output depends on the context we provide.
The old rule—garbage in, garbage out—plays out much faster now. In the past, a vague specification could ruin a sprint. Today, it can mean a thousand lines of flawed code generated in the space of a minute.
People think assembling the context, constraints, and examples is administrative overhead. It might have been, but now, it is real work.
Four: Verification
AI shifted the bottleneck from generation to validation. We judge AI output with precision.
Is it correct? Is it secure? Is it effective?
Writing code is cheap today, but proving it works is not. Our job is to deploy software we know functions correctly.
A test can tell you the code runs; it cannot tell you the code solves the business problem, and no one can write a test for a failure they can’t imagine. A machine cannot be held accountable for a business outcome. Only an engineer can.
Five: Domain Expertise
When code becomes a commodity, we must master what matters: industry knowledge, business understanding, and product judgement.
No AI model has listened to an angry customer on a support call. They don’t know why a certain compliance rule exists, or what edge cases have bankrupted competitors. Value comes from knowing and understanding the specifics of your market, your users, and your constraints.
I’d say domain expertise is our most durable skill. The technical aspects of engineering keep changing, but the value of understanding the domain can only increase.
The Best Time to Be an Engineer
If you work the way this creed describes, this is the best time to be a software engineer. The skills that are now scarce—judgement, taste, verification, and domain knowledge—are, not coincidentally, the skills that good engineers have always been proud of.
The 2025 DORA Report backs up our conviction about the importance of the software engineer. Noting that developer AI adoption reached 90% in 2025, its key insight is that AI is “the great amplifier”: Adoption correlates positively with delivery throughput. But it also correlates negatively with delivery stability.
It is engineers who provide stability, which makes them more valuable than ever.
Why Write This Down?
We wrote this down to anchor our focus. If we just add AI to our workflows without redefining the engineer’s role, we’ll build the wrong things really fast—and fill our codebases with unmaintainable junk.
None of this is aspirational. It is how our people work. We wrote it down so we could be held to it, and so the leaders we build alongside know precisely what they are getting.
Indexnine isn’t a shop that happens to use AI well. We know what engineering becomes when the code writes itself.