DEV Community: Eugene Maiorov

Stop Copy-Pasting Project Context Into AI Chats

Eugene Maiorov — Thu, 25 Jun 2026 07:26:12 +0000

I use AI tools a lot when I write code.

And I keep seeing the same annoying pattern.

You open a new chat and start with:

Here is the project context...

Then you paste the README.

Then some API docs.

Then one file.

Then another file.

Then you explain the part that is not in the docs.

Then you say:

Important: ignore the old service, we don't use it anymore.

The model answers.

It is almost right.

But not really.

So you paste more context.

And tomorrow you do the same thing again.

At some point, this stops being “AI assistance” and becomes manual context babysitting.

The usual workflow looks like this

Developer
   |
   v
Copy README
   |
   v
Copy docs
   |
   v
Copy code files
   |
   v
Explain architecture
   |
   v
Correct outdated assumptions
   |
   v
Ask the actual question

This works for one small task.

But it does not scale.

A chat window is not a project memory. It is just a temporary place where we throw text and hope the model understands enough.

Project context is usually scattered

In a real project, context lives everywhere.

Context	Where it usually lives
Setup instructions	README
API behavior	docs or code
Architecture decisions	old tickets, Slack, Notion
Deprecated logic	someone's memory
Database structure	migrations
Business rules	code, comments, support cases
Deployment details	CI/CD config
Edge cases	production bugs

When we paste only part of this into a chat, the model gets only part of the story.

And then it guesses.

Sometimes the guess is useful.

Sometimes it creates more work.

The model is not always the problem

It is easy to blame the model.

“GPT failed.”

“Claude missed the point.”

“The coding agent is dumb.”

But many times the model did exactly what we asked.

We gave it incomplete context.

For example:

Question:
How should I add a new payment provider?

To answer this properly, the model needs to know things like:

- Is there already a payment abstraction?
- Are providers stored in config or database?
- How are webhooks handled?
- Are payments async?
- What should be logged?
- What should never be logged?
- Are there old providers that should not be copied?
- Are there tests?

Without that, the model will still answer.

That is the dangerous part.

It will answer confidently from partial context.

Copy-paste context also gets stale

Another problem is context drift.

Your README says one thing.

Your code does another thing.

Your old docs describe a service that was removed six months ago.

A ticket contains the real decision, but nobody moved it to documentation.

So the chat context becomes a random mix of truth, old truth, and maybe-truth.

Something like this:

Project context in chat
|
|-- README
|      status: mostly correct
|
|-- old API docs
|      status: partly outdated
|
|-- copied code file
|      status: correct
|
|-- architecture note
|      status: old
|
|-- developer explanation
|      status: correct but temporary
|
|-- missing edge cases
       status: unknown

No wonder the model gets confused.

Bigger context windows do not fully solve this

Yes, larger context windows help.

You can paste more.

You can include more files.

You can dump more docs.

But “more text” is not the same as “better context”.

A simple mental chart:

Usefulness
^
|                        clean, structured context
|                     /
|                  /
|               /
|            /
|         /
|      /  giant copy-paste dump
|   /
+---------------------------------> Amount of text

At some point, more pasted text becomes noise.

The model does not need everything.

It needs the right thing at the right moment.

A better pattern: reusable project context

Instead of pasting project context again and again, I think we need to treat project context as something reusable.

Not like this:

Every chat starts from zero

But like this:

AI chat / agent
      |
      v
Project context layer
      |
      |-- repository knowledge
      |-- docs
      |-- architecture rules
      |-- API examples
      |-- internal tools
      |-- deprecated things to avoid

Then the agent can use the project context when it needs it.

The developer should not have to explain the same project every day.

What this could look like

Imagine a simple project context file.

Not perfect. Not magic. Just structured.

project:
  name: billing-api
  stack:
    - Laravel
    - MySQL
    - Redis
    - Queue workers

rules:
  - Never log full payment payloads
  - Webhooks must be idempotent
  - New providers must implement PaymentProviderInterface
  - OldStripeService is deprecated, do not copy it

