Skip to content

How to Make Your First Pull Request for Hacktoberfest

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Leaves are changing color. Pumpkin spice flavors are everywhere. Yards are decorated with skeletons, ghouls, and spiders. It must be October in the US! This means it's also time for Hacktoberfest!

What is Hacktoberfest, exactly?

Hacktoberfest is a month-long event that celebrates open source software, and encourages everyone to get involved. Whether you participate through creating pull requests for your favorite projects, opening your own project to support from others, hosting an event, or donating directly, Hacktoberfest is a way to encourage the global community to help make the world of open source software a better place.

How does it work?

To participate, sign up directly on the Hacktoberfest site. You can sign up anytime during the month of October.

Projects on GitHub or GitLab can opt in to participate by adding the hacktoberfest topic to their project. You can often find issues that will have the hacktoberfest tag added to them. This means they're open to support on solving these issues, and that it will count towards your participation!

There are only a few simple rules:

  • Pick an issue you'd like to work on from any participating project and write a solution.
  • The solution must contain text and code you wrote yourself - no copying, no bot scripts!
  • It's also important to make contributions that provide value to the project. Find ways you can contribute that actively help the project, its maintainers, and the people who use it. Documentation is a GREAT way to get involved. Or maybe there's an issue you've run across while using it that you found a solution to. The key is to add value- some fixed typos and small writing changes are great, but try to avoid simply formatting files or something like adding your name to a list. Quality over quantity!
  • Submit your solution as a pull request (PR) on the project's page.
  • Your pull request counts towards your participation when it's approved by maintainers, has been merged into the project, or is marked with the hacktoberfest-accepted label.
  • Do this 4 times in the month of October, and you're good! The first 50,000 people with 4 approved pull requests can either get a free t-shirt or have a tree planted in their name.

Is This Dot Labs Participating?

We are! This Dot has a number of repositories for resources we share with the community year-round. And this year, helping us keep these resources accurate and up to date counts towards your Hacktoberfest progress!

Here's the list of repositories we have enabled for Hacktoberfest participation:

For all of these repositories, we're looking for YOUR help in growing our library of resources, ensuring the data we have is still accurate, and helping to make these resources easier to navigate. Have a resource you love that you don't see listed? Try to check a resource out and the link no longer works? Great at organizing, and want to create a table of contents? All of this help is greatly appreciated!

Ok, but what IS a pull request?

Great question! Let's create an actual pull request on one of these repositories, and see how it's done!

What You'll Need to Get Started

First, you'll need to have an account on GitHub. If you don't already have one, you can sign up here.

You'll also probably want a code editor. There are a ton out there to choose from. However, GitHub has also added the amazing ability to run a web-based version of the popular editor VS Code, which is what we'll use!

Step 1: Find an Issue to Work On

For this walkthrough, we're going to add some excellent tech podcasts to the Podcasts repository! So we'll go visit that webpage and double check to make sure the podcasts we want to add don't already exist in the list. In our case, we're in luck, and we have a few to add that don't already exist in the project!

Step 2: Make a Copy of the Repository to Work From

