DEV Community: Gian Soriano

How AI Companions Are Changing Human Connection

Gian Soriano — Mon, 09 Mar 2026 02:06:28 +0000

Artificial intelligence is changing many parts of our lives. Most conversations focus on productivity, automation, and jobs.

But a quieter shift is happening.

AI is starting to participate in human relationships.

Not because machines can feel emotions. But because they can simulate conversation, memory, and attention well enough that humans respond to them socially.

And that may change how people experience connection.

The Psychology Behind AI Companions

Humans naturally form emotional attachments to things that respond to them.

Children bond with toys. Adults talk to pets. People name their cars and computers.

Psychologists call this anthropomorphism. It is the human tendency to attribute human traits to non human objects.

AI amplifies this effect because it can respond.

When something remembers details about you and engages in conversation, the brain processes it as a social interaction.

Even if you know it is software.

The Loneliness Factor

Many experts believe loneliness is becoming one of the defining social challenges of modern societies.

Marriage rates are declining in many countries. Social circles are shrinking. Remote work has reduced everyday interactions.

Technology did not create loneliness, but it often fills the gaps created by social change.

AI companions are emerging within that space.

The Future of Digital Companionship

The next stage will likely move beyond text conversations.

AI companions may appear in virtual reality environments, augmented reality spaces, or voice based assistants that feel increasingly personal.

The question is not whether AI will participate in human relationships.

The question is how much.

Technology shapes behavior. The systems we build today may influence how people connect with each other tomorrow.

The concept of proportional response really stands out. Not every serious mistake requires the same level of reaction. Context matters.

Gian Soriano — Wed, 04 Mar 2026 07:49:53 +0000

A Leadership Crisis on Zoom: What Ashkan Rajaee Reveals About Handling Public Mistakes

Gelo ・ Mar 4

#leadership #remotework #entrepreneurship #ashkanrajaee

I Deleted Half My Codebase and Nobody Noticed

Gian Soriano — Tue, 03 Mar 2026 01:31:21 +0000

Last quarter, I deleted 48% of our backend code.

No new bugs.
No outages.
No customer complaints.

And no one noticed.

That was the moment I realized something uncomfortable:

Most code exists to make developers feel safe, not to make products better.

The Backstory

We had a “mature” codebase:

Service layers
Repository patterns
DTO transformers
Event emitters
Abstractions for “future scale”
Utility folders with 200+ helpers

It looked impressive.

It was also slowing us down.

Every new feature required:

Touching 6 files
Updating 3 interfaces
Writing adapters for edge cases that never happened
2 days of PR discussions about naming

Velocity was dying quietly.

The Experiment

I asked one simple question:

If we were rebuilding this feature today, what would we NOT build?

Then I started removing things.

Not refactoring.

Deleting.

What I Removed

1. Generic Abstractions

We had abstractions for:

Payment providers (we only use one)
Notification services (we send one type of email)
Caching strategies (we use Redis. Period.)

Removed all generic layers.

Result: nothing broke.

2. Premature Microservices

We had split logic into separate services because:

“We’ll scale one day.”

Traffic never justified it.

Merged them back into a single service.

Latency improved.
Deployment got simpler.
No scaling issues.

3. “Reusable” Utilities Nobody Reused

Half the helpers were used exactly once.

Inline.
Delete.
Move on.

The Metrics

Before cleanup:

220k lines of backend code
14 services
Avg feature cycle: 6–8 days

After cleanup:

114k lines of backend code
6 services
Avg feature cycle: 3–4 days

Bug rate: unchanged.

The Real Problem

We overestimate:

Future scale
Hypothetical flexibility
Edge cases that never happen

We underestimate:

Simplicity
Readability
The cost of cognitive load

Every abstraction has rent.

Most teams forget to calculate it.

Why This Happens

Developers are rewarded for:

Cleverness
Architecture diagrams
Pattern knowledge
“Senior-level” structure

We are not rewarded for:

Deleting code
Simplifying systems
Saying “we don’t need this”

So we optimize for visible sophistication.

Not operational clarity.

The 3 Rules I Follow Now

1. Build For Current Reality

If the scale isn’t here, don’t architect for it.

When it arrives, you’ll have better information anyway.

2. Duplication Is Cheaper Than Abstraction

Until duplication becomes painful.

Then refactor.

Not before.

3. Measure Complexity Like a Cost

