Working at xAI involves high stakes and rapid execution. A colleague named Tyler once won a Cybertruck from Elon Musk by successfully starting a training run on GPUs within a 24 hour deadline. This pace defines the culture. On his first day, Sulaiman received a laptop and a badge but no specific team or instructions. He jumped into working on the AskRock integrations with X because he saw an opportunity to help.

If I have a good idea, I can usually go and implement it that same day and show it to Elon or whoever and get an answer. No one tells me no.

The leverage available to individual engineers is immense. The value per code commit to the main repository is estimated at about 2.5 million dollars. By completing five commits in a single day, an engineer can provide over 12 million dollars in value. This environment allows for immediate implementation and direct feedback loops with leadership.

Engineering at xAI operates without artificial blockers. Sulaiman explains that the company focuses on fundamental physical limits rather than traditional software schedules. Due dates do not exist because the goal is always to have things finished yesterday. This approach requires working backward from future bottlenecks that Elon identifies years in advance.

We don't really have due dates. It's always yesterday. There's no blockers for anything, at least nothing artificial. The whole Elon thing about going down to the root, the fundamental, whatever the physical thing is, we get there pretty quick.

The company functions as much as a hardware firm as a software one. While most tech companies rely on cloud providers like Amazon or Google, xAI builds its own infrastructure. This allows them to set up hardware racks and start training models within hours rather than weeks. Sulaiman notes that in the current AI landscape, relying on external capacity is a losing strategy. The only path to winning is building everything in-house.

In most cases, in the last 10 years you abstract this away and let Amazon or Google take care of this. But you can't have that be the case and win in AI now. So the only solution is to die or build it yourself.

This vertical integration allows for rapid iteration. Software teams can often improve the performance of existing stacks by 2x to 8x by removing unnecessary overhead. They are currently producing new model iterations daily, which is rare for pre-training cycles. By ignoring conventional wisdom about what is possible, the team consistently shreds typical development timelines.

Sulaiman joined xAI after being recruited by co-founder Greg Yang. He was working on his own startup at the time and initially thought the recruitment email was spam. The onboarding process was unconventional and highly autonomous. Sulaiman received a laptop and a badge but no specific instructions or team assignment. He spent his first days finding projects to help with, eventually working on the integration of Grok with the X platform.

My first day they just gave me a laptop and a badge. I was like, okay, now what? I did not even have a desk assigned to me. I just sat at random people's desks that were not there that day. I could point to whoever built any specific part of xAI right from my desk.

The culture at xAI emphasizes speed and the assumption of abundant resources. The company completed the Colossus data center in 122 days. This pace allows the team to plan for future models like Grok 4 and 5 well in advance. Despite having a much smaller engineering staff than other labs, the high utilization rate and parallel training runs allow for rapid iteration on both models and products.

A significant technical goal involves deploying millions of human emulators. To solve the massive hardware requirement, xAI is exploring the use of existing Tesla vehicle computers. Since millions of Teslas sit idle for most of the day while plugged into power and networking, they represent a massive, untapped compute resource. This software-based solution avoids the need for new physical infrastructure.

There are 4 million Tesla cars in North America alone. We can potentially pay owners to lease time off their car and let us run a human emulator right on it. They get their lease paid for and we get a full human emulator we can put to work.

Digital emulators aim to automate any task a human currently performs on a computer. While physical robots like Optimus handle manual labor, these emulators focus on digital inputs like keyboard and mouse movements. This approach allows the technology to be deployed in any situation where a human works without requiring software companies to change their systems. Sulaiman notes that once the initial infrastructure is built, scaling from one thousand emulators to a million is not the primary challenge.

With Optimus you are taking any physical task a human can do and allowing a robot to do it automatically at a fraction of the cost. With uptime, we are doing the same with anything that a human does digitally. So anything where they need to digitally input keyboard and mouse inputs, we just emulate what the human is doing directly.