To add your own work, you'll need to make a copy that's tied to your account. To do this, we'll make a fork of the repository. You'll find this button in the upper right hand corner of the page. Click that, and it will ask you where you want to make the fork. Pick the account you want to work from (often you'll only have one account, but some folks might have a separate work account as well).

Screenshot of the thisdot/tech-podcasts repo on GitHub, with the cursor pointing over the fork button in the upper right hand corner.

GitHub will do a little magic, and we'll now have our own version of the project! 🎉

Some projects will also have a mention in the README file of their project pointing to contribution guidelines. Make sure you read this if you're wanting to work on this project! It will give you any specifics for running the project and submitting the pull request when you're ready.

Step 3: Create a New Branch to Make Your Changes On

It's almost always recommended to create a branch when you want to make changes on a project. This provides the maintainers with a way to view what's different between your changes and the current, up to date project, and ensures that anything that accidentally breaks the project isn't automatically pushed live when the changes are saved.

So, let's use this web-based editor! Once GitHub has redirected you to your personal copy of the repository, simply hit the . on your keyboard, and watch the magic happen. 😎 It should load the editor directly in the browser window, and once it's done, you'll see something like this:

VSCode editor open to the CONTRIBUTING file of the repository

And we're in! Now, we want to make a branch to work off of. We can do this in VS Code by clicking on the third icon down the left-hand list, the one with three small dots and lines connecting them. If you hover over it, it will say "Source Control". Then, from the menu in that panel, we'll create a new branch for our changes.

Showing the menu open and the mouse pointer hovering over the create new branch option

You'll want to name your branch something that describes what you're working on. If the issue you've picked up has a number associated with it, be sure to include that too. The editor will open a box for you to put in the name you've picked, and will ask if you want to switch to that branch. Switch over, and we're ready to work!

Step 4: Make the Changes!

Now, let's add those changes! I'm going to add a few podcasts I enjoy in the categories they fit best with, and provide the links to them. Make sure you save the file as you go, so you don't lose your work! Any lines you've edited will be highlighted on the left hand side, so you can quickly view where your changes are.

README updated with a few new podcast titles and links, showing what new changes look like

Step 5: Commit Your Changes

Once you've made the changes you want to make, tested your code, spell-checked your text, and you're feeling good about your work, it's time to get those changes pushed onto your copy of the repository.

There's a few steps here:

  • Add the changed files to our source control list
  • Make a commit - a description of the work we did, tied to a uniqiue identifier
  • Push the changes to our copy of the repository

If you've noticed, the "Source Control" icon we clicked on earlier will now have a little circle with the number of files we've updated on it. Click into this menu again, and we can do all these steps from here!

We'll see a list of the files with changes made. Next to each file, there will be some icons on the right side. For each one, we'll want to click the little + icon, to stage those changes. If you have a lot of files to add, you can also click the + icon from the "Changes" section as well to add all of them at once. We'll now see that these files have moved from "Changes" to "Staged Changes".

Source Control menu with the mouse pointer hovered over the plus sign

Great, now our changes are staged and we're ready to write our commit! In the text input at the top of the section, write your message - a short description of the work you did. Spaces are allowed here and there's not a hard length requirement, but try to keep it fairly short and succinct so others can quickly tell what changes we made.

Dialog filled in with "added 4 new podcasts to the list"

When you're satisfied with the message, press ctrl and enter together, and the editor will automatically commit those changes to your branch!

Step 6: How to Open a PR (Pull Request)

The moment you've been waiting for: we're ready to make an official pull request to the main repository! Since we've been using GitHub's web editor, we'll create our pull request directly from the same editor! And I'll also show you what it would look like from the main repository view as well, if you work from a local editor instead. Both options will need the same information, but the visual is a little different.

GitHub will be able to guess a majority of the information for you, but there's a few things to point out.

  • You'll be selecting your branch from your copy of the repository, and sending it to a branch in the remote / original repository.
  • Double check that it has selected the right branch from your copy of the repository. You should see the name of the repository with your user name before it, and the name of the branch you want to submit.
  • Also, make sure that the original repository you're sending it to is correct. It should show the company name, followed by the project name, and the branch you want to send this to. Often, it will be "main", but sometimes projects will want you to submit your request to a different branch. Make sure you check for a contribution guide if they have one!
  • Write a title for the request. This will be shorter than the commit message we made before, and describes the work we did overall.
  • Write a description. This will be a bit more in detail on the work we did. Some projects might have checklists of things they want to make sure you did, or they might want a list of the commits you created. There's no wrong way here - just make sure if the project specifiew what they want here, that you follow that!
  • When you're ready, click create!

From the Web Editor:

There's a button at the top of the "Source Control" menu that has a straight line next to a curved arrow with a plus sign (it's the second from the left side). Click this, and it will open the menu for you to fill out.

Web Editor showing the button to click to open the pull request menu

From the Website:

You'll often see a colored bar above the repository when you've got a branch that's able to be used for a pull request. Click the green button inside of it that says "Compare & Pull Request", which will take you to the form to fill out.

GitHub website showing the pull request button

Step 7: Adjust for Feedback & Wait for Approval!

And that's it. Our pull request is created! The project maintainers can now view the changes you've made. You can see your pull request on the main repository's page, under the "Pull requests" tab.

View of our newly created pull request