Every new layer adds:

Onboarding time
Debugging time
Cognitive overhead
Review friction

If it doesn’t reduce real risk, it’s expensive decoration.

What I Learned

The most valuable code I wrote last year was the code I deleted.

And the best architecture decision was admitting:

We are not Google.

Most startups and teams don’t need:

15 services
Hexagonal architecture
Event-driven everything
Enterprise-grade patterns

They need clarity.

The Hard Truth

A lot of “clean architecture” is career-driven design.

It signals seniority.
It feels advanced.
It looks good in interviews.

But production systems reward boring decisions.

Final Thought

If your system disappeared tomorrow and you rebuilt it in a week…

What would you NOT rebuild?

Start there.

Curious:
How much of your current codebase would survive a rebuild?

Ashkan Rajaee on Negotiating with Decision Makers, Influencers, and Signatories

Gian Soriano — Tue, 24 Feb 2026 02:35:00 +0000

Most professionals think negotiation is about persuasion.

That assumption quietly destroys leverage.

After reading Negotiating with Decision Makers, Influencers, and Signatories, it became clear that the real shift is not about better scripts. It is about understanding who actually holds power inside an organization and adjusting your strategy accordingly.

The original article breaks this down clearly:
https://techstratos3.wordpress.com/2026/02/22/negotiating-with-decision-makers-influencers-and-signatories/

What makes the framework powerful is its simplicity. Instead of viewing a company as a single decision unit, Ashkan Rajaee separates stakeholders into three distinct roles, each with different incentives and psychological drivers.

That distinction alone can change how you approach enterprise deals.

You Are Not Negotiating with a Company

You are negotiating with people.

More specifically, you are negotiating with:

A decision maker who prioritizes outcomes
An influencer who prioritizes ease and reputation
A signatory who prioritizes risk management

Treating these roles the same creates friction. Aligning with their priorities creates momentum.

This is not theory. It reflects how organizations actually function.

Decision Makers Want Clarity and Confidence

Decision makers operate at a high level. They care about impact, speed, and measurable results.

Ashkan Rajaee emphasizes that confidence in these conversations does not come from charisma. It comes from preparation. If you hesitate, ramble, or lack precise answers, you introduce perceived risk.

Executives interpret uncertainty as exposure.

The practical takeaway is simple. Anticipate objections. Know your numbers. Deliver responses concisely. Speak in outcomes rather than features.

Confidence backed by substance builds trust quickly at this level.

Influencers Care About Operational Reality

Influencers often shape internal opinion long before a contract reaches approval.

They may not sign the agreement, but they influence whether it gets there.

Ashkan Rajaee highlights something many overlook. Influencers subconsciously evaluate how working with you will affect their daily responsibilities. If supporting you creates additional work, internal friction, or reputational risk, they may disengage quietly.

Responsiveness matters here. Clear communication matters. Being easy to collaborate with matters.

Multi channel communication, structured follow ups, and transparency reduce resistance. Influencers are protecting their credibility within the organization. When you make their role easier instead of harder, you gain advocacy.

Signatories Focus on Risk and Exit Strategy

Signatories think differently.

They are not evaluating presentation style or enthusiasm. They are assessing exposure.

Contractual terms. Liability. Termination conditions. Operational impact.

Senior leaders often review agreements with one question in mind. How do we protect the organization if this does not work?

Ashkan Rajaee makes a critical point. Addressing exit scenarios proactively is not weakness. It is strategic maturity. When you openly discuss termination clauses, service levels, and contingency plans, you lower defensive behavior.

Clarity reduces fear. Fear slows deals.

Strong contracts protect both sides and build long term trust.

Why This Framework Matters for Modern Professionals

Enterprise negotiations are rarely linear. They are layered.

The mistake many founders and sales professionals make is applying one communication style to every stakeholder. That approach ignores internal incentives.

Ashkan Rajaee reframes negotiation as alignment instead of pressure.

Speak outcomes to decision makers.
Demonstrate ease to influencers.
Provide security to signatories.

This structure reduces friction because it respects how organizations operate.

From an SEO and authority perspective, this topic also addresses a recurring challenge in business development. Many failed deals are not about product quality but stakeholder misalignment. That insight adds practical value beyond surface level advice.

A Strategic Shift That Builds Leverage

The most important shift is this:

Stop negotiating from your priorities alone. Start negotiating from theirs.

