Quando a Midjourney compra um app de astrologia como o Co-Star, não é “só mais uma aquisição”. Na minha experiência, isso é um sinal claro de uma virada: IA deixando de ser apenas ferramenta de imagem/vídeo e virando camada de entendimento emocional e autoconhecimento. E, pra quem programa, a parte interessante é como esse tipo de produto exige engenharia bem mais delicada do que “gerar um prompt bonito”.
Segundo o Olhardigital.com.br, a Midjourney comprou o Co-Star e trouxe a fundadora Banu Guler como diretora de design, com acesso a recursos da Midjourney. A ideia parece simples: combinar reflexão individual (astrologia + journaling) com tecnologia generativa. Mas por trás disso tem um monte de implicações técnicas: dados, personalização, UX de confiança, avaliações de qualidade e até arquitetura de modelos.
O que a compra do Co-Star diz sobre o futuro da IA (e o que muda na prática)
Eu já vi essa tendência acontecer em ciclos: primeiro vem a geração de conteúdo (arte, texto, vídeo). Depois vem o “assistente” (chat + recomendação). Agora começa a fase de experiência contínua, onde a IA observa padrões, sugere caminhos e ajuda a pessoa a organizar o que sente.
No caso do Co-Star, astrologia é só o “formato”. O valor real está em: transformar sinais (datas, mapas, rotinas, preferências) em linguagem útil e emocionalmente segura. E é exatamente aí que desenvolvedores percebem que “funciona no demo” não é o mesmo que “funciona no mundo real”.
Geração criativa vs. personalização com responsabilidade
Midjourney é conhecida por criatividade visual. Co-Star é conhecido por interpretar e contextualizar. Unir os dois mundos força decisões que devs costumam subestimar:
- Personalização: o app não pode parecer genérico. Mas quanto mais personalizado, mais você precisa controlar privacidade e vieses.
- Confiabilidade: previsões e leituras não podem soar como “verdades” médicas/psicológicas. O tom precisa ser cuidadoso.
- Qualidade consistente: se a IA variar demais, o usuário perde confiança rápido.
Em engenharia, isso costuma virar um problema de produto, mas também é um problema de sistema: caching, versionamento de modelos, métricas de qualidade e regras de fallback quando o modelo “escapa” do tom.
Por que a Midjourney quer “mudar o jogo” fora do pipeline de mídia
Segundo o Olhardigital.com.br, a Midjourney já mira diversificar negócios além de licenciar IA, incluindo projetos como scanner corporal ultrassônico e divisão voltada à saúde. O padrão aqui é: tecnologia que entende pessoas.
O que me chama atenção é que o Co-Star serve como uma ponte perfeita para esse tipo de visão, porque o produto já vive no campo entre:
- conteúdo (mensagens, leituras, textos)
- contexto (rotina e preferências)
- emoção (linguagem e estrutura)
Pra um time de IA, isso vira um laboratório de aprendizado sobre como pessoas interagem com sugestões. Para um dev, vira um laboratório de arquitetura de “IA com produto”: orquestração, validação, governança e observabilidade.
Comparação prática: por que não é “só um chat com astrologia”
Uma alternativa simples seria pegar um LLM e adicionar um prompt do tipo “faça uma leitura”. Eu chamaria isso de técnica de blog: rápido de construir, fácil de errar. Co-Star, ao que o mercado indica, trabalha com uma estrutura mais específica (eventos, ciclo, signos, consistência), o que torna a leitura menos aleatória.
Em engenharia, isso geralmente significa:
- um motor de regras/ontologia (astrologia como base de dados e estados)
- camadas de geração (texto final) condicionadas por estado
- guardrails de conteúdo e tom
Ou seja: o modelo não decide tudo. Ele expressa e ajuda a narrar, enquanto regras e contexto reduzem variância.
Arquitetura provável: como eu desenharia um Co-Star “com Midjourney por trás”
Não dá pra saber detalhes internos, mas eu apostaria em uma arquitetura modular. Quando você tenta integrar geração criativa com personalização, o segredo é separar “o que decide” de “o que escreve”.
Camadas que eu colocaria (e por quê)
- Camada de contexto: calcula mapa, eventos relevantes, preferências do usuário. Motivo: determinismo parcial e rastreabilidade.
- Camada de política (“policy engine”): define limites de confiança, tom, o que pode ou não pode ser afirmado. Motivo: segurança e consistência.
- Camada de geração: LLM escreve o texto, com prompt templates versionados. Motivo: manter qualidade ao longo do tempo.
- Camada de interpretação: score de qualidade, validação de estilo, filtros anti-desvio. Motivo: observabilidade e redução de “surpresas”.
Isso conversa com o que a Banu Guler disse ao Olhardigital.com.br (via publicação no X): computadores como ferramentas que revelam humanidade. Eu traduziria isso em engenharia como: reduzir ambiguidade e aumentar clareza, sem ultrapassar limites.
Na Prática: como implementar personalização responsável com guardrails (exemplo)
Vou mostrar um exemplo funcional de backend que combina “contexto determinístico” + “geração” + “validação do tom”. Pense em um endpoint que gera uma leitura diária. Você passa contexto calculado e o sistema decide se a saída está dentro do esperado.
import express from "express";
const app = express();
app.use(express.json());
// Exemplo de "motor determinístico" (astrologia simplificada aqui)
function buildAstroContext(input: { date: string; timeZone: string }) {
const day = new Date(input.date).getUTCDate();
// placeholders: em produto real, aqui entrariam signos, casas, trânsitos etc.
return {
moodTheme: day % 2 === 0 ? "clareza" : "reflexão",
focus: day % 2 === 0 ? "conversas honestas" : "autoconhecimento",
disclaimer:
"Esta leitura é para reflexão pessoal e não substitui aconselhamento profissional."
};
}
// Policy: define limites do estilo
function validateTone(text: string) {
const forbidden = [
"garantido", "certamente", "tratamento", "cura",
"você é doente", "diagnóstico", "vai acontecer sem falhar"
];
const hit = forbidden.find(w => text.toLowerCase().includes(w));
return !hit;
}
// Orquestração com LLM (simulado)
async function generateReading(astro: any) {
// Em produção, você chamaria seu provedor de LLM aqui.
return `Hoje o tema é ${astro.moodTheme}. Foque em ${astro.focus}.
${astro.disclaimer}
Sugestão: escreva 3 frases sobre o que você evitou dizer e depois leia em voz baixa.`;
}
app.post("/api/reading/daily", async (req, res) => {
const { date, timeZone } = req.body;
if (!date || !timeZone) return res.status(400).json({ error: "date/timeZone required" });
const astro = buildAstroContext({ date, timeZone });
const text = await generateReading(astro);
// Guardrail simples: valida tom (exemplo)
if (!validateTone(text)) {
// fallback: muda prompt, reduz assertividade ou retorna mensagem mais neutra
const fallback =
`${astro.disclaimer}\n\nHoje eu sugiro uma abordagem mais cuidadosa: observe seus padrões e escolha uma ação pequena e consistente para o seu bem-estar.`;
return res.json({ text: fallback, mode: "fallback" });
}
return res.json({ text, mode: "ok" });
});
app.listen(3000, () => console.log("API running on :3000"));
Por que essas decisões? Porque devs erram ao tratar guardrails como “apenas prompt”. Prompt ajuda, mas não garante. Validar saída e ter fallback reduz risco operacional. E separar contexto (determinístico) da geração (LLM) reduz variação e melhora consistência.
Erros Comuns: o que eu vejo devs fazerem (e que quebra esse tipo de produto)
1) Tratar o LLM como fonte de verdade
Se o modelo “inventa” detalhes do seu contexto, a confiança cai rápido. O usuário nota. Em produtos emocionais, isso é ainda mais grave porque o texto tem impacto na percepção da pessoa.
2) Não versionar prompts e modelos
Quando você atualiza o prompt ou troca o modelo, a qualidade muda. Sem versionamento, você perde rastreio e não consegue voltar atrás. Resultado: “de repente piorou” e ninguém sabe por quê.
3) Ignorar observabilidade (métricas de qualidade)
Dev acha que medir latência é suficiente. Aqui você precisa medir coisas como:
- taxa de fallback
- percentual de respostas com linguagem fora do tom
- feedback do usuário (cliques, tempo de permanência, salvamentos)
4) Guardrails frágeis
Somente “seu prompt diz pra não afirmar coisas” não é guardrail. Você precisa de validação pós-geração e fallback. O exemplo acima faz isso de forma simples.
5) Personalização sem controle de privacidade
Quanto mais “ciente” do usuário o app fica, mais você precisa: minimização de dados, criptografia, retenção com propósito e explicações. Mesmo que a IA pareça “inofensiva”, logs e analytics podem vazar.
Implicações para o dia a dia de quem programa
Eu vejo três áreas onde esse tipo de movimento impacta diretamente devs:
- Engenharia de produto com IA: você passa a desenhar fluxo de qualidade como pipeline (não como “uma chamada ao modelo”).
- Arquitetura e custos: personalização aumenta chamadas e condicionamento. Você precisa caching e otimização de token.
- Segurança e compliance: linguagem emocional exige controles. Não é só “conteúdo adulto” ou “injúria”; é também risco de aconselhamento/afirmações.
Pra um time de web, isso bate em front-end também: UI precisa explicar incerteza, oferecer opções, permitir que o usuário ajuste preferências e controlar o que fica salvo.
FAQ
1) Isso significa que a Midjourney vai virar um app de astrologia?
Não necessariamente. Segundo o Olhardigital.com.br, o foco é ampliar o Co-Star com recursos da Midjourney e manter a liderança da Banu Guler. O caminho mais provável é “IA generativa + contexto emocional”, não substituir o conceito do app.
2) Qual é a diferença entre usar LLM “cru” e uma arquitetura com regras?
LLM cru tende a variar e inventar. Regras/ontologia dão determinismo parcial (signos, eventos, estados) e o LLM apenas narra. Isso melhora consistência e reduz risco de respostas fora do tom.
3) Como medir qualidade em um app de autoconhecimento?
Além de métricas técnicas (latência, erro), você precisa de métricas de experiência: feedback do usuário, taxa de retorno, taxa de salvamento e análise de “desvio de tom” (guardrails em produção).
4) Guardrails só funcionam em texto curto?
Não. Eles devem atuar no output completo. Em geral, você valida por regras simples (keywords proibidas, presença de disclaimers, limites de assertividade) e usa fallback quando detectar desvio.
5) Vale cachear respostas em apps desse tipo?
Vale, mas com cuidado. Cache ajuda em custo e latência, porém você precisa garantir que o “contexto” usado para gerar a resposta é o mesmo (versão de prompt/modelo, preferências e data). Caso contrário, você entrega conteúdo “errado” para o usuário.
Fechando: por que essa compra importa pra quem programa
Eu vejo essa aquisição como mais um capítulo na evolução da IA: de “tool” pra “experiência”. O Co-Star mostra como tecnologia pode organizar emoção e pensamento. E a Midjourney, ao entrar nisso, sugere que quer atuar onde a interface humana importa tanto quanto o modelo.
Pra devs, o aprendizado é direto: não basta integrar um LLM. Você precisa de arquitetura, políticas, validação, observabilidade e UX que trate confiança como requisito de engenharia.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.