DEV Community: Neilton Rocha

What should go into a Git commit when a coding agent writes the code?

Neilton Rocha — Tue, 18 Aug 2026 13:09:00 +0000

A diff shows what changed. Agent-written code also needs context, verification results, human decisions, and known limits.

A coding agent can touch four files, generate a large diff, run several commands, and still leave the reviewer with the same unanswered question:

Why should anyone trust this change?

The diff shows the implementation. It does not show the original task, the reasoning behind the design, the checks that actually ran, or the parts that remain unverified.

Writing code became cheaper. Reviewing the result did not.

The diff is still necessary. It is no longer sufficient.

For agent-written code, I think the permanent record should preserve the task, engineering intent, final change, verification evidence, and known limitations. Prompts, tool calls, intermediate attempts, and checkpoints belong somewhere else.

The transcript is not the software history

An agent session can contain a long sequence of exploratory work:

Prompt
Files inspected
Tool calls
Intermediate attempts
Failed tests
Checkpoints
Reverted changes
Final patch

That record may help someone audit or reproduce the execution. It can also become very large, especially when an agent investigates several possible causes before settling on one implementation.

Most of that material has no lasting value in the project history.

A checkpoint helps restore an earlier state. A commit should explain a decision that remains useful after the session ends.

The distinction is easier to see when the records are separated:

AGENT EXECUTION
prompts
attempts
tool calls
checkpoints
        ↓
observability

ACCEPTED CHANGE
task
intent
diff
verification
limitations
        ↓
Git

REVIEW DECISION
review
approval
        ↓
pull request

The execution record answers, "What did the agent do?"

The Git commit answers, "What change did the project accept?"

The pull request answers, "Who reviewed and approved it, and under what conditions?"

Those are related questions, but they do not need the same document.

This is no longer only an individual workflow

Coding agents can now investigate issues, modify repositories, execute verification commands, and prepare pull requests.

That workflow is moving beyond a developer working alone in a local checkout. Spotify has described its background coding agent, Honk, operating through an internal engineering platform. The company reported more than 1,500 AI-generated pull requests merged through that platform and later described the context and feedback loops needed to make those changes reliable.

Amazon Q Developer follows a similar issue-driven workflow. According to AWS documentation, it can work from a GitHub issue, implement a change, and open a pull request for review. The implementation and the review remain separate steps.

At that scale, producing a patch becomes less of a constraint. The harder question is what evidence an organization should require before accepting it.

Sources: Spotify Engineering: Honk and AWS documentation for Amazon Q Developer.

What the diff leaves out

A hypothetical payment bug makes the gap concrete.

Suppose an issue called ENG-412 reports duplicate payment processing. An agent investigates the worker, the Redis lock, and the webhook handler. It tries one implementation, changes a test, reverts that approach, and produces a final patch involving four files.

The final diff may say:

4 files changed
87 insertions
31 deletions

That summary tells the reviewer how large the patch is. It does not answer the questions that affect acceptance:

What behavior was supposed to change?
Which test reproduced the original failure?
Did the agent change an existing test?
Why does the implementation use a Redis idempotency lock?
Which commands ran against the final version?
What was not tested?

A useful commit does not need to preserve every failed attempt. It does need to retain the information required to understand the accepted decision.

Verification should come from the repository

The agent can propose a solution and run commands. The repository tools remain the source of truth for compilation, linting, and tests.

That means the commit or pull request should record the commands and their actual output:

pytest tests/payments/
ruff check .
mypy src/

For example:

Verification:
- pytest tests/payments/: 142 passed
- ruff check .: passed
- mypy src/: passed
- existing tests modified: no

These results are illustrative. The real values must come from the repository where the change was made.

The tool name is useful for provenance:

Generated with Claude Code

It does not establish correctness. A Co-authored-by trailer can satisfy an internal attribution or audit requirement, but it does not replace test output.

The evidence should also state what did not run:

Not run:
- end-to-end tests require a local payment provider
- load tests were not executed

That small section makes the boundary of the verification explicit.

Passing tests does not settle the whole question

An agent can change the implementation and the tests. That creates a review point that should never remain implicit.

A test may have changed because the expected behavior was wrong. It may also have changed because the agent adjusted the test until the implementation passed.

The reviewer needs to know which happened.

Verification:
- tests added: tests/payments/test_idempotency.py
- existing tests modified: no
- tests removed: no

If an existing test changes, explain why:

Existing test modified:
- updated the fixture to match the payment provider's documented
  duplicate webhook response

A green test suite is evidence about the cases covered by that suite. It does not establish that every relevant behavior is correct.

The discussion around SWE-bench includes examples of patches that pass available tests while failing broader evaluation. That is one reason the accepted record should include scope and limitations, not only a green status.

A practical contract for the commit

I would keep the permanent record small:

Task
Intent
Change
Verification
Limitations

Task

State where the work came from:

Refs: ENG-412

This might point to an issue, an incident, or a technical specification. The purpose is to let a future reader recover the original problem.

Intent

Describe the engineering decision in one or two sentences.

Use a Redis-backed idempotency lock so duplicate webhooks do not
create multiple payment records across worker instances.

This is more useful than documenting the entire chain of prompts that led to the decision.

Change

The diff remains the central artifact. Keep the scope reviewable.

An agent can produce a large patch quickly, but the cost of understanding that patch still falls on the reviewer. If a small issue creates thousands of changed lines, the commit should explain why or be split before review.

Verification

Record the commands and the results from the final state of the repository.

Verification:
- pytest tests/payments/: 142 passed
- ruff check .: passed
- mypy src/: passed
- existing tests modified: no

Limitations

State where the verification stops:

Limitations:
- provider sandbox was unavailable locally
- concurrency was checked with unit tests only
- production load characteristics were not measured

A limitation does not weaken the record. It defines the boundary of the claim.

The pull request records acceptance

The commit and the pull request should not carry the same information.

The commit should remain useful when someone reads it months later, outside the original review conversation. The pull request can hold the discussion around acceptance:

Reviewed:
- payment idempotency behavior
- migration compatibility
- test coverage

Open risk:
- production concurrency was not measured

Approved by: [reviewer]

That is where reviewer questions, requested changes, follow-up work, and the final approval belong.

The agent may have produced the implementation. A human still decides whether the project should accept it.

Where execution history can live

There are legitimate reasons to preserve the agent's execution history.

A regulated environment may need an audit trail. A team may want to study failed attempts. An observability system may capture prompts, tool calls, repository state, and command output for debugging.

Those records can be valuable without becoming part of every Git commit.

The useful boundary is:

Execution evidence → accepted change → human acceptance

The execution log supports the change. The commit describes the change. The pull request records the acceptance decision.

Antigravity CLI's checkpointing documentation illustrates why checkpoints belong to the execution layer. They help restore a previous state while work is in progress. They are not automatically the right explanation for a change that remains in the repository.

Worktrees have a similar limit. They isolate parallel execution, but isolation does not provide verification, review, or acceptance.

