AI First Development

I have the sensation that I live in two different worlds right now, and I want to clarify my position about the use of AI in software development. On one side, I talk to senior engineers working on production apps who are bullish on using AI to strengthen their architecture. On the other side, I talk to senior developers who are skeptical about the use of agents in software development because they fear “AI slop” and badly generated code. I chose to be bullish on AI coding agents for several reasons that I want to explain here.

AI Agents are not just a productivity tool

Working with coding agents forces you to think in terms of delegation. You need to define clear outputs of what you need. Good delegation is a skill, and it’s hard to train with humans because it requires years of management to understand how to delegate correctly. I know it very well because I am (was?) very bad at team management. I tend to solve problems by myself instead of coordinating the team to help. So I am the first victim of that.

Thanks to AI and coding agents, I’ve learned a ton about good delegation. I was asking too much or too little in the beginning: “Change this button to blue” is too small to delegate. “Add more tests” is too much. You need to find the sweet spot for your agents.

• For the “too small” issue:

  • Batch your requests. Ask for a bunch of small changes at once; take the time to list all your changes and send them.

• For the “too big” issue:

  • Split the task into logical steps.
  • Add more details in the brief on how to write the tests. Point to examples that work well.
  • Ask for measurable outputs: a link to the page to QA, a green test to check, etc.

To get back to my point: stop treating AI as a tool and start rethinking the way you work as a developer. Delegate more by creating robust validation systems you can trust.

Think like this:

“What happens if I add 50 senior developers to the team right now? How do I staff them? How do I pass product specs? How do I track progress? Where should they ask me questions, and when? How do I validate the work? Where is the documentation for them? How do they learn collectively to avoid making the same mistakes twice?”

What 10x developer means

A developer today should be able to work on 8 to 10 apps at the same time rather than 1 or 2. That means being able to hold more context in their head. It’s very hard to know exactly what happens on 10 different apps when you didn’t work on them directly. You need to put systems in place to be sure you track everything that happens as input and output of the apps. It’s just software engineering:

• Clean documentation: create systems that auto-update the docs on every code change so you know exactly what the APIs are doing.
• Robust test suite: +90% test coverage, no flaky tests, massive fixtures that represent real-world data, and test suite speed.
• Bug reports: be able to understand the bugs in production, replicate them locally, fix them, deploy, and write the learnings in a central documentation to avoid making this error again.
• Chaos monkey: run agents locally to fuzz test the apps and try to find blind spots and uncovered use cases.
• QA servers: be sure you can QA each branch individually in isolated envs to try various features at the same time.
• Clean code reviews: you need to be able to review all the code pushed to production. Use an agent that does a first pass of code review.

You now have the tools to create such systems and be confident in your whole infrastructure.

Every change is information

I sometimes hear this: “Why use an LLM to change a button’s color?” The issue with these small changes is that they come from “unmonitored channels”. That means the issue is systemic, not atomic. If, in a video call with the product team, someone said this change is needed, that means there is no tracking in place of the why. The why is important because this same kind of change can be applied to other parts of the app later, and if you have a memory system in place with your agents, they will be able to remember it and anticipate these changes. It’s all about memory and patterns. The more you save, the less you have to repeat yourself later. PS: don’t get me wrong, if a color change is needed somewhere, it’s probably a design system change to be applied everywhere to keep consistency in the UI. I was just making the point about “small changes”.

Agent Orchestration

The real deal now is orchestration, and everyone is trying to build great systems around their infra. OpenClaw, PaperClip, and so many others are trying to solve the issue. I am bullish on NanoClaw because I think it’s the best base to build upon. Docker isolation by default, very lightweight, and a comprehensive code base that is easy to review. I’ll push more updates on my NanoClaw setup soon, but this is probably the way to go.

The answer is: there is no clear answer yet. We are all trying to figure it out.

Product first

I am lucky enough that I come from a product background. I always wanted to create products and solve issues (you can learn more about my background here). Then I “had” to code and create robust systems for these products to grow. But I never liked coding. I liked the result, not the process. And now we can create a process that generates clean code and validates the result while keeping the system sane. It’s the best time to be alive for a senior developer. I like to emphasize the fact that I don’t like to code. Writing code by hand should not be allowed anymore. I will never be frustrated by not writing code. I want to think in systems and architecture, not in granular details. Code has no real value anymore, but your AI guardrails do.

Who is in danger

I still think that developers will be more in demand than ever before because the demand for software is infinite. That being said, every developer will be asked to manage much more than before. The juniors will break things, and I expect a lot of security and data breaches coming from unsupervised AI code running in production. The companies will then have two options: hire senior people (anyone with +10 years of experience in the field) and push advanced training to juniors to keep them without breaking production.

Ok, but who’s in danger:

• Any developer trying to gatekeep some kind of information will be out of the game very soon. Coding agents already help product teams understand the codebase and see what exists or not, the data flow, the conditions, and can ask questions to the codebase instead of the developers.
• Any product manager trying to justify late deliveries with “developers are slower than expected on this task” won’t be able to do it anymore. They have to ensure the initial product specs are clear because this is the root of everything. The execution not being the bottleneck anymore, it moves to clear specs and QA, which is product team work.
• Developers who like to code should not be allowed to do it in a professional environment, but only as a hobby. You can’t be wasting time typing characters on a keyboard when you should be focused on architecture, refactoring strategies, data consistency, test coverage, QA environments, and much more high-level tasks. You are not allowed to write handwritten letters to coordinate a team when you have Slack. But you can totally do poetry on the weekends.
• Developers not spending at least 3h to 4h a week reading news about tech, tools, and AI.
• Developers not having side projects where they can push AI limits and break stuff without any real production impact. Developers have to try new tools and context engineering techniques to keep up the pace.
• Developers not being able to communicate clearly with the other teams.

It’s hard to hear someone saying “Damn, why does this button not work? It’s unacceptable” when this button is a 3-week sprint you did with 3 rounds of QA and “everything was fine”. Until a Sales guy did a demo to a client with very random data and broke the feature, losing the client’s trust right before his eyes. As a developer, you must face these situations and find solutions to fix the issue and guarantee it won’t happen again. Developers can’t hide from the real world anymore because the world is coming at them with clear arguments. A product person can totally ask a codebase “Why does this feature break when I do this?” and output a perfect plan on the missing tests and blind spots that the developer missed in the first place.

Conclusions

It’s actually so funny that I posted this article nearly 10 years ago, and nothing has changed, software engineering still holds the same foundations: How to become a good software engineer.