GPT-6 Astra Is Impressive. But the Bigger Change Is How We Build Software.

Opinion · AI engineering practice · September 2026
By Ananth Godavari · CEO, Intellifusion Technologies

OpenAI’s GPT-6 Astra arrived with the kind of capabilities that inevitably generate headlines: long-context reasoning, sophisticated software engineering, computer use, asynchronous tools, mid-task steering, and the ability to work through increasingly complex objectives.

Those capabilities are impressive.

But from where I sit, the more interesting story isn’t GPT-6 Astra.

It’s what models like Astra tell us about where software engineering is going.

At Intellifusion, we have already changed how we build software around that transition. Our development practice is called DEOVD: Discover → Engineer → Orchestrate → Validate → Deliver.

DEOVD isn’t something we’re waiting for future AI models to make possible. It is how we are building software today.

What Astra does is make the direction behind that change considerably easier to see.

We Didn’t Need Another Coding Assistant

The first generation of developer AI was easy to understand.

You wrote code. AI helped you write it faster.

Autocomplete became code generation. Code generation became chat. Chat gained access to repositories. Then agents gained terminals, browsers, testing tools, documentation, and other systems.

The obvious response was to keep asking:

How much more productive can AI make a developer?

I think that’s increasingly the wrong question.

The question we encounter in actual development is:

How should engineering work itself be organized when AI can participate in more and more of the development lifecycle?

That question led us somewhere very different from simply adding an AI coding tool to a conventional SDLC.

How We Actually Build: DEOVD

Our working model is:

Discover → Engineer → Orchestrate → Validate → Deliver

These aren’t five fancy labels for requirements, development, QA, and deployment. The distinction is important.

Discover

Before generating code, we establish what we’re actually trying to accomplish.

That includes business requirements, the existing system, constraints, dependencies, available evidence, user expectations, and what success looks like.

AI can participate heavily here. It can analyze repositories, documentation, transcripts, requirements, existing implementations, data structures, and previous decisions.

But discovery is not “ask AI what we should build.”

The goal is to assemble enough reliable context that both the humans and AI working on the project understand the problem.

Engineer

Engineering is where architectural decisions are made.

What belongs in deterministic software? What belongs in a database? What belongs in an API? Where is AI actually useful? What should never be delegated to a probabilistic model? What are the security and performance boundaries? What needs human approval?

This distinction has become increasingly important.

Putting an LLM in the middle of everything doesn’t make an application intelligent.

Sometimes the correct answer is SQL. Sometimes it’s a stored procedure. Sometimes it’s a conventional service. Sometimes it’s a vector search. And sometimes the problem genuinely requires AI reasoning.

Good AI engineering is partly knowing the difference.

Orchestrate

This is where modern AI changes software development most visibly.

Once the architecture and constraints are understood, work can increasingly be distributed across humans, AI agents, deterministic tools, development environments, tests, APIs, browsers, databases, and other systems.

The AI doesn’t have to be “the application.” It can be the participant coordinating work between specialized systems.

This is why some of Astra’s capabilities caught my attention.

OpenAI’s support for asynchronous tool operations and mid-turn steering moves the model toward a way of working that looks much more like orchestration than traditional prompt-and-response AI.

An agent can begin a task, use tools, receive additional direction while working, incorporate results, and continue toward an objective.

That’s much closer to the development environment we have been building around.

Validate

This may be the most important part of the entire methodology.

AI makes producing software dramatically easier. It does not automatically make producing correct software easier.

As generation becomes cheaper, validation becomes more valuable.

Did the implementation satisfy the requirement? Did it introduce regressions? Did the AI make an assumption that wasn’t actually supported? Did it change something outside the intended scope? Does the output agree with the source data?

Can another agent independently challenge the implementation? Can deterministic tests verify the result? And, where the consequences justify it, has a human reviewed the decision?

We don’t treat AI output as correct because the model sounds confident.

AI-generated work is evidence to be validated, not truth to be accepted.

That principle becomes more important as models become more autonomous, not less.

Deliver

Only validated work becomes delivered work.

Delivery includes the normal engineering concerns—deployment, monitoring, documentation, rollback, operational readiness, and stakeholder acceptance—but AI also changes this phase.

The context generated during development can become part of persistent project knowledge.

Decisions can be preserved. Rules can be reused. Failures can improve future instructions. Validation results can inform subsequent work.

The project becomes better prepared for the next development episode instead of starting each AI interaction from zero.

That accumulated context is becoming an engineering asset.

This Is Why Astra Matters to Me

Seen through that lens, GPT-6 Astra becomes interesting for a different reason.

Not because OpenAI released another model with higher benchmark scores.

It matters because several of its capabilities align with changes we have already found necessary in practice.

Consider mid-task steering.

Anyone who actually builds software knows requirements don’t politely remain unchanged while development happens.

A stakeholder clarifies something. Testing reveals an unexpected dependency. A developer recognizes an architectural constraint. Production behaves differently from the development environment.

Being able to tell an agent:

“Continue, but do not modify the database schema.”

without discarding everything it has already accomplished is much closer to real engineering collaboration.

The same applies to asynchronous tools.

Real engineering work isn’t always:

Do A → wait → do B → wait → do C.