important_paths:
  - app/Payments
  - app/Http/Controllers/WebhookController.php
  - database/migrations
  - tests/Feature/Payments

common_tasks:
  add_payment_provider:
    read_first:
      - app/Payments/PaymentProviderInterface.php
      - app/Payments/StripeProvider.php
      - tests/Feature/Payments

This is much better than pasting random files into chat.

The point is not this exact YAML format.

The point is that project knowledge should have structure.

This is where MCP becomes useful

MCP gives AI clients a standard way to connect to external tools and context.

So instead of dumping everything into the prompt, we can expose useful project context through an MCP server.

For example, an MCP server for a project could provide tools like:

{
  "name": "search_project_docs",
  "description": "Search approved project documentation and architecture notes.",
  "input": {
    "query": "string"
  }
}

Or:

{
  "name": "get_project_rule",
  "description": "Returns internal development rules for a specific area.",
  "input": {
    "area": {
      "type": "string",
      "enum": ["payments", "auth", "deployments", "database"]
    }
  }
}

Or:

{
  "name": "find_relevant_files",
  "description": "Finds important repository files for a development task.",
  "input": {
    "task": "string"
  }
}

Now the agent does not need the whole project pasted into the chat.

It can ask for the right piece of context.

But “connect everything” is also a trap

There is another mistake.

People connect all docs, all tools, all APIs, all repositories, and all tickets.

Then they expect the agent to figure it out.

That can become another kind of mess.

Bad setup:

AI agent
   |
   |-- 200 tools
   |-- 10 repositories
   |-- 5 documentation spaces
   |-- old tickets
   |-- random notes
   |-- internal APIs with unclear names

This is not much better than copy-pasting.

It is just automated noise.

A better setup is smaller and cleaner:

Better setup:

AI agent
   |
   |-- search approved docs
   |-- inspect repository knowledge
   |-- read architecture rules
   |-- find relevant files
   |-- use a few clear project tools

The goal is not to give the model everything.

The goal is to give it a good surface.

Tool names matter more than they look

This is bad tool design:

{
  "name": "get_data",
  "description": "Gets data",
  "input": {
    "type": "string"
  }
}

The model has to guess everything.

What data?
From where?
For what use case?
What should the input look like?

This is better:

{
  "name": "search_billing_docs",
  "description": "Searches approved billing documentation. Use this before changing payment provider logic.",
  "input": {
    "query": "string"
  }
}

Still simple.

But now the model has a much better chance of using it correctly.

This is why I think tool design is becoming part of developer experience.

We are no longer designing only for humans.

We are also designing for models.

Local context is fine until a team needs it

For one developer, local setup is okay.

You run a local MCP server.

You connect it to your AI client.

You add some tools.

It works.

But in a team, this gets messy fast.

Problem	What happens
Different local configs	AI answers differ between developers
No versioning	Tool changes break workflows
No shared testing	Nobody knows if the agent uses tools correctly
Old docs included	The model learns the wrong thing
Too many tools	The agent chooses poorly

This is where project context starts to look like infrastructure.

It needs to be shared.

It needs to be tested.

It needs to be versioned.

It needs to be maintained.

This is why I am building Vectoralix

I am building Vectoralix because I think AI agents need better project context, not just bigger prompts.

Vectoralix is a platform for creating, testing, versioning, and hosting MCP servers and knowledge sources for AI agents.

The workflow I want is simple:

Import repository
      |
      v
Add project knowledge
      |
      v
Create clear MCP tools
      |
      v
Test in playground
      |
      v
Publish stable MCP endpoint
      |
      v
Use it from AI clients

The playground part is important.

A tool can be technically valid and still bad for an agent.

The name may be unclear.

The response may be too large.

The schema may be too open.

The model may choose it at the wrong time.

So I do not think MCP should be “deploy first, debug later”.

It should be tested before it becomes part of a real workflow.

The real goal

The goal is not to replace developers.

The goal is much smaller and more practical.

Stop explaining the same project again and again.

Stop pasting the same README.

Stop saying “ignore that old file” every day.

Stop asking the model to guess from partial context.

A good AI workflow should feel more like this:

Developer:
"Add a new payment provider."

Agent:
"I found the payment interface, current provider, webhook rules,
and tests. I will follow the existing pattern and avoid the deprecated service."

That is the kind of workflow I want.

Not magic.

Just less repetitive explaining.

Final thought

Copy-pasting project context into AI chats is okay for quick tasks.

But if you do it every day, it is probably a sign.

Your project context is not reusable yet.

The next step for AI coding is not only better models.

It is better context infrastructure.

Cleaner project knowledge.

Better MCP servers.

Smaller and clearer tools.

Less guessing.

More useful agents.

Stop Reinventing Boilerplate: Modern Web Development Is About Orchestration

Eugene Maiorov — Tue, 16 Jun 2026 17:45:29 +0000

There is an old habit in web development that still feels attractive: build everything yourself.

Custom boilerplate. Custom admin panels. Custom authentication. Custom deployment scripts. Custom validation layers. Custom logging. Custom everything.

It feels professional. It feels like engineering. It feels like control.

But in many modern web projects, I think this approach is becoming a utopia.

Not because developers became worse. Not because writing code is bad. But because the web became too complex, too fast-moving, and too expensive to maintain when every team keeps reinventing the same basic building blocks.

The real cost of “just writing it ourselves”

When a team writes its own boilerplate, the first version often looks reasonable.

A few helpers here. A small internal framework there. Some custom conventions. Some glue code. Some shared base classes. A small wrapper around an API. A custom permission system because “our case is different.”

At the beginning, it works.

The problem appears later.

Six months later, nobody remembers why the abstraction was designed that way. One year later, the project has edge cases nobody wants to touch. Three years later, the system becomes “legacy,” not because the programming language is old, but because the decisions inside the codebase are hard to change.

This is how many old systems become almost impossible to support.

Not always because they were badly written. Often because they were over-customized, under-documented, and built around assumptions that stopped being true.

Orchestration is becoming more important than boilerplate

Modern web development is less about writing every part from scratch and more about choosing, combining, and controlling existing systems.

Authentication can be handled by mature providers.

Payments can be handled by Stripe, Paddle, Lemon Squeezy, or other platforms.

Email delivery can be delegated.

Analytics can be delegated.

Background jobs, queues, observability, file storage, search, feature flags, error tracking, deployment, monitoring — almost every common problem already has strong solutions on the market.

The developer’s job is changing.

It is not only “write more code.”

It is:

choose the right components;
understand tradeoffs;
design clean boundaries;
keep the system replaceable;
avoid unnecessary coupling;
document decisions;
keep the architecture understandable.

That is engineering too.

Sometimes it is harder than writing code.

Less code usually means less liability

Every line of code you own is a line you may need to debug, test, secure, migrate, document, and explain to another developer.

A smaller codebase is not automatically better, but unnecessary code is almost always expensive.

When you use a mature external solution, you reduce some maintenance burden. You let another team solve a generic problem so your team can focus on the specific business problem.

Of course, this is not free.

The flip side is dependencies.

Every dependency is a risk:

vendor lock-in;
pricing changes;
API changes;
security issues;
service downtime;
migration cost;
loss of control.

So the answer is not “use dependencies everywhere.”

The answer is to be intentional.

Do not build everything yourself by default. Do not install everything by default either. Think in tradeoffs.

The question should be:

Is this code part of our real advantage, or are we just rebuilding infrastructure that already exists?

Architecture matters more than clever boilerplate

A lot of developers still spend too much energy on implementation details that tools can already handle.

Formatting. Indents. Whitespace. Import sorting. Small style preferences.

These things matter for consistency, but they should not consume expensive human review time.

Use linters. Use formatters. Use static analysis. Use code analyzers. Use CI checks. Let tools fight about spaces and semicolons.

Human review should focus on things tools cannot fully understand:

Is this design maintainable?
Is the boundary clear?
Will this scale?
Is this abstraction necessary?
Is this decision documented?
Can another developer understand this six months later?
Are we creating future migration pain?

In 2026, arguing manually about indentation in pull requests is too expensive.

Documentation is not optional anymore

