Coder Legion - Recent posts tagged developercommunity

FROM CHATBOTS TO AUTONOMOUS AGENTS: THE REAL ARCHITECTURE OF AI IN PRODUCTION

Thu, 08 Oct 2026 18:42:51 +0000

The Origins: From BASIC to Robotics

How did you first get into software development, and what originally attracted you to programming and building software?

The day I discovered programming was in my childhood. My father brought me the computer I had been begging for months to get: a cassette-tape Spectrum 128k. At that time, the internet didn't exist yet, so the "computer" (a keyboard that plugged into my CRT television) came with a book that taught you how to program in BASIC—an obsolete language where I learned to write if-then statements in English. Video games took 45 minutes to load, so eventually, I found it more entertaining to just program.

I wrote my first real successful project at age 15 in HTML. It was the website for my father's company. It was a massive success because there were hardly any websites back then, and not everyone had internet at home. Since the budget for that project was zero, I decided to turn my PC into a web server and host the site using my noisy dial-up modem.

With an overwhelming passion for technology, I studied to become an electronics developer. Since I am old, I had the fortune—or misfortune—of learning to program firmware in Assembly language, which over the years has given me the ability to understand memory and data flow at all levels.

When did you first become seriously interested in AI and LLMs, and what made you want to explore them beyond simply using AI chatbots?

After years of adventures dedicated to electronics, I one day decided to focus on robotics. I've spent the last 10 years in this sector integrating firmware, software, and, in recent years, artificial intelligence for self-diagnostic processes.

The field of knowledge in robotics is so broad (mechanics, electronics, firmware, software, multiple communication networks, and even AI) that rarely does a single person have the capacity to accumulate all that knowledge. My first prototypes using AI APIs were dedicated to automating breakdown prevention processes. They were complete integrations of electronics and software using a physical trigger to analyze an image of certain robot parts, which reduced preventive maintenance hours.

It was precisely this level of physical interaction and complex problem-solving that made me want to go beyond chatbots: discovering that AI could be integrated into the real world to execute actions.

The Genesis of Zyro Workspace and AutomaticIA

Your profile says you built an autonomous AI colleague because you hated manually formatting Google Slides and copying data into Drive. Can you tell us about that experience?

More than two years ago, some colleagues at my company proposed that I join the workers' legal representation to negotiate improvements with the management. The workers voted for me, and I started my new adventure as a union representative.

I discovered that we were spending a lot of energy advising colleagues and answering the same questions over and over again. So, I decided to program a chatbot with a RAG (Retrieval-Augmented Generation) database so that colleagues could ask questions anonymously, allowing me to dedicate my time to preparing for negotiations. This simple chatbot reached the hands of someone in the union's industrial federation, and shortly after, they offered me an office to help them optimize work processes using AI.

It was from this perspective that I understood the pain points of an administrative office and a law firm, and for them, I designed the first version of Zyro Assistant. They work within the Google ecosystem, so I thought about designing an agent that would connect directly to Google Workspace and execute certain tasks for me, without me ever having to touch the keyboard.

What motivated you to start AutomaticIA, and what are you ultimately trying to build with it?

AutomaticIA is not my first business venture. Fifteen years ago, I founded SGS Automatismos e Ingeniería, my small electronics engineering company, which today continues to operate in the hands of one of my partners. About three years ago, I decided to buy a small driving school business—a highly profitable venture outside the tech sphere.

Simultaneously with the process optimization I was carrying out at the industrial federation, I implemented automation projects within my own companies, saving many hours of work and making them highly profitable. By deeply analyzing the real economic value that my automation projects provided, I decided to venture into creating AutomaticIA to meet the digitalization needs of Spanish companies.

My ultimate goal with this project is to democratize access to advanced business technology by offering artificial intelligence consulting and the development of custom autonomous agents. We want to be the bridge that covers companies' digitalization needs, transforming traditional workflows into efficient systems where AI takes on the heavy administrative burden.

What is Zyro Workspace, and what problem are you trying to solve with this open-source Node.js SDK?

The first version of Zyro Assistant was built entirely—both backend and frontend—inside Google Drive using a Google Apps Script. For several months, I analyzed common bottlenecks across all departments in the federation. After building specific apps for various departments, I realized I could work on a universal tool that would increase overall productivity across the entire federation simultaneously.

