DEV Community: Jackfiallos

I Don’t Think I’m Losing My Memory. I Think I’m Trying to Think at AI Speed.

Jackfiallos — Wed, 02 Sep 2026 11:10:27 +0000

Something strange has been happening lately, I keep forgetting small things.

Not names.
Not conversations.
Not important events.
Small pieces of routines.

Things I’ve done almost automatically for years, for example:

Every night I usually prepare everything I need for the gym the next morning.

Clothes.
Shoes.
Supplements.

Nothing complicated, but lately I’ll prepare the clothes... and forget the shoes. Or prepare everything except the supplements.

Small things, but frequent enough that I started noticing. And then I started seeing the same pattern at work.

I lose the thread

I might have three or four coding agents running at the same time.

One is fixing a bug.
Another is exploring a ticket.
Another is refactoring something.
Another is working in a different application entirely.

While Agent A works, I move to B, while B is thinking, I review C, then A finishes, so I go back to A.

And suddenly:

What was I doing before this?

Sometimes I need a minute, I open the previous ticket, read a few lines. look at the code and then the entire context comes back.

That’s when I started wondering:

Maybe this isn’t a memory problem.

Maybe I’m just constantly dropping context.

Developers already understand this problem

We talk about context all the time. processes have context, requests have context, applications have state, LLMs have context windows.

And humans do too.

When I’m working on a bug, my brain is temporarily holding things like:

what I’m trying to fix
what I already tested
what failed
what I suspect
what file matters
what another service is doing
what I need to check next

That information may never reach long-term memory, It doesn’t need to. It only needs to stay available long enough for me to finish the task.

That is working memory and working memory is not infinite.

AI changed something important

For most of my career, software development had friction.

You wrote code, you compiled, you waited, you ran tests, you searched documentation, you read Stack Overflow, you tried something. It failed, you stared at the problem, then you tried again, there were pauses. Not necessarily intentional pauses, but pauses.

Now I can do this:

Task A -> Agent A working
Task B -> Agent B working
Task C -> Agent C working
Task D -> Agent D working

Amazing, four things moving at once, except eventually:

Agent A -> finished
Agent B -> needs clarification
Agent C -> changed 12 files
Agent D -> found another problem

And every single one of them comes back to the same place.

Me.

The agents are parallel. I’m not.

This sounds obvious, but I don’t think I fully understood what it meant. AI made execution parallel, it did not make my attention parallel.

Every result still needs a human, someone has to understand it, review it, question it, check the diff, understand the architecture, notice the weird assumption, decide what happens next.

AI reduced the cost of producing work, but it did not remove the cost of:

understanding
evaluating
integrating
deciding

And now there is simply more of that work arriving.

Faster.

Faster output means more decisions

This is where things get strange. Imagine a task used to take me 30 minutes. Now an agent gives me a decent first implementation in 3, I saved 27 minutes.

Great.

So what do I do with those 27 minutes?
I start another task of course - duh!

Then another, then another and suddenly my workflow looks like this:

prompt
switch
review
switch
approve
switch
debug
switch
ask follow-up
switch
read diff
switch
remember what I was doing

The machine got faster, so I made my day more concurrent, and eventually something interesting happens:

I am producing more while feeling less focused.

That feels like a contradiction, it probably isn’t.

Context switching has a cost

We already knew this before AI.

Slack did it.
Email did it.
Meetings did it.
Notifications did it.

But agents make something much easier:

starting more work.

Before AI, opening another task meant I had to actually work on another task, there was a natural cost. Now I can start another workstream with a prompt, thirty seconds later, something else is running in parallel.

The cost of starting work has collapsed, the cost of keeping that work inside my head has not. That changes everything.

Maybe I’m not forgetting

This is probably the part I find most interesting. When I return to something after ten minutes and think:

What was I doing?

the experience feels like forgetting, but then I look at the code.

Read the ticket.
See the previous message.

And suddenly:
Oh, right.

Everything comes back, the memory was probably not gone. The context was simply no longer active.

There’s a big difference between:

losing information and losing access to information because your attention moved somewhere else.

Subjectively, though, they can feel almost identical.

Both feel like:

I forgot.

And yes, life is also happening

I don’t think AI explains everything.

Not even close, stress matters, sleep matters, family matters. mental health matters, changes in routine matter.

