Odysseus is interesting because it shows how a project with serious ambitions can now be built outside a traditional software company. 

After speaking with Ivan Mihić, a software engineer who spent time testing PewDiePie’s AI project, I ended up thinking that the software itself might not be the most interesting part of this story.

Odysseus may come from a YouTube creator with a massive audience, but the more important question is what it says about software development itself. 

Another AI app – or something more?

When Felix “PewDiePie” Kjellberg unveiled Odysseus, the internet reacted in the way it usually does when a major creator launches a software project. Some treated it as a celebrity side project, others focused on the privacy claims and some compared it with other AI tools such as GPT or Claude. 

For those of you who might be late to the party (same as we are with this text), Odysseus is an open source, self hosted AI workspace designed to run locally. Instead of depending only on cloud services, it combines local models with web search, document analysis, long term memory, and AI agents inside a single browser interface. If you want, you can also add cloud models to it as well.

Under the hood, the application integrates components such as ChromaDB for memory, SearXNG for search, and local model serving, while also letting users decide whether they want everything on their own hardware or connected to external APIs. 

What stood out to Ivan was not just what Odysseus does, but what its existence says about how software gets built nowadays:

The biggest thing isn’t that Odysseus is a good tool, It’s that a project of this size probably wouldn’t exist without AI.

A few years ago, building a system that combined models, search, memory, document pipelines, and agents would usually have required a much larger engineering team. Today, a determined individual or a small group can at least prototype that kind of product and keep iterating on it.

To me as an outsider, this looks like the phase in which we built AI tools mainly for internal use is slowly coming to an end. More and more of these tools are now being prepared for public release, even if they are still far from fully polished.

Ivan also admints that he was was surprised. Not because the tool is perfect, because it as you would expect isn’t but because something that started from a hobbyist, vibe-coding context grew into a project of this scale. For him, Odysseus is less a sign that AI has replaced engineers and more a sign that AI has changed the starting line. And I couldn’t agree more on this one.

Privacy alone won’t protect you 

Much of Odysseus’ appeal comes from privacy. Running AI models locally means sensitive data does not have to leave your machine, which is a real advantage. But Ivan pointed out that privacy and security are not the same thing. 

Odysseus is local-first, but that doesn’t automatically make it secure. 

The platform can access files, execute shell commands, perform web research, and interact with external services, therefore a bad configuration can quickly create security risks. That matters even more if users expose their instance to the public internet. 

Ivan’s point is simple: a tool can be private in design and still be unsafe in practice if people do not understand what they are connecting, exposing, or automating. 

When a tool presents itself through the lens of privacy, security becomes extremely important. Privacy without security doesn’t mean much.

Odysseus is not mature… yet

Architecturally, Ivan sees Odysseus as a large monolithic application coordinating several supporting services rather than a fully mature enterprise platform. 

It’s not the cleanest or most mature architecture I’ve seen. You can clearly tell it evolved through experimentation.

That experimental nature is visible throughout the product. Odysseus tries to combine chat, agents, research, memory, document analysis, and productivity tools into one personal AI workspace, with varying degrees of success.

A few features stood out to Ivan in particular. “Compare” lets users run the same prompt across multiple models at once. “Deep Research” automatically performs multi step web research and returns cited sources. “Cookbook” helps users choose, download, and serve models based on the hardware they actually have. 

Still, for someone who is just entering the world of local AI, Ivan thinks more established tools currently make more sense, just because tools like Open WebUI has had more time to mature.

This is not exactly a beginner-friendly tool

Talking about Odysseus once it’s installed is fine, but getting there as a regular AI user might prove to be a challenging task. From my experience, users need to be wary of the fact that, in order to fully use Odysseus, many setup steps are needed. They also need to know that they might not understand a single thing about what’s happening, which is also a risk in itself.

Odysseus is not an app you can install and run in a minute or two, while other tools do just that. The user experience for a beginner might be overwhelming and, at times, just simply not worth it if you’re in it just to experiment and see what the tool can offer.

Ivan Šimić, the third Ivan in this story, a senior writer at ShiftMag who kept experimenting with the tool to figure it out, added:

Trying to hop on the bandwagon of local LLM’s after reading about Odysseus might not be the greatest idea, since it requires a capable machine, a basic understanding of key aspects of making things happen on a PC or Mac, patience and time. For many interested in trying it, this might prove to be too much “tinkering” for not a lot of results.

Big ideas in software are no longer a big-team privilege

It would be easy to frame Odysseus as another celebrity tech experiment but that would miss the broader point. 

What matters here is that AI assisted development has lowered the cost of building ambitious software. A project that once would have required a sizable engineering team is now something a small group, or even one person, can assemble and refine much faster than before. 

And yes, while a fair portion of the pessimistic internet is claiming this means software engineers are disappearing, I highly doubt it. The job is changing, and the gap between an idea and a working product is smaller than it used to be.

As Ivan nicely put it, it’s like Jack Black’s quest for the magical guitar pick in The Pick of Destiny. In the film, that pick gives its owner superhuman guitar skills. In reality, even the best tool won’t make him or anybody else the world’s best developer, but it can certainly make everyday job a lot easier.

Therefore, the most interesting thing PewDiePie built may not be another AI assistant, but proof that ambitious software is no longer reserved for traditional software companies and big teams. Big Tech, are you scared yet?

The post PewDiePie’s AI Experiment Is What Software Development Looks Like Now appeared first on ShiftMag.

Meet Branded Caller from Infobip.

Unlike regular caller ID that might flash a name (or worse, just a number), Branded Caller puts verified, visual brand info front and center. Think: the company’s logo, a recognizable display name, and even a quick note about why they’re calling. No more mystery calls.

For developers, this isn’t just a nice-to-have feature – it’s a serious upgrade to the voice call experience.

By integrating Branded Caller, you’re helping businesses increase answer rates, build trust, and fight fraud, all while working inside a secure and standardized ecosystem built for interoperability and long-term use.

Why developers should care about branded calling?

With call fraud on the rise in the U.S., Branded Caller has stepped up by using cryptographic security under the STIR/SHAKEN protocol to verify caller numbers and significantly reduce spoofing and robocalls.

