I don't develop on a powerful machine.

My main development laptop has 4 GB of RAM, limited graphics memory, and just enough storage to make me think twice before installing another tool I probably don't need.

It's not the kind of machine you'd look at and think, "perfect development environment."

But I've spent a lot of time building software on it.

And it taught me something I probably wouldn't have learned from a much more powerful machine:

Hardware constraints make software impossible to ignore.

When you have plenty of resources, inefficient software can hide behind them.

When you don't, it introduces itself immediately.

Powerful Hardware Can Hide Bad Decisions

This is probably the biggest lesson.

If an application consumes an extra 500 MB of memory on a machine with 32 GB, you might never notice.

On a machine with 4 GB, you definitely will.

The underlying software hasn't changed.

Only the amount of room available to hide its inefficiencies has changed.

That made me appreciate something simple:

Performance isn't just a benchmark number.

It's also about how much unnecessary work your software does.

How much memory it holds.

How many processes it starts.

How much it keeps running in the background.

How much data it moves around.

How many dependencies it needs before it can do something useful.

I Started Caring About Lightweight Tools

This changed the tools I choose.

I started preferring software that does one thing well without bringing an entire ecosystem with it.

Command-line tools became more attractive.

Simple utilities became more attractive.

SQLite became more attractive.

Local scripts became more attractive.

I started paying attention to applications that didn't need a dozen background processes just to open a window.

This isn't an argument that everyone should abandon modern tools.

Sometimes a heavier tool is absolutely worth the resources it uses.

The point is knowing that the resources are being spent.

Linux Made This More Obvious

Using Linux made this even more interesting.

The system exposes a lot more of what's happening underneath.

Processes.

Memory.

CPU usage.

Disk usage.

Services.

Logs.

Network connections.

You can inspect things instead of treating the operating system as a sealed box.

That changed the way I think about my development environment.

If something is slow, I want to know why.

If something is consuming memory, I want to know what it is doing.

If something is running in the background, I want to know whether I actually need it.

The machine became part of the development process rather than something I simply use to run an editor.

Constraints Change Architecture

Hardware limitations don't only affect which applications you install.

They can influence how you build software.

Running everything locally isn't always the best choice.

A local database might be perfectly reasonable.

A local API might be fine.

But running several containers, a database, a local model, a frontend development server, and multiple supporting services simultaneously can turn a small laptop into a space heater with a keyboard.

Sometimes the better architecture is:

Local development → lightweight services → expensive workloads elsewhere

That might mean using an API instead of running a large model locally.

Or using SQLite instead of running a database server when a server isn't necessary.

Or shutting down services when they're not being used.

The goal isn't to avoid complexity at all costs.

It's to make complexity intentional.

I Started Looking at Dependencies Differently

Dependencies are easy to accumulate.

You need something.

You install a package.

Then another.

Then another package pulls in five more.

Eventually your project works, but you don't really know how much machinery is underneath it.

Limited hardware makes that uncomfortable.

It encourages a different question:

Do I actually need this?

Sometimes the answer is yes.

Sometimes the answer is:

I could write this myself in twenty lines.

And sometimes the answer is:

This dependency is absolutely worth it.

All three are valid.

The important part is making the decision consciously.

Small Tools Started Feeling More Valuable

One of the reasons I enjoy building developer tools is probably connected to this.

A small CLI can sometimes solve a problem without requiring an entire application around it.

You run a command.

It does the work.

It prints the result.

You move on.

That's part of why I built Machine, a Linux diagnostics CLI.

The project started from a simple idea: I wanted a practical way to inspect my system without manually digging through different commands and files.

It eventually became more than that, with structured output, verbose modes, and snapshots.

But the basic philosophy stayed the same:

Give me the information I need without making me fight the tool.

Resource Constraints Also Improve Debugging

There is another unexpected benefit.

When resources are limited, problems become easier to notice.

A process leaking memory doesn't quietly disappear into 64 GB of RAM.

A build that suddenly becomes expensive is obvious.

A background service consuming CPU gets noticed.

A badly designed application can make the entire machine feel worse.

That feedback loop is valuable.

It forces you to investigate.

You learn to look at processes.

You learn to inspect logs.

You learn what swap actually does.

You learn the difference between something being slow and something simply waiting on I/O.

You learn that "the computer is slow" isn't a useful diagnosis.

Something is causing it.

Find the something.

It Changed How I Think About Optimization

I used to think of optimization as something you do after the software works.

Now I think there is a difference between optimization and awareness.

You don't need to prematurely optimize every function.

You do need to understand what your software costs.

There is a big difference between:

Make everything as fast as possible.

and:

Don't waste resources for no reason.

The second one is much more practical.

Constraints Are Also a Design Tool

This is probably the most useful lesson I've taken from working with old hardware.

Constraints aren't always just obstacles.

They can be design feedback.

If your application only works comfortably on a machine with huge amounts of RAM, maybe that's completely justified.

Or maybe you've accidentally built something much heavier than it needs to be.

If your development environment requires ten services just to start the project, maybe that's necessary.

Or maybe there's a simpler architecture hiding underneath.

The constraint doesn't tell you which answer is correct.

It makes you ask the question.

I Still Want a Better Laptop

This isn't a heroic story about embracing suffering and never upgrading.

I would absolutely enjoy having more RAM.

I'd like faster builds.

I'd like to run more things simultaneously.

I'd like to experiment with larger local models without watching memory disappear in real time.

Having better hardware is useful.

But I also don't want to forget what the limited hardware taught me.

Because once you develop on a machine where every resource matters, you start noticing things.

You notice unnecessary processes.

You notice bloated applications.

You notice dependencies.

You notice architecture.

You notice what your software is actually doing.

And that awareness follows you even when the hardware gets better.

The Machine Is Part of the Software

I think that's the biggest thing I took away.

Software doesn't exist in isolation.

It runs somewhere.

On a CPU.

Using memory.

Reading from storage.

Talking over a network.

Competing with other processes.

Waiting for hardware.

Those details are easy to ignore when everything feels instantaneous.

They're much harder to ignore when your machine makes you wait.

And maybe that's useful.

Because good software isn't just software that works.

It's software that understands the environment it has to work in.

Building on old hardware didn't make me a better programmer by magically teaching me some secret optimization technique.

It made me pay attention.

And sometimes, paying attention is where good engineering starts.

More files. More conversation history. More documentation. More retrieved chunks. More memory.

It feels logical.

If the model doesn't know enough, give it more information.

But there is a point where more context stops helping and starts getting in the way.

The problem isn't always that an agent knows too little.

Sometimes it knows too much at once.

Context Isn't Memory

It's easy to treat an LLM's context window like a memory system.

It isn't.

Context is information the model can currently see while generating a response. Memory is information that has been deliberately stored, organized, retrieved, and used when it becomes relevant.

That distinction matters.

Imagine an agent working on a codebase.

It could be given:

• the current task
• the entire conversation
• every previous decision
• all relevant files
• old implementation details
• every tool result
• every error it has encountered
• documentation for the entire project

Technically, the agent has more information.

But that doesn't necessarily mean it has a better understanding of the task.

It now has to figure out what matters.

And that is another problem you just gave it.

More Context Creates More Noise

Suppose an agent is fixing a bug in an authentication flow.

You retrieve ten files.

Only three actually matter.

The other seven contain related concepts, old implementations, helper functions, comments, or configuration that happens to mention authentication.

Nothing is necessarily wrong with those files.

They're just not relevant enough.

Now the model has to process all of them while trying to identify the small amount of information that actually matters.

This creates a retrieval problem before you even reach the reasoning problem.

A useful mental model is:

Too little context
       ↓
The agent doesn't know enough

Useful context
       ↓
The agent has what it needs

Too much context
       ↓
The agent has to search through what it needs

The third case is surprisingly easy to create.

The Context Window Is Not a Free Database

A larger context window makes this easier to do, because there is more room to put information into the prompt.

But more capacity doesn't mean every piece of information should be included.

Think about a database query.

You wouldn't normally fetch every row from every table and hand the entire database to your application just because the database can handle it.

You query for what you need.

The same principle applies to agent context.

The goal shouldn't be:

Put everything relevant into the context.

It should be:

Put the right information into the context at the right time.

That sounds like a small distinction.

It isn't.

Old Information Can Be Worse Than Missing Information

This becomes even more important when agents have memory.

Imagine an agent remembers:

The project uses PostgreSQL.

Six months later, the project has moved to SQLite.

If the old memory is still being retrieved because it appears relevant, the agent now has conflicting information.

It may see:

Current configuration:
SQLite

Previous observation:
PostgreSQL

Now the model has to decide which one is correct.

You have turned memory into another reasoning problem.

This is why storing information isn't enough.

A useful memory system also needs things like:

• relevance
• recency
• confidence
• relationships
• source
• verification
• lifecycle

Otherwise, memory slowly becomes a junk drawer.

And junk drawers are technically full of useful things.

Finding the useful thing is the problem.

Conversation History Has the Same Problem

Long conversations can create another form of context overload.

