DEV Community: Jojo

Two Ways an AI Writes: One Step at a Time, or Draft and Revise?

Jojo — Thu, 12 Nov 2026 15:52:25 +0000

Imagine two writers tackling the same sentence.

The first writes one word at a time, checking each new word against everything already written. The second sketches several blanks, fills in what it can, then revises the sentence until it makes sense.

The steady storyteller: autoregressive models

Most familiar chatbots generate text autoregressively. They predict the next token, add it to the text, and predict the next one. Each choice depends on the growing conversation.

This step-by-step approach works well when order matters: answering a question, writing a long explanation, or completing code from a cursor. It also makes streaming feel natural the model can start showing you its answer while it continues writing.

The trade-off? Those generation steps happen in sequence. The model has to produce one token before it can move on to the next.

The collaborative editor: diffusion models

A diffusion language model starts with a partly blank or noisy sequence. It predicts several missing tokens, then refines the result over multiple passes. Think of it as filling in a draft with context from both sides.

That makes diffusion appealing for tasks such as filling a gap in a document or editing several known regions. It can also predict multiple positions at once, creating the possibility of faster generation.

But parallel guesses can clash. If a model fills several parts of a list simultaneously, each item might look reasonable on its own while the overall list breaks the requested pattern.

	Autoregressive	Diffusion
How it writes	One token after another	Fills and revises multiple positions
Good fit	Chat, streaming, code continuation	Infilling, editing, structured drafts
Watch out for	Sequential generation can take time	Parallel guesses may need extra refinement

What researchers are learning

Recent papers show that diffusion’s potential speed advantage depends on the task. ParallelBench, an ICLR 2026 study, found that parallel decoding can lose quality when tokens depend strongly on one another. A useful reminder for developers: test on the patterns your users actually care about, not just on average benchmark scores. ParallelBench, ICLR 2026

Researchers are also trying to make diffusion models smarter about when to generate in parallel. Learn2PD, another ICLR 2026 paper, uses a lightweight filter to decide which token predictions are ready to accept. Its reported speedups are promising, but they come from specific experiments your results may differ. Learn2PD, ICLR 2026

So, which one should you choose?

For general chat, streaming, and tasks where every next word depends on the last, autoregressive models are a strong place to start. For filling gaps, revising multiple regions, or generating outputs with room for parallel work, diffusion models are worth testing.

The interesting question isn’t simply which model is faster. It’s whether your task gives a model enough room to work on several parts at once without losing the connections that make the answer correct.

Papers and further reading

Aaron Lou, Chenlin Meng, and Stefano Ermon. Discrete Diffusion Modeling by Estimating the Ratios of the Data Distribution (SEDD), ICML 2024.
Shansan Gong et al. Scaling Diffusion Language Models via Adaptation from Autoregressive Models, ICLR 2025.
Daniel Israel, Guy Van den Broeck, and Aditya Grover. Accelerating Diffusion LLMs via Adaptive Parallel Decoding, 2025.
Wonjun Kang et al. ParallelBench: Understanding the Trade-offs of Parallel Decoding in Diffusion LLMs, ICLR 2026.
Scaling Behavior of Discrete Diffusion Language Models, ICLR 2026.

AI Can Write Code. Engineers Still Have to Make It Work.

Jojo — Mon, 02 Nov 2026 05:50:59 +0000

Marc Benioff and Mark Zuckerberg have made bold predictions about AI and software engineering. But writing code is only one part of the job and the tools that generate it still need people to guide, review and improve their work.

Picture an AI coding assistant producing a patch that looks right. It compiles. The tests pass. But it misunderstands a requirement, breaks an older feature, or mishandles an unusual case.

Someone still has to notice.

That is my concern when I hear predictions that AI will replace software engineers. Generating code is not the same as building dependable software. Engineers have to understand what people need, fit changes into complicated systems, test what could go wrong and take responsibility for the result. AI can help with parts of that work, but it does not make the rest disappear.

In late 2024, Salesforce CEO Marc Benioff said the company might not add software engineers in 2025, citing productivity gains from AI tools. In January 2025, Meta CEO Mark Zuckerberg predicted that AI could become “a sort of mid-level engineer” that could write code. Those were significant statements, but they were forecasts about productivity and capability not proof that companies no longer need engineers.

