Header image generated by AI

By Tian Yu

Edited by Shen Xiao

On October 19, MiniMax M3.1 Flash was released; on October 17, DeepSeek-V4.1-Flash-1017 was updated. A few days earlier, Meta introduced Muse Spark Open; OpenAI updated GPT-6 Pro's parallel Agent capabilities; Google also launched Gemini 4 Argon for complex tasks...

Model iterations are accelerating, and AI programming tools are continually transforming how developers work. Generating code, building websites, and developing games can now be accomplished in just a few rounds of dialogue. But does writing code faster mean software is easier to make?

In the podcast 'Beyond Coding,' host Patrick Akil asked lead architect Carlos Kelkboom a question: What is the most noticeable change in software engineering compared to a few years ago?

Carlos replied, 'I've noticed a phenomenon I don't particularly like: collaboration among developers is decreasing.' 'You'll work with your own Agent, but you're no longer working with the team.'

The changes AI brings to programming go far beyond code generation itself. How to control code quality, coordinate different Agents to work together, and retain engineering judgment amid efficiency gains have all become new challenges developers should face.

Around these issues, Carlos shared his practical experience. He summarized five principles that provide a concrete perspective for understanding AI programming:

1. Personally build the code skeleton, determining directories, key files, and function signatures in advance.

2. Prohibit the main Agent from directly modifying code and files; only activate the execution Agent after fully understanding the requirements.

3. If the generated code is incomprehensible, throw it away. Isolate execution results in the working tree, and if they deviate from the expected structure, discard and start over.

4. Have Agents complete larger tasks in one go as much as possible, avoiding repeated modifications that lead to constant patching of code.

5. Let multiple Agents explore different solutions in parallel—for example, have three Agents develop separately, then let a fourth Agent compare results and merge only the good parts.

Against the backdrop of reduced collaboration, there's an even more direct issue: AI makes it easy to start projects but doesn't make completing them equally easy. The host has felt similarly, noticing that while he can easily start many projects, he often fails to finish them.

Carlos once started five compiler projects, but only one was truly completed. Projects that begin but aren't finished aren't unique to the AI era. To create products, developers can't remain stuck in the stage of constant experimentation.

Carlos compares it to a marathon versus a sprint: 'Quickly making something without finishing it is different from making something you hope will last. When working alone on a project, you usually don't take that extra step to truly finish it.'

Carlos also uses game development as an example: 'For instance, you'll see many people 'quickly' make games. I put 'quickly' in quotes because the biggest issue in game development is listening to user feedback and getting the design right. You can iterate repeatedly with intelligent agents, but you still need to communicate with the outside world.'

As generating code becomes easier, developers can quickly achieve initial results. However, they may not be willing to invest sustained time in solving subsequent engineering problems. Carlos warns developers: 'You must resist the dopamine rush of getting something immediately.'

If quickly starting projects is the convenience AI programming brings, then how to keep projects iterating continuously becomes a bigger concern for Carlos.

Carlos introduces his workflow: Before starting development, he manually creates directories and files, sometimes supplementing them with language specifications, code examples, and relationships between modules. This process usually takes 20 minutes to an hour.

He calls this step 'Scaffolding': 'For example, if I'm writing a compiler, I'll first set up the directories, write the lexer, then add some language specifications. I'll arrange the directory structure for how intermediate representations flow from the abstract syntax tree and write many examples in the target language. After that, the Agent can directly generate a compiler perfectly suited to the language, like a master.'

He explains why he does this: 'I've found that Agents are good at finding a solution by brute force, but they often forget how that solution fits into the entire application.'

Carlos once tried having an Agent develop an application from scratch. After a month or two, he found the code increasingly difficult to understand—original deployment scripts were replaced by others, and the purposes of some new scripts were unknown.

Carlos suggests that when facing unfamiliar domains, one can first find mature open-source projects, have an Agent extract their excellent design patterns, and then, after understanding them, gradually build scaffolding starting from small-scale proof-of-concepts, having the Agent help check if the design is reasonable.