As Ryan McQueary (Manager of Voice Engineering, Infobip) explains, STIR/SHAKEN is a set of industry standards that enhance call verification by cryptographically signing voice calls – a critical step for ensuring call authenticity.

Here’s how it works from a technical standpoint:

When a call is placed, the originating service provider sends a verification request to an Authentication Service (AS). This request includes key details like the originating and receiving phone numbers, timestamp, and an important metric called the trust level or Attestation Level.

This trust level indicates how reliable the call is:

• Both the network and caller are trusted.
• The network is trusted, but the caller is not.
• Neither the network nor the caller is trusted.

The Authentication Service then returns an Identity Header, which includes a cryptographic signature and certificate. This data travels along with the call through the phone network. Before the call reaches the recipient, the terminating provider verifies this signature and trust level.

Based on the verification results, the provider can decide to mark the call as “trusted,” block it, label it as “SPAM Likely,” or flag it for further action.

For developers, this process offers a powerful way to build secure, trusted communication apps and services that can help businesses reduce fraud while improving customer trust and engagement.

STIR/SHAKEN – one protocol to rule them all

Early branded calling systems, or “legacy” approaches, explains McQueary, relied on a patchwork of databases, carrier deals, and handset partnerships. They showed logos or caller names but were fragmented, lacked cryptographic security, and varied in accuracy across networks and devices.

Legacy systems didn’t securely embed branding into call signaling, and before STIR/SHAKEN, there was no standard way to transport and validate branding across carriers – making calls vulnerable to tampering.

STIR/SHAKEN changes all that.

It builds a higher level of trust for carriers and users by ensuring the displayed brand identity stays legit and can’t be easily faked.

And because STIR/SHAKEN is based on industry – wide standards, it works seamlessly across carriers, mobile systems, and networks. Regulators, carriers, and standards bodies back it as the universal solution, making cryptographically signed branding more trusted wherever calls go.

How do I wire Branded Caller into my stack?

So, how do you plug Branded Caller into your existing setup, and what’s needed to make it work?

First off, Infobip acts as the Originating Service Provider and signs calls using a Signing Agent from the CTIA ecosystem. They picked SecureG to handle this crypto magic, making sure calls are legit and trusted.

Next, they team up with an Onboarding and Vetting Agent, NumHub, which lets customers securely add their brands to the mix. Think of it as the bouncer making sure only the right brands get in.

Security’s no joke here, Infobip runs a strict KYC (Know Your Customer) check before handing out Virtual Local Numbers. They follow CTIA’s standards to keep everything reliable and above board.

And it’s not just about old-school phone calls (PSTN). Infobip also supports cool OTT channels like Viber Business Calls and WhatsApp Business Calling, showing off verified business names and logos. That way, businesses can reach customers wherever they’re most likely to pick up.

Want to learn more about Branded Caller? We’re here to help!

The post Developers, Make Your Calls REALLY Legit with Branded Calling appeared first on ShiftMag.

Throughout the last couple of years, we’ve seen new frameworks, methods of work, and different ways of approaching problems come to our attention every week. And if you are in a position where you have a new project or have to migrate an existing one to something new, you have almost endless choices of approaches to any part of your tech stack.

Usually, at this point, you expect someone to tell you what you should do. But not me. Together, we will go through some of the things you absolutely shouldn’t do when picking anything new in your tech stack, be it the whole stack or any part of it.

Why do I want to consider anything new?

When moving your current project to the new technology or starting a new one, the easiest thing to do is just keep doing what you’ve always been doing and leave it at that. But is that always the right approach? This might be the perfect time to reconsider potential reasons for a switch. All of them can be valid for yourself or your team, although some might be more obvious than others.

The first one is simply legacy technology. If you have a current technology stack (or a part of it) with some stale elements, it might be a good idea to update it.

On the other side, the term “legacy” means something else for everyone, so what I am mostly thinking about is a framework or library that is deprecated and no longer supported.

When thinking about existing projects, they sometimes behave like a living organism. With constant evolution and growth over time, it is natural that project requirements change, and with that, a need may arise to change things up, replace existing paradigms, and introduce something new.

Something that is not talked about enough is the developer experience. Developers might not be satisfied with the current technology stack, which is enough reason to take the initiative and change the existing processes. Even though it sounds a bit simplistic, sometimes the only reason to change can be the fact that you would like to try something new. In that case, what’s stopping you?

Planning phase

Okay, you have decided that you want to change the technology stack in your project. Some things should be emphasized when planning such a change. For simplicity’s sake, I have decided to reduce the list to 5 important elements.

1. Establish project requirements, size, and scope
2. Understand what needs to be added (or changed)
3. (Re)evaluate the business logic
4. Define the current budget
5. Think about maintenance

Now, most of this advice seems like something that is common sense, and it is, but it is common sense we overlook very often. We usually like to enter a sort of “Yes we can” mode on some things. That is why it’s very important to establish clear scope and boundaries so we can hold the initial project completion to a sensible degree. Secondly, we have to check what needs to be changed. Sometimes, only a part of our stack would need to be changed. But if we have a pre-existing monolith application, it’s harder to find parts that will stay untouched.

If we have some pre-existing business logic, it should ideally be re-evaluated for multiple reasons. First, we have to consider that new technologies can make the process easier and simpler for everyone. Also, some decisions had to be made because the previous stack just couldn’t handle some requirements, which should be taken into account. But what is most important, you have to think about maintenance.

If you build projects that last, maintainability should be the focus for all stakeholders. Focus on creating as many rules as possible that are clear, simple, and above all, that have only one interpretation to avoid future doubts.

What (not) to do

Usually, when talking about solutions and ways to think, there is a lot of advice on what to do and how to behave. But here, we’ll be talking about what not to do, which should provide a different point of view and additional food for thought. We will cover five examples of the mistakes that engineers and engineering teams can make, but there are (as always) many more that could have been covered here.

Seeking complete solutions

Although it sounds a bit counter-intuitive, complete solutions are rarely the perfect fit for you. I like to call them “Jack of all trades and masters of none.” Usually, when searching for solutions like this, they often sound perfect and without fault, but after you scratch under the surface even a little bit, you can get bit by some issues you haven’t noticed when researching. The best way of tackling this is to look for features according to current requirements and future potential. Of course, looking at stacks as your jumping-off point is a very wise option, but you should not treat them or their creator’s ways as a gospel.

