DEV Community: Evan Lausier

The Estimate That Became a Quote

Evan Lausier — Mon, 08 Jun 2026 18:46:56 +0000

I said "maybe a couple days" on a call last Tuesday. By Wednesday morning it was in a Jira ticket as "2 days." By Thursday afternoon somebody was checking in to see if we were tracking against the two day commitment.

Nobody did anything wrong. The person who wrote it down was capturing what I said. The person checking in was doing their job. I was the one who said the words. The system worked exactly as designed. The system is the problem.

Something Ive learned is that theres no such thing as a rough number in meetings today with all of the AI note takers... The moment you say a number out loud, it stops being a feeling and starts being a quote. The hedge in front of it doesnt survive the transcription. "Maybe" disappears. "Couple" gets rounded to a specific integer. "Give or take" is the first thing that hits the cutting room floor. What lands in the document is the number, naked, with no caveats and no error bars.

Everyone in the meeting heard what you heard. They heard the hedge. They watched you wave your hands. They understood, in the moment, that you werent committing. But the document doesnt remember any of that. The document just remembers the number. And the document outlives the conversation, which is where all the nuance lived.

Ive watched myself do this for years and I still get caught by it. Someone asks how long something will take. I want to be helpful. I want to seem confident. I want to keep the meeting moving. So I say a number. The number is approximately right, or at least I think it is, but I havent actually thought about it the way you would think about it if you were going to commit to it. By saying it out loud, Ive committed to it.

The fix, if theres one, is to refuse the number. Not rudely. Just clearly. "I need to look at it before I give you a real number. I can have one for you by Friday." This works about half the time. The other half, somebody in the room is going to ask you for a ballpark anyway, and youre going to give them one, and that ballpark is going to be in a slide deck by lunch.

I dont know how to stop doing it. Im writing this mostly so the next time it happens, I have something to point at.

Every Tool Eventually Becomes Tuesday

Evan Lausier — Mon, 25 May 2026 12:25:10 +0000

I opened my email this morning and there were three product announcements from companies I have never heard of. Each one was going to change how I work. Each one had a logo I will not remember by Friday. I closed the tab and made more coffee.

That used to be unusual for me. For years I read every announcement. I clicked through every demo. I built side project after side project just to keep up with whatever wave was supposedly cresting. Now I just feel tired.

If you're feeling the same thing, Id like to suggest that you are not broken. You are just on schedule.

I've been in this industry long enough to have watched a few waves come through. RPA was going to eliminate back office work. Low code was going to make every business analyst a developer. Blockchain was going to remake supply chains. AI copilots were going to ten x our productivity. Agents are now going to replace whole roles. Some of these were real shifts. Some were not. All of them arrived with the same breathless tone, the same conference circuit, the same blog posts about how everything was about to change.

Something Ive learned is that every tool that survives eventually becomes Tuesday. It stops being the future and starts being part of the floor you walk on. Nobody writes a blog post about npm install anymore. And Im pretty positive no one is getting excited about Jira. Git is just there. The wave that felt like it was going to drown you is now the puddle you step over without thinking. That is what success looks like for a tool. Boring infrastructure that you stop noticing.

Which means the exhaustion you are feeling is not really about the tools. Its about the gap between the volume of the announcements and the actual rate at which any of this becomes useful... The announcements come in daily. The integration into your job comes in months or years. Your brain is being asked to pay attention at the speed of marketing and adopt at the speed of reality, and those two speeds do not match.

So Ive given myself permission to stop trying. I let the announcements pile up. I look at the ones my team is actually using. I learn the tool when it shows up in a real ticket, not when it shows up in a launch post. The waves will keep coming. Some of them will become Tuesday. Most of them will not. I will be here either way, drinking coffee, ignoring the email.

I Document Like a Professional at Work. My Side Projects Are a Disaster.

Evan Lausier — Sat, 25 Apr 2026 14:24:19 +0000

It feels like documentation at work is more of a checking the box exercise sometimes. My own side development projects brought a lot to light.

I write business requirements documents. I write functional specs. I write process flows, configuration workbooks, user guides, and the occasional runbook that lives on a shared drive forever. None of it because I love writing documentation. I do it because there is a project manager waiting on a sign off, a client who will not accept go live until the deliverable is in their hands, and an auditor somewhere who might eventually pull a thread.

So I check the box. The BRD gets written. The functional and technical designs get reviewed. The process flow gets diagrammed in whatever tool the client has standardized on this quarter. Then it goes into a SharePoint folder and, if I am being honest, half of it never gets opened again.

