DEV Community: Heriberto Flores

Nearshoring After AI: Will LATAM Go Back to Software Factories?

Heriberto Flores — Thu, 05 Nov 2026 18:54:15 +0000

If you're a software engineer in Latin America, you know the dream job: a US company, a Slack full of people in Austin, paid in dollars. Nearshoring. For a decade it's been the best deal in the region.

But there's one uncomfortable piece of math.

The math

Nearshoring sells engineers by the head, or by the hour. More engineers, more money.

Now add AI. With agents, what took me a week takes a day or two. So if one engineer does the work of three and the client pays per head… how many heads does the client still need?

Worse: if we bill by the hour and get three times faster, we just made three times less money for the same work. A business model that profits from slowness doesn't survive a technology that removes it.

Three scenarios

1. The cut. The easiest line in a US budget isn't the employee in the office. It's the contractor. Us. No layoff headlines, just a contract that doesn't get renewed.

2. Back to the software factory. Remember the 2000s? Fixed price, Gantt charts, a CMMI certificate in the lobby. It might come back with a new shape: "Don't rent ten engineers. Give us the spec, we deliver in eight weeks." Now the speed is our margin, not the client's discount. But selling results means owning the risk, the architecture and the deadline.

3. Nothing changes. Every time software got cheaper, we built more of it. Ask any PM if their backlog is done. They'll laugh, then schedule a meeting about it. Same headcount, way more output.

My bet

A mix, unevenly distributed. Engineers who are just "extra hands" are at risk, because hands are exactly what AI replaces. Engineers who bring judgment will be fine: the ones who understand the business, design the system and lead the agents.

Same for companies. The ones selling hours will compete on price against a machine. The ones selling results will have the best margins the region has ever seen.

What I'd do

Be a person, not a seat. The engineer the client would miss by name.
Learn the business. Agents know the stack. They don't know why billing hates the invoice flow.
Lead agents. That's the new seniority.
Keep your English sharp. Fewer seats go to whoever communicates best.

Your turn

LATAM folks: are contracts shrinking, or are clients asking for more? US folks: is AI changing how big you want your nearshore team?

Let's talk in the comments.

Request, Review, Accept, Repeat: The Life Inside the Loop

Heriberto Flores — Thu, 05 Nov 2026 18:40:28 +0000

I used to be a developer. Now I'm a very well-paid while (true) loop.

Request, review, accept, validate. Repeat.

A small eulogy for the fun part

Remember the bug that took three days? console.log("HERE"), then console.log("HERE 2"), then console.log("WHY"). And on day three, in the shower, it hit you: the timezone. It was always the timezone.

That little fireworks show when the problem finally clicks? Mostly gone.

Now the agent finds the timezone bug in forty seconds. No shower needed. It just says "The issue is a UTC conversion in the date parser. Here's a fix." and waits for me to press accept, like a waiter holding the bill.

I miss being clever. I miss the whiteboard full of arrows only I understood. The part where I solved the puzzle got replaced by me reading someone else's solution and nodding.

Rest in peace, console.log("WHY"). You were a real one.

So what did I get back?

Time. Actual, unscheduled time. Here's where it went.

Big picture. When you're deep in the code, you see the function. In the loop, you see the system. Why do we have three services that do the same thing? Who approved this architecture? (Me. In 2021. I'm not proud.)

Technical debt. That TODO: refactor this later from four years ago? Later is now. The legacy module everybody was afraid to touch? I touched it. Nothing exploded. Mostly.

Testing. It used to get whatever energy was left after the feature worked. Usually none. Now the agent writes code fast and my job is to prove it's right: edge cases, weird inputs, the user who pastes an emoji into the phone number field. Breaking things is more fun than I remembered.

Meetings. The gift nobody asked for. Now that I'm "so much faster", I have plenty of time for everything my PM and manager love:

The standup: "I approved stuff, I'll approve more stuff, no blockers."
The sync before the planning. The planning. The sync after the planning.
The "quick 15 minutes" that has never once been 15 minutes.
The meeting about why we have so many meetings.

For ten years, "Sorry, I'm deep in a bug" was my shield. Now everybody knows the agent is fixing the bug. The agent took my code. The calendar took my afternoons.

Don't get me wrong

This isn't a complaint. This new stage is genuinely great.

Every team has a graveyard of ideas killed by two sentences: "We don't have time" and "What if it doesn't work?"

That graveyard is opening up.

Experimenting is cheap now. An idea that used to cost two weeks and a meeting to justify now costs one afternoon and a request. If it works, I show up with a working prototype instead of a slide. If it doesn't, I throw it away and nobody notices. Especially my manager.