There is a difference between a company deciding it can do more with its current team and a company being able to build and run software without engineers. Benioff’s comments were about Salesforce’s hiring plans. Zuckerberg was describing what he expected AI to be able to do. Neither statement, on its own, shows that AI can independently understand a product, maintain a large system and make sound decisions when something goes wrong.

A 2025 study by the research organization METR offers one useful test of the productivity claims. Sixteen experienced developers completed 246 tasks in open-source projects they knew well. For those tasks, the developers took 19% longer on average when they could use the AI tools tested. Yet after the study, they estimated that AI had made them faster.

That result needs context. It was a small study of experienced developers working in familiar, complex codebases, using a particular set of tools in early 2025. It does not prove that AI always slows engineers down. It does show that code generation and real-world productivity are different things and that perceived speed can differ from measured completion time. METR’s paper describes the study and its limits.

Google’s DORA research points to a related challenge at the team level. Its 2024 report found that higher AI adoption was associated with lower software delivery throughput and stability in the organizations studied. That is an association, not proof that AI caused the decline. The report suggests one possible reason: AI can help produce code faster, while larger changes can take longer to review and make systems less stable. Faster output still needs effective testing and review.

This is why engineers remain essential even when AI writes more of the code. People have to explain the goal, supply context the model may not have, judge whether the result meets the need, and feed mistakes and user feedback back into the system. That feedback might come from a failed test, a bug report, a customer who cannot complete a task, or an engineer who spots a security problem during review.
The same is true of the AI tools themselves. They depend on software, data pipelines, computing infrastructure, integrations, monitoring and safeguards. Engineers build and maintain those systems. Human feedback helps teams see where an AI feature is useful, where it fails, and what needs to change.

AI will change engineering work. It may automate some routine tasks, help teams move faster in some situations and affect how companies hire. But the real question is not simply whether AI can write code. It is whether it can reliably help deliver software that meets people’s needs and who checks that it does.

For now, the evidence supports a more careful conclusion than “engineers are being replaced.” AI can generate code. Engineers make sure that code belongs in a product, works in the system around it, and serves the people who use it.

Sources

Marc Benioff’s 20VC interview
Mark Zuckerberg’s January 2025 interview with Joe Rogan
METR’s developer productivity study
Google Cloud’s summary of the 2024 DORA report

I Asked My Neural Network to Try Again. Then I Asked It to Learn Only from Its Best Answer.

Jojo — Fri, 30 Oct 2026 20:40:16 +0000

Training a neural network can take a lot of time. I used to think the obvious fix was simply to make the model smaller or find faster hardware. Those can help, but I’ve learned that training time has several possible bottlenecks: the model’s architecture, the way it processes data and updates its weights, and how effectively it uses the hardware.

That led me to a more surprising question: What if a model generated several answers, but learned only from the best one?
The idea sounds simple. A model produces multiple candidate outputs. A scoring method picks the strongest candidate, and training focuses on that one. Instead of treating every attempt as equally useful, the model gives its learning signal to the answer that best meets the goal.

I found connections to selective backpropagation and rejection sampling. Selective backpropagation chooses which examples contribute to the model’s gradient updates. In some reinforcement learning fine-tuning methods, rejection sampling filters generated answers so that preferred ones can be used for further training. They share a broad idea—being selective about what the model learns from but they are not the same technique.

I also came across early exit architectures, which sound related but solve a different problem. They let a model stop processing an input early when it already has a confident answer. That can save computation during inference. It does not, by itself, mean generating multiple answers and training on only the best one.
The catch is that “try several and keep the best” is not automatically faster. Generating and scoring extra answers costs time, and the scoring method has to choose well. If it takes too much effort to find the winner or if the winner is not actually useful the approach may not save training time.

What I learned is that speeding up training isn’t only about making every step faster. It can also mean asking which steps are worth taking at all. The challenge is finding the right balance: give the model enough chances to produce a strong answer, then make sure the learning signal goes to the attempts that genuinely help it improve.

From Rules to Reasoning: How AI Evolved into Agents