I told myself for a long time that this was the nature of the work. Documentation is overhead. A tax. Something that exists to satisfy people who are not actually doing the building.
Then I got a little too deep in building a side project on my own time.

The README says "wip lol." The .env file has variables called OPS and OURA_THING.

There is a folder on my desktop named "projects_old" that I cannot describe the contents of without going in there. I will not be going in there.

Same person who, two days ago, delivered a configuration workbook to a client.

I never thought much about the gap until I started building MCP servers.

Where the chaos meets the wall

For anyone who has not played with this yet, the Model Context Protocol is a way to expose tools, resources, and prompts to an LLM in a structured format. You write a server, you define your tools, you give each one a description, and the model uses those descriptions to figure out what your tool does and when to call it.
The description is not a comment. It is the interface.

It is, weirdly, the closest thing personal projects have to a functional spec. If your tool is named get_data and its description is "gets data," the LLM is not going to know what to do with it. It will not call it. Or worse, it will call it at the wrong time for the wrong reason. The model needs to understand your tool the way a business analyst would understand a process step. Inputs, outputs, when it runs, what it depends on, what it does not handle.

I sat down to build a small MCP server for a personal experiment. Nothing serious. A few tools wrapped around a service I use for fun.

And I could not write the descriptions.

Not because I did not know what the tools did. I built them. I knew exactly what they did. I had just spent so many years writing personal projects for an audience of one that I had lost the muscle of describing anything to an outside reader. Every description I wrote either assumed too much or said nothing. The first draft of one of my tool descriptions was something close to "fetches the thing."

If a junior consultant on my team turned in a technical spec that read like that, I would send it back.

What the box checking was actually doing

Here is the part that took me a while to admit. The BRDs, the functional specs, the process flows, the workbooks I half resented while writing them. They were not just there to satisfy a project manager. They were forcing me to think about my work the way an outside reader would. What does this do. Why does it exist. When does it run. What happens when something goes wrong. Who needs to understand it.

I was doing that work every time, even while I was complaining about doing it.

At home, with nobody making me, I never did it. I built things and assumed I would remember. I did not. The MCP server forced me back into the same questions I answer every day at work, except this time there was no project manager. Just a model that needed to understand my tool well enough to call it correctly.
What I am actually doing about it

Probably not enough. I have started writing tool descriptions before I write the tool itself, which is a small but meaningful shift. It is the personal project equivalent of writing requirements before you build. If I cannot describe what the thing does in one clear sentence, the thing is not ready to be built. That alone has caught a few half formed ideas before they became half built code.

Turns out the box was doing more work than I gave it credit for.

Why Build a Local MCP Server (And How to Do It in 15 Minutes)

Evan Lausier — Tue, 14 Apr 2026 20:05:57 +0000

I've been working with MCP servers for a few months now. If you're not familiar, MCP (Model Context Protocol) is Anthropic's open standard for connecting AI models to external tools and data sources. Think of it as the API layer between an LLM and the stuff it can actually do.

There are already a bunch of prebuilt MCP servers out there. Ones that connect to GitHub, Slack, Google Drive, databases, you name it. You can plug them into Claude Desktop or VS Code and start using them immediately. So the obvious question is why would you build your own?

Here's why. Because the prebuilt ones solve general problems. Your problems are specific.

Maybe you have a local SQLite database with project data and you want Claude to query it conversationally. Maybe you have a folder full of markdown files that represent your team's internal documentation and you want an AI that can actually search them. Maybe you have a custom API at work that nobody outside your company will ever build an integration for.

That's the gap. MCP lets you fill it yourself. And the local version is the fastest way to get something running without deploying anything, paying for anything, or asking anyone for permission.

What You Need
Python 3.10 or higher and the fastmcp library. That's it.

shell pip install fastmcp

If you prefer TypeScript, there's an official MCP SDK for that too, but Python is the faster path for a first server.

The Simplest Possible Server
Here's a working MCP server in about 10 lines. This one exposes a single tool that searches through local text files in a directory.

from fastmcp import FastMCP
from pathlib import Path

mcp = FastMCP("Local Notes Search")

NOTES_DIR = Path.home() / "notes"

@mcp.tool()
def search_notes(query: str) -> str:
    """Search through local notes files for a keyword."""
    results = []
    for f in NOTES_DIR.glob("*.md"):
        content = f.read_text()
        if query.lower() in content.lower():
            results.append(f"**{f.name}**\n{content[:200]}")
    if not results:
        return f"No notes found matching '{query}'"
    return "\n\n".join(results)