Life can leave a lot of invisible processes running in the background.

In my own case, the last few months have contained enough personal stuff that cognitive load is probably already higher than normal.

So saying:

AI is doing this to me

would be lazy. I don’t know that, but I do think AI may be acting as an amplifier. It gives me the ability to create far more cognitive demand than I could create before.

And because that demand looks like productive work... it’s very easy not to recognize it as overload.

Productivity can hide overload

That’s probably what worries me most, overload doesn’t always feel like overload.

Sometimes it looks like this:

lots of commits
lots of tickets moving
lots of agents running
lots of answers
lots of progress

Everything appears productive, meanwhile:

attention becomes more fragmented, tasks become harder to reconstruct, small routines start losing pieces, you start rereading things, you switch windows and forget why, you finish the day having done a lot... but feeling strangely scattered.

That’s an interesting failure mode because the dashboard says productivity went up.

We removed almost all the waiting

For decades, engineering has tried to remove latency.

Faster builds.
Faster tests.
Faster computers.
Faster deployments.
Faster feedback.
Faster everything.

That was mostly a good thing, but I’ve started wondering whether some of that waiting had an accidental benefit.

Waiting for a build.
Walking to get coffee.
Reading documentation slowly.

Looking at a bug without immediately asking something else for the answer.

Sitting with a problem. Those moments looked inefficient, but perhaps they gave the brain time to stay inside one context.

AI is removing enormous amounts of friction, which is amazing. But the machine no longer forces us to slow down, maybe that means we need to do it ourselves.

More speed should not mean more concurrency

This is the adjustment I’m experimenting with.

I’m not trying to use less AI. I’m not going back to doing everything manually, that would miss the point.

Instead, I’m trying to separate two resources:

Machine throughput
!=
Human attention

An agent finishing something does not mean I must review it immediately. An agent waiting does not mean I must start another one. A task taking 3 minutes instead of 30 does not mean I need 10 tasks in flight.

The mental model I’m trying to adopt is:

AI works in parallel.

I work sequentially.

The agents can wait.
The output can wait.
The notification can wait.
My attention decides what runs next.

The funny thing is that most agent interfaces still behave like chat applications.

Something happens, they tell you. Another thing happens, they tell you again.

The result is basically:

Agent A -> INTERRUPT
Agent C -> INTERRUPT
Agent B -> INTERRUPT
Agent D -> INTERRUPT

Maybe that is the wrong model, maybe what I actually want is:

11:00 AM

Agent review queue

A: finished
B: blocked
C: needs one decision
D: still working

One review window, one context-switching event. Machines stay asynchronous and humans stay sane. That feels much closer to how agent systems should eventually work.

Developers may just be early

I suspect developers will encounter this problem earlier than most people, simply because coding agents already make extreme parallelism possible.

Today I can have agents:

writing code
debugging
reviewing pull requests
creating tests
researching libraries
exploring architecture
documenting systems

all at once.

Soon this won’t be unusual, and it won’t be limited to developers.

Managers will have agents, designers will have agents, researchers will have agents, founders will have agents, students will have agents. Knowledge work may become massively parallel, human cognition will not.

There is already a lot of discussion around cognitive offloading.

The concern is understandable.

If AI writes for us, remembers for us, searches for us, reasons for us... maybe we exercise certain cognitive abilities less, but there may be another problem hiding on the opposite side.

Not:

AI makes us think less.

But:

AI makes it possible for us to try thinking about too many things at once.

The chain might look something like this:

More AI
   ↓
More output
   ↓
More work in flight
   ↓
More decisions
   ↓
More context switching
   ↓
More fragmented attention

Maybe we’re not becoming forgetful, maybe we’re just overflowing our cognitive context window.

I don’t need to think at machine speed

This may sound obvious too, but I think many of us are unconsciously doing exactly that.

The AI answers faster, so we answer faster. The agent finishes faster, so we start something else faster. Research takes seconds, so we immediately consume more research.

Every efficiency gain creates another opportunity to do something.

And if every second AI saves becomes another task... we haven’t really created free time, we’ve increased throughput. Those are not the same thing.

The next AI bottleneck might be us