Jojo — Sun, 25 Oct 2026 21:53:15 +0000

When I look at how artificial intelligence has developed, I see a journey from computers that could only follow instructions to systems that can understand a goal and take steps toward completing it. AI didn’t arrive all at once. Each stage built on the ideas and technology that came before it.

The flow of AI’s evolution is:

It began with rules

The modern field of AI is often traced to a 1956 workshop at Dartmouth College, where researchers explored whether machines could imitate parts of human intelligence. Dartmouth’s history of AI

The earliest AI programs worked by following rules that people had written for them. They could solve puzzles, prove mathematical statements, or play simple games but only when the problem fit the rules they had been given. If something unexpected happened, they usually couldn’t adapt.

That makes me think of these systems as highly capable instruction followers. They could do specific jobs, but they couldn’t learn from experience or handle every situation on their own.

Then AI learned from examples

Researchers eventually began asking a different question: what if, instead of writing every rule, we gave computers examples and let them find patterns?

That idea led to machine learning. A system could study examples—such as labeled pictures of cats and dogs and learn to tell them apart. It didn’t need someone to spell out every feature to look for.

Machine learning helped power tools such as recommendation systems, fraud detection, and speech recognition. AI was becoming more adaptable, but most systems were still designed for one kind of task at a time.

Deep learning helped AI recognize more complex patterns

As computers became faster and more data became available, deep learning made it possible to train larger neural networks. These systems could learn complex patterns in images, speech, and text.

This helped improve voice assistants, image recognition, and language translation. Instead of relying on people to define every useful feature, a deep learning system could learn many of those patterns from data.

AI was getting better at understanding different kinds of information, but its skills were often still separated. One system might recognize speech while another translated it. People had to connect the pieces.

Large language models made AI easier to talk to

Large language models changed how many of us interact with AI. We could ask questions in everyday language and get help writing, summarizing, brainstorming, or coding.

That made AI feel more accessible. I didn’t need to know a special command or how a system worked behind the scenes; I could describe what I wanted.

But a useful answer isn’t always the same as a completed task. A language model might explain how to find information or update a document, but it couldn’t necessarily do those things by itself. It could also make mistakes or present uncertain information as if it were true.

Now AI is moving from answering to acting

Today’s AI agents build on language models by giving them access to tools. Depending on the system, an agent may be able to search the web, work with files, run code, or interact with other software.

The change is that I can give an agent a goal, and it may break that goal into steps, use tools, check what happened, and continue. A chatbot might suggest how to plan a trip; an agent might research options and prepare an itinerary. A coding assistant might suggest a change; an agent might edit files and run commands.

“AI agent” can describe systems with very different levels of independence, though. Some need frequent direction, while others can work through several steps with less supervision. A recent survey of deployed agents found variation in both their capabilities and their published safety information. 2025 AI Agent Index

This evolution is impressive, but today’s agents still make mistakes. They can misunderstand instructions, choose the wrong tool, or lose track of a detail in a longer task. Stanford’s 2026 AI Index reported that AI systems had improved on a benchmark of multistep assistant tasks, while still trailing the reported human baseline. Stanford HAI, AI Index 2026

That’s why I think trust will matter as much as capability. An agent that drafts an email is different from one that sends it. An agent that prepares a purchase is different from one that completes it. People need to know what an agent can access, what it can change, and when it should ask for approval.

AI has evolved from following rules to learning from data, communicating with us, and beginning to take action. The next step is making agents reliable enough to handle more complex work and clear enough that we can stay in control.

Building an AI Issue Triage Assistant with Python, Spring Boot, and React

Jojo — Mon, 12 Oct 2026 18:50:21 +0000

GitHub maintainers spend time reading new issues, deciding which label fits, and checking whether a similar report already exists. I built an Issue Triage Assistant to explore how machine learning can make that first pass faster while keeping the final decision with a person.

The app takes an issue title and optional description. It suggests one of three labels—Bug, Docs, or Enhancement—and links to five related pandas issues. You can try the public demo or explore the code on GitHub.

This project helped me connect several technologies in one workflow: Python for data and ML, FastAPI for model serving, Spring Boot for a Java API layer, and React for the local browser interface.

Project workflow

