DEV Community: khaled Alshibani

Using ChatGPT With GitHub as Another Developer on the Team

khaled Alshibani — Mon, 31 Aug 2026 11:30:41 +0000

Before going deeper, this article is meant to be a simple guide. It only depends on normal ChatGPT conversations and basic Github usage. I am not going into AI Skills, advanced agent setups, custom automations, or other more complex configurations here.

I also tried to keep everything understandable even for someone who has not used ChatGPT with GitHub before. The goal is to explain the workflow itself first, using the simplest setup possible. I hope you enjoy reading it ; )

A few days ago I wanted to vibe code a new project and started with Codex. After some time I hit the usage limits, so I had to decide how to continue the work.

I could have moved to claude code, and sometimes I actually find claude better for coding. But personally, when I still need to talk through the idea, and do planning like thinking about the architecture, organizing the work then I always prefer ChatGPT.

So I continued from ChatGPT, connected it with GitHub, and this is where the workflow started becoming much more interesting for me 😀

Instead of treating ChatGPT only as a chat and something that answers questions or generates code, I started treating it more like another developer working on the project. The implementation is only one part of the work. There are also issues, planning, branches, pull requests, reviews, CI, and deciding what should happen next.

The goal became that I want to discuss the project and make the important decisions, while most of the normal repository workflow can happen without me explaining every step.

Ideally, after some work is finished, when I want to do testing I just switch to the branch and pull the changes.. it is exactly as someone in the team works with you and you can either just manage, or review and test or also sometimes coding.

Codex Is Better for Coding, but the Limits Matter

Codex is still much better suited for the actual coding environment because it can inspect the full repository locally on my machine and work directly with the tools available to the project. But this does not mean Codex is required for making changes in GitHub. ChatGPT itself can still commit changes and handle the GitHub workflow directly through the connected GitHub plugin.

BTW, normal ChatGPT chatting does not consume that same Codex allowance, so I can usually keep discussing, planning, and working for much longer during the day. It is not literally unlimited because ChatGPT can still have usage limits depending on the plan, but compared with Codex it can sometimes feel almost like infinite working time for this kind of workflow 😀

Connecting ChatGPT to GitHub