The management style focuses on moving quickly from one problem to the next to resolve blockers immediately. Sulaiman describes how a single phone call can often solve technical issues that would typically take weeks of back and forth between companies. Leadership frequently asks how to make processes faster at the end of every meeting. This culture encourages employees to take initiative without waiting for permission or sync meetings. If a team member proposes a good idea, the standard response is often a question about why it is not already finished.

Ownership within the organization is fluid and based on performance rather than formal titles. Sulaiman explains that if someone helps with a project and iterates quickly, they effectively own that part of the technology. People often work on multiple projects at once based on which one is most pressing. Formal HR systems rarely reflect these shifting roles because the pace of work moves faster than the administrative updates.

If you have any particular experience or can iterate on something very quickly within days you own that component. There is no formal anything officially on our HR software. My journey has been showing up and hopping from project to project by whoever asked for my help.

Sulaiman's journey began with backend reliability and building a desktop suite before moving to the iOS team for the Imagine rollout. Despite a massive user base, the iOS team consisted of only three people. This period demanded an intense workload and rapid iteration cycles where the team gathered feedback nightly and implemented fixes by the next morning.

The Imagine rollout was a really good push because we had this 24 hour iteration cycle. We would push out that night, and in the morning, we would have all the feedback. We would immediately knock out all the bugs and implement the new stuff people were asking for.

The engineering environment is characterized by high stakes and fast paced rewards. In one instance, a team member named Tyler bet he could get a training run active on new GPU racks within 24 hours. He succeeded and received a Cybertruck for his efforts. Managing power requirements for massive data centers involves complex coordination with local power companies. To avoid impacting the public grid, the team uses over 80 mobile generators and massive battery packs. Batteries are useful because they can respond to millisecond level power fluctuations from GPUs much faster than physical generators.

With a generator, you are asking a physical thing to speed up or slow down. That is obviously going to take a certain amount of time. Batteries can react to the load much faster.

Permitting for land is often a major hurdle for rapid development. To bypass delays, the lease for certain data centers was filed as a temporary permit. This utilizes a special exception in local and state government intended for events like carnivals. Sulaiman explains that this was the fastest way to get things done, allowing internal planning to move at an incredible pace.

XAI is actually just a carnival company. It is a carnival currently. And so that was the way to get done quickly. It was done in 122 days for internal planning.

Planning for massive scale involves working backward from the highest leverage goals. Instead of starting with physical requirements, the team focuses on economic outcomes. They determine what revenue targets they want to hit and then figure out the physical and software rollouts required to get there. The physical requirements are usually the final piece of the puzzle rather than the starting point.

We try very hard to work backwards from what is the highest leveraged thing we can be doing and then we determine the physical requirements later. If we want to get to $100 billion in revenue, what are the highest leverage things we can do from an economic perspective?

The engineering process often mirrors the SpaceX algorithm of deleting steps. Sulaiman mentions that they frequently remove special cases or requirements to simplify the system, only adding them back if they prove essential. For instance, they recently removed a special case for multiple encoders but found it was necessary for 5K resolution displays. This forced them to add the requirement back into the stack after identifying the limit.

XAI operates with a culture of extreme leverage. The value per employee is remarkably high. By calculating the company valuation against activity in the main repository, each code commit represents roughly 2.5 million dollars in value. This high-leverage environment allows a small group of people to accomplish more than traditional large teams could achieve in the past. Sulaiman explains that working with high-quality people and specialized internal tools makes it possible to get much more done with less effort.

Right now we are at about 2.5 million dollars per commit to the main repo. And I did five today. So you added like 12.5 million of value. Light day. It was a good day. The levers are extremely strong. You can get a lot done with a lot less effort and time than you used to be able to.

This efficiency is driven by high ownership and the use of AI agents. A single engineer can rebuild core production APIs by managing 20 agents. Because the team remains small, individuals own massive sections of the product. The hiring process reflects this need for autonomy and skill. Sulaiman conducts dozens of interviews a week looking for a specific mindset. He uses a deceptively simple computer vision problem to filter for candidates who do not overthink things.

