DEV Community: Kelechukwu Amadi-Keke

The Sustainability Question Around AI Models

Kelechukwu Amadi-Keke — Thu, 09 Oct 2025 15:37:29 +0000

There’s something about this AI wave that feels different from past tech cycles. The speed, the hype, the reach — it’s all unprecedented. But as everyone rushes to build, release, and integrate, I keep wondering: is any of this truly sustainable?

When we talk about “sustainability” in tech, the first thing that comes to mind is usually environmental impact — energy use, carbon footprint, resource consumption. But with AI, sustainability goes deeper. It’s not just about how much power these models consume, but about the ecosystem that keeps them alive: compute, capital, and control. How much longer will AI tools be free/affordable?

The Cost of Intelligence

Someone in a discussion I had recently said something that’s really true: “These models are energy-intensive, and the current pricing structure isn’t sustainable.”

That line stuck with me. Because when you look at the sheer scale of what it takes to run systems like GPT, Claude, or Gemini, it’s staggering. These aren’t static models sitting quietly in a data center. Every query, every API call, every chat or image generation spins up thousands of GPUs burning power at an industrial scale.

It’s not just a matter of hardware — it’s the economics behind it. AI companies are in an arms race to make models smarter, faster, and more accessible, but each step up comes with exponential cost. Someone, somewhere, is paying that bill. Right now, it’s venture-backed firms and hyperscalers. But for how long?

The Capitalist Engine Behind “Open” AI

Others in that same conversation pointed to what’s maybe the less visible issue — the capitalist structure of modern tech. The people building the most powerful AI tools also own the platforms that distribute them, the servers that host them, and the companies that profit from their use.

It’s a closed loop — and it’s hard to imagine true openness inside that.

Even the supposedly “open” frontier models depend on infrastructure that’s owned by the same few companies. You can fork the code, train a small version, or deploy a fine-tuned variant — but in the end, you’re still renting your compute from the same giants who built the original models.

It makes you wonder whether this ecosystem is designed for democratization or for deeper dependency.

A Possible Shift: Self-hosted and Smaller

That’s why I find the rise of self-hosted models so interesting.

Developers and organizations are beginning to realize they don’t always need a massive, general-purpose model. For many tasks, a small, domain-specific model is enough — and it can run locally, without cloud APIs or recurring costs.

The tools are improving too. Frameworks like Ollama, vLLM, and Hugging Face’s inference tools are making it surprisingly easy to spin up your own LLM. You can fine-tune, host, and serve it privately.

This shift feels like a quiet rebellion — not against AI itself, but against its centralization. It’s a movement back toward autonomy.

And in that sense, it reminds me of the early days of open-source software — when people built because they could, not because it was profitable.

The Rise of Open and Chinese Models

Another recurring point in these conversations is the growing presence of Chinese models and open alternatives.

It’s not just diversity for diversity’s sake. It’s competition. Models like Yi, Qwen, and DeepSeek are advancing rapidly, and they’re breaking the Western monopoly over AI capability.

That shift could be healthy for the industry. It introduces pressure — on pricing, access, and innovation. It forces transparency and keeps the power balance in check.

In the long run, the end users — the developers, creators, and small startups — benefit from that competition. When there’s more choice, there’s more room for sustainability.

The Quiet Dependency No One’s Talking About

But there’s another kind of sustainability we don’t talk about enough — workflow dependence.

We’re entering a phase where an entire generation of developers is being shaped by AI-assisted tools. Things like Copilot, Replit AI, or N8N make development smoother, faster, and more enjoyable. They reduce friction and lower the barrier to entry.

But they also shift ownership.

When your entire workflow — your automation, your code generation, your pipelines — lives inside a closed ecosystem, you’re not working independently. You’re working inside a subscription model that can change, limit, or lock your access at any time.

Take N8N for example. It’s one of the most exciting no-code automation tools out there, but it’s slowly drifting toward paywall-based limitations. You can self-host it, yes, but the message is clear: freedom is available, but convenience costs money.