Often, there might be changes they'd like you to make, or questions they want to ask about the work you've done. Be polite and honest, work diligently to make the requested changes, and ask questions if you don't understand something! When you make the changes, you can add those changes directly to your branch on your copy of the repository, and the pull request will be automatically updated. Just leave them a comment on the pull request view so they know there's new changes to review!

Once the maintainers are satisfied with your work, your pull request will be approved and merged into the project! Then you'll get to see the work you've done directly in the main repository and on the live site (if they have one). Excellent job!

You're Ready to Help Open Source Projects!

Now that you know how to create a copy of a repository, find issues to work on, complete that work, and submit the pull request for it, you're ready to complete your 4 pull requests and win a sweet t-shirt or have a tree planted!

Here's our list of repositories that are accepting contributions for Hacktoberfest again:

Feeling like you're "too new" to coding, and aren't sure what you can work on? Try filtering your searches in issues by labels like "good first issue" or "help wanted"! And also, helping with documentation is a fantastic way to start to get involved! It's often hard to keep up with documentation, but incredibly vital to helping new folks start using a tool. Figuring out how something works or updating the docs with current information is completely valid and worthwhile!

The Hacktoberfest site also has some great resources for finding issues to work on for beginners and intermediate folks!

We also have some great open source tooling that we're working on! We'd love to have you check these projects out and let us know what you think! We're always open to suggestions for how we can improve them and other tools you'd like to see: This Dot's Open Source Projects.

Good luck on your contributions! We're so excited to see what you work on, and welcome your help in providing excellent resources for the community!

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

You might also like

Introducing Vue and Angular Versions of Framework.dev  + New Landing Page cover image

Introducing Vue and Angular Versions of Framework.dev + New Landing Page

Our team created Framework.dev to help developers feel less overwhelmed when researching technical resources. We appreciate how important it can be to have a starting point when it comes to learning a new technology, or keeping up to date with the latest developments in the OSS community surrounding a stack. Previously, we started with just React, but our solution is deliberately extensible, and designed to be themed and filled in with different content for different frameworks. That's why we are happy to announce our new Vue and Angular versions for Framework.dev, a series of websites dedicated to cataloging resources to learn and develop in a given frontend framework. Our newest versions have the same features as the React version, which allows developers to search, compare, and discover libraries and resources! By adding tags and filters with a number of different attributes to all resources, and also making all the titles and descriptions searchable, we make the task of finding what you are looking for way easier. And who knows? Maybe in that search for finding out which library is the best for your needs, you ended up encountering one which you have never heard about before. Or perhaps you are just not sure which one to choose because all the options are solid. Well, we got you! With Framework.dev, you can compare libraries to look at metrics like the number of downloads, test coverage, and Github stars so you can get an idea of how popular and well-supported it is. To help you in these decisions, we've made it so you can take any set of libraries, and arrange them into a sortable table with a number of useful statistics sourced from npms. Our New Landing Page Since our plan is not to stop here, but to keep updating and making the site much bigger with more resources, frameworks and more, we decided that it was time to launch our landing page! This is where you can easily access the framework you are most interested in. Take a look at it! Help Build and Curate the Content! We are just getting started, and we know there's still a lot of content to add and cover! Framework.dev is hosted and maintained by This Dot Labs, but is a fully open-source project. No single person can keep up with how the frontend framework ecosystem constantly evolves and changes, but we might just stand a chance if we work together. Framework.dev is made for the community, and we hope community members will be inspired to enrich it. Do you have a favorite book that you think others should know about? Do you know about a cool feature that we could add? Did you encounter a bug? Then go look at our contribution guidelines and contribute to Framework.dev today!...

How to Contribute to Blitz.JS cover image

How to Contribute to Blitz.JS

