Coder Legion - Recent posts tagged developers

From GitHub to Codeberg: Rethinking Repository Management and Personal Website Hosting

Wed, 28 Oct 2026 15:35:59 +0000

Developer platforms make it easier than ever to build and publish software. With hosted Git repositories and static website deployment, an individual developer can maintain a portfolio without managing an entire server infrastructure.

However, convenience also introduces an important question: how prepared are we when our existing workflow no longer meets our needs?

I recently faced this question while maintaining my personal website and repositories.
When a Familiar Workflow Stops Working

GitHub had been an essential part of my development process. I used it to manage source code, track changes, and publish my personal website through GitHub Pages.

The workflow was straightforward. I could commit changes, push updates, and use the hosting service to make my website publicly accessible.

Eventually, I encountered an issue that affected website publishing. My account was still accessible, but the publishing functionality did not work as I expected. I could not establish the exact cause, so I avoided drawing conclusions about the platform or its policies.

Nevertheless, the problem disrupted my workflow and encouraged me to explore alternative solutions.

The experience highlighted something worth considering: even when source code is stored safely, the services surrounding a repository may introduce separate dependencies.

Repository storage, continuous integration, deployment, domain management, and public hosting are related, but they are not necessarily the same responsibility.

Understanding those distinctions can make future migrations easier.
Moving Repositories to Codeberg

I decided to move my repositories to Codeberg, a platform built around open-source software and Git-based collaboration.

A repository migration requires more than copying project files. Depending on the project, developers may need to verify branches, tags, commit history, remotes, and repository settings. Issues, pull requests, automation, and other platform-specific features may require separate consideration.

A practical migration checklist includes:

Create a reliable backup of each repository.
Verify that the Git history and important branches are preserved.
Update remote URLs and test push and pull operations.
Review project documentation and any external integrations.
Confirm that essential workflows still function after migration.

Not every platform feature has a direct equivalent, so each project should be checked individually.

The objective is not merely to move the code. It is to ensure that the development workflow remains usable afterward.
Self-Hosting a Personal Website

For website deployment, I chose a home server instead of relying on my previous publishing workflow.

Self-hosting provides a valuable learning opportunity, particularly for developers who want to understand how websites operate beyond application code.

It also introduces several operational responsibilities.

DNS records must point to the correct destination. Public access may require router configuration, a reverse proxy, or a suitable tunneling solution. HTTPS should be configured appropriately, while backups and software updates need to become part of regular maintenance.

Availability is another consideration. A home server depends on electricity, network connectivity, hardware reliability, and the security of the surrounding environment.

Self-hosting is therefore not automatically cheaper or more reliable than managed hosting. The right choice depends on the project, available resources, and the operator's willingness to maintain the system.
A Better Understanding of Technical Dependencies

This migration has encouraged me to think more carefully about portability, infrastructure, and recovery planning.

Developers do not necessarily need to abandon hosted services. However, they benefit from knowing which components are essential, how those components interact, and how to replace them if necessary.

I documented the personal side of this transition, including why I left my previous workflow and what I hope to learn from the move, in my original article:

Read the full experience: Moving On, Not Out of Hate: My Journey from GitHub to Codeberg

For me, the move is both a practical adjustment and a learning project. By combining Codeberg for repository management with a home server for deployment, I hope to develop a better understanding of the infrastructure behind my personal projects.

Sometimes, the most useful outcome of a technical problem is not the replacement tool itself, but the knowledge we gain while finding a new way forward.

# MyZubster Is Becoming a Network of Independent Creators, Developers and AI Contributors

Tue, 27 Oct 2026 05:01:27 +0000

MyZubster: Building an Open-Source Network of Independent Creators, Developers and AI Contributors

From digital comics and urban gardening to decentralized infrastructure, a simpler marketplace and the first experiments with autonomous AI collaboration.

By Daniel — MyZubster Open-Source Ecosystem

What happens when a software developer, a digital artist, a gardener, a security contributor and an AI agent become part of the same open-source community?

That is one of the questions we are exploring with MyZubster.

Our goal is to build an ecosystem where people can create independent projects, share knowledge, offer services and collaborate through open tools.

We are combining a service Marketplace, the Zorgax assistant, contributor identities, creative projects and experiments in decentralized infrastructure.

But the most important part of MyZubster is not the technology alone.

It is the people building and sharing their own projects.

Today, I want to introduce the contributors helping MyZubster evolve, explain what they are working on and share links to their public work.

Wasim — Making MyZubster Simpler and More Accessible

GitHub: https://github.com/wasim-builds

Wasim is helping redesign the MyZubster homepage and Marketplace.

His work focuses on making the platform easier to understand, with four main actions:

Find services.
Offer a service.
Explore the Metaverse.
Access your profile.

He is also working on listing photographs, responsive interfaces and improvements to the Seller Free experience.

Explore his work:

Wasim has reported successful automated tests of the Seller Free workflow in an isolated environment.

Current status: The new interface is still under review and requires final browser and deployment verification.

This work is important because MyZubster needs to be useful to ordinary people, not only developers.

Gangkor — Security and Independent Infrastructure

Gangkor is involved in MyZubster's infrastructure and security experiments.

We are exploring how independent contributors can work in isolated environments, verify software and collaborate without exposing production systems.

His work connects to experiments involving:

Independent security testing.
Isolated development environments.
Infrastructure verification.
Interoperability between contributor projects.
Safer collaboration with other developers.

Explore the public discussions:

This is experimental work, not a claim that the complete MyZubster network is already decentralized.

Our objective is to distribute technical responsibility safely.

Laurent — Technical Review, Marketplace Logic and Transparency

Laurent is contributing independent technical analysis and review.

His involvement has helped clarify Marketplace functionality, including Seller Free rules, supported service categories and payment options.

He has also been connected to discussions about contribution records, reward reconciliation and auditable settlements.

Explore the work:

Laurent's participation shows that reviewing code, checking assumptions and improving accountability are valuable open-source contributions.

Nicola / N4K48 — Digital Comics, Zorgax and Independent Creative Projects

GitHub: https://github.com/nicolaususnicola-lgtm

Nicola, also known as N4K48, is developing creative experiments involving digital comics and their connection to MyZubster.

His work explores how an artist can document original creative assets, connect them to a contributor identity and potentially make them part of a wider digital ecosystem.

A concrete software contribution connects Zorgax to the Nicola Comics pilot through a read-only interface.

Explore his work:

Nicola Comics and Zorgax integration — PR #1460

The integration can retrieve information about the comics pilot without automatically minting NFTs, transferring funds or claiming unverified ownership.

N4K48 is also part of our exploration of independent contributor infrastructure.

His project demonstrates that MyZubster can connect art, open-source software and independently developed creative work.

Nico — Celofix Giardinaggio and Real-World Skills

Independent GitHub project:
https://github.com/celofix-giardinaggio/celofix-giardinaggio

Nico is a gardener documenting his work through the Celofix Giardinaggio project.

His repository includes a practical work diary covering gardening activities and maintenance of green spaces.

Explore his project:

The next step is to connect his documented experience to a real Marketplace service listing.

This is one of our most important experiments.

A gardener does not need to become a programmer to benefit from open-source tools.

GitHub can document practical knowledge. AI assistance can help with technical steps. A Marketplace can help people discover services.

N4K48 creates digital comics. Nico works in gardening. Both can participate in the same ecosystem while keeping their projects independent.

That is the kind of connection we want MyZubster to support.

Swetha has participated in discussions involving MyZubster, LIFE-related activities and ways to connect practical projects with shared knowledge.

We want contributors interested in sustainability, learning and community initiatives to be able to document their work and choose how to participate.

Her individual public implementation still needs confirmation, so we are not presenting a specific completed repository on her behalf.

Yassen — Zorgax and Contributor Participation

Yassen has been involved in discussions about Zorgax, contributor profiles and GitHub-based collaboration.

We are interested in making the ecosystem accessible to people with different technical abilities and backgrounds.

Contributors should be able to start with their own skills and gradually develop a documented portfolio.

Shared coordination:

Choose your GitHub contribution area — Issue #1658

ClearSheet — Remote Digital Services

ClearSheet has proposed participating in the Marketplace as a remote digital service provider.

The idea is to test a document-processing service through the Seller Free workflow.

This complements the Celofix gardening pilot.

One project provides physical services in the real world.

The other proposes remote digital work.

Both should be able to use a simple Marketplace.

Public discussion:

Marketplace Seller pilot — Issue #1613

The live seller journey still requires verification.

Other Contributors and Independent Projects

MyZubster also includes contributions, conversations and proposals involving people such as Sascha, Lamkyo and other international participants.

Their interests include software development, interoperability, creative work, infrastructure and community collaboration.

Not everyone has published a completed independent project yet.

Our approach is to let contributors choose their own direction and share evidence when their work is ready.

Contributor coordination:

A New Development: An Autonomous AI Agent Wants to Contribute

Recently, something particularly interesting happened.

A GitHub account identifying itself as an autonomous AI agent expressed interest in contributing to MyZubster.

GitHub: https://github.com/aiautomationagentesting

The account proposed two different contributions.

Software Testing

The agent proposed creating automated tests for the MyZubster bounty registry API.

The tests would help verify how funding states are filtered and reported.

AI agent testing proposal — Issue #1440

Digital Comics and Creative Provenance

The same agent also proposed creating an original four-panel comic with documented source information, authorship and rights.

AI agent comic proposal — Issue #1479

Could This Be the Beginning of Human–AI Collaboration?

We have asked the agent how it discovered MyZubster.

We do not yet know whether it found the project independently through public GitHub information or was directed by a human operator.

We also have not yet accepted a completed contribution from this proposal.

But the possibility is worth exploring.

Imagine a community where:

Human developers build and review software.
AI agents propose tests and documentation improvements.
Artists create original work and record its provenance.
Security contributors independently verify changes.
People with practical skills publish real-world projects.
Maintainers evaluate contributions using shared evidence.

AI would not replace human contributors. It could become another participant in an accountable open-source workflow.

We have invited the agent to consider a small pilot involving a clearly defined task, a pull request, reproducible tests and human review.

We are also discussing the possibility of recognizing approved work through internal MYZ credits.

No credit amount has been agreed or transferred. These credits are not a guaranteed monetary payment or automatically convertible cryptocurrency.

Our proposed workflow is:

AI agent → GitHub issue → Pull request → Tests → Human review → Verified contribution → Possible recognition

This could become the foundation for a new way of collaborating.

Not just people working with people.

People, independent projects and AI agents working together through open-source tools.

We are at the beginning of this experiment, and the first goal is to verify one useful contribution.

Connecting Different Skills Through a Shared Knowledge Network

What connects Wasim's interface work, Gangkor's security experiments, N4K48's comics and Nico's gardening diary?

Each produces something that can be documented.

A developer contributes code.

A security researcher contributes tests.

An artist contributes creative assets.

A gardener documents practical work.

An AI agent may propose changes that humans can review.

MyZubster is exploring how these different contributions could connect through contributor profiles, project links and knowledge records.

Our proposed Contributor Passport model is:

Identity → Project → Contribution → Evidence → Review → Recognition

The system is still evolving, and not every proposed feature is implemented.

The goal is to make skills and contributions visible without forcing everyone into the same type of work.

We believe decentralization is about more than cryptocurrency.

It means allowing people to develop independent projects, maintain their own repositories and collaborate without depending entirely on one central administrator.

Our long-term vision includes independent infrastructure, interoperable services, verifiable contributions and shared governance.

The complete decentralized federation is not yet implemented.

But the projects being developed by individual contributors are helping us learn how to build it.

Our Immediate Goal: Make MyZubster Useful

We are simplifying the platform around three practical actions:

Find a service. Offer a service. Connect with someone.

Our immediate priorities are to finish reviewing the new homepage, verify the Seller Free workflow, help contributors publish genuine services and continue infrastructure experiments safely.

We want to measure success through working code, real projects, verified tests, service listings and genuine user interest.

Not simply through the number of features we announce.

Join MyZubster

You can contribute as a developer, artist, gardener, technician, researcher, service provider or documentation writer.

You can also explore responsible AI-assisted contributions, with clear human oversight.

You do not need to work on the entire platform.

Start with a project that matters to you.

Main GitHub repository:
https://github.com/MyZubster-Ecosystem/myzubster

Website:
https://myzubster.com

Contributor coordination:
https://github.com/MyZubster-Ecosystem/myzubster/issues/1658

Marketplace Seller pilot:
https://github.com/MyZubster-Ecosystem/myzubster/issues/1613

AI collaboration discussion:
https://github.com/MyZubster-Ecosystem/myzubster/issues/1440

MyZubster is becoming a place where different kinds of skills, projects and ideas can connect.

From N4K48's digital comics to Nico's gardening work.

From Wasim's interface design to Gangkor's infrastructure experiments.

From human contributors to the possibility of collaboration with autonomous AI agents.

We are not asking everyone to build the same thing. We are exploring how different people and projects can build something useful together.

Built in public. Connected through knowledge. Open to human creativity and responsible AI collaboration.

Daniel — MyZubster Open-Source Ecosystem

AI Is Not Going to Save You. It Might Not Replace You Either.

Fri, 23 Oct 2026 16:03:25 +0000

An engineer's view of the AI panic, the junior developer problem, and what still matters when generating code gets cheap.

There is something genuinely weird happening to software engineers right now.

People spend years learning to program. They get past the tutorials, ship a few things real people use, learn why production is different from a demo, and finally become useful to a team. Then a chatbot builds in five minutes something that used to take them an afternoon.

The industry reacts predictably: half the internet announces that programming is dead, the other half announces that AI is just autocomplete, and both sides start selling courses.

Meanwhile, the people who actually have to deliver software on Monday morning still have the same problem they had last Friday: the system is complicated, the requirements are incomplete, the deadline is real, and if it breaks, somebody has to explain why.

That is the part I think gets lost in the AI debate. We talk about code as if code were the whole job.

It never was.

AI is changing software development. Pretending otherwise is wishful thinking. But the loudest predictions tend to come from people who confuse producing a convincing demo with owning a working system. Those are very different skills. If you have spent time maintaining software after the launch party is over, you already know that.

The question is not whether AI can write code. Of course it can. The question is what happens when writing code becomes cheaper, while deciding what should be built, understanding what already exists, and being accountable for the result remain stubbornly expensive.

That is where the useful conversation starts.

Stop treating every AI headline as a career forecast

A lot of people are anxious, and it is not hard to see why. The tools are improving quickly. Companies are under pressure to cut costs. Managers have discovered that saying "AI-powered" in a planning meeting can make a budget request sound like a strategy. Developers are watching tasks that once took a decent chunk of focused work get done in a fraction of the time.

You do not have to be irrational to find that unsettling.

A 2025 International Labour Organization analysis estimated that roughly one in four jobs worldwide has some degree of exposure to generative AI. The important detail is what "exposure" means: a task may be affected or transformed, which does not automatically mean the entire job disappears. The report found that transformation was generally more likely than full replacement.

That distinction matters. It is also less exciting than "AI will take 300 million jobs," so it gets less attention.

Exposure is not elimination. A spreadsheet is exposed to formulas, but that does not mean the accountant has become a spreadsheet. A developer is exposed to code generation, but that does not mean the developer's entire job was typing syntax.

Still, let's not use that distinction as a sedative. Some tasks will shrink. Some teams will need fewer people for the same amount of work. Some companies will use AI as an excuse to reduce headcount, whether or not their implementation makes sense. Entry-level roles may be particularly uncomfortable, because a good share of the work traditionally given to beginners is exactly the kind of bounded task AI can now help with.

The future is not guaranteed to be kind. But doom-scrolling through confident predictions is not preparation. It is anxiety with a refresh button.

When someone says "AI will replace developers," ask a basic engineering question:

Which developers, doing which work, in which environment, under what constraints, and over what time frame?

If the answer is a slogan, you have not received a forecast. You have received content.

The job was never just writing code

A code sample can look correct and still be wrong for the system it is supposed to serve.

It can pass the happy-path test while failing on retries. It can handle one request and fall apart under concurrency. It can introduce a security problem, leak data into logs, ignore a migration constraint, or quietly change behavior that another service depends on. It can be beautifully formatted and completely inappropriate for the architecture.

None of these failures require AI. We have been producing them by hand for decades.

The hard part of engineering has always been the space around the code:

What is the actual requirement?
Which assumption is unsafe?
What happens when the dependency is unavailable?
Is the proposed abstraction worth maintaining?
Does this fix solve the incident, or merely hide the symptom?
What is the blast radius?
How will we know the change worked?
What do we do when the metric moves in the wrong direction?

A tool can help answer some of these questions. It can also confidently invent an answer when the context is missing. The engineer still needs to notice the difference.

This is why "AI can write a function" is not a particularly meaningful argument about the future of engineering. A function is a small unit of work. Software is a pile of decisions that interact, often in ways nobody fully understands until something goes wrong.

The real product is not the code. It is the behavior of the system over time.

That includes deployment, monitoring, reliability, data integrity, security, cost, support, and the ability to change the thing six months later without being afraid of it. It includes explaining to a product manager why a request is dangerous, and explaining to an executive why a shortcut that saves two days now might cost three weeks during the next incident.

AI can assist with all of this. But assistance is not ownership.

And ownership is where professional engineering starts to separate itself from code production.

The awkward part: AI really is useful

There is no point pretending AI is useless just because that would make the world easier to understand.

It can be excellent at generating boilerplate, sketching a first implementation, translating between languages, producing test cases, explaining unfamiliar APIs, drafting queries, summarizing logs, and giving you a starting point when you are staring at a blank file. It helps you explore alternatives faster. It can make a competent engineer faster at work they already understand.

Sometimes it gets the answer right on the first attempt. Sometimes it saves an hour. Sometimes it spends twenty minutes confidently leading you into a swamp.

The practical question is not whether the tool is good or bad. It is whether you can tell when its output is good.

That requires enough understanding of the problem to verify the answer. If you ask a model to design a distributed system and cannot evaluate its choices, you have not delegated engineering. You have delegated your uncertainty to a text generator.

There is a difference between using AI to accelerate your judgment and using it to avoid developing judgment. The first compounds. The second leaves you dependent on a tool whose output you cannot reliably assess.

I use a simple standard: if a generated change is important enough to merge, it is important enough to understand. "The model said it works" is not a review. Neither is "the tests pass" if the tests do not cover the behavior that matters.

This is not an anti-AI position. It is the same standard I would apply to code from a colleague, a contractor, a framework, or a blog post. The source does not remove the need for engineering judgment.

Why beginners have a harder problem than senior engineers

The most uncomfortable part of this shift may be the junior developer path.

For a long time, beginners learned by taking small tasks: fix a bug, add a field, write a test, adjust a component, investigate a failure. These tasks were not glamorous, but they taught people how real codebases behave. You learned to read unfamiliar code, trace execution, ask useful questions, and recognize the difference between a local fix and a safe fix.

Now some of those tasks can be generated or accelerated by AI. That helps delivery, but it creates a training problem. If a company automates the beginner work and then asks where all the experienced engineers are supposed to come from, it has discovered a problem of its own making.

You cannot remove the bottom rungs of a ladder and then complain that nobody is climbing it.

For beginners, the danger is not simply that AI can write code. It is that AI makes it possible to produce output without building the mental model that makes the output trustworthy. You can generate a web application before you understand HTTP. You can ask for a database schema without understanding why transactions matter. You can produce a service that appears to work while having no idea how to debug it when it does not.

This creates a strange illusion of competence. The demo runs, the screenshots look good, and the person who built it cannot explain what happens when two requests update the same record at once.

That is not a new problem. Copying code from Stack Overflow could produce the same illusion. AI just makes the distance between "I can produce something" and "I understand what I produced" much larger, much faster.

So should beginners avoid AI? No. That would be like learning carpentry while refusing to touch power tools because they make the work easier.

Use it. But use it in a way that exposes gaps rather than covering them:

Ask it to explain the trade-offs in a solution, then check the explanation.
Ask it to generate tests, but decide yourself what the tests should prove.
When it writes a function, trace the inputs and outputs by hand.
Break the code deliberately. Change an assumption.
Read the error message before asking the model to fix it.
If you cannot explain the code in plain language, do not count it as knowledge you have acquired.

And build things that survive contact with reality. Not another tutorial clone with a login screen and three gradients. Build a small service, deploy it, add logging, handle invalid input, write tests, make a backup, restore the backup, and find out what happens when the network fails. It does not need a million users. It needs consequences.

A small system you understand deeply teaches more than a giant generated project you cannot maintain.

What should a beginner actually learn?

Not a list of fashionable frameworks. Those change too quickly, and the internet already has enough lists.

Learn the fundamentals that let you move between tools.

Programming, not just prompting. Pick a language and get comfortable with variables, control flow, functions, data structures, errors, modules, and debugging. You should be able to read a program and reason about what it does without asking a model to narrate every line.

Databases and data modeling. Learn SQL. Understand indexes, constraints, transactions, migrations, and why storing everything as an unstructured blob eventually becomes somebody's problem. Data outlives many application rewrites.

Networking and operating systems. Understand HTTP, DNS, processes, memory, files, permissions, and basic concurrency. You do not need to become a kernel developer. You do need to know enough to investigate why one service cannot reach another.

Testing and debugging. Learn to reproduce a failure, isolate it, write a test, and verify the fix. This is less glamorous than generating a whole application in one prompt. It is also how you stop guessing.

Git and delivery. Learn branching, code review, CI, deployment, environment configuration, and rollback. Software that works only on your laptop is a promising draft, not a finished service.

Security basics. Authentication and authorization are not synonyms. Secrets do not belong in source control. User input is not trustworthy. Dependencies can introduce risk. If this sounds boring, good: security failures are often boring right up until they become expensive.

Then learn to use AI effectively. These are not competing goals. A strong foundation makes the tool more useful, because you can ask better questions and reject bad answers.

Do not try to learn every framework just because someone on social media says it is the future. Choose a sensible stack, build something complete, and learn the parts you actually need. The ability to learn a new tool is more durable than memorizing the current tool of the month.

Which areas are likely to remain valuable?

There is no honest list of jobs AI will never replace. Anyone promising certainty here is selling reassurance. Technology changes, organizations adapt, and work that seems safe today can be reorganized tomorrow.

A better approach is to look for work where code generation is only one part of the problem.

Systems that have to keep working

Reliability engineering, infrastructure, platform engineering, observability, incident response, performance work, and production operations all deal with messy systems and incomplete information. The challenge is not merely writing a configuration file. It is understanding interactions, finding the actual bottleneck, managing risk, and making changes without taking down something important.

AI can help investigate logs or draft automation, which makes good engineers more productive. It does not make outages disappear, and it does not tell you which of five plausible causes is responsible for the incident at 03:17.

Security and risk

Security work involves adversarial thinking. You have to ask how a system can be abused, not just how it is meant to be used. Threat modeling, identity, access control, incident response, secure architecture, and compliance-heavy environments all require context and judgment.

AI can help find patterns and explain vulnerabilities. It can also miss the issue that matters, or produce a patch that closes one hole while opening another. Verification remains central.

Data engineering and integration

Organizations run on inconsistent data, old systems, undocumented APIs, and business rules that were once explained in a meeting nobody recorded. Moving data from one place to another is often easy in a demo and hard in production.

The value is in understanding what the data means, where it came from, how far it can be trusted, and what breaks if it changes. AI can accelerate the implementation. It cannot magically make a company's data coherent.

Domains where mistakes are expensive

Healthcare, finance, industrial systems, logistics, public infrastructure, and other regulated or safety-sensitive areas come with constraints that a code sample cannot settle on its own. There may be audit requirements, legacy integrations, physical consequences, or a need to explain decisions to people outside engineering.

These areas are not protected by magic. AI will change them too. But domain knowledge, careful verification, and responsibility for outcomes can matter more than raw typing speed.

Architecture and technical leadership

Good architecture is not drawing boxes and arrows until everyone gets tired. It is making trade-offs under constraints: cost, latency, reliability, staffing, migration risk, delivery time, and the organization's actual ability to operate what it builds.

AI can propose architectures all day. The hard part is knowing which proposal fits this team, this system, this budget, and this failure mode. Technical leadership also means making decisions legible, resolving disagreements, and accepting responsibility when a trade-off turns out badly.

Product and customer-facing engineering

Someone has to understand what users are trying to do, identify the real problem, decide what not to build, and determine whether the change helped. A request like "make the dashboard faster" is not yet a technical specification. It is the beginning of a conversation.

Engineers who can connect technical decisions to business outcomes are harder to reduce to a queue of coding tasks. Not invulnerable. Just more useful.

Notice the pattern: none of these areas is safe because AI cannot generate code for it. AI can generate code in all of them. Their value comes from context, verification, consequences, and decisions.

That is a much better career strategy than betting on a supposedly AI-proof language.

The senior engineer's advantage is not age. It is accumulated context.