That’s the new dependency — not on a single model, but on the infrastructure of convenience.

Power, Cost, and Ownership

When we talk about sustainability in AI, we often focus on energy usage or financial viability. But maybe the real sustainability question is about ownership.

Who owns the models?
Who owns the pipelines?
Who owns the tools we use to create?

Because if the answer to all three is “someone else,” then what we’re building isn’t a sustainable ecosystem. It’s a rental economy disguised as innovation. And if the majority of students, developers and other professionals are hooked on these tools that have suddenly been made expensive, we might be looking at the new “white gold”.

The future we seem to be moving toward is one where access replaces ownership, convenience replaces control, and automation replaces understanding. And maybe that’s fine for some — but it shouldn’t be the only path forward.

Where we go from here

There’s still hope in the small things. The open-source communities building local models. The engineers writing papers outside corporate labs. The creators pushing for smaller, decentralized systems that can thrive independently.

That’s where sustainability might actually live — not in the biggest data centers or the most powerful models, but in the ability to build, host, and maintain tools on our own terms.

AI doesn’t have to be unsustainable. But it does need to evolve beyond this cycle of scale and dependency. Otherwise, we’ll wake up one day surrounded by incredible tools — none of which we actually own or understand.

And that’s not intelligence. That’s just another form of control.

I Failed My First Software Engineering Interview — And Here’s What I Learned

Kelechukwu Amadi-Keke — Sun, 28 Sep 2025 22:09:17 +0000

On Wednesday this week, I had my very first interview for an internship role at a software engineering company. Nerves were high, the stakes felt even higher, and I wasn’t sure what to expect.

I joined the call, introduced myself to the interviewer, and we got started. Things began smoothly… until they didn’t.

The Beginning

The interviewer started with the classic question: “Tell me about yourself.”

I had prepared well for this, so I answered confidently. We quickly moved on to my projects. He focused on my blockchain-based voting system and asked me to explain the architecture, data flow, and the essential parts of the app.

I walked him through the user interface, the smart contract functions, the backend, and how I used the MVT framework to tie it all together. Up to this point, everything felt great.

Mid-Interview

Then came the first curveball: “Why did you make XYZ design choice?”

I froze for a second. I knew that design had a flaw that would hurt performance in large-scale elections, but I hadn’t fixed it due to time constraints. I went into defensive mode, explained the flaw, and then talked about how I could fix it in future iterations. Luckily, that seemed to land well.

But then he followed with: “Your projects are cool, but your stack doesn’t really fit ours. How quickly can you adapt?”

This caught me off guard, but I shared how I had quickly adapted to Solidity when working on the voting system. That seemed to reassure him, and we moved to the final stage.

Interview End

The interviewer asked a few Python questions — my strongest language. I was ready… until he asked about two very basic concepts:

Asynchronous programming
Mutability of data structures

For reasons I still don’t understand, I blanked. I stuttered, gave answers that weren’t entirely wrong, but weren’t textbook definitions either.

I heard the sigh on the other end. In that moment, I knew the truth: I wasn’t getting the job.

Lessons Learned

This interview humbled me. It made me question whether I was truly good enough, whether I really knew my stuff, and whether I even belonged in this space.

But after reflecting, I realized a few things:

One interview isn’t the end. There will be many more, and better opportunities will come.
Interviews are a skill of their own. Preparing for interviews is almost like a full-time job, and fumbling doesn’t mean you’re not a good developer.
Failure is feedback. I now know exactly what to revise, and where to sharpen my knowledge.

Walking away, I didn’t get the offer — but I gained something else: clarity on what to improve, and confidence that the next time will be better.

How I Built a Blockchain Voting System (And What I Learned in 4 Days)

Kelechukwu Amadi-Keke — Sun, 21 Sep 2025 23:58:04 +0000