A commit template for agent-written code

A practical template could look like this:

Fix duplicate payment processing

Refs: ENG-412

Intent:
Use a Redis-backed idempotency lock so duplicate webhooks do not
create multiple payment records across worker instances.

Verification:
- pytest tests/payments/: 142 passed
- ruff check .: passed
- mypy src/: passed
- existing tests modified: no

Limitations:
- provider sandbox unavailable locally
- concurrency checked with unit tests only
- production load not measured

The template does not attempt to reconstruct the agent's entire thought process. It records the information a maintainer needs to evaluate the accepted result.

Known limit

This format cannot compensate for incomplete requirements, weak tests, or behavior that only appears under production load.

Some changes will need a design document, an incident record, a security review, or a separate audit trail. The commit remains one part of that system.

Its job is narrower: preserve the engineering decision, the evidence available at acceptance time, and the limitations that future readers should not have to rediscover.

Agents make patches cheap. The decision to accept a patch still requires engineering judgment.

Git history should preserve that decision.

References

Building a company in 2026: What I’m learning along the way

Neilton Rocha — Mon, 03 Aug 2026 23:55:20 +0000

I have spent the last 18 years working in technology, including around six years as a CTO in startups.

Architecture, cloud infrastructure, engineering teams, incidents, and delivery deadlines are familiar to me. This is also my second time as a co-founder, but my role is different now.

At CatechLabs, I work across product, sales, customer discovery, positioning, partnerships, and strategy.

That shift made something clear: knowing how to build software is not the same as knowing how to build a company.

I am still learning the second part.

We talk to customers, test ideas, send proposals, adjust the scope, and learn from what does not work.

Building is no longer the main bottleneck

In 2026, creating software is much faster than it was a few years ago.

AI helps with research, prototypes, interfaces, code, documentation, and integrations. A small team can now build in days what might previously have taken months.

Because software is easier to build, it is tempting to treat shipping as progress. A working prototype does not prove that there is a business behind it.

Many products use the same models, interfaces, and promises. Building is easier; finding a real problem and earning trust are not.

My instinct as an engineer is still to start solving immediately. Now I first try to understand who has the problem, what it costs, whether it is a priority, and who has the authority to buy.

It is possible to build the wrong product very efficiently.

Learning to listen first

One of the most useful parts of this journey has been spending time with customers and the people who run the processes we want to improve.

Not to present the product. Just to understand how the work happens today.

I look for where time is lost, which steps are manual, where mistakes happen, and what result would justify changing the current process.

Customers are often polite. They may praise a demonstration or say they would use the product. That does not mean they will buy.

The stronger signals are urgency, budget, access to the decision-maker, willingness to run a pilot, and commitment to changing the process.

Sales conversations have also become a source of product information. Objections show what is unclear. Unanswered proposals and lost opportunities often reveal problems with urgency, positioning, price, or trust.

The Claude question

During a customer conversation, someone asked:

Why should we pay for your platform instead of simply giving our team access to Claude?

My first instinct was technical. I thought about retrieval, permissions, orchestration, integrations, security, and data architecture.

Those points were relevant, but they did not answer the real question. The customer wanted to know what would change in the operation.

That conversation changed how we explained the product. Instead of starting with models and agents, we started with the workflow.

People were manually collecting information, reviewing documents, checking inconsistencies, and repeating similar analyses across multiple cases.

The value was not access to an AI model. It was making that process faster, more consistent, traceable, and easier to review.

We gave less attention to generic chat features and more attention to structured workflows, audit trails, integrations, and human validation.

A general AI tool can help one person complete a task. A business system needs to make that process work repeatedly across a team.

What I am studying

As part of this transition, I have been studying areas that were less central to my work as a CTO.

Some of the books that keep coming up in conversations with founders are:

The Mom Test, by Rob Fitzpatrick
Build, by Tony Fadell
Amp It Up, by Frank Slootman

I also follow Lenny’s Newsletter, which shares practical lessons on product, growth, leadership, and company building.

None of these references provides a formula.

They help me ask better questions, avoid obvious mistakes, and learn faster.

Final thought

Building software is faster than ever.

Building something valuable is still difficult.

That is what I am learning now: how to move beyond technology and build the company around it.

CatechLabs is still early, and I am documenting the lessons as we build.

Visit CatechLabs

If you knew how hard It was, would you still start?

Neilton Rocha — Sun, 21 Jun 2026 22:03:31 +0000

The most honest thing I read about building a company this year wasn't from a venture capitalist, a founder on stage, or a bestselling business book. It came from a MicroSaaS founder who wrote:

"If I knew how hard it would be to be an entrepreneur, I wouldn't have started."

That is not a marketing line. It is an operational truth.

We are sold a romanticized version of entrepreneurship. We see the funding announcement, the acquisition, the viral launch, the successful exit. We see the highlight reel and assume success happens on a specific day. But companies are not built on days of victory. They are built on ordinary days when nobody is watching.

The real victory is not becoming the entrepreneur people admire. It is the accumulation of thousands of decisions made under uncertainty, pressure, and incomplete information.

The vision trap

One of the biggest misconceptions about entrepreneurship is the belief that vision is the primary driver of success. Vision matters, but it is often overrated. What matters more is what happens after the excitement fades.

Every founder starts with optimism. Most have a roadmap. Many have capital. Some have exceptional products. The hard moments arrive regardless.

I've seen months of work become irrelevant because a market assumption was wrong.
I've watched key contributors leave at the worst possible moment.
I've experienced launches that generated almost no response after weeks of preparation.

None of those situations cared about the original vision. They only tested whether the team would continue executing anyway.

This is where a different trait becomes important. Not vision. Not intelligence. Not even creativity. Stomach. The ability to keep moving when conditions are far from ideal.

💡 Key Takeaway: most startups do not die because they run out of ideas. They die because founders run out of emotional endurance.

The market rarely rewards the smartest person in the room. More often, it rewards the person who can absorb uncertainty for longer than everyone else.

Stomach Is a competitive advantage

Many people treat resilience as a personality trait. It is not. It is a skill. Like any skill, it is developed through repetition.

You build it by:

Making difficult decisions.
Shipping despite imperfection.
Facing rejection, setbacks, delays, and unexpected problems without allowing them to stop execution.

This is why waiting for the perfect moment is such a dangerous strategy. There is no perfect moment. There is only the next decision. The market does not validate what is planned. It validates what is launched.

Victory is a process

Most founders make a mistake when defining success. They treat success as a destination: An exit, an IPO, a valuation milestone, or a specific revenue target. The problem is that these moments are rare. If those are the only victories you recognize, the journey becomes emotionally unsustainable.

A healthier perspective is recognizing that victory happens throughout the process:

When you ship a feature that reduces churn by 1%, that is a victory.
When you solve a critical production issue before customers notice, that is a victory.
When you have a difficult conversation with a customer and learn something valuable, that is a victory.
When you make a hard hiring decision that protects the company long-term, that is a victory.