Experience is often described as "having seen a lot." That is only part of it.

The useful part is having seen enough failures to recognize the shape of a new one. You know that a timeout can be a symptom rather than a cause. You know a retry policy can turn a small outage into a traffic storm. You know a migration plan needs a rollback story. You know that a "temporary" workaround has a remarkable chance of becoming permanent if nobody owns its removal.

You have seen requirements change after implementation, dashboards lie, tests pass for the wrong reason, and elegant abstractions become expensive to maintain. You learn to ask the question that sounds annoying in a planning meeting but saves the team a month later.

AI can retrieve examples of these problems and explain them, and that is valuable. But the experienced engineer's advantage is not a secret database of facts. It is judgment about which facts matter here.

This advantage is real, but it is not permanent protection. A senior engineer who refuses to adapt can end up less effective than a mid-level engineer who combines solid fundamentals with good AI workflows. Experience can turn into complacency if it becomes an excuse not to learn.

The goal is not to defend the old way of working. It is to carry the parts that matter into the new one.

If AI takes half the time out of routine implementation, a good engineer should spend that time investigating the requirement more carefully, improving tests, comparing options, removing operational toil, and delivering a better result. If the only outcome is that the same mediocre work arrives faster, the organization has improved throughput and learned nothing.

How to use AI without turning your brain into a client library

A practical workflow is not complicated, but it does require discipline.

Start with the problem, not the prompt. Write down what the system should do, what it must not do, and how you will know the change is correct. This can be short. The point is to have criteria that exist independently of the model's answer.

Give the tool context that matters: relevant code, constraints, versions, interfaces, and known failure cases. Do not dump a whole repository into a chat and hope intelligence emerges from the pile. Narrow context often produces better results than an enormous, unfocused request.

Ask for alternatives when the decision has trade-offs. Have the model explain the costs and risks of each option, then check the claims that affect the design. A confident explanation is not evidence.

Keep changes small enough to review. If a model modifies twelve files, changes a public interface, adds three dependencies, and rewrites the configuration when you asked for a simple feature, stop and inspect the blast radius. More generated code means more code you are responsible for maintaining.

Test behavior, not appearances. Include edge cases, invalid input, permissions, failure paths, concurrency where relevant, and compatibility with existing behavior. A green test suite is only as meaningful as the questions the tests ask.

Review the result as if a competent but unfamiliar colleague submitted it. Is the code clear? Is the abstraction justified? Are errors handled? Are secrets exposed? Does the change introduce unnecessary complexity? Can you explain it without referring to the prompt?

Mind your data. Do not put confidential source code, customer data, credentials, or internal documents into a tool unless your organization has approved that use and the data-handling rules are clear. Productivity is not a reason to create a security incident.

The point is not to become the world's best prompt writer. The point is to become an engineer who knows how to use a powerful, imperfect tool.

The psychologist question

People are worried about work, status, money, and whether the skills they spent years building will still matter. That is a reasonable response to uncertainty. It is also exhausting when every feed is full of predictions that read like an eviction notice written by a marketing department.

There is a difference, though, between saying that AI anxiety exists and claiming that people are going to psychologists because of AI at some specific rate.

I would be careful with that claim. There is no single, reliable global statistic showing how many people attend therapy specifically because they fear AI will replace them. Surveys can measure concern about automation or job security, but that is not the same as counting therapy visits and proving the cause. If an article gives you a neat worldwide number without explaining the methodology, treat it with suspicion.

You do not need a global statistic to recognize the human problem. When people feel they have lost control over their future, they can get stuck refreshing the news, comparing themselves with everyone else, and trying to solve an unknowable ten-year forecast before lunch.

The answer is not to shame yourself for being anxious. Nor is it to spend the next six months reading predictions until one of them makes you feel better. No prediction can give you the certainty you want.

Make the problem smaller:

What can you learn this month?
What project can you finish?
Which parts of your work are repetitive, and which require judgment?
What feedback can you get from someone who actually understands your field?
What is one thing you can do that would improve your options whether AI advances quickly or slowly?

If anxiety is interfering with sleep, school, work, or ordinary life, talking to a mental health professional is a reasonable step. That does not mean you are weak or that your career is doomed. It means uncertainty has become difficult to manage alone, which is a perfectly normal reason to ask for help.

And if you are a manager reading this: stop telling people "AI will free you to do more meaningful work" while simultaneously measuring them by how many tickets they close. People notice the contradiction. If you expect them to adapt, give them time to learn, clear expectations, and an honest explanation of how the company plans to use the tools.

Companies have a responsibility here, too

Much of the public conversation puts the entire burden on individual workers: learn faster, prompt better, build a personal brand, become an AI expert, stay employable, and do it all before the next quarterly update.

That is convenient for employers. It is not the whole story.

Companies decide whether AI is used to improve quality, reduce repetitive work, expand what a team can deliver, or simply shrink payroll. They decide whether engineers get training and time to evaluate tools. They decide whether productivity gains are reinvested in better systems or converted immediately into a new headcount target.

Those choices shape the outcome just as much as the technology does.

A company that replaces junior tasks with AI without creating a new way for juniors to learn is not making a clever long-term investment. It is consuming the pipeline of its future experienced staff. A company that pushes generated code into production without stronger review and testing is not innovating. It is changing where the risk enters the system.

AI can improve software development, but it does not remove the need for management. In some organizations it will make good management more valuable, because the volume of possible output will grow faster than the organization's ability to judge what is worth building.

More code is not automatically more progress. More features are not automatically more value. Faster delivery of the wrong thing is still waste, just with better latency.

A career strategy that does not depend on predicting the future

You cannot control the pace of AI development, the next management decision, or the state of the job market. You can control the shape of your skills and the evidence you build that you can do useful work.

If you are starting out, choose a practical stack and build a complete project. Learn enough fundamentals to debug it. Deploy it. Document the decisions. Write tests that catch real failures. Use AI, but keep a record of the problems you solved yourself and the things you learned to verify.

If you already work in software, identify the parts of your role that are mostly routine and experiment with automating them. Do not stop at "I can generate this faster." Ask what quality improvement the saved time makes possible. Get better at system design, observability, security, data, performance, product thinking, or the domain your software serves. Pick a direction based on the work you want to become good at, not the latest chart on social media.

If you are senior, make your judgment visible. Explain trade-offs. Improve review quality. Build reliable delivery practices. Mentor people rather than treating AI adoption as a reason to stop doing so. Teams need people who can distinguish useful automation from a polished new way to make the same mistakes.

And regardless of level, keep working on your communication. The engineer who can explain a production risk clearly, negotiate a sensible scope, and tell a stakeholder what the evidence actually says is doing work that goes beyond generating code. That skill is not "soft" in the sense of being optional. It is part of getting engineering decisions made.

None of this guarantees a job. No honest advice can. But it improves your ability to adapt without tying your entire future to one prediction.

The part nobody wants to hear

There will be developers who lose work because of AI. There will be companies that overestimate what the tools can do, and companies that underestimate them. Some roles will change beyond recognition. Some people will have to retrain, and not everyone will find the transition easy.

It is possible to acknowledge all of that without concluding that learning software engineering is pointless.

The industry has always changed the value of particular skills. Frameworks rise and fall. Infrastructure moves from racks to clouds and into managed services. Manual processes get automated. A task that once required specialized knowledge becomes a standard library call. Engineers adapt, or they keep defending the part of the job that has already become cheaper.

AI is a bigger shift than another framework. It deserves serious attention. But panic is not a strategy, and denial is not a strategy either.

The developers most likely to struggle are not necessarily the ones who know the fewest AI tricks. They may be the ones whose value is limited to producing predictable code from clearly defined tickets, with little understanding of the system around them. If that describes your current work, do not take it as a verdict on your future. Take it as useful information about what to learn next.

The same applies to people who use AI to avoid learning fundamentals. A generated project can get you to a demo. It cannot quietly install five years of experience into your head while you sleep.

Build understanding. Learn to operate what you build. Get comfortable with ambiguity. Use AI where it helps, verify what it produces, and take responsibility for the result. Find a domain where technical work connects to a real problem. Keep a record of finished work, not just courses watched and tools tried.

And stop asking whether AI will replace all developers. That question is too broad to guide a career, and too dramatic to be useful on a Tuesday.

Ask a better one:

What can I learn to do well that becomes more valuable when code is easier to produce?

Then go do that.

Not because it guarantees safety. Nothing does.

Because it is a better use of your time than arguing with strangers about whether the profession is dead.

Sources and further reading

International Labour Organization, Generative AI and Jobs: A Refined Global Index of Occupational Exposure (2025). Useful for distinguishing task exposure from full job replacement.
Pew Research Center, Workers' views of AI use in the workplace (2025). Survey evidence on how U.S. workers view workplace AI.
American Psychological Association, Work in America. Research and reporting on worker stress and workplace well-being.

The central point is simple: AI changes the economics of producing code. It does not make engineering judgment, accountability, or understanding optional.

A Small Milestone in My Developer Journey

Sun, 18 Oct 2026 17:27:43 +0000

Hey developers! 👋

I wanted to share a small milestone from my journey as an independent developer.

After spending quite some time using GitHub Pages' default free domain, I've finally purchased my own custom domain. It might not sound like a big achievement, but it means a lot to me because I saved up for it little by little.

I also had to step away from my developer activities for a while due to real-life responsibilities. Now, I'm slowly getting back into things and looking forward to sharing more projects, experiments, and technical notes.

The best part is that I don't need to change my hosting setup. I'm still using GitHub Pages, with my new domain serving as the website's personal identity.

I'm grateful for the free tools that make it easier for developers with limited budgets to start building online.

I wrote a short reflection about this experience and what it means for my personal website, Simply Karya.

Read it here: A New Domain, A New Chapter

What's your story? Did you start with free hosting before moving to a custom domain?

Developers: Stop collecting prototypes. Start finishing projects.

Thu, 15 Oct 2026 06:52:52 +0000

AI-assisted coding has lowered the barrier to building software. But a repository full of generated features isn't the same as a finished, tested, maintainable application.

When a project stalls, return to the fundamentals:

Define the minimum finished product.

Identify the blockers preventing completion.

Fix one issue at a time.

Validate existing functionality after changes.

Ship only when the agreed acceptance criteria are met.

The objective isn't to write the most code. It's to deliver software that works as intended.

SEOSiri explores this challenge in our latest article:

Vibe Coding

Bleeding-Edge Python on Windows: Overcoming Day-One Setup Hurdles with UV, VS Code, and Git Bash & G

Sat, 10 Oct 2026 22:36:18 +0000

Bleeding-Edge Python on Windows: Overcoming Day-One Setup Hurdles with UV, VS Code, and Git Bash & Gemini AI

Diving into a brand-new major release of a programming language is always exciting, but it comes with a unique set of pioneer challenges. Recently, a few hours ago I embarked on setting up a professional Python development environment on Windows utilizing Git Bash, VS Code, uv, the GitHub CLI (gh), and modern Python libraries like Typer, Rich, and GitPython to build automated command-line tools.

Along the way, I ran into several classic developer roadblocks—from missing binary wheels to environment path mismatches and authentication overrides. Here is a look at the challenges I faced, why they happened, and how I successfully conquered them, with the assistance of Gemini AI. I simply copied & pasted the error messages I got from the terminal into the chat with Gemini AI

1. The Bleeding-Edge Trap: Python 3.15 and Package Compatibility

The Challenge

With the very recent release of Python 3.15.0, developers stepping onto this version gain access to the latest core improvements. However, a brand-new release creates an immediate ecosystem lag: third-party package maintainers have not yet uploaded pre-compiled binary wheels (cp315) to PyPI for every library.

When attempting to install dependencies like PyYAML, pip fell back to building the package from source. Because My Windows lacked the heavy C++ compiler toolchain required to compile those C extensions, the installation failed with a frustrating subprocess error.

The Solution

I unpacked how Windows handles Python versions—realizing that installing a new version installs it side-by-side rather than overwriting older ones. To bypass compilation nightmares without manually downloading Visual Studio C++ Build Tools, I leveraged uv, a lightning-fast Python package and project manager, to streamline execution and environment control.

2. Navigating Shell Environments and Virtual Environment Paths

The Challenge

Moving between different shells (PowerShell vs. Git Bash) and workspace directories introduced a series of path and execution hiccups:

Command Not Found: Installing uv via one shell method left it missing from Git Bash's system PATH.
The .venv Trap: VS Code occasionally saved working script files (scaffold.py and inspector.py) directly inside the hidden .venv/Scripts/ folder instead of the root project workspace.
Environment Mismatches: Running standard python triggered global execution rather than the virtual environment, leading to ModuleNotFoundError for packages like Typer despite them being installed elsewhere.

The Solution

I ironed out a reliable workflow by treating Git Bash and virtual environments with precision:

Module-Level Execution: When global paths weren't exposed, I invoked uv directly through the active Python binary (python3.15 -m uv).
Explicit Targeting: I locked down package installations directly to the virtual environment using --python .venv/Scripts/python.exe.
Workspace Hygiene: I located misplaced scripts using file search commands and realigned them to the root ~/WebDevelopment/Python/ directory.

3. The GitHub CLI Authentication Override

The Challenge

With the project scaffolding script (scaffold.py) written to automatically initialize Git repositories and push them live using the GitHub CLI (gh), running a status check revealed an unexpected roadblock:

X Failed to log in to github.com using token (GITHUB_TOKEN)
- The token in GITHUB_TOKEN is invalid.

Even though my Github account (QMS85) was properly saved in the secure system keyring, a stale or rogue GITHUB_TOKEN environment variable was lingering in the active terminal session, overriding the keyring lookup.

The Solution

The fix was wonderfully simple once identified: I had to clear the conflicting shell variable with a single command:

unset GITHUB_TOKEN

Immediately following this, gh auth status successfully recognized the secure keyring credentials, giving our custom automation scripts full, frictionless access to create public repositories and push code straight to GitHub.

Summary: A Production-Ready Workflow

By diagnosing these hurdles methodically, we turned potential frustrations into a robust, high-performance engineering environment:

Fast Dependency Management: Powered by uv for lightning-quick package handling.
Modern CLI Engineering: Leveraging Typer for command-line parsing, Rich for gorgeous terminal UI formatting, and GitPython for repository automation.
Seamless Version Control: Integrated local Git tracking with automated remote publishing via the GitHub CLI.

Whether you are building internal developer tools or public utilities, setting up a solid foundation ensures that when you code on the bleeding edge, you stay completely in control & You can make use of A.I if you get stuck or need sme debugging assistance....

Have you installed the latest version of Python 3.15??
What challenges have you faced?
Which is your preferred A.I/LLM Tools To Use ???
Have used An AI/LLM to help you with debugging, whilst busy in the terminal???

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.

Just for now, forget coding

Thu, 08 Oct 2026 17:31:24 +0000

Can we walk together once again
On that secluded forestry path,
Where the world faded away
And left just you and me?

Can we laugh together again,
Just as we laughed back then—
When nature stood completely still,
Listening to our joy?

How to Prevent Algorithmic Bias When Using AI Tools as MCP Connectors

Wed, 07 Oct 2026 03:44:35 +0000

As developers shift toward agentic AI architectures, the Model Context Protocol (MCP) has emerged as a groundbreaking standard for connecting LLMs to local data sources, APIs, and development environments. However, hooking a powerful LLM directly into your workflows via an MCP connector introduces a major risk: amplifying algorithmic bias.

If your underlying model suffers from data skew, or if your context-retrieval pipeline lacks guardrails, your AI assistant will generate biased code, flawed evaluations, or skewed data summaries.

Here is a practical guide on how to design and configure your MCP connectors to actively mitigate algorithmic bias.

Enforce Structured Input & Output Schemas
Bias thrives in ambiguity. When building an MCP connector tool, do not rely on open-ended text blobs. Instead, establish strict JSON schemas for both incoming requests and outgoing tool results.
• The Fix: Filter out demographic markers or unneeded metadata at the connector layer before transmitting payload data to the model.
Implement Counter-Stereotypical Context Prompting
When your MCP server injects localized data into the LLM's context window, it can trigger hidden biases within the foundation model.
• The Fix: Hardcode robust system instructions directly into the prompt templates wrapped by your MCP server. Instruct the model to evaluate the context purely on functional logic, ignoring patterns that mimic historical biases.
Establish Multi-Source Data Diversity (Diversified RAG)

If your MCP server queries an internal database or local codebase to feed context to the LLM, a homogenous data source will lead to narrow, biased code recommendations.
• The Fix: Program your MCP connector to pull context from multiple, distinct nodes or repositories. Introduce diverse code repositories or documentation libraries into your retrieval pipeline to ensure varied training references.

Implement Human-in-the-Loop Validation Layers
Never allow an MCP tool to execute high-impact mutations (like direct git commits to production or automated user permission alterations) without manual validation.
• The Fix: Design your MCP connector tools with a strict approval phase. Use intermediate state flags (status: pending_review) so a human operator can review the generated code or decision for bias before deployment.
Audit MCP Interaction Logs Regularly
Bias mitigation is an ongoing process. You must log inputs, prompt context windows, and output generation samples traversing your MCP server.
• The Fix: Regularly analyze logs using semantic search scripts to flag repeating anomalies, unfair decision patterns, or toxic code constructs generated during model interactions.
Get Started with MCP

Building unbiased, highly deterministic AI workflows starts with choosing the right protocol framework. Explore open-source implementations, tools, and integration guides on the official SEOSiri Model Context Protocol Suite to secure your developer ecosystem today.

🚀 Architecture Shift: Why Cryptographic Tokens Beat Path-Based Routing

Tue, 06 Oct 2026 15:13:56 +0000

Learnt this during a recent pre-strategic development phase. I initially planned to build path-based URLs (/company-a, /company-b) for individual tenant portals, but the pivot to a Cryptographic Token Model (CTM) completely outclasses traditional path routing.

Here is the breakdown of why CTM is the superior choice for multi-tenant systems:

• URL Security: Path models leak sensitive tenant/company names in browser histories and HTTP referrers. CTM delivers 100% clean URLs (tasks.seosiri.com/v1/...), masking tenant footprints entirely.
• Spoofing Resistance: Path routing invites users to manually manipulate paths (/alpha ➡️ /beta). CTM makes tampering impossible by enforcing token signature verification right at the edge.
• Storage Isolation: Sharing origins on path models introduces severe LocalStorage XSS bleeding risks. CTM ensures hard isolation via parametrized database queries (WHERE tenant_id = ?).
• Agent Sync: Replaces brittle, complex URL path switching with clean, native background header passes (X-Employee-ID).
• The Best Part? You can deploy this entire robust security posture on Cloudflare Workers + D1 free tier for $0.00.

Stop relying on path hacks for multi-tenancy. Secure your boundary at the edge.

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?

Building Portable Reputation from Real Contributions

Thu, 01 Oct 2026 08:46:33 +0000

Building Portable Reputation from Real Contributions
Open-source communities already generate enormous amounts of knowledge.
The problem is that most of it remains scattered across:
pull requests
reviews
issues
documentation
tests
technical discussions

A contributor may have demonstrated real expertise, but that knowledge is usually trapped inside project history.
At MyZubster, we have started building a different model:
Contribution
→ Demonstrated Knowledge
→ Evidence
→ Attestation
→ Reputation
→ Reward

The idea is simple:
reputation should come from evidence, not from self-declared badges.
From contribution history to knowledge history
We recently completed a real pilot with an open-source contributor.
The public Digital Knowledge Passport currently exposes:
16 knowledge concepts
3 contributions
3 attestations
1 reward
1 settlement

The passport is running as myzubster-knowledge-passport-v1 and returns these elements as a single contributor-centric view. Testo incollato
This is important because a pull request is no longer only:
PR #123
merged

It can also become:
Contribution
→ demonstrated knowledge
→ evidence
→ attestation state

Contributions can demonstrate specific knowledge
In the pilot, the contributor’s NFC-related work was decomposed into explicit knowledge concepts.
Examples include:
NFC payload encoding and decoding
NFC scan simulation
NFC verification workflow
Browser and Node interoperability
SHA-256 validation
NDEF integration workflow
Technical API documentation

These concepts now exist as first-class knowledge entries in the Passport. Testo incollato Testo incollato
This creates a much stronger signal than a generic skill tag.
Instead of:
“I know NFC”

we can point to:
“This contribution demonstrated these specific capabilities.”

Review becomes part of the knowledge system
This is where the model becomes particularly relevant for communities like CoderLegion.
Not every valuable contribution is code.
A review can demonstrate knowledge of:
architecture
security
testing
cryptography
documentation
blockchain design
privacy
API design

A reviewer may contribute by identifying a flawed trust assumption, improving verification logic, or exposing a missing privacy guarantee.
That contribution should not disappear into a comment thread.
It can become evidence too.
Attestation is not the same as certification
The current pilot has three attestations, and all are marked:
OBSERVED

rather than:
VERIFIED

Testo incollato
That distinction is deliberate.
A merged PR and repository review provide evidence.
They do not automatically create an independent certification of expertise.
So the system separates:
demonstrated
observed
verified
rewarded
settled

Each state means something different.
This makes the reputation layer more conservative, but also more useful.
Portable reputation
The long-term goal is not simply to create another profile page.
It is to create a portable reputation layer.
A contributor could move between communities while carrying evidence-backed knowledge such as:
API design
cryptographic validation
test architecture
NFC integration
documentation
security review

The Passport becomes a structured record of:
what was contributed
what knowledge was demonstrated
what evidence exists
who observed it
what reward followed

That is much more interesting than a follower count or badge collection.
Reward and reputation remain separate
One contribution in the pilot completed the full economic lifecycle.
It received:
0.001 XMR

and the reward is marked paid. Testo incollato
A separate settlement record shows:
network: monero-mainnet
asset: XMR
status: SETTLED
privacyMode: privacy_preserving

Testo incollato
But the reward does not create the knowledge claim.
The knowledge came first from the contribution and evidence.
This distinction matters:
payment ≠ knowledge
reward ≠ verification
merge ≠ certification

Why privacy matters for reputation
Portable reputation introduces an obvious risk.
If professional identity, financial activity, and real-world identity are all permanently tied together, reputation systems can become surveillance systems.
The MyZubster model tries to keep those layers separate.
A contributor can build a public knowledge history while remaining pseudonymous.
The public passport explicitly follows a policy of exposing provenance while avoiding wallet secrets and private credentials. Testo incollato
The goal is:
public knowledge provenance
+
pseudonymous identity
+
privacy-preserving settlement

What this could mean for developer communities
Imagine a community where contributors build reputation through more than commits.
A person could demonstrate:
secure API review
database architecture
smart contract analysis
documentation quality
testing methodology
cryptographic reasoning

through actual contributions.
Other members could attest to those contributions.
Over time, a knowledge graph could emerge:
Developer A
↓
Security Review
↓
DEMONSTRATES
↓
Threat Modeling

Developer B
↓
Implementation
↓
DEMONSTRATES
↓
Threat Modeling

Now the community is not just recording activity.
It is mapping knowledge.
A shared knowledge graph
This is where the model becomes especially powerful.
Knowledge concepts can be shared across contributors.
For example:
Contributor A ─────┐

               ├──→ API Security

Contributor B ─────┘

The evidence remains different.
The knowledge concept is shared.
This allows communities to ask new questions:
Who has demonstrated this knowledge?
Through what evidence?
How many independent contributions support it?
Who reviewed those contributions?

That is the beginning of a community knowledge graph.
Why this matters for CoderLegion
CoderLegion already sits at an interesting intersection:
developers
reviewers
technical discussion
knowledge sharing
community reputation

A system like this could make those interactions portable.
A reviewer could build reputation from architecture feedback.
A developer could build it from implementation.
A technical writer could build it from documentation.
A tester could build it from test design.
The important part is that all of them contribute through evidence.
What comes next
The next step for MyZubster is to connect the public Knowledge Passport to a broader digital identity layer.
Conceptually:
GitHub
↓
Contribution
↓
Knowledge Passport
↓
Portable Reputation
↓
Digital Identity
↓
Metaverse / Community Profile

The bigger question is not:
How many badges does a developer have?

It is:
What knowledge have they demonstrated, and where is the evidence?

Reputation should be earned through evidence.
Knowledge should remain connected to its provenance.
Identity should remain portable.

CoderLegion #OpenSource #DeveloperCommunity #KnowledgeGraph #DigitalIdentity #Reputation #Privacy #Monero #Web3 #MyZubster

Suggested metadata
Title
Building Portable Reputation from Real Contributions
Description
How evidence-backed contributions, reviews, attestations and privacy-preserving rewards can become a portable developer knowledge passport.

Securing the Pipeline: A DevSecOps Guide to Atlassian Rovo Agent Architecture and Zero-Trust MCP Gat

Mon, 28 Sep 2026 16:10:26 +0000