Simplicity is a requirement when deploying across diverse hardware and operating systems. Without simple solutions, the codebase would become unmanageable. This is especially true when using AI for coding. While AI is a powerful force multiplier, it often generates hundreds of lines of code when a ten-line solution would be more effective. Finding the shorter, more elegant path is the primary goal for the team.

An AI will happily churn out 200 lines when a 10 line solution will do and probably do better. You have to look for that. I want people and I look and actively hire for people who can find the 10 line solution first. We are totally fine with people using AI to code things. You should use that as a force multiplier.

Sulaiman looks for force multipliers who are willing to challenge requirements. He adopts a hiring strategy from Chester at Joe's Forge by intentionally including impossible or incorrect tasks in coding challenges. He wants to see if a candidate has the confidence to point out a mistake rather than just following orders. If a candidate does not flag the error, Sulaiman does not hire them.

He throws in usually an incorrect requirement or a question or an impossible line in his challenges for people. He expects people to come back and say like, hey, this is wrong, this is not possible, you made a mistake. And if he doesn't, then he doesn't hire them.

Learning a new codebase quickly requires reading the code by hand and using the go to definition tool. In fast moving environments where multiple versions exist at once, talking to teammates is the best way to find the current path. The team culture is helpful and collaborative. People are smart but kind. This is necessary because the pace is too fast to maintain traditional documentation.

Sulaiman is exploring ways to use Grok to automatically generate documentation as the team builds. Having unlimited access to powerful AI models allows for a level of experimentation that is impossible for most startups. They can afford to try many ideas and fail frequently because they do not have to pay for expensive API credits. This ability to fail for free leads to more experiments and more eventual successes.

We have unlimited access to very smart AI, because then we can try a bunch of stupid things, see if it works, which otherwise at a startup would cost you maybe like 100k or a million dollars in credits. But we do it for free. So experimentation, you can fail on a lot of things. As a result, more experiments are tried, more succeed.

Sulaiman explains that maximizing the number of experiments often involves running multiple tests simultaneously. This happens even when waiting for prerequisites like new hardware or training data. If a specific result is needed immediately for revenue or customer needs, the team deploys what is available now while preparing for the next shift in a few weeks. This approach is standard at Macrohard.

When faced with aggressive deadlines that seem impossible, the team first looks at the assumptions backing the original estimate. By identifying which factors are impacting the timeline most and changing those assumptions, they often see a massive improvement in speed.

The rest of the time is dedicated to getting it done in that time. Frequently the estimated time to get something done is based on some set of assumptions. Once you get this timeline that is half or one tenth of what you would have otherwise done, you look at the assumptions and say, how much is this impacting my timeline? Then you knock it out or you change it. Suddenly you get a 2x improvement.

Aggressive timelines create a sense of urgency that forces efficiency. Sulaiman notes that even if a goal is not met exactly on time, setting a one month deadline for a year long project might result in finishing in two months. This is still much faster than the original estimate. At Macrohard, the financial stakes are high. Sulaiman can quickly calculate the massive revenue gains or losses tied to just a few days of acceleration or delay.

One of the most impactful decisions made at the company was choosing to focus on speed. While other labs prioritize building bigger models and increasing reasoning capabilities, this approach targets a model that is significantly faster than a human. This strategic choice is similar to the logic behind full self driving. People are willing to pay for a computer that completes a task in ten seconds rather than waiting ten minutes for a process they could have done themselves in five.

The approach in other labs has been let's do more reasoning and build a bigger model. That decision put us in totally the opposite track of what everyone else is doing. Everything that we're doing really is downstream of that.

