DEV Community: Cesar Aguirre

#3.—Use AI for opposite tasks.

Cesar Aguirre — Tue, 16 Jun 2026 15:07:17 +0000

Cesar Aguirre

Jun 15

Unpopular Opinions on AI-Assisted Coding That May Annoy You

#discuss #coding #beginners #ai

2 min read

Unpopular Opinions on AI-Assisted Coding That May Annoy You

Cesar Aguirre — Mon, 15 Jun 2026 05:00:00 +0000

Vibecoding was bad. But now, AI-assisted coding seems...fine?

Nothing sparks more heated discussions than asking coders about best practices. The other day, someone I follow on LinkedIn shared his weekend AI experiment to build an app. As usual, "passionate" coders threw virtual stones, saying he didn't follow the right approach, engineering practices, or the latest spec workflow.

To turn the conversation around, he asked for our unpopular opinions about AI-assisted coding.

To avoid burying mine in a comment, here they are:

#1. Use AI as a calculator.

Only useful if you know what you're doing. Otherwise, it's just a cool toy.

#2. Don't let AI touch code directly.

That's my go-to rule for coding with AI.

Unproductive? Maybe. But it forces me to decompose problems and validates AI-generated code.

#3. Use AI for opposite tasks.

This is my most recent rule:

If I write code, AI reviews it. If AI generates it, I review it.

According to a recent Sonar survey, only 48% of respondents always check AI-assisted code before committing. #yolo, right? By reviewing, I'm already in the top 50%.

#4. AI is like a semi-autonomous car.

You trust it to steer, but you never take your hand off the wheel. Otherwise, AI could be a sloppy junior coder with bad memory.

AI alone won't make you a great coder. It only amplifies the skills you already have. That's why I wrote Street-Smart Coding—because you need more than syntax to stand out.

#2.—Showing progress is better than doing the work.

Cesar Aguirre — Thu, 11 Jun 2026 15:42:55 +0000

The shift from code to meetings

Cesar Aguirre

Jun 8

12 Hard Truths About Coding I Learned the Hard Way After 10+ Years

#career #careerdevelopment #beginners #coding

3 min read

#4.—The work isn't over when you finish coding.

Cesar Aguirre — Tue, 09 Jun 2026 15:32:26 +0000

The shift from code to meetings

Cesar Aguirre

Jun 8

12 Hard Truths About Coding I Learned the Hard Way After 10+ Years

#career #careerdevelopment #beginners #coding

3 min read

12 Hard Truths About Coding I Learned the Hard Way After 10+ Years

Cesar Aguirre — Mon, 08 Jun 2026 05:00:00 +0000

I got fired from my first job, took down a database server with a badly written query, and was rejected from a FAANG. That all happened over the past 10 years.

But I've learned a lesson or two about coding along the way:

1. Estimates are just guesses.

The problem is when your guesses don't overlap with everybody else's guesses.

2. Showing progress is better than doing the work.

Did you guess you can finish a task in 4 days? No, no, no.
You're better off splitting it into smaller ones to show progress.

3. Proofs of concept are better than long documents nobody will read.

When was the last time you read more than 2 or 3 pages of documentation?

You're better off creating a quick and dirty Pull Request to show an idea or a prototype. "Working code over documentation."

4. The work isn't over when you finish coding.

After coding comes deployment, testing, user adoption, customer support, and follow-up.

5. The more senior you become, the less it's about coding and the more about meetings.

Did you join Software Engineering because you like coding? Forget about that.

You'll spend more time in meetings:

1-on-1s,
Daily meetings,
Retrospectives,
Sprint planning,
Alignment meetings,
Brainstorming sessions,
Poker estimation sessions,
A few minutes with a guy from another team who needs to touch the code you wrote one year ago and you don't remember now.

And on and on...

In a perfect day, you'll have 1 or 2 hours of coding without distractions.

6. You learn to love tests when you work with a legacy app.

Call it unit, integration, end to end, TDD, BDD, or anything DD.

You're better off with anything that lets you know when you break something before shipping your code.

7. Don't start a big major refactoring if nobody asks you to.

This is what I call Massive Unrequested Refactorings.