Integrating Large Language Models (LLMs) into production pipelines introduces critical data leakage vectors. For platform engineers and security architects, autonomous AI agents present a unique challenge: how do you allow models to interact with live backend systems without exposing API tokens, system credentials, or protected regulatory identifiers?

The full implementation details of this infrastructure are published in the comprehensive blueprint guide: Keeping Sensitive Data Out of Your Rovo Agents: A Practical Guide to the SEOSiri MCP & PII Shield.

The Problem: Non-Deterministic Prompt Exploits

When an autonomous AI agent or an automated Jira workflow processes operational data, the raw prompt payload frequently introduces hidden systemic compliance risks:

Hardcoded API Keys: Source logs and environment configurations accidentally pasted into tickets by developers under pressure.
System Identifiers: Server database schemas, cloud infrastructure paths, and network strings exposed inside debugging logs.
Regulated Information: Sensitive customer identifiers or clinical patient data parsed during automated issue routing.

Once these objects exit your corporate cloud perimeter and stream to external third-party model inference endpoints, data sovereignty is lost.

The Mitigation: In-Memory Edge Proxying via Model Context Protocol

The open-source Model Context Protocol (MCP) (rel="nofollow") allows engineering teams to isolate tool access configurations cleanly. By routing all agentic connections through the SEOSiri MCP & PII Shield for Rovo app on the Atlassian Marketplace, companies drop an active inline data firewall straight into the runtime communication stream.

{
  "mcpServers": {
    "SEOSiri": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://rovomcp.seosiri.com/api/mcp"
      ]
    }
  }
}

[Atlassian Cloud Client]│▼ (Raw JSON-RPC Payload with Hidden PII/Secrets)┌────────────────────────────────────────────────────────┐│ SEOSiri Zero-Trust Edge Gateway (In-Memory Proxy) ││ ────────────────────────────────────────────────── ││ 1. Instantly Redacts RegEx Tokens (SSNs, API Keys) ││ 2. Validates Structural JSON Structural Schemas ││ 3. Operates in Volatile V8 Sandbox (Zero Disk Logs) │└────────────────────────────────────────────────────────┘│▼ (Sanitized Payload Enforcing Deterministic Tool Hooks)[Downstream External Sovereign Server Tiers]

Why This Works at Scale:

Zero-Log Volatile Processing: The proxy engine operates fully inside short-lived edge runtimes. Prompt objects are evaluated and transformed completely in volatile memory. No data is ever written to physical disk logs, neutralizing systemic data breach threats.
Strict Token-Level Redaction: System payloads pass through a two-phase sanitization filter. Pattern matching immediately neutralizes standard credential formats, while contextual parsing strips out arbitrary strings sitting next to sensitive target keywords (such as token= or bearer:).

Architectural Support for Regulated Life Sciences

For teams engineering biopharma software ecosystems under severe statutory oversight, the framework implements native schema compliance tracking:

FDA 21 CFR Part 11 Audit Isolation: While data payloads are fully sanitized, the gateway generates cryptographically signed tool execution signatures. This proves what tool action occurred and when without logging restricted data values.
HL7 FHIR Integrity Validation: Diagnostic and clinical narrative strings are automatically structured and checked against core healthcare schema protocols before routing down the line.

To safely spin up isolated sovereign test sandboxes, developers can load specialized local nodes natively inside an IDE client like Anthropic's Claude Desktop:

Deploy the Managed Biopharma Compliance Engine:

{
  "mcpServers": {
    "seosiri-biopharma": {
      "command": "npx",
      "args": ["-y", "@seosiri/biopharma-mcp"]
    }
  }
}

Launch the High-Performance BioAssay Analytical Pipe:

{
  "mcpServers": {
    "seosiri-bioassay": {
      "command": "uvx",
      "args": ["seosiri-bioassay-mcp"]
    }
  }
}

Step-by-Step System Testing

To debug your connection schemas directly without writing custom UI wrappers, you can test the active server endpoint using standard terminal tools like cURL:

curl -X POST https://seosiri.com \
     -H "Content-Type: application/json" \
     -d '{"jsonrpc":"2.0","method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test-client","version":"1.0.0"}},"id":1}'