Zyro Workspace is the result of over two years of work, testing, and solving bottlenecks in law firms and administrative departments. I noticed a pattern: although Google provided useful productivity tools in their corporate accounts, almost no one used them. They required a learning curve, and workers are simply too busy to stop, test, and learn new software.

Zyro Assistant solves this by integrating with all the tools in the Google ecosystem using only voice commands. You just tell Zyro what you need, and it guides you. As I integrated more functions, I decided to break through the limits of Apps Script and build a much more robust, complete version on Google Cloud. I developed an independent multi-agent PBX (telephone switchboard) software and integrated it with Zyro, making it the first autonomous, multi-functional agent capable of making real phone calls. Today, Zyro is used as the central orchestrator to interact with other custom-built applications for clients.

The Engineering Behind the Agent

What makes an AI agent fundamentally different from a traditional chatbot? When does an AI system actually become autonomous?

A chatbot only answers questions; an agent is given tools to carry out specific tasks. A chatbot has a single AI layer, whereas an agent capable of being truly autonomous and error-free has multiple layers of agents and skills managed by an orchestrator that interacts with the user.

From my experience in process optimization, total autonomy is a major point of friction. Today, most people are still not psychologically prepared to let an AI do a job that a person previously did autonomously. That is why it's crucial to carefully study which of the agent's processes will be autonomous and which will need confirmation.

In Zyro Assistant, we have given it many layers of background functions that gather information from its environment to give it the ability to be proactive and learn how its user works. The main rule is that it only has full autonomy in creative tasks—like generating a report before a meeting by analyzing the agenda, email interactions, and transcripts. However, it never has autonomy in destructive tasks, such as deleting an event or a document.

Why did you choose Node.js and JavaScript as the foundation for your work with autonomous AI agents?

The initial choice was a matter of pragmatism. Since Zyro's first prototype was born inside Google Apps Script (which runs on JavaScript's V8 engine), migrating to Google Cloud and Firebase made Node.js the path of least friction.

However, as the architecture grew more complex, I discovered Node.js offered unbeatable technical advantages for orchestrating AI in production. The current paradigm of autonomous agents is based on Function Calling. The LLM reasons and returns its execution intents in structured JSON formats. In Node.js, JSON is a first-class citizen. Parsing, validating, mutating, and routing the model's structured responses is an organic, fast process that avoids strict serialization overhead.

An AI agent is a massive orchestrator of input/output (I/O). When Zyro executes a mission, it is calling the Gemini API, searching Google Drive, scheduling in Calendar, and simultaneously waiting for an asynchronous webhook from our PBX after a call ends. The non-blocking Event Loop in Node.js is architecturally perfect for handling these concurrent waits without choking the server's processing resources.

What do developers often misunderstand about LLM Function Calling, and why is it so important?

The biggest misunderstanding is believing that the Artificial Intelligence is executing the code. There is a false illusion that by giving a tool to the LLM, the model magically "connects" to Google Calendar or an email API.

The technical reality is that the model is like a "brain in a jar": completely isolated from the outside world. All Function Calling does is apply an Inversion of Control. The model executes nothing; it simply reasons about which tool it needs to use and returns a structured JSON payload. It is you, in your middleware, who must intercept that JSON, validate security, execute the actual code, and return the result to the model.

The second huge mistake is trusting the JSON schema blindly. In production, AI hallucinates parameters, invents database IDs that don't exist, or tries to execute tools in the wrong order. If you don't design a robust backend capable of intercepting those errors, returning the stack trace to the model, and forcing a silent retry—a self-healing system—your agent will constantly break.

Trust, Security, and Event-Driven Architecture

Your profile mentions Inversion of Control (IoC) architectures. How does IoC influence the way you design autonomous agents?

It shifts the security paradigm: we go from "trusting the AI" to "trusting the infrastructure." When you design an autonomous agent for a B2B corporate environment, companies' biggest fear is that the AI will hallucinate and delete confidential files. If you don't apply Inversion of Control, your only defense is writing rules in the System Prompt, which is incredibly fragile and vulnerable to prompt injection.

