GPT-6 Astra + Codex: Driving Full-Stack R&D Across Disciplines Through Conversation

From "Hands-On Execution" to "Conversation-Driven Progress"

Bilibili creator "马上开机" ("Boot Up Now") shared his hands-on experience with GPT-6 Astra: the more he uses it, the more he feels that a lot of work can genuinely be pushed to completion through conversation alone. This isn't just about "having AI write some code" — it represents a fundamental shift in how R&D collaboration works.

What makes this creator's work particularly noteworthy is its sheer scope. He handles full-stack development for automation products — and "full-stack" here goes well beyond front-end and back-end web development. It includes embedded software, electronic hardware, and even mechanical design. A complete automation product demands that software enables user interaction, circuits connect the hardware, embedded programs control the system, and the mechanical structure actually fits together and moves as intended — all of these components must ultimately work in concert.

In the past, he had to constantly switch between different tools, documentation, and problem domains. Now, more and more execution work is handed off to agents: he describes the requirements through conversation, adds constraints as needed, and then reviews the results returned to him. His tool of choice is Codex, with a clear goal — completing all his work through dialogue.

What Does a "Useful Conversation" Actually Look Like?

The author is careful to dispel a common misconception: "completing work through chat" does not mean sending a message like "build me a product" and walking away. In real-world practice, a productive conversation always starts with specific requirements.

He breaks down the key elements clearly: What problem am I trying to solve? What files and constraints are already fixed? What does "done" actually look like? Only when these are clearly communicated can AI meaningfully advance a task within a specific set of tools and a real project.

This is also a good moment to clarify what an agent actually is — an AI assistant capable of invoking tools, executing tasks, and continuing to act based on the results it receives. The model provides understanding and reasoning; tools give it the ability to read files, edit code, and operate software; and project materials and rules define what the task actually requires. Only when all of these come together does a conversation truly enter the workflow.

Codex is OpenAI's code-specialized model and the underlying technology behind GitHub Copilot. In an agent workflow, Codex doesn't just generate code snippets — once granted file system access, it can read project files directly, execute terminal commands, run tests, and iteratively fix issues based on error messages. This transforms it from a "completion tool" into an autonomous executor capable of continuously advancing tasks within a real codebase. The "completing all work through conversation" described in this article is technically grounded in Codex's tool-calling and multi-step reasoning capabilities — not merely its ability to generate static code.

Which R&D Workflows Has Astra Already Penetrated?

According to the creator's own account, he has already brought Astra into multiple stages of automation product development, covering a surprisingly wide range:

• Hardware and circuits: Schematic drawing, design rule checking, and PCB component placement and routing
• Software development: From front-end and back-end to general programming tasks
• Company website: Building the official site with both SEO (Search Engine Optimization) and GEO (Generative Engine Optimization) built into the strategy

These experiments have given him a firsthand sense of agents entering the workflows of different disciplines. Tasks that once required hands-on work across multiple tools can increasingly be organized and executed through conversation.

He also honestly notes that these projects aren't yet suitable for public demonstration, so he's sharing impressions first and plans to follow up with appropriate case studies. This restraint actually makes the account more credible — it's the real-world record of a working engineer, not a polished marketing pitch.

SEO (Search Engine Optimization) improves a website's ranking in traditional search engine results pages — like Google or Baidu — by optimizing page structure, content, and backlinks. GEO (Generative Engine Optimization) is a newer concept that emerged alongside AI-powered search tools like ChatGPT and Perplexity. Rather than targeting traditional blue-link results, GEO focuses on making content more likely to be cited and recommended when AI systems generate answers. The two require different optimization strategies: SEO emphasizes keyword density, backlinks, and page authority, while GEO prioritizes content credibility, structural clarity, and phrasing that AI can easily extract and quote. Including both in a website build reflects the author's read on a broader shift — traffic is migrating from traditional search toward AI-mediated conversation.

What Changes Is the Collaboration Model — Not the Work Itself

The author describes this shift with clear eyes: in the past, a large portion of his energy went into personally executing every step. Now, many of those steps can be "handed off," and he spends more time clarifying goals, evaluating approaches, and reviewing results.