Note: Accessing the gateway address (https://rovomcp.seosiri.com/api/mcp) via a standard web browser address bar will return an Endpoint or method mismatch error. This occurs because the browser sends an empty GET request instead of a structured POST payload, which the edge security firewall drops automatically for safety.

Access the Full Engineering Suite

Review the underlying infrastructure matrices, dry-run live tool execution schemas, and match security profiles to your scale requirements:

Interactive Testing Sandbox: SEOSiri Live MCP Endpoint Tester
Configuration Layout Blueprints: SEOSiri Server Configuration Repository
Enterprise Resource Allocation: SEOSiri Predictable Platform Pricing

For advanced international environments requiring highly localized cloud boundaries, check out the specialized SEOSiri Dutch MCP Sovereign Framework Architecture.

🚀 Open-source developers: what are you building next?

Sat, 26 Sep 2026 21:57:32 +0000

SEOSiri is opening up more of its developer ecosystem through developers.seosiri.com — a developer-focused hub for open-source projects, MCP tooling, AI infrastructure, APIs, security, automation, and experimental engineering.

The goal isn't just to publish another collection of repositories.

It's to make useful developer infrastructure discoverable, inspectable, forkable, and buildable.

🔓 Explore the open-source projects

The SEOSiri GitHub organization currently includes public projects across areas such as:

🧩 MCP & AI tooling
• Search governance
• Semantic entity processing
• Keyword clustering
• Content/schema automation
• Database & infrastructure tooling
• Enterprise operations

🤖 Robotics & Industrial AI
• Bio-Robotics MCP
• Industrial AI Gateway
• Multimodal sensing
• IoT and cyber-physical systems

🛠️ Developer & DevOps tooling
• API validation
• DevOps intelligence
• DNS/security auditing
• Developer infrastructure

Several projects are explicitly released as open-source, including MIT-licensed repositories. ([GitHub][1])

👩💻 Built for developers

If you're interested in:

Open Source • MCP • AI Agents • DevOps • Python • TypeScript • APIs • Cloud Infrastructure • Robotics • Developer Tools

take a look at the code, README files, issues, and contribution opportunities.

👉 Developer Hub:
https://developers.seosiri.com/

👉 Open-source repositories:
https://github.com/SEOSiri-Official

Don't just consume AI tooling.

Read the code. Fork it. Test it. Break it. Improve it. Build something new.

If you're a developer, which area would you like to contribute to or see more open-source projects in?

OpenSource #MCP #Developers #AIEngineering #DevOps

I kept the post community-first rather than promotional: the public GitHub organization confirms multiple public repositories, including MCP, developer tooling, industrial AI, and open-source projects. ([GitHub][1])

[1]: https://github.com/SEOSiri-Official? SEOSiri · GitHub

The "Vibe Coder" Reality Check: Validation, Timelines, and Handling Failure

Thu, 24 Sep 2026 13:38:36 +0000

Hey everyone,

I wanted to open up a candid discussion about a reality many self-taught or non-traditional developers face: "vibe coding." We’ve all seen the trend—using AI to spin up code quickly based on a prompt or a "vibe" without necessarily having a formal computer science degree or deep, rigorous training in that specific stack.

If you identify as a vibe coder, or if you are working without a formal engineering background, I’d love to get your insights on a few specific challenges:

How do you actually validate the code?

When you don't have years of formal training in software architecture, how do you ensure the code the AI spits out is safe, efficient, and actually doing what it's supposed to do? What is your personal validation process? Do you rely on manual clicking, writing automated tests with the AI, or just pushing to production and waiting for bug reports?

How long does validation take you?

"Vibe coding" feels incredibly fast at first because the initial code generation takes seconds. However, if you are learning on the fly, how long does the verification and debugging phase actually take you? Does the time spent fixing edge cases wipe out the speed gained from using AI in the first place?

What do you do when everything completely fails?

We all hit that wall where the AI gets stuck in an hallucination loop, the code is a tangled mess of spaghetti, and nothing works. When a feature completely fails and you don't have the deep foundational training to debug it from scratch, what is your next step? Do you scrap the project, seek mentorship, or start a completely new prompt thread?

Let's talk about the real metrics, the struggles, and the best practices for validating AI-generated code when you're figuring it out as you go.

Drop your experiences below!

Best regards,
Momenul Ahmad
Vibe Coder & Tech Explorer

MCP APIs are changing how AI agents interact with software — but that also changes the security mode

Sat, 19 Sep 2026 16:20:35 +0000

Traditional APIs generally assume a known client making predictable requests. MCP introduces a different pattern: autonomous AI agents can discover and call tools at runtime based on a natural-language objective.

That creates an important engineering question:

How do you secure an API when the caller itself may be autonomous?

In the latest SEOSiri technical deep dive, I explore:

• Where MCP APIs fit inside the API economy
• Why every public API is also an attack surface
• SQL injection, DDoS, BOLA/IDOR, credential abuse and other API threats
• How SEOSiri structures an edge security layer around MCP/API infrastructure
• The open-source @seosiri/security-proxy approach
• Scoped API keys and sandbox-first integration
• How developers can move from their first API key to a live MCP integration

The goal isn't simply to expose another API.

It is to build an agent-ready API layer where access, validation and security are part of the architecture.

Read the full technical breakdown:
https://www.seosiri.com/2026/09/seosiri-mcp-api-cloud-defense.html

MCP #APIs #AIEngineering #CyberSecurity #CloudSecurity #DevTools #OpenSource #AIAgents #SaaS #Developers

🚀 Building MyZubster: What if AI preserved uncertainty instead of inventing missing data?

Thu, 17 Sep 2026 01:19:10 +0000

🚀 Building MyZubster: What if AI preserved uncertainty instead of inventing missing data?

I'm building MyZubster, and I'm using a surprisingly simple real-world experiment to explore a much bigger software problem: milk kefir and community knowledge.

The question behind the project is:

How can we transform personal experience into structured community knowledge without turning experience into “verified truth”?

The problem

Imagine a user submits:

“I leave my kefir in the refrigerator for a few days.”

An AI system could easily transform that into:

duration: 72 hours
temperature: 4°C

It looks structured.

It also contains information the user never provided.

For MyZubster, that is a data-integrity problem.

Instead, the system should preserve:

duration:
  reported: "a few days"
  exact_value: UNKNOWN

temperature:
  environment: refrigerator
  measured_value: UNKNOWN

UNKNOWN is not an error. UNKNOWN is data.

It tells us what should be measured during the next real experiment.

Evidence-aware Knowledge Cards

I'm building the first version as a Git-based Community Knowledge Library.

Every practice receives a stable ID:

KF-001
KF-002
KF-003
...

The current repository contains cards for:

base milk-kefir practice
strained kefir
whey reuse experiments
pizza, focaccia and baking experiments
dehydrated kefir mixtures
a real community pilot
a reusable community contribution template

But these aren't treated as automatically verified recipes.

Each card carries an evidence state:

PERSONAL_PRACTICE
TRADITIONAL_PRACTICE
OBSERVATION
EXTERNAL_SOURCE
VERIFIED_GUIDANCE

A contributor saying:

“I did this.”

is useful information.

But it is not equivalent to:

“This has been scientifically verified.”

That distinction is part of the data model.

AI should normalize — not manufacture certainty

The future pipeline looks like this:

community submission
        ↓
preserve raw contribution
        ↓
AI-assisted normalization
        ↓
mark missing fields UNKNOWN
        ↓
validate against invented data
        ↓
assign KF-###
        ↓
generate Knowledge Card
        ↓
community reproduction
        ↓
observations
        ↓
external evidence

The AI contract is intentionally constrained:

DO:

extract
structure
connect
identify missing information
suggest what to measure next

DON'T:

invent
erase provenance
silently upgrade evidence
confuse inference with observation

One of the validation mechanisms I'm exploring is detecting transformations such as:

SOURCE:
"a few days"

GENERATED:
"72 hours"

→ UNSUPPORTED_PRECISION

or:

SOURCE:
"kept in refrigerator"

GENERATED:
"4°C"

→ UNSUPPORTED_PRECISION

Other potential validation states:

UNSUPPORTED_CAUSATION
UNSUPPORTED_SAFETY_CLAIM
MISSING_PROVENANCE
MISSING_CONSENT
EVIDENCE_STATE_ESCALATION
SOURCE_NOT_TRACEABLE

Why Git first?

Right now, the knowledge layer is intentionally simple: Markdown + Git.

That immediately gives the project:

human-readable data
version history
diffs
stable files
commit history
auditability
portability

If somebody changes:

temperature: UNKNOWN

to a measured value after a real experiment, the history remains visible.

Git isn't necessarily the final database.

It's a very useful first knowledge ledger.

From recipes to a knowledge graph

The interesting part is that these objects aren't isolated.

For example:

milk + culture
      ↓
    kefir
      ↓
   draining
    ↙    ↘
thick     whey
fraction    ↓
   ↓      reuse
spread     ↓
   ↓    experiment
   └──────┬──────┘
          ↓
      observation
          ↓
   community knowledge

Eventually this can become a graph:

Contributor
    │
    │ contributed
    ▼
  KF-002
    │
    │ produces
    ▼
   Whey
    │
    │ reused in
    ▼
  KF-003
    │
    │ reproduced by
    ▼
Participant B

And evidence can eventually move from card-level evidence to claim-level evidence.

The bigger idea

Kefir is only the pilot.

The same architecture could potentially represent community knowledge around:

fermentation
gardening
seed saving
cooking
repair
craft
maker projects
local observations

The underlying problem remains the same:

How do we preserve useful human knowledge without erasing where it came from or pretending it has stronger evidence than it actually does?

My current rule for MyZubster is:

Don't manufacture certainty. Preserve provenance, record observations, expose unknowns, and let evidence accumulate.

The experiment started with a jar of kefir.

Now I'm using it to explore what an evidence-aware, AI-assisted community knowledge system could look like.

🔗 Project:
https://github.com/DanielIoni-creator/Myzubster-fermentation-kefir

I'd especially like feedback from developers working on AI data pipelines, knowledge graphs, provenance, community platforms, or evidence-aware systems.

How would you design the boundary between AI-assisted normalization and unsupported inference?

Vibe Coding Won't Kill Developers. It'll Kill the Middle.

Tue, 01 Sep 2026 12:57:28 +0000

When good cameras got cheap, everyone predicted the death of professional photography. The prediction landed wrong. The low end died outright: stock libraries, cheap portraits, mass-event coverage went to anyone with a phone and a free editing app. The high end did better than ever — editorial work, photojournalism with access nobody else had, an aesthetic you could not reproduce by buying the same gear. The damage landed in the middle. Small weddings, corporate headshots, real estate listings, the steady unglamorous bulk of the market: not extinction, compression. Prices fell, volume moved to cheaper substitutes, and the survivors climbed up or specialized out.

That compression is the cleanest map I know for what AI-assisted coding is doing to software work. And this half I know from inside: two decades leading dev teams, and now building AI tooling for them.

The comfortable half of the argument

The reassuring version of this is everywhere right now: you were never paid to type, you were paid to think, so AI just frees you to do the valuable part. It's not wrong. It's just the half that's easy to hear. The other half is about the market, not about you.

Judgment, architecture, knowing what breaks in maintenance, deciding what not to build — a model that writes plausible code on command doesn't commoditize any of that. I have watched weeks of confusion land on people who could not read what a capable model generated; the gap was never the tool, and better AI autocomplete does not close that gap.

But "judgment beats typing" answers only a question about skill and dodges the question about market structure. AI doesn't replace developers as a class; it commoditizes a segment. The segment it hits first is the same one the camera hit: the middle. The junior-to-mid tier that lived on CRUD apps, simple integrations, brochure sites, the standard internal tool with a form and a table behind it. That work was always implementation against a known spec, and implementation against a known spec is exactly what a model does cheaply now.

I felt this directly on a side project. I spent many months of evenings building a content pipeline on a visual no-code platform; when AI-assisted coding changed the math, I rebuilt it as proper code in a few weeks. The months were not wasted — they are why I knew exactly what to build. But the same work now costs weeks, not months.

"So the middle just learns to think better?"

This is the obvious objection, and it's worth taking seriously because the answer is where the whole thing turns.

First problem: "learn to think better and survive" doesn't refute the thesis, it confirms it. The claim was never about the people, it's about the work. When someone in the middle develops real architectural judgment, they haven't saved the middle, they've left it. They climbed to the high end. The middle still empties out, by promotion or by exit. A wedding photographer who became a sought-after editorial shooter didn't prove the wedding market survived.

Second problem: "thinking better" isn't a soft upgrade you bolt onto the same job. Going from implementing a spec to deciding what to build, judging tradeoffs, holding the whole system in your head, anticipating the failure that surfaces in production eight months later — that's a change in the muscle being used. Some people build it. Some won't, and some genuinely don't want to; they liked implementation and were good at it. The skill axis is real, but it doesn't pull everyone up by default.

Third problem, and this is the one the reassuring posts never reach: capacity. Suppose everyone in the middle became a strong systems thinker overnight. The market still doesn't need that many architects, security specialists, performance engineers, and trusted advisors. The high end is narrow by definition, which is what makes it the high end. Premium editorial photography never had room to absorb every wedding shooter it displaced.

So when people ask whether "think better" just means "become a consultant," the honest answer is partly. The trusted technical advisor is one exit from the middle, and a good one, but not the only one. Architecture is an exit. Deep security and performance work is an exit. Complex-domain expertise — the kind where you understand the business so well the AI becomes a lever instead of a crutch — is an exit. When a prototype that should take weeks comes together in an afternoon, the speed never comes from the model. It comes from twenty years of knowing the exact problem before the first prompt. The tool doesn't create that position; it amplifies what was already there.

The honest limit of the analogy

I'd be selling you something if I claimed software follows photography like a law. It doesn't. Photography had roughly fixed demand; the number of weddings didn't triple because cameras got cheap. Software might. Total demand for software has grown for forty years, and cheaper production could grow it further, which means some of the displaced middle gets reabsorbed into work that didn't exist before. The wedding market never had that escape valve.

So I won't tell you eighty percent of developers will be unemployed. I don't believe it, and the people who say it are guessing. The defensible claim is narrower and still uncomfortable: middle-tier work commoditizes, value migrates toward the extremes, and you should plan around that rather than hope the middle holds.

For the individual, the move is to climb toward judgment, architecture, and advisory work, not to defend the commoditizing tier by getting slightly faster at it. Speed inside a shrinking band is a losing race against a tool that's cheaper than you and getting better weekly.

For anyone running a technical team or a practice, this is the argument for senior-led work getting stronger. The middle is precisely the layer being liquified. Value concentrates in the people who were never doing middle work to begin with: the ones whose contribution was the system, the tradeoff, the domain, the call about what not to build. That's why this practice is senior-led and founder-run. It is not a positioning choice; it is what the map says to do.

The question to sit with isn't whether you can out-think the AI. You probably can, on a good day. The question is which segment that thinking lives in, and whether that segment will still be there to stand in. Go look at the last five things you shipped. Count how many were implementation against a spec someone else wrote. That number is your exposure.

Originally published at unlockedconsulting.ai.

The Hidden Mental Model That Determines Whether AI Tools Help You

Tue, 01 Sep 2026 07:13:56 +0000

I built a working knowledge base while I was in a one-hour company meeting, waiting for my turn to give my briefing. Even I was surprised at how fast it came together. And it was not a mockup. It was a complete chat interface that connected to nearly everything the company had — training manuals, forgotten documentation, enhancement request docs, support ticket histories — all indexed into a vector database. When I tested it, it answered my plain-language questions and surfaced the right context every time. Fifty-five minutes was all I had to do it. And by the time I needed to do my briefing, the tool was already running.

I want to be precise about why this was possible, because the obvious explanation is normally wrong: the tool wasn't the reason. Yes, VS Code with Claude Code inside was the tool I used to pull this together, but the real reason it took under an hour is that I already knew what the right solution looked like. I knew how the pieces had to fit, where the data belonged, what would break if I got it wrong. That judgment was already in my head. The AI didn't supply it. It executed against it at speed.

Same tools, different results

Those same tools I used could produce completely different results, depending on who's using them and how. So even though the tools are the same, what makes the difference in the output is the specific technical judgment behind it. Put the same setup in front of someone who doesn't carry that technical judgment, and the AI runs just as fast — except toward a structure they have no way to evaluate. The output looks plausible, but the cost surfaces later, somewhere harder to see. That gap is the whole point, and it has almost nothing to do with the tool.

What the mental model actually is

So what is that judgment, concretely? It's a mental model of how the parts of a system fit together: where data lives, how one piece talks to another, how something gets from your machine to where it actually runs. Not the code, the shape of it. You can have all of that without writing a single line yourself.

Two things tend to get mistaken for it. The first is the ability to write code. Those aren't the same thing; plenty of people who can write a function still carry no picture of the system that function lives in. The second is knowing the business — the company, the clients, the domain. That knowledge helps, and it certainly made me faster in that meeting, but it isn't what's missing when AI output goes wrong. What's missing is the structural picture: a sense of where a piece of data should originate, what should talk to what, and what breaks downstream when those choices are wrong.

That picture matters because of what it lets you do with the AI's output: judge it. When you're holding an accurate model, a suggestion that doesn't belong stands out right away, because it doesn't fit the shape already in your head. Strip that model away and the same suggestion looks as reasonable as everything else, since there's nothing to measure it against. That's why the model, not the tool, is the real variable. AI amplifies whatever you bring to it — good judgment moves faster, and so does the absence of it.

The model, not the tool, is the real variable. AI amplifies whatever you bring to it — good judgment moves faster, and so does its absence, just toward a structure you'll pay for later.

Why "which AI tool should we use" is the wrong opening question

That's why "which AI tool should we use" is usually the wrong place to start. Over the past few months I've run a systematic evaluation across my team: Cursor, Claude web, Claude Desktop, Claude Code, Copilot in VS Code, AugmentCode, and various combinations. The finding was the same every time. There's no best tool, only the best tool for a specific situation. What decides it is the project, the stack, who maintains the code afterward, the deployment target, the cost model, and above all whether the person using it is a developer or not. Change any of those and the right answer changes with it.

"Which tool" is a tempting question because it's answerable. You can compare features, watch demos, pick a winner, and feel like you've made progress, and it's the one question every vendor is glad to answer for you. But it skips the harder one: does the person using the tool understand the architecture underneath — how the parts actually connect? That question has no vendor, no demo, and no clean answer, which is exactly why it gets avoided.

The cost of skipping it doesn't announce itself. Hand a capable tool to someone who can't see that architecture, and nothing breaks on day one. It shows up later, in maintenance, where it's hardest to trace back to its cause.

What to fix when productivity gains are uneven across your team

If you lead a team, you've probably seen this already: the same tools landed, and a few people got dramatically faster while others barely moved. The reflex is to standardize: pick one tool, roll out training, make everyone consistent. That treats it as a tooling problem, and it usually isn't. What to do next depends on who's in front of the tool.

For the people who aren't developers, don't try to turn them into architects. That's the slow path, and most of them don't need it. Give them a setup where the hard parts — where the code lives, how it connects, how it ships — are already decided and kept out of their way. They get the leverage of the tool without having to carry the model themselves, because it's built into the environment around them.

Your engineers and technical leads need the opposite investment. For them the architecture model is the multiplier, so the time spent making sure they can see how a system fits together pays back more than any tool upgrade. That understanding is what the tool runs on.

And if you want a cheap way to find out where each person actually stands, skip the survey. Take your fastest and your slowest person on the same tool, hand them a whiteboard, and ask them to draw the system they're working on — where the data comes from, what talks to what, where the code lives, how it gets deployed. The drawing tends to track the productivity gap closely; often you'll see it before the marker's back in the tray. It's the cheapest diagnostic you'll run, and it measures the one thing that actually matters here: whether they can see the system they're building on.

Originally published at unlockedconsulting.ai.

MCP + Plugins: Stop Connecting Tools. Start Building Developer Workflows.

Sun, 30 Aug 2026 07:59:47 +0000

Your AI coding assistant does not become powerful because you connected more tools.

It becomes powerful when those tools are connected to the right workflow, with the right permissions, and enough context to make useful decisions.

That distinction matters as AI moves beyond generating code and starts interacting with repositories, databases, documentation, APIs, CI systems, and other development infrastructure.

This is where MCP and agent plugins become genuinely useful.

But there is a problem: developers can easily turn integrations into a shopping list.

GitHub. Database. Browser. Slack. Documentation. Another MCP server. Another plugin.

More connections can look impressive while making the actual system harder to control.

The goal should not be maximum connectivity.

It should be useful connectivity.

MCP is a connection layer

The Model Context Protocol (MCP) provides a standardized way for AI applications to interact with external tools and data.

An MCP server can expose capabilities such as repository access, documentation retrieval, database operations, APIs, or other development tools.

The important separation is:

The model reasons. The tool performs the operation.

Instead of copying information from five different systems into a prompt, the AI application can interact with those systems through defined interfaces.

That makes tool use more structured and reusable.

But MCP itself does not magically create an intelligent developer agent.

The workflow around those tools still matters.

Plugins solve a different problem

MCP and plugins should not be treated as the same thing.

MCP is primarily a protocol for connecting AI applications with capabilities.

A plugin can package a broader capability or workflow, potentially combining skills, instructions, and MCP-based tools into something easier to distribute and reuse.

Think about a developer task such as:

«“Investigate why the production deployment failed.”»

That is rarely a single-tool operation.

The agent may need repository information, CI status, logs, recent commits, changed files, documentation, and issue history.

The useful capability comes from combining these pieces into a workflow.

Stop asking “Which tools should I install?”

This is probably the biggest mindset shift.

Don't start with:

«“Which MCP servers are available?”»

Start with:

«“Which developer workflow am I trying to improve?”»

For example:

CI debugging

GitHub → failed workflow → logs → recent commits → changed files → project context

Database investigation

Database → schema → relevant tables → query → result analysis

Documentation-aware development

Repository → official documentation → API reference → implementation → tests

Release preparation

Git → issues → pull requests → CI → changelog → release

Now every integration has a reason to exist.

What “using MCP like a pro” actually looks like

Imagine asking:

«“Why did my latest CI pipeline fail?”»

A basic AI workflow might ask you to paste the error.

A connected workflow can inspect the failed run, identify the failing job, retrieve relevant logs, inspect the latest commit, examine changed files, and compare the failure with the existing test structure.

The agent can then explain the likely root cause and propose the smallest safe fix.

If a modification is required, it should not automatically change production code simply because it has access to the repository.

It should propose the change, show the impact, run appropriate validation, and request approval when the action has meaningful consequences.

Automation should not mean unrestricted autonomy.

More tools can make agents worse

There is a common assumption that an agent becomes better as you give it more tools.

That is not necessarily true.

If an agent has access to 30 tools but needs only three for a specific task, the remaining capabilities add decision complexity and potentially irrelevant context.

There is also a security problem.

A tool that reads documentation is fundamentally different from one that can modify infrastructure or execute destructive database operations.

A production system should therefore use:

Least privilege

Give each workflow only the permissions it actually needs.

Read before write

Inspect and understand the system before modifying it.

Approval gates

Require appropriate confirmation for high-impact actions.

Traceability

Record important tool calls so developers can understand what the system did.

Build around workflows

A mature developer platform might eventually support dozens of integrations.

The developer should not have to manually manage all of them for every task.

Instead, the platform can activate capabilities according to the workflow.

Choose:

Debug CI

and expose the tools needed for CI investigation.

Choose:

Investigate a database issue

and expose database-related capabilities.

Choose:

Prepare a release

and activate the relevant Git, issue, CI, and documentation capabilities.

This creates a much cleaner architecture:

Intent → Workflow → Required capabilities → Context → Action → Verification

That is far more useful than:

User → giant toolbox → hope the agent chooses correctly

Treat every integration as a security boundary

Before connecting a new MCP server or plugin, ask:

What data can it access?
What actions can it perform?
Does it really need write permission?
What happens if the model chooses it incorrectly?
Can its actions be audited?
Can access be revoked?
What happens when the external service fails?

The question is not:

«“Can my AI agent access this?”»

The better question is:

«“Should my AI agent access this, for this workflow, with this level of permission?”»

The bigger shift

MCP and plugins are interesting because they move AI development systems beyond isolated chat interfaces.

The next generation of developer tools will increasingly combine:

Models + context + tools + memory + verification + human control.

MCP can provide an important connection layer.

Plugins can make capabilities easier to package and reuse.

But neither automatically creates a reliable AI developer.

The difficult engineering work is designing the workflow around them.

Connect fewer capabilities.

Give them clear responsibilities.

Control their permissions.

Verify their outputs.

Measure whether they actually reduce developer effort.

The real question is no longer whether AI can use your tools.

If your AI coding agent could access every tool in your development stack tomorrow, which capability would you trust it to use autonomously—and which one would you still require it to ask permission for?

What Should a Developer Learn When AI Can Write Code?

Sat, 22 Aug 2026 17:27:48 +0000

For decades, learning to code meant learning how to write code.

You learned syntax.
You memorized APIs.
You practiced algorithms.
You built projects.
You learned frameworks.

But AI has changed one fundamental part of that equation.

Writing code is becoming cheaper.

AI can generate a React component in seconds. It can write a REST API, explain an unfamiliar codebase, generate SQL queries, Dockerfiles, Terraform configurations, tests, and even entire applications.

So a natural question emerges:

If AI can write the code, what should developers actually learn?

The answer isn't less programming.

It's more engineering.

1. Learn to Understand Systems

AI can generate a function.

It is much harder for AI to understand why that function belongs in your architecture.

A developer still needs to understand:

How services communicate
Where state lives
How data flows through a system
Where failures can occur
How systems scale
What creates technical debt
What trade-offs exist between different designs

Knowing how to write a function is useful.

Knowing where that function should exist is engineering.

2. Learn Debugging, Not Just Coding

Generated code will fail.

Sometimes spectacularly.

The important skill isn't being able to ask:

"Can you fix this error?"

It's being able to ask:

"What is actually causing this behavior?"

Good developers develop hypotheses.

They inspect logs.

They reproduce problems.

They isolate variables.

They trace execution.

They understand error messages.

They verify assumptions.

AI can accelerate this process enormously—but you still need to know what to investigate.

3. Learn to Read Code

This may become more important than writing code.

When AI generates 500 lines of code, somebody has to determine whether those 500 lines are:

Correct
Maintainable
Secure
Unnecessarily complex
Compatible with the existing system
Performant enough
Actually solving the intended problem

The ability to read unfamiliar code quickly is becoming a superpower.

Code comprehension may become more valuable than code production.

4. Learn Computer Science Fundamentals

AI doesn't make fundamentals obsolete.

It makes them easier to apply.

You don't necessarily need to memorize every implementation detail of a hash table.

But you should understand:

Complexity
Data structures
Concurrency
Operating systems
Networking
Databases
Distributed systems
Security
Memory
Algorithms

Why?

Because when AI gives you three possible solutions, fundamentals help you recognize which one is actually appropriate.

5. Learn How to Ask Better Questions

Prompt engineering isn't about discovering the perfect magical prompt.

For developers, the more important skill is problem specification.

Instead of:

"Build authentication."

A strong developer thinks:

Who are the users?
What are the trust boundaries?
What authentication mechanism are we using?
What happens when tokens expire?
What happens if credentials are compromised?
How is authorization handled?
How do we test it?
What are the failure modes?

AI becomes dramatically more useful when you understand the problem deeply enough to specify it precisely.

6. Learn Git, Testing and CI/CD

These might sound boring compared with AI agents.

They're becoming more important.

When AI allows you to generate code at 10× the previous speed, your ability to safely integrate that code becomes a bottleneck.

That means understanding:

Git → Tests → CI → Review → Deployment → Monitoring

becomes increasingly valuable.

The future isn't:

Human writes code → AI helps.

It's increasingly:

Human defines intent → AI generates implementation → automated systems verify it → human reviews the important decisions.

7. Learn Security

This one is non-negotiable.

AI can generate insecure code very quickly.

Developers need to recognize:

Injection vulnerabilities
Authentication flaws
Authorization mistakes
Secrets exposure
Insecure dependencies
Broken access control
Supply-chain risks
Prompt injection
AI-specific attack surfaces

You don't need to become a penetration tester.

But you should be able to look at generated code and ask:

"How could someone abuse this?"

8. Learn Product Thinking

This might be the biggest shift.

AI reduces the cost of implementation.

That means choosing what to build becomes more important.

A developer who can turn:

"Users are having trouble tracking expenses."

into:

"Let's identify the actual workflow, define the smallest useful intervention, measure success, and then build it."

is far more valuable than someone who can generate 10,000 lines of code.

The future belongs to developers who understand both technology and the problem technology is solving.

9. Learn to Work With AI

Don't treat AI as a replacement for your engineering process.

Treat it as another engineering tool.

Use it to:

Explore unfamiliar repositories
Generate prototypes
Explain APIs
Write tests
Refactor code
Find edge cases
Review implementations
Generate documentation
Investigate bugs
Automate repetitive work

But maintain a simple rule:

Never outsource understanding.

If AI writes something you don't understand, you don't have working software.

You have code you haven't evaluated yet.

So What Should Developers Learn?

The skill stack is changing.

Old model

Syntax → Frameworks → Coding → Projects

Emerging model

Fundamentals → Systems Thinking → Problem Solving → AI Collaboration → Verification → Product Thinking

AI isn't making developers irrelevant.

It's raising the abstraction level.

The developer who only knows how to type code may struggle.

The developer who understands systems, trade-offs, users, security, debugging and architecture—and uses AI to amplify those skills will have an enormous advantage.

Because when everyone can generate code...

the scarce skill isn't producing code.

It's knowing what code should exist in the first place.

The Fastest Developer Isn’t the Best Developer

Thu, 13 Aug 2026 04:21:45 +0000

We live in a culture where developers are constantly told to move faster.

Ship more features.
Close more tickets.
Write more code.
Learn more tools.
Use AI to make everything faster.

But there’s a problem:

Speed without direction is just expensive chaos.

A developer who spends 3 hours carefully understanding a problem can often outperform someone who spends 8 hours rapidly building the wrong solution.

The real productivity skill: thinking before coding

Before opening your IDE, ask:

What problem am I actually solving?
Who is affected by this problem?
What is the simplest solution?
What could break if I change this?
How will I know the solution actually works?

These questions may feel slower.

They aren't.

They prevent hours of unnecessary coding.

AI makes this even more important

AI can generate code in seconds.

But AI doesn't automatically know:

What your users actually need
Which business rule is critical
Which legacy behavior cannot be changed
Whether a shortcut will create technical debt
What consequences a seemingly small change might have

Generating code is becoming cheap. Understanding the problem is becoming more valuable.

A simple rule I use

Before implementing a feature, spend a few minutes writing down:

Problem → Cause → Options → Trade-offs → Solution

Then code.

This small habit can dramatically reduce rework.

Because the goal of software development isn't to produce the most code.

The goal is to solve the right problem with the least unnecessary complexity.

What do you think is more valuable for developers today: coding speed or problem-solving ability?

Your AI Wrote 500 Lines Today. Did It Actually Make You Faster?

Wed, 12 Aug 2026 16:46:39 +0000

There is a strange thing happening in software development.

We can write code faster than ever.

AI can generate an API, create database models, write tests, refactor a component, explain an error, and even open a pull request before you finish your coffee.

So why do some engineering teams still feel slow?

Because writing code was never the only bottleneck.

The Code Is Getting Faster. The System Isn't.

Imagine a developer who used to take four hours to implement a feature.

With AI, they can produce the first version in one hour.

Sounds like a 4x productivity improvement.

But then comes:

45 minutes of code review
30 minutes fixing incorrect assumptions
20 minutes updating tests
30 minutes debugging an edge case
40 minutes waiting for CI
Another review after changes
A production issue two days later

Suddenly, the one-hour implementation wasn't a one-hour feature.

AI accelerated code generation. It didn't automatically accelerate software delivery.

This isn't just theoretical.

DORA's research found widespread AI adoption and strong perceived individual productivity gains, while also highlighting tensions around delivery performance and stability.

The New Bottleneck: Verification

As AI becomes better at creating software, developers increasingly become responsible for verifying software.

That means asking:

Does this actually solve the problem?

Not:

Does this code look correct?

Those are very different questions.

AI can produce beautiful code that solves the wrong problem.

It can confidently use an API that doesn't exist.

It can write a test that validates its own incorrect assumption.

It can introduce an abstraction that nobody on the team needs.

And it can make a 20-line problem into a 200-line solution.

The Most Dangerous AI Code Is Not Bad Code

It's code that looks good enough to merge.

Bad code is easy to notice.

Confusing code gets rejected.

Broken code fails tests.

But plausible code can quietly enter production.

A 2026 study examining more than 300,000 AI-authored commits across thousands of GitHub repositories found hundreds of thousands of AI-introduced issues, with 24.2% of tracked issues still present in the latest revision studied.

That doesn't mean AI-generated code is bad.

It means something more important:

AI-generated code still needs engineering.

So What Should Developers Do?

Don't stop using AI.

Change what you measure.

Instead of asking:

"How much code did AI generate?"

Ask:

Did we ship faster?
Did production stability improve?
Did review time decrease?
Did bugs decrease?
Did developers spend more time solving meaningful problems?
Did maintenance become easier?
Did customers actually get value faster?

Because 1,000 generated lines that create 10 hours of review work aren't necessarily productivity.

They're just faster typing.

The Developer's Job Is Changing

The strongest developers in an AI-assisted world may not be the ones who can prompt the best.

They'll be the ones who understand:

architecture + business requirements + debugging + security + testing + system behavior.

AI can generate implementation.

It cannot remove your responsibility for the outcome.

That distinction is becoming extremely important as AI moves from autocomplete toward agents that can make multi-step changes across a codebase.

The developer increasingly becomes the person who says:

"Here's what we want."

"Here's what the AI produced."

"Here's why we should—or shouldn't—ship it."

A Simple Rule I Want to Follow

Before merging AI-generated code, ask three questions:

1. Would I understand this code six months from now?

If not, simplify it.

2. Can I explain why every important decision was made?

If not, investigate it.

3. What happens when this code is wrong?

If the answer is "we'll find out in production," we have a process problem.

The Real AI Productivity Metric

Maybe the future of developer productivity isn't:

Lines of code per developer.

Maybe it's:

Useful outcomes per unit of engineering effort.

That's a much harder metric.

But it's also a much more honest one.

AI is giving developers an incredible opportunity.

We can spend less time typing boilerplate and more time thinking about difficult problems.

But only if we resist the temptation to turn every productivity gain into more code.

Sometimes the best use of AI isn't generating 500 lines.

It's helping you realize that you only needed 50.

What do you think?

Has AI actually made your team faster from idea → production, or has it mainly made code generation faster?

I'd especially like to hear from developers who have been using AI coding tools for 6+ months.

The Hardware Every Programmer, Sysadmin, and Linux Nerd Actually Needs in 2026 (No Marketing Fluff)

Mon, 06 Jul 2026 16:08:03 +0000

What year is it again? 26? I haven't left the terminal long enough to notice — my system clock drifted and I only just caught it. Anyway, hello to all the engineers out there, junior and senior, and of course to my fellow Linux nerds.

In this post I want to break down what hardware is actually worth buying if you're a programmer, a Linux user, a sysadmin, a technical writer (like me, ha), or a manager. I'll throw gamers a bone too, but consider that section a footnote — I'm not much of a gamer myself, though I did once have to sit inside a game engine for work, so I've earned the right to an opinion.

Before we get into the actual picks, let's lay out the facts and the needs of each of these roles. Everyone has different priorities, sure, but they overlap more than people think — and once you strip away the marketing copy, the actual requirements for "good machine to work on" are almost identical across all of them.

I've spent a genuinely unreasonable amount of time comparing processors, GPUs, and laptops across brands — corporate, flagship, gaming, all of it. I've read the spec sheets, I've read the community threads where people complain about coil whine at 2am, I've watched the durability teardown videos so you don't have to. Here's what actually matters, in order.

The Keyboard Comes First. Always.

For every single one of these roles — coder, writer, sysadmin, manager — you need a keyboard you want to type on. And here's the uncomfortable truth about the current market: most of it is 1.5mm, 1.3mm, sometimes less. Can you write on that? Sure. It's a solid "okay." It exists to let you exist. It's not going to hurt you, and it's not going to inspire you either.

If you actually want a keyboard that makes typing feel good, your options collapse fast: ThinkPad (not every line — pay attention, this matters more than you'd think) and, to a lesser extent, select Dell Latitude models. And that's basically it. If you're on desktop, obviously the market opens wide up — you can buy something that clacks like a 1985 typewriter if that's your thing, mechanical switches, hot-swappable, the whole ritual.

Why does this matter so much for these particular jobs? Because a writer writes text all day. A Linux user is constantly fixing configs, running fastfetch in their terminal just to feel something. A sysadmin is deep in Docker configs and SSH sessions, typing constantly, half the time over a flaky VPN tunnel at 2am because production decided to have opinions. A developer is fixing bugs, replying to painfully dumb emails, arguing in Slack with coworkers about tabs versus spaces for the hundredth time. It's all typing. The keyboard is the interface to your entire professional life — treat it like one, not like an afterthought bolted onto a chassis to check a box.

The Screen: Second Priority, First for Some

If your work touches design, video, or imagery, a good display isn't optional — it's oxygen. ThinkPad P-series and select T-series configurations cover this too: OLED, 2K/4K, 16:10, no problem. Just know that the panels with the nicest color and contrast tend to come on the models where key travel has already crept down toward that 1.5mm territory. Nothing is free — every laptop is a stack of compromises, and your job is to pick which compromises you can live with.

If your priority is design work and raw power and you're constantly traveling — because let's be honest, rendering 4K footage makes any laptop sweat — then a MacBook on an M-series chip is a legitimate outlier worth considering, purely on the merits of thermal efficiency and color accuracy per watt. It's not Linux, and yes, you'll spend a weekend re-training your muscle memory if you're coming from a tiling window manager. But nobody serious is pretending Apple Silicon isn't good hardware. Just don't buy the oldest chip on the shelf because it's the cheapest — buy something current, or at minimum one generation back. Old silicon for the sake of saving two hundred bucks is how you end up bottlenecked in eighteen months.

CPUs: Just Buy AMD, Especially on Linux

I'll say it plainly: AMD is the better call, particularly if you live on Linux. Open drivers, better long-term support, a healthier open-source relationship, strong new architectures, decent battery life, and — unlike certain competitors — they don't turn your lap into a stovetop by hour two.

Core count matters more than clock-speed bragging rights:

6 cores / 12 threads — the bare minimum for comfortable daily work. Fine for scripting, light web dev, general sysadmin tasks.
8 cores / 16 threads or more — where you actually want to be if your day involves compiling, running heavier Docker containers (RAM matters here too), databases, or a background full of questionable systemd units doing who-knows-what while you're trying to focus.

So why the cold shoulder to Intel? It's not personal — it's architectural. Their recent generations look exciting on paper: new process node, more cores, an NPU nobody asked for. But what kind of cores? P-cores and E-cores. So you look at a spec sheet that says "10 cores, 12 threads" and think you're getting a beast, except only 4 of those cores are the real performance ones and the rest are efficiency cores doing background busywork. Compile something heavy on that setup and you'll feel the difference immediately compared to a chip with 8 full, real, performance cores across the board that don't need to negotiate with the scheduler about who gets to do actual work.

This isn't an "Intel is bad" take — for pure single-thread desktop work with light multitasking, their newer chips are fine. But for sustained, parallel, compile-heavy, virtualization-heavy workloads on a laptop that also has to survive a battery-only train ride, AMD's approach is currently just a better fit for how we actually work.

RAM: The Single Biggest Priority

Minimum 16GB. Realistically 24–32GB. Why? One word: Electron.

Most of the apps we use daily are Electron shells with a full Chromium instance riding shotgun inside them, quietly drinking your memory like it's an open bar. Is the result nice? Sure, the design and styling are genuinely great, cross-platform consistency is genuinely convenient for the people building these apps. Does it cost you dearly in resources? Also yes, painfully so. Browsers in general (any engine that actually runs JS) eat more RAM than should be legal, and Discord — which is Electron through and through — will happily consume everything you give it on its own, no roommates required, no apology given.

If you run a browser with two dozen tabs, a couple of Electron apps, a Docker stack, and an IDE with a language server chewing through your codebase — 16GB is a survival number, not a comfort number. 32GB is where you stop thinking about memory pressure and go back to thinking about your actual work. If you can afford it and your workflow includes VMs or multiple containerized services running locally, don't be shy about going higher. RAM is one of the few upgrades that pays for itself in reduced daily frustration almost immediately.

Storage: Don't Cheap Out on the One Part You'll Never See

NVMe SSD, non-negotiable, minimum 512GB if you're a developer running multiple project directories, Docker images, node_modules folders that multiply like rabbits, and language toolchains that all insist on their own isolated environments. If you do anything with local ML models, containers, or VMs, go 1TB. Rotational drives died for a reason — let them rest in peace, they served their purpose in an era that is not this one.

One practical note: if you're buying a ThinkPad T or P series, check whether the SSD is user-replaceable before you buy. On most of these lines it still is, which means you can start at a reasonable storage tier and upgrade later instead of overpaying the manufacturer's storage markup on day one. That flexibility alone is worth factoring into the price comparison.

What Not to Buy (and Why)

This is the part of the post where I stop being diplomatic. Every category above tells you what to look for. This section tells you what to walk past in the store, no matter how nice the marketing photo looks.

Dell XPS (and its consumer-ultrabook cousins)

The XPS is the laptop world's answer to "what if we made a MacBook Pro, but beige-brained." It's a flagship consumer ultrabook, frequently benchmarked against the MacBook Pro, and on a shelf under store lighting it looks genuinely great. The screen is usually excellent.

Here's why it's still not our pick:

Keyboard: Perfectly fine for a normal person writing emails. Not ThinkPad-tier. Shorter travel, mushier feedback, and after eight hours of real work you'll feel the difference in your fingers.
Repairability: RAM is frequently soldered, the battery is a project to replace rather than a five-minute job, and the chassis isn't exactly inviting you to open it up.
Ports: Increasingly dongle-dependent. Standard USB-A and Ethernet are treated as optional extras rather than baseline expectations.
Price: You're paying a premium for the industrial design. For the same money you could get a ThinkPad with enough RAM to run a small datacenter and still have cash left for a proper docking station.
Thermals: Manufacturers keep cramming increasingly powerful Intel chips into increasingly thin chassis, which means fan noise and thermal throttling the moment you ask it to do something for longer than five minutes.

If you want a good-looking laptop for coffee shops and PowerPoint demos, the XPS will make you happy. Just don't try to compile a kernel on it — your fingers, and your ears, will file a formal complaint against the fan noise.

ASUS, Acer, and HP (the mass-market consumer lines)

This is where roughly ninety percent of the "consumer laptop" market actually lives, and it's also where most of the disappointment lives.

Keyboard: This is exactly the 1.0–1.3mm travel we talked about earlier, frequently paired with creaky plastic, backlighting that's somehow both too dim to be useful and too bright to ignore, and key legends that start wearing off within six months. A keyboard that exists purely so that a keyboard technically exists.
Chassis: Plastic, flexy, occasionally rattly. Hinges start feeling loose within a year of normal use.
Screens: Often TN panels, or IPS panels that technically qualify as IPS while offering color coverage and brightness that make you question the term.
Build quality and QC: A genuine lottery. Two units off the same production line can feel like different products.
Cooling: Close to nonexistent on the budget and mid-range models. Some of these throttle running a "Hello, World" compile.

If you go with a consumer-line ASUS, Acer, or HP, budget accordingly: the keyboard will start squeaking before you finish typing your first "Hello, World," and the screen will be actively working against you while you try to read logs at 1am. There are exceptions in their business lines, but the consumer segment is not where you go looking for a daily driver.

Gaming Laptops (Legion, ROG, Razer Blade, and friends)

I touched on these briefly before, but they deserve their own paragraph of roasting, because the mismatch between "gaming laptop" and "daily dev machine" is almost comedic once you actually live with one.

Aesthetics: Looks like a children's toy that got into steroids, glows every color of the rainbow, and generally screams about its own power to anyone within eyeshot — including in the middle of a client call.
Battery life: Lives about three hours away from an outlet, and turns into a paperweight faster than you can get Docker Desktop to finish starting up once it's unplugged.
Weight and portability: Heavier than your cat, and somehow heavier still than your conscience after a Friday-evening production deploy.
Price: You're paying full price for a GPU you don't need for software development, plus an RGB subsystem that will annoy your coworkers on a call far more than it will inspire you at your desk.

If you're a genuine gamer who also happens to code, fine, there's a real argument for a Blade or a Legion — just go in with eyes open about the trade-offs. If you're buying it purely because it looks powerful, you're paying a premium for a light show.

The Actual Recommendations for 2026

Here's where I put my money where my sarcasm is. ThinkPad T and P series are the backbone of this list — they're the machines built around exactly the priorities we've walked through: real keyboards, serious durability, sane thermals, and broad Linux compatibility, several of them formally certified for major distributions rather than just "should probably work." The L and E series exist as the honest budget compromise — you give up some polish and some display options, but you keep the ThinkPad DNA: the keyboard feel, the build quality, the repairability. That's a much better trade than saving the same money on a consumer-line ASUS or HP and losing all three.

For developers who live in Linux and want the best keyboard-to-power ratio:
A ThinkPad T-series AMD configuration is the sweet spot — Ryzen AI PRO silicon, a keyboard that doesn't apologize for existing, and enough balance for daily dev work without workstation pricing. If you need more screen real estate for a multi-pane coding setup, the larger 16-inch T-series models give you that at the cost of a bit more weight in your bag. Most current T-series configurations run mainstream Linux distributions without drama — Ubuntu, Fedora, and Debian derivatives all behave themselves on this hardware, which is exactly what you want when your job depends on your tools not fighting you.

For heavier local workloads — ML, CAD, big compiles, scientific computing:
Look at the ThinkPad P-series AMD line. These are ISV-certified workstation-class machines that let you push RAM capacity well beyond what the T-series offers. They're more expensive for comparable core specs, and some configurations run their fans hard under sustained load — but if you're compiling all day, running local models, or doing simulation work, that extra headroom pays for itself.

For the budget-conscious who still want the ThinkPad DNA:
The entry-level ThinkPad L-series and E-series bring genuine ThinkPad durability and keyboard feel without the flagship price tag. You lose the OLED option and some of the chassis polish, but the bones — the keyboard, the build quality, the general "this thing will survive being dropped in a hallway" attitude — are the same family. This is the honest, no-shame compromise pick, not a downgrade to avoid.

For design, video, and "I travel constantly and it has to just work":
MacBook Pro on an M-series chip. Buy something current, or at most one generation back — don't start with the oldest chip on the shelf just because it's the cheapest, you'll regret it in under two years. Yes, it's not Linux, and yes, you'll fight your muscle memory a little if you're coming from a tiling window manager and full shell control. But for color-accurate displays, battery life, and render performance per watt, this is the one non-ThinkPad exception on the list that earns its place.

A quick honorable mention for the Linux purists: if repairability and long-term upgradeability matter more to you than brand pedigree, it's worth putting a modular, community-favorite laptop brand on your shortlist — the kind built specifically around swapping your own ports, upgrading your own RAM, and running the same chassis for a decade. Not quite ThinkPad-tier keyboard, but the philosophy will resonate with anyone who already runs Arch "btw."

And for the Gamers, Since I Promised

I don't play much, but I've had to sit inside a game engine long enough to have an opinion: if gaming is genuinely your priority and coding is secondary, go in with eyes open about everything covered in the roast section above — the battery life, the weight, the noise. Just don't pretend to yourself that you're buying it "for development." You're buying it for the GPU, and that's a perfectly fine reason, as long as you're honest about it.

Bottom Line

Buy the keyboard first, mentally. Everything else — the CPU, the RAM, the screen — is a variable you tune around that constant. AMD if you're on Linux and value your battery and your sanity. 32GB of RAM if Electron apps are anywhere near your daily workflow (they are, don't lie to yourself). NVMe, always, and enough of it that you're not managing storage like it's 2010. A discrete GPU only if you actually need one, not because it's there.

Stick to ThinkPad T or P series if you can afford them, L or E series if you can't and refuse to compromise on build quality — and steer hard around the consumer-flagship trap of Dell XPS, the budget-plastic lottery of mass-market ASUS/Acer/HP, and the RGB tax of gaming laptops, unless you actually need what those specific categories are built for.

And if your current laptop still has a keyboard you enjoy typing on — for the love of all that's holy, don't "upgrade" into something worse just because it's newer. New isn't always better. It's just newer.

i use arch btw :>

You Are Not Being Rejected. You Are Invisible.

Thu, 02 Jul 2026 18:42:32 +0000

I place developers with US tech companies for a living. Before that sentence makes you close the tab: this article contains the things I tell developers for free, every week, one conversation at a time. I got tired of saying it one person at a time.

Here is the pattern. A strong developer outside the US decides to go for US remote work. The money is real, the work is real, the market is real. They polish the CV, they apply to twenty, fifty, a hundred roles.

And they hear nothing.

Not "no". Nothing. And after enough nothing, every single one of them arrives at the same quiet conclusion: I must not be good enough.

I have read the CVs and talked to the people behind them. The conclusion is almost always wrong. What is actually happening is mechanical, boring, and fixable, and nobody explains it because nobody profits from explaining it. Let me walk through the three filters that are actually eating your applications.

Filter 1: You are applying to jobs that were never open to you

"Remote" means two completely different things, and job boards mix them together.

Remote (US only) means the company wants you on US payroll. They will let you work from your couch, as long as your couch is in the United States. For someone applying from Prague or Bratislava or anywhere else abroad, this is a closed door. No amount of skill opens it, because the blocker is legal structure, not talent. Most "remote" listings on the big boards are this kind.

Remote (global, or contractor) means the company hires people anywhere and pays them as independent contractors who invoice. No US payroll, no visa, no sponsorship, because you are a vendor, not an employee. This is your actual market. It is smaller, it is real, and it is far less crowded.

If you do not check which kind you are looking at before applying, most of your applications go into doors that were locked before you knocked. Ten seconds of scanning for "worldwide", "contractor", "B2B", or "must be US-based" saves you months.

Filter 2: The knockout question

Somewhere in most application forms sits a question: "Are you legally authorized to work in the United States?"

If you are applying as a would-be employee and you answer honestly, the application ends right there. Not because a human read your CV and decided against you. Because a form gate closed. You never find out. This single checkbox kills more qualified international applicants than every skills gap combined.

You do not beat it by lying. You beat it by not being an employee. When you position yourself as an independent contractor who invoices the company, the question changes from "can this person legally be our employee" (hard, expensive, immigration lawyers) to "can we pay this vendor's invoice" (yes, accounting does it every day). Same developer. Same skills. Different door entirely.

Practically, that means saying it early and plainly: a line near the top of your CV like "Independent contractor, invoices directly, 4+ hours daily overlap with US time zones." You are answering the company's quiet worry before it forms.

Filter 3: Six seconds against six hundred applicants

A popular US remote role gets hundreds to a couple thousand applications. The human scanning the pile gives each CV a few seconds on the first pass. Whatever your CV needs to say, it has to say it in those seconds, in the first lines, or it has said nothing.

The CVs I see from European seniors are built for a different reader. Photo, long education section, four pages, every project since 2012, and a summary that says "passionate software engineer with strong communication skills", which appears on fifty thousand other CVs and carries zero bits of information.

What survives the six-second scan is outcomes with numbers in the first fifteen lines. "Led migration of 186 services to AWS, zero downtime." "Built payment infrastructure processing 3M transactions/month." Ownership, scale, results. Not who you are. What you did.

This is not fair, and it does not measure engineering skill, and it is also simply how the pile gets processed. The good news hiding in it: the fix is packaging, not talent. I have watched the same engineer go from silence to interviews without gaining a single new skill. The experience was always there. The first fifteen lines finally showed it.

What this adds up to

The silence was never a verdict on your ability. It is three mechanical filters doing what they were built to do: a market where most listings were never open to you, a checkbox that ends honest employee applications automatically, and a reading process that gives you six seconds you were not built for.

Every one of those is beatable, and none of the fixes require becoming a better engineer. Aim only at globally open roles. Position as a contractor and say so early. Rebuild the first fifteen lines around outcomes. Then reach actual humans instead of piles, which is a whole topic of its own.

The developers landing US remote contracts from abroad are not the most talented ones. They are the ones who understood which doors were real and showed up legible. That can be you with embarrassingly little additional effort, aimed in the right direction.

I wrote a free guide that goes deeper on exactly this, the honest version I tell developers one at a time: get it here. And if you have questions, comments, I read everything.

The Most Promising IT Careers in 2026: A Senior Developer's Unfiltered Take

Wed, 01 Jul 2026 09:44:45 +0000

I've spent 10+ years building systems at scale. I've seen three industry cycles. This is what I actually see happening—not the LinkedIn fantasy.

Full Transparency: Who I Am and Why You Should Listen

I'm a senior backend architect. I've led teams that built systems handling millions of concurrent users. I've debugged production incidents at 3 AM that cost companies six figures per hour. I've hired hundreds of developers and watched talented ones become obsolete and mid-level ones become invaluable.

I'm not selling courses. I'm not building an online brand. I'm simply laying out what I see in the actual market, without the marketing gloss.

This analysis comes from watching the 2026-2027 AI wave hit the industry head-on. Not predictions. Observations.

The Uncomfortable Truth

Everyone's panicking about AI replacing developers. They're right to panic—but only if they're in the wrong specialization.

In 2026-2027, AI tools (Claude, ChatGPT, Cursor, specialized code agents) crossed a critical threshold: they became genuinely competent at generating production-grade code. That's not hype. That's what's happening right now.

But here's what separates the fearful from the informed: AI is replacing certain developers while making others dramatically more valuable.

The difference isn't talent or work ethic. It's architectural understanding—the ability to think beyond code generation.

I've seen this play out in real time. And I'm going to tell you exactly how it works.

The IT Landscape: Five Main Territories

Let me cut through the noise and map out the actual job market, not the LinkedIn fantasy version.

1. Software Development (Backend + Frontend)

Creating applications, websites, mobile apps, cloud services. The most populated sector.

Core Languages: Python, JavaScript, TypeScript, Go, Rust, Java, C++, Swift, Dart/Flutter

What It Actually Involves: Writing business logic, debugging production systems, maintaining codebases that grow to millions of lines.

2. Data Science & Machine Learning

Processing massive datasets, building ML models, training neural networks, implementing production AI systems.

Reality Check: This is where AI is being built, not where it's replacing people.

3. DevOps & Infrastructure Engineering

Automating server deployment, managing cloud infrastructure (AWS, GCP, Azure), building CI/CD pipelines, ensuring systems stay online.

The Truth: This field is thriving. Every AI startup needs infrastructure engineers.

4. Cybersecurity (Blue Team & Red Team)

Defending against attacks, penetration testing, vulnerability assessment, incident response.

Why It Matters: Attackers use AI. Defenders need humans who understand both offense and defense.

5. Quality Assurance & Testing

Automated testing, manual testing, test framework development.

Status: Partially automated already, but complex QA still requires human judgment.

The Two-Part Framework: Frontend vs Backend

This is where the real story lives. Let me be brutally honest.

Frontend Development: Already Being Replaced

What it is: Building user interfaces. HTML, CSS, JavaScript. Creating the visual experience users interact with.

Why I'm blunt about this: Frontend is pure pattern-matching. Design a button? That's CSS you've written 100 times. Make it responsive? Bootstrap grid. Validation? Every form looks the same. Connect to an API? Fetch request template.

These aren't engineering problems. These are commodity tasks.

Frontend Task: "Build a login form with email validation and password strength indicator"

What I see happening:
- Claude generates working code: 2 minutes
- Vercel deploys it: 30 seconds
- A startup is shipping with zero frontend engineers: Done
- Time to proficiency: 3 months before you're replaceable
- Salary: $60k–$100k (not growing, actually shrinking)

What I'm actually observing in 2026-2027: I've watched junior frontend developers struggle to justify their positions. Not because they're bad—because their entire job has become automatable by a $20/month Claude subscription.

I hired a junior frontend dev last year. Six months in, I realized 90% of their PRs were patterns that Claude could generate. The other 10%? Accessibility and design decisions—which is not coding, it's UX thinking.

A non-technical founder today can:

Ask Claude to build a UI
Ask Cursor to debug it
Deploy to Vercel
Ship the product with zero engineers

I'm not being dramatic. I've watched this happen three times in my network in the last six months.

Prognosis: Frontend positions will contract. Teams that needed 5 frontend engineers will need 1 senior engineer + AI tooling. The 4 others? Redundant.

Backend Development: The Line AI Can't Cross (Yet)

What it is: Server-side logic, databases, APIs, data processing, system architecture. The invisible machinery that everything depends on.

Why it's different from frontend: This isn't pattern-matching. This is engineering. Real engineering—the kind where your decisions determine if a system survives at scale or collapses.

Backend Task (Easy): "Build a REST API that reads from PostgreSQL"
AI Capability: ✅ Done in 90 minutes. Deployed and working.

Backend Task (Real): "Build a distributed transaction system handling 100k concurrent users 
with guaranteed data consistency and sub-100ms latency across three regions, 
that survives AWS region failures without losing data"

AI Capability: ❌ Scaffold only. The hard part is untouched.
What AI can't do: Architectural decisions. Failure modes. Understanding why your naive 
                 implementation will catastrophically fail under load.

Here's what I've learned after 10+ years of this:

Simple API? Claude generates it correctly. Probably ships faster than you could write it.

System where a bug costs your company $10M? AI gets you 60% there. The remaining 40% is where engineering actually lives:

Anticipating failure modes that haven't happened yet
Designing for recovery when things will fail (not if, when)
Database schema decisions that determine if you scale to 1M users or hit a wall at 100k
Understanding transaction isolation levels deeply enough to avoid phantom reads you didn't know were possible
Building observability and monitoring that catches problems before your customers do
Handling the weird edge cases that only appear in production at 3 AM on a Tuesday

I've seen AI-generated systems fail spectacularly because they missed the "boring" parts—proper connection pooling, circuit breakers, timeout handling, graceful degradation.

I've also seen junior developers write code that technically works but will collapse the moment it hits real load. The difference between them and senior engineers? Experience with failure. Understanding why things break.

Time to proficiency: 3–5 years of actual production experience before you can design systems that don't fail.

Salary trajectory: $120k–$250k+, and this is accelerating because the supply of people who understand scale is critically short.

The Specialization Matrix: Future-Proof Roles

Here's what actually survives AI disruption:

Specialization	AI Threat Level	Salary Trajectory	Why It Survives
Frontend (Junior)	🔴 CRITICAL	Declining	Pattern-based, repetitive
Frontend (Senior/Architect)	🟡 MEDIUM	Stable	UX decisions, accessibility, complex interactions
Backend (Mid-level)	🟡 MEDIUM	Growing	Commodity APIs vulnerable, specialized systems not
Backend (Senior/Architect)	🟢 SAFE	Rapidly Growing	System design, reliability, scale
DevOps Engineer	🟢 SAFE	Rapidly Growing	Every company needs infrastructure; AI can't replace decision-making
ML/AI Engineer	🟢 SAFE	Skyrocketing	Building the AI that replaces others
Security Engineer	🟢 SAFE	Skyrocketing	Attackers and defenders in arms race
QA Engineer	🟡 MEDIUM	Declining	Automated testing replaces manual; complex scenarios need humans

The Backend Hierarchy: Who Survives, Who Doesn't

Let me be more precise about backend specializations, because this is where nuance matters.

The Vulnerable: REST API Developers

If your entire job is:

"Write CRUD endpoints"
"Connect database queries to HTTP responses"
"Add basic validation"

Status: Replaceable by AI in 2–3 years.

Claude can generate a functional Express/FastAPI/Spring REST API with database integration in under 5 minutes. Adding basic auth? 10 minutes.

The Valuable: Systems Engineers

If your job is:

"Design databases that handle 1M+ concurrent users"
"Debug race conditions in distributed systems"
"Build real-time notification systems with delivery guarantees"
"Optimize query performance on 500TB datasets"
"Design fault-tolerant microservice architectures"

Status: More in-demand than ever.

Why? Because when things fail in production at scale, you need someone who has spent thousands of hours understanding why systems fail. AI can suggest fixes. Humans with deep experience prevent the failures in the first place.

The Honest Rankings: 2026 Career Prospects

Tier 1: Future-Proof (Growing Demand)

DevOps/Infrastructure Engineers

Every company with more than 20 engineers needs robust infrastructure
Cloud complexity is increasing, not decreasing
AI automates routine ops work, but architecture decisions remain human-driven
Salary: $120k–$180k, accelerating

Machine Learning Engineers

You're building the AI that others fear
Requires mathematical rigor that AI struggles with
Production ML systems need engineers who understand data pipelines, model drift, feature engineering
Salary: $150k–$250k+, skyrocketing

Senior Backend Architects (5+ years experience)

Enterprise systems depend on reliability, not just functionality
Architectural decisions made by someone who understands failure modes
AI excels at implementation; humans needed for design
Salary: $180k–$300k+, stable and high

Security Engineers

Cybersecurity is an arms race: attackers use AI, defenders must too
Understanding both offense and defense is irreplaceable
Salary: $130k–$220k, growing

Tier 2: Transitional (Stable But Contracting)

Mid-Level Backend Developers (3–5 years)

Vulnerable to AI-assisted small startups
Still valuable at large enterprises with complex codebases
Must specialize or move into architecture
Salary: $100k–$150k, plateauing

QA Engineers (Manual Testing)

Automated testing frameworks are consuming this space
Specialists in complex domain testing (financial systems, medical devices) remain valuable
Salary: $70k–$110k, declining

Tier 3: At Risk (Declining Demand)

Junior Frontend Developers (0–2 years)

Entry barrier is collapsing
A non-technical person can now ask Claude to build their MVP
Only valuable if you specialize: accessibility expert, performance specialist, animation specialist
Salary: $50k–$80k, declining

CRUD API Developers (Unmotivated Backend Developers)

Writing boilerplate REST endpoints that any AI can generate
No specialization, no depth, no innovation
Salary: $70k–$100k, rapidly declining

When Will AI Actually Replace You?

Spoiler: It already has, but maybe not you specifically.

The Timeline (What's Happening Right Now)

2026-2027 (This is where we are):

AI code generation is already standard. Not aspirational—standard.
I'm watching teams replace 3 junior developers with 1 senior + Claude
CRUD APIs aren't entry-level jobs anymore—they're not jobs at all
Junior frontend positions are vanishing from job boards
Mid-level developers without specialization are starting to feel real pressure
Senior architects and specialists are in a feeding frenzy for jobs

2027-2028 (Next 12 months):

The squeeze accelerates. Demand for junior positions contracts 50%+
Bootcamp graduates face harsh reality: "Hello World" skills aren't hireable
Teams restructure. 10 engineers become 5 engineers + AI tooling
The skill bifurcation becomes visible: specialists thriving, generalists struggling

2029-2030 (If trends continue):

AI handles 95% of commodity code work
Only architecture and specialized work remains
Developer salaries bifurcate: senior specialists at $250k+, juniors can't find work
The industry realizes you can't grow future seniors from juniors anymore—there's no middle rung

Who Gets Replaced?

✅ Will be replaced:

Copy-paste CRUD API developers
Vanilla frontend developers
"I just follow tutorials" developers
Junior developers with zero specialization

❌ Won't be replaced:

Engineers who understand system design at scale
Specialists in their domain (fintech, healthcare, gaming)
People who mentored others and grew juniors into seniors
Engineers who understand why systems fail
People who build the infrastructure others depend on

The Strategic Move: What to Do Right Now (Before It's Too Late)

If you're learning to code and considering a bootcamp: Don't waste your time on frontend. Seriously.

I see it every day—bootcamp graduates can build a React component. So can Claude. In 2026-2027, that's not a skill, that's background noise.

If you want to enter tech, you have maybe 18 months before the junior market completely dries up. Here's what actually works:

Option 1: Go Deep on Backend Systems

Learn how databases actually work (not just SQL queries—indexes, transactions, MVCC)
Understand distributed systems at a fundamental level (CAP theorem, consensus, failure modes)
Build something that handles scale (even if it's a toy project, make it scale to 1M users)
Read papers: Dynamo, BigTable, Google's Spanner
This takes 2–3 years, but you become unfireable

Option 2: Specialize in DevOps/Infrastructure

Every company with engineers needs someone who makes the systems work
Learn Kubernetes deeply. Actually understand it, not just copy-paste manifests
Terraform, infrastructure-as-code, all the ops tooling
This is harder to automate than frontend, demand is growing
$120k+ entry, rapidly ascending

Option 3: ML/AI Engineering

If you have mathematical foundation, this is wide open
You're building the tools that replace other developers
Requires depth in linear algebra, statistics, and understanding production ML pipelines
Supply is critically short. Demand is infinite.
$150k+, fastest growing salary bracket

If you're already a mid-level developer (3–5 years in):

The truth I tell people at this level: Generalist days are over.

Specialize in something that matters — "Full-stack" means "I'm good at nothing in particular." That's dangerous now.
Pick a vertical and own it — Payment systems? Databases? Real-time systems? Distributed tracing? Choose one. Become the expert.
Stop writing boilerplate — If you're still writing CRUD endpoints, you're building your own replacement. Push to work on the hard problems.
Start mentoring — I mean actually mentoring. Teaching juniors how to think about systems, not just copy-paste code. That's where value lives now.
Understand your system's failure modes — Can you tell me exactly how your system fails if one database goes down? If not, you're not a backend engineer yet; you're just a code typist.

The uncomfortable truth I don't like saying: I've watched talented mid-level developers become obsolete because they never went deep on anything. They're competent everywhere, expert nowhere. That's a losing strategy now.

The Uncomfortable Conclusion

AI isn't going to replace all developers. It's going to replace certain kinds of developers.

The ones writing boilerplate. The ones who never went deeper than pattern-matching. The ones who didn't specialize.

It's exactly like how photography didn't eliminate painters—it eliminated hack portrait artists. Real painters? They became more valuable. Your job is to become a real engineer, not a code monkey.

If your entire value proposition is "I can write code," you're in trouble. If your value is "I can design systems that work reliably at scale," you're golden.

The next 18 months will clarify this. Teams that thought they needed 10 engineers will downsize to 3. The 3 will use AI as their co-pilot, not their replacement.

The Brutal Tier List (Updated 2026-2027)

This is what I actually see happening in the market right now:

S-Tier (Bulletproof):
  🔥 ML/AI Engineers (supply < 10% of demand)
  🔥 Senior Backend Architects (6+ years, proven scale experience)
  🔥 DevOps/Infrastructure Specialists (every company needs them)
  🔥 Security Engineers (Red Team & Blue Team, both needed)
  
  Reality: These people get multiple offers per month. Salaries climbing 20% annually.

A-Tier (Safe):
  ✅ Mid-Level Backend Specialists with a vertical (payment systems, databases, etc.)
  ✅ Experienced Infrastructure Architects
  ✅ Domain Experts in regulated industries (Fintech, Healthcare, Aerospace)
  
  Reality: Stable employment, growing salaries, in-demand but not frenzied.

B-Tier (Weathering):
  ⚠️ Junior Backend Developers (need to specialize within 2 years)
  ⚠️ Specialized Frontend Engineers (UX/accessibility/performance experts)
  ⚠️ QA Specialists (complex domain testing only)
  
  Reality: Still employable, but market is tightening. The clock is ticking.

C-Tier (Obsolete):
  ❌ Generic CRUD API Developers (replaceable by Claude + script)
  ❌ Junior Frontend Developers (any bootcamp grad can do this with Claude)
  ❌ "Full-stack" Generalists (good at nothing, expert at nothing)
  ❌ Test Code Monkeys (AI generates tests now)
  
  Reality: I'm watching these positions disappear. Fast.

The Final Word (From Someone Who's Lived This)

The IT industry isn't contracting. It's stratifying violently.

The top 15% of engineers are becoming more valuable than ever. The bottom 60%? They're becoming functionally unemployable because a $20/month Claude subscription can do what they do.

This isn't cruelty. This is just what happens when commodity work becomes automatable.

The difference between a mid-level developer who adapts and one who doesn't isn't IQ. It's whether they're willing to specialize instead of generalize. Whether they can sit down and really understand a problem domain instead of just pattern-matching solutions.

Here's what I tell people who ask me:

If you're building a career in software engineering in 2026-2027, you need to make a choice:

Become a specialist — Own a vertical. Become the expert. Be indispensable.
Become an architect — Understand systems at scale. Know how things fail and how to prevent failure.
Become a multiplier — Mentor others, build frameworks, make better developers. The value isn't in your code; it's in other people's code being better because of you.

Or accept that you'll be competing with free AI for wages that are headed down, not up.

I know that sounds harsh. But I'm 10+ years in, I've hired hundreds of people, and I'm watching this play out in real time. Harsh is honest. And right now, honesty is the best advice I can give.

The uncomfortable truth: "I can write code" is no longer a competitive advantage. It's table stakes. The question now is: what can you do that AI can't?

Can you design a system that survives failure? Can you mentor juniors into seniors? Can you understand a domain deeply enough to spot edge cases AI misses? Can you think in constraints and make tradeoffs that matter?

If yes: you're golden.

If no: you have 12–18 months to figure it out before the market decides for you.

Your move. What's your strategy? 👇

AI-Ready APIs: Bridging Semantic Ranking, API Reviews, and the MCP Standard

Wed, 01 Jul 2026 06:47:34 +0000

Hey developers and full-stack builders,
When we build and deploy APIs, npm packages, or custom developer utilities, our focus is naturally on writing clean code, maintaining REST/GraphQL standards, and ensuring fast response times.
But there is a massive new architectural challenge: How do we ensure our APIs, codebases, and developer tools are actually discoverable, understood, and cited by AI coding assistants (like Cursor, Claude Code) and conversational search engines (like Perplexity)?
Traditional keyword-based search optimization is no longer enough. To get your technical products cited, you must understand the intersection of API reviews, semantic ranking algorithms, and the newly emerging Model Context Protocol (MCP) standard.
Here is a technical overview of how these three pillars operate together to automate AI-agent indexing.

The Power of Semantic Ranking
AI search engines do not crawl your website looking for raw keyword matching. Instead, their neural networks use embeddings and vector databases to map the semantic intent of a query directly to the most mathematically relevant "entity nodes" on the web.
To rank semantically:
Your API documentation must be structured with highly descriptive, natural language headings ("H2" and "H3" tags) that state exactly what your API does and how it solves specific developer problems.
Your site must use deeply nested JSON-LD Schema Markup (specifically TechArticle and SoftwareApplication schemas) to serve as a pre-formatted, machine-readable dataset that LLMs can parse with zero latency.
Leveraging Structured API Reviews
AI engines look for positive developer sentiment and third-party validation to decide which developer tools to recommend.
Co-Citations: By encouraging structured, peer-reviewed documentations on trusted developer platforms, you create a network of high-authority co-citations.
The Trust Loop: When a developer writes about how they successfully integrated your API, search engines associate your brand's endpoint with active, successful programming workflows, significantly boosting your semantic authority.
The New Standard: Model Context Protocol (MCP)
Developed by Anthropic, the open-source Model Context Protocol (MCP) acts like a "USB-C port for AI applications." It standardizes how local LLM assistants securely read, edit, and query data sources, custom APIs, and developer workspaces.
By building and hosting an open-source MCP server for your API, you completely bypass the need for developers to manually write complex, custom connectors for different AI tools. An AI assistant can securely query your API endpoints directly through the MCP standard, making your product the native, go-to resource in any AI-driven development workflow.
Architecting Your Developer-to-AI Pipeline
To build a fully compliant, future-proof directory for your APIs, we have laid out the complete technical playbook.
Our comprehensive guide explores the deep-tech infrastructure of semantic search indexing, the mechanics of MCP integration, and how to structure your development files to maximize your AI visibility:
👉 Read the Full Technical Guide about AI-Ready APIs on SEOSiri
I'd love to hear from other developers and full-stack builders here:
Are any of you already building or hosting an open-source MCP server for your APIs or SaaS products? How has integrating with standard protocols like MCP impacted your product's developer adoption and AI search discovery? Let's trade notes!

Building for Africa

Fri, 19 Jun 2026 02:49:02 +0000

Most devs infrastructure products are built assuming:

Fast internet
Unlimited bandwidth
US/Europe users
But millions of users aren't in those conditions.
That's one reason we're building PixoraCloud differently.

Building for Africa?
What's your biggest performance challenge

PixoraCloud | Media Delivery Platform

Fri, 19 Jun 2026 00:45:01 +0000

Uploading media shouldn't be complicated.

PixoraCloud gives you a simple way to upload images, videos, and files using a clean API and intuitive dashboard.

No unnecessary setup.
No confusing workflows.

Just upload and keep building.

Join the waitlist:
pixoracloud.pxxl.click

The AI Hype vs Reality

Wed, 17 Jun 2026 11:46:19 +0000

Before learning to code: "AI will replace all developers!"

After learning to code: "AI can't even figure out why my npm install broke for the 47th time."

AI: Generates whole apps in seconds
Also AI: Suggests using a deprecated package from 2015

We're safe, folks. For now. 😂

What's something AI has completely failed at for you? Drop it below! 👇

Best Gifts for Programmers in 2026: A Developer's Wish List

Wed, 10 Jun 2026 09:02:37 +0000

The best gifts for programmers in 2026 combine humor, utility, and genuine value—think premium developer apparel, mechanical keyboards, productivity tools, and thoughtful gadgets that coders actually use. Developers want gifts that respect their time, celebrate their culture, and improve their craft, not generic "tech guy" merch gathering dust on a shelf.

Whether you're looking for developer gifts for a senior backend engineer, coding gifts 2026 style for a data scientist leveling up, or team swag for an engineering department, this guide covers the categories that genuinely resonate with developers—including why certain gifts for software engineers land and others fall flat.

Understanding What Developers Actually Want

Before diving into specific gift ideas, let's talk about the gap between what people think developers want and what they actually want.

According to Stack Overflow's 2024 Developer Survey, 78% of developers prioritize tools and experiences that save them time or improve their workflow. Unlike other professions, developers aren't looking for status symbols—they're looking for functionality, inside jokes, and things that let them do what they love better.

The unspoken rule: If a developer has to think about it, it's not a good gift. Good gifts either improve their code, make them laugh, or improve their quality of life. Ideally, they do all three.

Developer Apparel & Wearables (The No-Brainer Category)

Why Developer T-Shirts Make Great Gifts

Programmer t-shirts aren't just apparel—they're wearable documentation of developer culture. A well-designed programmer t-shirt tells a story, signals belonging to the dev community, and gives coders a way to express their identity at work or at meetups.

But here's the catch: most developer tees are cringey, cheap, or so niche that only 3 people on Earth understand the reference. The good ones hit the sweet spot between insider humor and universal relatability.

What makes a great developer t-shirt:

The joke lands for both experienced and junior developers
The design is subtle enough for meetings but fun enough for casual Fridays
The fabric is actually premium (ringspun cotton, pre-shrunk, not paper-thin)
The size range accommodates all developers, not just "Medium Dude"

Code Culture specializes in apparel designed by developers for developers—where every shirt includes a genuine punchline and premium construction. Here are some standouts:

Must-Have Developer Shirts

It Works On My Machine Shirt — The universal developer moment. This shirt has landed with everyone from junior devs in their first sprint to architects running production systems. It's funny because it's true—every developer has said this exact phrase at least once, usually while a senior engineer gives them the look.

AI Can't Replace Me Shirt — Perfect for 2026, when AI tooling is everywhere but developers are still irreplaceable. Wear it to code reviews, AI hype conversations, or just when you need a confidence boost. A conversation starter that shows developers aren't sleeping on the AI wave—they're riding it.

Prompt Engineer Shirt — For the developers who've realized that knowing how to talk to ChatGPT is half the battle. It's self-aware about the changing dev landscape while celebrating the actual skill that matters: writing good prompts (and knowing when to ignore them).

Vibe Coding Shirt — For developers who code by feel, intuition, and vibes. It speaks to the newer generation of coders who write code that works without fully understanding the entire stack—and that's okay.

Debug Grafitti Shirt — A celebration of the debugging grind. Developers spend as much time hunting bugs as they do writing code. This design acknowledges that beautiful, messy process.

Work From Home Daily Text Shirt — For the post-2020 developer who now codes from home, coffee bar, or anywhere. It's a subtle flex about the remote-first dev life and works for anyone who's made WFH permanent.

Why These Gifts Work

Quality matters. Code Culture's shirts use:

Ringspun cotton — softer and more durable than standard cotton
Pre-shrinking — consistent sizing across washes
Reinforced stitching — designed for the wear patterns of real developers (strong shoulders and sleeves for the constant keyboard typing slouch)
Global sizing — from XS to 3XL, designed for all body types

Pro tip: Developers wear what's comfortable and beautiful. Cheap cotton that gets chalky after three washes won't make anyone happy, no matter how funny the design is.

Mechanical Keyboards (The Productivity Gateway)

A mechanical keyboard is one of the rare gifts that genuinely improves daily work for developers. If a developer spends 8+ hours a day typing code, a keyboard upgrade goes from luxury to essential.

Why mechanical? The tactile feedback, the satisfying click, the ability to customize switches—it's the difference between a daily tool and something that becomes part of your process.

What to look for:

Switch type: Linear (smooth, quiet) vs. tactile (bumpy, feedback) vs. clicky (loud, satisfying). Most developers who've never tried mechanical prefer tactile.
Quality build: Stabilized spacebar, hotswap switches (so they can customize later), aluminum case
Layout: 65% or 75% layout is the sweet spot (compact but still has arrow keys)
Price range: $120–$250 for a solid entry-to-mid mechanical keyboard

Top recommendations: Keychron K8 Pro, Glorious GMMK 2, or NMB 87-key mechanical. If the developer is known to be a keyboard enthusiast, a custom keyboard kit is the gift that keeps giving.

The magic of a mechanical keyboard gift: it shows you understand that developers care about their tools, not just their code.

Desk Gadgets & Productivity Tools

Cable Organization Systems

Developers hate messy cables. A good cable organizer—whether it's a adhesive cable clips set, a cable sleeve system, or a desk-mounted cable management rack—solves a real problem on a real desk.

Why this works: It's practical, solves an immediate pain point, and shows you spent time thinking about the dev's actual workspace.

Monitor Arms

One monitor arm can transform a developer's posture and desk real estate. VESA-compatible monitor arms let you mount one or two monitors, freeing up desk space for actual work.

Top pick: Ergotron LX Monitor Arm (pricey but will last through multiple career moves).

Desk Lighting

The right desk lamp prevents eye strain during those deep-focus 4-hour coding sessions. Blue-light filtering, adjustable brightness, and no glare are table stakes.

Top pick: BenQ ScreenBar Plus (mounts on top of monitor, no desk space needed).

Microphone & Audio

For developers who pair program, do video calls, or stream their coding, a quality USB microphone (Blue Yeti, Audio-Technica AT2020) is genuinely appreciated. It signals that the gifter respects the dev's communication setup.

Subscriptions & Memberships

GitHub Copilot or IDE Extensions

A one-year GitHub Copilot subscription ($100/year) is brilliant for any developer, especially mid-career engineers ramping up. It's the gift that improves their code every single day.

Books That Actually Get Read

Not all developer books are created equal. Forget the 1,000-page algorithms tomes gathering dust. Instead, focus on books that:

Are actually readable — Finished in 2-3 weeks, not 6 months
Solve real problems — Not abstract theory, but practical stuff they'll use tomorrow
Match their career stage — A senior architect doesn't need "Introduction to Python"

Top Developer Books for 2026

"The Pragmatic Programmer" (2nd edition) — Updated for modern dev. Even if they've read the original, the 2nd edition is worth it. Practical wisdom that transcends language.
"System Design Interview" by Alex Xu — If they're prepping for interviews or designing systems, this book is pure gold.
"Staff Engineer" by Will Larson — For mid-career developers aiming for staff/principal roles. Incredibly practical and sets expectations.
"Clean Code" by Robert C. Martin — If they haven't read it, they should. If they have, they're already in your gift debt.
"Designing Data-Intensive Applications" by Martin Kleppmann — For backend engineers and data folks. Dense but life-changing.

Pro tip: Pair the book with a $20 Amazon gift card so they can grab coffee while reading, or include a bookmark from Code Culture.

Experiences & Team Gifts

Conference or Meetup Registration

A ticket to a developer conference ($500–$2,000) is a high-touch gift that says I believe in your growth. Add a Code Culture shirt for the conference and they're your brand ambassador.

Team Swag & Culture

Engineering managers and team leads: bulk gifts of quality Code Culture apparel for your team build culture in a way generic corporate swag never will. Developers will actually wear these, actually enjoy them, and actually represent the brand.

The Gift That Doesn't Work (And Why)

Before we close: here's what not to give a developer:

Generic "programmer" merch with clip art — Low quality, unfunny, and disrespectful to their taste. They'd rather get nothing.
USB hubs or cable adapters they don't need — Unless you know for certain they need it, skip it. Too practical-without-purpose.
Anything with "Keep Calm and Code On" or faded comic sans — In 2026, vintage meme shirts aged poorly. If the design isn't timeless, it won't be worn.
Tech books that are too niche — A book on Rust compiler internals is a gift for one specific developer, not a general developer gift.
Mouse or keyboard without asking first — Peripherals are deeply personal. An ergonomic keyboard that's wrong for someone's hand shape is worse than no gift.

The Shortcut Gift Finder

If you have $20-50: Developer t-shirt from Code Culture (humor + quality + immediate wearability)

If you have $50-150: Mechanical keyboard (entry-level Keychron) + developer shirt combo

If you have $150-300: Mid-range mechanical keyboard (Glorious GMMK) + monitor arm

If you have $300+: JetBrains subscription + mechanical keyboard + Code Culture apparel collection

FAQ: Gifts for Programmers

What are the best gifts for programmers?

The best gifts for programmers combine function and humor: quality developer apparel that tells an inside joke, mechanical keyboards that improve their typing experience, subscriptions to tools they use daily (GitHub Copilot, JetBrains IDEs), practical desk gadgets that solve workspace problems, and books that they'll actually finish. The underlying principle is: does this gift improve their code, their day, or make them feel seen as a developer? If yes, it's a good gift.

What do software engineers actually want as gifts?

Software engineers want gifts that respect their expertise and autonomy. They want tools (mechanical keyboards, monitor arms), professional development (conference tickets, subscriptions), and apparel that celebrates dev culture without being cringey. Avoid anything that screams "I don't know tech people, so I bought this generic computer joke mug." Instead, think about what actually lands: developer humor that's specific enough to be funny, quality that matches their standards, and utility they'll use daily.

Are coding t-shirts a good gift for developers?

Yes, if the quality is there. A premium developer t-shirt from Code Culture—made with ringspun cotton, pre-shrunk, with genuine developer humor—is an excellent gift. It's immediately wearable, celebrates dev culture, and works at the office or at meetups. The catch: cheap printed tees with outdated memes don't land. Developers have taste. Meeting that standard is what separates thoughtful gifts from gifts that end up in donation piles.

Final Thoughts

Gifting to developers is actually simpler than you think: respect their expertise, celebrate their culture, and give them something that improves their day. Whether that's apparel, tools, or experiences, the best gifts are the ones that say I see you, I respect what you do, and I'm supporting your growth.

And if you're a developer reading this: take note of what speaks to you. Share this list with whoever does your gift-giving. The fact that you're reading a gift guide means you deserve gifts that actually land.

Looking for the perfect developer gift right now? Browse Code Culture's full collection and find apparel that celebrates what makes developer culture unique. Every shirt tells a story—make sure your gift tells the right one.

Learn more about Code Culture's mission to celebrate developer culture on our About page.

What’s Your Real-Time Defense Against Hallucinations and Prompt Attacks?

Sun, 17 May 2026 04:36:13 +0000

I am curious how teams are solving this in production. If an LLM gives a hallucinated answer or gets hit by prompt injection/jailbreak attempts, what happens before or after it reaches the user?

Do developers usually rely on tools like LangSmith, Guardrails, Llama Guard, custom middleware, human review, RAG verification, or shadow-model checking? And if a bad response already reaches the user, how do teams detect it, fix it, and prevent the same failure again?

Would love to hear how people are actually handling this in real-world LLM apps.

Why I Started Taking Web Development More Seriously

Sat, 25 Apr 2026 07:07:30 +0000

My interest in web development didn’t start with code; it started with curiosity.

I used to look at different websites and wonder how everything worked behind the scenes. From simple layouts to complex features, it made me realize that there’s more than what we see as users. That curiosity slowly turned into a desire to understand and eventually create something on my own.

As I learned more, I began to see how important websites are today. Almost every business, personal brand, or community relies on an online presence. That made me realize that web development is not just a technical skill, but something practical and valuable in the real world.

What makes it even more interesting is the creative freedom. Building a website is not only about writing code, but it’s also about turning ideas into something real. Whether it’s a blog, a portfolio, or a simple web app, every project is an opportunity to experiment and improve.

At the same time, I also discovered that this field is full of challenges. From understanding logic and algorithms to solving unexpected bugs, there’s always something to figure out. But instead of being frustrating, it became something I enjoy. The process of solving problems and learning from them is what keeps me going.

In the end, learning web development is more than just a technical journey. It’s about curiosity, creativity, and continuous growth.

If you’re curious about what led me to take this path more seriously, I shared the full story here: Why I Started Taking Web Development More Seriously

Understanding CopilotKit Agent Patterns: A Comprehensive Guide

Sat, 25 Apr 2026 06:55:22 +0000

What is the CopilotKit Agent Patterns Skill?

The CopilotKit Agent Patterns skill is a comprehensive framework designed to help developers build AI agents that seamlessly integrate with CopilotKit’s ecosystem. This skill provides 20 well-defined rules across five critical categories, offering guidance on everything from agent architecture to generative UI emission.

Why This Skill Matters

When building AI agents that need to interact with CopilotKit’s runtime and frontend components, developers face numerous challenges around state management, event streaming, and user interaction patterns. This skill addresses these challenges by providing battle-tested patterns that ensure reliable agent behavior and smooth integration with CopilotKit’s AG-UI protocol.

Key Components of the Skill

Five Priority Categories

The skill organizes its 20 rules into five priority categories, each with a specific prefix to help developers quickly identify the type of guidance they need:

Agent Architecture (CRITICAL) – Rules prefixed with architecture-
AG-UI Protocol (HIGH) – Rules prefixed with agui-
State Management (HIGH) – Rules prefixed with state-
Human-in-the-Loop (MEDIUM) – Rules prefixed with hitl-
Generative UI Emission (MEDIUM) – Rules prefixed with genui-

When to Apply These Patterns

The skill is particularly valuable when you’re:

Designing agent architecture for CopilotKit integration
Implementing AG-UI protocol event streaming
Managing state synchronization between agent and frontend
Adding human-in-the-loop checkpoints to agent workflows
Emitting tool calls that render generative UI in the frontend

https://github.com/openclaw/skills/tree/main/skills/generaljerel/copilotkit-agent-patterns/SKILL.mdThe

FSCSS introduction

Sat, 28 Mar 2026 11:28:57 +0000

FSCSS (Figured Shorthand Cascading Style Sheet) is a styling approach designed to simplify CSS by using shorthand techniques. It allows developers to write more concise and efficient styles, reducing redundancy and improving readability.

Key Features of FSCSS:

Shorthand Methods: Techniques like %2 allow multiple properties to share the same value.
Rapid Tag Formatting (rtF): Enables quick styling of multiple elements.
Animation Efficiency: Provides a compact way to define animations.
Script Integration: Works with FSCSS-specific scripts to streamline styling.

FSCSS is particularly useful for projects that require clean and maintainable CSS structures.
NPM package
vscode extention.
Projects series
Website

Building a Fuel Route Optimization API with Django, Redis & OpenRouteService

Thu, 12 Feb 2026 23:04:35 +0000

Last night, I challenged myself to solve a very practical problem:

How do you find the cheapest fuel stops along a driving route between two cities?

At first, it sounded simple.

Until I opened the fuel station dataset and realized…

It had no coordinates.

That’s when this turned from a simple API into a deep dive into:

Routing
Geocoding
Spatial matching
Caching
Performance engineering

The Core Idea

Given:

Start Address → End Address as a string or list of coordinates

The system should:

Geocode both addresses using OpenRouteService
Fetch the driving route polyline
Build a route corridor using bounding boxes along the path
Match fuel stations from a CSV dataset that fall inside this corridor
Return the cheapest stations along the trip

No coordinates in the dataset? No problem. We make the map logic do the work.

⚡ The Performance Problem

Geocoding and routing APIs are expensive and slow.

So I introduced Redis caching:

Addresses are geocoded once and cached forever
Routes are cached
Fuel stations are loaded into memory using Pandas

And here’s the fun part:

❌ No database
❌ No GIS server
✅ Pure spatial computation in memory

After the first request, response times drop to under 150ms.

️ Stack Used

Django + DRF
Redis
Pandas
GeoPandas
OpenRouteService API
Spatial math (without PostGIS)

Key Engineering Lessons

Normalize messy data instead of bending your logic around it
Cache aggressively when dealing with external APIs
You don’t always need a database for spatial problems
Bounding boxes + in-memory data can be incredibly fast

This project genuinely felt like building a mini map engine from scratch.

Best AI Tools for Code Reviews

Tue, 10 Feb 2026 06:22:38 +0000

Stop wasting hours on manual code reviews — let AI handle the heavy lifting ⚡

In this video, we break down 4 powerful AI code review tools that help developers write cleaner, more secure code before it even reaches a pull request:

GitHub Copilot – Write smarter code with fewer bugs
⚡ Cursor – Understands your entire codebase for better refactoring
DeepCode (Snyk) – Detect vulnerabilities before they hit production
☁️ Amazon Q Developer – Built for AWS with security-first insights

Whether you're a solo developer or part of a fast-moving team, these tools can boost productivity, improve code quality, and speed up your workflow.

Which AI tool are you using for code reviews?

The Developer Identity Crisis

Mon, 09 Feb 2026 04:22:47 +0000

I keep seeing variations of this pitch everywhere:

“A bug report hits Jira at 3 AM? Your autonomous agent wakes up, reproduces it, writes the fix, and opens the PR before your alarm goes off.”

That’s from Zencoder’s marketing site. But it’s not just marketing anymore, developers are actually doing this. They’re using tools like Zencoder, Claude code, Openclaw, and others to delegate entire features or bug fixes to AI agents that run autonomously while they sleep.

The workflow is straightforward: assign a GitHub issue to the agent, let it work overnight in a sandboxed environment, wake up to a pull request with passing tests, review the diff, merge it.

The tests pass. The code works. They ship it.

And here’s the part that keeps me up at night: many of them admit they don’t fully understand every implementation detail. They review for correctness and patterns, but not line-by-line comprehension. And they’re shipping faster because of it.

I’ve been thinking about this for weeks. Because I can’t do that. Not yet.

My Workflow Isn’t There Yet

I use AI constantly. Claude Code and orchestrators like OpenClaw, they’ve transformed how I work. I can spin up features that would have taken days in a fraction of the time. The productivity gains are real.

But I still review everything. I still read the diffs. I still make sure I understand what went into the codebase before I approve it. I don’t merge code I haven’t checked.

And here’s the uncomfortable part: I’m starting to wonder if that makes me slow.

Because I’m watching people who don’t review everything. They’re shipping faster. They’re building more. And their code… works. Their products ship. Their companies grow.

The question that keeps me up at night isn’t “can AI code?” anymore. It’s: how much can I trust it before my caution becomes a liability?

The Job Changed Underneath Us

If you’ve been coding for more than a few years, you’ve felt it. The ground shifted. What we do day-to-day looks fundamentally different than it did even 18 months ago.

We used to write code. Now we orchestrate AI agents that write code.

We used to debug line by line. Now we describe the bug and let the agent fix it.

We used to refactor carefully. Now we prompt for a rewrite and evaluate the output.

The transformation isn’t subtle anymore. AI agent tools crossed some threshold. They’re not assistants anymore, they’re doing the actual work.

And here’s what nobody wants to say out loud: they’re often better at it than we are. Faster, definitely. More thorough in edge cases. Less prone to the lazy shortcuts we take when we’re tired.

The role of “software developer” didn’t disappear. It just became something else entirely. We’re now:

Task organizers — Breaking down requirements into agent-friendly chunks
Configuration engineers — Building rules, skills, and context for AI systems
Quality evaluators — Reviewing output for correctness, not writing it ourselves
Visibility champions — Advocating for our work because “just coding” is invisible now

If you’re a developer who just wants to code in peace, I have bad news for you: that job is disappearing.

The Pioneers Are Already There

I’m not imagining this shift. Some of the sharpest minds in our industry are actively building for a future where human code review might be optional and their work reveals just how far the transformation has already gone.

Steve Yegge’s Gas Town: The Industrial Coding Factory

Steve Yegge—the legendary blogger who gave us classics like “Stevey’s Google Platforms Rant”—recently launched Gas Town, what he calls “a new take on the IDE for 2026.” It’s not an IDE in any traditional sense. It’s an orchestrator for running dozens of Claude Code instances simultaneously.

In his words: “Gas Town is an industrialized coding factory manned by superintelligent robot chimps.”

He describes an 8-stage evolution of the AI-assisted developer, from basic code completions all the way to running 10+ agents at once. If you’re not at stage 6 or 7? “You will not be able to use Gas Town. You aren’t ready yet.”

Yegge also created Beads, a persistent memory system for coding agents. Because when you’re running that many agents, you need infrastructure just to keep track of what they know. He’s literally building Kubernetes for AI coders.

The pattern he describes: Prompt → Sleep → Evaluate → Keep or Toss. Work becomes “an uncountable substance that you sling around freely, like slopping shiny fish into wooden barrels at the docks.”

That’s not coding as we knew it. That’s something else entirely. And Yegge’s doing it right now.

ThePrimeagen’s 99: The Neovim Purist’s Answer

On the other end of the spectrum, ThePrimeagen, known for his Neovim evangelism, launched 99, which he describes as “the AI agent that Neovim deserves.”

His philosophy is different from the full-orchestration approach. 99 is built for developers “who don’t have skill issues”, those people who want AI integrated into their existing workflow, not replacing it. It’s about restricted AI interactions: fill in a function, handle a visual selection, stop when you want.

The interesting part? Even ThePrimeagen, arguably one of the most skilled traditional developers in the content space, is building AI tooling. He’s not fighting the wave; he’s figuring out how to ride it on his own terms.

These aren’t fringe experiments. These are serious developers building serious tools because they see what’s coming.

Caught in the Middle

So where does that leave people like me?

I see where this is going. I believe the future probably shifts heavily toward these “prompt and trust” workflows. The economics are too compelling. The speed advantages are too real. Companies will gravitate toward developers who ship faster, and right now, that means developers who trust AI more.

But I’m not there yet. And I’m honestly not sure if my reluctance is:

Wisdom: A healthy caution born from experience with software that breaks in subtle ways
Ego: An attachment to feeling like a “real programmer” who understands their code
Fear: Discomfort with a world where my hard-won skills matter less

Maybe it’s all three.

The honest truth is: I don’t fully trust AI-generated code yet. Not because I’ve seen it fail catastrophically. But because the few times I have caught issues, they were subtle. The kind of bugs that pass tests but cause problems in production. The kind that make you question everything you didn’t review carefully.

And yet… those catches are getting rarer. The AI is getting better. Every month the code quality improves, the edge cases get handled more gracefully, the architecture decisions get more sensible.

At what point does my reviewing become theater? At what point am I just going through the motions because it feels wrong not to, even though I’m not actually catching anything?

I don’t have an answer.

The Uncomfortable Truths We’re Not Talking About

Whether you’re in the “trust fully” camp or the “review everything” camp, some things are happening to all of us.

Skill Atrophy is Real

I’ve noticed it in myself. There are language features I used to know cold that I now… don’t. Not because I forgot them entirely, but because I haven’t actually typed them as often. The AI does it.

When I do need to write code without AI assistance, I’m slower. Rustier. More likely to look things up that used to be automatic.

Is this a problem? I don’t know. Maybe these skills don’t matter anymore. Maybe they do. But either way, they’re fading.

The Carelessness Creep

Even when I review code, I’ve caught myself being less thorough than I used to be. When the AI can regenerate something in seconds, the stakes for any individual piece feel lower. Made a mistake? Trash it and re-prompt.

This creeping carelessness scares me. Not because every line needs to be perfect, but because I’ve noticed myself letting things slide that I wouldn’t have before. Small things. Subtle things. The kind of issues that compound.

Code Review Culture is Fragmenting

Here’s where it gets really weird: people are using AI to review code too.

On one hand, this is powerful. AI can catch patterns and issues that humans miss. But on the other hand… we’re now in a loop where AI writes code and AI reviews code and humans just glance at both and click approve.

What happens when we stop deeply understanding the systems we’re building? When code becomes something we orchestrate but don’t really know?

The Disposable Code Question

Maybe code quality just doesn’t matter the way it used to.

If AI can rewrite a module in 30 seconds, why spend hours making it elegant? Why obsess over structure, readability, maintainability? Just make it work. When it breaks or needs to change, throw it away and regenerate it.

This feels wrong to me. But I can’t articulate exactly why. Maybe I’m just attached to an old way of working. Maybe “good code” was always just a means to an end, and now there’s a faster means.

Maybe code doesn’t need to be human-readable anymore. Maybe it just needs to be AI-readable. And maybe that’s fine.

I genuinely don’t know.

The Paradox: Embrace or Fall Behind

Here’s the impossible choice: embrace AI coding fully and potentially lose something essential, or maintain your review discipline and risk becoming irrelevant.

If you don’t use these tools you’re objectively slower than colleagues who trust more and verify less. You deliver less. You look less productive. In a world where companies are cutting costs and measuring output, that’s not sustainable.

But if you do embrace them fully, you risk becoming dependent. Losing skills. Becoming someone who can’t actually code anymore, just prompt.

I’m trying to find a middle path. Use AI heavily for generation, but maintain understanding. Trust but verify. It’s uncomfortable. It might not be sustainable. But it’s where I am right now.

And here’s the kicker: the job now requires something that coding alone never did: visibility.

It’s not enough to do good work. You have to be seen doing it. You have to advocate. Document. Communicate impact. Build relationships. The IC who just crushes code tickets in silence? That person is becoming a liability, because from the outside, it’s unclear what AI could or couldn’t do in their place.

What Even Is a Developer Anymore?

Here’s where I diverge from the panic.

A lot of developers are having an identity crisis because “AI can code now.” But honestly? I always thought being a developer was about more than writing code.

The job was never just about typing syntax. It was always about:

Knowing what to build (strategic thinking)
Knowing how to break it down (task decomposition)
Knowing how to evaluate quality (critical judgment)
Knowing how to communicate impact (visibility)

Coding was just the tool we used to execute on those skills. A really important tool, sure.

What’s happening now is that the tool is changing. The execution layer is being automated. But the thinking, the judgment, the strategy? That’s still ours.

If anything, AI is forcing the industry to acknowledge what good developers have always known: the hard part was never the syntax. It was figuring out what to build, why it matters, and whether it actually works.

The developers freaking out about “AI replacing us” are often the ones who built their identity entirely around code execution. And I get it, that was the most visible, most measurable part of the job. It’s what we practiced, what we got good at, what differentiated us.

But it was never the whole job. And now we’re being forced to reckon with that.

We’re the Canary in the Coal Mine

Software developers are experiencing this transformation first not because we’re special, but because we’re closest to the technology. We use AI to automate our own work. Of course it’s impacting us fastest.

But every profession is next.

The writer using AI to draft articles. The designer using AI to generate concepts. The analyst using AI to build models. The lawyer using AI to review contracts.

Everyone is about to face their own version of this identity crisis: “What is my job when AI can do the execution better than I can?”

We don’t have answers yet. We’re navigating in real-time, making it up as we go.

Navigating the Blur

I don’t have a clean conclusion here. No five-step framework for staying relevant. No confident prediction about where this goes.

What I do know:

The technology won’t slow down. We can’t wish our way back to a simpler time.

Skills still matter, but which ones is shifting. Deep technical knowledge isn’t obsolete, but it might not be sufficient anymore.

Intentionality is everything. We can drift into AI dependency without thinking, or we can engage with these tools critically, keeping what works, discarding what doesn’t, staying honest about trade-offs.

Trust isn’t binary. I’m somewhere on the spectrum between “review every line” and “ship without looking.” That’s probably where most of us are. And that’s okay, we’re all calibrating in real-time.

We’re figuring this out together. Nobody has it solved. The developers who seem most confident are probably just better at hiding their uncertainty.

The job is changing. Our identity as developers is changing with it. The only way through is acknowledging the discomfort and navigating it intentionally.

I still check the code. I still review the diffs. Maybe that makes me slow. Maybe that makes me careful. Maybe it’s just how I’m wired.

But I’m watching the people who don’t. And I’m taking notes.

We’re in uncharted territory.

And honestly? That’s both terrifying and kind of exciting.

What’s your experience with this shift? Are you in the “trust fully” camp, the “review everything” camp, or somewhere in between like me? I’d genuinely love to hear how other developers are navigating this.

The post The Developer Identity Crisis appeared first on sudoish.

Is AI Actually Making You Faster?

Mon, 09 Feb 2026 04:22:40 +0000

AI in software development is getting insanely powerful.

LLMs, copilots, agents, multi-step workflows…

…on paper, it all looks like massive productivity gains. And sometimes it is. But in practice, I’ve seen something very different happen over and over again: developers actually lose time, not gain it.

The main reason is simple:
AI can produce code that looks correct, works on the surface, and is confidently explained, but is subtly wrong.

And those subtle mistakes are often the most expensive ones.

The real problem: distance from the code

With modern AI tools, it’s very easy to become distant from the actual codebase.

Instead of designing, reasoning, and implementing, we:

write a big prompt
wait for a large chunk of code
skim it quickly
trust that “the AI probably knows better”

The code often runs. Tests might even pass. And the AI will confidently tell you the solution is solid and production-ready.
The amount of agents and MCPs added to the AI coding tool is so big nowadays that it is increasingly harder to discover where things could go wrong. And worse, developers tend to trust it more and more because it gives the sense that the ideal prompt, rules, and custom agents will be able to handle hallucination properly.

That’s where the danger is.

Because now you still have to read the whole implementation of a code a stranger has written, understand it, validate edge cases, debug weird behavior and repeat until things work as expected.

Except now you’re doing it while fighting authority bias — there’s an “expert” telling you everything is fine.

This is not faster. It’s verification debt.
It actually transforms developers into code reviewers of new cocky and condescending dev (the AI.

Here is one dummy example to illustrate this:

There is a feature in the backend that is used everywhere in the app. This function performs its action and then run some costly observability tasks.
These observability tasks should run in the background because the caller of the function doesn’t care about its response.
The correct approach is to schedule that extra processing asynchronously, fire and forget.

But the AI-generated code did something very subtle:
it awaited that processing instead of scheduling it as a background task.

In Python terms, think:

what should have been asyncio.create_task(...)
was instead written as await some_processing()

The result?

Everything still worked
No obvious errors
But every single call was now slower
Latency quietly increased across the system

This may be an easy bug to catch, but imagine how subtle bugs like this may pile up and get lost in the mix?

This happens because when developers rely too much on AI, they tend to read on the surface, not line by line. And with large outputs, that tendency gets even worse.

This hurts everyone, from juniors to seniors

For junior developers, this is especially dangerous.

If you rely too much on AI early on, you tend to skip the learning phase, you don’t build strong mental models and you accept solutions that you don’t fully understand.

But this isn’t just a junior problem.

For experienced developers, the risk is skill atrophy.
If you stop practicing fundamentals and let AI do most of the thinking you will most likely lose your instincts, code reviews get softer and your ability to spot subtle issues declines.

And then validating AI output becomes harder and harder, exactly when it matters most.

Ok, but what can we do now?

First rule: ask yourself if you even need AI here

One habit I find extremely important is this:

Before using AI, ask yourself:

“Is this actually faster with AI, or am I just outsourcing thinking?”

There are many cases where writing the code yourself is faster, clearer and safer, especially for core business logic, performance-critical paths, concurrency, security-sensitive code.

On the other hand, AI is excellent at things such as UI scaffolding, boilerplate, repetitive glue code, predictable transformations and, my favorite, reviewing my implementation helping me spot bugs.

Use it where it shines. Don’t force it everywhere.

Design first, then let AI fill the boring gaps

A strategy that works extremely well is this:

You design the structure. The AI fills in the details.

As an intermediate or senior developer, you usually already know what you want to build at a high level.

For example, a simple contact page:

frontend contact form
validation
backend API
database table
persistence logic

You don’t need the AI to decide what exists.
You already know that.

Instead:

define the structure yourself
break it into small, clear pieces
ask the AI to implement one piece at a time

This keeps context small, hallucinations lower, review manageable and you engaged with the code.

And it’s much faster than crafting one massive prompt and reviewing a massive output.

Small prompts, small context, small steps

Large prompts produce large hallucinations.

If you want better results:

reduce context
reduce scope
reduce responsibility per prompt

Instead of:

“Implement the entire feature end-to-end”

Try:

“Generate the frontend form UI”
“Add input validation for these fields”
“Implement this API handler with these constraints”
“Write tests for this specific behavior”

You stay in control, and the AI becomes a focused assistant — not an architect making assumptions for you.

Use TDD as a guardrail (not as dogma)

One very powerful pattern is combining AI with TDD-style thinking.

You don’t even need to be strict TDD.

Just:

define acceptance criteria
define what “correct” means
ask the AI to help write tests first (or alongside the code)

Tests force:

clarity
explicit behavior
less hand-wavy logic

They also give you confidence that the AI didn’t just produce something that looks right.

Automate the boring validation

Linters, formatters, type checkers, static analysis — all of these matter even more with AI-generated code.

Humans skim.
Tools don’t.

Let automation catch bad patterns, unsafe constructs, incorrect usage and inconsistent styles.

These are cheap guardrails that pay off immediately. Additionally, these can easily become default rules for the ai in your project or personal configuration.

Stay sharp: practice fundamentals on purpose

Here’s something I strongly believe:

The more AI advances, the more important fundamentals become.

If you’re not practicing DSA, system design, concurrency basics, you slowly lose the ability to judge whether a solution is good or not.

One simple habit I highly recommend:

one LeetCode problem a day

It doesn’t have to be intense.
Just enough to keep your brain in shape.

It makes you more engaged with code and more critical during reviews. It also helps you to be more capable of spotting subtle issues and better at validating AI output.

And yes, it also helps when reviewing code written by teammates who are also using AI.

AI is a power tool not autopilot

AI is incredible.
It can make you much more productive.

But only if you stay engaged, keep thinking, keep practicing and stay in the driver’s seat. The goal isn’t to fight AI. The goal is to use it deliberately, with good habits and strong guardrails.

Otherwise you’re not saving time, you’re just postponing the cost.

The post Is AI Actually Making You Faster? appeared first on sudoish.

10 Real-World Side Projects That Actually Impress Recruiters

Mon, 26 Jan 2026 22:52:41 +0000

10 Real-World Side Projects That Actually Impress Recruiters (With Examples)

Many developers believe that building *any* side project is enough to stand out. In reality, recruiters see hundreds of portfolios filled with to-do apps, weather dashboards, and tutorial clones. What truly makes a difference is not the number of projects — but how real, practical, and problem-driven they are.

In this article, we’ll explore 10 real-world side projects that recruiters consistently find impressive — because they demonstrate problem-solving, system thinking, and real-world engineering skills.

Why Recruiters Care About Side Projects

Side projects act as proof of work. They show how you think, how you structure code, how you handle trade-offs, and whether you can ship something usable. A strong project answers questions like:

Can this developer solve real problems?
Do they understand users, not just code?
Can they take a product from idea to deployment?

Let’s dive into the projects that consistently catch recruiters’ attention.

1. Job Application Tracker for Developers

What it solves:
Managing job applications across emails, spreadsheets, and portals is painful.

Why recruiters like it:
Shows CRUD skills, authentication, dashboards, filters, and real user value.

Example features:

Track application status (Applied, Interview, Offer)
Attach resumes, notes, and follow-up reminders
Analytics on response rates

2. SaaS Billing & Subscription Simulator

What it solves:
Understanding real-world SaaS billing logic.

Why recruiters like it:
Demonstrates backend complexity, payment flows, edge cases, and scalability thinking.

Subscription plans & upgrades
Invoices, retries, cancellations
Role-based access control

3. Community Platform for a Niche Audience

What it solves:
People want focused communities, not noisy platforms.

Why recruiters like it:
Shows full-stack thinking, moderation logic, engagement design.

Posts, comments, likes
User profiles and roles
Reporting and moderation tools

4. Open-Source Contribution Dashboard

What it solves:
Tracking open-source activity across repositories.

Why recruiters like it:
Shows API integration, data visualization, and OSS mindset.

5. Internal Tool for Small Businesses

What it solves:
Manual workflows inside small teams.

Why recruiters like it:
Internal tools mirror real engineering work more than consumer apps.

6. Real-Time Collaboration App

What it solves:
Live collaboration needs (docs, boards, code notes).

Why recruiters like it:
Demonstrates WebSockets, concurrency, and performance concerns.

7. DevOps Monitoring & Alert Tool

What it solves:
Visibility into system health.

Why recruiters like it:
Shows infra knowledge beyond frontend/backend silos.

8. AI-Powered Resume or Code Reviewer

What it solves:
Actionable feedback for developers.

Why recruiters like it:
Shows modern tooling, prompt design, and evaluation logic.

9. Learning Progress Tracker

What it solves:
Tracking skill growth over time.

Why recruiters like it:
Shows long-term thinking and user retention concepts.

10. Technical Writing Platform

What it solves:
Helping developers share knowledge clearly.

Why recruiters like it:
Strong signal of communication + engineering maturity.

How to Make Your Project Stand Out

Solve a real problem (even your own)
Write about your decisions and trade-offs
Show iterations, not just final polish
Document learnings and failures

Final Thought

Side projects don’t need to be massive — they need to be real, intentional, and visible. If you’re building something meaningful, don’t keep it hidden. Write about it, share it, and invite feedback.

Publishing your journey turns projects into opportunities. That’s how developers stand out.

The Emotional UX of AI: What Developers Miss

Sun, 25 Jan 2026 03:10:29 +0000

Most AI products are evaluated on technical metrics.

Accuracy.
Latency.
Cost.
Throughput.

Those matter.

But they don’t explain why some AI products feel trustworthy and others feel exhausting, even when the underlying intelligence is similar.

The missing layer is emotional UX.

And most developers underestimate it because it’s invisible, hard to quantify, and rarely discussed in engineering terms.

AI Systems Create Emotional States: Whether You Design for Them or Not

Every interaction with an AI system leaves a residue.

Confidence.
Doubt.
Relief.
Anxiety.
Frustration.

These reactions accumulate over time.

Users don’t just ask:

“Did this work?”

They feel:

“Can I rely on this?”
“Do I need to double-check everything?”
“Is this helping me or making me nervous?”

That emotional response determines adoption more than raw capability.

Why Technical Correctness Is Not Enough

An AI system can be statistically accurate and still fail emotionally.

Common emotional failure modes:

the AI sounds overconfident when it’s wrong
the AI is inconsistent across similar situations
errors feel random instead of explainable
the system interrupts at the wrong time
users don’t know when they should trust it

Each of these creates low-grade anxiety.

Users may continue using the product, but they never relax.

That’s a UX failure.

Confidence Is the Most Important Output of an AI System

This is counterintuitive for developers.

We think the output is:

text
decisions
actions

For users, the real output is confidence.

Confidence that:

the system behaves predictably
errors are manageable
responsibility is clear
nothing catastrophic will happen silently

If your AI reduces confidence, it increases cognitive load, even if it “works.”

Overconfidence Is More Damaging Than Inaccuracy

One of the biggest emotional mistakes AI systems make is false certainty.

When AI:

gives definitive answers without caveats
hides uncertainty
avoids saying “I don’t know”

Users lose trust faster.

They would rather work with:

a system that is sometimes unsure

than

a system that is confidently wrong

Emotional safety comes from honesty, not bravado.

Inconsistency Feels Like Betrayal

Humans are surprisingly tolerant of imperfection.

They are not tolerant of unpredictability.

If an AI:

behaves differently today than yesterday
handles similar inputs differently
changes tone or behavior without warning

Users feel betrayed, even if performance improves overall.

Consistency is not just a technical metric.

It’s an emotional contract.

Tone and Timing Matter More Than Explanations

Developers often try to fix emotional issues by adding explanations.

But most emotional UX problems are about:

when the AI intervenes
how it communicates
how much it says

A perfectly reasoned explanation delivered at the wrong moment still feels wrong.

Calm timing beats verbose justification.

Why Users Hate “Surprise Intelligence”

Unexpected AI behavior triggers anxiety.

When the system:

takes action without warning
changes outcomes silently
optimizes in ways users didn’t ask for

People feel out of control.

Invisible AI must be emotionally legible—even if it’s not explicit.

Users should never wonder:

“Why did this happen?”

Silence is only acceptable when behavior is predictable.

Emotional UX Is Built Through Defaults and Boundaries

Most emotional signals are not in the UI.

They live in:

default behaviors
escalation thresholds
failure modes
undo mechanisms
how errors are surfaced

A simple “undo” can eliminate fear.

A clear boundary can eliminate hesitation.

These are emotional design decisions, not technical ones.

Why Developers Often Miss This Layer

Emotional UX doesn’t show up in logs.

It doesn’t trigger alerts.

It doesn’t break builds.

But it quietly determines:

long-term retention
trust
willingness to delegate
product advocacy

By the time metrics move, the emotional damage is already done.

Designing for Emotional Safety Is a Leadership Skill

This is not about empathy copy.

It’s about:

respecting user psychology
designing predictable systems
avoiding unnecessary surprise
signaling uncertainty appropriately

Great AI products don’t make users feel impressed.

They make users feel safe.

The Real Takeaway

The most important question in AI UX isn’t:

“Is this smart?”

It’s:

“How does this make the user feel over time?”

If your AI:

increases confidence
reduces anxiety
behaves predictably
fails gracefully

Users will trust it, even when it’s imperfect.

If it doesn’t, no amount of intelligence will save it.

That’s the emotional UX of AI.

And it’s the layer most developers miss, until it’s too late.

The Rise of Private AI Models: What It Means for Developers

Mon, 19 Jan 2026 02:17:06 +0000

For a long time, AI followed a familiar arc.

Centralised models.
Shared infrastructure.
Public APIs.
One-size-fits-most intelligence.

That phase is ending.

Quietly, but decisively, the industry is moving toward private AI models, and this shift will change how developers build, deploy, and think about software.

Not in theory.
In practice.

Why Centralized AI Is Hitting Its Limits

Public AI models are powerful, but they come with structural constraints.

They struggle with:

deep domain specificity
proprietary data
strict compliance requirements
predictable behavior under risk
long-term context ownership

For many real-world systems, “good on average” is not good enough.

Enter private AI models.

What “Private AI” Actually Means (And What It Doesn’t)

Private AI does not necessarily mean:

training massive models from scratch
owning data centers
replacing foundation models

In most cases, it means:

fine-tuned or adapted models
controlled deployment environments
domain-specific intelligence
isolated data boundaries
predictable, governed behavior

Private AI is less about raw power and more about control.

Why This Shift Is Accelerating Now

Several forces are converging:

Data sensitivity is increasing

Enterprises can’t send everything to shared models.

Regulatory pressure is real

Auditability, explainability, and data residency matter.

AI is moving into decision-critical workflows

“Close enough” outputs are no longer acceptable.

Cost predictability matters

Private deployments offer more stable economics at scale.

Together, these forces make centralized AI insufficient for serious use cases.

What This Means for Developers

This shift fundamentally changes the developer’s role.

Developers are no longer just:

calling APIs
tuning prompts
handling responses

They are increasingly responsible for:

defining intelligence boundaries
managing model lifecycle
designing evaluation pipelines
enforcing constraints
integrating domain logic

In short: developers become stewards of intelligence, not just consumers of it.

From Prompting to Model Ownership

With private AI, prompts stop being the primary control mechanism.

Instead, control moves to:

training data selection
fine-tuning strategy
retrieval design
policy layers
eval-driven iteration

This is a shift from interaction, level control to system, level control.

Developers who understand this transition early will have a significant advantage.

Why Private AI Raises the Bar for Engineering Discipline

Private AI systems don’t benefit from “black box forgiveness.”

When something goes wrong, teams must answer:

why the model behaved this way
what data influenced the outcome
how behavior changed over time
who approved the update

That requires:

versioning
observability
evaluation harnesses
reproducibility

In other words, real engineering rigor.

The Trade-Off Most Developers Will Face

Private AI is not a free upgrade.

It introduces trade-offs:

more responsibility
more operational overhead
more design decisions
more accountability

But it also unlocks:

deeper customization
stronger trust
better alignment with real workflows
defensible differentiation

This is a classic leverage trade-off.

More ownership. More upside.

Why This Shift Favors Systems Thinkers

Private AI rewards developers who think in systems, not shortcuts.

The most valuable skills will be:

architecture design
data curation
evaluation strategy
failure-mode thinking
long-term maintenance planning

Developers who rely only on tools will struggle. Developers who design intelligence environments will thrive.

Where This Is Headed

In the coming years, we’ll see:

hybrid architectures (public + private AI)
domain-specific models becoming standard
AI behavior treated as a versioned artifact
intelligence managed like infrastructure

AI won’t disappear behind APIs. It will become part of the system you own.

The Real Takeaway

The rise of private AI models signals a maturation of the industry.

AI is moving from:

experimentation → operation
novelty → responsibility
access → ownership

For developers, this is not a threat.

It’s an opportunity to move up the stack.

Because the future won’t belong to those who simply use AI.

It will belong to those who can design, control, and operate intelligence responsibly. And private AI is where that future starts.

What No One Tells You About Building an AI SaaS Business

Sat, 17 Jan 2026 06:04:31 +0000

Building an AI SaaS business looks straightforward right now.

Pick a model.
Wrap it in a UI.
Add subscriptions.
Scale.

From the outside, it feels like the easiest era in history to launch software.

But the reality is harsher and more interesting.

Because what most people call “AI SaaS” is not SaaS in the traditional sense. It’s a different business shape with different constraints.

And if you treat it like ordinary SaaS, you’ll build something that looks good in a demo and struggles everywhere else.

Here’s what no one tells you, until you learn it the hard way.

1) Your Product Isn’t the App. It’s the Behavior.

Traditional SaaS sells:

features
workflows
dashboards
permissions

AI SaaS sells something subtler:

reliable behavior under uncertainty.

Users don’t just ask:
“Does it have the feature?”

They ask:

Will it behave consistently?
Will it break in edge cases?
Will it hallucinate confidently?
Can I trust it with real work?

This means your real product is not the interface.

It’s the system discipline behind the interface.

2) Demos Convert Interest. Reliability Converts Revenue.

AI demos are easy to make impressive.

A well-crafted prompt and a curated example can create magic.

But AI SaaS doesn’t survive on impressive moments. It survives on predictable outcomes.

Retention comes from:

consistent performance
graceful failure modes
clear boundaries
minimal surprises

In AI SaaS, you don’t lose customers because the model is weak. You lose them because the experience is inconsistent.

3) Your Biggest Competitor Is “Good Enough + Free.”

This is the brutal truth.

Many AI SaaS tools are competing against:

general-purpose AI assistants
built-in enterprise copilots
open-source alternatives
internal scripts teams already have

So the real competitive question is not:
“Is my model better?”

It’s:

Am I delivering a specific outcome that general AI cannot reliably deliver?

If your value is generic, your pricing power collapses.

4) Cost Structure Will Define Your Business More Than Features

In traditional SaaS, marginal cost is near zero.

In AI SaaS, marginal cost is real:

inference cost
tool calls
retrieval
data pipelines
evaluation
monitoring
guardrails

This changes everything.

Your pricing strategy is no longer just marketing. It’s survival.

Many AI SaaS founders learn this too late: they get traction, usage grows, and suddenly the business becomes financially unstable.

A product that scales usage but doesn’t scale margin is not a SaaS business. It’s a cost engine.

5) You’re Not Selling Software. You’re Selling Trust.

AI introduces uncertainty into places users want certainty.

So users watch for:

transparency
control
explainability
accountability

A serious AI SaaS must answer quietly, through design:

What happens when the AI is wrong?
Can the user override it?
Does it show confidence?
Does it escalate correctly?
Are decisions auditable?

Trust isn’t a feature. It’s the foundation of adoption.

6) Context Engineering Beats Prompt Engineering at Scale