Immediately start looking for comparisons

Searching the internet for available options is the natural pathway to gaining information. But can there be too much information? Too many options? When searching for a perfect framework/library, you can get overwhelmed in a matter of seconds. Besides that, too many choices can make you overlook the correct one. To ensure better comparison, work your way so you can narrow down your choices to 2 or 3 that best fit your use cases. That will make it much easier to compare your choices in depth and help nip the decision paralysis in the bud.

Listening to hot takes

• “That framework sucks!”
• “People that do it in X way don’t know what they are doing”
• “Trust me, bro”

Similar phrases can often be thrown in from various celebrities and influences, expressing their intense opinion of technology. It’s a very easy way to gather interest from people, but it is also a way for some people to fall into the trap of blindly trusting others. There can be many reasons why someone can dislike the tech, but they don’t always have to align with what you want to achieve. Every organization and person inside it has their preferences, so it is wise to check the claims from multiple sources to form as objective an opinion as possible. Or, the best-case scenario is to try it out yourself!

“But we’ve always been doing it this way”

The above-mentioned phrase is one of the most dangerous things to fall back on. It is not only a closed-minded way of looking at things but also a way of hindering progress and potential improvement. The first issue is that processes and how things work in one platform might not translate well to another. Secondly, failing to recognize and utilize this opportunity to rethink current processes can lead to issues further down the line and less successful migration. A big thing that should also be mentioned is as products grow, so do their issues and quirks, so you might as well take this time to address them and remove them from the picture.

Focusing only on the benefits

Focusing on the benefits is one of the most common mistakes engineers make in their pursuits of applicable technologies. When you think of it, it is very easy to find examples of positives, and when searching at a glance, they are the things most likely to surface. But, if you do a total 180 on this thinking and start looking at pitfalls and issues, it will give you a better overview of the limits of the system and a clearer image of whether you can be efficient within those limits.

By looking for weak spots, you will not only have a better fit for your project but also be more prepared for issues that may arise in the future.

Wrapping things up

Those and numerous examples show us how it is very easy to make mistakes when choosing a new technology or tech stack. If there is one thing missing from the above-mentioned list that I wanted to add, it is to not be afraid of making mistakes. Burdening yourself and taking things too harshly is never a healthy choice. Instead, focus on doing the best that you can do at the time and if you make mistakes, consider them a learning experience. After all, the advice mentioned throughout the article came from lessons learned from my or other’s mistakes.

The post Picking your (tech) poison wisely appeared first on ShiftMag.

They come and go, change faster than you can imagine, and each new release promises a revolution in how we create layout. If you are starting with web development, this can be overwhelming and off-putting, also it can lead you in the wrong direction. 

Let’s uncover the pros and cons of front-end frameworks dynamism, highlight the potential pitfalls of blindly following the latest trends without a solid foundation, and provide guidance on mastering any front-end framework. 

The Pros and Cons of a variety of choices

One of the biggest drawbacks, and at the same time the advantage, is an overwhelming variety of choices. In the ocean of front-end frameworks, it is challenging to make the correct selection, and a wrong choice can potentially delay project progress. Moreover, the variety of choices can overwhelm you with a constant need to learn new frameworks, potentially leading to burnout as you strive to keep up.  

However, this vast array of choices  allows developers to select a framework that aligns with their project specifications, potentially leading to improved performance, scalability, and more.  

Another positive aspect that emerges from dynamic development is innovation and evolution.  

New versions and updates often bring innovative features and improvements in performance, security, and user experience. Also, innovation often produces productivity boost. It brings features like hot reloading, component-based architecture, and more.  

That can also have a downside in some cases, such as deprecation of older features or APIs, which require developers to adapt and update their codebase to stay compatible with the latest advancements.  

How I prioritized frameworks over fundamentals

When I first ventured into frontend development four and a half years ago, my knowledge of HTML, CSS, and JavaScript was quite limited. Like many beginners, I was eager to jump into building impressive applications. So, as you might have guessed, I went on YouTube and found some videos that show how impressive frameworks are. That is the moment when a crucial mistake was made, I prioritized framework over fundamentals, but I did not realize it at the time. 

In the beginning, the development was quite rapid, even though I had no idea what exactly was happening and how the web or that framework functioned. A few months later, I began researching other frameworks because I was influenced by fellow frontend developers who consistently endorsed them. At that time, I was a self-taught developer with no working experience, and I found myself caught in the never-ending carousel of front-end frameworks.  

I was becoming a jack of all trades but master of none. After a few months, I came to the realization that I did not even grasp the fundamental aspects of web development . I secretly knew it all along but did not want to admit it to myself. After acknowledging this, I went back to learning the basic concepts, and shortly thereafter, I landed my first internship.  

If you understand one framework…

The most significant realization came after two years when a situation at work required me to learn a new framework again, but the learning process was quite straightforward. It was clear that I had gained more experience, but it was not just that. I realized that a deep understanding of JavaScript, HTML, CSS, and browser superpowers was crucial. Experience certainly contributes to even faster learning because you can connect more things. Also, if you understand one framework on top of the mentioned skills, drawing parallels and achieving outstanding results in learning another becomes easy.  

A blessing and a curse

The ever-evolving world of front-end frameworks can be both a blessing and a curse. While they offer exciting innovations and productivity boosts, diving into them without a solid understanding of frontend fundamentals can lead to shallow knowledge. So, before you rush into the latest frontend trend, take the time to build a solid foundation it will pay off in the long run . 

The post New frontend framework, again?! appeared first on ShiftMag.

Developers face a constant battle against complex, fragmented dev environments. Onboarding onto new projects means tedious setup, configuring databases, dependencies, and credentials. Environments drift apart, causing “works on my machine” bugs that impair collaboration. There had to be a better way.

The pain points of developer onboarding

I’ve spent countless hours as a developer across several codebases. While exciting initially, hopping between projects meant going back and forth between tools and configurations. Getting credentials, configuring databases, installing dependencies, and successfully setting up local environments became repetitive and draining.

Onboarding onto a new codebase often took much more time than I would have liked. My productivity took a nosedive in those early days just trying to set up a working dev environment. I dreaded having to switch contexts between projects, even if it was to make a quick fix.

