When writing code gets faster, what changes in engineering?

On November 4, Marcelo and I held a warmup for the OpenAI DevDay Exchange at Serena Cafeteria in São Paulo. We wanted to prepare the community for the event. The conversation surfaced a tension that already shows up at work: AI reduces implementation effort, but we still need to decide what to test, what to accept and what to keep running.

The event brought together Rodrigo Terron of NewHack and Marcelo Okano of OKN Technology. A Community Night followed the Open Class. The edition was held in collaboration with iMasters and sponsored by Agora, FalaBoss, Nuvia and Notion.

Testing more alternatives changes the decision

At Serena, I recounted a conversation with an engineer during a visit to Netflix. He described a change in how the team ran experiments: it used to prototype several alternatives, pick one to implement and return to the others only if the first failed. In the example he shared, it became possible to implement and test all four alternatives in parallel.

The interesting gain lies in what the team can learn. When implementing an option is expensive, teams often decide early based on the best hypothesis available. When more options can be compared, the decision can draw on observed results. That also requires defining what counts as an improvement up front and making sure the experiments produce comparable results.

What interested me most was that testing more alternatives also takes more energy. If each version changes several things at once, it is hard to know why one worked. And if nobody knows what result would settle the decision, the team ends up with four implementations and the same uncertainty. Speed makes room to experiment. The quality of the question determines whether the team learns anything.

One practical application is to choose a decision the team usually makes by intuition. Before asking an agent to implement variants, write down the behavior you want to improve and how you will measure it. If two versions work equally well, the cost of maintaining each can guide the choice.

Marcelo brought up another side of this acceleration. He recalled arriving at a sales conversation with much of a project already built, before the client had approved the proposal. It raises a question for anyone selling software or services: quick implementation can make a project viable, but the work of understanding the client’s needs, adjusting what was built and taking responsibility for delivery remains.

Specification and review are engineering work too

Okano described a way of working in which the developer spends more time discussing the specification with AI, reading what it proposes and approving the approach before delegating implementation. He connected that shift to engineering fundamentals and the ability to understand the problem being solved.

During the conversation, I returned to a problem I had demonstrated in an earlier workshop: asking for changes before clarifying what you want to build. The first version arrives quickly, then you ask to change it, reverse it and redo it. A specification brings uncertainty forward to a point where changing your mind still costs less.

A useful specification helps the agent get things right and gives the team a way to notice when it gets them wrong. For a small change, it may be enough to say what changes, what must keep working and which test shows the task is done. A request to improve sign-up gets clearer when the team identifies where people drop off, which fields must be preserved and what should happen if saving fails.

The same care applies to review. An agent can help locate a problem or propose hypotheses about a system, as discussed during the event. The team still needs to check whether the explanation matches the logs, whether the fix covers the case and whether it can be rolled back if necessary.

What does it cost to get a change accepted?

Cost came up when we discussed tokens and rework. Two teams can deliver the same feature while using very different amounts of resources. And model usage is only part of the cost: there is also the time it takes to frame the request, review the code, run tests and fix what slipped through.

If I were measuring results within a team, I would start with something that happens every week, such as fixing a recurring error. I would compare the time and resources it takes for a change to pass review and testing. If the first response took minutes but the team spent an afternoon understanding the change, there is still room to improve the workflow.

How do early-career engineers gain experience?

An audience question brought the missing tension into the discussion: if agents take on tasks previously assigned to junior engineers, where will those engineers learn to make engineering decisions? I suggested starting with concrete projects and going through the experience of putting them into use. That is when problems an isolated exercise never reveals start to appear, from environment setup to how an application behaves in someone else’s hands.

For teams that hire and train people, this is an opportunity to rethink their first assignments. On a low-risk change, a junior engineer can use an agent to implement it and then explain, with support from someone more experienced, what changed, how they tested it and how they would investigate a failure. That way, delivering the work also becomes a chance to practice review and diagnosis.

The opportunity shows up in day-to-day operations

I also raised a contrast that takes the discussion beyond developers. Consider businesses where some operations still run on paper, in systems that are hard to use or in the heads of the people doing the work. For them, an AI solution starts to make a difference when it fits the workflow without creating another step for the team to manage.

For a team getting started, a first test can be to follow a real task from the initial request to delivery. Where does someone copy information? Where do they wait for approval? What happens when a case falls outside the usual pattern? Those answers help decide whether to build something, adapt an existing workflow or simplify a step before automating it.

I left the warmup with a question to take to the DevDay Exchange: which decision can we make better now that implementation is faster? It might be choosing between product alternatives, reviewing a change with less rework or deciding whether a task is worth automating. The gain shows up when the team can explain what it learned and use that in the next decision.