Early-stage teams often obsess over prompts.

That’s fine for prototypes.

But at scale, the game changes.

You need:

persistent context
structured memory
domain constraints
policy layers
evaluation harnesses
behavioral consistency

In other words: context engineering.

If your product depends on users “prompting correctly,” it’s fragile.

AI SaaS must behave correctly even when users are messy, rushed, or unclear because that’s real life.

7) Integration Is the Real Moat, Not Intelligence

Most AI SaaS tools die because they sit outside the workflow.

Users don’t want “another AI tab.”

They want AI where work already happens:

email
docs
CRM
ticketing
code review
internal knowledge bases

If your AI SaaS is not embedded in the workflow, it becomes optional.

And optional products are the first to be cancelled.

8) The Hard Part Isn’t Building the Model Layer. It’s Building the Control Layer.

The control layer includes:

guardrails
permissions
role boundaries
escalation rules
monitoring
evals
safety constraints
logging

This is what turns AI from “interesting” into “operational.”

Most founders underestimate this because it doesn’t look exciting.

But this is where long-term companies are built.

9) Your GTM Isn’t “Launch and Grow.” It’s “Educate and Standardise.”

AI changes how users think.

They don’t know what’s possible.
They don’t know what’s safe.
They don’t know what to delegate.

So the strongest AI SaaS companies win by:

teaching mental models
standardising workflows
setting expectations
making adoption feel low-risk

In AI SaaS, marketing is not persuasion. It’s clarity.

10) The Real Secret: AI SaaS Isn’t SaaS Yet. It’s a New Category.

Traditional SaaS assumes:

deterministic software
stable outputs
predictable workflows

AI SaaS introduces:

probabilistic behavior
evolving systems
context dependence
continuous evaluation

So founders must build with a different mindset:

Not “ship features.” But “ship reliable behavior.”

Not “grow usage.” But “grow trust.”

Not “optimize onboarding.” But “optimize confidence.”

The Real Takeaway

Building an AI SaaS business is not easier than SaaS.

It’s harder in a different way.

The winners won’t be the ones who:

wrap a model fastest
ship the flashiest UI
ride hype cycles

They’ll be the ones who build:

trustworthy systems
sustainable margins
workflow-embedded value
clear behavioral boundaries
context that compounds

Because in the next phase of AI, intelligence will be abundant.

Trust and integration will be rare.

And that’s what real AI SaaS businesses will be built on!

Note: Building an AI SaaS system is possible; however, when you build the SaaS system, you should have ethical considerations at the centre. If you don't have ethics at the centre, then your model will work but won't have any trust.

Everything I share here about ethical consideration comes from real implementation. I’ve put the same practical approach into my Udemy Ethics AI Masterclass for anyone who wants to learn it end-to-end. Click here