Sulaiman shares that the recruitment philosophy also differs from the industry standard. Instead of seeking specific AI researchers, the focus is on hiring engineers who are fundamentally problem solvers. This broad definition allows people from unique backgrounds to join and contribute. Keeping the criteria wide ensures that the best talent can find a path to the company and help accelerate progress.

The day to day work environment is defined by a lack of bureaucracy. Even with a growing team, the culture allows for rapid experimentation. An engineer can have an idea and implement it on the same day. Feedback comes quickly, whether from evaluation metrics or direct input from leadership like Elon. This speed of execution is rare in larger organizations.

If I have a good idea, I can usually go and implement it that same day and show it off. We will get an answer usually that same day as to whether or not that was the right move. There is no deliberation. There is no waiting for any bureaucracy.

A flat organizational structure is more efficient because it prioritizes bottom up solutions over top down directives. In this environment, there are essentially only three layers of management: individual contributors, co-founders or new managers, and Elon Musk. Because managers often have over a hundred people reporting to them, they cannot provide constant top down instructions. Instead, engineers identify problems and build their own solutions. They only seek feedback or updates if necessary. This design ensures that the company is filled with builders rather than just people who manage others.

There is basically only three layers of management. There is ICs, there is the co-founders and some of the new managers, and then Elon, and that is it. And so because there is so many reports to the managers now, nothing really comes from them top down. We will usually come up with a solution.

The company maintains a strict focus on engineering. Sulaiman remembers meeting someone on the sales team who was also training models. This is common across the organization. Almost everyone is an engineer in some capacity, even those in enterprise deals or sales. This technical foundation allows every employee to contribute directly to the machine they are building.

Reducing the number of layers in a company also prevents information loss. Language is naturally lossy compared to the thoughts in a person's brain. Every time a message moves from a customer to a salesperson, then to a manager, and finally to an engineer, a huge amount of information is lost through compression. By removing those middle layers, the engineer can interact directly with the customer and solve problems without the message being distorted.

The less layers you have, the less information is lost. There is less compression because you have to communicate less times and language is lossy compared to what is going on in your brain. If you can cut as many layers as possible, then you have only got one compression step.

The speed at xAI is driven by a unique lack of boundaries between teams. Unlike traditional large companies, there is significant fuzziness regarding what everyone is responsible for. This allows employees to step outside their specific roles to solve problems across the entire infrastructure. If someone needs to fix a component they do not own, they are trusted to make the change and merge it immediately without facing a strict regiment.

Everyone is allowed to update everything, and there are some checks for dangerous things. But largely you are trusted to do the right thing and do it right, which is really cool.

This rapid pace involves a process of trial and error where infrastructure is frequently deleted to see if it is truly necessary. While things are often removed and then rolled back later if someone needs them, this rarely leads to irreversible destruction. In some cases, a piece of infrastructure might be rebuilt three times by the time a project is ready for deployment. This iterative approach ensures that only essential systems remain in place.

Small engineering teams are more effective because adding more people often slows down progress. A task meant for one person can take twice as long if assigned to two. This principle applies across various skills but is especially relevant in modern software development.

The more people you have doing, I definitely say a job for one person done by two will take twice as long.

Since developers no longer need to write as much code manually, they can focus on being decision makers and architects. Sulaiman notes that everyone has the capacity to be an architect now because fewer hands are required for the actual labor. A single brain can accomplish much more than before.

Before joining his current mission, Sulaiman attempted to start several companies and worked on various projects. His decision to shift focus was driven by a deep-seated admiration for ambitious aerospace achievements. He describes himself as being Elon pilled, viewing Elon Musk as a personal hero since childhood.

I went out to the Starship launch, which was so worth it. It was the first one they caught. It was definitely the coolest thing I've ever seen. So being part of anything remotely related to that sounds awesome to me.

Watching the first Falcon landings and seeing a Starship caught in mid-air were transformative experiences for Sulaiman. These milestones solidified his desire to be part of work that carries a similar level of impact and excitement. For Sulaiman, the chance to contribute to a project related to these grand engineering feats was too compelling to pass up.