In old projects, the biggest problem is often not the code itself.

The problem is missing context.

Why was this service created?

Why does this table have this strange structure?

Why is this module not using the same pattern as the rest of the system?

Why are we afraid to refactor this part?

Without documentation, every new developer has to reverse-engineer history from code, Git commits, Slack messages, and tribal knowledge.

That is slow. That is expensive. That is risky.

Good project documentation does not need to be huge. But every serious project should have clear notes about:

architecture decisions;
coding conventions;
deployment flow;
domain rules;
external dependencies;
known limitations;
reasons behind important tradeoffs.

This is more valuable than another custom boilerplate generator.

“Inventing the bicycle” is not always innovation

There are cases where custom code makes sense.

If your business depends on a unique workflow, a unique algorithm, a unique user experience, or a unique integration model, then yes, build it carefully.

But many teams invent the bicycle in places where the bicycle is already good enough.

Custom auth is not usually innovation.

Custom billing is not usually innovation.

Custom logging is not usually innovation.

Custom admin CRUD is not usually innovation.

Custom formatting rules are not usually innovation.

Most of the time, these things are just future maintenance.

The best code is sometimes the code you decided not to write.

The modern developer should think like an architect

I do not think web developers should stop coding. That would be absurd.

But I do think the center of gravity is moving.

The valuable developer is not the one who writes the most boilerplate. The valuable developer is the one who knows what should exist in the codebase and what should not.

That means understanding architecture, systems, documentation, team workflows, automation, deployment, testing, observability, and long-term maintenance.

It means asking better questions before writing code:

Should we build this?

Should we buy this?

Should we integrate this?

Should we remove this?

Will this decision still make sense in two years?

Good software is not only created by writing code. It is also created by avoiding the wrong code.

Final thought

Modern web development is not about proving that we can build everything ourselves.

Most experienced developers can build almost anything given enough time.

The real question is whether we should.

In many projects, the better strategy is orchestration: using existing tools, keeping the codebase smaller, documenting decisions, enforcing style automatically, and spending human attention on architecture instead of boilerplate.

Because in the long run, the most expensive part of software is not writing the first version.

It is living with it.

SEO and GEO in 2026: A Practical Growth Strategy for Small SaaS Projects

Eugene Maiorov — Mon, 15 Jun 2026 19:47:02 +0000

I think a lot of indie makers still treat SEO like it is only about keywords, backlinks, and publishing blog posts.

That is still part of it, but in 2026 it feels incomplete.

Search is changing. AI answers, Google AI Overviews, ChatGPT-style discovery, Reddit threads, YouTube videos, directory pages, and “best tools for X” lists are all part of the same discovery surface now.

So when people say GEO — generative engine optimization — I do not think it should mean “hack AI search.”

For small products, I think it means something simpler:

Make your product easy to understand, easy to cite, easy to compare, and easy to discover across the places where people already search.

That is the idea behind how I am thinking about growing Linxalium, a curated directory for developer tools, SaaS products, and useful projects.

SEO is still the base layer

I do not believe SEO is dead.

But I also do not think “write 100 AI articles and wait” works anymore.

The stronger approach is boring but more durable:

clear landing pages
useful category pages
good titles and descriptions
real screenshots
fast pages
internal links
honest product descriptions
no fake reviews
no thin duplicated content

For a directory like Linxalium, this matters a lot.

A project page should not just say:

“Best AI tool for productivity.”

That says almost nothing.

A better page explains:

what the product does
who it is for
what problem it solves
what category it belongs to
whether it is free, paid, open source, waitlist, or early stage
why someone should care

This is useful for Google, but more importantly, it is useful for humans.

And if the page is useful for humans, it has a better chance of being useful for AI search systems too.

GEO is mostly about being easy to mention

I see a lot of people trying to overcomplicate GEO.

They ask:

Should I create an llms.txt file?
Should I write special AI summaries?
Should I create pages only for ChatGPT?
Should I stuff every page with question-answer blocks?

Maybe some experiments are worth trying, but I would not start there.

For small products, I would focus on making the product easy to describe in one sentence.