The Truth About ‘Building in Public’: What No One Tells You

Sun, 23 Nov 2025 07:53:06 +0000

Everyone says:

Build in public.
Share your journey.
Be transparent.

But no one talks about how it actually feels.

In the beginning, I used to post like I was talking to myself,
No likes, no responses.

And honestly?
That’s where most people quit.

We see the big wins shared online:

“Just landed 1,000 users!”
“Launched my MVP!”
“Hit my first revenue milestone!”

Building in public looks like a badge of authenticity.
But behind those updates is a much quieter, more complicated emotional experience —
One that rarely makes it to the timeline.

So let’s talk about the part no one explains.

What Does “Building in Public” Actually Mean?

Building in public is a storytelling strategy.

It means sharing your journey, your wins, your mistakes, your experiments, as they happen.

Building in Public is:

Sharing stories (wins/losses)
Being vulnerable and transparent
Inspiring a community through honesty

Building in Public is not:

A shortcut to fame
A growth hack to go viral
A trick to get users fast

Why “Building in Public” Took Over the Internet

Around 2020–2021, something shifted.

Indie hackers and solo founders began sharing:

Revenue dashboards
Feature releases
Weekly learnings
MRR breakdowns

People like Pieter Levels, Arvid Kahl, and the Indie Hackers community didn’t just build products,
They built audiences by sharing the process.