Sulaiman chose to work at xAI because it is the smallest and newest company among Elon Musk's ventures. He believes smaller teams offer individuals more leverage. In a smaller organization, each person represents a larger percentage of the total workforce. This allows for a greater impact on implementation and seeing results quickly.

I think my assumption is where you can have the most leverage and change as an individual person, because proportionately, you're a much larger percentage of the company than you would be at these other companies. Just the proportional change of weight to implementation, to seeing the results. It is very quick.

Sulaiman initially thought building things independently would be faster. However, he found that working within the xAI team is actually more efficient. The company provides a foundational groundwork and a team that has already handled many preliminary steps. There are few bureaucratic obstacles to overcome and very few people saying no to new experiments.

Sulaiman and his team have started testing human emulators internally as virtual employees. Sometimes these AI coworkers are so convincing that other staff members do not realize they are digital. This leads to humorous situations where a virtual employee invites a colleague to their physical desk. When the colleague arrives, they find nothing but an empty space. People even ping Sulaiman to ask if a specific person on the org chart is out for the day, not realizing the name refers to an AI.

The virtual employee is like, yeah, sure, come to my desk. And they go there and there's nothing there.

A significant challenge in building these emulators is capturing how humans actually work. When interviewed, people often leave out dozens of steps because they perform them on autopilot. They assume these actions are common sense or do not notice them at all. This is similar to driving a car for an hour and not remembering the details of the trip. To fix this, the team must watch humans work in real time to identify the missing pieces of the workflow.

The ultimate goal is to automate repetitive digital tasks so humans can focus on creative work. Customer support is a major area for this technology. AI can take messy, freeform input from a customer and translate it into a standard workflow. This acts as a massive compression step. Just as AI allows coders to describe a function in three words rather than writing it manually, virtual employees can handle the repetitive digital chores that currently drain human energy.

I don't need to write the same implementation 20 different times anymore. I can describe it in three words and it's done. It's a huge compression step. And this is the same thing basically, but for arbitrary digital workflows.

AI models are showing a surprising ability to handle tasks they were never trained for. Sulaiman mentions that these models can generalize better than expected, performing flawlessly on new cases. This efficiency mirrors the approach used for full self-driving technology. Smaller models allow the team to iterate much faster. A process that once took four weeks can now happen in a single week. This speed allows for dozens of different experiments to run at the same time.

Meetings with Elon are usually simple. Successful meetings involve very little feedback or a simple thumbs up to keep going. Feedback generally occurs at two extremes: high-level product direction or low-level technical details like compute efficiency. Opinions are not enough to change a direction. Every suggestion must be backed by an experiment and hard data.

He is open to being proven wrong. But it has to be proof. It has to be like let's try it and see what the results are. It cannot be just someone's opinion. There has to be an experiment done which has led to some surprising results sometimes and we go with it.

Creating a truthful AI is a significant challenge because the internet often lacks ground truth. The team tries to drill down to fundamental principles. This creates a difficult cycle where you need to know the truth to evaluate if the AI is being truthful. Evaluation methods are more important than the specific data sets used for training. The focus is on the art of avoiding a model that simply copies and pastes information from its training data.

The team has been operating in a war room for several months to maintain a high pace. When errors are identified, the response is immediate regardless of the time. Sulaiman explains that making a mistake once is acceptable, but repeating it is a major issue. The intensity is so high that the team eventually outgrew their original office and moved their entire operation into a gym to keep everyone together.

Generally making mistakes once is okay, but making the same mistake twice is a big problem.

There are rare moments in high-stakes technical work where time seems to compress. Sulaiman describes a night where the team achieved results in a single session that would normally take weeks of effort. He references a sentiment shared by Igor, a co-founder at xAI, that some nights feel like months of progress happening all at once. These surges are intense and demanding but allow for massive leaps forward in a very short window.