That's a complete MCP server. One file. One tool. When connected to Claude Desktop, you can say "search my notes for anything about project deadlines" and it will actually read your local files and respond.

Connecting It to Claude Desktop

Open your Claude Desktop config file.
On Mac:

plaintext ~/Library/Application Support/Claude/claude_desktop_config.json

On Windows:

plaintext %APPDATA%\Claude\claude_desktop_config.json

Add your server to the config:

{
  "mcpServers": {
    "local-notes": {
      "command": "python",
      "args": ["/path/to/your/server.py"]
    }
  }
}

Restart Claude Desktop. Your tool should show up in the tools menu. That's it.

Making It More Useful
Once you've got the pattern down, you can add more tools to the same server. Here's what a slightly more practical version looks like with a few tools on one server.

from fastmcp import FastMCP
from pathlib import Path
import json

mcp = FastMCP("My Local Tools")

NOTES_DIR = Path.home() / "notes"
DATA_DIR = Path.home() / "data"

@mcp.tool()
def search_notes(query: str) -> str:
    """Search local markdown notes for a keyword."""
    results = []
    for f in NOTES_DIR.glob("*.md"):
        content = f.read_text()
        if query.lower() in content.lower():
            results.append(f"{f.name}: {content[:150]}")
    return "\n".join(results) if results else "No matches found."

@mcp.tool()
def list_notes() -> str:
    """List all available notes."""
    files = sorted(NOTES_DIR.glob("*.md"))
    return "\n".join(f.name for f in files) if files else "No notes found."

@mcp.tool()
def read_note(filename: str) -> str:
    """Read the full content of a specific note."""
    path = NOTES_DIR / filename
    if not path.exists():
        return f"File {filename} not found."
    return path.read_text()

@mcp.tool()
def query_json_data(filename: str, key: str) -> str:
    """Look up a key in a local JSON data file."""
    path = DATA_DIR / filename
    if not path.exists():
        return f"File {filename} not found."
    data = json.loads(path.read_text())
    if key in data:
        return json.dumps(data[key], indent=2)
    return f"Key '{key}' not found in {filename}."

Four tools, one file, no deployment. You can ask Claude to search your notes, read a specific file, or pull data from local JSON files. Everything runs on your machine. Nothing leaves your network.

When to Go Local vs. Remote
Local MCP servers make sense when you're working with files on your machine, querying local databases, prototyping a tool before deploying it, or connecting to internal APIs that are only accessible from your network.

If you need the server to be available across devices, shared with a team, or triggered by other services, that's when you look at hosting it remotely. But for personal productivity and experimentation, local is the move.

The Bigger Picture
The reason MCP matters isn't the protocol itself. It's that it turns AI from a thing you type questions into to a thing that can actually interact with your environment. Every local tool you expose is one less copy and paste cycle between your terminal and your chat window.

Start with one tool. Make it solve one problem you actually have. You'll find the second and third ones pretty quickly after that.

FUNN

Evan Lausier — Sun, 12 Apr 2026 03:38:20 +0000

April Fools Challenge Submission ☕️🤡

FrancisTRᴅᴇᴠ (っ◔◡◔)っ

Apr 7

Forem (Dev.to) is slow, so I del...optimized it.

#showdev #devchallenge #418challenge #discuss

5 min read

Congrats!

Evan Lausier — Sat, 11 Apr 2026 11:55:12 +0000

Beaver-powered databases and ancient AI

Jess Lee for The DEV Team

Apr 6

Oracle, AI, and Who Actually Pays for the Race

Evan Lausier — Sat, 04 Apr 2026 23:40:25 +0000

At some point in the last six months or so, we quietly stopped arguing about whether AI was real ot just the next tech bubble waiting to pop.

That shift matters more than most people realize. Not because the debate was resolved cleanly. It wasn’t. The hype merchants are still out there, still pitching dashboards and slide decks to executives who want to look smart at board meetings. The valuations are still stretched in places. The AI wrapper startups are still going to die by the hundreds.

But the underlying technology…. That part stopped being a question. We can debate the semantics around it, but it different forms of it are likely to be around for a while.

And now we are finding out what happens when tens of thousands of people wake up to the answer.

On March 31st, somewhere around 30,000 Oracle employees started their day the same way. An email arrived at 6 a.m., signed not by anyone they knew, not by a manager, not even by an executive with a name attached to it, but by something called “Oracle Leadership.” By the time most of them finished reading it, their system access was already gone. Their unvested stock was already forfeited. Their careers at one of the largest enterprise software companies in the world were already over.

