DEV Community: Celestina Dike

When Code Becomes Cheap, Thinking Becomes Expensive

Celestina Dike — Thu, 26 Mar 2026 12:27:53 +0000

From "Prove It in Code" to "Prove It in Judgment"

For decades, credibility in software came from what you built with your own hands. Writing robust systems required stamina, coordination, and deep technical craft. The effort itself acted as a filter; only ideas worth the cost were implemented.
That constraint is gone.

Today, large language models can generate entire services, documentation, tests, and deployment scripts in minutes. The barrier to producing software artefacts has collapsed. The limiting factor is no longer typing speed or knowledge of syntax; it is clarity of thinking.

Inside an organisation adopting AI, this shift is profound. A team can spin up a prototype payments reconciliation service over a weekend using AI assistance. But the real question becomes: Who defined the problem well? Who validated the trade-offs? Who understands the system well enough to maintain it?
Code is abundant. Judgment must not become scarce.

When Output Becomes Cheap, Signal Changes

Well-structured codebases and thorough documentation used to be signals of maturity and care. Today, AI tools can generate pristine README files, polished APIs, and layered architectures instantly.
This makes surface quality an unreliable proxy for depth.
Within an AI-enabled engineering team, you might see beautiful documentation generated in seconds, clean abstractions suggested by the model, and automated test scaffolding created in bulk, but none of these guarantee that the system handles scale, edge cases, or operational realities.

An AI can generate an event-driven order processing service, complete with retry logic, dead-letter queues, and idempotency keys, and the code will look immaculate. But does it handle message ordering under partition rebalancing? Does the retry backoff account for downstream rate limits? A model can scaffold a Kubernetes deployment manifest with health checks, resource quotas, and horizontal pod autoscaling, yet miss that the pod affinity rules will starve a specific availability zone under real traffic patterns.

The signal of quality shifts from how polished it looks to something harder to fake: Does the team understand the system deeply? Is there ownership and accountability? Can someone explain why the circuit breaker threshold is set to 60% and not 40%, without re-prompting the model?
In AI adoption, governance and provenance become more valuable than aesthetics.

The Compression of Effort

AI drastically reduces the mechanical cost of building software. Tasks that once required weeks, writing gRPC service definitions with protobuf schemas, building CDC pipelines to sync state across bounded contexts, and standing up end-to-end integration test harnesses with containerised dependencies can now be compressed into hours.
This is not hype. It is leverage. Used correctly, AI frees engineers to spend more time on architecture and systems thinking, explore multiple design alternatives quickly, and run experiments that previously felt too expensive. In an organisation adopting AI at scale, this means faster iteration cycles and broader experimentation: scaffolding a complete OAuth2 flow with PKCE, token rotation, and role-based access control in an afternoon instead of a sprint; generating contract tests between fifteen microservices to catch breaking changes before deployment; spinning up a feature-flagged canary release pipeline to compare two ranking algorithms in production traffic. Teams can prototype an entire event-sourced domain model, evaluate its query performance against a traditional CRUD approach, and make an informed architectural decision all before the old process would have finished the design document.
However, speed without discipline produces fragile systems. The advantage goes to teams that combine AI acceleration with experienced technical oversight.

The Risk: Infinite Artefacts, Finite Understanding

If software can be generated endlessly, its perceived value drops. A pull request that took weeks of focused effort once carried an implicit sense of respect. Now, large AI-generated diffs may appear instantly with unclear human involvement.
This creates tension. Reviewing becomes harder than generating. Accountability becomes blurry. Junior engineers may rely on tools without building fundamentals.

For organisations, the real danger is not "bad AI code." It is teams that lose the ability to reason about systems independently.
If AI writes the data pipeline, optimises the SQL, and configures the infrastructure, but no one fully understands the flow, technical debt becomes invisible.

AI adoption must therefore include a strong review culture, explicit learning paths, and clear architectural ownership. Otherwise, productivity gains today become fragility tomorrow.

Talk Becomes the Multiplier