For example:

Linxalium is a curated directory where makers can submit developer tools, SaaS products, and small projects for discovery.

That sentence is simple. It explains the product without hype.

A good GEO strategy needs more of that:

simple positioning
consistent naming
clear category pages
comparison-friendly descriptions
public pages that can be crawled
real use cases
real examples
external mentions from relevant places

The goal is not to trick an AI model.

The goal is to create enough clear public context that when someone asks, “Where can I submit my developer tool?” or “What are some smaller Product Hunt alternatives?” your product has a chance to be understood.

Distribution beats waiting

One mistake I made before: publishing something and expecting traffic to arrive.

That rarely happens for small projects.

A better approach is to build small distribution loops.

For Linxalium, one simple loop could be:

Add a useful project to the directory.
Write a short, honest description.
Create a category page around the problem.
Record a short demo or walkthrough.
Post it on YouTube.
Use the same YouTube account to join relevant conversations.
If people click the profile, they discover the project naturally.

No aggressive promotion. No “check out my site” spam. No copy-paste comments.

Just useful participation from an account that is clearly connected to the product.

The YouTube strategy I like

YouTube is underrated for small SaaS and developer tools.

Not because every video will go viral. Most will not.

But YouTube gives you three things:

Searchable content.
A public proof of work.
A profile that can become a soft discovery channel.

For example, if I create a YouTube channel for Linxalium, I would not start with polished ads.

I would start with simple videos:

“How I submit a developer tool to Linxalium”
“How to write a better project description for directories”
“5 places to promote a small SaaS without spamming”
“What makes a project listing look trustworthy?”
“How I think about SEO and GEO for small tools in 2026”

These videos do not need to be cinematic.

They need to be clear.

A screen recording, a real example, and a useful explanation is enough.

Commenting under big videos can work, but only if the comment is useful

This is where many people get it wrong.

They find big videos with many views and write:

“Great video! Check out my tool.”

That is not marketing. That is spam.

A better comment should add something to the discussion.

For example, under a video about SEO for startups, I might write:

One thing I’d add for small SaaS projects: don’t treat GEO as a separate magic channel. I think it starts with clear public pages, simple positioning, and examples that are easy for both humans and AI systems to understand. We’re testing this with a small curated directory, and the hardest part is not keywords — it’s writing descriptions that don’t sound generic.

This kind of comment does not need a link.

The account name, profile, and channel content do the soft work.

If the comment is useful, some people may click. If nobody clicks, the comment still helped the conversation.

That is the right mindset.

The account itself becomes part of the funnel

This is a small but important point.

If your YouTube account name is connected to your project, then every good comment becomes a small brand touchpoint.

You do not need to force the link.

People can see the name. They can open the profile. They can watch the videos. Then they can decide if the product is relevant.

This is much safer and more natural than dropping the same link everywhere.

For example:

account name: Linxalium
channel description: curated directory for developer tools and SaaS projects
videos: useful tutorials about launch, SEO, directories, project discovery
comments: thoughtful opinions under relevant videos

That creates a small ecosystem.

Not a huge one. But a real one.

Directories are not just backlinks

This is also why I think directories still matter.

A bad directory is just a link farm.

A good directory helps people discover products.

For makers, a listing can provide:

a crawlable public page
a clean product description
a relevant category
a backlink
a small discovery surface
a place to explain the product outside your own website

The backlink is useful, but it should not be the only reason to submit.

If the directory is curated, indexed, and relevant, it can also become a trust signal.

That is the direction I want Linxalium to go: less spam, more useful project pages.

A simple 2026 promotion plan for a small project

If I were starting from zero, I would not try to do everything.

I would do this:

Week 1: Fix the base

Create or improve:

homepage title
homepage description
project tagline
project description
Open Graph image
category pages
sitemap
internal links
clean screenshots

Week 2: Create proof

Publish:

one real blog post
one demo video
one comparison page
one use-case page
one founder story

Not AI filler. Real experience.

Week 3: Start distribution

Join conversations on:

YouTube
Dev.to
Reddit
Hacker News
Bluesky
niche directories
founder communities

