magic.dev

Magic (magic.dev) is an AI company building frontier code models with the stated goal of automating software engineering and research. It describes this as its most promising path toward safe AGI: automating AI research and code generation so models can improve and solve alignment problems more reliably than humans working alone. If you want to know whether to follow its research, consider its tooling, or apply for a role, the short answer is that Magic is a small, research-heavy team with unusually large compute and funding, focused on code and research automation rather than a general-purpose consumer product.

What Magic says it is building

Magic's own framing is specific: frontier code models aimed at automating software engineering and research. That is narrower than "an AI assistant for everything" — the target is the work of writing, improving, and researching software and models themselves.

Its stated technical approach combines four elements:

• Frontier-scale pre-training — training very large base models.
• Domain-specific reinforcement learning — RL tuned to code and research tasks rather than general conversation.
• Ultra-long context — handling very large inputs, which matters for whole codebases and long research traces.
• Inference-time compute — spending more computation when generating an answer, rather than only scaling training.

The company's logic is that these pieces reinforce each other: better code generation speeds up model improvement, which in turn helps address alignment. That is a claim about strategy, not a demonstrated result, so treat it as Magic's stated rationale.

Scale, funding, and compute

Magic reports raising $768 million from investors including Nat Friedman, Daniel Gross, CapitalG, Elad Gil, Sequoia, Jane Street, and Eric Schmidt. It also states it has thousands of GB200s to support its work.

Those two facts explain why a small team can pursue frontier-scale training: capital and compute are the binding constraints for this kind of research, and Magic says it has secured both. The site does not publish pricing, product tiers, or a public sign-up flow, so there is no basis to assume a free or paid end-user product exists today.

Recent research direction

Magic points to recent work on compute-efficient pretraining and scaling to trillion-parameter models, described as ">10x More Efficient Pretraining." The practical takeaway for a reader tracking the field: the company is publishing on training efficiency and scale, which is consistent with its stated focus on frontier code models rather than application-layer features.

Who this matters to

Open roles

Magic lists these positions, mostly in San Francisco (SF), with one remote option:

• Research Engineer — SF
• Member of Technical Staff, Inference & RL Systems — SF
• Member of Technical Staff, Kernels — SF / Remote
• Member of Technical Staff, Pre-training Systems — SF
• Member of Technical Staff, RL Research & Environments — SF
• Member of Technical Staff, Security Engineer — SF

The role list is itself informative: kernels, inference and RL systems, pre-training systems, and RL environments are all infrastructure-and-research positions, not product or growth roles. That matches the company's description of itself as "a small group of engineers and researchers working to solve a short list of fundamental research problems."

How to decide whether to follow Magic

• Follow the research if you care about compute-efficient pre-training, trillion-parameter scaling, long context, or RL for code — these are the areas Magic says it works in.
• Consider applying if your background is in training systems, kernels, inference, or RL research; the listed roles are concentrated there.
• Wait for a product if you want a tool to use. The site describes a mission and a team, not a released application, and it publishes no pricing or access details.

For the most current information, the company's blog and careers pages are the primary sources, since team size, roles, and research results change over time.

AGI, or Artificial General Intelligence, is a hypothetical system that can learn and perform any intellectual task a human being can, rather than excelling at one narrow domain. Today's AI systems — chatbots, image generators, code assistants — are narrow: they operate within boundaries set by their training and task design. AGI would need to generalize across unfamiliar domains, transfer knowledge between them, and reason at or near human level without being retuned for each new task. No system has met that bar, and there is no agreed test for confirming it.

Narrow AI vs. AGI: the core distinction

The difference is not raw capability but scope and adaptability.

A code assistant that completes functions is narrow even if it writes in many languages, because it does not decide what to build, learn a new field from scratch, or carry its skill into unrelated work.

The criteria people use to judge AGI

Because there is no single accepted test, researchers and writers tend to argue over a cluster of properties:

• Generality across domains — the same system handles math, writing, planning, and physical-world reasoning without separate models.
• Transfer learning — knowledge from one area improves performance in a genuinely new one.
• Autonomy — the system can break a goal into steps, execute them, and recover from failure with little human intervention.
• Human-level reasoning — performance comparable to a capable adult on novel problems, not just benchmark items seen in training.

Meeting one criterion is not enough. A model can transfer somewhat and still fail badly at autonomy; a system can act autonomously in a sandbox and still lack general reasoning.

Why AGI is still hypothetical

Current systems, including frontier models, are trained on large corpora and optimized for prediction or task reward. That produces broad-seeming behavior, but it is bounded by the training distribution and by the interface around it. They do not reliably learn a new skill from a handful of examples the way a person does, and they do not set their own long-horizon goals.

This is why definitions and timelines are contested. Some define AGI as human-level performance on most economically valuable work; others set the bar at any intellectual task, which is far higher. A system can look general in conversation and still be narrow in practice.

One example of how labs pursue AGI

Some organizations treat AGI as an engineering target rather than a definition to debate. Magic, an AI company, states that it is "building frontier code models to automate software engineering and research" and argues that "the most promising path to safe AGI is to automate AI research and code generation to improve models and solve alignment more reliably than humans can alone." Its stated approach combines frontier-scale pre-training, domain-specific reinforcement learning, ultra-long context, and inference-time compute.