Collaborating with teammates in this fractured ecosystem also proved challenging. We wasted precious time sorting out why the same code behaved differently on each of our machines. I couldn’t stand encountering obscure bugs that only occurred in production or hearing somebody say “It works on my machine.” Our development velocity slowed to a crawl because the environments would rarely be in sync.

Provisioning development environments became a major bottleneck. We relied on tribal knowledge and incomplete READMEs for our workflows, but we knew there had to be a better way.

An ideal dev environment enables developers to start coding within minutes, regardless of project or tech stack. It transitions seamlessly between machines without breaking. Developers can collaborate smoothly, unimpeded by configuration discrepancies.

Streamlining the environment setup would let us focus efforts on every developer’s core mission – creating stellar code.

Vision for the ideal coding environment

To overcome these struggles, we have conceptualized key attributes of an ideal development environment:

1. Instant Onboarding: Developers should be able to start coding within minutes on any project without days of setup. No more digging through confusing documentation or going through dependency hell.
2. Environment Portability: The environment should transition seamlessly across machines without breaking. You should be able to continue working on any device from exactly where you left off.
3. Security Minded: Safe environments for devs by default. Eliminating the need to worry about complex aspects like fine-grained access controls, vulnerability scanning, and secrets management.
4. Cloud-Scale Resources: Built to leverage the elasticity and power of the cloud. But also able to run in hybrid environments.
5. Environment Ownership: Standardized configurations maintain consistency. Developers can customize their environment with personalized dotfiles, tools, and integrations.
6. Vendor Agnostic: Compatible with any source code repository, infrastructure, or tools. Developers should use their preferred stack and be able to switch any part quickly if needed.

This was the dream. But turning this vision into reality would require completely rethinking how development environments are created and managed.

Assembling a team of cloud development veterans

Having outlined the dream of an ideal coding environment, it became clear that achieving such a feat would be no small task.

To achieve this vision, three cloud development environment veterans came together to found Daytona – Ivan Burazin, Vedran Jukic, and Goran Draganic. Their combined expertise equipped them to architect the next generation of standardized dev environments.

Our team has decades of collective experience operating developer tools at a massive scale, serving millions of users. We set out to design a secure and adaptable platform that would become developers’ go-to coding environment – not just for individual projects, but their daily driver.

Starting from scratch to craft the smoothest developer experience

Rather than retrofitting existing solutions, Daytona was envisioned from the ground up based on accumulated wisdom and first-hand lessons from years of hands-on tooling development. Our goal was for Daytona to become developers’ virtual “home” – an environment to code, collaborate, and create regardless of context.

The key innovation of Daytona is its Standardized Development Environments (SDEs). SDEs encapsulate pre-configured tools, services, and dependencies into disposable ready-to-code workspaces. We automate the provisioning and management of standardized configurations, eliminating the dreaded setup previously required when starting a new project. Developers can start coding instantly, using their preferred editors and tools.

Developers retain the flexibility to customize their SDEs with personalized configurations, dotfiles extensions, and tools. However, the environment foundation remains standardized, avoiding the crippling configuration drift that once obstructed team collaboration. With SDEs, developers invest more energy in writing stellar code rather than wrestling configurations.

Optimized for enterprise-grade security

The introduction of GitHub Codespaces has validated our vision for Daytona, but it falls short of meeting the needs of enterprise-scale development. To address this gap, there is a clear demand for a self-managed solution that offers robust security features, advanced access controls with fine-grained role-based permissions, and comprehensive auditing capabilities to meet strict enterprise requirements.

With self-managed environments, users have the flexibility to choose where their environment is deployed, whether it’s on-premises, in a public cloud, or in a hybrid setup. This allows for independent configuration and management without being locked into a specific platform or provider.

Daytona was specifically designed to cater to these enterprise security requirements. We provide users with the confidence to leverage the power and scalability of the cloud while ensuring they maintain the necessary control and protection required by their security teams and regulators.

Adaptable design to meet developers where they are

A key focus while designing Daytona was adaptability. We wanted developers to be able to seamlessly access their coding environment anywhere, anytime, on any device. With our web dashboard and CLI, developers can access their workspaces using their preferred code editor, regardless of their device’s hardware or operating system.

In addition, Daytona seamlessly integrates with all major source code repositories, including GitHub, GitLab, and Bitbucket. This adaptability ensures developers never have to leave their preferred tools or workflows.

The days of “works on my machine” are gone

The feedback from developers has been tremendous, with many expressing how Daytona has positively influenced their productivity. Improvements in onboarding efficiency have been particularly noticeable, allowing developers to devote more time to coding tasks. This has resonated well with clients from various sectors, including banking and defense.

The days of “works on my machine” are over. No more wasting days setting up environments. With Daytona, the developer commute becomes frictionless. Just click and code.

The post The days of “it works on my machine” are gone; meet standardized development environments appeared first on ShiftMag.

Don’t worry; developers are not getting replaced with AI, and there is still a lot of programming to be done by humans. It may only be done faster in some instances.

What’s especially reassuring is that these words come from the co-founder of a dev tool startup that recently launched a GPT Web App Generator. It works almost like magic – you describe the web app you’d like to create in plain English, and in a matter of minutes, a full-stack web app codebase written in React, Node.js, Prisma, and Wasp is generated, available for you to download, run it locally and deploy with a single CLI command. 

But it’s not magic, nor an attempt to make developers obsolete. It’s just an experiment created by the team behind Wasp, an open-source, full-stack framework for React & Node.js. 

Developers do more than just programming

Although Wasp is also in the business of automating and speeding up a lot of the developers’ work, its co-founder Matija Šošić says there is no such tool that can fully replace developers:

First, developers do much more than programming – planning, communication, architecture, etc. Many things have to happen, and decisions have to be made before we can finally fire up our favorite code editor and start typing.

 Another thing is that the code isn’t going away – it still needs to be written, understood, and maintained and serves as a unique specification of how your app works. Also, the libraries and frameworks need to keep progressing – we can’t stay forever on, e.g., React 18, and that’s it.

