Técnicas

Las organizaciones adoptan activamente pensamiento de producto de datos como práctica estándar para gestionar activos de datos. Este enfoque trata los datos como un producto con su propio ciclo de vida, estándares de calidad y un enfoque en conocer las necesidades del consumidor. Ahora lo recomendamos como la elección predeterminada para la gestión de datos, independientemente de si las organizaciones eligen arquitecturas como data mesh o lakehouse.

Enfatizamos la orientación al consumidor en el pensamiento de producto de datos para impulsar un mayor adopción y generación de valor. Esto significa diseñar productos de datos trabajando desde los casos de uso hacia atrás. También nos enfocamos en capturar y gestionar tanto metadatos relevantes del negocio como metadatos técnicos usando catálogos de datos modernos como DataHub, Collibra, Atlan e Informatica. Estas prácticas mejoran el descubrimiento y usabilidad de los datos. Adicionalmente, aplicamos el pensamiento de producto de datos para escalar iniciativas de IA y crear datos listos para IA. Este enfoque incluye una gestión integral del ciclo de vida, asegurando que los datos no solo estén bien gobernados y sean de alta calidad, sino que también se retiren en cumplimiento con los requisitos legales y regulatorios cuando ya no sean necesarios.

Fuzz testing , o simplemente fuzzing, es una técnica de pruebas que ha existido durante mucho tiempo, pero sigue siendo una de las técnicas menos conocidas. El objetivo es proporcionar a un sistema de software todo tipo de entradas inválidas y observar su comportamiento. Para un endpoint HTTP, por ejemplo, las solicitudes incorrectas deberían resultar en errores 4xx, pero el fuzz testing a menudo provoca errores 5xx o peores. Bien documentado y soportado por herramientas, el fuzz testing es más relevante que nunca con mayor cantidad de código generado por IA y Complacencia con el código generado por IA. Esto significa que ahora es un buen momento para adoptar el fuzz testing y asegurar que el código siga siendo robusto y seguro.

Desde nuestro primer blip sobre Software Bill of Materials (SBOM) en 2021, la generación de SBOM ha pasado de ser una práctica emergente a una práctica por defecto en nuestros proyectos. El ecosistema ha madurado significativamente, ofreciendo un conjunto de herramientas robusto y una integración fluida con CI/CD. Herramientas como Syft, Trivy y Snyk permiten la generación integral de SBOM, desde el código fuente hasta las imágenes de contenedores, además de escaneo de vulnerabilidades. Plataformas como FOSSA y Chainloop mejoran la gestión de riesgos de seguridad al integrarse con los flujos de desarrollo y reforzar políticas de seguridad. Aunque un estándar universal para SBOM sigue en evolución, el amplio soporte para SPDX y CycloneDX ha reducido los desafíos de adopción. Los sistemas de IA también requieren SBOM, como lo demuestran el AI Cyber Security Code of Practice del gobierno del Reino Unido y el AI Cybersecurity Collaboration Playbook de CISA. Seguiremos monitoreando los avances en este ámbito.

En el panorama en rápida evolución del desarrollo de software impulsado por IA, el modelado de amenazas es más crucial que nunca para crear software seguro, manteniendo la agilidad y evitando el security sandwich. El modelado de amenazas; un conjunto de técnicas para identificar y clasificar potenciales amenazas, se aplica en diversos contextos, incluyendo aplicaciones de IA generativa, que introducen riesgos de seguridad únicos. Para que sea eficaz, debe realizarse con frecuencia a lo largo del ciclo de vida del software y funciona mejor junto con otras prácticas de seguridad. Entre ellas se incluye la definición de requisitos de seguridad interfuncionales para abordar riesgos comunes en las tecnologías del proyecto y el aprovechamiento de escáneres de seguridad automatizados para monitoreo continuo.