This Dot Media is kicking off a brand new series of videos in 2022 to help developers learn how they can contribute code to some of the world’s most popular JavaScript frameworks and technologies. Subscribe to This Dot Media’s Youtube Channel. In the newest episode of this series, looking at the best practices for contributing to open-source web frameworks, I spoke with Brandon Bayer, Founder of Flightcontrol and Creator of Blitz.js. If you would like to check out that interview, you can see it here. What is Blitz.js? Blitz.js is a web framework built on Next.js that offers out-of-the-box features including a “Zero-API” data layer that eliminates the need for REST/GraphQL, and was modeled after Ruby on Rails. Brandon Bayer Brandon Bayer is the Founder of Flightcontrol, a full-stack deploy platform for Nest.js and Blitz.js. Additionally, he is the Creator of Blitz.js, and also offers independent software engineering consulting services. Brandon created Blitz.js after coming from the Ruby on Rails community, and wanting something similar with “batteries included” in the JavaScript ecosystem. What to Know Before You Get Started Developers who are interested in contributing to Blitz.js should visit the Blitz.js repository, read the documentation to learn how to contribute, and discover more about the community! *Quick Tips!* - Check out Blitz Project Dashboard on Github, and view the “ready to work on” column for issues that have been unassigned and need help! - Join the Discord and get involved in the community! The Best Way to Get Started Those who are just getting started with contributing to Blitz.js can help with code reviews, documentation, and addressing issues in the “ready to work on” column in the Blitz.js repository. If you are interested in working on a particular issue, you can comment on it, it will be assigned to you, and then you can start working on it. *Quick Tips!* - To find ideal issues for new contributors, look for the tags “good first issue” and “second first issue”. - If you are using Blitz and you find a bug, you are encouraged to bring that to the attention of maintainers. - If you are looking to build relationships and get involved on a regular basis, you can become a maintainer. There are different levels of maintainers like L1, L2, and Core Team. On the Blitzjs.com documentation page, there are descriptions on what it means to be what type of maintainer. How to Submit a PR Once you submit a PR, someone should review it within a few days, possibly request that you make changes, and then it may be merged. Sometimes PRs might be on hold until there is a release, but usually they are merged immediately. *Quick Tip!* The Blitz.js team doesn't have a lot of people reviewing PRs, so contributors are welcome to look at PRs and comment to make suggestions! What About Attending Core Team Meetings? Currently, the Core Team does not offer contributor meetings. However, earlier in the framework’s history, the Core Team hosted meetings that were recorded and shared on the Blitz.js Youtube channel if you would like to review old meetings. __Are There Ways to Contribute to the Ecosystem Without Coding? Those interested in contributing to the Blitz.js ecosystem without contributing code can: - Help triage issues when new issues come through - if there is a bug, see if you can reproduce it, or ask the original person for details. - Speaking at meetups and conferences. - Making courses and writing books. - Translating the docs into other written languages. - Contribute anything that can spread the word about Blitz.js! Blitz.js Success Stories Aleksandra, who is a TypeScript expert, started using and contributing to Blitz.js. Whenever there was a particularly challenging problem with Blitz in TypeScript, Brandon Bayer would go to her and ask for help. That led to her working full time for Blitz.js! Level 2 maintainers Simon and Juan have been successful too. Simon, who has only recently gotten started with the project, has been super helpful in building items like SuperJSON. Juan got started through translating docs, and he’s been working as a Maintainer ever since. Ready to Begin? You can find the Blitz.js Github repository here....

How to Create a Custom Login Command with Cypress, React, & Auth0 cover image

How to Create a Custom Login Command with Cypress, React, & Auth0