In this new landscape, the most valuable skill is not typing code, it is articulating intent`
The engineer who can frame a problem precisely, define constraints clearly, ask the right questions, and evaluate model output critically will outperform someone who merely executes.
AI does not eliminate engineering roles. It amplifies differences in clarity and systems thinking. Organisational structures compress too - design, coding, testing, and iteration increasingly blur into tight feedback loops.

The Future Is Thinking-First

The future of software development is not code-first. It is thinking-first.
When machines can generate implementation at scale, the competitive edge shifts to strategic problem definition, technical stewardship, responsible governance, and mentorship that builds foundational skill.
Code may be cheap now. But reasoning, accountability, and leadership are not.

Got any questions? Drop a comment

Pavan leads multiple engineering departments at Moniepoint

Curiosity Doesn’t Kill the Engineer

Celestina Dike — Wed, 25 Feb 2026 18:48:48 +0000

It Gives Them Nine More Lives in the Age of AI

“Curiosity killed the cat” is a warning.
In engineering, it is survival. And in the age of AI, it may be the single trait that keeps us relevant.

AI can autocomplete code. It can scaffold services. It can generate infrastructure templates, tests, and even architectural diagrams.
But AI is trained on patterns. Curiosity questions patterns.
That difference matters.

The engineer who stops at “it works” will slowly be replaced by systems that can also make things “work.” The engineer who asks “why the queue saturates at this load”, “what the true bottleneck is”, “what assumption an abstraction is hiding”, and “what happens when the model is wrong” cannot be easily replaced.

Curiosity operates below the surface layer where AI is strongest.

Every Deep Question Is an Extra Life

When you trace a request from the load balancer to the kernel to userspace and back, you gain a life.
When you understand how WAL durability interacts with fsync semantics, you gain another.
When you read the consensus paper instead of just using the library, that’s another.
And another life when you model throughput using queueing theory instead of guessing,
These are not just technical wins. They are resilience wins.

AI can produce solutions. Curious engineers understand trade-offs.
AI can refactor code. Curious engineers understand failure modes.
AI can summarise documentation. Curious engineers build mental models.
Mental models compound.

The Real Threat Is Complacency

The danger is not that AI will replace engineers.
The danger is that engineers will outsource their curiosity.
If we let tools think for us, abstractions become opaque walls instead of glass windows. We become operators of systems we do not understand.
The curious engineer uses AI differently.
Not as a crutch but as a multiplier.
They ask better questions.
They interrogate outputs.
They test assumptions.
They dive into edge cases that the model glosses over.
Curiosity turns AI from a replacement into an amplifier.

Curiosity Makes You Antifragile
When production fails, the incurious engineer searches for a quick answer.
The curious one traces signals.
Why did the replication lag spike?
Why did tail latency explode?
What is the queue discipline actually doing?
Is this a coordination limit or a physical limit?
Each failure becomes another life added to the stack.
Over time, systems stop looking like random collections of tools. They start revealing deeper patterns.
Entropy and compression.
Backpressure and channel capacity.
Cache hierarchies and storage engines.
Scheduling theory and latency.
Once you see principles instead of products, you cannot be easily automated away.
AI predicts tokens.
Engineers reason about constraints.

Nine Lives in the AI Era

Technologies will change.
Frameworks will expire.
AI models will improve.
But the engineer who remains relentlessly curious about fundamentals, failure, and first principles keeps regenerating.
Each layer of understanding is another life.
In an era where automation accelerates everything, the only durable edge is the willingness to keep asking ‘why?’ long after others have stopped.

Curiosity will not kill the engineer.
It will give them nine more lives.
And it may be exactly how we survive.

Opeyemi Folorunsho leads the Engineering Research & Development team at Moniepoint.

How to Build Engineering Teams That Think in Systems, Not Tickets

Celestina Dike — Wed, 25 Feb 2026 17:41:21 +0000

                    _Commits by John_

The Performance Conversation That Changed the Room

During a performance review, an engineering manager highlighted that an engineer had spent several late nights debugging production issues and pushing features. It was presented as proof of performance beyond expectation.
The room expected agreement.
Instead, I said something that made it uncomfortable.

Spending more time is not the same as performing better. Effort alone is not performance. Outcome is.

Yes, features were shipped quickly. But months later, we were still fixing subtle bugs tied to that release. Every small enhancement required touching core architectural decisions. During the product review, assumptions were not questioned. The design was implemented verbatim.
The engineer looked busy. The system was fragile.

In the same period, another engineer worked normal hours. No heroics. No drama. Since his release, there have been no production incidents in that module. He questioned the PRD. He challenged design decisions. He wanted to understand how the feature affected customers. As we scaled, extending his work became easier, not harder.
He was rated beyond expectations.
That contrast exposed something deeper — a flaw not in the engineers, but in what we had trained ourselves to value.

• • •

We Reward What Is Visible, Not What Is Valuable
Most engineering performance systems are biased toward visible work.
Hours spent. Story points completed. Tickets closed. Production calls attended.
These are observable. They are measurable. They make managers feel progress is happening.
But systems thinking is often invisible.
Clean architecture is invisible. Prevented incidents are invisible. Reduced complexity is invisible. A system that rarely breaks does not receive applause.
Over time, engineers optimise for busyness instead of durability.
When that happens, ticket completion becomes the goal instead of system integrity.
And nowhere is this more apparent than in how we treat incidents.

• • •

Prevention Should Matter More Than Recovery
Recovery is important. Incident response discipline matters. Mean time to recovery matters.
But prevention should carry more weight.
If I were to assign weights, prevention should count for 80 per cent and recovery for 20 per cent. It is cheaper to prevent than to recover.

Reducing incidents from 10 per month to 1 is more valuable than reducing recovery time from 2 hours to 30 minutes.
When teams focus primarily on recovery, they build better firefighters.

When teams focus on prevention, they build better architects.
If you celebrate the firefighter more than the architect, you are building a culture that creates a fire incident all the time.
The root cause of this pattern is almost always the same — teams that have been conditioned to think in tickets.

• • •

Ticket Thinking Creates Avoidable Work
Ticket thinking creates the illusion of velocity while increasing fragility.

Architecture gets reworked after release. Hotfixes stabilise features that should have been designed more carefully. Refactoring becomes necessary because shortcuts were taken to meet sprint targets. Adding new modules becomes increasingly expensive because the foundation is unstable.

Velocity looks impressive in the short term. But complexity compounds quietly.
Every new feature becomes harder to ship safely. Every release carries anxiety. Engineers spend more time fixing than building.
That is not scale. That is activity disguised as progress.
So how do you break the cycle?

• • •

How to Build Teams That Think in Systems

Shifting from ticket thinking to system thinking requires deliberate leadership.

Redefine performance. Stop rewarding just hours spent or story points completed. Start recognising engineers who reduce incident frequency, simplify architecture, and make future changes easier. Promotion should reflect ownership of outcomes, not volume of output.

Change what you measure. Track incident recurrence, change failure rate, and the safety of extending the system. Measure the reduction of avoidable work. If every new feature destabilises the system, velocity is meaningless.

Involve engineers earlier. Engineers should not simply implement requirements. They should challenge assumptions, clarify ambiguities, and consider second-order effects. An engineer who takes a PRD verbatim is implementing tasks. An engineer who questions it owns outcomes.

Reward complexity reduction. Promote engineers who simplify flows, clarify domain boundaries, and reduce cognitive load. Complexity is invisible until it explodes. Recognise those who prevent that explosion.

When you start doing all of this, one question inevitably comes up — especially from engineers who have been grinding hard but not seeing the results they expect.

• • •
Promotion Is About Mastery, Not Busyness

Many engineers ask why they are not being promoted despite long hours and visible effort.
Promotion panels are not looking for busyness. They are looking for depth.

Companies are looking to promote masters.
Mastery in engineering is not about writing more code or responding to more incidents. It is about understanding systems deeply enough to design them so that problems do not repeatedly occur. It is about building foundations that scale and optimising for the long term.
Speed and quality are not enemies; they answer to mastery.

• • •

This is ultimately a leadership problem. If we want to build engineering teams that think in systems, not tickets, we must reshape how we define performance, what we measure, and what we celebrate.

Tickets close.
Systems endure.

And endurance is what separates coding from engineering.

*John Ojetunde leads multiple Engineering Teams at Moniepoint
*