IoC allowed me to decouple the AI's "intent" from the actual "authorization." Since the Node.js middleware executes the action, we always inject the native OAuth2 token of the user operating the agent. The AI never holds master admin keys. Because the AI doesn't execute code directly, IoC also allows me to protect the user from parameter hallucinations. If the LLM makes a mistake formatting a date, my server intercepts that crash, feeds the raw error back to the AI in the background, and asks it to rectify. The user is completely unaware that an internal failure occurred.

Autonomous agents can take actions on behalf of users. How do you handle permissions and prevent an agent from taking an action it shouldn't?

Security is managed on the server through the principle of native token delegation (Zero-Retention). The AI doesn't know who you are or what permissions you hold. When it decides it needs to read a document, the backend intercepts that intent and executes the API call using the active user's OAuth token. If the human employee doesn't have corporate permission to view that document, neither does the AI.

For critical or destructive actions, we enforce a strict Human-in-the-Loop protocol mandated by the backend. The model can reason and propose deleting an event, but the middleware pauses the process and pushes that intent to the GUI for manual approval.

How do events change the way an autonomous agent operates compared with a traditional request-and-response application?

It completely changes the nature of the software: you go from having a "digital slave" that waits for your orders to having an "asynchronous coworker."

A classic Request-Response architecture is inherently synchronous and linear. But when you orchestrate complex API calls, RAG tools, and LLMs, a process can take 15 or 30 seconds. Keeping an HTTP connection open and blocking the user is not scalable. Migrating to an event-driven architecture in Node.js allowed me to implement true asynchrony.

For example, when I ask Zyro to call a client, the system doesn't block waiting for the person to pick up, talk, and hang up. Instead, Zyro dispatches the mission to the PBX and "goes to sleep," freeing up resources. When the physical call ends 5 minutes later, the PBX fires an asynchronous Webhook to our backend. That event "wakes up" Zyro, injects the call transcript into its context, and the agent proactively generates a summary notification. The agent is subscribed to reality, not just user clicks.

You also mention exploring ways of bypassing virtual DOMs for custom RPA extensions. What problem are you trying to solve?

Our idea is to take the agent out of the isolated UI and give Zyro "eyes and hands" so it can guide the user in their daily work across other websites. We leave DOM tree analysis as an absolute last resort due to the massive amount of AI tokens it can consume. Instead, our primary approach uses Computer Vision models. We capture an image of the screen of the user's active tab and pass it to the AI. The model visually analyzes the interface and returns the precise (X,Y) coordinates of where interaction is needed. From there, our extension dispatches real mouse events to those coordinates, effectively bypassing Virtual DOM blockers in modern frameworks.

The Reality of AI in Production

What has been the hardest part of turning your ideas about autonomous AI agents into a real open-source project?

Without a doubt, the hardest and most time-consuming part has been the paradigm shift in debugging. Anyone can integrate the Gemini or OpenAI API over a weekend and claim they've built an "agent." But making that agent handle dozens of simultaneous functions securely, without hallucinations, and with a near-zero error rate in production—that is the true architectural challenge.

*The three toughest technical barriers have been:

Debugging Non-Deterministic Systems: With LLMs, failure is statistical. Debugging forces you to build layers upon layers of validation in Node.js to encapsulate an unpredictable engine within a strictly deterministic environment.
Cognitive Overload and "Prompt Gravity": As I gave Zyro more skills, the model started confusing tools because of the context size. I had to investigate advanced context injection techniques (like Tail-end Overrides) to inject absolute reminders milliseconds before execution.
Designing Self-Healing: Achieving a minimal error rate forced me to design recursion loops in the backend. If the AI fails to execute a tool, the server intercepts the crash and feeds it back to the AI to correct its own hallucination in milliseconds, utilizing a circuit breaker pattern to prevent infinite loops.*

Looking ahead, where do you see autonomous AI agents heading in the next few years?

AI agents already possess the technical capability for total autonomy. As AI models advance exponentially, it is inevitable that agents will completely take over any job performed on a computer. When that time comes, our job will be to perform the only task AI cannot innately do: imagine, structure architectures, and have brilliant ideas for the AI to implement.

For Zyro Assistant, my medium-term vision is for it to become the foundation and orchestrator of a complete ecosystem of AI applications for all types of administrative management: ERP, CRM, OMS, BI, CPM, and BPM. AutomaticIA will serve as the consulting and distribution arm. We are developing a proprietary platform covering ERP, CRM, and BI, all connected and orchestrated natively by Zyro, featuring a universal database import program to eliminate vendor lock-in.