Starting with real issue data

I used the GitHub Search API to collect 1,000 recent issues from pandas-dev/pandas. For each issue, I saved its title, description, labels, URL, and creation date. Using public issues made the project more realistic than training on a handful of invented examples.

The raw labels needed care. An issue can have many labels, or none. For classification, I kept an issue only when it had exactly one of the three target labels. That gives each training example one clear answer without pretending that every pandas label belongs to my three-class problem.

I also removed label-like prefixes such as BUG:, DOC:, and ENH: from titles before training. Otherwise the model could learn to spot the answer in the title prefix instead of learning from the actual report. That was an important lesson about data leakage: a model can appear useful while relying on a shortcut that will disappear in real use.

Two kinds of text features

The classifier combines two representations of each issue:

TF-IDF word features capture useful words and two-word phrases. Terms such as read_csv, error, or documentation can be strong clues.
Sentence embeddings from the all-MiniLM-L6-v2 model capture broader meaning, even when two reports do not use exactly the same words.

I join those features and train a balanced logistic regression classifier. TF-IDF uses the title and up to 1,500 characters of the description; the sentence embeddings use the title and up to 1,000 characters. A stratified train/test split produces a held-out classification report; after that check, the final model is retrained on all eligible labeled issues and saved for the app.

In an evaluation run on October 13, 2026, 713 of the 1,000 collected issues had exactly one target label: 459 Bug, 144 Docs, and 110 Enhancement. On a 143-issue held-out set, the classifier reached 0.94 accuracy. F1 scores were 0.96 for Bug, 0.88 for Docs, and 0.91 for Enhancement. These numbers measure label classification on this dataset, not whether the search finds actual duplicates. The class counts and scores can change when the issue collection is refreshed.

Finding related issues

For search, I create a sentence embedding for every stored issue and normalize the vectors. The incoming report is embedded the same way. The app ranks stored issues by the dot product of the normalized vectors, which is cosine similarity, and returns the top five with links to the original GitHub reports.

This is similarity search, not a verified duplicate detector. A high score says that the texts are close in the model's vector space; it does not prove that the reports describe the same bug. Even two reports about read_csv might involve different failures. A maintainer needs to open the links and decide what they mean.

The search also has a clear boundary: it can only return issues among the 1,000 collected reports. If a relevant issue is outside that collection, the app cannot find it.

Connecting Python, Java, and React

The local full-stack version has this request path:

React + Vite → Spring Boot /api/analyze → FastAPI /analyze → Python model

The React page sends a title and optional description. Spring Boot forwards the request to FastAPI. Python loads the saved classifier, predicts a label, runs the similarity search, and returns both results. React then displays the suggested label and linked reports.

I added the Java layer to practice connecting services across languages and keeping a clear API boundary. It also made me think about request and response contracts: the browser, Java service, and Python service all need to agree on the same JSON fields.

For the public demo, I built a separate Streamlit interface that loads the same saved Python model and search index directly. This lets someone try the project through one link without starting three local servers. The React/Spring Boot/FastAPI flow remains in the repository for anyone who wants to run and inspect the full-stack architecture.

Trying a report

For example, enter:

read_csv crashes when the file has an empty header

The demo suggests Bug and returns five related pandas issues. The linked reports are starting points for investigation, not an automatic duplicate verdict. You can also try the documentation and enhancement examples in the demo to see how the predicted label changes with the wording and context.

What I learned and what comes next

The most useful lesson was that building an ML feature includes more than fitting a model. I had to collect and clean data, prevent easy label leakage, evaluate on held-out examples, make inference consistent with training, design an API, and explain the limits of the output in the interface.

There is still room to improve. The current collection is limited, and I have not built a benchmark of confirmed duplicate and non-duplicate issue pairs. A next step is to create such an evaluation set and measure whether the related-issue ranking actually helps find true duplicates. I would also expand and refresh the issue index and track classification performance separately for Bug, Docs, and Enhancement over time.

If you try it, I would be interested in examples where the suggested label or related issues are useful—or where they clearly miss the mark. Those cases are the best guide for the next iteration.

Disclosure: This article was drafted and edited with AI assistance. Its technical claims were checked against the project source code.