Based on a clear early framework, Carlos prefers to plan complete features in advance and then let the Agent complete larger tasks in one go.

'Agents aren't good at modifications but excel at one-time completion. Their training seems closer to one-time tasks rather than iterative development on a codebase,' Carlos says. 'This is where scaffolding comes into play—most things are already defined.'

Of course, Carlos doesn't advocate spending the same amount of preparation time on all projects. For simply validating an idea, developers can absolutely try quickly and restart immediately if the direction is wrong.

He shares a method for parallel exploration: 'Create three branches, have three Agents work separately in each branch or working tree. Then let a fourth Agent compare the three results and merge only the good parts.'

AI can quickly generate code and continuously modify it based on feedback. However, as project scale grows, issues like redundant implementations, module confusion, and architectural drift gradually accumulate.

Carlos once had an Agent develop a compiler. A month later, when he asked it to check list functionality, he found the same feature had been redundantly implemented five times. Each modification might have solved the immediate problem, but after repeated superposition (overlays), the code became increasingly difficult to maintain.

So, he regularly checks whether the code aligns with expectations. If the implementation direction deviates, he prefers to revert and redo rather than continue patching on an incorrect foundation.

Carlos puts it bluntly: 'They're currently not good at building a complete application.' He has another criterion: 'If I don't understand it, I throw it away.'

Here, 'not understanding' means the code has deviated from the originally set structure and expectations. Carlos first checks whether the implementation aligns with the design; if key parts don't match, he reverts the current results, re-clarifies requirements and scaffolding, and then starts a new task.

In China, Meituan's technical team publicly shared an engineering practice in May this year. The business system they managed had grown to 310,000 lines of code, with over 90% generated by AI. As the system rapidly expanded, the team found that without unified architectural specifications, code generated by different developers using AI exacerbated system complexity, and historical technical debt slowed down subsequent iterations.

To address this, the team converted engineering specifications into rules executable by AI, added an AI self-check step before code submission to have the model first inspect specifications, defects, and exception handling, and then had engineers focus on reviewing business logic and technical solutions.

Individual developers control code quality through periodic checks, while enterprise teams need to implement specifications through automated checks and review processes. This shows that as code generation speed increases, quality checks must keep pace.

Since Agents can generate large amounts of code at once, reviews face new pressure. Carlos suggests maintaining normal iteration and review processes: 'People often use code volume as an excuse. But if there's too much code, why not have the Agent write less?'

Instead of generating large amounts of code at once and then conducting centralized reviews, it's better to control the scale of each change, increase review points, and retain discussions among developers. This makes it easier to spot issues and helps the team understand why code changes occur.

Carlos also designed a special Agent workflow: The main Agent in direct conversation doesn't modify code or touch the file system—it only handles interaction. When it's time to work, it dispatches sub-Agents. Meanwhile, another main Agent with identical behavior runs in a loop.

The host was puzzled: 'Why not allow the main Agent to modify any files by default? Modifying files is something they can do, and they're very proactive about it. Yet you consciously prohibit them from doing so. Why?'

Carlos said, 'Because I want it to focus on what I'm truly asking.' Once, while making a game, he asked AI about John Cleese's speech on creativity's 'open mode' and 'closed mode.' The AI immediately asked Carlos, 'Should I implement this in your project?'

He suddenly realized, 'If an Agent approaches every problem from the perspective of 'Can I write code for you now?', how can I get a good answer?' So, he set the main Agent as a role that doesn't modify files by default. This Agent handles discussions, explanations, and clarifying requirements, and can call on sub-Agents to complete actual work.

To prevent Agents from starting execution without fully understanding the task, Carlos introduced a confidence assessment mechanism. Only when the system judges its understanding of the requirements exceeds 90% is it allowed to activate sub-Agents. 'Once sub-Agents are launched, they can complete tasks directly—running for twelve hours doesn't matter. Multiple Agents can be started simultaneously; I don't care. But before they're extremely confident they understand me, they mustn't begin.'

