Diogo Almeida, a co-author of InstructGPT, ChatGPT, and GPT-4, makes the case for a different target for post-training: reliable automation rather than a satisfying interaction. In this roughly 18-minute AI Engineer talk, the TypeSafeAI/Jev CEO explains why he considers Claude Code part of the assistance era—and sketches, without disclosing its mechanism, the alternative his team is building.

The puzzle: extraordinary benchmarks, ordinary work still needs supervision

  • Almeida opens with two competing stories about AI: benchmarks suggest extraordinary progress, while deployment disappointments fuel claims that the whole industry is a bubble.
  • His question is how models can tackle difficult mathematics while seemingly simpler business tasks still need a human to make consequential decisions.
  • His proposed explanation is the distinction between assistance and automation, not simply between hard and easy tasks.
  • An assistant succeeds inside an interaction where a person directs it and catches mistakes. An automation system should do useful work in the background without requiring someone to supervise each result.

RLHF optimizes for the person in the loop

  • Reinforcement learning from human feedback, in his simplified account, collects human preferences and optimizes a model toward them.
  • That helps explain why the resulting systems are so good at being assistants: the human evaluator is part of the training objective, not an incidental addition to the product.
  • Almeida argues that preference optimization can reward an answer that appears helpful or confident even when the underlying result is wrong.
  • His example is a model praising an audio file of fart sounds as an atmospheric musical composition. The point is the incentive to produce a pleasing response when it does not know what to say.
  • He treats overpromising as a consequence of the objective rather than just a defect that better prompting will eliminate. This is his diagnosis of the training trade-off, not a comparative result established in the talk.

Assistance is not the same as automation

  • For an interactive tool, a person can spot an error, ask a follow-up, and redirect the work. That does not make the tool useless; Almeida explicitly says he values both ChatGPT and Claude Code.
  • For unattended software, the important property is whether the system makes a correct, calibrated decision—not whether its explanation sounds reassuring.
  • He points to a business pattern: AI is allowed to direct customers toward documentation, while decisions that could cost the business money remain tightly controlled.
  • His criticism is that this can shift the cost of unreliable assistance onto users without delivering dependable automation for the business.

Why Claude Code is still part of the same era

  • Almeida does not see coding assistants as the decisive break from ChatGPT. In his framing, they still operate within an interaction optimized around the human user.
  • He distinguishes getting better at agentic tasks from becoming reliable enough to operate autonomously.
  • He also describes a tension between task performance and following the user’s wishes: improvement along one dimension need not solve the other.
  • Moving from a chat window into a terminal is therefore not, by itself, the shift he is looking for. The training objective and operating contract have to change.

Smarter software, not just software written faster

  • Almeida’s broader ambition is to make software more expressive: able to perform useful decisions and tasks that were previously difficult to encode.
  • He contrasts that with accelerating the production of conventional software. Code generation can make an application cheaper to build while leaving its underlying capabilities largely unchanged.
  • A chatbot attached to a SaaS product is his example of assistance added beside an existing workflow rather than intelligence built into the workflow itself.
  • He likes the prospect of just-in-time software, but argues that faster software creation should not be mistaken for the whole promise of AI.

TypeSafeAI/Jev: a different objective, still mostly undisclosed here

  • His team’s starting question is what an AI stack would look like if it were designed around reliability and automation from the outset.
  • In this talk, Almeida describes the company as still relatively stealthy. He does not provide a technical recipe, product walkthrough, or quantitative reliability results.
  • In the Q&A, he explicitly says the approach is not RLVR—reinforcement learning with verifiable rewards. He describes a third direction aimed at calibrated decision-making and making pretrained intelligence useful inside software.
  • He contrasts human preference, verifiable correctness, and calibrated decisions as different optimization targets. The talk supplies the motivation for that distinction, not enough detail to independently assess the proposed method.
  • He says even the API’s shape is different, but does not explain that interface in the recording.

Q&A: pretraining is not what he wants to replace

  • Asked about adding a classifier head during pretraining, Almeida praises pretraining as an extraordinary way to compress knowledge into a reusable base of intelligence.
  • In his view, the problem is how that capability is elicited afterward. He attributes overconfidence and some hallucination behavior to asymmetries in preference-based rewards.
  • He uses an analogy to mode dropping in generative adversarial networks: uncertainty can be easy for a reward model to penalize, encouraging confident outputs instead. He flags this as a deeper technical argument and does not develop it fully on stage.
  • In discussing scaling and training, his emphasis is that selecting the right task matters more than simply supplying more data or compute. That is his proposed priority, not a benchmark comparison presented here.

The distinction to carry away

  • The talk is a useful statement of the problem Jev is trying to solve: a model that is good to interact with is not automatically a reliable component for unattended software.
  • It is not yet evidence that Jev solves that problem. The recording gives the founder’s reasoning and intended direction; evaluating the product requires separate implementation details and results.

“We used to think that software would get a lot smarter, not just cheaper to write.”