When writing code gets faster, what changes in engineering work?

Originally published on NewHack on November 4, 2026.

At Open Class #61, I talked with Marcelo Okano, also a Codex ambassador in São Paulo, about what changes when a team manages to implement more ideas. The question that stayed with me was how to turn that speed into learning, without pushing the cost onto review and operations.

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

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

Testing more alternatives changes the decision

At Serena, I shared a conversation I had with an engineering professional during a visit to Netflix. He described a change in the way of testing: before, the team would prototype a few alternatives, choose one to implement, and only go back to the others if the first one failed. In the example he shared with me, it became possible to implement and test all four alternatives in parallel.

The interesting gain lies in what the team manages to discover. When implementing an option is expensive, it's common to decide too early based on the best available hypothesis. If it's possible to compare more options, the decision can rest on observed results. This also requires defining in advance what would count as an improvement and making sure the tests produce comparable results.

The detail that interested me most is that testing more alternatives also demands more energy. If each version changes several things at once, it becomes hard to know why one worked. And if no one knows which outcome would settle the choice, the team ends up with four implementations and the same doubt. Speed opens room to experiment. The quality of the question determines whether that turns into learning.

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

Marcelo brought the other side of this acceleration. He said he once arrived at a sales conversation with a good part of a project already built, before the client approved the proposal. The example raises a question for anyone who sells software or services: a fast implementation can make a project viable, but there's still the matter of understanding what the client needs, adjusting what was built, and taking ownership of the delivery.

Specifying and reviewing are also engineering work

Okano described a way of working in which the developer spends more time discussing the specification with the AI, reading what was proposed, and approving the approach before delegating the implementation. In the conversation, he connected this shift to engineering fundamentals and to the ability to understand the problem being solved.

In the conversation, I returned to a problem I had already shown in a workshop: starting to request changes before clarifying what you want to build. The first version comes out fast, but then you ask to change it, reverse it, and redo it. The specification helps bring the doubt to a moment when changing your mind is still cheap.

A useful specification gives the agent the conditions to get it right and gives the team the conditions to notice when it gets it wrong. For a small change, it may be enough to say what changes, what needs to keep working, and which test demonstrates that the task is done. A request such as improving the registration form gains precision when the team points out which step causes drop-off, which fields need to be preserved, and what should happen if the save fails.

The same care applies to review. An agent can help locate a problem or raise hypotheses about a system, as came up in the conversation. The team still needs to check whether the explanation matches the logs, whether the fix covers the case, and whether it can be reverted when necessary.

How much does it cost to reach an accepted change?

Cost came up when we talked about tokens and rework. Two teams can deliver the same feature while consuming very different amounts of resources. And the model's bill is only part of the cost: it also includes the time of whoever formulates the request, reviews the code, runs the tests, and fixes what slipped through.

If I were to measure the outcome in a team, I would start with a task that already happens every week, like fixing a recurring bug. I would compare the time and resources spent until the change passed review and testing. If the first response was ready in minutes, but the team spent an afternoon understanding the change, there's still work to do to improve the flow.

How do beginners gain experience?

A question from the audience brought up the tension that was missing: if agents take on tasks that used to be delegated to junior professionals, where will these people learn to make engineering decisions? I suggested starting with concrete projects and going through the experience of putting them into operation. That's when problems show up that an isolated exercise doesn't reveal, from environment setup to how the application behaves in someone's hands.

For teams that hire and train people, this opens room to redesign the first tasks. For a low-risk change, a junior professional can use the agent to implement it and then explain, with support from someone more experienced, what changed, how it was tested, and how they would investigate a failure. That way, the delivered work also becomes an opportunity to practice review and diagnosis.

The opportunity shows up in operations

I also brought up a contrast that helps move beyond the discussion among developers. Just look at businesses where part of the operation still runs on paper, in hard-to-use systems, or in the head of whoever handles customer service. For those involved, an AI solution only starts to make a difference when it enters the workflow without creating one more step for the team to manage.

For a team that's just starting out, the first test can be following a real task, from order intake to delivery. Where does someone copy information? Where do they wait for approval? What happens when the case deviates from the standard? These answers help decide whether it's worth building something, adjusting an existing flow, or simplifying 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 implementing got faster? It could be choosing between product alternatives, reviewing a change with less rework, or deciding whether a task deserves to be automated. The gain shows up when the team can demonstrate what it learned and use that in the next decision.