Either you refactor as part of your tasks (honoring your current estimates. See #1) or make it official as part of your sprint planning. There's no point in between.

8. Don't waste time on pointless discussions about tools or tech.

— "Entity Framework is the best."
— "No, it's painfully slow."
— "Nooo, stored procedures are the best"

Arrggg!

Tools are just tools.
That's why we, coders, have the reputation of being opinionated and grumpy.
And please, let's not talk about clean code and best practices. That's a subject I changed my mind about.

9. Always automate code style and best practices.

Don't ask a human to do the work of a machine.
Code style perfectly matches the type of work for machines.

10. Projects fail because of communication problems.

The same thing I've heard about marriages.

At a past job, I was engaged in 3- or 6-month projects.
We used the shiniest and brightest tools and frameworks.
But some projects ended up off the rails.

The only moving variable?
Our communication patterns:
Failing to communicate expectations, project goals and scope, action plans, and technical issues on time.

11. Every tech problem is a communication problem.

It's a corollary of #10.

At a past job, I was new to ASP.NET Core and when trying to test my code, I changed a connection string in a settings file and ended up deleting another environment database. Ooops!

I used the wrong settings file in the wrong environment.
I didn't ask, nobody told me, and there wasn't any restrictions or guards in the code.

It was a communication problem.

12. Solve the problem you have today.

Premature optimization or just being lazy, don't solve and optimize for a problem you don't have yet. Avoid writing just-in-case code.

If any of that resonates, check out Street‑Smart Coding, the roadmap with 30 practical lessons I wish I had starting out my coding journey.

When code is cheap, here's how you can stand out:

Cesar Aguirre — Fri, 05 Jun 2026 15:58:15 +0000

Cesar Aguirre

Mar 9

Forget Syntax and Lines of Code. Do This to Stand Out

#coding #beginners #career #careerdevelopment

2 min read

Recently, for the nth time, I had to bulk-import records using Excel.

Cesar Aguirre — Tue, 02 Jun 2026 14:23:09 +0000

Cesar Aguirre

Jun 1

The Excel Paradox of Coding

#coding #beginners #softwaredevelopment #programming

1 min read

The Excel Paradox of Coding

Cesar Aguirre — Mon, 01 Jun 2026 05:00:00 +0000

Last week, for the nth time, I had to bulk-import records using Excel.

No matter how advanced and complex your business rules and code, they often circle back to reading and writing Excel files.

I should call it The Excel paradox of coding.

Instead of writing enterprise software, maybe we should build Excel add-ons and let end users stick to what they know, Excel.

Tasks for bulk-importing from Excel files

If you're starting out, here's a street‑smart tip:

Learn to work with Excel in your language of choice to:

Download an Excel file with existing records.
Upload an Excel file with updated columns, using an ID column to find matching records.
Validate data integrity of the file. Be careful with date and numeric columns.
Bulk-update the records from the file. Optionally, use a background processor.
Report once the file is processed. Optionally, report the progress with a completion bar on a page and send an email when done.

It'll save you countless headaches. You'll use it a lot! I've seen those tasks in every single job I've had. Let know in the comments how many times you've worked with Excel in the last year.

That lesson didn't make it into Street‑Smart Coding, but inside you'll find a roadmap with 30 practical lessons to level up your coding skills.

AI may already be turning translators into proofreaders. Coders could be next?

Cesar Aguirre — Tue, 26 May 2026 13:29:41 +0000

Shortcomings in idioms and technical jargon

Cesar Aguirre

May 25

Now I See Why Translators Are Panicking Over AI—Should Coders Panic Too?

#discuss #coding #ai #programming

2 min read

Now I See Why Translators Are Panicking Over AI—Should Coders Panic Too?

Cesar Aguirre — Mon, 25 May 2026 05:00:00 +0000

Last year, I met a young translator reinventing herself.

She studied Translation for five years at a local university. We met online by commenting and engaging on each other's LinkedIn posts. When we met, she was looking for another way to make money. Her agency cut down her rates and couldn't find her as many gigs as before.

Who to blame? AI!

AI isn't disappointing at translation. But it doesn't score A+

Her story came to mind when I started my own translation project, and I quickly understood why she was looking for another job.

Recently, I translated Street-Smart Coding to Spanish. As a native Spanish speaker, I could have done it easily myself.

But to make it faster, I used Copilot with a simple prompt. I specified a tone, voice, and style. Latin American conjugations and vocabulary instead of Spaniard ones, for example.

I was surprised by the results.

Copilot translated chapters with almost no fixes. Of course, there were places where the phrasing made it clear the text was machine-generated.

In English, we say "wear all hats" when someone has to do multiple tasks alone. Copilot translated word by word. The same expression in Spanish ("usar todos los sombreros") makes no sense at all.

Copilot struggled with coding terms like "parser combinators." In Spanish, we use a completely different term. Direct translation doesn't work either.

That's when I jumped in. But Copilot handled most of the job in just a couple of work sessions.

What if it isn't only translation, but coding too?

This made me rethink one of the lines I heard the other day:

"AI won't take your job. It will change your job description."
(Credits to Kevin Kelly)

AI may already be turning translators into proofreaders. Coders could be next. Maybe the world won't need as many coders, and coding may no longer mean typing symbols anymore. Who knows?

In any case, I predicted AI won't take our jobs by 2034. Let's see if I was right. In the meantime, I'd like to pick a DIY skill and double down on my creative and writing skills—just in case.

When AI generates code faster than any of us, you need more than syntax to stand out. That's why I wrote Street-Smart Coding, a roadmap to build hype-proof skills.

It might seem slower or old-school. But it forces me to stay in control

Cesar Aguirre — Tue, 19 May 2026 13:31:51 +0000

Cesar Aguirre

May 18

The One Rule I Follow to Code with AI (Without Losing My Skills)

#beginners #ai #coding #programming

2 min read

The One Rule I Follow to Code with AI (Without Losing My Skills)

Cesar Aguirre — Mon, 18 May 2026 05:00:00 +0000

I haven't blindly jumped on the AI hype train. But I'm no hater either.

AI is here to stay. That's why I've tried AI to offload tasks while coding.
But after a few weeks, I was so dependent I couldn't write a simple LINQ query by hand.

So I decided to stop relying too much on AI and adopted this one rule:

Use AI outside my IDE or editor.

When I'm coding, I like to think I'm a surgeon in an operating room, and AI is my assistant doctor. They hand me tools and monitor my patient, but I'm always in charge.

How to be always in charge of AI

To stay in control, I never let AI into my editor. I use it in a browser tab.

It might seem slower or old-school. Sure!
But it forces me to decompose my problem and extract relevant code for AI.
And once I have an answer, it forces me to make it work on my side.
At least, I know if the output actually works.

Just like code you find on StackOverflow or anywhere else online, don't use what AI gives you if you don't understand what it's doing.

Don't let AI touch your code directly either.

AI is faster at generating code than us. No doubt! But being a good coder isn't about typing fast. It's about estimation, collaboration, and many more skills I've included in Street-Smart Coding—The roadmap I wish I had when I was starting out.