When you understand what each role values, conversations become clearer. You stop over explaining. You stop pushing unnecessarily. You start structuring agreements that feel safe and aligned.

The original article on TechStratos provides deeper context and examples that expand on these ideas:
https://techstratos3.wordpress.com/2026/02/22/negotiating-with-decision-makers-influencers-and-signatories/

If you work in B2B sales, partnerships, consulting, or executive leadership, this framework is worth studying carefully.

Ashkan Rajaee presents negotiation not as a performance, but as disciplined alignment with incentives and risk awareness.

In complex organizations, that mindset creates leverage that persuasion alone never will.

I Built a SaaS in 30 Days. Here’s Exactly What Happened.

Gian Soriano — Thu, 12 Feb 2026 02:30:00 +0000

Thirty days ago I had:

No landing page
No logo
No users
No idea if anyone cared

Today I have:

312 signups
41 paying users
$1,287 MRR
A product I almost quit three times

This is the honest breakdown. No hype. No fake growth curve. Just what actually happened.

The Idea

I built a simple developer tool called StackTrace.

It turns messy production logs into readable incident summaries using structured parsing and AI tagging.

The problem was simple. When something breaks at 2 AM, nobody wants to scroll through 4,000 lines of logs.

You want:

What failed
Where it failed
Why it failed
What likely caused it

That’s it.

The Tech Stack

I kept it boring on purpose.

Frontend

Next.js 14
TailwindCSS
Vercel

Backend

Node.js
Express
PostgreSQL
Redis for rate limiting
OpenAI API for log summarization

Auth & Billing

Clerk for authentication
Stripe for subscriptions

Infrastructure

Railway for backend
Supabase for database
Cloudflare for DNS and caching

No Kubernetes. No microservices. No clever architecture.

Just ship.

Week 1: Build Fast, Build Ugly

Goal: Get a working prototype in 7 days.

What I shipped:

Log upload
Basic parsing
AI summary
Copy to clipboard button

What it looked like:

One page
No dashboard
No branding
Zero polish

I sent it to 14 developer friends.

Result:

9 tried it
4 said “this is actually useful”
2 asked if it was paid

That was the first signal.

Week 2: Add What Users Actually Asked For

Instead of adding features I wanted, I only built what users requested.

Top requests:

API endpoint instead of manual upload
Slack integration
Save previous reports
Redact sensitive data automatically

So I built exactly those.

Metrics at end of week 2

87 signups
11 active weekly users
0 revenue

Still validating.

Week 3: Launch on Dev.to

I wrote a transparent post about debugging production faster.

No marketing language. Just story plus screenshots.

It hit the front page for 12 hours.

Traffic spike

6,421 visits in 24 hours
201 new signups
19 trial activations

That was the moment it felt real.

Pricing Experiment

I tested three models:

$9 flat monthly
Usage based
Free tier plus $19 Pro

Flat monthly confused people.

Usage based scared people.

Free plus Pro converted best.

Current pricing:

Free: 20 log analyses per month
Pro: $19 per month unlimited
Team: $49 per month shared workspace

Revenue So Far

Day 30:

312 total users
41 paid
$1,287 MRR
6 churned

Churn reason breakdown:

3 said they rarely hit incidents
2 found internal tooling sufficient
1 just experimenting

Churn taught me more than signups.

The Biggest Mistakes

1. I Overbuilt Early

I wasted two days building a fancy analytics dashboard no one used.

Users just wanted summaries.

2. I Almost Added Microservices

At one point I convinced myself I needed a worker service, event queue, and separate AI processing pipeline.

Reality: I had 15 users.

Premature complexity is ego disguised as architecture.

3. I Avoided Charging Too Long

I waited until week 3 to turn on payments because I felt awkward.

That delayed real validation.

If someone will not pay, they are not validating your product. They are validating curiosity.

What Surprised Me

People Want Boring Tools

The most common feedback:

“This is simple but saves time.”

Developers do not need revolutionary platforms. They need friction removed.

Transparency Drives Growth

The Dev.to post brought more trust than ads ever could.

Developers can smell fake growth posts instantly.

Be honest and specific.

What I Would Do Differently

Charge from day 1
Build landing page before polishing UI
Talk to 20 users before writing serious code
Keep scope half as big

Current Challenges