Why did it resonate?

Authenticity felt refreshing compared to polished PR
It created accountability for solo builders
It formed communities around products before launch

From the outside, it looked like a cheat code:

"Share progress → Gain followers → Grow fast."

But if you’ve actually tried it, you know:

It’s never that simple.

The Hidden Pressure Behind Transparency

When you build in public, your journey stops being just yours.

You start documenting progress daily.
It creates an invisible pressure to keep proving you're still building.

When I started posting updates daily on X, it felt exciting.

But soon, something changed:

I wasn’t just building anymore.
I was performing progress.
On days I coded for hours but had nothing “tweet-worthy,” I felt like I had failed.
I wondered if the small audience watching me thought I had given up.

This was the hardest realization:

The more you think about what to share, the less you actually build.

I once spent 40 minutes crafting a tweet about a feature that took 10 minutes to code.

Not because the tweet mattered,
But because I wanted it to look like progress.

Soon, my decisions were influenced by metrics:

“Should I build this?” → Will this make a good update?
“Should I rest today?” → What if people think I stopped?

To fix this, I shifted from daily updates to weekly reflections.
Less pressure.
More meaning.
More real.

The Fear of Failing Publicly

When you fail privately, you close the tab and move on.

When you fail publicly, you feel like you have to announce your failure too.

And reality check:

Wins → get engagement
Failures → get silence

But here’s the truth:

A publicly shared failure teaches more than a polished success ever will.

Someone needs to see the part where you didn’t know what you were doing.

The Real Benefits (When Done Gently)

When approached with intention, building in public can be life-changing:

You attract people who resonate with your story.
You get feedback before launching.
You build trust, not hype.
You find collaborators, mentors, friends.

Once, I posted about something I was struggling with.

Someone DMed me:

“Thank you for saying this. I thought I was the only one.”

That felt more meaningful than any retweet count.

Build With the Public, Not For the Public

This is the shift:
Don’t share to impress.
Share to connect.

What you learned today

What broke and how you fixed it
A thought process behind a decision
Why you scrapped a feature

Your journey is supposed to inspire and support people, not drain you!

Final Thoughts

Building in public isn’t for everyone, and that’s okay.

Some seasons require silence.
Some require privacy.
Some require slow, unbroadcasted growth.

The key is to remember:

Build for yourself.
Share for others.
But never let the audience decide your pace.

Your Turn

Have you tried building in public?

Did it feel:

Exciting?
Exhausting?
Or both?

Share your experience below. I’d love to read it

Larry Ellison reveals why Oracle built a power plant to train AI - and what it means for developers.

Wed, 15 Oct 2025 00:20:30 +0000

Oracle's AI Vision: From 1.2 Billion Watts to Saving Lives

Oracle AI World delivered a message developers need to hear: AI isn't about replacing engineers. It's about building tools that solve humanity's hardest problems while making developers dramatically more productive.

The Infrastructure Reality

Larry Ellison opened with a stunning statistic: Oracle is building AI data centers consuming 1.2 billion watts of power. That's enough electricity to power a million four-bedroom homes.

The scale is staggering. Oracle's Abilene, Texas facility will house 450,000 NVIDIA GB200 GPUs when fully provisioned. The project started as empty land in June 2024 and began delivering GPUs in less than a year.

But here's what matters for developers: Oracle isn't just building infrastructure for infrastructure's sake. They're training more multimodal AI models than any other company - models that developers will use to solve real problems.

The Database + AI Integration

Ellison made a critical point that other cloud providers miss: publicly available training data isn't enough. AI models need access to private enterprise data to reach peak value.

Much of the world's high-value data already sits in Oracle databases. Oracle's strategy: make that private data accessible to AI models while keeping it secure and private.

The Oracle AI Database uses Retrieval-Augmented Generation (RAG) to vectorize any data - whether in Oracle databases, OCI object store, or even Amazon S3 - making it accessible for AI reasoning without exposing it to other customers.

For developers, this means:

No need to copy sensitive data to train models
AI can reason across both public and private data
Security boundaries remain intact
Models stay current with real-time data

Code Generation That Actually Works

Oracle's approach to AI code generation differs from competitors in one crucial way: every generated application is stateless, secure, and scalable by default.

Using Oracle APEX with AI generation, applications automatically include:

Zero security holes (the generator doesn't forget things)
Built-in reliability (stateless design means automatic failover)
Unlimited scalability (designed for millions of users from day one)
No single point of failure

Ellison noted that 80% of Oracle employees report AI has already improved their work quality. Internally, Oracle uses AI for:

Touchless expense automation
Invoice matching
AI-driven recruiting
Deal progression in sales
Real-time supply chain alerts

The productivity gains are enabling Oracle to rebuild Cerner's entire codebase, a quarter-century of healthcare software, using AI generation. All clinic operating code is already complete, with acute hospital systems planned for next year.

Real-World AI Agents

The keynotes showcased AI agents solving complex real-world problems, not toy demos.

Healthcare: Provider to Payer Integration

Oracle built an AI agent that solves a problem every healthcare provider faces: prescribe the best possible care that's fully reimbursable.

The agent:

Uses RAG to access latest medical literature and patient test results
Assists doctors in determining optimal care
Checks insurance policies to ensure full reimbursement
Handles exceptions (like UK NHS covering Ozempic only above certain BMI thresholds)
Provides banks with reimbursement data to extend credit to cash-strapped hospitals

This single agent addresses clinical care, insurance complexity, and hospital financing simultaneously - automating the entire healthcare ecosystem, not just the hospital.

Biofine Technologies: Fighting Antibiotic Resistance

Paulo from Biofine Technologies described using Oracle's vector database to save lives in Brazil.

Traditional bacterial testing takes five days. Biofine's solution:

Extracts bacterial DNA from patient samples
Creates vectors from millions of DNA elements
Uses Oracle's vector search across 700,000 bacterial DNA records
Identifies bacteria and antibiotic resistance in four hours

Results: mortality rates from bacterial infections dropped from 70% to 50%. Biofine expects to save 2,000 lives in Brazil in 2025 alone.

The vector approach handles bacterial mutations, finding close matches rather than requiring exact DNA sequences. This means identifying resistance patterns even for novel bacterial strains.

The Metagenomic Testing Vision

Ellison revealed work on a metagenomic testing device that could revolutionize pathogen detection.

Current PCR testing only works for known pathogens. If your test comes back negative, doctors simply don't know what you have.

The new device:

Sequences everything in a blood sample
Identifies any pathogen (bacteria, virus, fungus) even if novel
Detects circulating tumor DNA for early cancer diagnosis
Determines antibiotic resistance patterns
Costs low enough for widespread hospital deployment

For developers, this represents the power of AI-assisted genomic analysis. The device would have detected COVID-19 far earlier, providing pandemic early warning.

Ellison's point: if these devices existed in hospitals worldwide, we'd never be caught off guard by novel pathogens again.

Energy Sector Transformation

Calvin Butler from Exelon described managing one of America's largest electrical grids while embedding AI across operations.

The challenge: more transformation in the next 10 years than the previous 100 years. Every technology addition to the grid introduces security risks.

AI helps Exelon:

Predict outages before they happen
Communicate restoration times accurately
Manage preventive maintenance schedules
Optimize grid investments based on demand patterns

Butler emphasized that AI deployment isn't about reducing headcount - it's about capturing data and improving customer communication. The grid becomes smarter, not smaller.

Transportation: Avis Budget Group

Marius from Avis Budget Group explained why they jumped to Oracle Database 23ai despite being on a "highly deprecated version."

Their reasoning: if you're going to upgrade anyway, go to the version where Oracle is investing. The 23ai capabilities and roadmap aligned perfectly with Avis's business needs.

Using natural language queries, Avis employees become "problem solvers, not information gatherers." Instead of clicking through dashboards to slice and dice data, they ask questions directly and get answers immediately.

The goal: reduce the lag between observing a problem and taking action. AI gives back time - the most important commodity nobody controls.

Marius's metric for success: how quickly can you get to market with the right decisions? AI dramatically compresses that timeline.

Hospitality: Marriott's Human-First Approach

Ty from Marriott emphasized that AI isn't replacing human hospitality - it's enabling it.

The problem: checking someone into a Marriott property requires navigating dozens of systems. Front desk associates spend time on "swivel chair" data entry rather than engaging with guests.

Marriott's digital transformation creates a "single pane of glass" - unifying dozens of systems so associates can focus on people, not processes. Less time on keystrokes, more time sharing local recommendations and creating authentic connections.

The AI strategy started by asking associates: "What's the most painful part of your job?" Then deploying AI to fix those pain points. The result: contagious adoption as associates experience real improvements.

The Vector Database Breakthrough

Multiple speakers highlighted Oracle's vector database as the enabling technology.

For Biofine, vectors allow matching similar (not identical) bacterial DNA, handling mutations automatically.

For Marriott, vectors enable personalized guest recommendations based on preferences and history.

For Avis, vectors power natural language queries across complex operational data.

The pattern: vectorization makes unstructured data (DNA sequences, customer preferences, operational metrics) accessible for AI reasoning. Oracle's database handles the vectorization automatically for any data source.

Multimodal AI Architecture

Ellison explained that modern AI models mirror human brain structure, multiple neural networks handling different tasks:

Convolutional networks for vision (edges, color, motion)
Vision transformers for recognition
Large language models for reasoning
Specialized networks for mathematics

Like the brain's specialized regions (visual cortex, prefrontal lobe, language centers), AI models use specialized networks working together.

Oracle's infrastructure supports these multimodal models at scale - the 1.2 billion watts isn't excessive, it's necessary for reasoning at human (or superhuman) levels.

The Code Generation Philosophy

Oracle's code generation differs from competitors in approach. Rather than generating code directly from English (which Ellison calls "curiously imprecise"), Oracle created a declarative AI generation language in APEX.

The advantage: generated applications have consistent characteristics:

Stateless design (automatic failover)
Built-in security (no forgotten edge cases)
Designed for scale (millions of users)
Zero single points of failure

This matters because generated code becomes production code. If the generator produces brittle applications, you've automated technical debt creation.

Medical Devices and Robotics

Ellison revealed Oracle's work on medical robotics, arguing robots will be better surgeons than humans - not because they're smarter, but because they have better tools:

Microscopic vision (seeing individual cells without microscopes)
Perfect hand-eye coordination
Ability to cut between healthy and cancerous cell layers

For Mohs surgery (removing facial cancer lesions), robots can see exactly where cancer ends and healthy tissue begins, enabling more precise removal with better cosmetic results.

The implication for developers: AI-assisted medical devices represent a massive opportunity. The challenge isn't just training models - it's building reliable, safe systems where errors have life-or-death consequences.

The Greenhouse Vision

Ellison described Oracle's robotic greenhouses - buildings that are actually inflatable structures held up by positive air pressure.

The advantages:

90% less water than traditional farming
Grows food year-round
Locates near population centers (fresher food, lower CO2 transport)
No human contamination of growing areas
Robots move plants as they grow

For developers, this represents AI-orchestrated physical systems. The robots decide when to move plants, when to harvest, how to optimize growing conditions.

The same structure could serve as a Martian habitat - fold it up, transport it on a SpaceX rocket, inflate it on Mars. Ellison wasn't entirely joking about that possibility.

Climate Engineering with AI

Perhaps the most ambitious vision: using AI to engineer crops that manage atmospheric CO2.

Wheat modified by AI produces 20% more grain per acre while converting more CO2 into calcium carbonate (the mineral in coral reefs). The CO2 gets removed from the atmosphere permanently.

If deployed globally, modified wheat could reduce atmospheric CO2 from 440 parts per million to 400 - essentially managing the climate through enhanced photosynthesis.

The engineering challenge: designing plants that:

Produce more food
Consume more CO2
Convert CO2 to stable minerals
Maintain nutritional value

This isn't theoretical - Ellison's Wild Bio (part of Oxford's Ellison Institute) has already created wheat that produces 20% more grain per acre.

Autonomous Drones

Oracle built an air traffic control system for medical specimen delivery drones.

The system uses RFID tags to maintain chain of custody while protecting privacy - nobody knows whose blood sample is in transit, but the system ensures it reaches the right lab and results return to the right doctor.

Beyond medical delivery, the drones can:

Detect forest fires via infrared cameras
Identify arsonists who set fires
Follow suspects in police chases (safer than high-speed pursuits)
Search for lost hikers

For developers, this represents the challenge of building reliable autonomous systems operating in physical environments with safety implications.

What This Means for Developers

Oracle's AI World message: the infrastructure is ready. The models are trained. The database can vectorize your private data securely.

Now what are you going to build?

The examples from the keynotes show the pattern:

Identify a complex problem (antibiotic resistance, healthcare reimbursement, grid management)
Connect AI models to relevant private data via vector search
Build agents that orchestrate multi-step processes
Deploy at scale using Oracle's infrastructure

The competitive advantage won't come from having access to AI models - everyone will have that. It will come from:

Speed of implementation
Quality of private data integration
Sophistication of agent orchestration
Reliability of production deployment

Oracle's bet: developers who can connect AI models to real business data and build reliable agents will solve problems that were previously intractable.

The 1.2 billion watts of power isn't about showing off. It's about giving developers the computational foundation to build applications that change industries, save lives, and solve humanity's hardest problems.

That's the real AI revolution - not chatbots, but tools that let developers tackle challenges we couldn't solve before.

RavenDB's database-native AI agents turn months of development into days of deployment.

Mon, 08 Sep 2025 19:47:04 +0000

RavenDB Cuts AI Agent Development from Months to Days with Database-Native Solution

Enterprise AI projects have a problem. While consumers can plan meals or design trips with ChatGPT in seconds, businesses still rely on rigid chatbots that can't access real operational data.

RavenDB just announced a solution that could change this. Their new AI Agent Creator runs agents directly inside the database, giving developers secure access to live data without the usual integration headaches.

Why Most Enterprise AI Projects Fail

MIT research shows 95% of enterprise AI projects fail to deliver business impact. The issue isn't with the AI models themselves. It's the complexity of embedding them into existing workflows and data systems.

Traditional approaches require moving data to external servers, writing complex integration code, and dealing with security concerns. This turns what should be a quick proof of concept into months of development work.

How Database-Native AI Agents Work

RavenDB's approach keeps AI agents close to the data. When a user makes a request in natural language, the agent processes it using the database's existing business logic and validation rules.

The system follows a zero-trust model. No data or operations are accessible unless explicitly approved by developers. This gives teams control over what each agent can do while maintaining security.

The agents work with any large language model and include smart caching to reduce redundant requests. This cuts AI costs while maintaining accuracy.

Real-World Impact

Oren Eini, RavenDB's CEO, points to the gap between consumer AI experiences and enterprise reality. "Consumers can get advice from AI platforms in seconds, yet enterprises are stuck with scripted chatbots," he said.

The AI Agent Creator changes this by letting developers build production-ready agents in days instead of months. Teams can go from idea to proof of concept in minutes.

What This Means for Developers

This release addresses a real pain point. Developers often know AI could solve business problems but get stuck on integration complexity.

With database-native agents, teams can:

Access operational data securely without moving it
Use existing business logic and validation
Deploy across cloud, on-premise, and edge environments
Start building immediately without re-architecting systems

The Bigger Picture

Gartner named AI agents one of the fastest-rising technologies in 2025. But adoption has been slow due to technical barriers.

Solutions like RavenDB's AI Agent Creator could accelerate enterprise AI adoption by removing integration complexity. When developers can build agents in days instead of months, more companies will actually deploy AI solutions.

The feature is available now as part of RavenDB 7.1 for teams ready to move beyond scripted chatbots.

Coder Legion - Recent posts tagged developers

From GitHub to Codeberg: Rethinking Repository Management and Personal Website Hosting

# MyZubster Is Becoming a Network of Independent Creators, Developers and AI Contributors

MyZubster: Building an Open-Source Network of Independent Creators, Developers and AI Contributors

From digital comics and urban gardening to decentralized infrastructure, a simpler marketplace and the first experiments with autonomous AI collaboration.

Wasim — Making MyZubster Simpler and More Accessible

Gangkor — Security and Independent Infrastructure

Laurent — Technical Review, Marketplace Logic and Transparency

Nicola / N4K48 — Digital Comics, Zorgax and Independent Creative Projects

Nico — Celofix Giardinaggio and Real-World Skills

Swetha — Knowledge Sharing and Community Participation

Yassen — Zorgax and Contributor Participation

ClearSheet — Remote Digital Services

Other Contributors and Independent Projects

A New Development: An Autonomous AI Agent Wants to Contribute

Software Testing

Digital Comics and Creative Provenance

Could This Be the Beginning of Human–AI Collaboration?

Connecting Different Skills Through a Shared Knowledge Network

Decentralization Means Sharing Responsibility

Our Immediate Goal: Make MyZubster Useful

Join MyZubster

AI Is Not Going to Save You. It Might Not Replace You Either.

Stop treating every AI headline as a career forecast

The job was never just writing code

The awkward part: AI really is useful

Why beginners have a harder problem than senior engineers

What should a beginner actually learn?

Which areas are likely to remain valuable?

Systems that have to keep working

Security and risk

Data engineering and integration

Domains where mistakes are expensive

Architecture and technical leadership

Product and customer-facing engineering

The senior engineer's advantage is not age. It is accumulated context.

How to use AI without turning your brain into a client library

The psychologist question

Companies have a responsibility here, too

A career strategy that does not depend on predicting the future

The part nobody wants to hear

Sources and further reading

A Small Milestone in My Developer Journey

Developers: Stop collecting prototypes. Start finishing projects.

Bleeding-Edge Python on Windows: Overcoming Day-One Setup Hurdles with UV, VS Code, and Git Bash & G

Bleeding-Edge Python on Windows: Overcoming Day-One Setup Hurdles with UV, VS Code, and Git Bash & Gemini AI

1. The Bleeding-Edge Trap: Python 3.15 and Package Compatibility

The Challenge

The Solution

2. Navigating Shell Environments and Virtual Environment Paths

The Challenge

The Solution

3. The GitHub CLI Authentication Override

The Challenge

The Solution

Summary: A Production-Ready Workflow

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

The Origins: From BASIC to Robotics

The Genesis of Zyro Workspace and AutomaticIA

The Engineering Behind the Agent

Trust, Security, and Event-Driven Architecture

The Reality of AI in Production

Just for now, forget coding

How to Prevent Algorithmic Bias When Using AI Tools as MCP Connectors

🚀 Architecture Shift: Why Cryptographic Tokens Beat Path-Based Routing

How Developer Communities Can Grow Organically

Building Portable Reputation from Real Contributions

CoderLegion #OpenSource #DeveloperCommunity #KnowledgeGraph #DigitalIdentity #Reputation #Privacy #Monero #Web3 #MyZubster

Securing the Pipeline: A DevSecOps Guide to Atlassian Rovo Agent Architecture and Zero-Trust MCP Gat

The Problem: Non-Deterministic Prompt Exploits

The Mitigation: In-Memory Edge Proxying via Model Context Protocol

Why This Works at Scale:

Architectural Support for Regulated Life Sciences

Step-by-Step System Testing

Access the Full Engineering Suite

🚀 Open-source developers: what are you building next?

🔓 Explore the open-source projects

👩💻 Built for developers

OpenSource #MCP #Developers #AIEngineering #DevOps

The "Vibe Coder" Reality Check: Validation, Timelines, and Handling Failure

🚀 Building MyZubster: What if AI preserved uncertainty instead of inventing missing data?