Code Like Humans: Iterative, Human-Centric Coding
- Code like Humans is a paradigm that defines coding as an iterative, human-like process focused on incremental refinement, debugging, and balancing performance trade-offs.
- Methodologies such as EvoCodeBench and CoCoNUT evaluate code based on iterative improvements, human-readable patterns, and comprehensive metrics like pass rate, runtime, and memory efficiency.
- Applications include enhancing maintainability, security, and human–agent collaboration, ultimately aligning AI-generated code with real-world software development practices.
“Code like humans” denotes a research orientation in which code systems are evaluated not only by whether they produce correct outputs, but by whether they resemble human programmers in iteration, debugging, performance trade-offs, language robustness, explanation, collaboration, and maintenance behavior. In this framing, coding is a trajectory rather than a single emission: strong systems are expected to read a specification, draft a solution, inspect failures, revise code, and balance correctness with runtime, memory, and language-specific constraints. The phrase also extends beyond generation to editing, evaluation, security, testing, and software interaction, where the central question is whether machine behavior aligns with human coding practice rather than merely with endpoint accuracy (Zhang et al., 10 Feb 2026).
1. Human-like coding as behavior, not just output
A central claim in this literature is that human programming is bimodal: code is executed by machines, but it is also read, maintained, and judged by humans. This helps explain why developers do not use all semantically equivalent forms that programming languages permit. “Natural” code is highly repetitive, and meaning-preserving transformations such as operand swapping, some parenthesis changes, and variable renaming generally make code less probable under LLMs trained on real corpora; human-subject results show alignment between language-model preference and human preference for familiar forms (Casalnuovo et al., 2019).
Within coding benchmarks, human-like behavior is characterized less by one-shot correctness than by iterative refinement. EvoCodeBench states that strong coding systems should not just “spit out” correct code once, but should behave more like human programmers: iterating, debugging, trading off speed vs. safety, and adapting their behavior over the course of solving a problem. It therefore evaluates within-inference refinement, repeated submissions under a revision budget, changes in correctness and efficiency across attempts, and resource costs such as solving time and memory consumption (Zhang et al., 10 Feb 2026).
The same idea appears in software testing. “Machines that test Software like Humans” replaces DOM- and pixel-specific automation with English-like test scripts, OCR, CNN+LSTM-based GUI element localization, and mouse/keyboard interaction through Java’s Robot class, so that the system reads test instructions, looks at the screen, finds the relevant component, and acts on it as a manual tester would. Tests are authored in a constrained DSL implemented via xBase, and the prototype is trained on approximately 2200 manually annotated examples, with the authors reporting that DSL-based authoring works extremely well while web-element identification shows moderate results (Dwarakanath et al., 2018).
2. Trajectory-aware evaluation and self-evolving coding systems
EvoCodeBench is the most explicit formalization of “code like humans” for LLM-driven coding systems. It is built on LeetCode’s online judge, with a task pool of 3,822 algorithmic problems at crawl time and a held-out evaluation set of 100 recent problems to reduce contamination. Evaluation spans five languages—Python3, C++, Java, Go, and Kotlin—and compares two agents: a vanilla coding agent with one submission, and a self-evolving coding agent with up to 3 reflection–revision rounds. Each revision round receives a judge verdict such as Accepted, WA, TLE, MLE, CE, RE, plus runtime, memory, and human percentiles, while keeping the problem statement, prompt schema, and model parameters fixed; only the solution code changes during evolution. Capability metrics include Pass Rate, TLE, MLE, CE, RE, WA, TO, and RpE, while efficiency metrics include average runtime, average memory, average passed test cases before failure, cumulative runtime, Average Runtime Beats, and Average Memory Beats. This makes the core correctness metric effectively a multi-try pass rate bounded by 3 revision attempts for evolving agents (Zhang et al., 10 Feb 2026).
The benchmark’s empirical results show that iterative refinement changes both accuracy and efficiency. Using Gemini‑3‑Flash, the self-evolving agent improves pass rate from 79 to 87 in Python3, 84 to 99 in C++, 84 to 98 in Java, 82 to 95 in Go, and 75 to 95 in Kotlin. Average runtime also decreases from 1376.19 to 1269.39 ms in Python3, 266.04 to 142.60 ms in C++, 125.04 to 96.30 ms in Java, 139.22 to 111.64 ms in Go, and 171.99 to 122.83 ms in Kotlin. CE, RE, TO, and RpE often drop to zero; WA and TLE shrink substantially; and runtime-beats rise sharply in compiled languages, including C++ from 68.02 to 88.99 and Java from 71.03 to 88.33. The benchmark therefore argues that self-evolving behavior yields both higher accuracy and better human-relative efficiency, especially in languages with stricter tooling such as C++, Java, and Kotlin (Zhang et al., 10 Feb 2026).
| Language | Pass Rate | Average Runtime |
|---|---|---|
| Python3 | 79 → 87 | 1376.19 → 1269.39 ms |
| C++ | 84 → 99 | 266.04 → 142.60 ms |
| Java | 84 → 98 | 125.04 → 96.30 ms |
| Go | 82 → 95 | 139.22 → 111.64 ms |
| Kotlin | 75 → 95 | 171.99 → 122.83 ms |
This trajectory-aware perspective differs sharply from static benchmarks such as HumanEval, MBPP, APPS, or CodeContests, which focus on endpoint pass rate under fixed inference behavior. A plausible implication is that human-like coding competence is partly invisible under one-shot evaluation, because many failures are only one or two edit steps away from correctness or efficiency improvements (Zhang et al., 10 Feb 2026).
3. Human-relative performance, cross-language robustness, and security
Human-likeness in coding is not exhausted by correctness. EvoCodeBench explicitly grounds evaluation in the human ability distribution by using LeetCode’s runtimeBeats and memoryBeats, which are aggregated as ARB and AMB. These percentiles show that a model can be highly efficient conditional on success while still lacking coverage. For example, deepseek-v3.2 can have ARB approximately 73% and AMB approximately 74% on C++, but a very low PR of 11; GPT‑5.2 reaches PR values of 84 in Python3, 90 in C++, 91 in Java, 90 in Go, and 78 in Kotlin, with Kotlin showing CE = 17 versus 0–4 in other languages. Kotlin is used as a long-tail language with approximately 0.97% TIOBE market share compared to Python’s 22.61%, and the benchmark reports that nearly all models show lower PR and more compile errors in Kotlin, even though accepted Kotlin solutions often achieve high ARB and AMB. This separates language robustness from conditional efficiency and shows that human-like coding must include stability across languages, not just good solutions in Python or C++ (Zhang et al., 10 Feb 2026).
Security studies add another dimension. “How to Compare the Security of Code Written by Humans to LLM-generated Code” proposes an automated, species-fair framework for human-only, LLM-only, and hybrid comparisons under symmetrical tasks, environments, and metrics. It stores exercises in git and SQLite, executes code inside rootless Podman containers with no external network, records prompts and metadata, checks correctness, measures clarity via cyclomatic complexity and function length, and runs Ruff with Bandit security rules such as S101, S105, S113, S311, and S324. In the feasibility study, five OpenAI models generate 3,832 solutions for 13 Python exercises, of which 2,615 are correct. Aggregated failures include 426 “No output,” 394 “WrongLogic,” and 194 SyntaxErrors. Correct human reference solutions are 100% correct by construction but are acknowledged to be non-representative. Among correct solutions, humans have the lowest cyclomatic complexity at , while gpt-4.1 has and gpt-5-mini ; human function length is , compared with for gpt-4.1 and for gpt-5.1. The study concludes that LLMs and humans often share vulnerability patterns such as insecure randomness or insecure hashing when a task invites those mistakes, but that LLMs remain less consistently correct and typically produce more complex code than strong human baselines (Balebako et al., 29 May 2026).
A recurrent misconception is that “superhuman at coding” is a single status. These results indicate that human-relative coding performance is multidimensional: coverage, runtime efficiency, memory efficiency, language robustness, output discipline, and security behavior can diverge sharply within the same model (Zhang et al., 10 Feb 2026).
4. Structural reasoning, explanations, and developer-style thought
Several studies argue that human-like coding requires more than emitting correct code; it requires structural understanding and explicit reasoning. CoCoNUT tests this directly by asking models to predict execution traces rather than final outputs. It contains 285 tasks and 1703 traces, including HumanEval-derived traces plus advanced subsets for recursion, concurrency, and object-oriented programming. Despite strong performance on HumanEval, even the top-performing model, Gemini, can fully and correctly generate only 47% of HumanEval task traces. Accuracy collapses with longer traces, and besides OOP, none of the investigated models achieve accuracy over 5% on recursion or concurrency. The benchmark therefore concludes that high performance on code generation does not correlate with humans’ ability to follow structural control flow and mentally simulate execution (Beger et al., 27 Jan 2025).
Reasoning-oriented fine-tuning attempts to close this gap by teaching models to think in the style of human developers. SVRC mines, restructures, and enriches community discussions from LeetCode into SDLC-aligned reasoning chains containing problem understanding, planning, design, implementation, testing, and iterative refinement. The resulting dataset, SVRC, contains 12,444 reasoning-augmented samples, averaging 5,546 tokens each, and is used to fine-tune CodeThinker from Qwen2.5-Instruct-32B. On LiveCodeBench, CodeThinker surpasses its base model by 42.86% on medium-level code problems in terms of pass@1 and outperforms GPT-4o-mini and GPT-4o by 73.14% and 115.86%, respectively; ablations show that raw community discussions can hurt, while discussion completion, format perturbation, SDLC structuring, and iterative refinement each contribute to reasoning quality (Yang et al., 19 Mar 2025).
Human-like coding also includes explanation. In introductory-programming settings, ChatGPT-generated line-by-line explanations are much closer to expert-written explanations than to student-written explanations on METEOR, USE, and BERTScore, and they are comparable to experts in vocabulary size and length. However, they are less readable on Gunning Fog, Flesch Reading Ease, and Flesch–Kincaid Grade Level, especially under more elaborate prompts. This suggests that current LLMs can explain code like expert humans in semantic content, but do not yet teach like humans in terms of readability and novice adaptation (Lekshmi-Narayanan et al., 2023).
5. Human–agent collaboration, debugging curricula, and AI-friendly code
Another strand of work treats “code like humans” as learning from the artifacts of real software development rather than from standalone solutions. AgentPack assembles 1,337,012 code edits co-authored by Claude Code, OpenAI Codex, and Cursor Agent across public GitHub repositories up to mid-August 2025, totaling 59 GB of patches. The median edit touches 2 files, changes 70 patch lines, spans 1.5 hunks, and has a median message length of 323 characters—far longer and more explanatory than prior human-only corpora such as CommitPackFT or CanItEdit. The dataset contains merged, primary-branch edits only, thereby filtering for changes accepted by maintainers. Fine-tuning DeepSeekCoder-1.3B on an AgentPack subset raises HumanEvalFix from 0.20 to 0.32 relative to EditCoder, and raises CanItEdit from 0.29 to 0.32; for DeepSeekCoder-6.7B, HumanEvalFix improves from 0.45 to 0.48 while CanItEdit remains competitive at 0.41 versus 0.42. This supports the view that human–agent co-authored trajectories, rather than final code alone, are valuable supervision for human-like editing behavior (Zi et al., 26 Sep 2025).
Debugging curricula provide a complementary angle. AP2O-Coder constructs an error notebook from failed code, labels failures by type, progressively optimizes the model to correct errors type by type, and periodically replays the model’s current weaknesses. The method preserves the DPO loss but changes how preference pairs are built and scheduled. Across Llama, Qwen, and DeepSeek models from 0.5B to 34B, AP2O-Coder improves code generation performance by up to 3% in pass@k while using less preference data, and error analyses show systematic reductions in runtime and logical failures such as SyntaxError, TypeError, KeyError, IndexError, and WrongResult (Zhang et al., 1 Oct 2025).
Maintainability studies extend human-likeness from model behavior to codebase properties. “Code for Machines, Not Just Humans” evaluates 5,000 Python files from competitive programming and defines AI-friendly code operationally as code on which LLM refactoring preserves semantics and improves maintainability. It uses CodeHealth, a file-level score from 1 to 10, with Healthy defined as , Warning as , and Alert as . Across medium-sized local models, Healthy files show 15–30% lower refactoring break risk than Unhealthy files; in decision trees using CodeHealth, perplexity, and SLOC, CodeHealth is always the most important feature, and root splits cluster around the healthy boundary at approximately CH 0. This suggests that code written to minimize human cognitive load—low complexity, shallow nesting, simpler conditionals, smaller functions—also becomes safer terrain for AI agents (Borg et al., 5 Jan 2026).
6. Adjacent domains, limits, and research directions
The “code like humans” paradigm also appears in adjacent software-engineering tasks. In legacy modernization, “Can LLMs Replace Humans During Code Chunking?” shows that LLMs can select partition points closely aligned with human expert partitioning in MUMPS and IBM assembly language code, and that LLM-created partitions produce comments that are up to 20% more factual and up to 10% more useful than when humans create partitions. In no-code cobot programming, RATS demonstrates that LLMs are capable of generating accurate first-order code for repetitive assembly tasks, but have problems producing higher-order code such as functions and loops. In GUI testing, the vision-based system described above suggests that human-like software interaction may depend on combining natural-language instructions with perceptual grounding rather than implementation-specific selectors (Glasz et al., 24 Jun 2025, Kranti et al., 2024, Dwarakanath et al., 2018).
Across these studies, a common design pattern emerges: explicit human rules, structured intermediate reasoning, and closed-loop feedback tend to improve alignment with human behavior. In autonomous driving, InstructDriver encodes human rules such as collision avoidance and traffic-light compliance as instruction text and uses a four-step InstructChain to produce interpretable plans in closed-loop nuPlan evaluation. A plausible implication is that coding systems may benefit from analogous “rule blocks” and domain-specific reasoning chains that make design choices, failure analysis, and trade-offs explicit rather than latent (Zhang et al., 2024).
The limitations are equally consistent. EvoCodeBench uses only 100 held-out problems and has human comparisons only through runtime and memory percentiles rather than human pass-rate trajectories. CoCoNUT is Python-centric and shows that structural execution tracing remains a major weakness. The security framework is presently a feasibility study, with no empirical hybrid condition yet. AgentPack captures only final landed edits, not the original human prompt or failed intermediate attempts. AP2O depends on automatic error analyzers and currently targets error types exposed by tests and interpreters. SVRC1 is Python-only and LeetCode-centric. Collectively, these results suggest that human-like coding is not a single benchmark score but an open research program spanning dynamic evaluation, human-relative baselines, structural reasoning, maintainability, collaboration, and domain-specific workflow modeling (Zhang et al., 10 Feb 2026, Beger et al., 27 Jan 2025, Balebako et al., 29 May 2026, Zi et al., 26 Sep 2025, Zhang et al., 1 Oct 2025, Yang et al., 19 Mar 2025).
A plausible synthesis is that “code like humans” now refers to a family of measurable properties: preference for familiar idioms, explicit reasoning over structure and constraints, iterative self-correction, calibration against human performance distributions, sensitivity to security and maintainability, and competence within real collaborative workflows. Systems that satisfy only one of these properties may generate useful code, but they do not yet reproduce the broader repertoire of human software development.