This happened, by the way, in the same quarter Oracle posted a 95% jump in net income. $6.13 billion in profit.

I want to sit with that for a second… because it sounds so strange when you say it outloud…

Oracle is not the exception here. It is the clearest example of a pattern playing out in plain sight across the entire tech industry. The global tech sector has eliminated nearly 60,000 jobs in the first three months of 2026. That works out to roughly 700 jobs gone every single day. Amazon fired 16,000 people after posting record revenue of $716 billion in 2025. Meta is cutting up to 15,000 workers while simultaneously doubling its AI capital expenditure to $135 billion. Block, Jack Dorsey’s company, cut 40% of its entire workforce and framed it as a competitive necessity.

The companies doing the cutting are not struggling. They are thriving. They just need cash.

Specifically, they need cash for data centers.

Here is the uncomfortable part. The people losing their jobs right now cannot really console themselves with the idea that this is all going to blow over.

For the past couple of years, there has been a comforting narrative available. The bubble will burst. The dot-com comparison will hold. The breathless valuations will correct, the vaporware startups will vanish, and things will return to something recognizable. That narrative still has some truth in it. The hype bubble will deflate. The me-too AI companies with no moat and no margin will disappear. Stock prices will correct in places.

But the technology itself is not going anywhere.

The distinction matters and it is getting lost in the noise. The dot-com crash was built on ideas running on air. Pets.com. Webvan. Companies that were essentially PowerPoint presentations with server rooms attached. Today’s AI infrastructure buildout is different in kind. Oracle currently sits on $523 billion in remaining performance obligations, up 433% year over year. The contracts are real. The data centers being built are physical, steel-and-concrete, take-years-to-construct infrastructure. The demand is real. The technology works.

That is exactly why the layoffs are happening. Not despite AI succeeding. Because of it.

When a company like Oracle commits to $156 billion in AI capital spending, it has to find that money somewhere. According to analysis from TD Cowen, the layoffs free up somewhere between $8 billion and $10 billion in annual cash flow. In other words, the salaries, benefits, and unvested equity of 30,000 people are the down payment on the data centers Oracle needs to stay competitive in a race it cannot afford to lose.

I spent years working inside enterprise software. I know what the teams at a company like Oracle actually build and how long it takes to develop the institutional knowledge that makes a product work for the businesses depending on it. The people who just got that 6 a.m. email were not passengers. They were the product.

And the AI race ate them.

The hardest-hit divisions were Revenue and Health Sciences, SaaS operations, and the NetSuite India Development Centre. That last one matters to me specifically. NetSuite is the product that tens of thousands of mid-market businesses run their entire operations on. The people building it, supporting it, and extending it are not interchangeable. You cannot fire a development centre and replace it with a GPU cluster and get the same outcome. Not yet anyway.

But Oracle is making a bet that the math works out. That building the infrastructure to power the next decade of AI contracts is worth more than preserving the teams that built the last decade of enterprise software. Maybe they are right. Maybe the contract backlog and the data center revenue prove it out over the next few years.

The people who got that email at 6 a.m. will not be around to find out.

I am not arguing that AI is bad, or that the race should stop, or that any of this was avoidable given the competitive dynamics at play. I genuinely believe the technology is going to matter in ways we are still figuring out how to articulate. I use it every day. It is already embedded in how I work.

But I think we owe it to ourselves to be honest about what the cost actually looks like.

The question was never really whether AI would arrive. It was always who would pay for it.

Right now the answer is turning out to be the same people it usually is. The ones who built the thing in the first place.

A race this expensive has to be funded by someone. We just found out who.

Source:

Really Fun!

Evan Lausier — Fri, 03 Apr 2026 10:26:33 +0000

Top scores will feature in a monthly report

FrancisTRᴅᴇᴠ (っ◔◡◔)っ

Mar 30

What is your WPM (Words per Minute)? #1

#discuss #watercooler #challenge #community

1 min read

Very Helpful!

Evan Lausier — Sun, 29 Mar 2026 12:00:19 +0000

Mark

Mar 27

How to Talk to Managers (So They Actually Listen to You)

#career #beginners #productivity #programming

6 min read

Great Read! Very Relatable!

Evan Lausier — Sat, 28 Mar 2026 13:49:21 +0000

The irony of ignoring our own advice

Sylwia Laskowska