Finally, what advice would you give to a developer who wants to start building autonomous AI agents today?

Ground the weight of any AI project on solid software architecture. A very common mistake is placing AI at the structural base of the system. If you build on top of that, your project will be incredibly inefficient and will collapse very quickly. Build a robust traditional software foundation first, and use AI as an attached "engine," never as the foundation.

I would also advise having a clear understanding of the physical limits of the model you are using: its context window, inference speed, and token consumption. If you don't learn to strictly manage the amount of context you inject into the model, your system will be agonizingly slow and extremely expensive to maintain. Poorly calibrated tokens can cause a context window overflow, triggering hallucinations and cascading errors. Memory footprint management in complex agents must always be an absolute priority.

How Developer Communities Can Grow Organically

Tue, 06 Oct 2026 08:51:06 +0000

Developer communities don’t grow because you simply put up a Discord server, run ads, or post invitations everywhere.

They grow when people have a real reason to stay.

A few lessons from this article that stood out to me:

🔹 Start with a real problem Give developers something they genuinely need.

🔹 Value your first members A small group of active, helpful people is more powerful than thousands of silent members.

🔹 Be useful before promoting Share knowledge, answer questions, and help people without always expecting something in return.

🔹 Consistency beats intensity One big event followed by months of silence won’t build much. Regular, useful conversations will.

🔹 Let members take ownership When people can suggest topics, host discussions, or contribute content, they become part of the community rather than just an audience.

🔹 Go where developers already are GitHub, Reddit, Discord, meetups, and other existing communities are great places to build genuine relationships.

The biggest takeaway for me:

A developer community should be built around people and their problems not around marketing.

Organic growth may take longer, but the relationships and trust it creates are much more sustainable.

What do you think is the most important factor in building an active developer community?

The Feature Works, So Why Is the Product Still Failing?

Wed, 16 Sep 2026 14:48:17 +0000

As web developers, we often measure our work by a simple question:

“Does the feature work?”

The button works.
The API returns the expected response.
The database stores the data.
The page loads.
The deployment succeeds.

So we move the ticket to Done.

But sometimes a strange thing happens.

A few weeks later, users complain.

The application feels slow.
Customers cannot find an important feature.
Support receives the same question repeatedly.
The database has thousands of unnecessary records.
The dashboard works perfectly on a developer's laptop but becomes painful on a real user's phone.

Technically, the feature works.

But the product is still failing.

This is one of the most important lessons a web developer can learn:

Building working software and building useful software are not always the same thing.

Modern development has made it easier than ever to create features. AI coding assistants, component libraries, frameworks, APIs, cloud services, and reusable packages can dramatically reduce development time.

But faster development also creates a new risk.

We can become very good at building things that nobody actually needs.

The Difference Between “Working” and “Useful”

Imagine you are building an online shopping application.

The product team asks for a wishlist.

You create:

a wishlist database table
an API endpoint
authentication
a React component
add/remove functionality
loading states
error handling
tests
deployment

Everything works.

You proudly demonstrate it.

But after launch, almost nobody uses it.

Why?

Maybe the wishlist button is difficult to find.

Maybe users don't understand what it does.

Maybe customers usually purchase products immediately.

Maybe the application has a bigger problem: checkout is confusing.

Maybe the wishlist feature was requested because another competitor had one, not because customers actually wanted it.

From a purely technical perspective, you succeeded.

From a product perspective, the result may be very different.

This is why developers should sometimes ask a question before asking:

“How should I build this?”

Ask:

“Why are we building this?”

That single question can save weeks of engineering work.

The Hidden Cost of Features

Every feature has a cost beyond development time.

When we add something to an application, we also add maintenance.

A new feature can introduce:

more database tables
more API endpoints
more frontend components
more tests
more documentation
more monitoring
more security considerations
more edge cases
more support questions
more deployment complexity

For example, adding a simple notification system might initially look easy.

You create a notifications table.

Then you need:

notification preferences.

Then email notifications.

Then push notifications.

Then notification history.

Then unread counts.

Then retry logic.

Then rate limiting.

Then background jobs.

Then monitoring.

Then users complain about receiving duplicate notifications.

Suddenly a feature that looked like a small task becomes another system that the team must maintain.