The challenges of creating a GPT Web App Generator:

 1) The first challenge was to become better at writing prompts. Since GPT is a black box from the usage perspective, it took time to try it out for our use case (building web apps) and learn what is too little and what is too much information. After a few days of experimenting, we figured out the correct approach and started seeing pretty consistent results.

2) Another way to battle GPT’s non-determinism is to provide some fixed boundaries for it to operate within, reducing search space and minimizing the amount of errors. It’s where the simplicity and declarative nature of Wasp framework came in handy. With the basic setup of a new Wasp app, we could ensure the app has the whole, full-stack architecture correctly in place, along with the authentication system.

 3) App generation is divided into three main phases: 

• Generating an implementation plan (from the user’s input)
• Implementing the files that are part of the implementation plan
• Fixing errors

Initially, we would use GPT-4 for all the phases, but then we discovered it was unnecessary. The first step, plan generation, is the most complex, and using GPT-4 for it makes a difference. On the other hand, file implementation and error fixing are straightforward enough to be performed well by GPT-3.5 (GPT-4 still provides better results, but only marginally).

With that approach, we managed to reduce the cost of the generated app to $0.10 – $0.20. For the comparison, some of the other GPT coding agents we tried took up to $10 to generate the same kind of application.

Frameworks and LLM will keep advancing together

Matija and his co-founder (and twin brother) Martin have been building web apps for nearly 15 years before creating Wasp and have gone through pretty much all the major stacks, starting from PHP/Java to jQuery/Backbone/Angular and finally React/Node.

Every time they would start a new major project, there was a new stack to learn to figure out the best practices of that particular stack, and it would just get more complicated each time. 

That motivated us to start experimenting with the idea of Wasp – we wanted a solution that wouldn’t drastically change with every new library/framework. Thus, the config language, which is very “human readable”, pretty much a specification of your app and isn’t dependent on the specific technology.

They wanted to simplify the whole DX, reduce the boilerplate code, and make sure best practices were set and enforced from the start. Also, the key was to make sure their solution was not reinventing the wheel and that it still works with the dev’s favorite technologies, such as React and Node.js. That would be, Matija says, crucial for adoption.

Ever since they’ve set out to build Wasp, Matija and Martin got the same question: 

Why are you bothering to create a new language for web app development? Isn’t Github Copilot soon going to generate all the code for developers?

Matija says they believe Wasp is what’s the future of web development. For humans and machines alike:

Wasp’s declarative nature and higher-level abstractions is what make it easy for LLMs to work with it and produce better, more consistent results. The same goes for humans. 

This is the future of web development that goes hand-in-hand with the LLM-powered development. You can read more about our thesis on how both frameworks and LLMs will keep advancing together and power each other here. 

The post They’ve created a GPT Web App Generator and realized AI is not going to replace developers appeared first on ShiftMag.

API Bakery is a project generator SaaS. More specifically, it generates API services that can be used for web or mobile app backends or exposed to the public. In a way, it’s an API for generating APIs – with a twist. Based on a recipe that describes the project and data on a high level, API Bakery generates the complete ready-to-use project in a way that makes it easy to modify and build upon.

Code generation pros and cons

Generative AI helping programmers be more productive is all the rage now, but using programs to generate new programs is nothing new. As an industry, we’ve been doing that for decades. This is especially true for APIs. In the broadest strokes, an API can be understood as a specification of how to call (interface with) some program or service. And we programmers are lazy: if we have the spec, why not generate code for it?

The problem is two-fold: we can rarely automagically create all the functionality that we need; and auto-generated code is usually an ugly, unmaintainable mess.

The many code-generator tools that exist can’t handle all imaginable cases and situations. Because of this, they focus on covering the most common functionality, or what’s the easiest to automate. For APIs, that’s usually the client SDKs that wrap the HTTP calls and parse the responses. This works, but the resulting code isn’t as nice to use as something crafted by hand. On the server side, the generated code usually consists of empty wrapper methods that need to be filled in by the user to actually provide the working code.

This brings us to the second problem: having to update and maintain that code manually. Often, the generated code doesn’t conform to the coding style, best practices, or patterns of the framework or platform being used. Because it doesn’t have a wider context of the entire application, it can also be sub-optimal or have potential security issues. Nobody likes having to go in and deswamp that.

Trying existing code and API generators

On the other hand, code generators can save you a lot of time. In our web development agency work, we’ve worked on a lot of projects where the API was mostly standard CRUD (Create, Read, Update, Delete) methods, plus a few things like payments and project-specific flows. Writing this almost-boilerplate API seemed like a waste of time and clients’ money, so we started using existing project generators and building an internal tool to automate as much of it as possible.

Most modern web frameworks have one (or a few) project generators. We work with Django (a web framework for Python) a lot, and there are at least a dozen Django project generators, with the most popular being cookiecutter. However, we found that those generators can only provide a barebones skeleton for a new empty project. All those CRUD APIs we still had to write ourselves.

The more we tried to customize the generators to help us generate more code, the more we had to maintain those customizations, in effect creating our own framework on top of Django. This was definitely not the way we wanted to go.

We also tried using Swagger (an open API specification that can be used to generate documentation or client or server code) and found out that writing a complete OpenAPI spec was almost the same amount of work as writing the Django code for it!

How we built API Bakery

What we ended up doing was writing our own code generator from scratch, focusing on two things: making it take a description of a project only to generate what’s needed and making sure the generated code looks and works great, like it was written by an actual person on the team.

This means, for example, that the code passes code-style and quality checks (linters), has unit tests (we aim for 90%+ coverage out of the box), and that when you open any file in the editor, the layout, variable naming, etc. all feels “normal”. On the flip side, we wanted to make sure we didn’t generate any generic code that would do more than asked: we aimed for the simplest, straightforward solution like a human programmer would.

We sorely underestimated how hard it would be! It took us a few rewrites of the generator itself to make it to a point where we’re satisfied with the output and with the complexity of the generator.

Realizing how useful it could be to other developers beyond our agency, we decided to spin it off into a separate standalone software as a service – API Bakery.

How API Bakery works

API Bakery combines project scaffolding (creating a structure for a new empty project), database model generation, CRUD API generation, and tests (and other features, but these are the main areas). Of those, the project scaffolding part is straightforward and doesn’t need to be customized much – it’s the most like other generator tools like cookiecutter. For a new project, we just create a couple dozen files with (mostly) boilerplate code.