That is one strategy among several, not the definition of AGI. It illustrates a common bet: that automating the work of building and improving AI is a route toward general capability. Whether that route succeeds is an open question, and the company's own framing treats AGI as a goal still being pursued.

What to take away

AGI names a capability that does not yet exist: general, transferable, autonomous, human-level reasoning. Today's AI is narrow by comparison, even when it feels broad. When you see the term used, check which criteria the speaker means — generality, autonomy, or economic impact — because the disagreement is usually about the bar, not the label.

An AI pair programmer is a tool that works alongside you inside your editor on a task you describe, rather than only predicting the next line as you type. It fits best when you already know roughly what you want to build and want help drafting, refactoring, testing, or explaining code across more than one file. Code autocomplete is narrower: it completes what you're already writing, token by token, with little or no task-level direction from you.

The core difference: scope and interaction

Autocomplete reacts to the text immediately around your cursor. You start typing fetch(, and it offers the rest of the call. You stay in control of the task; the tool only accelerates keystrokes.

An AI pair programmer accepts a described intent — "add pagination to this endpoint," "write tests for this module" — and proposes a larger change. You then review, accept, edit, or reject. The interaction is a loop, not a single suggestion.

A chat assistant sits outside that loop: you paste code or describe a problem, get an answer in a separate panel, and copy it back yourself. An autonomous coding agent goes further still, planning and executing multi-step changes with limited supervision.

The typical workflow

1. Describe intent. State the task in the editor or a prompt field — for example, "extract this validation logic into a helper and update the two callers."
2. Let it gather context. The tool reads the relevant files, imports, and types. Multi-file context is what separates a pair programmer from a line completer.
3. Review the proposal. Read the diff before accepting. Check that it uses APIs that actually exist in your version.
4. Accept, edit, or reject. Partial acceptance is normal; treat the output as a draft.
5. Iterate. Ask for a test, a refactor, or an explanation of what changed.

Capabilities to expect

• Multi-file edits — changes that touch a helper, its callers, and its tests together.
• Test generation — scaffolding unit tests from existing code, which you then correct.
• Refactoring — renaming, extracting functions, or restructuring modules.
• Explanation — describing unfamiliar code so you can decide whether to keep it.
• In-editor chat — asking questions without leaving the file.

Practical limitations

• Hallucinated APIs. Suggestions may call methods or parameters that don't exist in your dependency versions. Verify against your actual libraries.
• Security and licensing. Generated code can reproduce patterns from training data. Check your organization's policy on what may be sent to a hosted service and how output is licensed.
• Human review is required. Treat every proposal as untrusted until you've read it. This is especially true for authentication, payment, and data-handling code.
• Context limits. Large repositories may exceed what the tool can see, so it can miss conventions used elsewhere in your codebase.

How to evaluate a tool

Compare candidates on the same dimensions:

• Language and framework support — does it handle your primary stack well, or only the popular ones?
• IDE integration — does it live in the editor you already use, or require switching?
• Context window — how much of your project can it actually read?
• Privacy terms — is your code used for training, and can you opt out?
• Review ergonomics — how easy is it to see, accept, or reject a diff?

Magic, the company behind magic.dev, describes its work as building frontier code models to automate software engineering and research, combining frontier-scale pre-training, domain-specific reinforcement learning, ultra-long context, and inference-time compute. That positions it toward the more autonomous end of the spectrum described above rather than simple completion — useful context when you're deciding which category of tool actually fits your workflow.

Magic AI is an AI company working toward safe AGI by automating software engineering and AI research. It builds frontier code models rather than a consumer chatbot or a plug-in coding assistant. If you are looking for a tool to install in your IDE today, Magic is not that; if you want to understand who is building the most capable code models and why, this is the company to watch.

What Magic AI is trying to do

Magic states its mission directly: it is "building frontier code models to automate software engineering and research." The reasoning behind that focus is that automating AI research and code generation could improve models and solve alignment more reliably than humans can alone — the company describes this as "the most promising path to safe AGI."

That framing matters. Magic is not positioning code generation as a productivity feature. It treats code as the substrate for AI improving itself, which puts it in a different category from an AI pair programmer that suggests the next line in your editor.

How its approach differs from typical AI coding assistants

Magic describes four technical pillars it combines:

• Frontier-scale pre-training — training very large models from scratch rather than fine-tuning an existing one.
• Domain-specific reinforcement learning — optimizing specifically for code and research tasks.
• Ultra-long context — handling far more code and context than a typical assistant window.
• Inference-time compute — spending more computation when generating an answer to improve quality.

A conventional AI pair programmer usually wraps a general-purpose model behind an editor extension. Magic's stated approach is to build the underlying frontier model itself and push on all four dimensions at once. The company also publishes research; one public update covers compute-efficient pretraining and scaling to trillion-parameter models.

Who is behind it and how it is funded

Magic describes itself as "a small group of engineers and researchers working to solve a short list of fundamental research problems on a direct path to AGI." Supporting that work:

The combination of a small team, heavy compute, and large funding is a deliberate choice: fewer people, more compute per person, aimed at a short list of hard problems rather than a broad product surface.

What roles it hires for

The careers listings reveal where the company concentrates effort:

• Research Engineer (SF)
• Member of Technical Staff, Inference & RL Systems (SF)
• Member of Technical Staff, Kernels (SF / Remote)
• Member of Technical Staff, Pre-training Systems (SF)
• Member of Technical Staff, RL Research & Environments (SF)
• Member of Technical Staff, Security Engineer (SF)

The titles map onto the four pillars: pre-training, inference and RL systems, kernels (low-level model performance), and RL environments. There is no product, growth, or developer-relations role listed, which reinforces that this is a research organization, not a tool vendor.

Magic AI vs. other things called "magic"

"Magic" is a common name in software, so it helps to separate the entities:

• Magic (magic.dev) — the company described here: frontier code models and safe AGI research.
• Magic AI coding assistants — various unrelated plug-ins and editors that use "magic" in their branding.
• General AI pair programmers — tools like IDE-integrated assistants that autocomplete or chat about code, typically built on third-party models.

If a product markets itself as "magic AI" and offers an install button, it is almost certainly not this company. Magic at magic.dev does not present a consumer product or published pricing on its site.

What to take away

Magic AI is best understood as a research lab betting that automating code and AI research is the route to safe AGI. Its differentiators are frontier-scale pre-training, domain-specific RL, ultra-long context, and inference-time compute, backed by $768M and thousands of GB200s. It is not a coding assistant you adopt for daily work — it is a company building the models that could eventually power that class of tool.

AI charge capture is software that reads clinical documentation and produces coded, bill-ready charges automatically. Instead of a provider or coder manually translating a visit note into CPT and ICD-10 codes, the system extracts the relevant details from the note and selects codes for review or submission. It fits teams that already document visits in an EHR or EMR and want to reduce missed charges, manual coding searches, and claim delays — MediMobile's Genesis is one example of this category, positioned as an automated medical coding and charge capture solution.

How AI charge capture differs from manual charge entry

Manual charge capture depends on a person remembering to log the encounter, then finding the right codes by hand. That creates three predictable failure points:

1. Encounters get missed — billable work falls through the cracks when a busy provider moves to the next patient.
2. Coding takes time — manual searches and reviews slow coders down.
3. Claims get delayed — late or incorrect charges affect reimbursement.

AI charge capture targets all three by making code selection part of the documentation workflow rather than a separate step after it.

The workflow: from EMR documentation to bill-ready charges

The mechanism MediMobile describes is deliberately narrow: providers document their visits in their EMR, and the system handles the rest. In practice that means:

• Input: the clinical note the provider already writes during or after the visit.
• Action: AI coding reads that documentation and generates CPT and ICD-10 code selections.
• Output: coded charges that are ready for billing, with a charge review step available for coding teams.

The stated result is that documentation turns into CPT and ICD-10 codes "instantly," so encounters are captured before revenue slips away. The provider's job ends at documentation; the coding and charge creation happen downstream.

How the AI selects CPT and ICD-10 codes

The platform describes AI-assisted coding that produces "coded, bill-ready charges from documentation," paired with cleaner charge review and fewer manual searches for coding teams. Two things are worth separating here:

• Code generation — the system proposes CPT and ICD-10 codes based on what the note contains.
• Charge review — a human-facing step where coding teams check and clean up those charges before they move toward billing.

That review layer matters because it keeps a person in the loop on code selection rather than treating AI output as final. The source does not specify the model, accuracy rates, or whether any codes bypass review, so treat "autonomous" coding as a spectrum and confirm the review policy with any vendor.

Who each part of the platform serves

MediMobile frames the product around three roles, which is a useful way to check whether a tool fits your team:

If your bottleneck is providers forgetting to log encounters, the provider-side capture matters most. If it's coder throughput, the AI coding and review layer is the relevant piece.

Where charge capture connects to the rest of the revenue cycle

Charge capture is one link in a longer chain, and the platform's other features show where it plugs in:

• MIPS reporting — quality measures are tracked inside the same workflow, so reporting doesn't require a separate data pull.
• Integrations — connections to EHR, billing, and data workflows, which is what allows charges to move toward billing without re-entry.
• Reporting and analytics — visibility into missed charges and coding progress for revenue cycle leaders.

The practical takeaway: evaluate AI charge capture by how well it hands off to coding review and billing, not just by whether it generates codes.

Common failure points to check before adopting

The problems MediMobile names — missed encounters, slow manual coding, delayed claims — are the same things to test against in a demo. Ask specifically:

• Does the system capture encounters from the EMR automatically, or does someone still trigger each one?
• How are generated CPT and ICD-10 codes reviewed, and who signs off?
• What happens to a charge the AI can't confidently code?
• How do charges flow into billing, and what integration work is required?

MediMobile lists "Service Levels & Pricing" and a demo request as the next steps, but the source does not publish prices or plan details, so cost and contract terms have to come from the vendor directly.