Software complexity grows not only from the amount of code we write, but from the number of behaviors we introduce.

This is why “just add one more feature” can be dangerous.

The Developer's Responsibility Doesn't End at the Commit

There is a common mindset in software development:

Product defines the requirements.
Developers implement them.

There is some truth in this division.

But developers are also users of technology.

We understand technical consequences that may not be obvious to everyone else.

Suppose a requirement says:

“Allow users to upload unlimited images.”

A developer should immediately think about:

storage cost
file size limits
image compression
malicious uploads
file formats
CDN usage
database metadata
deletion policies
backups
bandwidth
performance

The requirement sounds simple.

The implementation is not.

A good developer doesn't simply say:

“Sure, I can build that.”

A better response might be:

“Yes, but let's clarify the expected file sizes, formats, storage policy, and how long we need to retain these files.”

That isn't being difficult.

That's engineering.

Start With the User's Problem

One of the biggest mistakes in software development is starting with technology instead of the problem.

A team says:

“We need a dashboard.”

The immediate discussion becomes:

Should we use React?

Should we use Vue?

Should we use Next.js?

Should we use GraphQL?

Should we use PostgreSQL?

Should we use Redis?

But none of these questions answer the most important question.

What problem will the dashboard solve?

Maybe the actual problem is that managers receive five different reports every morning.

If that's the problem, perhaps the solution isn't a giant dashboard.

Maybe it is a simple daily summary email.

Or perhaps a dashboard really is appropriate.

The important part is understanding the problem before deciding on the implementation.

Technology should support the solution.

It shouldn't become the solution by itself.

AI Has Made This Problem More Interesting

AI coding tools have changed the development workflow dramatically.

Today, a developer can describe a feature and quickly receive:

frontend components
backend APIs
database schemas
tests
documentation
validation
authentication flows
deployment configurations

This can be extremely useful.

But there is a hidden danger.

When implementation becomes cheaper, unnecessary implementation becomes cheaper too.

In the past, building an unnecessary feature might require two weeks.

Today, an AI-assisted developer might create a prototype in a few hours.

That sounds like a pure advantage.

But imagine creating ten unnecessary features instead of one.

The speed itself doesn't guarantee better software.

AI can help answer:

“How can I build this?”

But humans still need to answer:

“Should we build this?”

And:

“What happens after we build it?”

That distinction will become increasingly important.

Don't Let the Demo Become the Product

Another common problem is optimizing software for demonstrations.

A feature looks impressive during a product demo.

Everything works.

The developer uses:

fast internet
a powerful laptop
clean test data
a modern browser
perfect inputs

Then real users arrive.

They have:

slow connections
older phones
large datasets
unexpected input
accessibility needs
different browsers
poor network conditions

The feature suddenly feels very different.

This is why developers need to test beyond the happy path.

Ask:

What happens when things go wrong?

What happens if the API takes 10 seconds?

What happens if the user refreshes during a payment?

What happens if the database contains one million records?

What happens if the user submits the same form twice?

What happens if the user loses internet connection?

What happens if JavaScript fails?

What happens if the user enters unexpected data?

These questions often reveal more about software quality than a successful demo does.

Performance Is a Product Feature

Developers sometimes treat performance as an optimization task that can be handled later.

But users experience performance as part of the product.

If a page takes too long to load, the user doesn't think:

“Interesting, this application probably has an inefficient database query.”

They think:

“This website is slow.”

That difference matters.

A web developer should consider performance from the beginning.

For example:

Instead of loading every record immediately, use pagination.

Instead of sending huge images, optimize them.

Instead of making unnecessary API requests, cache appropriate data.

Instead of rendering everything on the client, consider whether server-side rendering or other strategies make sense for the application.

Instead of optimizing based on assumptions, measure real performance.

And importantly:

Don't optimize everything. Optimize what actually affects users.

A developer can spend two days optimizing a function that runs in 5 milliseconds while ignoring a page that takes five seconds to load.

Measurement helps us focus.

The Database Is Part of the Product

Frontend developers sometimes think primarily about screens.

Backend developers may focus on APIs.

But the database quietly determines how much pain the application will experience later.

A poor schema can create problems that become increasingly expensive to fix.

Consider a system storing customer activity.

At first:

10,000 records.

Everything is fast.

Then:

1 million records.

Still manageable.

Then:

50 million records.

Suddenly queries become slow.

Reports take minutes.

Indexes need to be reconsidered.

Storage costs increase.

Backups become larger.

Data retention becomes important.

The original feature may still work exactly as designed.

The problem is that the system wasn't designed with growth in mind.

This doesn't mean every small application needs a massive distributed architecture.

It means developers should understand the expected scale.

Don't build for imaginary scale, but don't completely ignore predictable scale either.

Simplicity Is an Engineering Skill

Developers often celebrate sophisticated architecture.

Microservices.

Event-driven systems.

Distributed queues.

Multiple databases.

Complex caching layers.

Service meshes.

These technologies can be valuable.

But complexity itself isn't a sign of engineering quality.

Sometimes the best architecture is boring.

One application.

One database.

A few clear APIs.

Simple deployment.

Good monitoring.

Good tests.

Clear documentation.

That can be much easier to understand and maintain.

The goal isn't to use the most advanced architecture.

The goal is to build a system that solves the problem reliably.

Complexity should be justified by a real requirement.

Not by the desire to make the architecture look impressive.

Maintenance Is Where Software Quality Becomes Visible

Launching software is exciting.

Maintaining it is where reality appears.

After six months, someone needs to understand your code.

After one year, the original developer may not even be on the project.

A dependency becomes outdated.

An API changes.

A security vulnerability is discovered.

A database grows.

A customer asks for a new workflow.

A bug appears in a feature nobody has touched for months.

This is why maintainability matters.

Code should be understandable.

Naming should be clear.

Important decisions should be documented.

Tests should cover meaningful behavior.

Logs should help diagnose failures.

Monitoring should tell the team when something goes wrong.

Good software isn't simply software that works today.

Good software is software that a team can continue changing tomorrow.

Security Shouldn't Be an Afterthought

Another example of “working but failing” is security.

Imagine a user profile endpoint.

It correctly returns profile information.

The feature works.

But the endpoint doesn't properly verify authorization.

A user might access another user's data by changing an ID in the URL.

Technically:

The endpoint works.

Functionally:

It returns data.

From a security perspective:

The design is broken.

Security needs to be part of the feature itself.

Developers should think about:

authentication
authorization
input validation
sensitive data
secrets
file uploads
rate limiting
dependency vulnerabilities
logging
access control

A feature isn't complete simply because the normal user flow works.

Accessibility Is Also Part of “Working”

Consider a website that works perfectly with a mouse.

Can someone navigate it using a keyboard?

Can screen readers understand the content?

Do buttons have meaningful labels?

Is the color contrast sufficient?

Can users identify form errors?

Are interactive elements accessible?

If the answer is no, the application may technically work for the developer who built it, while failing for part of the intended audience.

Accessibility shouldn't be treated as decoration.

It is part of building usable software.

Even small improvements can matter:

semantic HTML
proper labels
keyboard navigation
meaningful alt text
visible focus states
accessible error messages

These practices often improve the experience for everyone.

How Can Developers Build More Meaningful Software?

A useful approach is to add a few questions to the development process.

Before building a feature, ask:

What user problem are we solving?

Who actually experiences this problem?

How frequently does it happen?

What does success look like?

What is the simplest solution we can test?

Before launching, ask:

What can go wrong?

What happens with bad input?

What happens under slow network conditions?

What happens when the system has much more data?

Is the feature secure?

Is it accessible?

Can we monitor it?

After launching, ask:

Are users actually using it?

Are support requests increasing or decreasing?

Did the feature solve the original problem?

What did we learn?

These questions don't require a new framework.

They require a different mindset.

The New Developer Skill: Knowing What Not to Build

For a long time, software engineering rewarded the ability to build.

Now, the ability to decide what not to build is becoming equally important.

If AI can generate code quickly, typing code becomes less of a bottleneck.

The bottleneck becomes judgment.

Understanding requirements.

Identifying risks.

Choosing trade-offs.

Recognizing unnecessary complexity.

Understanding users.

Testing assumptions.

Communicating with product teams.

Measuring outcomes.

Maintaining systems.

These are not separate from engineering.

They are engineering.

A developer who can create 10,000 lines of code quickly isn't necessarily more valuable than someone who prevents 10,000 unnecessary lines from being written.