The database model generation needs to know the structure of your data. This structure is an input to API Bakery in a form of a JSON recipe. The recipe describes the database models and their relationships. For example, a webshop might have Products that are grouped into Categories. Each Product might have a few Variants (SKUs), and so on. API Bakery users configure this through a web-based UI, and it is passed as a JSON recipe to the project generator. Based on this, the actual code to create and manage the data is created.

The API generation builds on this. API Bakery generates the standard CRUD methods for accessing and managing the data through a REST API. The code for this is generated in such a way that it’s easy to add custom API (like payments or more involved data flows) later. We realize that no generator can generate all the functionality, so we take care to make it easy to expand it with custom code.

Finally, we generate automated tests. This has proven the most tricky part because tests must be tailored to the API for the custom data models. Things like default or required fields, allowed values, and permissions all must be handled here; there are tons of edge cases that we have to handle.

Finally, we have a Docker-based isolated environment in which we run the linters and tests to make sure the generated code does what it’s supposed to do. Automated tests with high coverage make this easier – we just run the tests we generated in the previous steps.

For the user, this all takes a few seconds, and the project is baked and ready!

The AI future?

Will AI replace us all? The jury is still out, but in the meantime, we’ve started exploring how it can make our projects better. For API Bakery, we’re very happy with the code generator and don’t think GPT or other coder AIs are there yet when it comes to creating a full non-trivial project. Where we see the value is in combining AI’s ability to understand imprecise, implicit, and context-dependent human instructions.

Our current integration takes advantage of this – users can describe their project in as much detail as they like in normal human language. We then use GPT4 to turn these instructions into a recipe, which then feeds into our existing code generator. The results have been striking. You can literally type one sentence and get a fully working and tested project for what you describe.

Where AI can be of great use is also in side-coding or co-piloting, i.e., helping the programmer write code faster and better. This is an area that API Bakery doesn’t currently cover – once you have the initial project generated, you’re on your own. Using AI to add custom code to an existing project and to go beyond CRUD API is an exciting proposition and within the realm of feasibility already.

With continuing AI progress, the life of API developers will just get easier!

The post API Bakery: Building APIs that build APIs appeared first on ShiftMag.

The results of the Stack Overflow Developer Survey 2023 are in!

This year, the survey included questions about the usage of AI/ML tools, and 70% of more than 90,000 respondents use or plan to use AI tools in their development process.

More precisely, 44% of them use AI tools in their development process now, and 26% plan to soon. Those learning to code are more likely than professional programmers to operate or use AI tools (82% vs. 70%). When asked about the specific AI tool they use, it turned out that most developers use the two most popular tools: 83% of them use ChatGPT, and 56% use GitHub Copilot.

Developers turn to AI tools to increase productivity (32.81%), speed up learning (25.15%), and become more efficient (24.96%). When asked how AI tools would evolve their workflow over the next year, 77% of developers said AI would change how they write code, and 75% of them feel the same about debugging.

While they use it, developers don’t trust the accuracy of AI tools – of those using or planning to use AI tools, only 3% highly trust the accuracy they provide, and twice as many (6%) highly distrust them.

Developer profile

Regarding developer education, most professionals obtained a bachelor’s degree (47%), while a quarter received a master’s degree (26%). More than half of developers learning to code are between 18 and 24, so it stands to reason that they’re more likely not to have a degree.

The survey shows that learning to code from online resources has increased from 70% to 80% compared to the 2022 survey. Respondents under 18 are the most likely to choose resources (e.g., videos, blogs, forums) to learn online. Respondents aged 25 to 34 were the highest age group to study online courses or certifications (52%) but still participated more, thanks to traditional schools (55%).

When it comes to the types of developers, more precisely about their roles, full-stack developers make up the majority of the respondents at 33.48%, followed by back-end developers at 17.88%, front-end developers are at 6.6%, and those who develop desktop or enterprise applications at 5.08%, and mobile developers at 3,38%.

JavaScript is the most-used language for 11 years in a row

Several technologies moved up this year (Bash/Shell, C, Ruby, Perl, and Erlang), and two moved up two spots (Elixir and Lisp). The big mover, gaining seven places in 2022, was Lua, an embeddable scripting language. The top three technologies for professional developers are the same as last year—JavaScript, HTML/CSS, and SQL. But it’s a different picture for those learning to code. HTML/CSS and JavaScript are almost tied as the most popular languages for people learning to code.

Student developers use Python more than SQL (59% vs. 37%), while professional developers report using SQL more than Python (52% vs. 45%). Compared to experienced programmers, those learning to code are more likely to use Java (37% vs. 31%), C++ (32% vs. 20%), and C (32% vs. 17%).

On the other hand, 47,883 people in the survey answered questions on what technologies are paid the most. Zig took first place with an annual salary of $103,611, Erlang with $99,492, and F# worth $99,311. Interestingly, Ruby came in fourth place with $98.522.

Namely, according to the survey, work in Python is paid 78.331 dollars, and for other popular languages, the statistics look like this:

• C# – 74.963;
• C++ – 74.963;
• SQL – 74.963;
• JavaScript – 74.034;
• Java – 72.701;
• HTML/CSS – 70.148;
• PHP – 58.899.

Developers resist returning to the office

For all respondents this year, we see a slight increase in “Independent contractor, freelancer, or self-employed” and an equal-sized decrease in full-time students (1 percentage point) compared to last year and other employment statuses changing less than that. The costs of investing in oneself have risen with inflation in 2023, but more is needed to sway many from the opportunity to level up their developer skills.

The most popular topic in the IT industry is the work environment. Hybrid is here to stay for larger organizations; over half of the employees in 5,000+ organizations are hybrid. The smaller organizations are most likely to be in-person, with one out of five organizations with fewer than 20 people reporting being in-person. More developers are working in person this year than last (+2%). Return-to-office initiatives aside, coding easily lends itself to fully remote work, and one-third or more of all organization sizes are still fully remote.

On the other hand, the most crucial topic concerns salaries in the IT industry. Almost 47,000 people completed this segment of the survey. Quite expectedly, senior and engineering positions occupy the very top of the list regarding salary.

70% of developers code outside of work