Small wins are not distractions from success. They are success. The visible outcome is simply the accumulation of hundreds of invisible victories.

The real combination of factors

Building a company is not a linear sequence of product, engineering, marketing, and sales. It is a balancing act between constraints. Eventually, everyone is managing the same variables:

Time availability: the finite window to achieve product-market fit.
Financial runway: the literal burn rate limit.
Emotional endurance: the capacity to make high-stakes decisions under stress.
Execution speed: how fast cycles of feedback turn into code.
Ability to recover: the MTTR (Mean Time to Recover) after a strategic or technical setback.

Ignoring any one of these creates fragility.

You cannot compensate for a lack of execution with more planning.
You cannot compensate for a lack of endurance with a better idea.
You cannot compensate for repeated failure to recover by working harder.

The strongest founders are not necessarily the most talented. They are often the ones who recover the fastest and continue moving forward.

The actionable shift

If success is not about waiting for the perfect moment, what should founders and builders do instead?

1. Stop optimizing for ideal conditions

The ideal conditions rarely arrive.

2. Treat difficulty as part of the job description

A crisis is not evidence that something is wrong. It is evidence that you are building something real. Technical failures, hiring mistakes, customer churn, cash flow pressure, and competitive threats are not exceptions—they are standard operating conditions.

3. Measure progress daily

Ask yourself every day:

Did you ship the code?
Did you talk to customers?
Did you improve the product?
Did you make the difficult decision you were avoiding?

Those actions matter more than most founders realize because entrepreneurship is a continuous process of building the capacity to operate under uncertainty.

Most people think entrepreneurship is a test of intelligence. It is usually a test of endurance. The market does not reward the founder with the best idea. It rewards the founder who remains in the arena long enough to make the idea work.

Vision may start a company. Stomach is what keeps it alive.

🔧 Let's keep it real in the comments:

Building a company is a balancing act of trade-offs. We often trap ourselves trying to optimize the wrong things.

So, where are you investing your stomach right now?

Beautiful Code (The engineering dream: clean architecture, perfect test coverage, scalable infrastructure)
vs. Beautiful Product (The market reality: shipping features fast, hacking a Monolith, validating with real users before the runway ends)

How do you balance your financial runway with your emotional endurance when you know the code isn't perfect, but it needs to go live?
What is one difficult product or technical decision you’ve been avoiding that you need to execute on today?

Drop your frameworks, battles, and thoughts below. 👇

Stop reading to build a library. Start reading to solve a problem.

Neilton Rocha — Sun, 21 Jun 2026 00:11:41 +0000

Most engineering reading lists are optimized for knowledge accumulation.

Modern engineering rewards bottleneck elimination.

Last week, a junior engineer showed me a "Top 10 Books Every Engineer Should Read" list. It looked almost identical to the lists I saw ten years ago.

The same classics.

The same process books.

The same assumption:

Read enough books and you'll become a better engineer.

That's not how most high-performing teams learn.

The best engineers I know don't build learning plans around books.

They build learning plans around constraints.

The Problem with standard reading lists

Most reading lists assume that knowledge is universally valuable.

In practice, engineering value is highly contextual.

A backend engineer struggling with database contention does not need another chapter on Agile.

A team spending thousands of dollars per month on LLM inference does not need a generic software craftsmanship book.

A startup fighting latency issues does not need a leadership framework.

They need solutions to the bottleneck directly in front of them.

Reading lists rarely account for this.

They optimize for completeness.

Engineering rewards relevance.

The Shift Most Engineers Miss

The fundamentals still matter.

Distributed systems matter.

Databases matter.

Networking matters.

Operating systems matter.

They are not obsolete.

But they are no longer sufficient.

Modern systems introduce constraints that barely existed a few years ago:

AI inference costs
Context window limitations
Agent orchestration
Evaluation pipelines
Semantic caching
Non-deterministic workflows
Model routing
Human-in-the-loop systems

Many traditional reading lists never touch these problems.

Yet these are exactly the problems teams are solving every day.

The challenge is no longer simply writing correct software.

The challenge is building reliable systems on top of components that are inherently probabilistic.

What Changed

For decades, engineers mostly worked with deterministic systems.

Given the same input, the same code produced the same output.

Today, many production systems contain components that behave differently.

A prompt may generate different responses.

An agent may choose different execution paths.

A model upgrade may change behavior without changing your application code.

The architecture challenges become different:

How do you evaluate quality?
How do you measure reliability?
How do you observe failures?
How do you control costs?
How do you debug probabilistic behavior?

These are not edge cases anymore.

They are becoming part of everyday engineering.

Read for Mechanisms, Not for Completion

Most engineers read cover to cover.

The strongest engineers read for mechanisms.

When they encounter a bottleneck, they identify the underlying mechanism and learn exactly what is needed.

If latency becomes a problem:

Study batching.
Study caching.
Study asynchronous execution.

If context becomes a problem:

Study retrieval.
Study chunking.
Study memory architectures.

If agents become unreliable:

Study evaluation.
Study state management.
Study workflow orchestration.

Learning becomes directly connected to production outcomes.

Knowledge is immediately converted into leverage.

The Learning Loop That Actually Scales

The most effective learning loop I've observed is simple:

Identify the bottleneck.
Find the mechanism behind it.
Study only what is necessary.
Apply immediately.
Measure results.
Repeat.

This approach compounds much faster than consuming books for the sake of completion.

Because the goal is not to finish a reading list.

The goal is to improve the system.

The Practical Test

Before starting your next book, ask a different question:

What is the biggest constraint in my current system?

Latency?

Cost?

Reliability?

Observability?

Evaluation?

Now find the best resource for that specific problem.

Not the most popular resource.

Not the resource everyone recommends.

The resource that directly attacks the bottleneck.

Because engineering is not a reading competition.

It's a constraint-solving profession.

The system should dictate what you learn next.

Not a list.

SEO Isn't Dead — But GEO Is already eating Its lunch

Neilton Rocha — Sat, 20 Jun 2026 01:43:42 +0000

Three signals landed in the same week. Together they answer one question: whether a machine ever mentions your name.

Most teams still ask whether they rank. The sharper question in 2026 is whether a model ever cites them — because for a growing share of users, the model's answer is the only page they read.

Three signals landed almost on top of each other this week: someone declaring that "SEO is dead and GEO is the new game," a new tool that tracks brand citations inside ChatGPT, Perplexity, Claude, and Gemini, and analysts arguing that product discovery is migrating from Search Engine Optimization to Generative Engine Optimization (GEO) — the practice of getting your content cited inside an AI-generated answer rather than ranked in a list of links. When a meme becomes three headlines on the same day, it's worth stopping to look carefully.

The short thesis: search didn't die. It stopped being the only front door. More people now put the question to a model and accept the finished answer, without clicking ten blue links. If your content isn't cited in that answer, you don't exist for that user.