Tratar APIs como producto significa priorizar la experiencia del desarrollador(a), no sólo mediante un diseño razonable y estandarizado de dichas APIs sino también proporcionando una documentación completa y una experiencia de onboarding fluida. Aunque las especificaciones de OpenAPI (Swagger) pueden documentar interfaces de APIs de manera efectiva, el onboarding continúa siendo un desafío. Los desarrolladores(as) necesitan acceso rápido a ejemplos funcionales, con autenticación pre-configurada y datos de prueba realistas. Con la evolución de herramientas de clientes API (como Postman, Bruno e Insomnia), recomendamos tratar las colecciones de peticiones API como artefactos del producto API. Las colecciones de peticiones API deben ser diseñadas cuidadosamente para guiar a los desarrolladores(as) a través de flujos de trabajo clave, ayudándoles a comprender el lenguaje y funcionalidad del dominio de la API con el mínimo esfuerzo. Para mantener estas colecciones actualizadas, recomendamos almacenarlas en un repositorio e integrarlas dentro del pipeline de despliegue de la API.

Uno de los retos constantes en equipos grandes de software es determinar quién toma las decisiones arquitectónicas que dan forma a la evolución de los sistemas. El informe State of DevOps report revela que el enfoque tradicional de las Juntas de Revisión de Arquitectura es contraproducente, y a menudo obstaculiza el flujo de trabajo y se correlaciona con un bajo rendimiento organizacional. Una alternativa convincente es architectural advice process — un enfoque descentralizado donde cualquiera puede tomar una decisión arquitectónica, siempre que busque asesoramiento de los afectados y de aquellos con experiencia relevante. Este método permite a los equipos optimizar el flujo sin comprometer la calidad arquitectónica, tanto a pequeña como a gran escala. A primera vista, esta alternativa puede parecer controversial, pero prácticas como Architecture Decision Records y los foros de asesoramiento garantizan que las decisiones se mantengan informadas, mientras que también empoderan a quienes están más cerca del trabajo a tomar decisiones. Hemos visto este modelo tener éxito a escala en un gran número de organizaciones, incluyendo aquellas en industrias altamente reguladas

En nuestra última actualización de RAG, introdujimos GraphRAG , descrito originalmente en el artículo de Microsoft como un enfoque en dos pasos: (1) fragmentación de documentos y uso de análisis basado en LLM de los fragmentos para crear un grafo de conocimientos; (2) recuperación de fragmentos relevantes en el momento de la consulta mediante incrustaciones mientras se siguen las aristas del grafo de conocimiento para descubrir fragmentos relacionados adicionales, que se añaden al prompt aumentado. En muchos casos, este enfoque mejora las respuestas generadas por LLM. Hemos observado beneficios similares al utilizar IA generativa para comprender bases de código heredadas, donde utilizamos información estructural, como árboles sintácticos abstractos y dependencias, para construir el grafo de conocimiento. El patrón GraphRAG ha ganado adeptos, con herramientas y frameworks como el paquete en Python GraphRAG de Neo4j, que están surgiendo para soportarlo. También consideramos que Graphiti se ajusta a una interpretación más amplia de GraphRAG como patrón.

El principio de privilegio mínimo garantiza que los usuarios y sistemas solo tengan el acceso mínimo necesario para realizar las tareas. El abuso de credenciales privilegiadas es un factor clave en las brechas de seguridad, siendo la escalada de privilegios un vector de ataque común. Los atacantes suelen empezar con un acceso de bajo nivel y explotan vulnerabilidades del software o configuraciones erróneas para obtener privilegios de administrador, especialmente cuando las cuentas tienen permisos excesivos o innecesarios. Otro riesgo que a menudo se pasa por alto es el de los privilegios permanentes: accesos privilegiados disponibles de forma continua que amplían la superficie de ataque. La gestión de acceso privilegiado justo a tiempo mitiga este riesgo al conceder acceso solo cuando es necesario y revocarlo inmediatamente después, minimizando la exposición. Un modelo de seguridad de menor privilegio garantiza que los usuarios, aplicaciones y sistemas tengan únicamente los derechos imprescindibles durante el mínimo tiempo posible, un requisito fundamental para el cumplimiento normativo y la seguridad regulatoria. Nuestros equipos lo han implementado a través de un flujo de trabajo automatizado que activa un proceso de aprobación ligero, asigna roles temporales con acceso restringido e impone un tiempo de vida a cada rol, lo que garantiza que los privilegios expiren automáticamente una vez completada la tarea.

Las leyes de Escalabilidad han sido un factor clave del auge de la IA; el principio de que modelos más grandes, conjuntos de datos más extensos y mayores recursos de cómputo conducen a sistemas de IA más potentes. Sin embargo, el hardware de consumo y los dispositivos perimetrales a menudo carecen de la capacidad para soportar modelos a gran escala, lo que crea la necesidad de la destilación de modelos.