It’s still early, agents are new and most people are only starting to build AI deeply into their daily workflows. So I don’t know whether this becomes a serious widespread proble, maybe it doesn’t, but I think it’s worth paying attention to, because eventually one developer won’t be supervising one assistant.

They may be supervising five agents, then ten, then twenty. At some point, the machine will not be the limiting factor anymore. The limiting factor will be the person trying to understand what all those machines just did.

And maybe one of the most important skills in an AI-heavy world will not be learning how to make AI move faster.

It will be learning when not to follow it.

The machines can work at machine speed, we still need to think at human speed.

And maybe that is something worth protecting.

Building Solo: Architecture, Decisions, and Challenges After Launching Deeditt

Jackfiallos — Fri, 23 May 2025 15:05:30 +0000

A solid infrastructure doesn't guarantee users. Neither does a good idea, but sharing the journey?
That changes things.

👋 Who I Am and What I'm Building

I'm a software developer with years of experience building products from scratch, scaling infrastructure, and leading teams, but for the past few years, I've been working on something personal that I have named Deeditt.

Deeditt is a different kind of social network. While platforms like LinkedIn only celebrate achievements, Medium rewards articles written for algorithms rather than people, and the others where you can post anything you want, Deeditt offers something more authentic: documenting the journey whether personal or professional. What you learned, what you did wrong, what you had to rebuild from scratch.

It's a platform where you can share your real experiences through "deeds" (individual posts) and organize them into "journeys" (collections that tell a complete story over time). Think of it as a way to show "how I got here" not just "look where I am."

Have you ever wanted to share the stumbles in a project but couldn't find where that story fits? you're right, this is what Deeditt was built for.

🤔 Why I decided to build such thing

During job interviews and team building, I noticed how people often told small lies about their experience because there was no tangible way to prove otherwise. I kept thinking, "If there was a platform where people documented their actual journey, this wouldn't happen".

Like many who work behind complex systems, I felt something was missing: a space where people could share the process, not just the outcome. I wanted to read more about difficult decisions and less about brilliant successes, to have a better idea of people's real experiences.

So I decided to build it myself, because it's definitely better to learn from someone else's experience than from their final achievement where they usually say "I learned to roller skate, here are 5 tips that will teach you to go faster."

It took me about a year to mentally prepare for this long-term commitment, another year to develop the backend, frontend, server setup, and basic security, and yet another year to start testing the idea with real users. This timeline stretched out because I had a full-time job and Deeditt was my side project, which meant evenings and weekends were my development time.

📱 A wrong beginning? I Started with a Mobile App

When I imagined Deeditt, I saw it as a social network and automatically thought of a mobile app. It seemed logical, so I started building with React Native, a technology I already knew well and that allowed me to maintain a single codebase for iOS and Android.

So I started building the mobile app using React Native with TypeScript, along with Zustand for state management and React Navigation for routing. I chose this stack because it offered the best balance between development speed and performance. Some might argue that using Expo would have been a better choice, but at the time I started the project, Expo didn’t meet my needs. I required more flexibility and control than Expo could offer back then.

I started with just a few screens, but within months it grew so much that I kept introducing more and more features that I thought were "needed." This was the first trap - feature creep without users to validate what was actually necessary but on the other hand, I always was building this for myself.

But wait! Deeditt is also a free space for writing, for expanding ideas, for reflection, and that's not so comfortable on a small screen. Over time like a year after, I realized that starting with web might have been more effective for initial adoption. Visibility and long-form content fit better there. It wasn't a critical mistake, but an important lesson about how the platform defines product dynamics.

🌐 Building the Web Version: A Work in Progress

This realization led me to start working on a complete web version, which is what I'm doing now. Even though it's partially completed, there's a lot of work to do to fully match what I built in the mobile app.

For the web version, I'm using Astro Framework with Preact islands for interactive components - a perfect match for a content-first platform that needs good SEO and performance. I've decided to work in small stages and introduce features one by one. The first stage was deed details and journey detail pages, and now I'm working on authentication, deed posting, and more navigation pages for deeds discovery.

Though the mobile experience is excellent, I discovered many people prefer not to install new apps, especially in markets with geographic restrictions where the web offers greater accessibility. Fortunately, my architecture allows me to extend easily without having to rebuild everything from scratch.

🧱 Architecture: When the Stack Works But Isn't Enough