Sometimes the best code is the code you decide not to create.

A Simple Rule I Try to Remember

When I work on a feature, I think about three different questions:

Does it work?

This is the technical question.

Does it help?

This is the product question.

Can we maintain it?

This is the engineering question.

A feature should ideally survive all three.

Because software isn't created just to exist.

It exists to help someone accomplish something.

The future of web development isn't simply about writing code faster.

It is about understanding problems better, making better trade-offs, and creating software that remains useful after the excitement of launch disappears.

AI will continue to change how quickly we can build.

Frameworks will continue to evolve.

Browsers will continue to become more capable.

Cloud infrastructure will continue to become easier to access.

But one principle will remain:

The goal of software development isn't to produce more software. The goal is to solve meaningful problems with software.

And sometimes, the most valuable thing a developer can say isn't:

“I can build that.”

It is:

“Let's make sure we're solving the right problem first.”

What Do You Think?

As developers, we often celebrate shipping features, closing tickets, and releasing updates.

But how often do we go back and ask whether those features actually improved the user's experience?

Have you ever built a feature that worked perfectly technically but turned out not to solve the real problem?

What did you learn from that experience?

And with AI making software development faster, do you think developers will spend more time solving meaningful problems—or will teams simply produce more features?

I'd love to hear how other developers approach this.

Sumita
Web Developer

I'm Not a Developer. But I've Spent 10 Years Writing for Them.

Thu, 14 May 2026 13:36:51 +0000

Most Dev's Journey stories start with a first line of code. Mine starts somewhere different.

I came from marketing. And somewhere along the way, I became a technology writer — not because I could build software, but because I was genuinely curious about the people who do.

Over the past 10 years, I've interviewed more than 4,000 IT executives. I've attended several hundred user conferences and press tours. And I've written more than 2,000 articles, blog posts, use cases, and white papers — all focused on one thing: helping developers, engineers, and architects understand new tools and solutions that can make their work simpler and easier.

That's been my job. And honestly, it still feels like the right one.

Why Developers, Engineers, and Architects?

Early in my writing career, I found a home at DZone. It was the go-to destination for technical professionals who wanted to stay current — not just learn how to code, but understand what was new, what was changing, and what was worth paying attention to.

I loved that audience. They're sharp, skeptical, and they don't have time for fluff. If your writing isn't useful, they're gone. That kept me honest.

But DZone evolved. And for a while, I wasn't sure where to find that same engaged, technically-minded community.

Then I found Coder Legion.

What Coder Legion Gets Right

Training and tutorials are valuable. But staying current on new solutions matters just as much. The best developers and engineers I've spoken with over the years are always looking ahead — not just sharpening existing skills, but scanning the horizon for tools that will help them work better and faster.

Coder Legion feels built for that mindset. It's a place where technical professionals can discover what's new, share what they know, and learn from people across the industry — including, apparently, writers like me who spend their days talking to the people building the future.

What I've Learned Along the Way

After 4,000+ interviews and 2,000+ articles, a few things have stuck with me.

The best technology solves real problems. Not hypothetical ones. Not marketing ones. Real ones that slow people down, create friction, or make already-hard jobs harder.

Developers don't want to be sold to. They want to be informed. There's a difference. The articles that perform best aren't the ones with the most superlatives — they're the ones that answer a real question clearly.

The community matters. I've seen technologies rise and fall. What lasts is usually backed by a community of people who believe in it, build on it, and share what they know. That's true of platforms, too.

Why I'm Here

I publish on Coder Legion because the audience is right. These are the people I've been writing for all along — technical professionals who want to know what's new and whether it's worth their time.

I'm not a developer. But I've spent more than a decade trying to make their lives a little easier. And I plan to keep doing it.

Tom Smith is a technology writer and communication strategist who has written more than 2,000 articles covering cybersecurity, AI, and developer tooling. He writes for publications including Coder Legion and Techstrong.

Account Abstraction: Web3 Made Easy

Thu, 08 Jan 2026 03:22:25 +0000

Ditching the Seed Phrase: How Account Abstraction Makes Web3 Logins as Easy as Google

The initial experience of setting up a crypto wallet, involving a 12 or 24-word "seed phrase," has been a significant barrier to mainstream Web3 adoption due to its anxiety-inducing nature and the burden of secure storage. Account Abstraction (AA) aims to transform the Web3 user experience by making interactions as intuitive as logging into Web2 applications with Google or Apple IDs, eliminating the need for seed phrases.

