Boris Cherny and Agentic Programming Practice

1. From Individual Developer to Agentic Programming Practitioner

Boris Cherny is a long-time software engineering and artificial intelligence practitioner who has worked on intelligent programming tools at an AI company and led related engineering work. His public value is not only that he helped build a tool, but that he has demonstrated a software development style that depends heavily on AI agents.

This style differs clearly from the traditional pattern in which a developer writes code and a tool supplies completions. Traditional assisted coding is usually developer-led and handles one function, one file, or one local problem at a time. Agentic programming asks the AI to understand the task goal, analyze the codebase, modify multiple files, run tests, and continue correcting the work based on results. The developer’s main job gradually shifts from typing code line by line to breaking down tasks, designing constraints, accepting results, and governing the system.

Cherny’s experience also points to an important trend: foundational software engineering skill still matters, but the skill mix is changing. Developers still need syntax and frameworks, yet they must also master system design, code review, automated testing, version control, risk control, and methods for collaborating with agents.

2. From Early Programming to Engineering Practice

According to public accounts, Cherny began programming in secondary school, initially learning on a graphical computing device. The lasting value of that early experience was not the device itself, but several habits that remain useful:

1. Break problems into executable steps.
   Programming often starts with simple calculations and grows into conditionals, loops, data processing, and modular design. That process builds the ability to turn a complex problem into explicit steps.

2. Correct the work through feedback.
   Program output, error messages, and edge cases test whether a design is sound. Code generated by AI still has to be validated through compilation, tests, and runtime results.

3. Develop abstract thinking.
   High-quality software is not a pile of code. It depends on clear data structures, module boundaries, and interface constraints. AI can generate implementations quickly, but it cannot replace a developer’s judgment about business goals and system boundaries.

AI does not make foundational engineering skill obsolete. The opposite is true: the more code is generated, the more developers need to recognize flawed designs, hidden dependencies, and long-term maintenance cost.

3. How Multi-Session Parallel Work Changes the Development Flow

Cherny has described a highly concurrent way of working: several terminals and several AI sessions run at the same time, with different agents handling different tasks. The point is not simply to open more windows. It is to split development into independent task units with clear boundaries.

A larger feature, for example, might be divided as follows:

• Session 1: analyze the existing code structure and dependencies
• Session 2: design data model or interface changes
• Session 3: write unit tests
• Session 4: implement the main business logic
• Session 5: check error handling and security risks
• Session 6: organize technical documentation and change notes

Parallel work can reduce waiting time, but only when coupling between tasks is low. If several agents edit the same core files at once, they may conflict, overwrite each other’s changes, or produce an inconsistent design. Sound scheduling usually follows these principles:

1. Analyze before modifying

Before code is generated, the agent should read the directory structure, configuration files, interface definitions, and test cases, then state its understanding of the system. Implementation should begin only after the developer confirms that understanding.

2. Define inputs and outputs

Each task should state the scope of change, modules that must not be touched, acceptance criteria, and expected deliverables. “Add caching” is not enough. The request should also specify which request types the cache covers, the invalidation policy, fallback behavior on failure, and the tests that must be added.

3. Use isolated environments

Parallel tasks are best run on separate branches, temporary workspaces, or other isolated environments. After a task finishes, the developer reviews and merges the result so agents do not overwrite one another.

4. Make tests a shared language

Agents should not hand work off through natural language alone. Test results, static checks, and structured change records should also carry context from one task to the next, reducing the risk of lost context.

4. The Value and Limits of Overnight Automation

Cherny has also described running multiple agents continuously overnight. While the developer is away, agents can analyze code, fill in tests, organize documentation, check dependencies, or compare candidate approaches. The developer reviews the results the next day.

The value shows up in three ways:

• Better use of time. Time-consuming tasks with clear rules can run outside working hours.
• Broader exploration. Agents can try several implementations and present candidates.
• Faster feedback. Test failures, static-analysis warnings, and dependency issues can surface earlier.

Overnight automation does not mean agents should be free to change production systems. High-risk operations need permission boundaries:

• Do not allow automatic access to sensitive production data.
• Do not allow unapproved file deletion, core configuration changes, or releases.
• Restrict external network access, secret reads, and data export.
• Keep logs for every change and trace them to a specific task.
• Run full tests and human review on automatically generated code.

A safer pattern is to let agents do advisory work overnight: generate patches, raise issue lists, or draft tests, rather than perform irreversible actions directly.

5. What “A Correct Plan Makes Correct Code” Means in Engineering

Cherny’s central idea can be summarized this way: if the plan is accurate enough, the implementation is more likely to be correct. That does not mean AI-generated code is inherently reliable. It stresses the importance of understanding requirements and planning the task.

A high-quality plan should at least cover:

1. What the goal is. State the business problem to solve, not only a button or an interface to add.
2. What the current state is. Describe existing modules, data flow, dependencies, and known limits.
3. Where the boundary is. State what is out of scope so the agent does not expand the change.
4. How to verify it. Specify test scenarios, error cases, performance requirements, and compatibility requirements.
5. What happens on failure. Design rollback, degradation, and error messaging.

A task description can be structured as follows:

Task goal:
Modules to modify:
Parts that must not be modified:
Inputs and outputs:
Error handling:
Test requirements:
Acceptance criteria:
Rollback method:

This structure reduces ambiguity and makes it easier for several agents to work together. On a large project, one agent can analyze and plan, others can implement, and a separate agent can review, forming a plan-implement-verify pipeline.

6. The Practical Challenges of Nearly 100% AI-Generated Code

Cherny has shared a practice of using AI to generate a very large share of his code, approaching full reliance on AI for coding. That can be highly efficient, but it does not mean the developer no longer needs programming skill.

First, faster generation increases review pressure. AI may produce code that is syntactically correct but architecturally unsound, or that omits permission checks, resource cleanup, concurrency control, and error handling.

Second, more code creates more maintenance burden. Without shared coding standards and module boundaries, short-term speed can become long-term complexity.

Third, AI amplifies unclear requirements. When the requirement is vague, an agent can quickly build a system that looks complete but is wrong. What should be automated is repetitive work and verifiable steps, not every judgment.

Teams that want a similar model should put these controls in place:

• Require code review.
• Maintain unit tests, integration tests, and regression tests.
• Use dual approval for sensitive modules.
• Keep AI interaction records and task logs.
• Run static analysis and dependency security checks.
• Assess generated code for license, privacy, and security risk.
• Regularly remove dead code, duplicate implementations, and outdated documentation.

7. How the Developer Role Changes

Cherny has suggested that the traditional title “software engineer” may gradually give way to a broader “builder” role. Whatever the name becomes, the trend is clear: the developer’s scope is expanding from implementing code to solving the whole problem.

Future developers may take on several responsibilities at once:

• Requirements analyst: turn a vague goal into an executable specification
• System designer: decide module boundaries, data flow, and technical direction
• Agent coordinator: split tasks and arrange collaboration among agents
• Quality owner: verify function, security, stability, and maintainability
• Risk manager: control permissions, data, release, and rollback risk
• Product builder: move from an idea to a verifiable prototype and system

This does not retire traditional programming knowledge. People who understand underlying mechanisms are better at spotting hazards in AI output and at locating and fixing complex failures.

8. From Individual Practice to Team Standards

An individual developer can gain speed from multiple sessions and overnight tasks, but a team also has to settle collaboration standards, permission management, and accountability. A practical path is to pilot low-risk work first—test generation, documentation cleanup, log analysis, and refactoring—and only then expand into business feature development.

A mature AI software engineering process should have four properties:

1. Tasks can be split. Goals break into independent, verifiable steps.
2. Results can be verified. Every deliverable has tests, review, or explicit acceptance criteria.
3. The process can be traced. It is possible to record who started a task, what the agent did, and how the code changed.
4. Risk can be rolled back. Important changes can be undone, and critical actions do not depend on a single agent’s judgment.

Overall, Boris Cherny’s practice is best read as an experiment in how software engineering is organized: AI agents expand parallel capacity, while humans own goal definition, boundary control, and quality acceptance. What is worth borrowing is not the number of open sessions, and not the pursuit of writing no code at all. It is an engineering system that lets agents work efficiently while keeping results under continuous control.