Technically, I set out to build a system that could sustain itself without constant intervention. So I developed a self-sufficient architecture, focused on efficiency and low cost. Basically, much of what cloud service providers do for you, I decided to do myself. The result is many hours of work, but an extremely low monthly expense to maintain the infrastructure.

I work with:

Docker for containerization, with services defined for production
GitHub Actions for CI/CD pipelines
Ansible with custom scripts that manage remote deployments on my VPS
Prometheus with Grafana for monitoring and visualization
New Relic for performance monitoring
Loki for log aggregation
Slack for real-time alerts
Rollbar for exception tracking
A set of microservices divided by functionality, each with its isolated PostgreSQL database that is using PgBouncer.

Most services are written in Node.js (NestJS framework), Python (FastAPI), and Go (Fiber), depending on the type of workload. API-heavy services are built with NestJS for its structure, computation-intensive services use Go for its performance, and data processing pipelines use Python for its rich ecosystem of libraries.

I don't use tools like Terraform or EKS. I want to maintain control and avoid unnecessary costs. My infrastructure-as-code consists of Ansible playbooks and shell scripts, which together handle everything from server provisioning to automatic SSL certificate management with certbot. Automation allows me to make monthly releases that rarely take more than a few minutes.

Background services run with Prefect for workflow orchestration, and asynchronous communications between applications use BullMQ with Redis as the message broker. For real-time features, I use Socket.IO with Redis adapters to support scaling. Currently, Deeditt costs me not more than $150 USD monthly, and that's enough to support a few hundred more users before needing to scale.

🔀 The Challenge of Service Communication

One of the most complex challenges was establishing communication between different micro-services and servers. With Docker Swarm orchestrating several nodes, I had to make difficult decisions about how to distribute limited resources most efficiently.

I implemented an internal API gateway pattern where each service communicates through a central orchestrator that handles routing, authentication, and rate limiting. This reduces point-to-point communications and simplifies the overall architecture. Since everything runs under Docker Swarm, I don't need additional service discovery tools - the built-in networking handles service location efficiently.

For data consistency across services, I implemented an event-driven architecture using a message queue system. When a service makes a state change, it publishes an event to a topic that other interested services subscribe to. This maintains eventual consistency without tight coupling.

I had to write several custom rules to ensure stable connections between containers. Nothing overly complex, but certainly delicate. This is where my previous experience with distributed systems proved invaluable. I could have started with more sophisticated methods, but maintaining them would have been a headache I wanted to avoid at this stage.

🧩 The Hidden Complexity Behind Simplicity

There's a whole world of complexity beneath Deeditt's surface that users never see. For example:

Internationalization: While Deeditt is prepared for multiple languages, I've currently implemented 6 languages in the frontend and 2 in the backend. The infrastructure is ready for full localization including time formats and cultural contexts, but it's not completely set up yet.
Content Caching: What appears real-time actually involves caching systems with slight delays, optimizing the balance between immediacy and server load. User feeds are cached with intelligent invalidation to ensure content stays fresh.
Security Layers: Multiple security systems work together to protect user data and ensure platform integrity, from authentication to data validation.
Recommendation Engine: I'm working on a system that suggests relevant content and connections based on user interests and behavior patterns. It's still a work in progress, but even in its early stages, it helps users discover content they might find valuable.
Interface Complexity: The UI might resemble Twitter or Threads at first glance, but once inside each "deed," there's a different world of options to discover—creating this intuitive complexity was one of the toughest design challenges.

Each of these elements taught me something valuable, both technically and about user expectations. The most elegant solutions are often those the user never notices are there.

🔄 Deployment and Recovery: Versions, Environments, and Pragmatism

I work with three branches (dev, staging, production). Since my budget is limited, my sandbox is very restricted and shares some resources with production plus a local mix, which forces me to be careful, but it works.

To stay organized, I use Linear for project management, and each ticket number becomes a branch name. This approach clearly helps me identify what I'm building and keeps my work focused. Once a feature is ready, it gets merged into dev. This simple system creates a clear connection between planning and implementation that's invaluable when working solo.

Each deployment is linked to a version tag, both in GitHub and Docker Hub. If something fails, I rollback to a previous stable image. My deployment strategy ensures minimal disruption when updating services, with health checks confirming stability before completing the transition.