Auth0 is a tool for handling user authentication and account management. Cypress is a tool for writing end to end tests for your application. Getting these two technologies to work together can have a few gotchas, especially if your application is set up to have the end to end tests in a separate folder from your frontend code. Today, we’ll go over the steps you’ll need to implement so you can have a custom Cypress command to log in a user, and also let your front end code continue to work safely! --- Setup For this setup, we're making the choice to keep our end to end tests in one folder, and our front end code in a sibling folder. You don't have to do it this way. It's just the choice we've made for this project. So our folder setup has two root level folders, "cypress" and "app": ` --- React Adjustments Auth0 provides a default login form for you to use. We’ll focus on the fact that the forms use web workers to store the user’s access tokens in memory. This helps them keep that access token more secure from attackers. This is important to note for Cypress. But because Cypress does not have a way to interact with that web worker. So we need to be able to detect when our application is running the site through Cypress so we can adjust how we get the access token. We’ll need to update the way our Auth0 form saves that token based on if our app is running normally, or if it’s running through Cypress. To do this, we can add a check to the cacheLocation prop in our Auth0Provider field that wraps around our root app component. app/index.ts ` > Important note if you’re using TypeScript: > If your project is using TypeScript, there will be two more small changes you might need to make. > First, your editor may be yelling at you that it doesn’t know what Cypress means, or that it doesn’t exist on the window interface. So you can make a type file to solve this. src/types/globals.d.ts ` > Then, in the root level tsconfig file, we need to add an option to the compilerOptions section so it knows to look for this file we just made and use it. Then your editor should be happy! :) app/tsconfig.ts ` And that’s all your front end code should need to work! It’ll continue to work as expected when running your app locally or in production. But now when you run your Cypress tests, it’ll store that access token in local storage instead, so we can make use of that within our tests. --- Cypress Adjustments Now we can make our custom login command! Having a custom command for something like logging in a user that might need to be repeated before each step is super helpful. It makes it faster for your tests to get started, and doesn’t need to rely on the exact state of your UI so any UI changes you might make won’t affect this command. There’s a few different things we’ll need to handle here: - Writing the custom command itself - Making an e2e file where we’ll set up this command to run before each test - Updating the Cypress config file to know about the environment variables we’ll need - If you’re using TypeScript, you’ll also need to make a separate “namespace” file and an index file to pull all the pieces together. We’ll start with the meat of the project: making that custom command! I’ll share the whole command first. Then we’ll walk through the different sections individually to cover what’s going on with each part. The Custom Command Cypress automatically sets up a support folder for you, so you’ll likely already find a commands file in there. This will go in that file. If you don’t have it, you can create it! cypress/support/commands.ts ` The first piece to note is line 2. Cypress.Commands.add('loginWithAuth0', (username, password) => {... This is what actually tells Cypress “hey, this is a command you can use”. The name can be anything you want. I’m using “loginWithAuth0”, but you could call it “login” or “kitty” or whatever makes the most sense for your project. Just make sure you know what it means! :) Lines 3-6 are setting our the environment variables that the Auth0 call will use. Then, on line 8, we use Cypress to make the actual request to Auth0 that allows us to log in. For this use case, we’re choosing to login with a username and password, so we tell the call that we’re using the “password” type and send all the necessary environment variables for the call to work. (You can find info on what these values should be from the Auth0 docs.) Then, on lines 20 and 21, we’re starting to deal with the response we get back. If the call was successful, this should contain the information on the test user we just signed in and the access token we need for them. So we extract those values from the body of the response so we can use them. On line 22, we again use Cypress to get the browser’s window, and let us store the user access token. We'll use localStorage for this as seen on line 23. Important note here! Pay extra special attention to the way the string is set up that we’re storing in localStorage on line 24! Auth0 needs the access token to be stored in this specific manner. This is the only way it will find our token! So make sure yours is set up the same way. The rest of the code here is taking the information we got from the Auth0 call and adding it to our new localStorage value. You’ll see that on line 35 we’re parsing the user information so we have access to that, and then setting an expiration on line 40 so the token won’t last forever. And that’s it - our command is set up! Now on to the rest of the things we need to set up so we can actually use it. :) Supporting Files If you have commands that should be run before every test call, you can create an e2e file in your support folder. These are your global imports and functions that will apply to all of your Cypress test files. Here we’ll import our custom commands file and actually call our new command in a beforeEach hook, passing in the test username and password we want to use. cypress/support/e2e.ts ` > TypeScript Note: > To get the typings to work properly for your custom commands, you’ll need to do two things. > First, you’ll want to make a new file called namespace in your “support” folder. Then, you’ll want to declare the Cypress namespace in there, and set up a line for your new custom command so Cypress knows the type for it. (If you originally edited the default Cypress commands file, you’ll also want to go to the bottom of that file and remove the namespace section from it - this is replacing that.) ` > Then in your support folder, create an “index.ts” file and add your commands and namespace imports to it. ` > That should clear up any TypeScript related warnings in your files! The final piece is updating our Cypress configuration file. We need to add all the environment variables we need in here so Cypress is aware of them and we don’t have them hard coded in our files. cypress.config.ts ` Wrap Up With that in place, you should be good to go! Whenever you run your Cypress tests now, you should see that a user is automatically logged in for you so you start on the first page of your app. We hope this helps! If you run into any issues or have questions on anything, please feel free to reach out to us. Leave a comment on this post or ask in our Discord. We’ll be happy to help!...

What Sets the Best Autonomous Coding Agents Apart? cover image

What Sets the Best Autonomous Coding Agents Apart?

Must-have Features of Coding Agents Autonomous coding agents are no longer experimental, they are becoming an integral part of modern development workflows, redefining how software is built and maintained. As models become more capable, agents have become easier to produce, leading to an explosion of options with varying depth and utility. Drawing insights from our experience using many agents, let's delve into the features that you'll absolutely want to get the best results. 1. Customizable System Prompts Custom agent modes, or roles, allow engineers to tailor the outputs to the desired results of their task. For instance, an agent can be set to operate in a "planning mode" focused on outlining development steps and gathering requirements, a "coding mode" optimized for generating and testing code, or a "documentation mode" emphasizing clarity and completeness of written artifacts. You might start with the off-the-shelf planning prompt, but you'll quickly want your own tailored version. Regardless of which modes are included out of the box, the ability to customize and extend them is critical. Agents must adapt to your unique workflows and prioritize what's important to your project. Without this flexibility, even well-designed defaults can fall short in real-world use. Engineers have preferences, and projects contain existing work. The best agents offer ways to communicate these preferences and decisions effectively. For example, 'pnpm' instead of 'npm' for package management, requiring the agent to seek root causes rather than offer temporary workarounds, or mandating that tests and linting must pass before a task is marked complete. Rules are a layer of control to accomplish this. Rules reinforce technical standards but also shape agent behavior to reflect project priorities and cultural norms. They inform the agent across contexts, think constraints, preferences, or directives that apply regardless of the task. Rules can encode things like style guidelines, risk tolerances, or communication boundaries. By shaping how the agent reasons and responds, rules ensure consistent alignment with desired outcomes. Roo code is an agent that makes great use of custom modes, and rules are ubiquitous across coding agents. These features form a meta-agent framework that allows engineers to construct the most effective agent for their unique project and workflow details. 2. Usage-based Pricing The best agents provide as much relevant information as possible to the model. They give transparency and control over what information is sent. This allows engineers to leverage their knowledge of the project to improve results. Being liberal with relevant information to the models is more expensive however, it also significantly improves results. The pricing model of some agents prioritizes fixed, predictable costs that include model fees. This creates an incentive to minimize the amount of information sent to the model in order to control costs. To get the most out of these tools, you’ve got to get the most out of models, which typically implies usage-based pricing. 3. Autonomous Workflows The way we accomplish work has phases. For example, creating tests and then making them pass, creating diagrams or plans, or reviewing work before submitting PRs. The best agents have mechanisms to facilitate these phases in an autonomous way. For the best results, each phase should have full use of a context window without watering down the main session's context. This should leverage your custom modes, which excel at each phase of your workflow. 4. Working in the Background The best agents are more effective at producing desired results and thus are able to be more autonomous. As agents become more autonomous, the ability to work in the background or work on multiple tasks at once becomes increasingly necessary to unlock their full potential. Agents that leverage local or cloud containers to perform work independently of IDEs or working copies on an engineer's machine further increase their utility. This allows engineers to focus on drafting plans and reviewing proposed changes, ultimately to work toward managing multiple tasks at once, overseeing their agent-powered workflows as if guiding a team. 5. Integrations with your Tools The Model Context Protocol (MCP) serves as a standardized interface, allowing agents to interact with your tools and data sources. The best agents seamlessly integrate with the platforms that engineers rely on, such as Confluence for documentation, Jira for tasks, and GitHub for source control and pull requests. These integrations ensure the agent can participate meaningfully across the full software development lifecycle. 6. Support for Multiple Model Providers Reliance on a single AI provider can be limiting. Top-tier agents support multiple providers, allowing teams to choose the best models for specific tasks. This flexibility enhances performance, the ability to use the latest and greatest, and also safeguards against potential downtimes or vendor-specific issues. Final Thoughts Selecting the right autonomous coding agent is a strategic decision. By prioritizing the features mentioned, technology leaders can adopt agents that can be tuned for their team's success. Tuning agents to projects and teams takes time, as does configuring the plumbing to integrate well with other systems. However, unlocking massive productivity gains is worth the squeeze. Models will become better and better, and the best agents capitalize on these improvements with little to no added effort. Set your organization and teams up to tap into the power of AI-enhanced engineering, and be more effective and more competitive....

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Prefer email? hi@thisdot.co