There are some months where only a few days go by and then there are some nights where months happen. That was one of them for sure. I think we would have gotten to the technical result in a few weeks anyway, but doing it in one night was a huge push.

Sulaiman also reflects on the personal significance of working alongside Igor. He recalls trying to replicate Igor's StarCraft AI research while in high school, long before they became colleagues. This experience highlights the rapid transition from a student of the field to a peer working on cutting-edge projects.

During model training surges, the office often becomes a temporary home for many team members. These intense periods require people to stay overnight to monitor progress and handle issues as they arise. To accommodate this, the workspace features dedicated sleeping pods and bunk beds. While the bunk beds are a newer and less comfortable addition, they provide a necessary place to rest when the work schedule becomes relentless.

The surges for the models usually result in a lot of people staying in overnight. We have some sleeping pods and we have some bunk beds now, too, which are less nice, but they exist.

A viral photo once circulated showing a large number of tents set up inside the office. Sulaiman mentions that while tents are available for use, it is rare to see so many of them occupied at one time. This setup reflects the high-intensity culture and the dedication required during critical phases of development.

Sulaiman started tinkering with programming and manufacturing at a young age. He learned to code at 11 and began making money by writing game scripts. This led to his first encounter with online payments, which felt strange and exciting. He used that money to buy parts for a 3D printer from Alibaba. The process was difficult. Sulaiman built a RepRap printer, which is a machine designed to print its own components. During the assembly, a copper wire from a power supply went deep into his thumb. Because it was 3 am on a school night, he could not go to the hospital. He ended up cutting the wire and letting it work its way out over several weeks.

I was very obsessed with it, and so I took one of their parts list and bought everything from Alibaba. A month later things came in and I assembled it all one night, which went poorly, actually. When I was unbundling the copper cable for the power supply, all the copper windings came loose and frayed everywhere and one went like two inches into my thumb.

Once the printer worked, Sulaiman launched a fidget spinner business. He ran a small factory in his bedroom and used school friends as distributors. He was eventually shut down by his school for violating food vendor licenses. This experience gave him a healthy disrespect for authority. He believes that unconventional outcomes require an unconventional path, as institutions naturally enforce convention. Creativity and interesting outcomes usually come from free-spirited individuals rather than large organizations.

The world is built on the passion projects of individuals. For example, most of the world's zippers are made by just a few companies. These are mechanical miracles that exist because a few people spent decades perfecting them. Our global supply chain often depends on these niche, highly specific manufacturers. Sulaiman also built a liquid fuel rocket engine in about four weeks. Unlike software, there is no open source code to download for rocket design. He had to study textbooks to understand material properties and chemical reactions. Designing the injector was the most challenging part, taking up half of his development time.

Sulaiman faced a difficult challenge building a rocket engine injector. He spent several weeks on the project and ordered expedited parts from China to meet a tight deadline. With a trip home for Thanksgiving approaching, he had to decide whether to test the engine immediately or wait two weeks. He chose to work through the day and fire the engine that night.

I was like, okay, either I build it and fire it tonight, or I do this in two weeks. And I'm like, I'm not going to do this in two weeks. I'm going to do this right now. So I drank a lot of coffee in the morning and then spent the whole day hacking away at aluminum extrusions and built out the test frame.

The testing process became dangerous due to a missing equipment piece. Sulaiman intended to fire the engine remotely, but the necessary power supply had not arrived. He was forced to use a short USB cable from his laptop to power the onboard computer. This required him to stand only six feet away from the engine during the test despite the high risk of an explosion.

I didn't have a long enough USB cable. The longest one I had was six foot. So I had to stand right next to it and light it off. And I was like, there is a 30% chance that this thing explodes or launches fire everywhere.

The injector design caused overpressure events which sprayed unburnt ethanol fuel. Some of the fuel landed on Sulaiman's jacket and caught fire. He considers the burnt jacket a trophy from the successful if risky test.