La destilación de modelos transfiere conocimiento de un modelo más grande y potente (maestro) a un modelo más pequeño y eficiente en coste (estudiante). El proceso suele implicar la generación de un conjunto de datos de muestra a partir del modelo maestro y el ajuste del modelo estudiante para que capture sus propiedades estadísticas. A diferencia de la poda o la cuantización, que se enfocan en la compresión de modelos suprimiendo parámetros, la destilación intenta retener conocimiento específico del dominio, minimizando la pérdida de precisión. También se puede combinar con la cuantización para una optimización adicional.

Propuesta originalmente por Geoffrey Hinton y otros, la destilación de modelos ha sido ampliamente adoptada. Un ejemplo destacado es Qwen/Llama la versión destilada de DeepSeek R1, que mantiene sólidas capacidades de razonamiento en modelos más pequeños. Con su creciente madurez, la técnica ya no se limita sólo a los laboratorios de investigación; ahora se aplica en una amplia variedad de proyectos, desde industriales hasta personales. Proveedores como OpenAI y Amazon Bedrock ofrecen guías para ayudar a los desarrolladores a destilar sus propios modelos de lenguaje reducido (SLMs, small language model, por sus siglas en inglés). Creemos que la adopción de la destilación de modelos puede ayudar a las organizaciones a gestionar los costes de despliegue de los LLM al tiempo que libera el potencial de la inferencia LLM en dispositivos.

Prompt engineering se refiere al proceso de diseñar y refinar los prompts (instrucciones) para modelos de IA generativa, con el objetivo de producir respuestas de alta calidad conscientes del contexto. Esto implica elaborar indicaciones claras, específicas y relevantes, ajustadas a la tarea o a la aplicación, para optimizar el resultado del modelo. A medida que las LLM evolucionan, particularmente con las llegada de los modelos de razonamiento, las prácticas del prompt engineering deben ser adaptadas. Basados en nuestra experiencia con la generación de código con IA, hemos observado que los prompts con pocos ejemplos pueden ofrecer un menor rendimiento comparado con prompts sin ejemplos al trabajar con modelos de razonamiento. Además, la técnica ampliamente usada de cadena de razonamiento o chain-of-thought (CoT) puede degradar el desempeño de los modelos de razonamiento, probablemente debido a que el aprendizaje por refuerzo ya ha afinado su mecanismo interno de CoT.

Nuestra experiencia práctica se alinea con lo que señala la investigación académica, que sugiere que “los modelos más avanzados podrían eliminar la necesidad del prompt engineering en el desarrollo de software”. No obstante, las técnicas tradicionales del prompt engineering seguirán teniendo un rol crucial en reducir alucinaciones y mejorar la calidad de las respuestas, especialmente considerando las diferencias en tiempos de respuestas y costos de tokens entre los modelos de razonamiento y los LLM generales. Al crear aplicaciones con agentes autónomos, recomendamos elegir los modelos estratégicamente, con base en las necesidades y seguir refinando tanto las plantillas de prompts cómo sus técnicas correspondientes. Encontrar el equilibrio entre la calidad, el tiempo de respuesta y el costo de los tokens sigue siendo clave para maximizar la efectividad de los LLM.

El reciente anuncio de DeepSeek R1 es un gran ejemplo de por qué los small language models (SLMs) siguen siendo interesantes. La versión completa de R1 tiene 671 mil millones de parámetros y requiere alrededor de 1.342 GB de VRAM para funcionar, algo que solo se logra utilizando unmini cluster de ocho GPUs NVIDIA de última generación. Pero DeepSeek también está disponible en versión distilled en Qwen y Llama — modelos más pequeños yopen-weight —, transfiriendo efectivamente sus capacidades y permitiendo que se ejecute en hardware mucho más modesto. Aunque el modelo sacrifica algo de rendimiento en esos tamaños reducidos, aún permite un gran salto en rendimiento respecto a los SLMs anteriores. El campo de los SLM sigue innovando en otros ámbitos, también. Desde el último Radar, Meta introdujo Llama 3.2 en tamaños de 1B y 3B, Microsoft lanzó Phi-4, ofreciendo resultados de alta calidad con un modelo de 14B, y Google presentó PaliGemma 2, un modelo de visión-lenguaje en tamaños de 3B, 10B y 28B. Estos son solo algunos de los modelos que se están lanzando actualmente en tamaños más pequeños y, sin duda, es una tendencia importante a seguir.

