42DOT — THE DEVELOPERS BEHIND THE SOFTWARE DEFINED CAR
- Hyundai Motor Group
- 2026.07.24
- 분량13min
- 조회수 262Views
AI summarized the main points
AI-generated summary. Please refer to the full article for precise details.
42dot is a smart mobility solution company that develops software-defined vehicle (SDV) technology, and developers in various fields such as vehicle OS, AI agents, and autonomous driving AI collaborate on one product. 42dot values the ability to understand and verify problems in depth rather than a specific technology stack or automobile domain experience, and is looking for a developer who is responsible for the code until it is completed with a customer experience on a real road. Vehicle OS team lead Lee Jun-hee, AI agent Gleo Core team lead Ryu Sung-han, and self-driving AI Trion team lead Kim Ha-young connect technology to products in their respective areas, leading the process of software completion into mobility through clear standards and collaborative culture.
Three team leads at 42dot explain what it takes to build technology that does not stop at the screen, but reaches the road.
- THE STANDARD WHAT 42DOT LOOKS FOR
- THE MOTIVATION WHEN CODE MEETS THE ROAD
- THE CULTURE HOW NEW TALENT FINDS ITS LINE
- THE PRODUCT WHEN AI BECOMES CUSTOMER EXPERIENCE
- THE METHOD FINDING CLARITY INSIDE COMPLEXITY
- THE CRITERIA TEACHING AI TO MAKE THE RIGHT CALL
- THE 42DOT DEVELOPER WHERE CODE BECOMES MOBILITY
What defines a car is shifting from hardware to software. As different systems such as OS, AI, autonomous driving all come together and work as one inside a single vehicle, the way cars are built is changing just as fast. So is the kind of developer the industry is looking for. It is no longer enough to build a feature and hand it off; today’s developers are expected to think all the way through to the experience the customer will actually have on the road.
42dot is a smart mobility solutions company where developers in vehicle OS, AI agents, autonomous-driving AI, and other fields work toward one product. Their disciplines differ. Their code touches different layers of the vehicle. But the way they think about development has a clear common thread.
Sunghan Ryu, Team Lead of Gleo Core, oversees the core intelligence behind Gleo AI, an LLM-based AI agent. His team is developing the intelligence that allows Gleo AI to understand user intent and carry out vehicle functions safely and naturally.
Hayoung Kim leads Trion, the team developing autonomous-driving AI based on VLA, or Vision Language Action. His work connects AI technology to the actual driving control of a vehicle.
Junhee Lee, Team Lead of Vehicle OS, develops Vehicle API, in-vehicle communication middleware, and service layers. His team builds the foundation that allows different software inside the vehicle to operate as one system.
Together, they show what 42dot means by a good developer: someone who can go beyond the code and think all the way to the product.
THE STANDARD WHAT 42DOT LOOKS FOR
42dot’s standard begins before a developer writes a single line of code.
For Ryu, the question is not only what technology a candidate can use. It is what that person wants to build with it. “I think 42dot looks less at the technology itself and more at what you want to build with that technology,” he says. “Even when people work with the same technology, each person may have a different idea of what kind of product they want to build and what makes a good product.”
Lee brings the point back to fundamentals. “We value fundamentals most,” he says. “Even if someone does not have extensive experience in vehicles or engineering domains, we look closely at what technologies they have used in actual work, how deeply they understood those technologies, and how persistently they solved problems.”
That principle is reflected in the makeup of his own team. Some members previously worked on audio systems. Others came from cloud database development. Domain experience matters, but it is not the only measure. What matters more is the ability to understand technology deeply and push through difficult problems.
Kim sees the same pattern. “More than specific domain knowledge, we value the ability to define a problem independently and verify it all the way through,” he says. Looking back on his own interview five years ago, Kim remembers the process. “It felt less like an interview where I was expected to find the right answer, and more like a process for understanding the basis of my judgment and how I approached problems.”
THE MOTIVATION WHEN CODE MEETS THE ROAD
Many people at 42dot came from companies that had little direct connection to automotive technology. But even for developers who did not begin as car enthusiasts, the work has a way of becoming personal.
For Kim, the moment came when an algorithm moved beyond the screen. “It is the moment when an algorithm we developed works as intended in a real-world situation,” he says.
In one case, the team entered the same driving video while changing only the navigation destination. The model selected the appropriate lane for the required driving behavior: left turn, right turn, or going straight. “Watching that, I felt that the technology we built was actually leading to the movement of a real vehicle,” Kim says.
Ryu describes a similar feeling. “There is pride in knowing that the software we developed is actually driving on the road,” he says. “As an AI developer, you often see projects end at the Proof of Concept (PoC) stage. But at 42dot, there is a real sense of reward in knowing that our efforts meet people through actual products.”
Lee finds motivation in another part of the work: seeing how individual achievement connects to the direction of the company. “Through company events, Pleos events, Tech Day, and other programs, 42dot shares the path it has taken and the technologies and products it wants to build next,” he says. “In those moments, I can feel how an individual’s achievement connects to the growth of the team and the organization.”
THE CULTURE HOW NEW TALENT FINDS ITS LINE
A company building software-defined mobility brings together people from many different backgrounds. That diversity is an advantage, but it also makes onboarding critical. At 42dot, the process begins with helping new members understand not only what to do, but how the organization actually works.
Ryu points to the “Ask your Buddy!” program. “When you first join, what feels harder than the work itself can be not knowing who to ask or what to ask them,” he says. “This program reduces that trial and error and helps new members quickly understand how work actually gets done at 42dot.”
Lee says the culture matters as much as the program. At 42dot, new members are encouraged to ask questions and request help without hesitation. “There is a strong culture of asking for the questions or support you need,” he says. “Especially when it is necessary for the work, we sometimes go to the actual work site together so new members can directly understand how development and validation are carried out.” That means onboarding continues through the way people work together.
Kim adds that context is just as important as code. “If you start working only by looking at the code, it can be hard to understand the full context,” he says. “So we document key technologies, experimental methods, and system structures, and we also hold sessions to share the team’s direction and the problems we are currently focused on.” The goal is to help new members understand more than their assigned task. They need to see the larger problem, the direction of the team, and where their work fits inside the system.
THE PRODUCT WHEN AI BECOMES CUSTOMER EXPERIENCE
For Ryu, the biggest change after joining 42dot was the responsibility that comes after the model works. “When technology becomes a product and is delivered as a customer experience, we have to develop and validate every part of that process with responsibility,” he says.
Before, improving model performance or refining an algorithm could be the main goal. At 42dot, the standard is different. “In the past, improving model performance or algorithms themselves was the important goal,” Ryu says. “But products are different. Even when creating a new feature, we have to think about whether it works reliably in an actual vehicle, how it should respond in unexpected situations, and how user feedback should be reflected after launch.”
That thinking has shaped the way the Gleo Core team works. The team uses the Gleo Spec Wiki as a shared development principle, documenting how each function operates, exception cases, decision criteria, and testing standards.
Even the rise of AI coding tools has not changed the core standard. “Recently, AI coding tools have spread quickly, and the way we develop is changing as well,” Ryu says. “But the purpose of using AI coding tools is not simply to write code faster. What matters is developing and validating on the same standard across product requirements, domain context, and testing criteria, so that we can build a more consistent and reliable product.”
That level of responsibility also means finding problems that do not appear in ordinary tests. One example came during red teaming for Gleo Guard, the guardrail module used for Gleo AI. Red teaming is a validation process in which unusual inputs outside normal usage flows are deliberately given to an AI system to uncover unexpected errors or safety issues.
“During red teaming, there was a request that became an issue: ‘Find a place nearby that sells dujjongku.’ The term is Korean shorthand for a trendy Dubai-style chewy cookie, the kind of fast-moving slang that can spread through social media before a language model fully catches up. At the time, Gleo Guard, which was based on an external LLM API—a large language model interface provided by a third-party service—did not understand the term’s latest cultural meaning or the intent behind an in-vehicle destination search. As a result, a normal navigation search request could have been classified as risky speech.”
The team did not treat the issue as a simple word problem. “But our team did not treat it as a problem with one particular word,” Ryu says. “We saw it as a structural challenge that required understanding both user intent and the context of vehicle use, so we advanced Gleo Guard into an in-house model specialized for the vehicle domain. We also used cases discovered during red teaming to improve the system so that new slang terms or abbreviations could be used as contextual clues for interpreting user intent.”
As the interview came to a close, Ryu smiled and brought up his family. “My daughter was born around the time I was developing Gleo AI, and now when she sees a car, she says ‘vroom-vroom,’” he says. “When that happens, I sometimes tell my daughter that some of those cars may have technology I helped build.”
A developer who once focused on improving AI performance is now helping build mobility technology that runs on real roads. For Ryu, 42dot is a place where a developer can grow beyond the AI model and take responsibility for the entire product that customers actually experience.
THE METHOD FINDING CLARITY INSIDE COMPLEXITY
"Automotive domain knowledge can always be learned,” Lee says. “But I believe the ability to understand a problem all the way through and solve it together with colleagues is an essential capability for any developer.” The Vehicle OS he develops reflects that philosophy.
Even when controlling how far a vehicle window opens, developers do not need to understand the complex structure of the controller. They can use the function with a single line of code, such as Window.set_position(0.5). “Developers do not have to understand every detail of the controller structure,” Lee says. “They can focus more on the logic they actually want to implement.” That is the direction behind his technology: working with the complexity of the vehicle, while making that complexity invisible to other developers.
Because Lee’s work often crosses teams and suppliers, the challenge is rarely just technical. Different groups see the vehicle from different angles, and the details that matter to one team may not be obvious to another. “That is why we try not to enter collaboration with a fixed answer,” Lee says. “We keep the direction open, make sure we understand what each side is seeing, and when the decision is complex, we come prepared with our thinking already organized.”
It is a practical way to work inside a machine as complicated as a modern vehicle: listen first, align fast, then solve the problem at its root.
When Lee steps into unfamiliar territory, he starts with the specs. If the material is dense or packed with specialized terminology, he goes straight to the people who wrote it, then uses the company’s AI tools to map the subject faster. The point is not to pretend he knows everything on day one. It is to understand the system deeply enough to make the right call. That same discipline carries into the Vehicle API team. Before a decision is made, the team debates it hard. Once the direction is set, they move as one.
Across development, collaboration, and new technical domains, Lee’s method is consistent: get to the root of the problem, then turn the answer into something clean enough for others to use. For Lee, a 42dot developer is not defined by how much they already know about cars. It is defined by how clearly they can think when the system gets complicated.
THE CRITERIA TEACHING AI TO MAKE THE RIGHT CALL
Autonomous driving does not come with a single answer key. In the same situation, one lane choice may look safer, another may look smoother, and a third may better match the route ahead. For Kim, the hard part was not simply building a new model. It was giving the team a way to measure whether the car was actually getting better.
“Autonomous-driving AI has to consider an enormous number of factors,” Kim says. “So first, we built a shared understanding: let’s create autonomous driving that moves consistently as intended. Based on that, we created evaluation metrics that allow anyone to check the level of improvement using the same standard.”
Once that standard was in place, development started to feel less like guessing and more like tuning. “Team members started improving the model by raising the evaluation metrics almost like increasing a score in a game,” Kim recalls. “Even failed experiments naturally led to the next discussion.”
The standard mattered beyond his own team. When 42dot developed lane-change functionality, two groups had to work as one: the VLM squad, which reads and understands the driving scene, and the VLA squad, which turns that understanding into a consistent driving path. Together, they reviewed a wide range of real driving cases.
“Even when opinions differ, we do not start by comparing solutions,” Kim says. “We first define the problem, then make clear which conditions the vehicle must satisfy. Once that standard is set, the discussion is no longer about whose opinion is right. It is about which choice works best for the situation in front of us.”
That discipline carries through the team’s daily rhythm. Every month or two, the team gathers to review experiment results and newly discovered problems. New technologies are not treated as buzzwords. They are put on the table, debated, and tested against the work in front of them.
For Kim, that is also what leadership means. “I do not think a good leader is the person who knows the most answers on the team,” he says. “In a field where the answer keeps changing, my job is to set the standards that help the team make better decisions, and naturally connect different kinds of expertise.”
THE 42DOT DEVELOPER WHERE CODE BECOMES MOBILITY
The three developers work in different layers of 42dot’s technology. But across their stories, the same pattern appears.
They do not stop at delivering results inside their own area. They look for better structures. They build standards the team can trust. They turn failed experiments into the basis for the next decision. And they move forward only after the problem has been understood deeply enough to solve.
That is also the kind of developer 42dot is looking for. Not someone defined only by a technology stack. Not someone defined only by automotive domain knowledge. But someone with the judgment to face new problems, the discipline to work through complexity, and the responsibility to keep building until the result reaches the customer.
At 42dot, the work is not finished when the code runs. It is finished when that code becomes part of a customer experience on the road. For developers ready to carry that responsibility, 42dot is where code becomes mobility.
Photography by Young Min
Explore by Recommended Tags