There may be a build running while another part of the repository is being examined. Documentation can be researched while a test suite executes. Independent work can proceed while a slower operation completes.

Models capable of participating in that environment are becoming more useful members of an engineering workflow.

The AI Teammate Needs a Workshop

This is where I think much of the discussion around coding agents misses the point.

People keep comparing the workers.

Which model writes better code? GPT? Claude? Gemini? Codex? Cursor with one model versus Cursor with another?

Those comparisons matter.

But imagine hiring the world’s best engineer and putting that person into a company with no documentation, no development standards, no architecture, no test strategy, no access boundaries, no institutional memory, and requirements scattered across email and meetings.

The engineer’s individual intelligence won’t solve the organizational problem.

AI agents have the same problem.

A great AI model inside a poor engineering environment is still working inside a poor engineering environment.

That is why our focus has increasingly moved toward the environment surrounding the agent.

We call that environment the Builder Lab.

The Builder Lab isn’t a particular model or IDE.

It is the combination of engineering practice, project context, reusable rules, tools, architecture, validation, human oversight, and AI participation that allows us to build software effectively with increasingly capable agents.

Models can change. The Lab remains.

Context Is Becoming Infrastructure

This has also changed how we think about project documentation.

Historically, documentation was something developers were supposed to write after doing the interesting work.

In an agentic environment, project knowledge becomes operational.

Architecture decisions matter because an agent needs them.

Coding rules matter because an agent can follow them.

Historical decisions matter because otherwise an agent may repeatedly reconsider problems the team has already solved.

Requirements matter because agents cannot reliably infer business intent from source code alone.

Test expectations matter because generation without validation is just accelerated uncertainty.

This isn’t merely prompt engineering. It’s building persistent engineering context.

And I believe that will become one of the most valuable assets in AI-assisted software development.

We Are Also Learning Where NOT to Use AI

This may sound strange coming from a company investing heavily in AI development.

But one of the most important lessons has been learning when not to use AI.

If a deterministic SQL query answers the question perfectly, use SQL.

If a business rule can be expressed reliably in code, write the rule.

If a calculation must always produce exactly the same result, don’t introduce probabilistic reasoning merely because an LLM is available.

AI becomes valuable where we need interpretation, synthesis, ambiguity resolution, cross-source reasoning, natural-language interaction, or orchestration across systems.

The architecture shouldn’t become:

Everything → AI → Everything

It should look more like:

Human + AI + Deterministic Systems + Specialized Tools + Validation

Each component does the work it is best suited to perform.

That principle applies to the applications we build and increasingly to the process we use to build them.

The Developer Isn’t Leaving

There is an understandable fear that increasingly autonomous coding agents mean developers eventually disappear.

Our experience points toward a more nuanced change.

Developers spend less time producing syntax.

But someone still has to understand the business. Someone has to recognize bad requirements. Someone has to design architecture. Someone has to decide what the AI should be allowed to change.

Someone has to recognize when an implementation is technically elegant but operationally ridiculous. Someone has to determine what constitutes sufficient evidence that the work is correct.

And someone ultimately has to be accountable for what gets delivered.

The developer’s role is moving upward—from primarily producing code toward engineering and directing systems that produce software.

That’s a significant change.

But it isn’t the disappearance of engineering. It may require considerably more engineering discipline.

Better Models Actually Make Process More Important

This sounds counterintuitive.

If Astra and the models that follow it become dramatically more capable, shouldn’t we need less methodology?

I think the opposite happens.

A weak agent that can generate a function has a limited blast radius.

A powerful agent that can inspect a repository, modify code, operate a browser, execute commands, interact with systems, and independently pursue a multistep objective has a much larger one.

The more capable our AI teammates become, the more mature the engineering environment around them needs to become.

Astra Won’t Be the Last One

GPT-6 Astra will eventually be surpassed.

Maybe by another OpenAI model. Maybe by Anthropic. Maybe by Google. Maybe by something open source. Probably by several of them.

That’s why I’m less interested in designing our engineering practice around a particular model.

The durable question is:

Can our development environment take advantage of increasingly capable AI without becoming dependent on whichever model happens to lead today’s benchmark?

That’s what we’re trying to solve with Builder Lab and DEOVD.

The model is a participant. The methodology defines how the work gets done.

The Real Transition

The first phase of AI-assisted software development was about helping developers write code faster.

We’re moving beyond that.

AI can increasingly discover information, reason across large systems, operate tools, implement changes, test results, receive corrections while working, and participate across much more of the development lifecycle.

That creates something qualitatively different from autocomplete.

We’re moving from:

AI as coding assistant → AI as coding agent → AI as engineering teammate

GPT-6 Astra is another indication that the underlying technology is moving rapidly in that direction.

At Intellifusion, our response isn’t to wait and see what these models eventually become.

We’ve already changed how we build.

Discover. Engineer. Orchestrate. Validate. Deliver.

The models will keep changing.

The engineering practice is what makes them useful.

Ananth Godavari is CEO of Intellifusion Technologies. He has decades of experience in software engineering and technology leadership. His current work focuses on agentic software engineering, enterprise AI systems, and the development of the Builder Lab Method, including the DEOVD — Discover, Engineer, Orchestrate, Validate, Deliver — development practice.