En los últimos meses, el uso de GenAI para comprender bases de código legado ha generado verdaderos progresos. Herramientas populares como GitHub Copilot se están promocionando como capaces de ayudar a modernizar bases de código legado. Herramientas como Cody de Sourcegraph facilitan a los desarrolladores la navegación y comprensión de bases de código completas. Estas herramientas utilizan multitud de técnicas de GenAI para proporcionar ayuda contextual, simplificando el trabajo con sistemas legados complejos. Además, frameworks especializados como S3LLM están mostrando cómo los modelos de lenguaje extensos (LLMs) pueden manejar software científico de gran escala -como los escritos en Fortran o Pascal- llevando la comprensión mejorada por GenAI a bases de código fuera de la TI empresarial tradicional. Creemos que esta técnica continuará ganando terreno dada la enorme cantidad de software legacy en el mundo.

Agentes de engenharia de software supervisionados estão cada vez mais capazes de identificar atualizações necessárias e fazer alterações maiores em uma base de código. Ao mesmo tempo, vemos uma crescente complacência com código gerado por IA e desenvolvedoras demonstrando resistência em revisar grandes conjuntos de mudanças feitas por IA. Uma justificativa comum para isso é a ideia de que a legibilidade do código voltada para humanos importa menos, já que a IA pode lidar com modificações futuras. No entanto, assistentes de código baseados em IA também têm um desempenho melhor em bases de código bem estruturadas, tornando o design de código compatível com IA essencial para a manutenção.

Felizmente, boas práticas de design de software para humanos também beneficiam a IA. Nomes bem definidos fornecem contexto de domínio e funcionalidade; modularidade e abstrações mantêm o contexto da IA gerenciável ao limitar as mudanças necessárias; e o princípio DRY (“don’t repeat yourself”, ou “não se repita”) reduz a duplicação de código, facilitando para a IA manter a consistência do comportamento. Até agora, os melhores padrões compatíveis com IA estão alinhados às boas práticas já estabelecidas. À medida que a IA evolui, mais padrões específicos devem surgir, por isso, considerar o design de código com isso em mente será extremamente útil.

Técnicas novas de assistência baseada em IA para equipes de software estão surgindo além da simples geração de código. Uma área que está ganhando destaque é o teste de UI baseado em IA , aproveitando a capacidade dos modelos de linguagem de grande porte (LLMs) de interpretar interfaces gráficas de usuário. Existem várias abordagens para isso. Uma categoria de ferramentas utiliza LLMs multimodais ajustados para o processamento de snapshots, permitindo que scripts de teste sejam escritos em linguagem natural para navegar em uma aplicação. Exemplos nessa área incluem QA.tech ou LambdaTests' KaneAI. Outra abordagem, vista no Browser Use, combina modelos fundacionais multimodais com Playwright, oferecendo insights sobre a estrutura de uma página em vez de depender de modelos ajustados.

Ao integrar testes de UI baseados em IA em uma estratégia de testes, é crucial considerar onde eles agregam mais valor. Esses métodos podem complementar os testes exploratórios manuais e, embora ao não determinismo dos LLMs possa introduzir instabilidades, sua flexibilidade pode ser uma vantagem. Isso pode ser útil para testar aplicações legadas com seletores ausentes ou aplicações que frequentemente mudam rótulos e caminhos de cliques.

A teoria da extensibilidade graciosa define as regras básicas que regem os sistemas adaptativos, incluindo os sistemas sociotécnicos envolvidos na criação e operação de software. Um conceito fundamental nessa teoria é o envoltório de competência - o limite dentro do qual um sistema pode funcionar robustamente diante de uma falha. Quando um sistema é levado além de seu envoltório de competência, ele se torna frágil e tem maior probabilidade de falhar. Esse modelo fornece uma lente valiosa para entender a falha do sistema, como visto nas falhas complexas que levaram à interrupção do Canva em 2024. A Teoria da Residualidade, um desenvolvimento recente no pensamento da arquitetura de software, oferece uma maneira de testar o envoltório de competência de um sistema introduzindo deliberadamente fatores de estresse e analisando como o sistema se adaptou aos fatores de estresse históricos ao longo do tempo. As abordagens se alinham com os conceitos de antifragilidade, resiliência e robustez em sistemas sociotécnicos, e estamos ansiosas para ver aplicações práticas dessas ideias no setor.