An agent might have hundreds of messages describing:

• previous approaches
• abandoned ideas
• temporary decisions
• failed experiments
• corrected assumptions
• unrelated questions
• implementation details

Passing all of that into every new request sounds convenient.

But not every historical statement should have equal importance.

A decision made twenty messages ago might still matter.

A failed experiment from yesterday might be irrelevant.

A temporary workaround from an hour ago might actively confuse the agent if the underlying issue has already been fixed.

History is not automatically memory.

It is just history.

Retrieval Quality Matters More Than Retrieval Quantity

This is one of the biggest lessons I've noticed while working with RAG systems.

It's tempting to measure retrieval by how much information you managed to retrieve.

But retrieving twenty chunks isn't inherently better than retrieving five.

If those five contain the answer and the other fifteen are noise, the smaller context can be better.

A simple retrieval pipeline might look like:

User Query
    ↓
Retrieve documents
    ↓
Rank results
    ↓
Select useful context
    ↓
Build prompt
    ↓
LLM

The important part is the middle.

Retrieval shouldn't end at:

Here are some documents that look similar.

It should eventually answer:

Which of these documents are actually useful for this task?

That's where techniques like hybrid search, filtering, reranking, metadata, and relevance thresholds become important.

Context Should Have a Budget

I think it helps to treat context like a resource.

You have a limited amount of attention available.

So instead of asking:

How much context can I fit?

Ask:

What deserves to occupy the context?

For an AI coding agent, that might mean prioritizing:

Current task
    ↓
Relevant files
    ↓
Recent decisions
    ↓
Verified project knowledge
    ↓
Relevant tool results
    ↓
Everything else

Not every piece of information deserves equal priority.

Some information is critical.

Some is useful.

Some is outdated.

Some is noise.

Some is actively dangerous because it looks authoritative while being wrong.

A good context pipeline should know the difference.

This Is Where Memory and Context Start to Separate

This is also why I've become interested in memory layers for AI software engineering.

An agent shouldn't have to carry its entire history around forever.

Instead, information can exist outside the active context and be retrieved when needed.

Conceptually:

                 ┌──────────────┐
                 │   Memory     │
                 │              │
                 │ decisions    │
                 │ observations │
                 │ relationships│
                 │ snapshots    │
                 └──────┬───────┘
                        │
                     retrieve
                        ↓
User Task ─────────→ Relevant Context
                        │
                        ↓
                      Agent

The context becomes a working set rather than a warehouse.

That distinction is important.

A warehouse stores everything.

A working set contains what you currently need.

Bigger Context Windows Don't Solve This

Longer context windows are useful.

They allow agents to work with larger codebases, longer conversations, and more complicated tasks.

But increasing the capacity doesn't automatically solve information selection.

If anything, it can make bad context design easier to hide.

You can keep adding information because the system still technically fits inside the window.

The failure becomes less obvious.

Instead of hitting a hard limit, you get an agent that technically has everything it needs but somehow keeps missing the important part.

That's a much more interesting problem.

The Goal Isn't Less Context

I don't think the answer is to give agents tiny prompts and pretend context isn't important.

Agents need context.

Good context is one of the things that makes them useful.

The goal is better context.

That means:

• retrieve information instead of dumping everything
• prefer recent and verified information
• remove stale observations
• rank retrieved results
• separate memory from active context
• preserve important decisions
• avoid carrying irrelevant conversation history
• give tools only the information they need
• treat context as a resource

The best agent isn't necessarily the one that knows the most.

It's the one that can bring the right knowledge into the room when it matters.

Context Engineering Is Really Information Engineering

This is probably the bigger lesson for me.

Building AI systems isn't only about choosing a better model.

A model can be extremely capable and still perform badly if the information around it is poorly managed.

You need to think about:

What should be stored?
What should be retrieved?
What should be ignored?
What should be trusted?
What should expire?
What should be verified?
What should actually reach the model?

Those are software engineering questions as much as they are AI questions.

And as agents become capable of working across larger codebases and longer-running tasks, I think this becomes increasingly important.

The interesting problem isn't just giving agents more information.

It's building systems that help them know which information matters.

Final thought

There is a strange irony in building systems that are supposed to help AI remember.

The obvious solution is to remember everything.

But useful memory has never really worked that way.

Humans don't need to consciously carry every conversation, every mistake, and every piece of information they've ever encountered.

We remember selectively.

We forget.

We prioritize.

We retrieve.

We update what we know.

AI agents need similar mechanisms if they're going to operate reliably over long periods of time.

So maybe the future of agent context isn't:

more context.

Maybe it's better context.