"I'm not sure it's possible" used to be the reason not to try. Now it's the reason to try, because finding out is faster than debating it. I'm not just the person who closes tickets anymore. I bring ideas, already working.

The loop, honestly

The loop isn't the enemy. It's fast and it ships. But it only works if the person inside is still thinking. The moment I accept proposals without reading them, I'm not a developer. I'm a rubber stamp with a salary.

The creativity didn't disappear. It moved. Writing a good request is design. Rejecting a proposal is architecture. Deciding what's "enough" is engineering.

Less fireworks, more chess. I still miss the shower moment, though.

Your turn

Are you in the loop too? What are you doing with the time you got back? Fixing tech debt, chasing that idea from the graveyard, or sitting in the sync about the sync?

Tell me in the comments. I'll read them between meetings.

The Unnecessary Evil: How I Stopped Opening Visual Studio for .NET Framework 4.8

Heriberto Flores — Thu, 15 Oct 2026 19:47:29 +0000

Every developer has a necessary evil. Mine had a purple icon, a splash screen and 14 GB on my disk.

The relationship

I want to be fair to Visual Studio. It's a powerful IDE. It has helped millions of developers ship software. It has also, on more than one occasion, frozen while I typed a semicolon.

But I had no choice. I work on an old .NET Framework 4.8 codebase: classic non-SDK .csproj files, Web.config files the length of a novel, NHibernate, IIS Express. That kind of project doesn't do dotnet run. It needs Visual Studio the way an old car needs one specific mechanic who's the only person in town who still has the parts.

So every morning went like this:

Open the solution.
Get coffee while it loads.
Come back. It's "Preparing solution…".
Get a second coffee.
Press F5. It builds the 37 projects I didn't touch and somehow skips the one I did.
Clean. Rebuild. Restart Visual Studio. Restart the computer. Question my career.

Meanwhile, VS Code sat in the corner, opening in half a second, quietly judging me. I wrote everything else in it. I just couldn't run anything in it.

The necessary evil.

The breakup

Here's what I eventually realised: I didn't need Visual Studio. I needed four things it did for me.

Find MSBuild.
Build the projects in the right order.
Put the right config in place.
Start IIS Express on the right site and port.

None of those needs a 14 GB window. They are just steps. And steps can be written down.