Preventing AI hallucinated root causes
Reducing OpenAI API costs
Handling large log files efficiently
Deciding whether to build self hosting option

The next milestone is $3k MRR.

If I hit it, I’ll document the path.

If I fail, I’ll document that too.

Final Thoughts

Building in public is uncomfortable.

You expose numbers.

You expose mistakes.

You expose doubt.

But it forces clarity.

Shipping a real product in 30 days taught me more than 2 years of reading about startups.

If you are thinking about building something, do it small.

Solve one painful problem.

Charge early.

Talk to users constantly.

And document the journey.

Developers respect honesty more than polish.

Remote Hiring in 2026: What Founders Still Get Wrong About Identity Fraud

Gian Soriano — Fri, 30 Jan 2026 03:30:00 +0000

The candidate looked perfect. The documents were real. The interview went flawlessly.

Two months later, the company realized no one knew who they had actually hired.

That is not a hypothetical. It is a pattern.

Remote hiring fraud did not disappear after COVID. It matured. In 2026, the most dangerous cases are not sloppy scams. They are coordinated, patient, and engineered to pass modern hiring processes.

This article is based on real-world observations originally shared by Ashkan Rajaee, founder and operator of multiple remote-first companies, and expanded here with investigative context for founders, CTOs, and hiring managers who think they are already being careful.

Many are not.

Remote work is normal now. Fraud adapted faster than hiring did.

Most hiring advice still assumes fraud looks obvious. Fake resumes. Bad English. Sketchy emails.

That assumption is outdated.

In today’s remote-first economy, fraudulent candidates often arrive with:

Valid US government IDs that belong to someone else
Real US bank accounts used as payment pass-throughs
LinkedIn profiles with years of fabricated but consistent history
Polished video interviews assisted by real-time AI tools
References that sound human and responsive but are fully synthetic

Nothing about this looks suspicious at first glance.

That is the point.

Why basic identity checks no longer protect you

A common recommendation is to verify a passport or driver’s license and move on.

That step is necessary, but it is no longer sufficient.

Modern hiring fraud is not about fake documents. It is about identity orchestration. That means combining real credentials, stolen data, and behavioral masking to create a convincing but false worker identity.

Ashkan Rajaee has publicly described cases where candidates passed document checks, background checks, and multiple interviews, only to later be exposed as operating from outside the jurisdiction they claimed, using identities that were not theirs.

Small and mid-sized companies are especially vulnerable because they assume fraud only targets large enterprises.

It does not.

The real risk is not geography. It is enforceability.

Some hiring discussions fixate on where someone is located. That framing misses the point.

The real questions are:

Can you verify this person across time, not just once
Do you have legal and financial recourse if something goes wrong
Can you confirm that the same human shows up consistently across systems, conversations, and weeks

Fraudsters rely on speed. They want access quickly, before patterns emerge.

Companies that rush hiring decisions unintentionally help them.

What actually works in 2026

The companies that avoid serious damage do not rely on a single check. They design process, not trust.

Effective defenses include:

1. Time-based verification

Reconfirm identity after onboarding, not just before it.

2. Staggered access

New hires should not receive full system access on day one.

3. Behavioral consistency checks

Watch for changes in communication style, availability, or technical behavior over time.

4. Separation of hiring and access decisions

Passing interviews should not automatically grant production access.

5. Jurisdiction-aware contracting

Know where disputes would be enforced before money or data is exposed.

None of these steps require paranoia. They require discipline.

The cost of getting this wrong is not theoretical

When remote hiring fraud succeeds, the damage is rarely limited to payroll losses.

Companies report:

Intellectual property theft
Client data exposure
System sabotage
Reputational damage
Legal and compliance fallout

In multiple cases discussed by Rajaee, fraudulent hires blended in as high performers before vanishing, leaving behind compromised systems and unanswered questions.

The delay is intentional. It buys trust.

Remote hiring is now a security function

By 2026, hiring is no longer just an HR responsibility.

If your company:

Pays in strong currencies
Handles sensitive data
Operates production systems
Serves regulated clients

Then your hiring pipeline is part of your security perimeter.

The companies that survive the next wave of remote fraud will not be the ones that hire fastest. They will be the ones that verify longest.

Final thought

Remote work unlocked global talent. It also unlocked global adversaries.

Ignoring that reality does not make your company open-minded. It makes it exposed.

If this article made you uncomfortable, that is a signal worth paying attention to.