Saída estruturada de LLMs se refere à prática de restringir a resposta de um modelo de linguagem a um esquema definido. Isso pode ser alcançado tanto através de um modelo generalizado, para que ele responda em um formato específico, quanto ajustando um modelo para que ele nativamente produza um JSON, por exemplo. A OpenAI agora suporta saídas estruturadas, permitindo que as desenvolvedoras forneçam um esquema JSON, pydantic ou um objeto Zod para restringir as respostas do modelo. Essa capacidade é especialmente valiosa para permitir chamadas de função, integração com APIs e integrações externas, onde a precisão e conformidade com o formato são críticas. A saída estruturada não apenas aprimora a maneira como as LLMs podem interagir com o código, mas também suporta casos de uso mais amplos, como a geração de marcação para renderizar gráficos. Além disso, a saída estruturada demonstrou reduzir a probabilidade de erros nas respostas do modelo.

A IA está diminuindo as barreiras para que pessoas que não programam construam e integrem software por conta própria, em vez de esperar que o departamento de TI atenda às suas necessidades. Embora estejamos entusiasmadas com o potencial que isso desbloqueia, também estamos atentas aos primeiros sinais da TI invisível acelerada por IA. Plataformas de automação de fluxo de trabalho sem código agora oferecem suporte à integração de API de IA (por exemplo, OpenAI ou Anthropic), tornando tentador usar a IA como tapa-buraco — unindo integrações que antes não eram possíveis, como transformar mensagens de chat em chamadas de API de ERP via IA. Ao mesmo tempo, assistentes de programação de IA estão se tornando mais “agênticos", ou autônomos, permitindo que pessoas com treinamento básico construam aplicativos de utilidade interna.

Isso tem todas as características da próxima evolução das planilhas que ainda alimentam processos críticos em algumas empresas — mas com uma pegada muito maior. Se não for controlada, essa nova TI invisível pode levar a uma proliferação de aplicativos não regulamentados e potencialmente inseguros, espalhando dados por cada vez mais sistemas. As organizações devem estar cientes desses riscos e avaliar cuidadosamente as compensações entre a resolução rápida de problemas e estabilidade a longo prazo.

À medida que os assistentes de programação de IA continuam a ganhar força, o mesmo acontece com o crescente conjunto de dados e pesquisas que destacam as preocupações sobre a complacência com código gerado por IA. A mais recente pesquisa de qualidade de código da GitClear mostra que, em 2024, códigos duplicados e a rejeição de códigos aumentaram ainda mais do que o previsto, enquanto a atividade de refatoração nos históricos de commit diminuiu. Também refletindo isso, uma pesquisa da Microsoft sobre “trabalhadoras do conhecimento” descobriu que a confiança impulsionada pela IA geralmente ocorre às custas do pensamento crítico (um padrão que observamos à medida que a complacência se instala com o uso prolongado de assistentes de programação). O surgimento de agentes de engenharia de software supervisionados amplia ainda mais os riscos, pois quando a IA gera conjuntos de alterações cada vez maiores, as desenvolvedoras enfrentam desafios maiores na revisão dos resultados. O surgimento da “vibe coding”, em que desenvolvedoras permitem que a IA gere código com revisão mínima, ilustra a confiança crescente nos resultados gerados pela IA. Embora essa abordagem possa ser apropriada para coisas como protótipos ou outros tipos de código descartável, advertimos fortemente contra seu uso para código de produção.

As organizações continuam cautelosas em relação aos assistentes de programação com IA de terceiros, especialmente devido a preocupações com a confidencialidade do código. Como resultado, muitas desenvolvedoras estão considerando o uso de assistentes de programação locais — IAs que rodam inteiramente em suas máquinas — eliminando a necessidade de enviar código para servidores externos. No entanto, os assistentes locais ainda ficam atrás das versões baseadas na nuvem, que utilizam modelos maiores e mais avançados. Mesmo em máquinas de alto desempenho, os modelos menores continuam apresentando limitações. Observamos que eles têm dificuldades com prompts complexos, não possuem uma janela de contexto suficientemente grande para problemas mais amplos e, muitas vezes, não conseguem ativar integrações de ferramentas ou chamadas de funções. Essas capacidades são especialmente cruciais para os workflows baseados em agentes, que representam o estado da arte na assistência à programação atualmente.