This is no longer a forecast. SparkToro's 2026 data shows fewer than one in three Google searches still ends in a click. In Google's AI Mode, roughly 93% of queries end with no click at all. And Capston.ai projects that by late 2026, more than 40% of product discovery will begin inside AI-native platforms. The front door moved while most teams were still optimizing the hallway.

What changes from SEO to GEO

In classic SEO the goal was to rank: land on page one, win the click. In GEO the goal is to be cited: become the source the model uses to compose its answer. Same sport, different rules.

The target stops being position on the SERP (the search engine results page) and becomes presence in the generated answer. The metric stops being the click and becomes share of citation — how often you are the source named for a given set of questions. And the unit of content stops being a page optimized for a keyword and becomes a clear, verifiable, easy-to-extract claim.

No surprise a wave of tools showed up to measure exactly this: who gets cited, in which model, for which question. It's the Google Search Console of the LLM era — crude still, but it's the beginning. The demand is already real: 43% of marketers report actively implementing GEO in 2026, up from near zero a year earlier.

Why this is happening now

GEO isn't an isolated marketing trick. It's a symptom of a larger shift: the reader of your content is no longer always human.

This week Coinbase made that literal. It gave AI agents their own wallets to execute trades and pay for data, and launched Coinbase Advisor, one of the first AI investment advisers registered with the SEC. When the thing consuming your information stops being a person scrolling results and becomes an agent composing an answer or making a decision, how you publish has to change. Text written to seduce a human into a click is not always text a model can extract and cite with confidence.

The risk almost no one priced

Then came the uncomfortable news of the week. On June 12, the US government issued an export-control directive suspending access to Anthropic's newest models, Fable 5 and Mythos 5, for any foreign national — which forced Anthropic to disable both models for every customer overnight to stay compliant. Other Claude models stayed online; these two went dark. Legal analysts described it as an escalation in the use of export controls against frontier AI models.

The lesson for anyone building on these APIs is blunt: model availability is now a geopolitical variable, not just a technical one.

Here two distinct dependencies tend to get confused, so name them separately. The first is a distribution dependency: your content has to be citable across every answer engine — ChatGPT, Claude, Gemini, Perplexity — not tuned for one. Invisible in three of the four means invisible to most of the market. The second is a build dependency: if your product runs on a single model, you inherited a risk you don't control. Anyone who had built on Fable 5 lost it without warning.

Both collapse into one principle a regulated-infrastructure operator learns early: a single point of dependency is a single point of failure. Provider diversity stopped being hygiene and became strategy — on the distribution side and the build side alike.

What to do this week

None of this requires rewriting your site from scratch. It requires starting to play the new game in parallel with the old one.

Pick 10 questions an ideal customer would ask an LLM about your market, and test how ChatGPT, Perplexity, Claude, and Gemini answer them today. Note whether you're cited.
Rewrite your key pages with direct, verifiable claims at the top — definition, number, source — instead of warming up until the third paragraph.
Treat model-provider diversity as a requirement, not a future optimization.

SEO isn't dead. But ignoring GEO in 2026 is the equivalent of ignoring Google in 2006. The cost of starting now is one afternoon's experiment. The cost of waiting is becoming invisible on the only surface that's still growing.

LLM Routing: How to cut AI Infrastructure costs by 70% Without losing quality

Neilton Rocha — Thu, 07 May 2026 11:40:05 +0000

Running everything on frontier models is an operational mistake. Here is the routing architecture that reduced cost per task from $8.20 to $2.44 in production

GPT-5.5 costs 34x more than DeepSeek V4-Pro. 95% of your queries do not need frontier.

Routing (upfront decision) and cascading (confidence-based fallback) solve different problems. Production uses both.

ESKOM.ai went from $8.20 to $2.44 per completed task. Same quality. 70% cost reduction.

Every week someone tells me the same thing: "I tested an AI agent and it was useless. LLMs are overrated."

My answer: you sent a cardiac surgeon to put on a bandage and did not give him the patient notes.

The model is not the problem. The problem is that everything runs on frontier with zero selection logic. Here is what that costs at scale:

Model	Cost per 1M tokens	Multiplier
DeepSeek V4-Pro	$0.435	1x
GPT-4o-mini	$1.50	3.4x
Claude Sonnet 4.5	$5.00	11.5x
GPT-5.5	$15.00	34.5x
Claude Opus 4.7	$26.00	59.8x

A well-designed router pushes 95% of traffic to the cheap tier and reserves frontier for the 5% that actually needs it.

Routing vs. Cascading

These are two distinct strategies. Mixing them up is the most common architecture mistake I see.

Routing is an upfront decision. A classifier evaluates the query and picks a tier before any LLM call is made. One decision, one execution, no fallback.

query = "Extract the cost values from document X"
tier = classifier.predict(query)  # returns "simple"
response = router.call(tier, query)  # DeepSeek, $0.435/1M

Use it for structured, well-defined workloads: extraction, classification, fixed-template generation. The trade-off is that a wrong classification has no recovery path.

Cascading starts at the cheapest model and escalates based on a confidence score. If the output confidence falls below a threshold, it retries at the next tier automatically.

response = deepseek.call(query)

if response.confidence < 0.70:
    response = sonnet.call(query)

# Total cost: $0.435 + $5.00 = $5.435 vs. $26 going straight to Opus

Use it for unpredictable workloads: open-ended analysis, financial or legal reasoning, anything where query difficulty varies widely.

The latency trade-off is real. Sequential calls at 100ms each stack up. If P95 exceeds 500ms, rethink.

Production systems use both. Routing for structured flows, cascading for analytical ones.

The 3-layer architecture

Request
   |
[Semantic Cache] -- hit --> Response (zero cost)
   | miss
[Intent Classifier] (0.5B model, ~5ms)
   |
   |-- Simple     --> DeepSeek V4-Pro   ($0.435/1M)
   |-- Medium     --> GPT-4o-mini       ($1.50/1M)
   |-- Critical   --> GPT-5.5 / Opus    ($15-26/1M)
                         ^
                  [Confidence Gate]
                  confidence < 0.70: escalate

Layer 1, semantic cache: before any classification, check if this query was already answered. For B2C products with repetitive queries, a 30-40% hit rate is realistic. Marginal cost: zero.

Layer 2, Intent classifier: a small model (0.5B parameters) trained on your actual workload, not on generic benchmarks. Running locally with vLLM, latency is under 5ms. Cost is roughly $0.20/hour of GPU.

Layer 3, confidence gate: each response returns a score. Below 0.70, escalate. Above 0.85, trust it. Financial and legal domains bypass the gate and go straight to frontier.

Five mistakes that break this in production

No observability on routing decisions. If you are not logging the classifier score, selected tier, and final confidence for every query, you will not know when calibration drifts. The system degrades silently.

Single provider dependency. If DeepSeek goes down, your cheap tier goes with it. Configure a same-tier fallback on a different provider.