But do it carefully.

Do not post the same thing everywhere. Do not drop links without context. Do not pretend to be a neutral user if you are the founder.

Week 4: Repeat what works

Check:

which pages get indexed
which comments get replies
which videos get impressions
which directories send traffic
which posts get saved or shared

Then repeat the best channel.

Small projects do not need 20 strategies.

They need 2 or 3 channels that compound.

My current view

SEO in 2026 is not only about ranking pages.

It is about building a public footprint that makes your product understandable.

That footprint can include:

your website
your blog
your docs
YouTube demos
directory listings
useful comments
social posts
comparisons
founder notes
community answers

For Linxalium, I want to test this slowly.

No fake hype. No comment spam. No mass-produced AI pages.

Just useful pages, useful listings, useful videos, and useful participation in places where makers already search for answers.

That sounds less exciting than “growth hacks.”

But I think it is much more durable.

I Built a Small Directory for Tools That Help Developers Build Faster

Eugene Maiorov — Tue, 09 Jun 2026 07:12:33 +0000

I Built a Small Directory for Tools That Help Developers Build Faster

There are a lot of SaaS products being launched every day.

Some are big, polished, and already have marketing budgets. Others are small, useful tools built by indie developers, solo founders, or small teams. Many of those products are actually good, but they are hard to find.

That is one of the reasons I built Linxalium.

Linxalium is a small directory for tools, apps, services, and resources. The goal is simple: help people discover useful products, and help SaaS developers share what they are building in a cleaner, more structured way.

Why I built it

If you are building a SaaS product, promotion is hard.

Posting on social media disappears quickly. Product launch platforms are useful, but usually only for a short moment. SEO takes time. Communities often do not like direct promotion. And paid ads are expensive when you are still small.

So I wanted to create a place where SaaS builders can list their products in a more permanent way.

Not spam.
Not fake hype.
Not “growth hack” promotion.

Just a clean product page with the right category, description, link, and context.

A place where a product can slowly build visibility, reputation, and trust.

What Linxalium is

Linxalium is a curated directory of tools and services across categories like:

AI
Developer Tools
Design
Marketing
Productivity
Automation
Business
Analytics
E-Commerce
Education
No-Code

For users, it is a way to discover tools that may help them build, ship, design, market, automate, or manage something faster.

For SaaS builders, it is a way to present their product outside of the usual noisy channels.

Why this matters for small SaaS products

A lot of good products never get attention because the founder does not know how to promote them.

That is especially true for technical founders.

We can build the product, improve the backend, polish the UI, fix performance, add features — but then comes the hard part:

How do people actually find it?

A directory can help with that, especially when it is structured properly.

A product listing can become:

a simple public profile for the product
a way to explain what the product does
a discoverable page by category
a reputation signal
an SEO-friendly page
a GEO-friendly page for AI search and answer engines
a long-term link that does not disappear after one day

Of course, a directory alone will not magically bring customers.

But it can be one more stable place where your product exists, can be found, and can be understood.

SEO and GEO are becoming important

Search is changing.

People still use Google, but more and more product discovery also happens through AI tools, answer engines, curated lists, and recommendation-style searches.

That means SaaS products need clear public pages that explain:

what the product is
who it is for
what category it belongs to
what problem it solves
why someone should trust it

That is where directories can still be useful.

Not as a replacement for your own website, but as an additional structured presence.

Why another directory?

Fair question.

There are already many directories.

But I think there is still room for smaller and cleaner ones, especially if they help both sides:

People looking for useful tools.

And builders looking for a fair way to share their product without being annoying.

I do not want Linxalium to become a random link farm. That would make it useless.

The challenge is to keep it simple, useful, and organized.

What I want to improve next

Some things I am thinking about:

better product pages
user submissions
verification for founders
richer categories and tags
similar tool suggestions
screenshots or previews
reviews or simple reputation signals
better SEO structure
better support for AI/search discovery

The main goal is still the same:

Help useful tools get found.

Feedback welcome

I would like to hear from other developers and SaaS builders.

When you list your product somewhere, what actually matters to you?