But he's explicit about one thing: wiring still has to be done, parts still have to be machined, and products still have to be validated. "Advancing work through conversation" refers to a change in how humans and tools collaborate — not a disappearance of everything involved in product development.

This is an important reminder for anyone looking to bring AI into complex R&D workflows: AI excels at execution and reasoning, but physical-world validation, assembly, and testing still require people and real hardware.

Will AI Replace People? The Focus of Learning Is Shifting

On the anxiety of being replaced, the author offers some substantive thinking. He acknowledges that some work currently done by humans will indeed be handed to AI — he's doing exactly that himself. But he doesn't conclude from this that "people no longer need to learn."

On the popular saying "it's not AI that will replace you, but people who use AI," he prefers to treat it as a reminder rather than a guarantee about the future. He emphasizes that work will change and roles may shift, and the thing we can actively do is learn to combine our own experience and knowledge with AI's execution capabilities.

On whether learning is still necessary, his answer is an unambiguous yes — but the focus of learning is changing:

• The "where's the button, how does this command work, how do I write this boilerplate code" skills that used to require study can increasingly be offloaded to AI
• But "what does the requirement actually need, what are the constraints, why is it designed this way, how do we validate the result" — these still need to live in your own head

He gives practical examples: without understanding circuits, it's hard to tell whether a connection is problematic; without understanding mechanical structures, a model might look elegant but you'd have no idea whether it can actually be assembled; without understanding how software runs, it's hard to judge whether a fix actually solved the problem.

EDA (Electronic Design Automation) refers to the professional software toolchain used in circuit design, covering schematic capture, PCB routing, simulation, and verification — common tools include Altium Designer, KiCad, and Cadence. SolidWorks is a widely used 3D CAD modeling application in mechanical engineering, used for designing parts, assemblies, and engineering drawings. The author notes that in the past he would teach the operational details of these tools step by step — but now AI can handle much of the concrete execution. This means learners no longer need to invest heavy time memorizing menu locations and command syntax. However, the need to understand underlying principles — electrical rules, structural strength, tolerance and fit — has not diminished, because these principles are exactly what's needed to judge whether AI output is actually usable.

"AI Is a Lever — You Need to Have Weight"

The author puts forward a compact but powerful idea: the ceiling of what a person can do with AI is set by the person, not the AI. More precisely, your knowledge and judgment shape what quality of output you can get from it.

AI can certainly know things you don't, or propose approaches you hadn't considered. But for any specific task, you need to gradually develop the ability to ask good questions, identify the critical constraints, and check its answers. A solution that looks complete doesn't mean it actually meets the requirements; software that runs doesn't mean it works under real-world conditions — and in product development, someone always has to be accountable for those judgments.

For cross-disciplinary engineers, the knowledge base needs to be broad enough to connect different components; and when it comes to critical problems, there needs to be a willingness to go deep. So he compares AI to a lever — and a lever requires you to have weight. That weight is your understanding of the problem, along with the capacity to keep learning, make judgment calls, and validate results.

He also offers a practical learning path: you don't need to become an expert in every domain before you can use AI effectively. Quite the opposite — you can learn as you go, asking it to explain things you don't understand, then verifying through reference materials and real-world results.

A New Direction: Learning Through Real Tasks

This period of hands-on practice has also led the creator to rethink his content direction. Rather than the previous approach of "walking through EDA, SolidWorks, and various dev tools step by step," he's decided to restructure around a new throughline: take a real production development task and demonstrate how to use Astra (or whatever suitable model comes next) to build it out, step by step.

This includes how to describe requirements, how to supply relevant materials, how to get the model to use tools, how to correct it when things go wrong, and ultimately how to judge whether the result is good enough. Software operations will be covered when needed, but the main thread runs through tasks and outcomes. Underlying principles will continue to be explained, because without understanding the principles, it's hard to turn what AI produces into something genuinely usable.

His closing thought is worth remembering for anyone working in the age of AI: models will update, tools will change, but the ability to understand problems, organize tasks, and validate results will always be relevant. Using AI to complete real tasks is also, in the process, a way to make yourself more capable.