Tail miscalibration. Overall accuracy of 94% sounds good. The 6% that fails is exactly the rare, high-stakes queries your classifier has the least training data for. Oversample the tail when you validate.

Cascade latency stacking. Three sequential calls at 100ms each equals 300ms. Sometimes paying $26 directly on Opus is cheaper than the latency cost to your conversion rate.

Thresholds set by intuition. Run an A/B test. Compare 0.65 vs. 0.75 for one week. Measure escalation rate, average quality score, and cost per task. The optimal point is specific to your workload.

Real case: ESKOM.ai

ESKOM.ai runs an agent stack for energy data processing. Before and after implementing the architecture above:

Metric	Before	After
Query distribution	100% GPT-4.5	70% DeepSeek / 25% mid / 5% frontier
Cost per task	$8.20	$2.44
Escalation rate	N/A	2.8%
P95 latency	250ms	180ms
Quality score	4.1/5	4.2/5

At 30,000 tasks per month, that is $27,000 saved in the first month. Annualized: approximately $324,000.

An escalation rate of 2.8% means the classifier was well calibrated: 97.2% of queries stayed at the initial tier. If yours is above 5%, retrain.

How to implement this week

LiteLLM handles routing and fallback across 100+ models with a YAML config:

pip install litellm

from litellm import Router

router = Router(model_list=[
    {"model_name": "tier-simple",   "litellm_params": {"model": "deepseek/deepseek-v4-pro"}},
    {"model_name": "tier-medium",   "litellm_params": {"model": "gpt-4o-mini"}},
    {"model_name": "tier-frontier", "litellm_params": {"model": "claude-opus-4"}},
])

RouteLLM (Berkeley, arXiv:2410.13765) provides a calibration matrix trained on your query history. Their published benchmark: 85% of queries routed to cheap tier, maintaining 95% of frontier quality.

vLLM lets you run the intent classifier locally for sub-5ms latency and full query privacy:

pip install vllm
vllm serve Qwen/Qwen2.5-0.5B-Instruct --dtype auto

Four-week rollout:

Week 1: LiteLLM with 3 tiers + structured logging
Week 2: Confidence gate + domain overrides (finance and legal to frontier)
Week 3: Empirical threshold calibration via A/B test
Week 4: Monitor cost per task, escalation rate, quality score

Target at week 4: cost per task down at least 40%. If not, the classifier needs more domain-specific training data.

That is exactly backwards.

The defensible moat in AI infrastructure is not which model you have access to. Every competitor has API access to the same frontier models you do. The moat is how efficiently you decide which model to use for each specific task.

Organizations building this routing layer today operate with a 10-30x structural cost advantage over everyone still sending everything to frontier. That gap compounds. As usage scales, the teams without a router pay exponentially more for the same output quality.

The question is not "which LLM is best." The question is "which LLM is best for this query, right now, given confidence and latency constraints."

If this was useful:

Drop a comment with the escalation rate you are currently seeing in production, or the tier distribution you are targeting. I read every one.

If you are setting up LLM routing for the first time and hit a wall on classifier calibration, tell me your domain and workload profile. Worth a follow-up post if enough people are stuck on the same step.

References: RouteLLM · LiteLLM · arXiv:2410.13765

10 Engineering lessons I wish I learned sooner (Every Developer Should Master)

Neilton Rocha — Wed, 10 Dec 2025 16:30:00 +0000

In 2009, I was fresh out of the gate. I had plenty of energy, but very little wisdom.

My toolkit was simple: FileZilla, jQuery, and a lot of blind faith. I genuinely believed that if it worked on my laptop, the job was done.

Then came the day that taught me otherwise.

I deployed an e-commerce feature on a Friday afternoon without load testing. It worked fine for me. But on Monday morning, under real traffic, a bad database query locked the entire system.

I spent four hours sweating while support tickets piled up.

I wasn't a bad developer. I was just inexperienced. I knew the syntax, but I didn't understand the system. There is a massive gap between writing code that runs and engineering software that survives.

If you are early in your journey, don't fear these moments. They are the price of entry. It took me a decade to bridge the gap between 'coder' and 'engineer.'

You can cross it faster. Here are the 10 shifts that changed my career.

1. Don't block the user (async processing)

I used to handle heavy tasks, like generating a PDF or importing a CSV, right inside the main HTTP request. The browser would spin for 40 seconds, and if the user got bored and closed the tab, the process died.

I didn’t realize I was blocking the user from doing anything else.

How I handle it today: I treat the API like a receptionist, not a factory worker. It takes the order, acknowledges it, and moves on.

Senior code example: asynchronous API handling

// 1. Add to queue (Redis/SQS)
await reportQueue.add('pdf-gen', { userId: req.user.id });

// 2. Release the user immediately
return res.status(202).json({ msg: "We are working on it." });

This keeps the application responsive, no matter how heavy the workload is.

2. Zero trust architecture (validation)

I used to be naive about the Frontend. I thought: "If I put type='email' in the HTML input, I don't need to validate it on the server."

I was wrong. A malicious user can bypass your UI with a simple curl command and send garbage (or exploits) to your database.

Senior code example: Backend data validation with Zod

import { z } from 'zod'; // Assuming zod is installed

const UserSchema = z.object({
  email: z.string().email(),
  age: z.number().min(18)
});
// If this fails, the code stops here, ensuring data integrity.
const cleanData = UserSchema.parse(req.body);

The Backend is the guardian of data integrity. Never lower the shields just because the UI looks safe.

3. The N+1 problem (database efficiency)

I often wrote code that looked logical in the editor but was a disaster in production. I would fetch a list of posts and then loop through them to fetch the author.

In code, it looks fine. In reality, for 50 posts, I was triggering 51 separate database queries.

Senior code example: efficient SQL Join

SELECT p.title, u.name 
FROM posts p 
JOIN users u ON p.author_id = u.id;

Latency kills user experience. Reduce the round trips.

4. Logs are for context, not text

console.log("Error happened") is useless when you have 500 concurrent users. You need to know who crashed and why.

I stopped writing text logs and started writing structured logs (JSON).

Senior code example: structured logging

// Assuming a logger like Winston or Pino is configured
logger.error({
  msg: "Payment failed",
  userId: req.user.id,
  cartTotal: req.body.total,
  reason: err.message
});

Now, instead of guessing, you can search your log aggregator for userId: 123 and see exactly what happened to that specific customer.

5. Config goes in the environment

I used to hardcode API keys and database passwords directly in the code. It was "easier". Until I accidentally committed a password to a public repo and had to rotate every key we had.

The Rule: code is logic. Configuration is environment.

Senior code example: Environment variables for configuration

// The code doesn't know the secret. It asks the environment.
const dbPassword = process.env.DB_PASS;

This makes your application secure and portable. You can move from Staging to Production without touching a single line of code.

6. The network is unreliable (retry logic)

I assumed APIs would always be online. If a request failed, I just threw an error to the user. But networks glitch. Packets get lost. A 50ms blip shouldn't break your app.