Regarding other popular positions, back-end developers have an average median annual salary of $76,034, while full-stack developers earn $71,140. Mobile developers earn $68,192, while front-end developer positions earn $59,970. Interestingly, most professional programmers also code outside of work and do it as a hobby, even 70% of them.

The Stack Overflow Developer Survey is based on a survey of 89,184 software developers from 185 countries worldwide.

The post Stack Overflow Survey: 70% of developers use AI tools for coding, but 3% highly trust their accuracy appeared first on ShiftMag.

Error tracking and APM (Application Performance Monitoring) tool Sentry was founded as an open-source tool in 2008, a solution to the frustration its founder David Cramer felt because he had had to talk to 10 sys admins to get access to logs he needed to fix if he broke something in production.

Cramer launched Sentry as an open-source product, and there was never much discussion on whether that was the right way to go, not even when Chris Jennings joined Cramer as co-founder.

The idea for Sentry has always been to bring that solution to as many developers as possible, and the open-source route was the only way. Sentry is now used by 4 million developers, has been bootstrapped for a long time, and has raised 217 million dollars in six funding rounds. We’ve talked to Sentry’s CEO, Milin Desai, on the journey from open-source project to unicorn company on and off the Infobip’s Shift Miami conference stage.

Desai describes himself as a “developer who moved to the dark side, which is the business side,” which makes him the perfect person to discuss open-source as a business model and how to turn open-source projects into unicorn companies.

Bring value + be affordable = developers will choose to pay

Sentry founders, he shares, just wanted to get the solution to as many developers as possible. They just started building it in the open and for the community.

Desai: The product had to be open-source. The reasoning was: If we deliver value and do it well, people will want to pay, one way or the other.

We make sure our service is always accessible and affordable, and because it’s so affordable and so easy to use, developers choose to pay us. The other option is to run it yourself, but then you have to set it up, upgrade, and maintain it. Why worry about all that when you can pay just 29 dollars a month not to have to? That’s the equivalent of five Starbucks coffees.

“Just be open-source, and millions of developers will use your product” is easier said than done, especially now when hundreds of open-source tools and products compete for engineers’ attention. How do you get the hearts and minds of developers?

How do you create a community around your product?

We chose not to go for maximum dollars, and we went for maximum adoption.

Milin Desai, CEO, Sentry

There is no easy formula, and it is hard to do.
One thing is crucial, the product has to bring value to engineers. Are you building just another library that’s nice to have but not essential, or is it something critical that significantly moves the needle for them?

There’s no magic trick to getting to developers. If they find your product useful, they will use it and talk to other developers about it, and your product will spread like that.

Also, get their feedback and listen to them, show them you’ve heard it – you won’t be able to fix everything right away, but you can acknowledge it and show the community you’ve listened to them. There is no other magic tool!

The business model of open-source

Sometimes it takes years of building the community and building the right product with that community. Sentry was bootstrapped until raising 1.5 million $ in 2015.

Desai: There is no secret to building a sustainable business with an affordable open-source product and, even if it wouldn’t make you millions in revenue from the start, there is one metric to tell you if you’re on the right track: the number of users.

We’ve always had the philosophy of growing sustainably. It’s a simple business; if you’re spending too much, not making enough revenue, and not growing fast enough – you’re in trouble!

It comes back to if you’re delivering the value in the first place and if you understand the value you’re delivering. You won’t make millions from the start, but you will grow.

We’ve had thousands of customers to sign-up for Sentry daily, so there was no doubt we were delivering value. If you’re not, of course, no one will use it, and no one will pay for it, and you’re in trouble.

Milin Desai, CEO, Sentry

Packaging, not pricing, is crucial

Founders, especially the ones with engineering backgrounds, often think pricing is crucial for building a sustainable company from a tool they’ve made to solve their pain points. Desai disagrees:

Desai: It’s packaging, not pricing! Founders should spend a lot of time figuring out what should be included in what plan, making sure the product’s main value is included in the entry-level plan, and what would drive someone to level up.

If you get the packaging right, you can always change the price. Packaging is super hard to change!

Milin Desai, CEO, Sentry

What if an enterprise customer shows up with a big check and a request to build a few features just for them?

Sentry’s motto is to never build for a few but to build for many. We’ve been in situations like that, and we turned them down because it did not fit what we had in mind for the company and the product.

Milin Desai, CEO, Sentry

We need to talk about funding open source

Desai agrees with Kelsey Hightower’s take that the open-source movement is and has to stay the source of innovation in tech. They also agree that the industry still needs to fully figure out how to turn open-source projects into sustainable businesses.

Desai: There is so much talk about open source, but we need to talk more about how we will fund the open-source. When we solve that, the pace of innovation will accelerate even more.

Many companies still habitually use numerous open-source projects and libraries without a second thought about their sustainability.

There is still a problem in open-source of developers contributing their time and expertise, and nobody’s paying them. Large companies are using many open-source products and not contributing financially, and I would say they’re abusing open-source. When using OS products, you must think about how you will give back.

Many big companies, hyper scalers, use a lot of open-source libraries without ever thinking about whether developers maintaining them are paid or not. We have to hold them accountable for such behavior. They get the most value from the open-source community and rarely give back.

Milin Desai, CEO, Sentry

But Desai thinks we’re on the right track to figuring out the business of open-source:

Desai: Some companies give back through regular donations or by employing engineers who develop open-source projects they share with the community.

At Sentry, we encourage engineers to work on their open-source side projects, and we pay extra to our engineers who contribute to libraries that we use or let engineers decide which project they want us to donate to. The idea of giving back is an easy one for us.

We became what we are because of the open-source community that supported us. Sentry’s CEO will also share more in detail at Shift Zadar on how Sentry has used their product to grow into a software company used at 95,000 organizations and a vibrant community of 4 million developers.

To hear more about Desai’s thoughts, check out the recording of his fireside chat with Ivan Burazin.

The post From open-source to a unicorn with Milin Desai, CEO of Sentry appeared first on ShiftMag.

CSS Wizardry’s Consultant Performance Engineer, Harry Roberts, has been a professional developer for 14 years and says he finds it funny how old trends in technology have become new again. He comments on developers’ tendency to get distracted by new frameworks again and again, and tend to fetishize frameworks. Oh, and he does not love the fact that everything is going JavaScript and into the browser.