Is it SEO, backlinks, referral traffic, reputation, category placement, reviews, or just having one more clean public page for your product?

And as a user, do you still browse directories to discover tools, or do you mostly rely on search, social media, and AI recommendations?

I Almost Quit Coding to Become a Welder

Eugene Maiorov — Tue, 26 May 2026 18:46:45 +0000

Twelve years. That's how long I've written code for a living.

About a year ago, I was ready to walk away from all of it.

I'm not joking. I spent real evenings looking up welding schools. I read about handyman gigs. I even checked what delivery drivers make near me. My plan was simple: do anything that didn't involve a screen. With welding, at least when something breaks, it's not because of a missing semicolon.

I was burnt out. Bad. I'd open my laptop, stare at the screen, and just... sit there. Four hours would pass. I'd write maybe ten lines of code, hate all of them, then delete nine. The work that used to feel like magic now felt like chewing glass.

The plot twist: I'm not even scared of new tech

Here's the funny part. I'm not some guy who hides from the future.

Back in 2022, I was one of the first 100,000 people to use GPT-3. I thought it was actual sorcery. For a hot minute, I was sure there were real humans on the other end, typing answers as fast as they could. I pictured a room full of very tired interns somewhere, sweating. (There were not. I think. I never got a clear answer on that.)

I jumped in right away. But the tools were rough back then. They'd make stuff up, break my code, and lie to my face with total confidence. Stack Overflow and the docs were still carrying me. AI was more of a weird hobby than a real helper.

Then things got bad in a way I didn't see coming.

The day my safety net disappeared

Last year, I lost my job.

Not because I was slow. Not because I messed something up. I lost it because my boss's clients figured out they could "vibecode" their own little tools. Why pay a developer when you can describe what you want to a chatbot and get something that mostly works?

Turns out my job security was one good prompt away from gone.

So there I was. Twelve years of experience, suddenly out of work, watching the exact thing I do for a living get handed out for free.

That's when the welding tabs really started piling up in my browser.

But I didn't quit. Not yet.

I had months of empty time. So I made a deal with myself.

Instead of being mad at these tools, I'd learn to actually build with them. Not just ask a chatbot to patch a bug. I mean really build. Design whole systems. Ship real features. Move fast.

It was a love-hate thing for a while. Some days the AI felt like a genius pair programmer. Other days it felt like a confident toddler with a keyboard. I'd ask for one small thing and get back something completely unhinged. I yelled at my screen more than once. My kids probably learned a few new words.

But slowly, it clicked.

I stopped "using AI" and started thinking with it. I learned how to talk to it. How to break a big mess into small pieces. How to set things up so it handled the boring parts while I made the real calls. It went from a toy to a power tool.

The comeback

Then I landed a new job.

This time at a company that actually trusts me. They let me bring my whole AI-first workflow to the team. And bringing it to real people, on a real product? Night and day.

I'm building things now I couldn't have touched two years ago. Like an AI that answers the phone and talks to customers like a real person. The kind of project that used to need a whole team and six months. I'm doing it almost solo, in days.

And here's the part I didn't expect.

I love my job again.

I'm not fighting with syntax. I'm not frozen in front of a blank file, slowly dying inside. I get to think about the fun stuff: what to build, why it matters, how to make it actually good. The boring parts mostly take care of themselves.

I feel like a developer again. Maybe more than ever.

Oh, and the welding?

I wasn't totally joking about that part.

I got myself a full welding kit for my birthday last year. Mask, inverter, electrodes, the works. Turns out the dream didn't die — it just turned into a weekend hobby instead of an escape plan.

So now I build software all week and melt metal in the garage on the weekend. Best of both worlds. My code compiles, and so do my welds. (Most of the time.)

Your turn

So that's my story. I went from googling welding schools to feeling more excited about code than I have in years. All because I stopped fighting the wave and learned to surf it.

I can't be the only one.

If you've been doing this for 10+ years and hit that same wall — the "I'm done, I'm going to go work with my hands" wall — I want to hear it. Did you find your way back? Or are you still eyeing the welding catalog?

Drop your story below.