Now, I implement Exponential backoff. If it fails, wait 200ms and try again. Then 500ms. Then stop.

Senior code example: fetch with exponential backoff Retry

import axios from 'axios'; // Assuming axios is installed

async function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

async function fetchWithRetry(url) {
  for (let i = 0; i < 3; i++) { // Max 3 retries
    try {
      return await axios.get(url);
    } catch (e) {
      console.warn(`Request to ${url} failed, retrying in ${200 * Math.pow(2, i)}ms...`);
      await sleep(200 * Math.pow(2, i)); // Exponential backoff
    }
  }
  throw new Error(`Failed to fetch ${url} after multiple retries.`);
}

// Example usage:
// fetchWithRetry('https://api.example.com/data')
//   .then(response => console.log(response.data))
//   .catch(error => console.error(error.message));

Robust systems absorb small failures instead of passing them to the user.

7. Cache the heavy stuff

I used to hit the database for data that rarely changed, like the list of product categories or site settings. It was a waste of resources.

The solution: Check memory (Redis) first. Check the database second.

Senior Code example: caching with redis

// Assuming redis client and db client are initialized
let categories = await redis.get('categories');
if (!categories) {
  categories = await db.query('SELECT * FROM categories');
  // Cache for 1 hour (3600 seconds)
  await redis.set('categories', JSON.stringify(categories), 'EX', 3600);
} else {
  categories = JSON.parse(categories);
}

Protect your primary database. It is the hardest part of your stack to scale.

8. Cookies over localstorage

I stored JWT tokens in localStorage because it was easy. But any JavaScript code (including third-party analytics libraries) can read localStorage.

I switched to HttpOnly cookies.

Senior code example: secure HttpOnly cookies

// When setting the cookie in a Node.js (Express) app
res.cookie('auth', token, {
  httpOnly: true, // JavaScript cannot read this, mitigating XSS
  secure: process.env.NODE_ENV === 'production', // Only send over HTTPS in production
  sameSite: 'Lax', // Protection against CSRF attacks
  maxAge: 3600000 // 1 hour expiration
});

This simple change eliminates a huge class of XSS attacks. It might be slightly annoying to set up, but it is worth the security boost.

9. Infrastructure as code

I used to configure servers manually via SSH. If the server died, I had to spend hours setting up a new one from memory.

Now, I use Docker. I define the environment in a file.

Senior code example: basic dockerfile

# Use a Node.js base image
FROM node:18-alpine

# Set the working directory in the container
WORKDIR /app

# Copy package.json and package-lock.json to install dependencies
COPY package*.json ./

# Install dependencies
RUN npm install

# Copy the rest of the application code
COPY . .

# Expose the port your app runs on
EXPOSE 3000

# Command to run the application
CMD ["node", "index.js"]

If a server dies, an automated process kills it and spins up a new clone in seconds. No emotional attachment required.

10. Focus on the solution, not the code

This was the hardest shift. If a client asked for an "Export to Excel" button, I built it.

Today, I ask "Why?". Often, they want the Excel file to import data into another system. So I suggest: "Let's integrate directly with that system via API."

The lesson: A junior developer builds what is asked. A senior engineer solves the underlying problem.

The bottom line

Seniority is not about how many years you have been coding. It is about how much you care about what happens after the deploy.

It is about moving from "it works" to "it lasts".

I'm currently drafting Part 2, focusing on the messy stuff: heavy debugging and production scars.

But first, I want to hear from you:

Which of these lessons did you learn the hard way?

Your story might save someone from a 2 AM incident. 👇

Don't Be (just) a developer: 6 "Soft" skills that actually define your career

Neilton Rocha — Sun, 02 Nov 2025 19:50:00 +0000

Your code might be perfect. Fine. But your career will fail if you only know how to code.

The real job? it's not about syntax. it's about navigating the corporate chaos outside your editor.

Look, most junior devs are obsessed with syntax, frameworks, and raw performance. that's just the baseline. it's table stakes. the real problem is that the corporate world doesn't really run on code. it runs on solving problems. Period. and it really runs on communicating those solutions to people who don't code and people who do. if tech and business aren't on the same page, you're sunk.

I saw this happen firsthand. e-commerce project. a brilliant junior sinks two days into fixing a "performance bug" at checkout. his code? chef's kiss.

But the real issue wasn't performance. it was a stupid business requirement that was overloading the API from the start.

He solved the symptom, not the disease.

That's the difference. a programmer codes. an engineer navigates the chaos outside the IDE.

The 6 "Soft" skills that aren't soft at all

Frameworks are nice. But your career is defined by this stuff.

Skill 1: customer obsession (the real starting point)

Too many engineers fall in love with the elegance of their solution. they forget who it's for.

"Customer Obsession" (yeah, the Amazon thing) isn't some fluffy marketing cliché. it's your starting block. before you argue Kafka vs. RabbitMQ, you must know why the customer even needs it.

Example: the team's arguing about Kafka vs. RabbitMQ for notifications. hold on. the right question is: "what does the user expect? do they need it now, or can they wait 5 seconds?" that one question changes the entire architecture.

Skill 2: problem solving (first principles thinking)

Most people build by analogy. "Spotify does it this way, so we will too."

It's fast, sure. But it's a trap. it kills innovation.

First Principles Thinking is the opposite. you tear the problem down to its fundamental truths.

Example:

Analogy: "we need a login screen. username, password. done."

First principles: "we need to (1) identify a user, and (2) prove they are who they say they are. what's safest? what has the least friction? magic link? biometrics? OAuth?"

This forces you to think about the job of the feature, not just copy-pasting the form.

Skill 3: clarity (The Feynman Technique)

If you can't explain it simply, you don't get it. it's that simple.

Early in your career, it's so tempting to hide behind jargon. "We optimized the query using an 'index hint' to force the 'nested loop'..."

Stop.

I guarantee your Product Manager is already checking their email. it's useless to them.

Example:

Jargon: "the CDN cache had 'stale data' and didn't invalidate."

Feynman: "the system saves an 'old photo' of the site on fast servers. our update didn't tell those servers to take a 'new photo.' so, users saw the old one."

You become the translator. the person who turns tech chaos into business clarity. that person is never fired.

Skill 4: "Selling" Ideas (The Pyramid Principle)

Your boss is busy. Your VP is really busy.

They don't have time for your chronological detective story of how you found the bug. they need the answer. Now.

The "Pyramid Principle" (by Barbara Minto) is built for this. it flips the script. start with the answer.

Example:

Wrong (Chronological): "so, I started looking at the logs, and I saw a 500 error, which was weird, and I thought maybe it was API X..." (They're already asleep).

Correct (Pyramid): "the slowdown is 100% the payment provider. it's killing our conversions. immediate fix: a 3s timeout and a fallback to save the sale. long-term fix: we must replace them. I need approval to start the RFP for next quarter."

Skill 5: storytelling (Ideas That Stick)

Facts are forgettable. Stories stick.

The "Made to Stick" book nailed this. to make an idea land, it has to be simple, concrete, and (shock) emotional.

Example:

Bad (Facts): "bug 87-B caused a 4% error rate on the checkout endpoint, affecting 1,200 users." (Nobody cares).

Good (Story): "maria, a 5-year customer, tried to buy a birthday present yesterday. the system errored out 4 times. she called support, furious. we lost the sale. this bug is doing that to hundreds of other 'Marias' right now."

See the difference? the second one gets a P0 ticket opened immediately.

Skill 6: conflict Management (Crucial Conversations)

You're going to disagree with your lead. Your teammate is going to merge messy code. A requirement will be absurd.

Most devs go quiet (fear) or go loud (ego). Both are career-killers.

The "Crucial Conversations" method is about keeping it safe. using facts.

Example (PR Review):

Bad (judgment): "this code is way too complex and it's going to break."

Good (facts): "i see this function has 5 'if/else' levels (fact). i'm worried about maintaining it (my story). could we simplify this with a strategy pattern? what do you think? (question)."

You attack the problem, not the person.

I had to invalidate a Senior's architecture three days before a sprint. total nightmare. i used this 'Facts-first' method. it focused us on the problem, not my opinion or his ego. it prevented a war.

The code is just the beginning

Look, you get hired for your tech skills.

You get promoted for your ability to communicate, think, and solve the real business problem.

The code is just the tool. These skills? this is your impact.

Reading list

What's the one 'soft' skill that blindsided you in your first year? Drop it in the comments.

You are the pilot: How to stand out in the vibe coding era

Neilton Rocha — Sun, 20 Jul 2025 14:40:38 +0000

You know that feeling? You open your editor, type a few words... and in seconds, Copilot completes the entire code. Claude, Gemini CLI, Cursor, Windsurf—all ready to refactor your function like magic. It's impressive. And, to be honest, a little scary too.
AIs are the best programming assistants we've ever had. I use them every day, and you should too. But here's the problem: if you let AI think for you, you're walking into a trap.
Think of it this way: AI is like a super-amplifier. If you have a solid foundation, it takes you far. But if your foundation is weak, you'll just get to the wrong place faster.
Microsoft made an excellent choice with the name "Copilot." The pilot still needs to know the destination, how to navigate through turbulence, and most importantly, how to land without breaking everything.
This article is your pilot's manual.

Fundamentals: Understand What's Happening Before asking AI to "create a function that searches for users," try writing a loop yourself. If you don't know the difference between a for...of and a forEach, or when you really need to use async/await, you'll have trouble debugging that "perfect" code the AI generated. What doesn't work: Blindly trusting the tool. Asking AI to "avoid excessive API calls" might generate functional code, but it might not be ideal for your specific case. What works: Understanding the why behind things. Knowing how to implement a debounce by hand shows you understand closures, setTimeout, and event management. That's what separates those who "use" code from those who "understand" code. JavaScript example:

// Example: implementing a debounce to understand the concept
function debounce(func, delay) {
  let timeoutId;
  return function(...args) {
    clearTimeout(timeoutId);
    timeoutId = setTimeout(() => {
      func.apply(this, args);
    }, delay);
  };
}

const searchAPI = (term) => console.log(`Searching for: ${term}`);
const debouncedSearch = debounce(searchAPI, 500);

// Only the last call within 500ms will execute
debouncedSearch('rea');
debouncedSearch('reac');
debouncedSearch('react'); // Only this one will run

To study more:

Book: "Data Structures and Algorithms with JavaScript" — Loiane Groner
Video: CS50 Introduction to Computer Science (Harvard on YouTube)

Front-End: Performance Is Not an Accident Anyone can "throw a component on screen." The differentiator is understanding how much it costs. AI can build a beautiful dashboard with 10 charts, but it won't warn you that the final file is 5MB and the page takes 8 seconds to load. Common mistake: Throwing everything in the same bundle. Importing heavy libraries directly, making users wait forever.

javascript// ❌ Naive way
import MegaHeavyChart from './MegaHeavyChart';

function Dashboard() {
  return (
    <div>
      <h1>My Dashboard</h1>
      <MegaHeavyChart />
    </div>
  );
}

Smart solution: Load on demand. Use React.lazy to load components only when needed. Shows you care about user experience.

javascript// ✅ Professional way
import React, { lazy, Suspense } from 'react';

const MegaHeavyChart = lazy(() => import('./MegaHeavyChart'));

function Dashboard() {
  return (
    <div>
      <h1>My Dashboard</h1>
      <Suspense fallback={<p>Loading chart...</p>}>
        <MegaHeavyChart />
      </Suspense>
    </div>
  );
}

To study more:

Official React documentation on optimization
Video: "How the Virtual DOM Works" (PurelyFunctional on YouTube)

Back-End: Architecture Is Your Legacy Messy code is the result of rushing. AI can generate an entire CRUD in a single file, but you're the one who should insist on proper organization. Why? Because a well-structured system is easy to test, modify, and understand—both for you and whoever comes next. Common mistake: Mixing everything—business logic, validation, and database in the same place. Impossible to test or modify without breaking something. Solution: Separate responsibilities. Divide into layers (controllers, services, repositories). This way you can change the database by modifying only one part, without touching business rules.

javascript// /services/userService.js
// AI generates the code, but you define the structure
export function createUser(userData, userRepository) {
  // Business logic here
  if (!userData.email || !userData.password) {
    throw new Error("Email and password are required");
  }

  // AI doesn't know that in your system all emails are lowercase
  const processedData = { 
    ...userData, 
    email: userData.email.toLowerCase() 
  };

  return userRepository.save(processedData);
}

To study more:

Book: "Clean Architecture" — Robert C. Martin (Uncle Bob)
Blog: "The Clean Architecture" (Uncle Bob's Blog)

SQL: Where Performance Really Happens Frameworks are great, but they hide the database. If you don't know what a JOIN, an index, or how to read an execution plan is, you're flying blind. AI writes the query, but won't optimize it for 1 million users. Inefficient query: A search on a giant table without an index. The database needs to read everything (sequential scan), causing slowness.

sql-- Slow on large tables
SELECT * FROM orders WHERE user_id = 123;

Optimized query: You know that user_id is frequently queried, so you create an index. The database now goes straight to the point.

sql-- 1. Create the index (once only)
CREATE INDEX idx_orders_user_id ON orders(user_id);

-- 2. Analyze performance
EXPLAIN SELECT * FROM orders WHERE user_id = 123;

-- Result:
-- Before: "Seq Scan" (slow)
-- After: "Index Scan" (fast)

To study more:

Site: Use The Index, Luke!
Site: "SQL Tutorial", W3Schools!

Security: It's Not Optional In 2025, insecure code is broken code. AI can suggest dangerous practices if you're not explicit. Security is your responsibility from the first line, not a problem to solve later. Dangerous mistake: Exposed credentials. Leaving passwords and tokens in code. One public git push and your company breaks.

javascript// ❌ DANGER: exposed key
const API_KEY = "sk_live_123456789SECRET"; // Leaked!
fetch(`https://api.service.com/data?key=${API_KEY}`);
Safe approach: Use environment variables and tokens with expiration.
javascript// ✅ SAFE: environment variables
import 'dotenv/config';
import jwt from 'jsonwebtoken';

const privateKey = process.env.JWT_PRIVATE_KEY; // Never in code!

const token = jwt.sign(
  { userId: 123, permissions: ['read:data'] },
  privateKey,
  { algorithm: 'RS256', expiresIn: '15m' } // Expires in 15 minutes
);

To study more:

Site: OWASP Top 10 (official list of security risks)
Video: "OWASP Top 10 Explained" (Fireship on YouTube)

Communication: What No AI Replaces You can write the most brilliant code in the world. If you can't explain it, defend your choices in meetings, or document it in Pull Requests, your impact will be limited. Code solves technical problems; communication solves business problems.

❌ Technical communication (the "bluff"): in meeting: "We implemented a distributed cache pattern with Redis to optimize N+1 queries from the ORM, resulting in P99 latency reduction from 2.5s to 340ms through TTL-based invalidation strategy and cache-aside pattern."
Result: Everyone agrees but nobody understood. The manager doesn't know if this solves the customer's problem or just shows you know difficult words.

✅ Effective communication: in meeting: "Our customers were complaining that the product page took too long to load—some were abandoning their purchases. I discovered the system was making 50 database queries to show a simple list. I implemented a smart cache system. Result: the page that took 3 seconds now loads in 0.3 seconds. This should significantly reduce cart abandonment."
Bad Pull Request:

Title: "Fixes bug"
Description: (empty)

Pull Request that tells a story:

Title: "Improves user search performance by 40%"
Description:

The problem: admin page took 5s to load due to unnecessary queries in userController
The solution: replaced multiple small calls with a single JOIN and added index on profile.user_id column
How to test: run user.spec.js test or access /admin/users. Should load in less than 500ms

To study more:

Book: "The Minto Pyramid Principle" — Barbara Minto
Video: "How to Communicate Like a Senior Developer" (Travis Media on YouTube)
Site: Bluf.co — learn the "Bottom Line Up Front" structure for direct and effective communication

Conclusion: You Remain in Command
AIs are incredible assistants. Use them to accelerate, automate tasks, and get a second opinion.
But never let go of the steering wheel.
Those who stand out aren't those who program fastest, but those who understand what they're programming. Those who think about architecture, optimize slow points, protect the system, and can explain their decisions clearly.
AI can be the hand that writes. But the mind that guides, that has the vision and takes responsibility, continues to be yours.
You are the pilot.

Is the software engineer the new farmer of the digital age?

Neilton Rocha — Sun, 22 Jun 2025 00:46:29 +0000

The software engineer is the new farmer of the digital age. Just as modern farmers use tractors, drones, and automated irrigation systems to maximize productivity, we software engineers now have artificial intelligence as our most powerful tool for cultivating quality code. But here's the crucial point: you can have the most advanced tractor in the world, but if you don't know how to plant, when to irrigate, or which soil is suitable for each crop, your harvest will be a disaster.

AI can dramatically accelerate our ability to write code — studies show developers can complete tasks up to twice as fast with tools like GitHub Copilot. However, this speed only translates into real value when built upon solid foundations of technical knowledge.

Why fundamentals are non-negotiable

Imagine you're building an API and AI suggests implementing caching, but you don't understand the fundamental concepts of caching, asynchronous versus synchronous processing, or when to use message queues. You might implement the suggestion quickly, but you won't know if you're solving the right problem, if the solution is appropriate for your specific context, or if you're creating new performance or security issues.

Data structures and algorithms remain the foundation of everything. A developer who doesn't understand the difference between a linked list and an array won't be able to ask intelligent questions to AI about performance optimization. Database knowledge and SQL are fundamental , how can you ask AI to optimize a query if you don't understand indexes, normalization, or joins?

MIT Sloan research revealed something fascinating: junior developers achieved productivity gains of 27% to 39% with AI, while senior developers saw only 8% to 13% improvement. Why? Because experienced developers already possess the contextual knowledge necessary to ask more sophisticated questions and critically evaluate AI suggestions.

The modern software engineer roadmap

To navigate effectively in this new era, you need to master both fundamentals and modern tools. Roadmap.sh offers a comprehensive guide, but here are the critical areas every engineer should master:

Essential technical fundamentals

Data structures and algorithms — Practice on LeetCode and visualize concepts with Algorithm Visualizer
Database and SQL — Improve your skills on Lost at SQL and StrataScratch
System design — Study real cases on Pramp System Design
Version control — Master Git with Learn Git Branching

Practical development

Frontend — Build real projects on Frontend Practice and Frontend Mentor
Project-based learning — Explore the Project Based Learning repository
Build your own tools — Follow the Build Your Own X guide

GitHub repositories with best practice examples

To accelerate your learning and see quality code in action, study these repositories that exemplify excellent programming practices:

Programming Best Practices — Comprehensive collection of best practices for multiple languages
Software Engineering Best Practices — Fundamental principles for professional development
Zustand — Example of a library with clean, well-structured code

How AI Amplifies (But Doesn't Replace) Knowledge

AI works best when you already have sufficient context to ask the right questions. For example:

Without knowledge: "AI, make my API faster"

With knowledge: "AI, implement Redis caching for this specific query that's causing a bottleneck, considering cache invalidation when data is updated"

The difference is striking. The first request might result in a generic and inadequate solution. The second demonstrates problem understanding and directs AI toward a specific and effective solution.

Specializations and complementary tools

For specific areas, consider these platforms:

Security — Practice on Hack The Box
Data Science — Explore datasets on Kaggle
DevOps — Solve real problems on SadServers
Technical assessment — Prepare on CodeSignal

The future belongs to technical polyglots

AI isn't here to replace us — it's here to amplify us. But this amplification only works when we have a solid knowledge base to amplify. 71% of organizations globally are impacted by technology failures, often because developers implement solutions without fully understanding their implications.

The software engineer of the future will be one who masters both technical fundamentals and the art of collaborating effectively with AI. They'll be able to ask intelligent questions, critically evaluate responses, and implement solutions that don't just work, but are robust, scalable, and maintainable.

Like the new digital farmer, you need to know your soil (architecture), your seeds (algorithms), your tools (AI and frameworks), and the seasons (development cycles). Only then will your code harvest be truly abundant and high-quality.

The bottom line

In this AI-driven era, your technical fundamentals aren't becoming obsolete — they're becoming more valuable than ever. They're what separate the developers who use AI as a powerful amplifier from those who become dependent on it as a crutch.

Master the basics, embrace the tools, and become the kind of developer who doesn't just write code faster, but writes better code that stands the test of time.