For smaller projects, this level of organization might seem excessive, but when managing multiple micro-services and a growing feature set, having this structured approach to deployment and recovery has saved me countless hours of troubleshooting.

🧠 Technical (and Not-So-Technical) Learnings

One of the first systems I implemented was a scoring algorithm with many rules and a popularity system based on multiple factors. It considered interaction patterns, content quality, and user engagement signals to determine what should be shown in feeds.

But over time, I realized I had over-designed things that actually needed to be simple. I refactored the system to focus on just a few core metrics, which resulted in both better performance and more intuitive results for users.

I also spent many hours creating monitoring dashboards. I tracked everything from resource usage to user engagement patterns. But eventually, I understood I was optimizing things that didn't yet need attention. In early stages, less is more.

Have you spent hours optimizing something that didn't really need optimization at that moment?

If I were to go back, I would simplify. Not everything needs to be perfect from day one. Sometimes, "good enough" is exactly what's needed.

In retrospect, developing such comprehensive metrics at an early stage was premature. Although it gives me visibility into the platform, that time could have been invested in features more important for attracting users.

🔑 The Unique Value: Journeys as a Differentiator

What truly distinguishes Deeditt from other platforms are "Journeys". While other social networks show isolated moments, Deeditt allows grouping related "deeds" (achievements/actions) that together tell a complete story over time.

Technically, Journeys are implemented as a flexible structure where each journey can contain multiple deeds, and journeys can also connect to other journeys. This creates a way to organize content that mirrors how real experiences are interconnected.

Each deed within a journey can include images, videos, hashtags, and mentions of other users. Additionally, you can configure privacy settings and define who has access to specific journeys and deeds through customizable visibility policies.

This approach solves a silent but critical problem of our time: the difficulty of verifying if someone really has the experience they claim. By seeing a complete story with all its parts, including obstacles and failures, you get an authentic context that traditional platforms don't offer.

And like many things we do in life, we're always involved in more than just one thing. I'm a clear example—while writing about the development process of Deeditt, I also share thoughts about my son, my journey learning open water swimming, some health issues, and other topics. Each of these is separate, without needing to share too many personal details—just a general view of the moment I'm going through.

The most beautiful part so far is that search engines are already starting to discover the content being created on Deeditt, and that means a lot of positive things.

🌪️ The Real Challenge: Users, Community, and Visibility

None of this matters if nobody uses it.

And there's the real challenge: building community. I returned to social media after years away, only to discover that organic marketing, content, and interaction are completely different worlds from distributed systems and CI/CD pipelines.

On platforms like Medium, I encountered the usual problem: algorithms that don't show what you write if you're not "playing the game." Claps, reads, comments... nothing seemed to have consistency. On LinkedIn, I saw an avalanche of "perfect posts" where everyone is successful, brilliant, and unstoppable.

Deeditt doesn't want that, Deeditt wants the journey, the stumbles, the questionable decisions, the discarded versions.

And of course, that's not easy to sell.

👂 What I've Learned from Feedback

User feedback has been revealing. many get excited about the concept, suggest features, and celebrate updates... but then don't actively use the platform.

This paradox—the gap between what people say and what they do—has been one of my biggest learning. By tracking feature adoption and identifying drop-off points, I discovered that while users loved the concept of Journeys, the friction of creating them was too high.

I'm using that behavior to adjust the experience, but I'm doing it calmly. I want to listen more than I assume, and I'm prepared to change whatever is necessary.

💬 Breaking the Technical-Human Barrier

Perhaps the most unexpected challenge has been learning to express myself effectively. As a developer, I was used to communicating with computers, not people. Marketing, clear communication, and emotional connection are skills I've had to develop from scratch.

It's ironic: I created a platform to improve authentic communication, and in the process, I'm learning to be more authentic in my own communication.

✋ To Those Who Haven't Started Yet: Don't Wait for Everything to Be Figured Out

If you're reading this and haven't started your project yet because you're waiting for your idea to be ready or the stack to be perfect, I'll tell you honestly: it won't be.

Start with what you know. Adjust along the way. Nothing is definitive. I've modified many parts I thought were immovable. Building is iterating, and if you can share what you experience, even a little, you're doing something much more valuable than it seems.

