Hi everyone and a very warm welcome to this course on Codex.
Really excited to have you here today and hope to learn a lot of things together.
We will learn how to use Codex for enterprise development.
We will see how it works as a coding assistant and its many functions in different situations.
Codex is a tool made by OpenAI.
You might know their famous tool called ChatGPT.
OpenAI is the main company behind ChatGPT and they handle all the AI generation and work.
First, I will show you the OpenAI website.
On their website, they say their research will lead to artificial general intelligence,
which is a system that can solve human problems.
In the products section, you can see tools like ChatGPT, Codex, Atlas and Prism.
ChatGPT is a very large tool that includes images, deep research and GPTs, codecs, multiple applications and libraries.
If we talk about apps, we have multiple apps connection.
You can connect it with popular apps like Adobe, Airtable, Booking.com, Canva, Spotify and more.
Now let us look at OpenAI Codex.
Codex is an AI software engineering agent.
It helps developers write, understand, change, test and ship code easily.
It is not just a simple chatbot that only answers questions.
It works directly with your project files and helps with the whole repository structure
and can make the changes, run commands and assists with development cycles.
It gives developers real engineering results.
Codex is also inside ChatGPT, so you can use it directly.
There is a specific app for Codex, and you can download it for Windows.
We will see how Codex makes real engineering work faster, from planning and building the features, to fixing and releases and cross-checking.
There is also a command line interface, or CLI, on GitHub for Codex.
CLI means Command Line Interface. It is a text-based interface used to talk to software and computers.
Instead of clicking buttons with a mouse on visual icons, you type text commands and the
text-based user interface used to interact with the software, operating system and on
your keyboard instead of using a mouse to click on visual items and press enter to make
them work.
We will learn how to use this CLI.
Codex helps what a developer wants to do and turns it into engineering output.
You can describe a bug or a new feature, test environment, documentation, task, in natural
language.
Codex can analyse the database identifying files, proposed changes and generate limitation
steps.
This makes it useful not only for the writer but also for navigating unfamiliar systemd.
Here we have codex discussion.
In this course we will talk about daily development, prompting, making agents and using codex to
for a long time. We will cover all of these important topics together.
So, moving on, the next critical discussion is primarily related to exactly
how we are going to securely install codecs on our machine. First, well before
actually installing it anywhere else, we will practically use the standard
command-line interface to get things started. But right before that specific
step, we can smoothly download the dedicated version specifically meant for Windows operating
systems. Now, I already have the necessary Codex installer fully ready to go here. I
simply open up the main system downloads folder right now. Then, I firmly run the executable
installer directly as a system administrator. The core software immediately starts to install
itself smoothly. Simultaneously, the Microsoft Store seamlessly begins its essential download
process. Finally, when the entire download completely finishes, Codex will successfully
run. Interestingly, we can certainly also manage to install it safely across multiple
different computer systems. As we smoothly scroll further down the main page, you will
clearly see three distinct setup options presented. The very first one is the
standard standalone app. If we really want to use a code editor we can install it
directly within our preferred IDE. Fortunately we already have Visual Studio
code fully set up. Right inside VS Code a highly helpful AI is fully available. It
is completely automated and we can easily use various models right here. To
To successfully add this to our daily workflow, we simply need to install it in VS Code.
We securely click Allow in VS Code and Codex will seamlessly open.
Essentially, it is OpenAI's powerful coding agent that constantly works with you.
It is fully included in ChatGPT+, Pro, Business, Education and Enterprise plans.
First and foremost we absolutely must carefully check our specific ChatGPT subscription plan.
I will officially open up the ChatGPT interface right now.
As you can clearly see, we currently have the Plus version fully activated.
Looking closely in the dedicated upgrade plan section, you clearly see our active billing
plan.
It is indeed the standard Plus plan.
This essentially means all our ongoing coding work is completely safe and secure.
Codex is fully available to use today.
The strictly required language model is situated right here.
Moving back into VS Code, we will effectively start the complete software installation.
It securely installs just like a standard web extension.
First, we smoothly pair it directly with Codex.
We basically add Codex as a dedicated side panel within VS Code to seamlessly chat, intuitively
edit and carefully check all our changes.
Then, we can confidently use Codex directly in the cloud, sending massive jobs straight
to it.
Moving gracefully to the very next step, we simply need to safely sign in using our primary
ChatGPT account credentials.
Once fully authenticated, our main application will automatically install directly into the
workspace.
Now, the third available setup option is to actually install this directly inside our
system terminal.
For this specific method, just look closely at the Keep going in the terminal prompt section.
We carefully copy this exact command string to our clipboard.
Following that, we explicitly open up the system command prompt, making sure to run it strictly as an administrator.
The Windows PowerShell interface naturally opens up.
Within PowerShell itself, we formally install the OpenAI Codex tool utilizing the NPM Package Manager.
Naturally, it will definitely take a little bit of time to fully install properly.
The underlying system will sequentially gather necessary data in a much better way.
Codex is actively installing and we have our app ready.
Now we go to settings.
We purposefully open the main application settings directly from the main dashboard.
settings menu there are actually many different customisable options
available. I specifically navigate over to the appearance tab in order to make
some visual interface changes. First, I completely change the overall display
theme to a comfortable dark mode. Next, I noticeably increase the base system UI
size for better visibility. We then carefully choose our preferred font
style and slightly adjust the visual contrast. Initially, I confidently write
in 32 for the primary font size, however upon seeing it, 32 is admittedly just a bit too
big for my screen. So I quickly change it down to exactly 24. Honestly, 24 is a genuinely
comfortable size for long coding sessions. For the dedicated code font, we firmly use
size 20. Moving on, we strategically turn off the reduce motion option. We ensure we
use standard pointer cursors and gently lower the screen contrast. Everything is working
well. Honestly, the overall reading experience is just so much better right now. Before we
made those crucial visual tweaks, the default text font was incredibly small and honestly
hard to read. We absolutely had to step in and make the font significantly bigger for
basic clarity. I truly believe that 24 and 20 are excellent, highly optimized sizes for
our daily coding tasks.
Now if we quickly navigate over to the General Configuration Settings menu, we can clearly
see multiple distinct operational modes available to choose from. I promise that I will carefully
explain all of these specific working modes in much greater detail a little bit later on.
Right now, all our required system packages are successfully installed.
The powerful OpenAI codex itself is completely installed.
Now, we just essentially need to forcefully run it one more time.
I smoothly tab back over to the chat GPT window.
I explicitly type out and clearly ask.
I have basically run this command in the terminal.
What do I do next to start it?
We will now officially start the require process right here within our local system terminal.
The entire background installation procedure is completely finished.
It successfully managed to add two vital software packages in just about 36 seconds total.
The software carefully checks the current NPM installation status alongside the available AI models.
First and foremost, we must verify the active codex version.
I simply type NPM codex directly into the prompt.
The resulting codex CLI version currently shows up as 0.139.0.
Next, we actively run codex so we can finally start to code.
to code. We type codex right into the system environment. A brand new security message
suddenly appears on the screen. It clearly asks, do you currently trust the exact contents
of this specific directory? Working directly with untrusted contents definitely carries
inherent security risks or potential prompt injections. Trusting that directory directly
allows for reading local configuration settings.
I confidently click yes and smoothly continue.
After successfully getting that required yes confirmation,
we now finally have our direct working option ready to go.
We have the full power of the OpenAI codex at our fingertips.
Our specifically selected AI model is currently GPT 5.5.
Our active working directory is listed safely as System32.
We can comfortably make direct code changes right here in this space.
If I quickly send over a very simple introductory message,
it impressively replies back almost automatically.
I simply write out,
can you explicitly help me in generating some basic HTML code?
It quickly gives a remarkably short, concise response.
It plainly says, yes, absolutely.
Just tell me exactly what you want the final HTML page to do, or what you want it to look like.
Paste any existing code snippets you might already have.
If you happen to start entirely from scratch, I can easily create a simple HTML framework for you.
Our coding journey begins.
I press Ctrl C to pause.
It shows the response.
The interface clearly displays our complete token usage statistics right on the screen.
The grand total comes out to exactly 7,939 tokens used.
The initial input strictly accounted for 7,881 tokens.
Meanwhile, the generated output was a remarkably short 58 tokens.
To seamlessly continue this exact same chat session, we carefully copy the provided resume
command.
I smoothly paste that specific command right back in here.
Instantly, the previous conversation thread beautifully continues right where we left
off.
If I suddenly decide that I want to completely change the underlying AI model, we currently
have three distinct options available.
Next is GPT 5.5, which is essentially the frontier model specifically built for complex
coding tasks.
Next is GPT 5.4, the strongest overall model strictly meant for everyday standard coding.
Finally, we have the incredibly lightweight GPT 5.4 mini.
We also have very handy slash commands completely ready to use.
we will clearly show exactly how to effectively use them moving forward.
Let's use slash commands.
When I proactively type out a forward slash, Codex immediately shows a complete, highly
detailed working menu of commands.
First and foremost, we can fully configure how Codex strictly operates.
We have the primary model selection option available.
We also have the specific fast option explicitly listed.
We have the IDE integration, to easily include currently open files and broader context.
We actively have detail permissions to precisely choose exactly what codecs can or cannot do
safely.
We have dedicated key maps specifically designed for setting custom keyboard shortcuts.
We have Vim mode strictly intended for our main code composer.
We logically have the Sandbox Add to Directory feature ready.
Finally, we have the Experimental Feature section.
I intentionally select the very first configuration option to explore the available models.
I ultimately choose the GPT 5.4 Mini variant.
Now we selectively choose the preferred reasoning level.
We specifically select low reasoning instead of the standard medium.
We can carefully view current IDE sessions and files.
Next, we review permissions.
There are several highly specific model permissions carefully listed here.
The Read Only setting strictly means that Codex can only safely read active files located
within the current workspace environment.
It absolutely requires your direct manual approval before it can ever attempt to edit
files or directly access the live internet.
The Ask for Approval setting actually serves as the standard default mode, where Codex
can seamlessly run, read or even edit files inside the current workspace and fully read
the active command prompt. Still, explicit manual approval is completely required to
permanently edit files or access the internet. Approved for me intelligently only asks for
explicit permission when it encounters potentially unsafe system actions. Full access simply
means Codex can freely edit files far outside the designated workspace and easily access
the internet without ever asking for prior approval. Exercise extreme caution and ask
vital questions when using this. I explicitly choose the Approve for me setting. Our updated
permissions are cleanly applied. I press Enter and transition to the Keymap configuration.
In Keymap we have our transcript, external editor, clear terminal and more options.
We practically have multiple distinct configuration options readily available right here, alongside
some incredibly useful direct operational options.
What we can actually do here is utilise the basic left and right keyboard arrow keys to
smoothly navigate and group items.
We firmly use the Enter key whenever we strictly need to modify or edit an existing shortcut.
We smartly use the star symbol strictly for creating completely custom shortcuts, the
dash symbol to quickly unbind an active key, and the Escape key to easily close out the
menu entirely.
I simply press Escape right now to smoothly go back to the previous screen.
Right after successfully configuring our system permissions, we logically have our custom key
maps fully sorted out.
Next up, we carefully review our active system approvals.
You can transparently see absolutely all the recent system changes we manually made right
here.
We actually changed our primary AI model twice today.
We closely reviewed the IDE context settings.
We officially updated our security permissions to Approve for me.
Finally, I press Control-C.
Executing that specific command officially closes out the active chat session entirely.
It is crucial to note that this specific underlying configuration genuinely remains the exact same
across every single linked application environment.
Thankfully, the powerful Codex tool is readily available right here too.
We can practically do so many different amazing things with it.
If we smartly decide to switch over to the exclusive pre-release software version, absolutely
all the newest experimental features become instantly available.
I am going to intentionally open up a brand new dedicated project folder officially named
Metabrains for our work.
We carefully select this exact folder directory and smoothly open up our fresh chat interface.
I explicitly confirm that I fully trust the verified authors operating in this specific
environment.
I smoothly close this secondary pop-up window.
I promptly open up a brand new code file appropriately named index.html.
You can distinctly see the familiar codex logo right inside this document.
We can now finally start to actively write out our core underlying code snippets.
The generated Codex AI response will seamlessly appear right here on the interface.
We will be able to clearly see our active IDE connection, the linked source repository,
the comprehensive onboarding bug log and of course, our preferred dark mode visual theme.
We will consistently get highly accurate direct responses moving forward.
Now we need to take a very close look at our overall system usage metrics.
I purposefully navigate back over to the main settings page.
The exact same user account is actively being used uniformly everywhere.
We can easily modify our deeper codec software settings right here.
You clearly see broad configurations, custom personalisation, advanced MCP servers, webhook
integrations, system usage and active billing.
We absolutely need to check these panels timely and consistently to perfectly know exactly
how we are efficiently carrying all these things forward.
We can chat and utilise commands.
We can switch models and connect apps.
Inside the primary settings menu, we prominently have the visual appearance and core system
configuration tabs right at the top.
We absolutely also have detail personalization settings, custom keyboard shortcuts, active
usage limits and standard billing information.
The general designated application usage limit strictly caps out at exactly 5 hours.
we happily have a massive 99% of that time left available.
The broader weekly limit currently shows 100% completely left over.
We have successfully expanded our overall codex usage capabilities
alongside the powerful GPT 5.5 deep thinking mode.
We can effortlessly purchase an additional credit balance whenever needed.
Supported system integrations proudly include
seamless browser connections,
broad computer use permissions and robust MCP servers.
The core coding section beautifully includes active webhooks, secure remote connections,
complete Git source control, safe isolated environments and managed work trees.
Our foundational setup phase is now entirely complete.
The highly anticipated direct usage strictly begins right now.
We will now efficiently set up highly secure cloud-based development environments right here in this specific module.
You probably remember that we previously ran our Codex agent directly here on the local machine.
Absolutely all of our core operational functions were safely contained directly inside it.
Now, however, we will purposefully run our advanced cloud-based development environment
securely integrated directly within our main codec setup.
First things first, I will quickly navigate back over to the main settings panel
and intentionally make the system font slightly smaller for better viewing.
We gracefully go over to the visual appearance tab
and actively change the primary tech size down from 24 to precisely 20.
Now, the overall tech size is just so much better and more manageable.
I will clearly explain to you generally what these advanced cloud-based development environments actually are.
We will deeply understand this entire concept right here today.
You absolutely should know right up front that this is essentially a pre-configured, entirely remotely hosted software workspace.
It actively contains your preferred IDE alongside all your necessary background tools.
Modern developers can effortlessly code, rigorously test and smoothly deploy complex software straight from the web browser.
The acronym CDE specifically stands for Cloud Development Environment.
It effectively solves that highly frustrating, age-old problem
when a specific piece of code miraculously only works on one specific person's local computer.
Brand new software engineers can easily start actively coding in mere minutes.
This is our dedicated cloud system.
Now, let's take a moment to talk about Codex itself.
Codex fundamentally has some massive, undeniably big advantages here.
Codex genuinely works absolute best when it can safely access the entire full code repository.
It impressively also has powerful built-in deployment tools.
A cloud environment safely lets Codex seamlessly talk directly to remote code repositories.
It can reliably run terminal commands, execute unit tests and thoroughly check projects.
It safely makes automated code changes.
The biggest overall benefit is undeniable, absolute consistency.
In significantly older traditional local development environments,
various developers constantly use completely different underlying operating systems
and vastly different local machine settings.
settings. This inherently creates the infamous, frustrating, well, it perfectly works on my
machine problem. Modern, streamlined cloud environments completely remove these highly
annoying problems entirely. Absolutely everything that we actively do right here, for example,
the previously pinned chat log specifically about making a functional calculator application,
all our deep technical discussions are safely stored permanently in this robust cloud system.
We can effortlessly and rapidly review our collective past work right here at any given time.
Other incredibly massive benefits strictly include nearly instant team onboarding,
highly consistent underlying tool setups, absolute hardware independence and reliable
long-term session persistence.
Now, moving forward, we will thoughtfully choose a specific cloud development platform to use.
I will happily show you some excellent real-world examples shortly.
First and foremost, we will take a very close look at GitHub Codespaces today.
It is a remarkably secure, highly robust cloud development environment used by many.
If we genuinely do not want to use this specific one, we can alternatively utilise Gitpod.
We actually use the Gitpod platform quite a lot in our daily workflows.
It is a fantastic, strictly on-demand, highly scalable development environment.
For massively big enterprise companies, we consistently have the AWS Cloud9 infrastructure safely available.
for our larger, more complex coding tasks.
It is basically a fully complete cloud-based integration development environment from Amazon.
It is truly a complete, fully featured IDE right in your browser.
We can effortlessly write, smoothly run and quickly fix our complex code directly inside it.
These are a few older, very solid examples.
Now, I will explicitly search the web to see if Codex itself is officially classified as a cloud-based development environment.
It confidently says, yes.
Codex, created by OpenAI, is officially a cloud-based AI software engineering agent.
It remarkably handles incredibly complex programming tasks, consistently fixes highly stubborn software bugs, and smoothly proposes absolutely all the necessary fundamental work changes for your review.
This essentially means that the powerful tool we are actively utilising right now acts almost exactly like a completely standalone, fully robust cloud-based development environment in itself.
I strongly suggest that we consistently use this incredible tool to intentionally make
a highly secure, deeply isolated remote workspace.
There are honestly quite a lot of highly technical back-end things actively running here.
I will quickly hop back and change the UI font size once again, because it simply does
not look visually right on this display.
I will purposefully make it just a little bit bigger, strictly for the sake of our video
course clarity. Now we simply go straight back into our main codex application. Everything
visually looks exceptionally good now. We have our advanced reasoning engine and other
vital backend things running. We will take a complete comprehensive look at this next.
This perfectly shows how we put things into a complete cloud-based setup.
Now, moving smoothly forward, our very next crucial task is to securely connect our remote
GitHub repositories directly.
We absolutely need to establish a solid link to our GitHub account directly within the
main codec system.
Inside our primary GitHub platform, a tremendous amount of distinct configurable options are
always readily available.
You can clearly see the active status regarding the connection with GitHub right here on the
interface.
If I cautiously go over to the main settings panel, specifically looking closely in the
Connections option area, there is currently absolutely no active connection established.
The standard SSH and secure Git credential options similarly show that there are simply
no active connections present.
Furthermore, down in the Remote Servers and Local Browser tab, there is similarly no connection.
In the Computer Use section, we can alternatively use the Google Chrome browser extension.
So, our primary GitHub repository profile is clearly not effectively connected to the system just yet.
I will intentionally just type out the specific query.
Is GitHub firmly connected to Codex right now?
to quickly see if we actually get a reassuring green verification tick.
This built-in diagnostic tool will thoroughly check the back-end systems
and explicitly tell us if our GitHub account is successfully connected or not.
Simultaneously, I will efficiently search for the precise phrasing
GitHub and official codex integration securely online.
This highly powerful system connection can miraculously be added directly without any significant friction.
It prominently includes highly advanced automated pull request code reviews,
a dedicated co-pilot AI coding agent and deeply integrated GitHub workflow actions.
We will comprehensively discuss absolutely all of these incredible back-end setup options in extreme detail.
The diagnostic system now clearly shows that the official GitHub integration plugin
is indeed fully available directly within the primary codex plugin section.
But, unfortunately, this specific local workspace folder
is actually not initialised as a valid Git repository right now.
A brand new Git tracking folder is quickly being created in the background.
Now, if we explicitly click the prominent plus button on the user interface,
we can clearly see the GitHub icon safely listed in the available plugins directory.
But we critically want to verify exactly which specific user account is currently connected directly to our active GitHub plugin extension.
We currently cannot seem to find our primary GitHub profile, so we will manually initiate a deep search for it.
When we effectively run the search, the official GitHub authentication app finally appears.
The application safely requests broad permission to actively access repositories, track software issues and manage pull requests.
But we have simply not fully connected it just yet.
So we will proceed to log securely into our main GitHub account.
This is our dedicated primary account explicitly named metabrains-del.
It undeniably has many repositories and we have done a lot of work here.
We will now meticulously connect this specific GitHub account directly to our active Codex
system workspace.
When I confidently click the connect button, it explicitly asks for final permission to
securely connect to GitHub servers.
It safely allows the underlying ChatGPT engine to carefully read our previous chats and stored
memories to consistently give significantly better, context-aware answers.
It clearly states that your deep personal privacy permissions are heavily respected,
and you are always completely in control.
It does warn that external connectors may possibly introduce some slight security risk.
I will boldly open up our Direct GitHub Developer Dashboard.
You can visually see that the secure GitHub app authorisation connection is actively starting
in the background.
Absolutely all our ongoing critical development work is safely housed right here.
We will press firmly to continue onward to GitHub so we can comfortably go straight to
our main profile account.
It will naturally take a little bit of processing time to fully connect.
A basic connection will form.
You can see it is connected.
I open plugins again.
Now you will actively see that our dedicated GitHub plugin is finally working precisely
as intended.
It smoothly works specifically because it is successfully connected to the backend.
If it is ever mysteriously not connected, we can easily check our credentials again to see if we can actively reconnect it.
We currently have our active user login, but unfortunately, adding the specific external link just failed.
Why exactly did it suddenly fail here?
We must remember that this is our specific ChatGPT Plus tier account.
You absolutely must remember this vital detail because it impacts our permissions.
Now we will purposefully open up the completely alternative ChatGPT account instead.
We will securely bring our dedicated Michael DuPont user account right here into the active workspace to try again.
Our premium ChatGPT plus subscription tier is fully available right here.
Now we will carefully attempt to securely connect the integration system once again.
It will systematically connect our main chat GPT interface to the repository.
If we ever eventually want to completely remove it for security reasons, we can easily uninstall it and quickly reinstall it from scratch later again.
We obviously also have the standard option to immediately disconnect the authorization any time.
We will gracefully proceed straight directly over to the main GitHub authorisation portal.
Now it will successfully build the required connection directly in our correct targeted application.
It strictly demands highly secure multi-factor user authentication.
We will comfortably utilise the standard Authenticator mobile app to handle this.
The mobile Authenticator app will swiftly finish processing our deep security verification.
Now you can clearly see that our primary GitHub profile is finally directly connected perfectly.
I will quickly pivot back over to our main codex interface.
You can clearly see that our secure software link is now fully established and solidly connected.
If we carefully look directly at our active system plugins list right now,
absolutely all our relevant GitHub integration tasks have delightfully started showing up directly in there.
We will smoothly navigate back over to our main chat terminal interface.
You can very clearly see our dedicated GitHub functionality is directly added and fully available right there.
We will quickly go back over to the plugins tab and our GitHub features will be permanently included in the active workflow loop.
It will effortlessly come directly into our daily software development work.
Ultimately, we have incredibly successfully added our robust Codex AI tool to perfectly
sync with our remote GitHub code repositories.
Moving logically to the very next crucial step, we will thoroughly talk about the highly
specific agents.md configuration file.
This incredibly important file is primarily used for organising massively big software
development projects. We specifically utilise it whenever we happen to have
many complex automated tasks or a full highly detailed business use case to
carefully look at. I will intentionally open it up right here on the screen so
you can clearly see exactly where these vital agent configuration files
naturally come from and exactly where to easily find them. It will reliably give
us the system response directly and accurately.
The dedicated agents.md file immensely helps us to deeply inspect and standardise our overall
project architecture.
You can clearly see it actively looking deep inside our raw project files.
Here, it explicitly states that the active workspace is entirely empty right now.
There is absolutely no agents.md file found.
It checked the temporary scratch space and verified there is no file.
To successfully create one from scratch, we absolutely must make a brand new, correctly
formatted Agents.md file.
I will manually go ahead and create a brand new foundational file right here for you.
This incredibly efficient way, we can consistently see absolutely all the necessary high level
production details firmly embedded safely within this specific file.
First, the core Structured Agents file is quickly drafted out.
Right after that initial phase, we can comfortably make far more highly nuanced text changes
to this preliminary draft.
In this specific advanced technical setup, we usually really need to carefully check
if our highly specific basic operational rules or distinct business use cases are actually
working properly.
successfully and directly created an excellent base foundational agent file
right here for us. If we carefully review the generated file we can clearly see
its intended core purpose. Besides the purpose there is a clear project
overview. We also see a working agreement, a layout and editing rules. We can
actively cross-check all of these fundamental operational rules precisely
here in the document. I will also make sure to explicitly tell you exactly where
this specialized configuration file is typically used. We consistently use the
specialized agents.md file to effectively establish strict working
boundaries and core rules for literally any AI agent operating in the workspace.
There are basically no other bizarre tasks or unrelated work explicitly meant
for it. Sometimes, unfortunately, we literally have to go deep down into our underlying operating
system just to manually set up the complex agents.md file perfectly. This tedious manual
process admittedly takes quite a lot of valuable development time. We essentially have to carefully
look at so many different distinct things, like our strict project requirements, core team work
ethics and several other highly detailed technical options. We absolutely need to fully know how to
properly handle these nuanced things. But for massively big projects, we only deliberately
include our basic setup requirements here. Moving right along, next we will deeply discuss exactly
how to effectively use this incredibly vital agents.md file in standard practice.
Deeply understanding this specific core concept is an undeniably very important foundational part of the entire development process
We absolutely need to fully know exactly how to actively create the underlying file directly from absolute scratch
Now we purposefully transition and move seamlessly right over to the very next important part
We will fundamentally learn exactly how to appropriately handle highly complex things and deeply understand them right after actively creating the foundational file.
This is fundamentally a highly special, deeply vital system instruction file.
It consistently provides invaluable deep guidance and much needed environmental context directly for our automated work.
It can absolutely also be used incredibly effectively, exactly like a traditional readme developer file.
You might vividly remember that standard software developers constantly use structured readme files.
In the exact same way, we can use this file.
I have created a basic agents.md file, but incredibly, we can undoubtedly also meticulously make a highly reusable foundational agents.md configuration template right here in the workspace.
We can comfortably and securely include absolutely all of our strict foundational base development requirements firmly inside it.
This proactive step will flawlessly kickstart our broader automation work immediately.
I will gladly proceed to show you an excellent, highly structured example right now.
I will purposely open up Microsoft Word or a standard blank doc text document.
I am deliberately using a blank doc right now, strictly so we can comfortably start
a fresh, entirely new, empty document.
Here, you can very clearly see exactly what critical structural things are highly recommended
and available.
First, we logically have the high-level project overview section.
This clearly tells us exactly what core deliverables we strictly need in the project.
Next, we definitely have the strict team coding standards that we must absolutely follow.
After that, we discuss repository structures, testing requirements, security rules and large-scale
systems.
We will practically use a fully functional, highly complete, overarching working system
here.
Our strictly prohibited, highly restricted system areas will absolutely also be meticulously
explicitly listed right here for immense safety.
Then, our highly nuanced, deeply specific primary AI operational instructions will be
thoroughly included next.
Right after all the comprehensive AI baseline instructions, we will seamlessly have all
our broader, full-feature architectural options carefully documented.
This is essentially exactly what we traditionally call a comprehensive, well-structured readme
file in standard development.
It practically has all our complete, strict baseline instructions deeply hard-coded and
built directly right into it.
After this section is successfully completed, the very next essential technical thing dynamically
available is dealing with our sensitive back-end environment variables.
We will deeply see precisely how we can effectively, securely manage these highly critical system
environment variables.
Now, our next incredibly critical technical discussion is primarily about handling robust
backend environment variables. These are essentially highly dynamic, configurable key values operating
in the background. We can actively store them either directly or indirectly deep within
our underlying operating system infrastructure. We can comfortably and securely utilise them
later for absolutely all of our other automated complex coding tasks. Usually, we deeply involve
our complete, highly systematic overall workflow process directly here to explicitly see exactly
how a full, robust software system is successfully constructed.
These are highly dynamic back-end key values that are stored strictly and directly inside
the native operating system, kept entirely safely outside of our vulnerable, raw source
code files. They heavily detect and dictate precisely how the running process fundamentally
behaves. This brilliant system effortlessly allows developers to incredibly safely store
highly sensitive security credentials. What exactly are sensitive credentials? It is highly
vital to see this clearly. If we fail to understand this, our work suffers. Sometimes developers
are understandably incredibly afraid that their highly sensitive personal or corporate
information will eventually accidentally leak to the dangerous public internet.
Why exactly does this enormous fear exist?
Basically, because our complete interconnected development environment inherently has some
deeply guarded secrets.
These highly confidential items definitely include things like private API keys, secure
admin account usernames and highly encrypted user passwords.
We absolutely have to carefully look closely at them and protect them.
Now we officially pivot to selectively talk about the massive, overarching enterprise operational level.
What exactly inherently happens operating at the massive enterprise scale level?
Let us quickly intentionally open up a brand new, fresh, isolated chat window.
At the highest enterprise level, actively managing profound structural secrets properly
is absolutely critical for safely protecting tremendously sensitive proprietary information.
Secrets routinely may include remote cloud access keys,
massive database passwords, complex encryption keys, vital third-party API credentials,
and various access authentication tokens.
Handling environment variables securely with codecs is important.
These specific, crucial security items are undeniably very important to actively manage appropriately right here.
Usually, wildly different distinct deployment environments inherently fundamentally require
completely different sets of unique configuration values.
We can intelligently deploy and actively utilise them safely over there.
Let me clearly tell you, whenever I actively try to perform a direct system search for standard environment variables,
you immediately see our primary system environment variables are visibly available precisely right here.
You will undeniably see that absolutely all of our current environment variables are entirely accessible and available literally right now.
Sometimes it happens to merely be the static number of active system processors.
Sometimes it is a highly confidential external API key.
We can smoothly dive deep directly right into the back-end system variables menu,
carefully enter the specific custom variable name
and its corresponding strict value directly and permanently safely store it.
So, the next time we run a use case, all variables are automatically set perfectly.
How exactly is this properly handled inside a secure underlying database architecture?
As you can visibly observe precisely here, located deep inside the primary configuration
interface, we purposely actively include a dedicated corporate company database link.
If there happens to clearly be a specific network port required, we firmly include it.
If there explicitly is an overarching master application configuration requirement, we
we safely add the core app environment variable alongside the specific designated app port.
Secure, highly confidential API credentials will absolutely come directly right here.
For one clear example, if we genuinely want to safely utilise an external OpenAI API authentication
key, we securely do it precisely here.
We can undoubtedly also clearly see secure encrypted payment gateway keys stored right
here.
Then, there are massive authentication backend settings designed purely to store multiple
dynamic secrets.
These environment variables brilliantly enable large organisations to safely manage app configurations.
It prevents leaking sensitive information.
handles keys safely too without hard coding. I will definitively also sincerely tell you
that strict environment variables frankly may not initially actively seem incredibly
very important right now when we merely successfully create basic simple software,
absolutely like a fundamental basic calculator or standard normal terminal tools.
however the exact moment when we actively rigorously try to fundamentally change our
massive software architecture or alter major things safely on a significantly much larger
incredibly massive corporate scale literally many distinct individual things wildly realistically
start changing aggressively side by side simultaneously we immediately rapidly actively
see literally multiple deep cascading fundamental code structural changes happening.
Now, moving confidently right forward seamlessly, we will deeply, actively, rigorously, explicitly
discuss all of these major systematic fundamental software changes and deeply integrated highly
complex AI functions directly later.
We will explore this in the next sections perfectly.
Authentication and access configuration is a critical part of using OpenAI codecs in an enterprise development environment.
Authentication verifies the identity of the user or system attempting to use codecs,
while access configuration defines what that user or system is allowed to do.
Together, these controls ensure that only authorised developers, teams and automation tools can interact with repositories, environments, APIs and sensitive project resources.
In enterprise software development, Codex usually works with cloud-based development environments, GitHub repositories, CI-cd pipelines and internal tools.
Because these systems may contain confidential source code, credentials, customer data and deployment configurations, access must be carefully managed.
A weak authentication setup can expose the organisation to unauthorised code access, accidental changes or security breaches.
Therefore, enterprises commonly rely on identity providers, single sign-on, role-based access
control and audit logging. The authentication process normally begins when a developer signs
in using an approved identity provider. This may include enterprise login systems such as SSO,
OAuth or multi-factor authentication. Once the user identity is confirmed, the
system checks whether the user has permission to access Codex, the
development workspace and the connected repositories. This ensures that Codex
activities are tied to a verified user and can be tracked for accountability.
Access configuration determines the scope of Codex's permissions. For example,
codecs may be allowed to read a repository, analyse code, create a branch, run tests or open a pull request.
In some cases, it may not be allowed to directly merge code or access production secrets.
These permissions should follow the principle of least privilege,
meaning codecs and users should receive only the access required to complete their assigned tasks.
Repository access is especially important. Codecs must often inspect project files,
understand dependencies and modify code. However, not every repository should be
accessible to every user or AI workflow. Enterprises should configure repository
permissions based on teams, projects and business sensitivity.
For example, a front-end developer may receive access to UI repositories
but not to payment infrastructure or identity management services.
Environment variables and secrets also require strict control.
Codecs may need to understand variable names, configuration patterns or runtime requirements,
but it should not expose or hard code secret values.
Sensitive credentials should be stored in secure secret managers and injected only when required.
This prevents accidental leakage of API keys, tokens, database passwords or cloud credentials
into source code.
Auditability is another major requirement in enterprise access configuration.
Organisations should be able to review who accessed codecs, which repositories were used,
what tasks were performed and what changes were generated.
logs help security teams investigate incidents, enforce governance policies, and demonstrate
compliance with internal or regulatory standards.
A well-designed authentication and access configuration model allows enterprises to use codecs safely
and efficiently.
It protects sensitive assets while still enabling developers to benefit from AI-assisted coding.
By combining strong identity verification, scoped permissions, secure secret handling
and continuous monitoring, organisations can create a controlled environment where Codex
improves productivity without increasing operational risk.
We discuss Codex workflows now.
We want to see how Codex uses large workflows.
We look at complete software solutions and workability.
Sometimes we must see how the whole process grows over time.
For this, we change and improve code on a large scale.
After these changes, we check the overall process understanding.
I will tell you about Codex workflows.
Codex helps developers in the software development lifecycle.
It does repeating tasks.
It makes the coding environment fast.
It helps us understand how to fix different problems.
It helps us understand different work processes.
The most important discussion is how we use codecs.
We start with a prompt.
We can add details in the prompt.
This helps software work well.
We use prompts to make software processes easy, fast.
We start with the prompt.
We can add details in the prompt.
The important thing in the prompt is a defined objective.
We must have a defined objective.
We bring this objective into our software and working process.
First, we take the generation process.
We understand the process on a large scale.
We see how we generate everything.
We have one big question.
The question is how to define the objective.
We look at things to define it.
We will see how these things work together.
This is a very strong and important point.
We must know how to set up objectives for large generation.
After we set the objective, we look at the next steps.
The next step is feature development.
Feature development is a process in our pipeline.
After development, the next thing is software defect identification.
We must make this defect identification process strong.
After we find defects, we move to next steps.
The next steps are refactoring and optimization.
First, we must define a task.
We must have a clear task definition.
After we define the task, we provide background context.
We provide this context on a large scale.
I will explain this process to you.
I will use a flow diagram to show how things work.
First, we have the task definition.
Next, we have Task Context.
We must know how to add the context.
After the context, we need a detailed prompt.
Then we connect our main codecs.
We connect codecs with our own codebases.
We connect codecs with our codebases to show complete analysis.
After analysis, we must have Solution Generation.
Solution Generation must be available.
After solution generation, the next step is review.
I tell you we need these things in our prompt.
When we have these things, our prompt starts.
Inside this prompt, our solution generation process starts.
Here we have our solution generation.
After we generate the solution, we review it.
We check everything in the review step.
After the review, another process starts.
We call this new process testing. Testing is very important here. In testing we include
debugging. Both testing and debugging must happen together. We need both in our workflow.
They help us find and fix problems. These steps make the software better and ready for
final stages. Both testing and debugging must be present.
The last step available here is refinement.
We call this refinement process iteration.
We do refinement to make software better.
After the refinement step, we commit changes.
We save all the changes we made.
This is the complete process.
At the end, our workflow closes.
It closes at the deployment stage.
We go to deployment.
We deploy our project into our system.
These steps are helpful on a large scale.
They help us create a better score.
They help us create a better decision tree for work.
This is how the complete workflow operates from start to finish.
We follow these simple rules to make good software.
Every step is important for the final product.
Deployment is the final goal of this journey.
Our next talk is about codecs.
We will learn about our projects in codecs.
Project navigation is a very important AI skill in modern software development.
In big business places, developers work with big repositories often.
These repositories have thousands of files.
We can see our multiple services directly.
It also sees big documentation, complex dependencies and multiple servers.
Understanding these projects by hand needs much time and effort.
helps developers understand the project structures well. It finds correct files, traces dependencies,
and locates our implementation details. I go to the project menu directly. I click
Start from scratch. I name the new project Metabrains. I start one project directly here.
I save it. Now we have a new project. There is no chat available yet in the project.
You see our Explorer and Object options.
If we turn on the Explorer, our file opens automatically.
You can see we have no document available yet.
With time, we will make many additions and changes.
Automatically, our response and style will change.
I will start from the beginning.
We will look at all the changes we make from start to now.
Along with changes, we will also see the time.
Along with changes we will also see the time. We will see how much time one full cycle takes.
We can look at the complete process directly. Sometimes we must approve things directly
to understand them, I will tell you. I will type what things should be in our project.
I write create an agent.md file. We will create the agent.md file here. This makes our agent
work in a much better way. I type because this is a corporate sales manager and content
creator project. It will do the first step of our project here. First of all, we give
the context and our details. We are making the employee do these things here. We will
include this directly for our approval. I tell you that a complete process discussion
is very important here. In this, we have to involve all our details. We must involve our
full working process here. You can see it will take some time, obviously. It is working
in our exact folder. If I refresh our folder here, you will see the agent.md file is created.
We can directly review it here. It created the agent.md file with a tailored operating
brief. This is for the corporate sales manager and content project. The agent.md file is
made here. You can see our exact source code and other things are available. We can open
it directly in our VS code. We can open it in the default application. We can also open
it in our terminal. These things are much better here. We have a complete system environment.
Automatically, we see all divisions and working ability here. Sometimes, this working ability
or complete process causes problems. It causes problems on a big scale. We see many issues
in our work. We usually create our complete empty MD file at the very start of the project
setup. So, on a big scale, if any issue happens later, we can understand it early. We can
do things early according to our system. This is a basic discussion now. We see how complete
generation happens. We see how we take a complete process or understanding with us. After the
agent.md file we will directly look at our project structure. I will go into the exact
same folder. I will include a new folder here. This is from a previously created section.
You can see our portfolios are available here. I will do all the portfolio discussion here.
I will now analyse our repository. I write analyse this repository and provide a comprehensive
overview of the project structure. It includes the main purpose of the application. Then we have
high-level architecture. Then we have important directories. Then we have all options for
important directories on a big scale. After major frameworks, we have entry points. After entry
points, we have configuration files. Then we have deployment-related files. Then we have testing
structure. Then it says present the information in a structured format,
suitable for onboarding a new developer. We can take our things directly in
developer onboarding too. We can involve them. This is a complete structured
repository layout that we use here. Sometimes we must see some changes in
this too. In this we also involve multiple repositories and options
directly. When I enter this it will directly go to our folder. The index file
is inside. You can see this is like our index file. When the index file opens a
complete portfolio website is available. Now we will see how to enhance and
understand this portfolio website on a big scale. This will happen in our codex
here. It understood the child item here. After that it showed our files. It has
shown the key pattern too. We have one HTML document. We have one style sheet. We
have one script bundle. Then we have some static assets. We also have all other
things available to use directly. Now I will take our details. I will see how our
process runs. I will see how all direct discussions and details run. With this we
will take our setup. Usually this needs a lot of time if we take these things in
another environment but here our things are much simpler now. We can include much
better things and accounts here. I will look at our direct use case now. It read
out our whole folder here. After that it told us there are no platform specific
deployment manifests checked into the repository. The deployment guidance is
document only. After that we have a testing structure. Then all other things
have come. Now we have gone inside our project. We have seen how we will include
our system. Now I will see what entry points are available there. I will write
to find the entry points. If we want to look at something other than entry points
we will involve all user authentication features here.
We will see how we can look at them.
Along with this, we will get a direct response from the complete system.
We will see how we take things directly in our system first.
I will type to locate and explain the implementation of the user authentication feature.
I will identify all the components involved here.
Then I will look at the authentication flow.
Then I will look at the authentication middleware
Then I will look at password handling
Then I will look at the token generation process
Then I will look at the session or token management
Then I will provide a step-by-step explanation of how the application starts
Then I will process the requests from login to successful authentication
These things bring all our details here
All our handling has come here now.
Generating code from requirements is one of the most practical uses of OpenAI codecs in everyday development.
Instead of translating every single business requirement into working code by hand,
developers can provide codecs with a vast amount of information or context.
We can include clear instructions, behaviours and context.
We have multiple forms of languages available to use.
Let me open Excalibur here.
As you can see, we have some business languages.
For example, we can allow users to export reports as CSV or involve role-based access control, also known as RBAC.
Codex helps bridge the gap between these requirements and implementations
by identifying relevant files, suggesting changes, creating new components,
updating APIs, and adding tests where needed.
However, Codex works best when the requirements are very specific in nature.
Let me show you how to include basics in Codex right from the start.
Suppose you want a plan mode, and after that you want to pursue a goal.
Then you might want to create a document.
After document creation, you might want to include photos.
You have multiple plugins that you can use side by side.
browser plugin you can use that one too. If you have specific content to use that
can be utilized as well. For instance we can go to documents or downloads, select
Select an available document and use it.
After that we select our model.
This latency is quite important, therefore I will use a latest model here.
With that latest model, we can increase speed and manage latency well.
After this, our prompt should contain very detailed options.
First of all, a well-set prompt has some specific elements available within it.
I will explain these elements to you.
A good prompt includes all these necessary components.
The very first thing is context, followed by the role, details, and then the requirements.
When discussing requirements, it is a crucial point because codex works better when the
requirements are specific.
A vague prompt may produce incomplete or misaligned code.
A strong prompt includes the feature goal, affected users, input and output behaviour,
or modules to consider, coding standards, test expectations and what our codex
should avoid changing. Developers should treat the codex generated code as a
first draft so we get a complete response right from the very start of it.
Next, after the requirements, we need to establish our acceptance criteria. This
defines the standard our response must maintain when we receive it. At the end
we sometimes use a negative prompt. In a negative prompt we specify the things
that we do not need. In the rest of the prompt we list all the necessary things
that we want. However, in a negative prompt we mention all those exact things
that are not required for our output at all. For example, let me show you a sample
prompt right here in this section. We can go into Codex and type out our prompt.
We will write that you are working in this repository as a senior software engineer with a lot of experience and solid technical background knowledge today.
This defines our role. The complete task is outlined in plain words.
After the task, you can see our functional requirements are discussed, such as adding an Export CSV button near the Reports table.
Towards the end, all the detailed steps we need to perform are available.
This is our acceptance criteria.
The export button appears on the report page.
Clicking the button downloads a valid CSV file,
and the CSV contains the same rows displayed on the table.
It will take data straight from the browser, commit the repository in GitHub,
and provide the response in document form.
Generating code from requirements with Codex improves overall development speed.
When our prompts are better, the final results we get will also be much better,
better, which we can then utilise today. Clear requirements, a defined scope and
strong acceptance criteria help codecs produce code that is easier to review,
test and merge in big enterprise teams. We are discussing how big enterprise
teams can incorporate these modern features on a larger scale today. Our
next discussion will be related to editing and refactoring existing code
We have generated this exact code as an example project where we are utilising all these core elements in real time.
Now, suppose our initial code is generated and ready.
To demonstrate this point well, I will show you a custom calculator code from our older previous generations.
In that existing code, we will perform and showcase our past iterations and refactoring processes step by step for all of you to see right here today.
today. Now we will discuss editing or refactoring the code. Here you can see
that we asked to create a calculator code. It took a quick look and made a
plan for us. After making the plan it implemented the calculator in the
calculator.py file. This is our calculator. Everything in it is
functional from start to finish. If we want to run it we will see that the
verification passed using the bundled Python runtime. Note that Python and py
are not on our system path, so if we want to use it in our environment we need all
these requirements. I will open PowerShell here or I will just open the
command prompt. In the command prompt we will give this command. When I press enter
you will see that we have a complete response included here. Now I will
include it here. There is an issue in the first line of our code. So we will run it
from here to here. I will copy this. After copying I will go back to the command
prompt. Here is the command prompt. Now we will include it in the command prompt.
When we include it you can see that because this file is very old our file
is not available here. But we can still run it in our browser. Now we will look
at our editing and refactoring here. Usually this is the most valuable
capability of our OpenAI codecs for enterprise software development. While
generating new code is useful, developers spend a lot of time improving,
maintaining and modernizing existing applications. Codecs can analyze the
current code base. It can understand relationships between files, identify code smells and suggest
improvements for better readability. First I will explain the first thing. This is what
we call refactoring code. This is a process of restructuring the existing code. It improves
readability, maintainability and internal design without changing its external behaviour.
We primarily involve this in our code review.
If I go to Excalordraw, I can tell you that after refactoring, the next thing is restructuring
or editing.
That is very simple.
It is simple because we can come into our code, include any line here, and include things
by giving a local comment.
Or, if we want to do overall refactoring, I can say to make this into an HTML file that
I can run in VS Code.
Here you can see that now it will directly take our prompt.
The code was previously available.
Now it will connect our Python calculator into a browser-friendly HTML version.
Alternatively I will open our VS Code.
You might remember that we already included codecs in Visual Studio Code before, so this
will also be available for us to use in a much easier way.
Along with this, in Visual Studio Code where everything else is, we will automatically
include our calculator file.
Codex is open.
All our generations and things are available in it.
Now you will see that our codex file has arrived here.
In the codex file, all our things are directly included.
Now you can see that if we want, we can directly open the calculator in the browser, or we
We can copy its link and go to another browser.
If we copy its link, we just have to go here.
When we open it here, the calculator will open in our browser.
This is a very simple calculator.
If we want to open it in the internal browser of Codex, that is also possible.
will load and run our calculator in the Codex browser.
Here you can see that if we want, we can directly use this file in our VS Code
from the options.
We can include annotations. If we want,
we can save a screenshot here. After saving the screenshot here,
we can also use it in another browser.
We can come here and use it here too.
So, if we want to make any design changes, we can do that directly.
When working with legacy systems, developers often face challenges such as inconsistent coding styles.
Here, the coding we have is AI-based coding.
However, if we talk about legacy systems, they are systems where we manually write all the code.
We make all the changes and alterations in that code ourselves.
There, sometimes there are outdated frameworks, poor documentation and tightly coupled components.
Codex can help developers understand the purpose of existing code before making modifications.
It does this by analysing the related files and dependencies.
It can recommend safer refactoring strategies and identify areas where changes may have downstream
effects. This significantly reduces the time required to understand unfamiliar code bases.
Despite these advantages, developers should carefully review all refactoring changes before
merging them into the production branches. Even when functionality appears unchanged,
modifications can introduce unintended side effects. Now, I will work on our code here.
I will go to our codex. In codex we will write a prompt that you are working as a
senior software engineer in this repository. The task is to refactor the
existing code without changing its functionality. We will improve the code
readability and maintainability and remove duplicate logic with simple
complex methods. There is a lot of detail here. The general overview of this
detail is that we should make our code readability and maintainability better.
As soon as I improve this, we start getting our response.
We can directly include this response.
First, it will look at the current state.
The main refactor target is that we will slightly change the HTML file.
First of all, we will include the keyboard handling.
After that, we will see multiple changes in this HTML file.
If we want to review it, our changes will automatically appear wherever changes are
being made in our file. You will see that the refactor is done in one focused pass.
I am validating both sides now. Python behaviour should still pass, and the HTML script should
still calculate and respond to the button and keyboard actions. Here our checks have
passed. Now, if we reload our calculator, many changes will be included in our calculator.
Now we have another very important thing.
It is not just doing a simple check.
It also performed a Python check.
If I show you the working, after the Python check it also included HTML behaviour checks.
The refactored HTML is built here.
It has only 123 lines.
I can say that our workability is much easier now.
If we look at the code review, it changed many lines in the code.
For example, instead of display value 0, it has set the display value to the default value.
Overall, it showed our functionality in depth.
It directly changed the error coming in the display into show error.
Here too, it changed set display error to show error.
In simple words, it improved our code maintainability and nullified the error-causing paths on a
large scale.
It manipulated the errors into the ShowError function.
Exactly here too, the SetDisplayError was changed to ShowError.
This means, in simple words, our code maintainability has improved.
It has removed the paths that cause errors on a large scale.
we will discuss context windows and scope. Context window is a new topic. People do not
discuss it much. I will tell you what a context window is. A context window is the maximum
text an AI model can hold at one time. It works as the AI's memory. Everything inside
this window, like prompts, history or files, is seen by the model. Before explaining how
it works, I will give you a simple example. For a simple example, I will go to ChatGPT.
First, I write a message in ChatGPT. I say, hi, I want to work with AI and HTML.
If I continue this conversation, it will write the code. This is simple prompting.
We get our answer through it. But if we do something else, if we give a very long prompt
again and again. You will see a message. The message says it is too long. Let us see the
size of the context window in ChatGPT. I will search for the context window of ChatGPT.
It will show the context window size. Usually the model has a 128,000 token window. This
This means it takes 96,000 words or 250 to 300 pages of text.
I will copy this text and paste it many times.
I will do this until the prompt becomes too long.
I will copy it and go to a word counter website.
It is a famous word counter.
When I paste the words here, you will see the website become slow.
This is because there are 9,776 words in total.
We put this in our prompt.
It has 76,000 characters.
Now suppose I paste the last text here.
You will see a message.
It says the long text is added as a file.
The text will show up here.
I will write that if I put this file in the chat it cannot process it.
The message is too long.
We want to see the context window size of ChatGPT.
It will take time.
You will see that the context window depends on the model.
OpenAI does not always show the exact limit, but if you see the message it means the text
is too long for one input, the file is too big, or the user interface has strict limits.
If we use fewer words, we will get our answer.
In the same way, when we go to Codex we can see limits.
In the new chat we have limits.
Wait a minute, I will open it here.
We know that Codex has some limits.
Even if we add many images, files and documents there are still limits.
In real business projects, apps have thousands of files and millions of lines of code.
No AI can read all the code at once.
Devils must help codecs focus on important information.
Scope sets the limits of a task.
It includes files, modules and features.
Setting the right scope stops bad changes.
It helps codecs focus on the right parts.
Now I will tell you directly.
Suppose we get an answer.
How will a full developer work?
For example, we will take an e-commerce store.
In our example we have an e-commerce store.
A developer wants to add a discount box to a product page.
Codex. He only shares the product model, service, controller, form and tests. This limits the
context. Codex can focus on the updates. It will not make bad changes in other
places. Where do we use this? When we make changes this is very helpful. We can
modify things easily. You will see two or three options here. We can open it in VS
code. We have a full MetaBrain's project here. It has all our files. We can run
the index file here. On the side we have our chat. Our codex is also running
directly. Besides codex we have an agents option. We can use agents to do
our work directly. Now we will verify our GitHub account. Do you remember how I did
GitHub authentication? We will authorize VS code directly. Our workflow and
personal details will be added here. This works for public and private projects.
We can include this directly. If I show you the sign in again, authorisation
comes directly. We can confirm it. Suppose we want to verify using email.
The email will come automatically. We will confirm the email here. These emails
run through a base setup. We got the code here. Then we will verify it. Our VS code
will sign in and connect automatically. After signing in, MetaBrainz connects with our co-pilot.
We are running many windows. In one place we run the agent. In another place we use
our IDE. In a third place, we use it as a chatbot. So, we must manage our context carefully.
Context window and scope management are very important for AI software development. By
giving the right information and clear boundaries, developers help codecs. It creates accurate,
good and reliable code. We must look at these important things carefully.
Now, our discussion is about reviewing our AI-generated code.
In the AI-generated code, we want to see how we previously used codes like
CreateCalculator multiple times, as you can see.
We have created the calculator here, and you can see that all our changes are also available here.
For these AI-generated changes, we first need to understand two or three things.
First, in this complete software we are using, whenever there are changes, the red values
will be all our previous values, and the green values will be our new possible changes that
we have used here.
If you look here, you can first see the set display error, but now in our new code, some
things have expanded.
Let us suppose I directly include a prompt here saying, I want a scientific calculator.
Now, a scientific calculator will be created here.
Usually we have this one code and we can call it version 1.
Automatically, this version of ours will be applied here, and along with this version,
if we have any other versions available here, they will be used.
First of all, it will take some time to think about what things were discussed in the previous
context.
It will review what discussions we were having previously.
After all those discussions, our code will automatically start generating here.
Alright, it is reconnecting with our work.
Our connection with the model is being created to see how a complete connection will be generated
and how our thinking will work on a larger scale.
Usually, when we are looking at such a code, we have to do validation.
We can separate our unified difference from here.
We call this split and we call the other one unified.
In the split view, our complete previous codebase is on one side and our new code is included
on the other side.
In the previous one, you can see the display error and here you can see how much our error
evaluation is available now.
Similarly, our if action is also available here.
We can see how much if action we had previously, and after that, how many evaluations are coming
in our run action.
Alright, so all these things are being directly included in our system.
We are looking at multiple changes here.
You can see that our connection is being created once again here.
We can change the model to a very simple one, make the speed fast, and also change the reasoning
here.
Now, besides all these things, we have two options available here, Review and Undo.
In the Review option, we can directly review our code once in the first scenario.
And Undo works exactly like our version control system.
It keeps multiple versions in our adopted system.
Here you can see that our system is now running, and it is telling us that it is upgrading
the existing HTML.
Now, let us suppose I take you to this HTML file.
I will show all the differences here.
They are here now and we will also enable the rich preview.
Now you can see that this is our newer file.
Even after the newer file, when we make changes again, those changes will also be visible
here.
You will see plus 32 and minus 21.
This shows how many lines of code were removed and how many lines of code were added to our
total system.
When both these things work together, we automatically start getting our response and work results.
It shows how we are managing things.
Alright, so this is our very detailed working process.
Here you can see all the changes.
For a simple example, as we are reviewing now, the title was previously Calculator, but now
Now our new title has become Scientific Calculator.
Alright, if we look here now, all the design changes of our calculator are shown here with
plus and minus signs.
Also, you can see that if we want to add something here, we can directly include a local comment.
For example, I can say here, I want round buttons.
Okay, so now we want our round buttons.
As soon as I post this comment, you can see it is included here.
Now this comment is added, alright?
Similarly, if we go here, I will say, I want more buttons.
I am making very simple changes in front of you.
I will add the comment.
Now there are two comments here, alright?
In the same way, at the end of this file, I will say that we need simpler functionality
here.
Okay, I will say, simple functionality please.
Alright, this comment is added here.
After that, we can go to the end or just go to the start.
In the start, I will change our name here.
Change the name as MetaBrainzCal.
Okay, MetaBrainzCal.
Alright, now our comment is added.
You can see that three or four comments are here now.
In our calculator, we have a comment in row number 46 and a comment in row number 102.
After that, there is a comment in row number 200 and then a comment in row number 6.
Now what we have to do here is I can say make the possible changes asked. Okay what will happen here
is that based on the changes we included in these comments the changes will happen at those exact
points. I will only show you this one change that we demanded at the end in the comments.
We will see how it changes the name of our scientific calculator here,
and this is a very advanced feature. We are reviewing our complete AI generated changes
to see how our reviews can be applied on a larger scale and how we can include them.
It will take some time to think. Obviously you can see that it is thinking here,
and after that it says, I will apply the review comments directly.
First of all, our name will be changed to MetaBrainz.
After that, the calculator buttons will be made circular.
A few practical scientific buttons will be included.
Here you can see our calculation.
MetaBrainzCal is written here.
After that, we also included a comment here that we want our buttons to be rounded.
So, you can see that by including height, aspect ratio, border radius and all these things,
it has provided us with some rounded buttons that we can directly see here.
Alright, so all these things are greatly included in our working process here.
And through this, we can include it in our system, and it will work here.
Now we will get all our changes here.
You can see that whatever visual changes we have,
it has included some lines in a file and showed us the changes here.
We can also open that here.
OK, after that, for the next changes it makes, you can see our thinking process here.
In the thinking process, as it is including our constants and other values, these files
will automatically come here side by side.
Now it has updated our file.
We have all the commands here.
As soon as we open this in our browser, all our discussed changes are here, like Metabrains
Cal.
Our buttons have become rounded.
And now, if we include anything here, that thing will automatically be directly included
here.
OK, our error came here.
We are seeing everything working.
Alright, if we suppose we need the value of pi here, we get our pi value.
If we need the value of log8, we can directly input it here.
Also, you can see that this delete option is working directly here too.
If we look at all the signs here, every sign that we have is working very easily.
We can directly enter all our values here.
If there is no responsiveness, we can go ahead and directly include responsiveness in our
code later.
But code review is the main thing that I have discussed with you.
After this, our next discussion is related to our prompt hints.
Next we discuss the main usage of a prompt library.
We will see how we can use it and where more options are included.
First I come here.
Instead of using everything, I will search the prompt library in Codex.
Here you see Codex prompting.
First I tell you this is a built-in collection of reusable workflows, templates and skills
in OpenAI Codecs and Agentic CLI.
When I go to prompting, you see we often use prompts.
You interact with the codecs by sending prompts that describe what you want.
Example prompts are shown here.
Thread is a single session.
It has your prompt plus the model outputs and tool calls that follow.
A thread can include multiple prompts.
We use a chain of process to take things forward.
I will explain this exact process right here in our codex.
In codex, we go to our main user settings.
Inside these settings we have personalization.
In personalization, our own custom instructions are included.
We can also switch our AI personality from pragmatic to friendly.
Both of these personalization options are here.
In custom instructions, we can include all custom-made, personalised instructions that
we want in our tool.
It is quite simple to include our text responses.
But sometimes, we must see our clear deviation and how we are working on stuff, and how these
custom instructions work.
We have our memory, which we can induce right here in our experimental form.
We see how our things can be included and how we can take our many processes forward.
Our standard options show how we will best include our own memory.
First is the main Enable Memories.
Second is our Good Tool Assisted Memories.
We can also involve Tool Assisted Memories and involve all our process or workability
in it.
Next thing is our own custom prompt libraries.
What is a good prompt library?
I will tell you first that our prompt library is a great reusable prompt hub.
In this we can do our text discussion multiple times.
We can do multiple workings for our single tool.
We must see one more thing here.
From the ChatGPT side, there is no prompt library available here yet.
We have clear information about basic prompting.
But if I talk about the Claude code, there is a distinct prompt library available.
We can go there and see the many prompts are collected from the various Anthropic guides.
This includes our common workflows and best practices, and how Anthropic teams take Claude
code forward.
If I want, we can also see the core understand prompts.
We see how we can use our own prompts if we need a new prompt for git, release, data,
automate or product.
A set number of proper prompts are available for every single thing.
We can reuse them multiple times over.
We can utilise multiple variations or our many functions.
This very same thing is available here in our Claude,
but if we go to our codex, then until now we do not have these full prompt libraries available.
We can do one other good thing here. We can come right here and ask a prompt question.
If we go into ChatGPT and for our codecs we include our own best prompts,
I can say I want a whole new prompt library for my codecs.
It will then give a good reusable clean codecs prompt library.
Inside it we have all our good useful prompts. We have our bug fixes, text test generator,
code review, refactoring, feature builder, API design, performance optimization and security audit prompt.
All these things will involve in that exact thing.
From there we will take and use it well. These various things are included in our entire core
system on a large scale. We must look at all these many things on a large scale to see how we can
reuse them. We will copy it and come inside this main system to use all our many prompts.
We will not use these exact things but besides this we have all our 12 core prompts.
As we go forward our prompt library will increase even more. From 1 to 12 our many different options
will be used and we will include them. These things are used very much inside the entire system.
With this, we have a lot of great automation in our work on a large scale.
We can use that well.
I will tell you, we also have cool automations here on the side.
We can run our day brief, week review or smart project monitor.
But besides that, if we look at our cool templates, we have very many.
Now our next discussion relates to integration.
We will see how to perform AI-enhanced CI slash CD.
First, I will explain the full definition of CI slash CD.
CI stands for continuous integration.
CD stands for continuous delivery and deployment.
Usually, when enterprise-level workflow loops run, we have multiple projects.
We have standalone projects, collaborative projects, or autonomous projects connected to multiple companies, industries, and businesses.
For them, we must look at integration and deployment.
This is a DevOps methodology that automates building, testing, and releasing software.
We can discuss this as automation.
This pipeline allows development teams to ship code updates frequently, safely and reliably,
while catching bugs early in the development cycle.
Usually we do CI slash CD at an industrial or enterprise level where we need automation.
First we have continuous integration.
It is a practice where developers regularly merge their code into a central repository
like GitHub or GitLab. Every time code is merged, an automated system builds the application
and runs tests until the integration finishes. This ensures that the new code does not break
the existing code base. It allows teams to catch errors instantly. Then we have continuous delivery
versus continuous deployment. How can we use CI slash CD? First, it gives a faster time to market.
New features and bug fixes reach users in hours instead of weeks or months.
There are fewer bugs, easier rollbacks and better developer productivity.
CI slash CD pipelines can be used in GitHub Actions, GitLab CI, Jenkins and Circle CI.
I will search for codecs on Google now.
For example, if I share here that I want this in Codex, then we can also do that, how it becomes possible.
Integrating the Codex command line into the pipeline enables OpenAI Codex to automatically evaluate build failures.
It analyses vulnerability scans and proposes minimal changes required to make the tests pass.
It executes code quality checks directly.
It also generates remediation patches or pull requests.
Usually, when we talk about our process, we can perform CI slash CD in multiple forms
inside our projects.
Here in this interface and outside it, if I go directly to the terminal, I can run the
CI slash CD pipeline.
How can I do this?
First, I will search for Codex CLI.
The developer platform will open, which we can access directly.
Here we must install it.
I will come here and command the system to install Codex.
We will copy and paste the required command.
You will see that Codex is already set up here.
Because of this, we do not need to install it again.
We simply type our Codex command and it will start running.
You have seen this here too.
Whenever we give a command, we have a terminal option available on the side.
Inside this, we can automatically initiate our working process.
We also have a browser option to run CI-cd pipelines.
Usually, continuous integration and continuous deployment have become a foundation of modern
software engineering.
Traditional CI-cd pipelines automate the building, testing and deployment processes.
This reduces manual effort and ensures consistent software delivery.
With the introduction of AI-powered development tools like OpenAI, Enhanced CI and CD introduces
a new layer of intelligence into the software delivery lifecycle.
Instead of merely reporting failures, AI systems can investigate the root cause.
They propose correlations and create pull requests containing fixes.
This dramatically reduces the time developers spend troubleshooting failed builds.
It allows engineering teams to focus on high value work such as feature development and
architectural improvement.
Let me show you a simple example.
We can take any system here.
When we give a prompt, you can see our working process begins.
We get options to debug an issue or review a plan.
I will select GitHub and ask it to review the newest repository.
The newest repository will appear.
Then, I will command it to analyse the latest pull request.
It must generate unit tests for newly added functions,
modified business logic and edge cases
to improve our error handling completely.
As soon as I include this,
the error handling scenarios will become much better.
The other responses will also appear here for us to analyse directly.
Usually, the GitHub workflow is infused here.
Inside the GitHub workflow, we can directly use our other generations or processes.
Our other regions and our understanding will also appear.
Side by side, I must tell you another thing.
We usually face a concern about how to check our processes inside out on a larger scale.
We will see that in a much better form now.
In the CI slash CD pipeline, you can see the local workspace is empty.
The GitHub account is authenticated, but Git is not available.
If we set up these things, we can cross-check our CI slash CD pipelines.
We prepare a repository and use the CI slash CD pipeline perfectly.
Here, I will give you the example of a pipeline.
If you prepare a pipeline of build, which have a request, it has many stage such as
names and tests will appear here.
If you connect codecs here, then our AI tasks can work side by side with it.
Our next topic is putting codecs into our work process.
This means adding codecs to our build system.
When we do this, the system helps us find problems.
If a build stops working or a task breaks, the tool sees the code quality issues.
Before, people had to look at every single problem by hand.
Now the system looks at the failures for us.
It gives ideas to fix them and creates tests.
It can even make pull requests with good answers.
In a normal process, a person sends code to GitHub.
Then our complete system starts running automatically.
Things begin to work on their own.
We usually watch these actions in our deployment area.
For enterprises, this saves a lot of time.
do not have to fix the same small problems again.
The Codex Assistant helps keep the work active.
It understands the whole process of how things run.
We like having a place without mistakes.
Now let us look at consistency.
This is a very important benefit.
Sometimes working directly with these pipelines can be hard.
First, I will go to our plugins section. We can see the GitHub plugin here.
Next, I will search for codecs in the bar.
We see many results, but I want to find it in the profile settings.
I look at the list of options like packages, co-pilot, pages and security.
Here I will search for the codecs.
And here we have our codecs.
We can also search in GitHub or settings.
Then I decide to grant access.
To do this, I open our repository.
I click on the code button and copy the link.
I will ask the chat, do you have access to this project?
The system will now check if it can reach the repository and provide us with it.
And how we can initiate our working or a larger scale.
Sometimes we have to look at these details ourselves.
Also, we can take a complete process out here and our generation will be completed in that.
This is usually present at a lesser extent.
But now we will initiate a full-fledged process here.
You will see that it has told us here that yes, I can access the repository.
The access to our repository has also arrived here.
The second thing it said is that our default branch is main, visibility is public and effective
permissions in the session are admin, maintain, push, pull and triage. I can
simply say here that we now have to include an agents.md file inside this.
This will directly include it and give it to us. But the thing is we cannot
create things inside this. So right now we will only cross-check our agents.md
file here to see if it is directly available to us or not. These are our
things. I will now take our full detailed discussion. You will see that directly
after just one second our agents.md file has been included here. Inside it, as you
see, git isn't available. So here, after inspecting, it has directly arrived. I can
give access here to directly push the code to see how we can improve or
include things on a large scale. Side by side another very important thing is
running here. Usually in a base pipeline I could not run git push origin here
because the directory is not a git repository. Git is not installed in our
current shell. Let us suppose we want to install git. How can we do that? First of
all we will open our PowerShell here. We come inside this one. Here I say our
PowerShell. This is our PowerShell window. Coming directly inside PowerShell, we will
state our Git version here. You are seeing that the Git version is available to us here.
Let us suppose we want to install our Git. If we use this directly, you are seeing that
now we will say we want to install Git with our basic widget. Automatically our widget
will be installed here. On the basis of that widget, we will take our things inside running.
Usually these things are not explained to us.
We are just initiating our production and working on a large scale.
Here it will take some time to install.
Until it installs we will wait here.
Now, due to some issues, our Git is not becoming active.
I tried a lot to activate our Git.
You are seeing the prefix.
Branch prefix is working. Everything is working.
We usually did not include our commit instructions, but still, it is possible that by opening these things, all these items come into working.
But still, as a matter of fact, the discussion here is that when integrating codecs, organisations start in non-production environments.
This allows codecs to analyse failures and generate suggestions.
Once the team gains confidence in the results, they can gradually introduce more advanced workflows.
These include automated pull request generations and our AI-assisted bug fixing.
Overall, Codex acts as an intelligent engineering assistant inside our CI-slash-CD pipeline.
It will overall help us in building all our things.
These entire matters have been discussed here.
An autofix workflow begins the moment a developer pushes code to a repository or submits a pull request for a review.
The CI slash CD pipeline automatically starts a series of validation processes such as compiling the application, running automated tests, checking code formatting standards, verifying linting rules and executing security scans.
In traditional software development environments, any failure in these checks would require
a developer to manually investigate logs, identify the source of the issue, and implement
a fix.
With codex-powered autofix workflows, the process becomes significantly more efficient.
Instead of merely reporting that something failed, the workflow can immediately begin
analysing the problem and preparing a potential solution.
This transforms CI-CD from a passive validation system into an active participant in software
maintenance and quality assurance.
Once a failure is detected, Codex examines all available information related to the problem.
This includes error messages, build logs, test outputs, recently modified files, project
documentation, repository instructions and any development guidelines defined in agents.md.
By reviewing these sources together, Codex gains a much broader understanding of the
issue than a simple rule-based automation tool.
For example, if a login-related test starts failing after a recent update, Codex can inspect
the authentication logic, compare the recent code changes, review the affected test cases
and determine where the behaviour diverged from expectations.
This contextual understanding is one of the major advantages of AI-assisted development workflows.
After gathering the necessary information, Codex performs root cause analysis.
Rather than attempting random modifications until a test passes,
it tries to determine why the failure occurred in the first place.
The underlying issue could be a missing import statement,
a renamed function that was not updated everywhere,
a changed API response structure,
an incorrect configuration value,
a dependency upgrade that introduced breaking changes,
or a test case that no longer reflects
the intended application behaviour.
By identifying the actual source of the problem,
codecs can generate fixes that are more accurate,
maintainable, and less likely to introduce new defects
elsewhere in the system.
Once the root cause has been identified, Codex generates a proposed solution.
A well-designed autofix workflow emphasises minimal and focused changes.
The goal is not to rewrite large portions of the application, but to make the smallest
possible modification that resolves the failure.
This approach reduces risk and makes the resulting changes easier for developers to review.
For example, if a build fails because of an incorrect import path, codecs should update
only the affected import statement rather than refactoring multiple unrelated files.
also provide explicit instructions to guide this process, such as requesting
that only necessary files be modified, preserving existing coding conventions,
and updating tests only when required to reflect legitimate behaviour changes.
Following fixed generation, validation becomes the next critical step.
The proposed solution is tested using the same pipeline checks that originally detected the problem.
Automated builds, unit tests, integration tests, linting tools and security scans are executed again
to confirm that the issue has been resolved successfully.
If the validation process still detects failures, developers can provide additional context or refined instructions and allow codecs to perform another iteration.
This feedback loop helps improve solution quality while ensuring that every proposed change is verified before moving forward.
Even when automated validation succeeds, human review remains an essential part of the workflow.
Developers examine the AI-generated modifications to confirm that the solution is technically correct, aligns with business requirements, follows architectural standards and does not introduce unintended side effects.
This review process also provides accountability and governance, which are especially important in enterprise environments where compliance, security and maintainability requirements must be carefully enforced.
Once the fix has been approved, the changes can be merged into the main branch and included
in future deployments.
Over time, teams can analyse recurring issues and improve their development processes accordingly.
Repository instructions, testing strategies, agents.md guidelines and CI-CD configurations
can be updated to help codecs handle similar situations more effectively in the future.
As a result, autofix workflows not only resolve immediate problems, but also contribute to
continuous improvement across the software development lifecycle, enabling teams to deliver
higher quality software faster, while reducing the manual effort required to maintain complex
systems.
Now, the discussion we have is related to configuring automated bug resolution.
We can say this on a large scale.
In our codecs, along with other things, a discussion was going on.
This is most valuable for enterprise use cases.
For OpenAI codecs, instead of developers manually investigating every test field, linting error,
securing warnings or production defects, codecs can analyse the issue, identify the affected
files, generate a proposed fix and create a pull request for human review.
This significantly reduces the time spent on repetitive maintenance tasks, while allowing
focus for engineers to concentrate on high-level architectural business problems.
In modern software teams, bugs are often discovered through CI-CD pipelines, monitoring systems,
issue trackers and security scanners.
Codecs can integrate into these workflows so that when an issue occurs, the AI automatically
receives the failure logs, repository context, coding standards, and our project instructions.
Alright, the critical aspect we have for automated bug resolution is defining clear boundaries.
Enterprise organisations should never allow AI to directly deploy files into production.
Instead, codecs should generate code changes, execute tests, and create pull requests that
that require developer approval.
This maintains governance and accountability
while still benefiting from automation.
Human reviewers can remain fully responsible
for validating the basic logic.
Now, let me tell you a very important thing.
Our agents.md file plays a crucial role in the process.
What happens is they provide our project specifications
and instructions that guide Codex's decision making
during bug resolution.
These instructions define the coding conventions, testing requirements, security constraints, dependency policies and our architectural patterns.
The more structured the agents.md file is, the more accurate and reliable the fixes become.
Organisations must look at another thing alongside agents.md – confidence thresholds.
For example, codecs may automatically fix linting errors and formatting issues, while
security vulnerabilities or database-related bugs require a mandatory senior engineer review.
An example of this is that first of all, we have to do this step by step.
The first part of our process is to identify our bug trigger resources and define where
the bug reports originate.
Usually what happens is we see this in our CI slash CD builds, or we can see this in our
unit tests we perform, or we can see this in our integration test failures.
Sometimes issues can arise in GitHub, or our security scans can cause an issue.
Alright, after that we have to identify the AI and look at the AI's fix permissions.
If, let's suppose, there's a formatting issue, a linting issue, or a unit test failure,
We'll automatically look at all of them, and a detailed discussion will take place regarding
production incidents and everything.
Agents.md is our most important file which I mentioned here.
What happens in Agents.md is we can see the automated bug resolution rules.
Whenever we fix a bug, we should minimize the code changes, we should never modify the
database schemas, we should preserve the API contracts, add our tests for everyone, and
run all of the affected test suites.
We must explain the root cause and also create a pull request summary.
You can see all of this in agents.md, where we address the bugs, and multiple things are
included.
Then, if I, let's suppose, perform proper CI slash CD integration, meaning after identifying
the trigger sources, we've defined our AI.
Then if I say we want to configure CI slash CD here, what I'll do first is take you to
the configuration.
In the configuration workflow, we first discuss the build failure, then we understand our
codex investigation, generate the fix, run the tests, create the pull request, develop
our reviews and also then merge our workings.
So this will come here.
Then the next and most important process, which will be discussed in our setup here,
will be our validation of fixes.
Here we will require our unit tests, integration tests, security scans, code reviews and our
build verifications.
These will directly be used to approve our process.
Alright, now as an example, if I go into Codex and open a new chat, what will happen in our
chat is I'll say directly that a GitHub action has failed. We'll include the
repository name directly. We have our failure logs here and the tasks are
being discussed the most here. Alright, after that we have our unit test
failure which we will use. After that, whatever automated bug resolution we
have directly we will configure it. We will discuss a OneGo project today. We
will direct a full repository in our OneGo project. First we will create all
project code and details. After that we will check our iterations and possible
improvements. Then we will use GitHub and Codex.
Here is our Codex. We open Codex.
Inside Codex, we generate a full project before using prompts.
In Codex, we must include the SetAgents file.
But we will first exit this project.
Then we will build a new project here.
I will close this one.
We close it and build a new project again.
You see projects are available here.
I can organise them or start from scratch.
We will name our project OneGo.
In this project we will build a complete application with everything.
First we will pin this project.
After pinning, we open it in our Explorer.
Our Explorer has no file inside.
Later, all generations will come into this file.
We have our VS Code and Terminal.
I told you before we can use codecs in our terminal.
In VS Code, our cursor is available.
I will first tell you the plan.
We will open our plan mode.
We have no plugins yet.
We will not use the browser much.
We will use the 5.4 model in our GPT.
We will use the medium 5.4 model.
We will use fast speed here, not default speed.
It will be used here.
We will not connect GitHub for now.
I will say in one go that I am going to make a project
about a health care application.
Can you plan a project for me?
Project planning will start here.
First, it will settle output resources.
I will not include them now.
We look at current workspace.
You see nothing is there in workspace.
Who is the primary user for the first version of the healthcare app?
We have patients and doctors.
I will say, this application is for patients.
We want to build an application for our patients.
What kind of first release do you want to plan? MVP or balanced or ambitious?
I will choose MVP. What is our delivery target? We want to build a web application here.
I will not build a mobile application. I will build a web app here.
The current decision is clear. Patient facing, MVP sized and optimised for a web app.
I still need to lock the feature set.
Now we have our feature sets.
Which feature bundle should define the MVP?
Booking and records?
We will use this simple option.
How should the plan treat healthcare compliance in the first version?
We will use HIPAA ready design, which is recommended.
We can also use full compliance track or lightweight prototype.
How much external integration should the first plan include?
I will say minimal integration will be included.
These things are recommended here.
Through them our entire process comes.
What will be the delivery timeline?
What will be the delivery timeline for our project?
I will say I want it in an urgent manner.
This is a fourth part where we can include what we want.
What team should this plan assume?
Our small team is here.
Instead of a small team, we can choose Solo Builder.
Our solo builder is here now.
What kind of plan do you need?
Build plan or business build?
We will work with a simple build plan.
Now it reduces the project scope and other things.
You see, multiple questions are asked here.
For a solo builder, what does urgent mean for the first usable release?
We will answer one week.
We will include one week here.
Our plan will come here.
Build a patient-facing WebMVP for a solo builder
optimised for one week urgent prototype
while keeping the design HIPAA aware and future ready
for real healthcare data handling.
I will read the plan once, then we will implement it.
I am saying that we have the entire process.
We say our product definition is also happening here.
After product definition, our recommended MVP features have also arrived here.
Frontend and backend have come in our technical approach.
I will tell it that I want just a working frontend and minimal backend.
Also, it should be just HTML and CSS with JS logics.
We want our product in a simpler way.
All these things will come here.
The stack has arrived.
What should a minimal backend do?
We can use a tiny mock API.
We can use a basic form backend.
We will not use any real backend.
How should the frontend be structured?
I can say a multi-page application will be required here.
What level of frontend quality is needed?
I will say we need a portfolio quality user interface.
Our plan is created.
You can see we have JSON objects and local storage here.
Key changes are to reframe the project as a frontend prototype, not a production ready
option.
Now we can implement this plan.
During implementation, it will bring our coding.
It is checking the workspace shape.
We will look at static app files and shared styles and JavaScript layers here.
We will also check the open file to see what things are discussed in it.
First it took basic index HTML.
We will open our file explorer.
We will open 1Go from Documents.
For the time being, we have no file or format available in one go.
But later our files will appear.
It has confirmed our HTML pages and state stylesheet and JS layer.
In plugins, our GitHub is not installed yet.
I will go to our codec settings to install GitHub once.
We will go to our settings.
You can see our connections here.
In settings, you can see we have our connections.
Besides connections, we have our MCP servers here which we can use.
We also use plugins here which we can connect.
I will go to our plugins.
You can see our plugins are available.
Where all our other details are, we will include our direct option.
In configuration we have our plugins.
We can use user configuration.
We have sandbox settings and current version and everything is working.
In MCP servers our plugins have arrived.
We can also see our most used plugin here and how it is discussed.
Then we have plugins inside our hooks.
And we have our computer use plugin, so any app and our Google Chrome browser has also
arrived here.
I will bring our plugins into our settings search.
These are our plugins.
I will use GitHub here.
When I connect GitHub, you can see all details have arrived here.
Because we are using the Michael DuPont account, we will bring the same Michael DuPont email
here.
We click on Add Plugin.
Adding GitHub will appear.
It is approved by our admin.
We will go to Connect and continue to GitHub.
We will get our detail in our browser, which we will use.
You will see that GitHub is now connected.
We can try it out in the chat too.
In GitHub, we have our repositories and pull requests, and all things have arrived.
Our GitHub access is now connected.
We have our repositories and issues, and pull requests inside it.
We have 97 actions available in the GitHub app related to Read and Write.
We can use it for Read and Write functions.
If we want to try it in the chat, we can do that too.
After this, we go to our healthcare application.
You will see that a total of 9 files generated here.
You can see in these files we have our app.js.
If I go here and reload it, our file structure is still not very strong.
But you will see that all our assets are available here.
Index and records.
And all these files are generated here overall.
Now it also told us it found a portability issue in the static assets.
A few non-ASCII characters slipped into the labels.
It will run them.
The command is normalised.
I am loading the normal browser.
Now we will connect things in our in-app browser.
You will see I did not give any prompt.
I did not give any prompt on a large scale.
I gave a basic prompt that I need a healthcare application.
It planned it and took multiple recommendations from me during planning.
In the end it generated all our assets in one go.
Appointments and dashboard and doctors and index and record files are generated.
Now browser automation has also arrived.
We have all files for implementation and we can run prototypes.
Here is our documentation.
Now if I open our file explorer and go to documents and one go, our folder is empty right now.
But if I look at our index.html here in the file explorer, you will see that we have a
file available.
If I open this file in our browser, you will see our project has arrived.
It is a healthcare app prototype.
We are accessing healthcare here with appointments and records and reminders.
When we want to enter a dashboard we sign in here.
Our doctors have arrived in it.
After doctors our appointments have arrived.
And our records have arrived.
This is our whole process as you can see.
If we want we can confirm any other appointment too.
I will confirm an appointment.
I will say I have a heart pain.
I will just include a reason.
When we include this part our second appointment will come.
This means our page is loading.
If we go to records we have our medications and allergies and recent visits available.
If we go to doctors, all doctors we have are listed here.
Then comes our dashboard.
Inside this dashboard we have our current summary showing the plan and conditions and
recent visits.
Our insurance card and hydration reminder and medication review are all available.
Members and unwanted things are available here. If we want we can build a new demo
account instead of demo credentials. I will close this one. I will give a prompt
here. I liked my first draft and I want to make this an official app for the
patients. Add some vibrant health-based colors in the website. Also try to make
it more real. Our prototype is very much liked. In the prototype our login and
doctors are very real. But this dashboard has some issues. When I bring it to the phone
view it does not look special. It has many issues. This dashboard does not go higher
from here. The second thing is our login panel goes too far back. If we go to our network
inside the console, nothing special is loading. This means we have no back end. It created
a working front end for us. I have given a prompt to update our prototype. You see we
have our browser available in plugins. Due to this we can use it. It says I am updating
the prototype. It is updating the prototype towards a more launch-oriented Alaska patient
app. First I am verifying the current front end structure. Then I will replace the mock
positioning with real Alaska provider data. It will shift the design towards a premium
Apple adjacent aesthetic without copying Apple owned logos or icons, because we cannot
copy the icons. But if we want, we can copy aesthetics based on an ecosystem. And we are
going to do the same thing here. This thing will be induced here. In styles you see we
we have many changes. It is performing enhancements in our file overall.
I have included one thing in the OneGo project. I want to run the Apple ecosystem here.
Apple ecosystem means the user interface enhancements in our MacBook or iPhones. I want to adapt
them in our project. All those things are happening here. You see what it is doing first.
I gave this information here.
Use real doctor information from Alaska.
I want to launch it there.
It is taking Alaska doctor profiles from the list.
First, it read all our files.
Then it understood index.js file.
Then it understood all files in data.js.
After that it is carrying on our research purpose.
When these things are included, our final website version will come in a better form
Let me tell you an important thing. In Codex, whatever things are happening now, you can see them all here.
If we have any output, we can see it too. If we have any source, we can see which source it is utilising here.
Like here, from a regional hospital list, it is retrieving doctors.
First, it makes concrete changes, replacing generic healthcare content with Alaska-specific facility and care context.
Second, it is rebuilding the visual system into a brighter, premium look that feels native
on iPhone and Mac without copying Apple trademarks or proprietary icon sets.
All these changes are being created right now here.
In the Styles section, you can see that we have many changes appearing.
We are experiencing many changes because it is performing complete enhancements in our
file overall.
All the styling updates are being processed to match the ecosystem we requested.
Our project design is improving to look professional.
The software implementation has reached the required final stages.
All web files were edited.
The main index file is now running.
The visual brand appears much better now.
Demo logging credentials exist in the database.
Entering the main dashboard shows AuroraCare Alaska.
Navigating to care teams displays available health and vascular care, internal medicine
and real-time schedules.
Alaska Regional Cardiology and Providence Primary Care Access Details are visible with exact
addresses and contact access details.
We can book a medical appointment here.
For example, a normal check-up for a child can be scheduled at 10.15.
A new medical appointment request is submitted for 1.30.
The system updates the patient schedule.
The active list shows scheduled visits.
We can cancel any booked visit from the records.
Previous health records display current patient medications and known allergies.
Recent clinical visits and lab reviews are also listed.
All recommended system features are implemented in this application version.
All these recommended software features are now complete.
Next, a brand new change will be adopted.
A new user profile feature is needed.
The end user should create a new account, add personal details and access a personalized dashboard.
Logging out of the current active session brings us to the main screen.
Clicking on Create a Demo Account opens a new form.
A new name, Alex, is entered.
The email address, alex at gmail dot com, is provided.
A secure password is created for this new account.
The brand new demo account is accessed.
Looking at the health records for this new user,
previous medications and known allergies are still visible.
The recent clinical visit data is also showing
old information. This problem happens because synthetic mock data is used.
When a new user account is created, all personal details should start fresh.
We need to include actual user inputs instead of synthetic data.
Even if previous scheduled appointments are cancelled
they remain in the application database for the new patient.
This behaviour applies to every new patient profile created.
New data is not available yet in the interface.
To solve this issue, new code logic must be introduced.
A text prompt is written to update the application logic.
The missing profile fields need to be added
and displayed on the main dashboard. The user account creation flow must be
complete from
end to end. The new user must feel personalized
without falling back to generic demo data.
The core application logic is updating.
Five project files are being edited to implement the changes.
These code items include data, HTML, dashboard, index and records files.
More software changes are expected to arrive soon.
The main project goal is defined now.
A new created user account must feel custom and personalized.
It should not fall back to generic demo data.
The user profile flow is implemented in the source code.
Syntax checks are running to verify the software changes.
The main index file now includes a complete sign-up form.
Logging out again allows us to test the updated demo account creation.
The new registration form requires comprehensive user details.
Full name, email, phone number, date of birth, blood type, address and medical insurance information must be provided.
Emergency contact details are also required to complete the setup.
These user details will be stored across the application assets.
The new account registration form is filled with specific user data.
The first name, Alex, is entered along with the email address.
A random phone number is provided.
The proper date of birth is set. The blood type is selected as A positive.
The user city is entered as Alaska. The geographic region is specified as USA, region, state, Alaska.
An insurance plan named Master Insure Pro is added.
An emergency contact number is also provided.
In the end, a secure password is created to finalise the account.
The new user account is created.
Navigating to the medical records section shows the updated patient identity.
All personal details provided during sign-up are displayed here.
The scheduled appointments section is now empty and ready for new bookings.
The care team section reflects the correct operational details.
The personalised user dashboard is functional.
Multiple future system changes can be integrated as the project evolves.
All main project details are configured.
The next crucial step is to upload the project code.
A command request is made to push all files into a remote GitHub repository.
The operating system checks available GitHub capabilities within the active workspace.
A local system Git installation is not found.
The active folder is not recognised as a valid Git repository.
Two concrete system blockers prevent the code push process.
First, the Git software is not installed on the machine.
Second, there is no connected remote GitHub repository available.
Suggested options are provided to resolve these software issues.
A new public code repository must be created first.
The main GitHub website is open to create a new online repository.
The user login credentials are saved.
A new repository named OneGoProjectHealthcare is created.
The access visibility is set to public.
The repository creation process completes.
The Internet repository link is now available for connection.
The required remote repository link is copied from GitHub.
This specific link is pasted into the system prompt to initiate the web connection.
The active system processes the target online repository URL.
It checks whether the main GitHub connector has the necessary account access.
The code push access is verified.
The current local project files are being read in order.
The development plan is to publish them into the main code branch.
This action is done through the built-in GitHub connector.
The raw text content of all project files is extracted.
The public code files are prepared for web publishing.
A small project readme file is also generated for the repository.
At this moment, the online repository is empty.
Refreshing the web GitHub page confirms no files are uploaded yet.
The background publishing application is running the pull request.
Once the upload process is approved, the new content will be available online.
The computer system waits for the background publishing process to execute.
A new approval prompt appears on the screen.
It requests security permission to allow GitHub to run the file creation tool.
The required permission is granted by selecting the Allow option.
This choice ensures automatic file creation without repetitive manual user approvals.
A subsequent system request asks to create code git blobs.
This security permission is also allowed to proceed.
These technical steps are necessary to transfer the local workspace files to the remote web environment.
If the source code is left in the local workspace, it cannot be shared or deployed.
Moving it to the online repository ensures the system is integrated.
Two separate system blockers are identified again.
the local machine still lacks a local software Git installation.
The web GitHub integration can read files, but write operations are blocked.
This problem happens because the integration cannot access the necessary developer tools.
To resolve this exact issue, a local system installation is required.
A new internet browser tab is opened.
install git is executed. The official git software installation page is accessed.
The Windows desktop operating system option is selected. The standalone
software installer for Windows is downloaded. The software download process
will take some time to finish. The installation setup will be executed soon.
The main git installer file is saved to the computer desktop. The file download
continues in the background. In the meantime the computer system provides a
text list of terminal commands. These commands are required to push the
source code by hand. Before executing them, remote repository permissions must
be verified. The main GitHub settings page is opened to ensure proper developer
access rights. The account security and variables section is examined. The account
moderation options are also visible. Navigating to the repository security
permissions is necessary to allow new code uploads. The active pull request
settings are reviewed. The code merge commits and squash merging options are
enabled by default. The version commit settings and archive features are
checked. The critical danger zone is avoided to prevent accidental project
deletion. Everything appears to be configured in a proper state. The git
software installer download is now complete. The application setup file will
be executed next to install the software on the computer. The downloaded git
software installer is executed from the computer desktop. The application setup
wizard appears on the screen. The standard default installation options are
selected by clicking the next button multiple times. The default components
are chosen for the system installation. The default code editor is maintained.
The initial project branch name configuration is left as a default
choice. The system path environment is updated. The software installation process
begins extracting core files. The visual progress bar indicates the current
installation status. The program installation is completed without errors.
The active current terminal window is closed. A fresh new terminal session is
launched to apply the updated installation paths. The specific git
initialize command is executed again. The operating system initializes an empty
local git repository. The local development project folder is now tracked by the git tool.
The next required command is copied from the text instructions.
The project branch is renamed to main using the active terminal.
The text command executes without any prompt errors.
The remote origin target command is copied next. This specific command links the local code
repository to the new created online GitHub repository. The web link is pasted
into the terminal and executed. The internet connection is established
without issues. The next development step requires adding all project files to the
code staging area. The standard git add command is prepared. An error prompt
occurs stating access permission is denied. The operating system cannot open
a distinct application data directory.
This file access issue must be resolved.
The access permission denied error halts the running process.
The operating system attempts to add developer files from the root user directory instead
of the project folder.
This behaviour is a crucial mistake.
The code terminal is operating in the wrong system directory path.
A new Terminal Application tab must be opened within the exact correct project folder.
The root user terminal is closed without delay.
The new command terminal now displays the correct document path for the software project.
The standard git initialize command is executed again in the right folder.
An empty code repository is initialized here without any issues.
The Branch Rename Text command is executed to set the main branch.
The Remote Origin command is pasted and executed to link the online GitHub repository.
The correct project folder is now connected.
The next workflow step is to add all files to the staging area.
The simple Git Add command is executed without errors this time.
All main project files are added to the code staging area.
The standard git commit command is executed with a descriptive message.
The operating system returns an author identity unknown error.
The code commit cannot proceed without proper user identification.
The global user configuration commands must be executed first.
The terminal command to set the user email is copied.
The account email address is updated to match the online GitHub account credentials.
The command is executed without any system errors.
The terminal command to set the username is copied next.
The developer username is retrieved from the Web GitHub profile page.
The target username is pasted into the terminal command line.
The system configuration is updated without issues.
The required author identity is now established.
The standard git commit command is executed once again.
This specific time, the code commit is a success.
All modified files are recorded in the local repository.
The source code is ready for the final push.
The main commit process includes all necessary application files, the design assets, HTML
web pages and application data files are secured.
The final terminal command to push the source code is executed.
The command terminal requests user authentication to access the remote GitHub repository.
A new internet browser window opens for the user login process.
The Sign in with internet browser option is selected.
The existing active session credentials are used to authorise the upload transaction.
The access authorisation succeeds without delay.
Returning to the command terminal confirms the code push process is active.
The data objects are compressed and written to the remote web server.
The main code branch is set up to track the remote origin point.
The entire application project is uploaded.
The online GitHub repository page is refreshed in the internet browser.
All local project files are now visible online.
The assets folder and HTML text documents are listed.
The code upload process is verified and a success.
The uploaded index document file is opened on GitHub to verify its code contents.
The online code matches the local computer version without flaws.
The source blame and file history options are functional.
The raw text code can be accessed any time.
The entire upload process is now concluded.
The initial project objective was to build a medical healthcare application project.
A detailed development plan was formulated first.
basic minimum viable product. The database backend requirements were later removed to
to focus on the user front-end interface.
The HTML and CSS design structures were developed with minimal JavaScript logic.
Various design iterations improved the visual page aesthetics and user experience.
The personalized user profile creation feature was integrated.
In the end, the local source code was pushed to a public code repository.
The application project is stored and accessible.
Future code modifications can be implemented and tracked through this version repository
system without effort.
The detailed software implementation plan proved effective in practice.
We established a strong code foundation using standard modern web technologies.
The front-end user interface provides a seamless, smooth experience for clinical patients managing
their healthcare needs.
The synthetic mock data limitations were overcome by implementing dynamic user input handling.
The medical appointment scheduling and user cancellation workflows operate without any
system errors.
Essential patient medical records remain accessible on the personalised user dashboard.
By utilising the Git version control system, the main source code remains protected against
accidental data loss. The open public repository allows other software developers to review
the application project structure. This developer workflow demonstrates a practical approach
to rapid web application development and code deployment. The initial system setup challenges
regarding local machine software requirements were resolved with great speed. The comprehensive
command terminal instructions ensured execution of necessary developer commands.
The final software outcome is a functional, well-documented and versioned front-end application.
The established project goals are fulfilled.
The discussion relates to possible iterations we can include here.
In our use cases, we create projects multiple times, requiring iterations.
We can include these iterations to see what is possible.
Iterations start from the beginning.
We include project details and formats.
Another option is available after project creation.
Moving to the end, our index was complete at this step.
Here, in frontend, backend, appointments and records, our option has arrived.
Changes are never small.
For changes, we will include details multiple times.
Another important thing is working in an environment requiring code changes.
Iterations become version-based.
The first website version was quite different from the current version.
We must understand version histories to see which was more compatible.
Sometimes we include specific things from a specific version.
Going into our project, this was the final version.
Looking at this project, considering the whole use case, the logo is incorrect.
We can change the logo.
The dashboard should be a sliding dashboard, not a consistent one.
Instead of this, some analytics should be involved here.
Looking here, the card distance and the empty space in the website should be minimal.
We should fill such spaces beforehand.
In our website text, search engine optimization is not involved.
The colors involved here are quite dull.
We can improve all these things just by giving it some prompts.
Our iteration will start happening now.
Alongside iteration, another important thing is making large scale improvements via prompts.
Since this tool is based on our prompts, any new improvement will be based on prompts.
there is no other way to improve our stuff.
These things will be induced here with our ongoing time.
As our time increases, we must iterate these things
and see how we are taking them forward.
Along with this, another important thing
is that when making improvements based on prompts,
error chances increase.
Therefore, we should review our code first.
After reviewing the code, we should take things
towards our other generations and discussions.
Sometimes, within our code itself,
there are multiple errors we spend time correcting.
We are focusing on making the dashboard intuitive.
The layout needs adjustments so upcoming visits
and active reminders are visible to the user.
Care teams and appointment sections
must be integrated together.
This ensures the entire application functions
without visual or technical interruptions.
This completes our entire discussion related to our iteration.
Along with the iteration, we covered possible improvements
that needed to be discussed.
Looking at the bottom section, the reminders and profile
loaded cards have gaps needing fixes.
The design should feel premium and responsive.
The patient readiness items must be tracked
on one premium dashboard.
When looking at source options for medical centres,
like Providence Alaska Medical Centre or Alaska Native Medical
Centre, information must be displayed.
The layout structure lacks proper alignment,
and text blocks feel disconnected.
We will use specific commands to refine these interface elements.
Once we apply new styles, the final product
will look more professional.
Everything will be committed to the repository, ensuring all changes are saved and tracked for future updates and continuous development.
Now comes the last part.
At the end of this course, you saw one main thing.
It was our GitHub and Codex tools.
We tried to connect GitHub.
Then we got many tech issues.
I will say here I will use our plugin of GitHub now.
I will start a discussion with the GitHub plugin tool.
I will ask, can you check if GitHub plugin is working?
This will test our plugin once.
We will see if our plugin works in any user case.
If our plugin is not available, we can check it.
You can see we have verification now.
You can see that I have verified it.
This login account Robert is here.
You will remember our main account here.
That is connected here.
Its user ID has also come.
that confirm that the plugin is installed, reachable and authenticated.
Now I can say, what can I do with this?
This will start giving us a response.
It will tell us where we can use this plugin.
This tool is not available on a weak level,
but still we have to see how our tool can work here.
You will see here it says you can ask it to read multiple actions.
In this we also get more recommendations.
I will suggest to you that we should use multiple plugins.
Like right now, you are seeing that we can use our windows.
We have our Chrome and data analytics and product design.
We also have Apollo and Atio and Carter CRM and Clay and Circleback.
We have Granola and Otter and Canva.
We can use all these plugins.
We have many options.
If we bring any of these in here, we can use it out.
For every niche, we have separate options available for us.
Like for our education and research, we also have options available right here.
We have our Dow Jones Factiva here.
We have our GovTribe and we have Life Science Research.
For finance, we have multiple softwares available right here.
So what Codex does is on a large scale it gives us multiple plugins to use.
From these, the used plugin on our developer side is our GitHub plugin.
But if we want to use multiple plugins on our whole enterprise level, we can do that too.
With that, our price will increase.
Our usage cost will also become a cost that is quite high.
The OpenAI ecosystem is a collection of tools, models and platforms
that help individuals and organisations use artificial intelligence in practical workflows.
In this diagram, OpenAI ecosystem is the central idea
and the main branches show the important parts connected to it.
ChatGPT is one of the most familiar parts of the ecosystem.
It helps users write content, explain concepts, solve problems,
summarise information and support daily work.
In software development, ChatGPT can help developers understand errors,
write documentation, plan features and improve prompts before using them with coding tools.
The OpenAI API allows developers to connect OpenAI models directly into their own applications.
For example, a company can build a chatbot, document assistant, coding assistant, customer support tool or automation system using the API.
This makes AI usable inside real business products and enterprise systems.
Codex is focused on software development.
It helps developers generate code, refactor files, explain existing code, create tests, debug issues, and work with repositories.
In an Enterprise course, Codex is important because it shows how AI can support real development workflows instead of only answering questions.
The Models branch represents the AI models behind the ecosystem.
These models can work with text, code, images and other types of input depending on the
product or configuration.
Better models usually mean better reasoning, better code understanding and more accurate
responses.
Finally, enterprise tools are important for organisations.
Enterprises need security, governance, permissions, auditing and control over how AI is used.
These tools help companies adopt AI safely while protecting data, managing access and
following internal policies.
Overall, the diagram shows that the OpenAI ecosystem is not just one product.
It includes user-facing tools, developer APIs, coding assistance, advanced models and enterprise
controls.
Together, these parts help teams build, automate, learn and develop software more efficiently.
This conclusion mind map summarises the key lessons learned throughout the OpenAI Codex Enterprise Development course.
The central idea is that AI-assisted development is becoming an important part of modern software engineering
and organisations that learn to use these tools effectively can significantly improve productivity, software quality and development speed.
The first branch focuses on OpenAI Codex itself.
Throughout the course, learners discovered how Codex helps developers generate code, analyse repositories, refactor applications, create tests and automate repetitive development tasks.
Rather than replacing developers, Codex acts as an intelligent development assistant that helps teams work more efficiently.
The next branch highlights the development workflow.
One of the most important lessons from the course is that AI can support every stage of software development.
Developers can use Codex during planning, implementation, testing, debugging and deployment preparation.
Instead of viewing AI as a tool used only for coding,
organisations can integrate it into the complete software development lifecycle.
The Enterprise Adoption section emphasises that successful AI implementation
requires more than technical capability.
Organisations must establish governance frameworks,
security controls, compliance processes and collaboration standards.
Enterprise teams need visibility into how AI is used and must ensure that generated code meets organisational policies and quality requirements.
The best practices branch represents the habits that produce the best results when working with codecs.
Effective prompt engineering helps developers communicate requirements clearly.
Code reviews ensure generated code is maintainable and secure.
Validation and testing confirm that AI-generated features satisfy business requirements.
These practices help maximise the value of AI-assisted development.
Another important area is operational excellence.
As AI adoption grows, organisations must monitor usage, manage costs, optimise resources and measure performance.
Understanding token consumption, tracking productivity improvements and evaluating return on investment help organisations scale AI responsibly and efficiently.
The continuous learning branch reminds learners that AI technologies evolve rapidly.
Developers should stay informed about new codex capabilities, open AI platform updates, community best practices and industry trends.
Teams that continuously learn and adapt will gain the greatest long-term benefits from AI-assisted development.
The Future of Development section looks ahead to emerging trends.
AI assistants will become more capable, agent-based workflows will become more common, and human-AI collaboration will continue to evolve.
Developers will increasingly focus on architecture, business logic and strategic decision making,
while AI handles more implementation tasks.
Finally, the most important takeaway is that AI augments developers rather than replacing them.
Human expertise remains essential for understanding business requirements,
making architectural decisions, reviewing code quality, managing risk and ensuring software meets organisational goals.
When used effectively, Codex enables developers to deliver better software faster while maintaining quality, security and reliability.
In summary, the course demonstrates that successful enterprise AI adoption requires a combination
of technical skills, governance practices, continuous learning, and thoughtful collaboration
between humans and AI systems.