The Web3 Onboarding Wall: Why Seed Phrases Just Don't Scale

Traditional Web3 interactions, primarily through Externally Owned Accounts (EOAs), present several friction points:

The Seed Phrase Saga: The seed phrase is the master key to an EOA. Loss or compromise of this phrase results in permanent loss of funds. The user bears the sole responsibility for its secure storage and recovery, creating stress and a steep learning curve.
Gas Fee Headaches: Transactions on most blockchains require gas fees in the native token (e.g., ETH). Users must acquire and hold these tokens to use applications, adding complexity and interrupting workflows.
Limited Flexibility: EOAs are basic accounts lacking programmable logic for advanced security or custom transaction rules.
Constant Approvals: Interacting with decentralized applications (dApps) often involves a barrage of transaction signing requests, disrupting the user flow compared to Web2 interactions.

These hurdles, particularly the seed phrase, have significantly hindered Web3's broader audience reach.

Enter Account Abstraction: Smart Contracts to the Rescue

Account Abstraction is a paradigm shift that redefines blockchain user interaction. It enables smart contract wallets to function as primary user accounts, moving beyond EOAs controlled by a single private key.

A wallet becomes a programmable contract with its own rules for transaction validation, execution, and recovery.
On Ethereum, ERC-4337 is a key standard enabling AA without core protocol changes. It introduces:
- UserOperation objects: A new transaction representation for smart contract wallets.
- A decentralized mempool for broadcasting UserOperation objects.
- An on-chain EntryPoint contract to process valid UserOperation objects and execute them via smart contract wallets.

This framework allows for more sophisticated and user-friendly wallets.

Your Google/Apple ID is Now a Crypto Wallet

AA bridges the Web2-Web3 gap by allowing familiar Web2 authentication methods (Google, Apple logins) to create and manage crypto wallets, eliminating seed phrases. This is largely achieved using passkeys based on the WebAuthn standard:

Seamless Authentication: When a user selects "Sign in with Google" or "Sign in with Apple," their device generates a unique cryptographic key pair (a passkey) using secure hardware (e.g., Apple's Secure Enclave, Google's Password Manager).
Public Key Registration: The public key of this passkey is registered and stored within the user's new smart contract account on the blockchain, acting as an authorized "owner" or "signer."
Familiar Transaction Signing: To approve a transaction, the user employs their device's primary authentication method (Face ID, Touch ID, PIN). This securely unlocks the private portion of the passkey (which remains on the device) to cryptographically sign the transaction.

The outcome is a non-custodial crypto wallet that functions like a Web2 login, abstracting blockchain complexities. Advanced implementations may also use Multi-Party Computation (MPC) or Secure Hardware Modules (HSMs) for enhanced security and recovery.

Beyond Logins: A Smarter Wallet Experience

AA offers benefits beyond simplified logins:

Gasless Transactions & Flexible Fee Payment: Developers can sponsor gas fees, or users can pay with any ERC-20 token, removing the need to hold native tokens for gas.
Enhanced Security & Account Recovery: Smart contract wallets can implement multi-factor authentication (MFA), multi-signature requirements, and programmable spending limits. Crucially, AA enables social recovery, allowing users to regain access via trusted contacts or pre-defined methods, mitigating permanent fund loss.
Streamlined UX & Automation: Batch multiple operations into a single transaction (e.g., "one-click buys," complex DeFi operations). Enable automated payments for subscriptions or games, leading to a smoother user experience.
Programmable Wallets: Wallets become customizable, allowing for features like daily spending limits for specific dApps or requiring secondary biometric scans for high-value transactions.

The Future is Seamless

Account Abstraction, through standards like ERC-4337 and Web2 login integration via passkeys, is a significant advancement for Web3 adoption. By abstracting technical complexities like seed phrases, it enables developers to build more accessible, secure, and user-friendly applications. The era of clunky onboarding is fading, paving the way for Web3 interactions that are indistinguishable from Web2 experiences. Developers are encouraged to embrace AA to build this future.

What are your thoughts on Account Abstraction and its impact on dApps? Share your insights!

Checkout the full post in dev.to!

Dev.to