Before continuing, GitHub needs to be connected to ChatGPT. Just open the ChatGPT plugin ( https://chatgpt.com/plugins/plugin_connector_1p_1a69035c238881919c4190932b2df699?q=github), then authorize the GitHub account and choose which repositories it should have access to.

If GitHub is already connected and repository access still needs to be configured, open the ChatGPT Codex Connector settings, select the GitHub account or org, and select the repositories ChatGPT should have access to or choose all, and save the changes.

I recommend giving it access only to the repositories that are actually needed. I also think the available actions can also depend on the ChatGPT plan and permissions given to the GitHub integration.

After that, the repository can be used directly from the conversation, so just copy URLs instead of continuously copying code, issues, PRs, and other information into the chat.

One important point here is that I am doing this directly from the normal ChatGPT conversation. With the GitHub plugin and the needed permissions, ChatGPT itself can create branches, change files and commit them, create issues, open PRs, review them, and merge them. I am not using Codex for these GitHub operations, and there is no need to generate ZIP files or manually copy the changes back into the repository. The current Github plugin is listed with write capabilities, so the repository workflow can happen directly from ChatGPT 🙂

GitHub became the state of the project

Keeping the whole project plan inside a ChatGPT chat/conversation becomes messy very quickly, and it is bad for the future when there is a need to review what is already done. So if an issue is discovered today and should be fixed two weeks later, I do not want the only record of it to be somewhere inside an old conversation. The same applies to architecture work, bugs, refactors, documentation, and features that were discussed but intentionally postponed.

GitHub already has a good structure for this. Issues contain the actual work, pull requests contain the implementation, and GitHub projects can contain the current state and priorities. It’s possible to use GitHub discussions for the ideas that need to be discussed and planned more.

This makes GitHub the shared state between me and whichever agent is doing the implementation. ChatGPT does not need to be the only place that knows what is happening. The repository itself contains the history and the project contains the work that still needs to happen.

Starting from scratch

When creating a product from scratch, it is very tempting to immediately ask the agent to build features.

I started preferring to do the opposite.

Before a lot of code enters the repository, I want the repository itself to define how development should happen. If the project is created from scratch, this means creating the repository properly first, configuring the project, and creating issues for the foundations before moving into the actual product features.

For example, I normally want the early work to cover things like:

Repository and branch rules (if available)
GitHub Actions and CI
Automated tests
Linting and formatting
Type checking
Build checks
Security and quality checks
Dependabot
Issue templates
Pull request templates
Development and architecture documentation

The exact list obviously depends on the project. A small package does not need the same setup as a large web application or any project.

The important idea is that quality should not exist only inside a prompt.

So when writing this:

this does not really enforce anything, but automated checks can!

Tests, linting, type checking, builds, and security checks can run automatically through GitHub Actions whenever new changes are pushed or a pull request is opened.

This becomes especially useful when AI is writing more of the code. If something breaks, CI can catch it before I consider the work finished, instead of depending only on ChatGPT remembering every quality instruction from a long conversation.

This becomes especially useful when AI is writing more of the code. If an agent can work quickly, the repository should also be able to reject bad work quickly.

If tests fail, the merge is blocked. If the build fails, the merge is blocked. If required code scanning fails, the merge can also be blocked.

This is much more reliable than expecting the model to remember every quality instruction from a long conversation.

I already saw others described a similar experience. They started from an empty Git repository, and a large part of making the agent effective was building the repository structure, CI, formatting rules, documentation, tools, and guardrails around it. Their conclusion was not simply to ask the agent to try harder when something failed, but to improve the environment so the expected behavior became easier to understand and enforce. And I like this idea a lot!!

The repository should teach the agent how to work.

Proper work starts with an issue

Another rule I started using is that proper work should have an issue before implementation starts.

This might sound unnecessary for a personal project, but it becomes useful once an agent starts doing a lot of the development.

Imagine the current task is authentication. While working on it, the agent notices that the something else could be improved, an unrelated test is missing, and one part of the API should probably be refactored.

All of these might be valid observations, but they do not necessarily belong inside the authentication change.

I prefer creating issues for those findings and continuing with the current scope.

This gives the project a memory. Useful work does not disappear inside an old conversation, but it also does not need to be immediately mixed into whatever PR is currently open!

I think this is even more important now because AI makes generating large changes very easy. I also ready see discussions from developers about AI generated pull requests becoming harder to review because the changes can quickly spread across many files and concerns. BTW, I do not think the solution is making every PR tiny, but the scope should still make sense.

One issue does not need to mean one PR

Having issues for the work does not mean I want to force one pull request for every issue.

For example, imagine the project has these issues:

These are separate tasks, but I would probably be fine with one repository quality PR completing all three.

The important part is that every piece of work is tracked and that the pull request clearly links what it completes. And I don’t see much value in creating three branches and three PRs only because there happen to be three issues!

At the same time, unrelated work should not silently enter the same PR.

So the rule I currently prefer is simple. Work should start from issues, and one PR can close multiple issues when they are genuinely related.

I want the workflow itself to be understood

After the repository foundations exist, the normal development loop should not need to be explained every time.

The flow is not something special invented for AI. It is basically normal development:

What changes is how much of this process I need to do manually.

If I ask chatgpt to start the next issue, I do not want the task to finish when a few files are changed.

The issue should be moved into progress. A branch should be created. The implementation should be done there. Relevant tests and quality checks should run. A PR should be opened with a useful description and linked issues. CI should be checked before merging.

This is also where issue templates and PR templates become useful. GitHub supports PR templates that can ask for the purpose of the change, related issues, testing notes, and other information needed for review. So, instead of repeatedly asking the agent to write a good PR description, the repository can already define what a good PR should contain!

Reviewing the pull request before merging

I also want the agent to review its own pull request before merging it.

At first, this sounds strange. If the same model created the implementation, how useful can it be to review its own code? 😅

I was unsure about this too, but I started finding the separate review pass useful, and here is why:
Implementation and review are different tasks.. During implementation, the goal is to solve the issue. During review, the goal becomes finding reasons the change might not be ready.

I normally want the review to look at the diff, tests, edge cases, architecture, security, unnecessary complexity, unrelated changes, and whether the linked issues were actually completed.

Something like this is enough to change the context:

CI becomes really more important

The repository should verify as much as possible before the PR reaches the final review.

For example, depending on the project:

GitHub can make these checks part of the merge requirements. When required status checks are enabled, a PR cannot be merged into the protected/destination branch until the configured checks pass.

This moves a lot of the repetitive verification into CI, so I can focus more on the implementation, architecture, edge cases, and product decisions during the review.

Why I prefer Squash and Merge

Agents can create many intermediate commits while implementing something.

A branch might end up looking like this:

I do not have a problem with that while the work is happening. I just do not necessarily want all of those commits inside main (or whatever is the default branch). So, for this workflow, I prefer using Squash and Merge.

GitHub’s squash merge combines all of the commits from a pull request into one commit on the base branch. The other common choices are preserving the commits through a merge commit or rebasing them individually onto the base branch.

With squash merging, the final history can stay much simpler:

instead of containing every correction the agent made during implementation.

This is only my preference. I do not think squash merging is automatically correct for every repository 😀

But when every PR represents one logical piece of completed work, having the merged PR become one proper commit fits very well.

GitHub Projects can handle more than I expected

At first I thought I would need a dedicated project management tool immediately.

For smaller projects, I do not think that is necessarily true anymore.

GitHub Issues and Projects already cover a lot of what I need for a development focused project. The backlog can live there, issues can have priorities and statuses, pull requests are already connected to the code, and project automation can keep much of the state updated.

This is important because I do not want maintaining the board to become another manual task.

If an issue is finished, its status should reflect that. If a pull request is merged, the project should not still show the work as being in progress.

For a new repository, I like starting with a simple kanban board:

Then the work can become more detailed later if the project actually needs it.

Linear when planning becomes more advanced

For larger planning, I also like using Linear. BTW, Linear has a deeper GitHub integration than I expected (check https://linear.app/integrations/github for information).

Also, Linear has an official ChatGPT plugin, so it can be connected directly to ChatGPT and used from the same conversation ( https://chatgpt.com/plugins/plugin_asdk_app_69a089a326dc8191b32a3f2553f5be2c?q=inear).

I still would not add Linear to every repository/project. For many projects, GitHub Projects is enough.

But once the planning includes larger backlogs, cycles, multiple projects, product work, or more advanced prioritization, Linear starts making much more sense!

That’s all

So overall, the interesting part for me is treating AI more like another developer (without hitting the limits), while I can make the important decisions, discuss the architecture, change the direction when something does not make sense, and review anything I do not trust.

Originally published at https://technway.biz on August 25, 2026.

The neverending nightmare of keeping code satisfying!

khaled Alshibani — Wed, 16 Oct 2024 20:54:50 +0000

TOC

Explaining the problem (Options overwhelming)
Real-life struggles from my experience
Results! Is this good or bad?

Explaining the problem (Options overwhelming)

When you build a real application for the first time using a new language, technology, or framework while you're learning, things can get messy fast. It all starts with small questions, like whether you're putting files in the right place.

Then you get sucked into every little detail:

searching for the “best” way to organize your directory tree.
The problem then is that You find 10 different ways, each one claiming to be the best, how to name files, how to write clean code, how to name variables... and suddenly you’re even more confused!

Before you know it, you're stuck figuring out your development workflow:

where do you even start? Then comes testing, what kind of tests should you write? Should you automate them? Which tool is the best? And, of course, writing documentation brings on yet another part of confusion.
It's perfectionism leading you to craziness!

YES, perfectionism takes over, and it's enough to drive you crazy!

Real-life struggles from my experience

Every time I learn a new technology, it’s the same nightmare. This happened to me when I built my first full-stack app, then again when I created my first React app, and yet again when I worked with Next.js.

Most recently, I went through this while building a component library. It started with the struggle of choosing the right tool. Firstly, I went with Stencil.js. But even during development, I kept questioning my choice, wondering why I didn’t go with Lit instead! Later on, I realized Stencil was the best choice for what I needed. These back-and-forths are frustrating, but they also make your decisions and satisfaction stronger as you go.

Results! Is this good or bad?

In most cases, I’d say it’s good!

Every time you learn something new, things often feel like a mess at first. Your code and logic might look pretty bad, but over time, you improve, refine, and make everything better bit by bit. And that’s the beauty of it. If you’re not going back to make things better, you may not be growing as a developer!

However, there’s a downside too. If perfectionism drains your energy and productivity, it’s a sign to take a step back. You need to remind yourself that "The more issues you encounter and fix, the more you’re mastering your craft."

No software or app was ever perfect from the start. Every great application evolves over time, and so will your skills.

Software Is Never Finished and Code Can Always Be Improved.

Software is never finished, only abandoned.

Upcasting - Using a Superclass Reference for a Subclass Object

khaled Alshibani — Fri, 11 Oct 2024 19:41:10 +0000

Consider a scenario where we create a class named User and then create a subclass that extends User called Employee.
Typically, we create an instance of User with:

User user = new User();

Here User is the type of the variable user.
user is the variable that holds the instance of the class.
And new User() creates a new instance of User.

Simply put, the user is an instance of User.

But what if the superclass User needs to use methods defined in its subclass Employee? Can this happen?
The short answer is yes, but only for overridden methods (methods that exist in both the superclass and the subclass). This is what enables polymorphism.
Since the inheritance relationship is "is-a" relationship, Employee is-a User. so, nothing prevents User from holding a reference to an instance of its subclass Employee, as long as it is a compatible type.

This is done as follows:

User user = new Employee();

Now, let’s say the User class has two methods:

getUserName()
getUserSalary().

while the Employee class has an additional method called getEmployeeInformation() and overrides the getUserSalary() method.

Then with User user = new Employee();:

user.getUserName() will work, as it's defined in the User class.
user.getUserSalary() will also work, but the output will be from the overridden getUserSalary() method in the Employee class, not from the one in User. This is the essence of polymorphism.
user.getEmployeeInformation() will not work. It will throw a compilation error as it's specific to the Employee class.

A compilation error occurs when the compiler finds issues such as syntax errors, type mismatches, or other violations that prevent successful code compilation.

If we try to do the reverse and reference a subclass object Employee with a superclass reference User, it will not work without manual casting! This requires explicit casting, as User is not necessarily an Employee.

Upcasting VS. Downcasting

After simply explaining this, with a simple example, let's focus on the terms.

Upcasting

"Superclass reference to subclass object" is typically called upcasting. Simply put, upcasting is typecasting a child object to a parent object, and it happens implicitly (meaning the compiler handles it automatically, so we do not need any specific casting syntax). It's like when we did User user = new Employee();.

What About Downcasting?

Downcasting is the exact opposite of upcasting.

Remember when we said that creating an Employee reference from a User instance is invalid? This is called downcasting, and it must be done explicitly using casting syntax. While upcasting is very safe, downcasting causes risks. This does not mean it's not useful, but it must be used with caution.

I won’t go into too much detail about downcasting since this article is focused on upcasting, but the key point is showing the main difference between downcasting and upcasting.

And that’s a wrap! :)

How to Land Web Development Clients and Build a Successful Career

khaled Alshibani — Thu, 14 Sep 2023 20:35:58 +0000

Introduction:
In the fast-paced world of web development, finding clients and establishing a successful career requires more than just technical skills. Clients won't magically appear at your doorstep, no matter how skilled you are. In this article, I'll delve into the strategies that can help you attract clients and build a thriving career in web development.

1. Build Your Online Presence:

One of the first steps to attracting clients is building a strong online presence. In today's digital age, this is where potential clients are likely to discover you. Here's what you can do:

Networking is Key: Networking isn't just about making connections, it's also about establishing trust. Engage with others in the web development community, share valuable content, and actively participate in relevant discussions on social media platforms.

2. Showcase Your Skills Through Your Work:

To prove your expertise, you need a portfolio that speaks for itself. Consider these points:

Create Diverse Projects: Develop at least four diverse projects that showcase your web development specialization. These projects should not only demonstrate your skills but also your versatility as a developer.
Quality Over Quantity: It's not about the number of projects but the quality. Potential clients will assess your work based on the projects you've completed.

3. Consistently Share High-Quality Content:

High-quality content not only attracts clients but also establishes you as an authority in your field. Here's how:

** Share Valuable Insights:** Strive to provide valuable insights, tips, and tutorials related to web development. This demonstrates your expertise and commitment to the field.
** Avoid Copy-Pasting:** Authenticity sets you apart from others. Avoid simply copying content from elsewhere; instead, provide your unique perspective.

4. Continuously Improve Your Skills:

Web development is a constantly evolving field. Staying updated with the latest trends and technologies is crucial:

Stay Informed: Keep up with the latest trends and technologies in web development. Share your knowledge with others, demonstrating your growth and expertise.

5. Explore Freelancing Platforms:

If your online presence alone isn't bringing in clients, consider leveraging freelancing platforms:

Join Platforms: Platforms like Upwork, Freelancer, and others connect freelancers with clients seeking specific skills. It can be a valuable way to find clients and projects.

Conclusion:
In the world of web development, skills alone won't guarantee success. Building a thriving career requires networking, a strong online presence, consistent quality work, ongoing skill development, and sometimes, the use of freelancing platforms.

Remember, patience and hard work are essential in this journey. By following these strategies, you can attract clients and pave the way for a prosperous web development career.

Learn the Basics of CSS and How it Works

khaled Alshibani — Sat, 15 Jul 2023 13:52:02 +0000

CSS, short for Cascading Style Sheets, is an essential part of web development that allows you to control the visual appearance of your web pages.

In this CSS beginner's guide, I will explore the fundamental concepts:

1. What is CSS?
2. CSS vs. CSS3. How do they differ?
3. Is there a CSS2?
4. Is CSS a programming language?
5. Who should learn CSS?
6. How CSS works?

1. What is CSS?

CSS is a language used to describe the presentation and styling of HTML documents. With it, you can define the styles of HTML elements, such as colors, fonts, sizes, and spacings. CSS achieves this by using selectors, properties, and values.

Selectors target specific HTML elements that you want to style, and they can be based on element types (<h1>, <p>, <div>), class names (.class-name), IDs (#an-id), or other attributes.

Properties represent the aspects or characteristics of element styles that you want to modify. such as color, font-size, background-color, and margin.

Values are assigned to properties and define how the selected elements should appear. For instance, the value of the color property can be blue, and the value of the font-size can be 18px.

By combining these three parts, you create CSS rules that instruct the browser on how to style elements. Here's an example:

h1 { /* The Selector */
  color /* The Property */: blue  /* The Value*/;
  font-size: 18px;
}

2. CSS vs. CSS3. How do they differ?

CSS3 is an updated version of CSS that introduces new and improved features for web styling.

With CSS3, you can achieve advanced effects like gradients, shadows, and animations. These enhancements provide greater flexibility and creative possibilities for designing modern and creative websites.

CSS, on the other hand, refers to the earlier versions of CSS before CSS3. While CSS3 has become the most popular and widely used version of CSS, understanding the basic concepts of CSS is still essential as it forms the foundation for CSS3.

3. Is there a CSS2?

Yes, there is a CSS2. It is a previous version of CSS that expanded the capabilities of CSS.
CSS2 introduced important features like positioning, floats, and advanced selectors, which have influenced the development of CSS3.
Although CSS2 has been largely replaced by CSS3, understanding its concepts is still valuable for maintaining and updating older web projects.

4. Is CSS a programming language?

It's important to clarify that CSS is a styling language, not a programming language.
While programming languages involve logic and calculations, CSS focuses solely on the visual presentation of web elements. CSS complements HTML by specifying how elements should appear on the screen.

5. Who should learn CSS?

CSS is a crucial skill for web developers and designers. By learning CSS, you gain the ability to customize the visual aspects of web pages and create engaging user experiences.

If you're involved in front-end development or want to design and develop web pages, learning CSS is a must.

6. How CSS works?

Understanding how CSS works allows you to optimize your stylesheets and make informed decisions when it comes to styling and layout. Here is the process of how CSS works:

1. HTML Parsing & Loading: The browser parses the HTML document, creating a structured representation known as the Document Object Model (DOM).
This step sets up the basic structure of the web page, including elements and their relationships.

2. CSS Loading: The browser loads external CSS files referenced in the HTML document, as well as any embedded or inline styles.
These CSS files contain the instructions for styling the HTML elements.

3. CSS Parsing: The browser interprets the CSS code, ensuring its syntax is correct and valid.
The parsed CSS is then transformed into a structured representation known as the CSS Object Model (CSSOM), which the browser can understand.
This representation organizes the CSS rules and properties.

4. CSS Rule Matching: Once the CSS rules are matched with the HTML elements, the browser combines the DOM structure, CSS styles, and any additional rendering instructions to generate the final layout of the web page.
The browser calculates the size, position, and appearance of each element, taking into account the CSS properties specified.

5. Rendering: After matching the CSS rules with the HTML elements, the browser proceeds to render the web page.
It combines the DOM structure, CSS styles, and any additional rendering instructions to generate the final layout.
This process includes calculating the size, position, and appearance of each element, including margins, paddings, borders, and backgrounds.

6. Viewing: Once the rendering is complete, the fully styled web page is displayed on the screen, allowing users to view and interact with it.
At this stage, users can experience the visual design, interact with interactive elements, and explore the functionality provided by the web page.

In conclusion, CSS is an essential language for web developers and designers, allowing them to control the visual appearance of web pages.
It provides the ability to style HTML elements using selectors, properties, and values.

And remember that, CSS is not a programming language but focuses on styling rather than functionality.

Selecting CSS Classes Ending With The Same Name Using $= Operator

khaled Alshibani — Sat, 08 Jul 2023 15:44:40 +0000

Did you know you can select all classes that end with the same name in CSS using the powerful $= operator?

This technique is particularly useful when employing the BEM methodology.

Selecting multiple elements with the same class name in CSS can be time-consuming. Fortunately, the $= operator allows us to select all classes that end with the same name.

The $= operator enables us to select elements that have an attribute ending with a specific value. When applied to CSS classes, this means we can select all classes that end with the same name, regardless of the preceding characters.

If you're utilizing the BEM methodology, you'll likely have numerous classes that end with the same modifier name, such as card--green, alert--green, button--green, and so on. The $= operator permits you to select all classes ending with a particular string, as illustrated below:

[class$="--green"] {
  /* CSS rules */
}

In the example above, we're selecting all classes that end with --green and assigning them a green background color.

By employing the $= operator` in CSS, you can effectively select and style all classes ending with the same name, resulting in cleaner and more maintainable code.
Experiment with this technique in your projects to enhance organization and reduce redundancy.

Check out the thread on Twitter: Here

Learn about the @if control statement in SCSS

khaled Alshibani — Tue, 04 Jul 2023 10:42:10 +0000

Level up your SCSS skills with flexible styles!

Learn about the @if control statement and its powerful role in creating dynamic designs that adapt to different conditions.

Take a look at this example to easily understand the concept.⚡️

In this example, I'm defining a mixin called button-size that takes a single argument $size.
Using @if, I'm applying different font sizes based on the value of the variable $size.

And to use this mixin, simply include it in your button selector and pass a value for $size, like this:

With @if, you'll have the ability to create versatile and reusable styles that adapt seamlessly to various button sizes. Apply the button-size mixin to any button element, specifying the size as an argument.

Follow Me On Twitter