Portanto, embora seja importante ter expectativas moderadas, algumas funcionalidades ainda são viáveis localmente. Algumas IDEs populares agora incorporam modelos menores em seus recursos principais, como a conclusão preditiva de código do Xcode e a completação de código de linha inteira da JetBrains. Além disso, LLMs que podem ser executados localmente, como o Qwen Coder, representam um avanço para sugestões inline locais e o manuseio de consultas simples de programação. Você pode testar essas capacidades com o Continue, que suporta a integração de modelos locais por meio de runtimes como o Ollama.

Quando as pessoas falam sobre assistentes de programação, o tópico programação em pares inevitavelmente aparece. Nossa profissão tem uma relação de amor e ódio com isso: algumas pessoas acreditam veemente, outras não suportam. Assistentes de programação agora imploram pela pergunta: pode um ser humano parear com uma IA, ao invés de outro ser humano, e obter os mesmos resultados para o time? O GitHub Copilot chama a si mesmo de seu programador em par de IA. Enquanto acreditamos que um assistente de programação pode trazer alguns dos benefícios da programação em pares, nós desaconselhamos totalmente substituir programação em pares por IA. Visualizar assistentes de código para o pareamento ignora um dos benefícios chave da programação em pares: tornar o time, não apenas os indivíduos que contribuem, melhor. Assistentes de programação podem oferecer benefícios para se desbloquear, aprender sobre uma nova tecnologia, integrar ou tornar o trabalho tático mais rápido para que possamos focar em design estratégico. No entanto, eles não contribuem para os benefícios da colaboração em equipe, como manter o trabalho em andamento em um nível baixo, reduzir handoffs e reaprendizados, possibilitar a integração contínua ou melhorar a propriedade coletiva do código.

Estamos observando uma proliferação preocupante do chamado ETL reverso. Os processos tradicionais de ETL têm seu lugar nas arquiteturas de dados convencionais, onde transferem dados de sistemas de processamento de transações para um sistema centralizado de análise, como um data warehouse ou um data lake. Embora essa arquitetura tenha limitações bem documentadas — muitas das quais são abordadas por uma abordagem de malha de dados —, ela ainda é comum em empresas. Numa arquitetura desse tipo, mover dados de volta de um sistema central de análise para um sistema de transações faz sentido em certos casos — por exemplo, quando o sistema central pode agregar dados de várias fontes ou como parte de uma arquitetura transicional ao migrar para uma malha de dados. No entanto, estamos observando uma tendência crescente em que fornecedoras de produtos usam ETL reverso como uma desculpa para mover cada vez mais lógica de negócios para uma plataforma centralizada — o produto delas. Essa abordagem agrava muitos dos problemas causados pelas arquiteturas de dados centralizadas, e sugerimos extrema cautela ao introduzir fluxos de dados de uma plataforma centralizada e abrangente para sistemas de processamento de transações.

Vemos uma adoção contínua do SAFe™ (Scaled Agile Framework®). Também continuamos a observar que os processos de SAFe, padronizados em excesso e com etapas faseadas, criam fricção, podem promover silos e que seu controle de cima para baixo gera desperdício no fluxo de valor e desestimula a criatividade dos talentos de engenharia, ao mesmo tempo em que limita a autonomia e a experimentação das equipes. Um dos principais motivos para a adoção do SAFe é a complexidade de tornar uma organização ágil, com empresas esperando que um framework como esse ofereça um atalho simples, baseado em processos, para alcançarem a agilidade. Dada a adoção generalizada do SAFe — inclusive entre nossas clientes — treinamos mais de 100 consultoras da Thoughtworks para oferecer melhor suporte a elas. Apesar desse conhecimento aprofundado e de muita tentativa, chegamos à conclusão de que, às vezes, simplesmente não existe uma solução simples para um problema complexo e continuamos a recomendar abordagens e governança mais enxutas e orientadas por valor que funcionem em conjunto com um programa abrangente de mudança.

Scaled Agile Framework® e SAFe™ são marcas registradas da Scaled Agile, Inc.