Before the Gen AI Age: Why Some Developers Succeeded and Others Failed

Lot of developers and companies would give up projects, re-write multiple times, never get results, or live a nightmare maintaining software where every change caused bugs.

Why did that happen? Check those scenarios.

Because they either did over engineering or spaghetti code.

You would see programmers getting fired for performance issues in projects where there was a knowledge hero adding multiple layers of abstraction and only himself understood that chaotic engineered environment.

And then you open the database schema columns names are two or four characters and no documentation explaining what they are.

Or you would see the spaghetti codebase, so called "senior" engineers doing classes with 6 thousand lines, methods with hundreds of lines.

You open the codebase and the cognitive load explodes.

You change one line and break logic everywhere.

Hard to understand. Hard to change. Usually no documentation useful for developing.

Agile Sprint that supposed to be 7 or 15 days take 3 months fixing bugs that were fixed dozen times, tech lead wouldn't admit code didn't grow health.

If the company loses the founder developers, the project simply dies, people decide to re-write it.

How did I realize that?

When I started working, I started as a freelancer.

I didn't have job opportunities.

I didn't have a mentor.

The only thing I knew was making it work, so I'm guilty, I did spaghetti it was the only way I knew, and many people were spaghetti's developers as well.

Then I started working as a web programmer in a web agency and later as a programmer in a startup.

I joined codebases that already had 5 or 6 programmers rage quitting bad code bases, a complete nerd exodus.

I used to work 10 up to 13 hours a day just to get small results.

The codebase was a mess:

• God classes
• Methods, classes, database columns, and variables with ambiguous or unclear naming
• Unnecessary abstractions
• Tightly coupled code
• Duplicated code
• Huge methods
• Hidden dependencies

You change one thing and many other things break.

I also produced horrible projects at some point, they were functional, the user click button produce what they want, but bugs due to edge cases, and that's what I was able to do at that time.

When I studied Computer Science I had classes about calculus, math, network, LISP, C and nothing explained how to produce software correctly neither any other course.

Then I had my first real mentor.

That happened when I joined a company, the guy wanted me to study hard half of my day some topics so I could keep in his company.

A guy gave me books like Clean Code and Clean Architecture, a Udemy account with software engineering courses, videos about paradigms, and exercises all the time.

Break this huge class into smaller classes applying Single Responsibility Principle.

Refactor this method until it becomes readable.

Write tests this method including for all possible scenarios where that method could break.

The guy pushed me hard into Test Driven Development.

Our pipelines had something like 3 thousand up to 8 thousand tests.

Then I realized something.

We were much slower at the beginning, facing learning curves, difficulties, blockers, but almost nothing broke later, we kept moving forward, time to do side projects instead bug fixing and even playing games during working hours.

We later after years we changed code and nothing exploded because things were loosely coupled, and it was consistent the time to do changes over time, onboard was quick.

When I had to change something, it was usually:

• A small class
• A small method
• A readable method, variable and table column name
• Strong typed variables with meaningful names
• No repeated code
• Summary and comments that really give context
• Simple implementations coming from KISS mindset
• I just look code and in a instant you get it
• Method name in IDE had button "run tests" and know if something broke just after changing

That was the moment I realized:

This is the way for long term projects.

Because people like Uncle Bob and Kent Beck have been doing this longer than I've been alive.

If they reached those conclusions after decades, there was probably a reason.

And honestly, results were good.

Most important of all:

It was a healthier way to build software.

Less stress.

Less panic.

You can go to the gym and live better, not trash talk due to anger issues when production break and customer public say how unsatisfied he is.

My conclusion about how to do software it's do the basic engineering well.

Example

• Write E2E tests for UI
• Unit tests for domain
• Test containers for repositories
• YAGNI
• KISS
• Tactical Domain Driven Design
• Separate Data Access with repository pattern
• Do well the domain layer

The real challenge in software is change and maintain in the long term.

We write systems that may live for 20 years or more.

Most of us won't even see the end of what we built.

Now the new spaghetti is vibe coding

Let's relate this experience before Agents with AI agents era such as Codex and Claude

Fabio Akita said something I really liked:

"AI will reveal who you are."

What does that mean?

If your mentality was always:

"Just make it work and move on."

Without caring about code structure, readability, database design, testing or maintainability, AI will amplify that 10x.

But if you truly believe in good practices, then AI becomes a multiplier in the right direction.

You:

• Write .md files with standards
• Learn prompt engineering
• Provide context and point agents to documentation
• Use planning mode
• Analyze generated code instead of blindly accepting it
• Keep iterating prompts to refactor code
• Keep pull request review, Git flow and testing culture

Then the quality stays the same.

Only faster.

Why are companies hiring junior developers again and failing with AI?

Because bad code, spaghetti-coded systems they lack of clear boundaries, missing tests and poor documentation require too much context and generate huge token costs.

Variables, classes, methods, database schemas, and business terminology lack a consistent ubiquitous language based on DDD principles, creating a chaotic environment for deterministic tools.

Last year I did a interview and the teach lead asked me "How capable are you in working in a very complex project where every class can have 6 thousand or even more lines code?"

Next question he wanted to know if I knew strategies to save tokens and he said how AI Agents are a lame, since they don't work well.

First thought came to my mind was "6.000 lines a class then those guys don't follow the most basic software engineering principle the Single Responsibility Principle, they probably don't follow anything at all, that's why they have problem with tokens".

Probably AI need much computation to understand all their code base, it probably fail at first try then have to iterate multiple prompts until it run out of tokens, that's why they are angry and mad on a interview...

When I write prompts, I usually describe the system context and the intended architecture clearly. For example:

“Class X has method Y. On mobile, this behavior happens because of logic coming from class Z. We need a refactor that simplifies this flow, reuses existing functionality where possible, and extracts this feature into a reusable component for future use.”

That kind of prompt may only require around 100 lines of meaningful context.

The human brain has trillions of neurons and evolves naturally, so he can know that wrong is right, but a deterministic tool no, for example when column names mean opposite of what they should.

You still remember context from MS-DOS or ENIAC if you are a dinosaur.

But an AI agent loses context every session.

When it receives a new task, it needs to scan everything again, so if your code base is gigantic because it doesn't follow Single Responsibility Principle, it will cost a lot tokens then you will have problems.

A human already carries awareness of the system, that's why the founders of projects they always know what to do.

Now, if you create good prompts with proper context, including .md files, the agent knows exactly which classes and methods matter.

It becomes like a sniper shot on a stopped target.

That is how, with intelligence you actually succeed with AI.

How I'm getting good results with AI Agents while keeping my values with good practices.

I write some .md files for example

• claude.md or copilot.md - Set general instructions and set which MD files have to read.
• Communication.md - Instructions for communication.
• Arquitecture.md - Define the high level details structure for example test strategies.
• SystemDesign.md - Define design patterns, principles such SRP, clean code, dry.
• Limits.md - Define restrictions such deleting azure resources or pushing to master.
• Stories/FeatureX.md - Set each feature in a file where I can specify all requirements context thought a file avoiding massive prompt text.

Then with chatGPT help I write a prompt with some engineer quality such using Self-Reflection

I use plan mode to make sure the generated code by this prompt is following my guidelines and avoid hallucination.

I do everything in local environment in a branch for this feature or change.

Then after accepting changes, I run tests, manually test, review and open the pull request.

Extra personal tips:

• Use best model for your task, example Opus for complex tasks, Sonnet for simpler tasks.
• Learn your tool of choice, mine was Claude then I use /clear peer task /compact long sessions /plan to activate discussion.
• Have a backup tool, I also have Copilot.
• For high level planning use OpenAPI Pro, much better to brain storm ideas.

Final conclusion

I agree with Fabio Akita AI will amplify depending of our who we are.

The companies winning with AI are usually the same companies that already had maturity, they keep doing good practices and QA processes.

What we do is organize with intelligence instructions for machines doesn't matter if it is assembly on English.

SEO Keywords

AI coding agents, vibe coding, software engineering, clean architecture, technical debt, software maintainability, prompt engineering, AI assisted development, TDD, Clean Code, software scalability, coding with AI, Codex, Claude AI, software engineering practices.