So I wrote them down. One Markdown file in the repo, written for Claude Code (and for humans, which turned out to be a nice bonus). It walks through the whole thing in plain steps: check that the local config is there (and stop and ask if it isn't, never invent secrets), put it in place, build the projects in the right order, start IIS Express in the background, and poll a health endpoint until the API answers.

At the bottom there's a troubleshooting section with every scar I collected along the way. My favourite: Git Bash helpfully turning IIS Express's /config: switch into a file path, so it dies complaining that switches must start with /. It did. Thanks, Git Bash.

Now my morning goes like this:

Start the admin Web API locally.

Claude Code reads the doc, checks the config, builds, starts IIS Express, polls the health endpoint and tells me the port. When something breaks, it reads the log file the doc points to, instead of me scrolling through the Output window looking for the one red line among four thousand grey ones.

I edit in VS Code. I run through Claude Code. Visual Studio stays closed.

Full disclosure

Visual Studio is still installed. vswhere finds MSBuild inside it, and IIS Express still reads the applicationhost.config that Visual Studio generated once, long ago.

So we didn't really break up. We just stopped living together. It's in the garage, doing build work, and I don't have to look at the splash screen anymore.

The necessary evil became the unnecessary evil. It's still there. I just don't need to open it.

The lesson

Nobody gave me a better tool for this. The codebase is still .NET Framework 4.8, and it's not getting migrated this quarter, or the next. The tooling I was handed was "use Visual Studio, that's how it's done".

What changed is that I stopped accepting that as the end of the conversation. I spent an afternoon writing down what the IDE did for me, and that Markdown file now saves me (and my team) the pain every single day.

So here's my question for you: what are you going to do with the tooling you have? Improve it, or accept whatever you were given?

Your necessary evil might be more unnecessary than you think. Tell me in the comments which one you're still opening every morning.

If You Just Failed an Exam, This Post Is for You

Heriberto Flores — Wed, 14 Oct 2026 16:41:48 +0000

If you just failed an exam, this post is for you.

Maybe you missed by a lot. Maybe you missed by a handful of points, which somehow hurts even more. Maybe right now you're wondering if you're really as good as you thought you were.

I know that feeling, because I failed the Claude Certified Architect exam twice.

By 30 points. Then by 20.

And I passed on the third try with 845. But I want to tell you about the part in between, because that's the part nobody posts about.

The first fail

I prepared the way a lot of us do. I paid for a practice exam and learned every question until I could answer all of them without thinking.

Then I sat the real exam, and it was nothing like what I had studied. The questions were different and much harder. They didn't ask me to remember things. They asked me to make decisions, and they were designed to find out whether I really understood the foundations.

I didn't.

The passing score was 720.

It stung, but I told myself it made sense. I just hadn't seen enough questions.

The fail that really hurt

So a month later, I tried harder. I bought a highly rated guide with more than 300 questions and memorised every one of them.

This time the exam felt easy. Every question seemed to have a clear answer. I went fast. I walked out feeling good.

700.

I can't fully explain how that one felt. The first time, I could blame the surprise. This time I had done everything I thought I was supposed to do. I had felt ready. And I still wasn't good enough.

I'll be honest: I got a bit depressed. It was hard to recover. I started questioning whether I was the engineer I believed I was, and whether I belonged in this new AI world I was so excited about.

What I finally understood

Here's what I couldn't see while I was in it.

Those fails weren't measuring me. They were measuring my strategy.

Memorising questions teaches you to recognise answers, not to understand them. It feels exactly like knowing, which is why my second attempt felt so easy. But a good exam changes the scenario just enough that the answer you remember is the wrong one. My confidence was real. My understanding wasn't there yet.

I wish I had realised that sooner. But I realised it, and that changed everything.

So I stopped memorising. I put the question banks away and studied only the foundations, as hard as my mind could.

The third attempt

I'm not going to pretend I walked in calm.

I was scared. Terrified of failing a third time and proving to myself, once and for all, that I wasn't good enough.

The exam was hard. Some questions confused me. But this time I didn't rush. I thought through every single one as well as I could, and I used every minute I had.

845.

I was so happy. Not only because I passed, but because I knew why I passed. I hadn't remembered my way through it. I understood it.

What I want you to know

If you just failed, here's what I'd tell you if we were sitting together:

Failing doesn't mean you aren't good enough. It means something in how you prepared didn't work. That's fixable. You are not the problem; the approach is.

Being close is not a reason to try the same thing again. I missed by 30, then by 20, and I almost convinced myself that a bit more of the same would close the gap. It didn't. Changing how I studied did.

The fail is part of the story, not the end of it. I'm grateful I didn't pass with a lucky 721. Those two fails forced me to build the understanding I now use every day.

Why it was worth it

I didn't want this certification for the badge. I believe we're at the start of a new way of building software, and I wanted to be part of it from the beginning, ideally the first one to bring it into my company.

Two fails made that feel very far away. Today I'm here.

So if you're looking at a score that's lower than you hoped, take a few days. Feel it. Then change your approach, and go again.

You've got this.

Have you ever failed something you really wanted? How did you come back from it? I'd love to read your story in the comments. And if you're preparing for the Claude Certified Architect exam right now, feel free to ask me anything.

From Coding to Lead Agents

Heriberto Flores — Wed, 14 Oct 2026 16:02:54 +0000

A while ago my relationship with Claude Code was simple: I typed a request, read what came back, corrected it and typed again. It worked. It was also me doing all the coordination. I was the one remembering what had been decided three messages ago, noticing when the model drifted, and deciding when something was "done".

Today most of my prompts don't ask for code at all. They describe a process: which phases run, in what order, who does each one, what counts as evidence, and when to stop. The agent writes the code. I write the rules it works under.

I didn't get here in one jump. It happened in four stages, and each one started with something going wrong.

Stage 1: Prompting

It was late in the afternoon, two hours into one long conversation. Early on, the model and I had agreed on how a validation rule should work. Now, deep in the scrollback, it rewrote that same rule the old way, and it did it with total confidence. I scrolled up to find where we had decided it, and I realised something uncomfortable: the decision only existed in the chat, and I was the only one still remembering it.

That was the pattern back then. Ask for a feature, get a diff, point out what's wrong, repeat. The chat was the source of truth, and when the context got long, decisions quietly disappeared. Every fix polluted the next step: by the time I asked for tests, the model had already seen the implementation, so the tests matched the code, not the requirement. And "done" meant "the model said it's done". No evidence, just confidence.

None of this was the model's fault. I was asking a single context to be the analyst, the architect, the developer, the tester and the reviewer, all at once, while remembering everything.

Stage 2: Spec-driven development

The first real change was adopting spec-driven development with Spec Kit. It splits the work into explicit phases, each one producing a file: spec → clarify → plan → tasks → analyze → implement → verify.

The first time I cleared the context between two phases, it felt wrong, like throwing away work. Then I watched the plan phase read the approved spec.md and catch a requirement I had forgotten I'd written. That's when it clicked: each phase stays consistent with what is actually written down, not with the half-decisions piling up in a conversation. If it isn't in a file, it didn't happen.

The rule that surprised me most was that the implementer doesn't write the tests. Implementation writes product code only. Tests come later, in verify, written from the spec's acceptance examples by an agent that isn't allowed to read the product source. A context that has seen the implementation writes tests that confirm the implementation. A blind tester writes tests that confirm the requirement. That only works if the context is truly clean, so clearing it between implement and verify isn't a nice-to-have; it's the whole guarantee.

Bugs fit the same pipeline. A feature starts from requirements, so the spec is authored. A bug starts from a symptom, so the spec is discovered from what the code does and what was reported. Both produce the same spec.md, and the bug path is allowed to stop instead of guessing: when it can't reproduce the symptom with evidence, when nobody has defined the correct behaviour, or when the bug comes from something the codebase doesn't own. Teaching an agent when to stop turned out to be as valuable as teaching it what to do.

Stage 3: Becoming the orchestrator

SDD fixed the drift, but it created a new routine. Clear the context, run the next command, read the output, decide whether to continue, clear the context again. One day I counted how many times I had done that for a single feature and realised I was just a very attentive for-loop.

So I wrote the for-loop as a prompt. The main session stopped doing work and became an orchestrator:

## Orchestration rules

- Act only as an orchestrator; never do the work of a phase yourself.
- Run phases sequentially. For each phase, create a new, isolated subagent
  and ask it to read and follow that phase's skill.
- Before each phase, read the progress file. After it finishes, record the
  result before starting the next one.
- Each subagent reports in at most 10 lines: status, artifacts, blockers.
- If a phase fails or is blocked, record it, stop, and report why.
  Do not run later phases.

Everything else in the prompt is about making that trustworthy. Each phase gets a fresh subagent with only the minimum it needs: the goal, the phase instructions, the relevant artifacts and the acceptance criteria. No transcripts, no "here's everything we discussed". Every subagent returns the same short report (PASS, FAIL or BLOCKED, plus artifacts, checks run and blockers), with one line I consider essential: PASS is only valid when the acceptance criteria were actually checked. The absence of reported errors is not evidence.

A progress file is the orchestrator's memory, updated after every step. The first time a session died halfway through a feature, a fresh one read that file and picked up exactly where the old one stopped. That's when I started trusting long flows.

After the phases pass, an independent subagent reviews the whole change. If it finds issues, new subagents fix them, tests run again, and a new review checks the result, for a maximum of three rounds. After that, the flow stops and reports. It never declares success on its own word, and specs can't be edited just to make a finding go away. Only when every exit condition holds does it commit, push and open a pull request. If it can't determine the target branch with certainty, it stops and asks. Do not guess the branch is literally in the prompt.

Stage 4: Planning for agents, not for humans

Once execution was agentic, the weak point moved upstream. I handed the orchestrator a plan I had written the way I'd write it for a teammate, with tasks like "refactor the module" and "fix the tests". The agents did exactly what each line said, and almost nothing I meant. A human fills the gaps with context. An agent in a fresh, isolated context has no context to fill them with.

So I wrote a second prompt whose only job is to produce plans an orchestrator can execute. Every task carries its own execution contract: the objective, the files to load, what may and may not change, dependencies, acceptance criteria, how to verify it, and a short handoff for whoever comes next. Alongside the plan comes a dependency map (what's sequential, what can run in parallel, where agents could collide on the same files) and a checkpoint so work can resume in a fresh context.

The test I use for a good plan: could another agent execute this task using only its specification and the referenced files, without the original investigation? If not, the task isn't done being planned.

What actually changed

Looking back, the code got better, but that's not the main difference. My job changed.

When I was prompting	When I lead agents
I write requests	I write processes
The chat holds the state	Files hold the state
One context does everything	Each role gets a fresh, minimal context
"Done" is the model's opinion	"Done" is a list of verified conditions
I catch mistakes by reading everything	Gates, limits and reviews catch them, and I review the artifacts
More agents feels like progress	Delegate only what's needed for the goal

A few lessons I'd pass on:

Context is a resource you manage. Load only what's needed, persist the rest.
Teach agents to stop. An agent that halts and explains is worth more than one that guesses and keeps going.
Separate who builds from who checks. Blind tests and independent reviews only work when the checker hasn't seen the builder's reasoning.
Demand evidence, not confidence. Write it into the prompt. Agents will happily report success otherwise.
You're still accountable. I review the spec, the plan and the final diff. Leading agents doesn't mean leaving the room.

If I could tell myself one thing on day one, back in that two-hour chat, it would be this: stop trying to remember everything. Write it down, and build something that checks.

Your turn

Are you still in the long-chat phase, or have you started writing processes for your agents? I'd love to hear what guardrails you've found useful, or where agentic flows broke for you. Leave a comment.