This process puts requirement discussions before execution. Developers can first clarify goals, design ideas, and constraints, then let Agents focus on completing the work.

Carlos believes, 'We're standing at the threshold of needing a new programming language.' He identifies several issues that must change: removing heap memory, eliminating the need for pointers, dynamic memory, and everything surrounding them.

This new language should have three layers: The first layer allows humans to express requirements, combining natural language with structured syntax to describe components and their functions. The second layer can generate visual content like diagrams and videos, letting developers inspect how the system plans to achieve goals and further adjust solutions through communication. The third layer then converts the confirmed design into machine-executable representations, maximizing determinism during runtime.

Carlos argues: 'We need to return to a state where we can reason about what's actually running on the machine, rather than facing today's uncontrollable AI-like systems.'

Why is a deterministic language so important? Imagine a satellite launched into space with limited memory. If the program uses heap allocation, memory exhaustion exceptions or null pointer exceptions could occur in the satellite. We're increasingly entering fields like robotics, satellites, and machine learning, so we want systems to be as deterministic as possible.

AI programming lowers development barriers. If more and more code is generated by Agents, do developers still need to spend time learning programming languages, frameworks, and underlying principles?

In Carlos's view, developers with a solid foundation can better leverage AI programming tools. Knowledge takes time to truly internalize—if you just have Agents generate code, you're not actually learning these things. He also worries that developers relying on AI for help will communicate less with others.

Some even tell colleagues, 'Ask your Agent first, then come to me.' This touches on another easily overlooked issue: independent thinking and creativity need space.

Carlos borrows John Cleese's concept of creativity's 'open mode' and 'closed mode.' Open mode requires being in a relaxed state, temporarily setting aside the task at hand, and letting thoughts flow freely to generate new ideas.

However, social media and AI constantly feed people information: 'You no longer have a moment to just sit there, close your eyes, and know yourself.' AI can quickly provide answers and have multiple models question each other, but that doesn't mean humans can entirely skip the thinking process.

What kind of people will the software industry need in the future? Carlos hopes software development can truly become democratized, enabling more people to solve real-world problems through software.

For example, there may be some process issues in medical services, and someone can try to develop software to help relevant personnel solve practical difficulties.

The old saying, 'We are the experts; only we can do it,' no longer works.” The moderator also mentioned that the lower bound of capability has been lowered, and the entry barrier has suddenly become accessible to everyone. “But I also feel that people who have worked in this industry for many years know what is right and what is wrong; the new generation has not yet developed that taste or intuition.

Carlos responded, 'If you look at the declining number of people choosing engineering, especially software engineering, in schools, you will see a terrifying future. We are no longer cultivating junior engineers; we are just handing intelligent agents over to them.

He proposed an extreme possibility: if, in the future, tokens become extremely expensive, or if AI disappears for some reason, then everything will collapse.

Following Carlos's remarks, the moderator raised a question, 'Is this a bubble? Will the bubble burst, leaving nothing in the end?'

Carlos mentioned that three things are currently happening:

First, AI has indeed brought revolutionary breakthroughs in fields such as healthcare, materials science, robotics, and more. These are astonishing and beautiful. Carlos described this world as 'magical.'

Second, large language models are incredibly cool, but they are very wasteful and energy-inefficient. Carlos believes this is hype, even though the benefits they bring in programming are indeed enormous. Companies invest huge sums of money without being certain whether they can fulfill the promises made to everyone.

Third, there has been a significant shift in the balance of power. The largest companies are almost all tech companies, and Carlos is concerned about future privacy and security issues. AI has been touted as a 'great tool for equalizing,' but so far, we have not seen it truly make everyone equal; in the future, it may just make the rich richer.

At the end of the interview, Carlos believed that we are all increasingly isolated in our own worlds, and the only way to counteract this is to come back together, work together, make mistakes together, laugh together, and learn together.