As a Consultant Performance Engineer at CSS Wizardry, Harry also helps companies improve website speed and optimize front-end development.

Roberts has worked with some of the most prominent and respected global companies and organizations, including Google, the BBC, the Financial Times, and the United Nations. His meticulous and analytical approach has made him a go-to expert in the field, and he regularly speaks at conferences worldwide to share his knowledge with the technical community.

We’ll also share Harry’s insights, including his perspective on choosing the right tools for you and your team and whether the market needs so many tools. So if you’ve ever wondered whether you need all those developer tools, keep reading – we’ve got you covered.

On working at big companies and impact

Harry: Honestly? Some of the most meaningful work I’ve done has been with much smaller companies where you can affect way more significant change. It’s probably not a very “rock and roll” and exciting answer, but some of the most impactful work happens on smaller teams. Because it’s a small environment, your impact is way more significant.

But working for BBC before the Olympics, was inspiring. It was stressful but exciting, and working with the UN – you know you’re doing something good.

On website speed issues impacting business in the millions of dollars

Harry: It varies dramatically for some companies.

Companies leave hundreds of thousands of dollars on the table yearly because they’re getting site speed wrong.

Harry Roberts, CSS Wizardry

Most companies aren’t aware of how serious it is. The way I try to describe it is – if the roof blows off the top of your house, you notice it immediately, and you fix it immediately.

However, if the insulation in your roof isn’t perfect, someone might tell you you can save 500 euros per year on your heating bill if you put in insulation, but for you, it kinda works well enough for now. So for companies, it’s that kind of thing. Their roof blows off, and they fix it immediately, but it’s harder to notice slowdowns that might happen for 12 months.

So I’ve worked this before, where a simple 300 ms speed up would have made them an extra 8 million pounds a year, and I’ve worked with a client this year where a 500 ms speed up would make them an extra 11,5 million euros a year. These numbers are enormous, but it’s all because of lost sales. It’s not like someone took 11,5 million euros out of a bank.

It’s a simple case of them earning that much extra. It’s not as urgent if you’re missing out. It’s critical if you’re losing money. So many clients don’t panic until they hear those numbers and see how big they can be.

On developer tools making life easier or more complicated

Harry: I don’t think it makes it more complicated, no. Most developers can pick the subset of tools that suits them and their day-to-day work, safely ignoring anything superfluous. The more significant fear is the obsession with frameworks rather than developer tools.

On favorite developer dools

Harry: 100% DevTools, in whatever browsers you’re working and testing in. Beyond that, a good command of whatever text editor you use and any useful plugins. For more peripheral development work (i.e., not actively writing code), solid foundational command line knowledge is constructive: Git, basic Bash/Zsh, etc. As a Performance Engineer, I also have tools like WebPageTest (a wrapper around DevTools anyway) that I couldn’t live without.

On developers being fascinated by every new framework and tool?

Harry: Firstly, don’t be! We fetishize frameworks, and they often get implemented on projects before they’ve stood the test of time elsewhere.

Everything old is new again, and we’ve already seen some of the largest and most prominent frameworks return to the ideas and solutions of yesteryear.

Some frameworks’ most significant initial selling points are now almost universally regarded as anti-patterns.

Harry Roberts, CSS Wizardry

U-turns at the scale are pretty terrifying. Instead, look at the problems you must solve and choose the most straightforward available tool. Focus on the fundamentals, and the rest will follow.

(Harry is not the only one highlighting the focus on the fundamentals, Kelsey Hightower said exactly the same in his interview for ShiftMag!)

On [disappointement that] everything is going into JavaScript

Harry: It used to be that a user visited a URL, their browser requested a page, and the server built the page and sent it back. It was the norm, and it worked very, very well. Folk decided to improve this for many reasons by shifting the workload to make it more like a user visiting a URL, requesting a near-empty page, receiving it from the server, asking for potential megabytes of JavaScript, running the JavaScript, and then building the page in the browser.

I mean, on what planet is that going to be faster?! (Note: not Earth, as we’ve learned.)

Developers made this a lot worse when they forgot that HTML exists and went to extraordinary lengths to rebuild native, accessible, fast browser features in woefully subpar JavaScript.

Harry Roberts, CSS Wizardry

That’s a lot of work (and code) to do a much worse job than we were five to 10 years ago! Thankfully, people have started to notice that this new way it’s better, and more considered solutions are slowly coming to the fore. That is reassuring!

On predicting tech trends

Harry: I’ve been thinking about this a lot. Trends move fast. And my career has always been based on something other than trends. In a way, I’m dull. Certain things are just fundamental to how the web works. So I’ve always bet on soft.

I’ve always gone with the reliable way things work. And I’ve felt like some miserable old man in the last five years.

Harry Roberts, CSS Wizardry

Everything’s really going JavaScript and into the browser, and I’ve always felt uneasy about that. But it turns out that the new trend is going along with the old ways but in a better way. I find it interesting that everything old is new again. And I’ve been a developer professionally for 14 years. I’ve seen a lot of changes and trends. They progressed fast, but they’re sometimes the right thing to do.

So over the next 12 months, we’ll see a bit of a return to, well, not necessarily basics, but more advanced ways of doing the old things. Developers have gotten more insightful and more mature. What I’m going to be focusing on, I have yet to learn! I need to start thinking about where I want to position myself in the next 12 months. But the industry is beginning to mature, so we won’t need to move as fast. Indeed, from a site speed perspective, the industry is moving as fast as ever, and I can’t comment on anything beyond my field.

On Shift conference

Harry Roberts is a long-time supporter of the Infobip Shift conference. A few years ago, he participated as one of the speakers, and is coming back to Zadar this September.

Shift stands out as a rare gem in a world of cookie-cutter tech conferences.

Listening to insightful talks from the brightest minds of today’s tech scene while surrounded by the enchanting history of a town built nearly two millennia ago, you’d be hard-pressed to find a more inspiring blend of past and future.
Oh, and it’s the most fun you’ll have all year!

Harry Roberts, 2019

The post On fetishizing frameworks and everything old becoming new again with CSS Wizardry’s Harry Roberts appeared first on ShiftMag.