I was doomscrolling on YouTube sometime around December last year, when I came across a video by Cleo Abram where she explained why the United States did not make use of E-Voting systems to carry out the 2024 General Elections. While I can’t explain everything she said in the video, it got me thinking: “Can All These Issues Be Solved via Decentralization? ”. This motivated the application I built for my final year project.
For my final year project, I built a blockchain-based voting system that uses smart contracts to make elections transparent, tamper-resistant, and verifiable. The idea was simple: every vote is recorded on the blockchain, and no one can change the results once they’re in.

In this guide, I’ll walk you through what building such a system entails from a developer’s perspective — the architecture, the smart contract design, how the frontend interacts with the blockchain, and some of the challenges I faced along the way. I will not be speaking in any programming language specific terms, so as to give everyone an understanding of the system.

Problem Statement & Goals
The system was aimed at addressing two main issues. Simplicity for non-technical voters, and Security/Transparency of cast votes. This meant that the voting interface was made as easy as possible to understand, while votes were stored in the blockchain for security and displayed to users in real time for transparency.

High-Level Architecture
The system was designed with a semi-decentralized architecture in mind. Instead of a completely decentralized system, the registration of voters is done by an electoral commission, and login credentials given to the voters to login.

At its core, the voting system I built has three main parts:

The smart contract: this lives on the blockchain and is responsible for storing candidates, recording votes, and making sure no one can cheat (for example, by voting twice).
The frontend interface: this is what the voter sees: a simple page where they can connect their wallet, view candidates, and cast a vote.
The backend/indexer: this listens to blockchain events and stores them in a database so results can be shown quickly and cleanly, without querying the chain every time.

Here’s how they work together: the frontend lets a voter choose a candidate → their wallet signs the transaction → the smart contract records the vote on-chain → the results can be read either directly from the contract or through the backend, which makes things faster and easier to display.

I deliberately kept most of the logic on-chain so that security and transparency were guaranteed. The trade-off is that everything stored on the blockchain is public, but for the purposes of my project, that was acceptable since the main goal was to prove tamper-resistance and verifiability.

Smart Contract Design
The smart contract, written in Solidity, handled verification of authenticity of votes, vote storage and retrieval via some major functions. The first function was triggered when the backend sent the list of candidates to the contract for storage. This meant that only votes related to these candidates would be allowed. The second function handled vote validation and storage and was triggered when an event (Vote Casting) was triggered. This function retrieved the ID of the voter and the ID of the candidate that was voted for. This is then hashed to ensure it remains secure and is stored on the blockchain. The last function simply sends the number of votes cast for each candidate back to the backend for display on the frontend.

   function vote(uint256 candidateId) public {
        require(!hasVoted[msg.sender], "You have already voted.");
        require(candidates[candidateId].id == candidateId, "Invalid candidate.");

        candidates[candidateId].voteCount += 1;
        hasVoted[msg.sender] = true;

        emit VoteCasted(msg.sender, candidateId);
    }

Furthermore, some constraints were implemented on the contract. Only one vote can be cast per address (User). Casting more than one vote will trigger an error and reject the vote.

Development Workflow
Some of the tools used for development included Remix IDE for writing and deploying Solidity smart contracts to the Ganache Ethereum testnet which was used to simulate the blockchain network.
The frontend was developed using HTML, CSS and JavaScript and retrieved data from the backend via API requests. The backend was developed using the Django framework which allowed for ease of scale in the long term and communicated with the smart contract via web3.py. So it was essentially a middleman between the frontend and the smart contract.

Challenges Faced and Lessons Learned
Building this system was a roller-coaster especially because I had four days to do so and in the course of this, many challenges were faced and many lessons learned. Some of these challenges included the complexity of working with a new language as I hadn’t worked with Solidity prior to this. Although not a major issue, scalability of the system was another issue faced as the speed of the system reduced as more voters were added to the system but given the fact that this was just a prototype, it was negligible.
Gas fees and cost of transactions was not an issue given the fact that this was done on the Ganache testnet, but in a live system, gas optimization will definitely be something to look into.

What do you think? Is a semi-decentralized model the right approach for secure digital voting? Have you built something similar? I'd love to hear your thoughts in the comments!