If you have an idea, start it and don't wait for it to be perfect, don't wait to have everything clear. You'll solve things as you go, and what seems like a great solution today might not be tomorrow. That's okay. That's what building is about.

Before Closing

I'm still building Deeditt. I'm still writing about its evolution under the title "Building Deeditt" I don't know when it will grow, or how many people will use it. But I do know that every line of code, every adjustment, and every decision is made with purpose.

What I want to convey is that building solo is possible—even rewarding—but requires balancing technical and human skills. You don't need to spend fortunes on cloud services to create something valuable, but the time you invest is perhaps your most precious resource.

I continue working on Deeditt because I believe it makes sense, even if growth is slow. I do it because I want there to be a place where we can show our processes—without fear and without embellishment.

In the end, it's about creating spaces where we can all grow, share, and learn together.

If you're curious, I invite you to take a look at what I've been building. I'm always eager to hear others' stories—feedback, good or bad, is always welcome. And if you're feeling a bit tired of traditional social media, I propose a different model for sharing content. One where you don’t need to chase validation or constantly post something flashy. I call it "slow content"—a way of publishing that encourages you to write only when you have something meaningful to share, something that adds value to your knowledge and might resonate with others.

And if you're also building something, I'd love to hear your story on Deeditt—or tell me in the comments.

How do you deploy your applications?

Jackfiallos — Sun, 17 May 2020 10:13:12 +0000

Usually I use Mina and Codeship and before Capistrano and Jenkins but I'm interested of knowing what you people use to deploy your applications. Comments and links are very welcome.

Cheers!

Create your own tunnelling like ngrok does

Jackfiallos — Wed, 19 Feb 2020 18:36:48 +0000

If you're here is because you don't want to use ngrok or you are looking for an alternative to it, which is pretty valid because if somebody did that, why you don't?

Well, this story begins with me trying to make my local development environment public and here is where ngrok came to the rescue, this tool works really well, but with some limitations, like having a random subdomain every time you restart your application or using more than one connection, are the things you will need to deal with unless you don't pay for it.

So basically everything works behind ssh tunnelling connections, and if you want to create your own ngrok clone, mainly you will need a VPS server running Linux preferentially.

Now try to connect your local computer to the VPS server through SSH (111.111.111.111 in this case).

$ ssh root@111.111.111.111

There are some different ways to get this done, every connection string depends on the service provider you're using, could need to type your password or could be using a .pem key but in the end, will have the same result.

With your VPS session opened, just type the next command in your terminal, if you have issues with this command try to open the sshd_config file and write at the very end "GatewayPorts yes".

$ echo "GatewayPorts yes" >> /etc/ssh/sshd_config
By default, OpenSSH only allows connecting to remote forwarded ports from the server host. However, the GatewayPorts option in the server configuration file sshd_config can be used to control this.

Restart the SSH service and exit from your session

$ service ssh restart
$ exit

Now you should be able to run a command similar to this one, and guess what!!

$ ssh -R 8080:localhost:3000 root@111.111.111.111

Voilá, this will open the port 8080 on the VPS server and will forward it to the port 3000 on our local machine, basically means you can type on your browser http://111.111.111.111:8080 and effectively will redirect the traffic to your local computer.

I know you want more, say.. subdomains and https connections? yeah, why not, let's finish this.

The next part of this mini how-to is creating a subdomain and link it with your public VPS IP, but I'm will leave this to you, again .. this depends on what service provider you're using.

At this point, you have your VPS server running and ready to forward from source to destination ports, let's assume you have your subdomain created as well, now the next step will be setting up your web server with a reverse proxy tweak. In my case I decided to use Nginx, it's my favourite and it's really simple to set up, actually, my current configuration is similar to this:

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name _;
    location / {
        proxy_pass http://127.0.0.1:8080;
    }
}

And again, works! my VPS server receives traffic from my subdomain and redirects to 127.0.0.1:8080 which is the same server but through SSH tunnelling.

If we test again typing in the browser address bar http://yoursubdomain.domain.com should work and redirect again all petitions to your local computer.

This still needs to work with SSL and to complete this step I recommend you to install certbot and follow the instructions, it's pretty straight forward so I don't have a doubt you will get it.

This is my first article as a non-native English-speaker, so be kind and patient.

Happy Coding! :D