Mar 26

How I Almost Burned Out Doing Everything “Right”

#discuss #career #productivity #mentalhealth

191

112

6 min read

What is MCP?

Evan Lausier — Sat, 21 Mar 2026 21:40:33 +0000

If you've been anywhere near developer Twitter or LinkedIn lately, you've probably seen this diagram floating around. Credit to Alex Xu at ByteByteGo for putting it together so cleanly. It stopped me mid-scroll because it finally gave a clear visual to something I had been reading about in pieces.

MCP, or Model Context Protocol, is an open standard from Anthropic that gives AI models a structured way to connect to external tools, data sources, and services. Think of it as a universal adapter layer between the model and the rest of your stack. Instead of writing one-off integrations every time you want Claude to touch a database or call an API, MCP gives you a consistent protocol to build against.

The diagram breaks it down into two layers worth understanding. The top half shows the host architecture, where an MCP host like Claude Desktop or an IDE runs multiple MCP clients, each speaking to a dedicated MCP server that fronts a specific resource. The bottom half gets into the core building blocks, which are the five primitives the whole thing runs on.

Nobody Is Reading Your Blog Post. They Weren't Going To Read Mine Either.

Evan Lausier — Fri, 06 Mar 2026 19:16:10 +0000

I was building a slide deck last week... technical content, thoughtful structure, a solid wall of text I was genuinely proud of. Somewhere around slide four I had a moment of uncomfortable clarity.

Nobody is reading this.

Not because it's bad. Because nobody reads anything anymore. And AI-generated content isn't causing that. It's just proving it.

The Research Was Telling Us This for Decades

Back in 1997, Jakob Nielsen and the Nielsen Norman Group published eye-tracking research showing that users read roughly 20–28% of words on a typical webpage. They scan in an F-pattern: a horizontal sweep across the top, a shorter sweep a bit further down, then a vertical skim down the left edge. That's it.

The research has been replicated and updated many times since. The pattern holds.

Then in 2014, Tony Haile at Chartbeat — analyzing data across billions of page views — reported that 55% of visitors spent fewer than 15 seconds on a page. Scroll depth data from the same era consistently showed most readers never made it past the midpoint of an article.

So let's be precise about what AI-generated content actually revealed: the bar for "good enough to publish" was always lower than we wanted to admit, because the bar for "read carefully" was already underground.

Your README Is Unread. Your Docs Are Unread. Your Blog Post Was Unread.

If you've been writing technical content for any meaningful stretch of time, you've felt this. The PR where you wrote a detailed description that someone clearly didn't read before commenting. The documentation page that generates the same support ticket every week. The README with a Prerequisites section that people routinely skip until something breaks.

This isn't a character flaw in your users. It's a behavior pattern baked in by information overload. We all do it. I do it. You do it.

We skim for the thing that matches our immediate problem. We ctrl+F. We scroll until something catches our eye. We open five tabs and read none of them completely.

AI content farms figured this out before most publishers did, which is why they're effective at scale. They're not fooling careful readers. There aren't enough careful readers to matter for their metrics.

So What Actually Works

None of this means writing is pointless. It means the format has to do work that the reader won't.

Front-load everything. TL;DRs, key takeaways at the top, summary sections before the detail. If the most important sentence is in paragraph six, it will be missed by most people.

Headers are navigation, not decoration. Someone scanning your post is making micro-decisions at every header: is this the part I need? Write headers that answer that question directly.

Short paragraphs aren't just stylistic. White space gives the eye a place to land. Walls of text read as "skip this block" to a scanner.

Code blocks are a rest stop. For a technical audience, a well-formatted code snippet is often more read than the paragraphs around it. Use them strategically.

The first and last sentence of every section carries disproportionate weight. That's where scanners pay attention. Write accordingly.

The Uncomfortable Part

Here's what I keep coming back to: the AI content problem isn't really an AI problem.

It's a publishing-into-a-vacuum problem that we've been doing for years and only now have a mirror for. When a GPT-generated article with thin sourcing and a generic structure outperforms a carefully researched post, that's not AI winning. That's formatting, SEO, and headline copy winning — the same things that were always winning.

The slide deck I was building? I'm still going to make it. But I rebuilt it with one idea per slide, tight headlines, and the details pushed to speaker notes where they belong.

The audience was always skimming. The only new thing is that I stopped pretending otherwise.

Has your approach to technical writing or documentation changed as you've gotten more honest about reading behavior? I'm curious what's actually worked — drop it in the comments.