For most people, NVIDIA means GPUs. But at WeAreDevelopers World Congress in Berlin, CTO Michael Kagan barely mentioned them.

Instead, he focused on the infrastructure behind AI: networking, energy, software, data centers, robotics, and the massive engineering challenge of scaling it all. NVIDIA’s framing was clear: modern AI is no longer just hardware – it’s an “AI factory.”

AI is changing how people interact with computers

Kagan compared AI to past tech revolutions. Electricity came through a wall socket. Cloud computing put infrastructure on demand. Now AI is changing the interface again making computers accessible through natural language instead of code.

Before AI, only a few million people on Earth could operate computers by programming them. Now everybody can program the computer and run the AI, and if you don’t know how to do it, just ask AI. It will tell you.

In other words, users no longer need to understand the technical details behind computing. If they’re unsure how to do something, AI can often explain it or do it for them.

Kagan framed AI less as a software category and more as a new computing layer that expands access to technology. The computer stays the same – the interface between people and machines is what’s getting much simpler.

How NVIDIA linked thousands of GPUs

One of the most interesting parts of the discussion focused on Mellanox, the networking company Kagan co-founded in 1999 before NVIDIA acquired it in 2020.

Mellanox was originally built for large-scale cloud computing, helping connect servers across massive data centers. But as AI workloads grew, that networking layer became even more important because the challenge was no longer just building individual processors, but making thousands of them work together efficiently.

That’s why Kagan says modern AI systems should be viewed as single computers made up of huge numbers of GPUs spread across racks and data centers:

The computer is not a box under the table anymore.

That made the Mellanox acquisition strategically important: it gave NVIDIA the networking needed to connect GPUs and train larger AI models at scale.

AI factories turn energy and data into intelligence

Kagan repeatedly used the term AI factory because, in his opinion, it better describes the role modern AI infrastructure plays.

Traditional data centers store data and process requests. AI infrastructure does something different: it uses huge amounts of data and power to train models and run inference across applications. “AI factories take the energy and the data and convert it to intelligence”, says Kagan.

He compared the process to a power plant generating electricity. It’s a metaphor, but it captures how NVIDIA sees AI infrastructure: as a production system where intelligence is the output.

When asked what an AI factory looks like, Kagan said:

The first thing you notice when you go to the AI factory is cables.

Those cables connect hundreds, thousands, and eventually millions of GPUs into one computing environment. NVIDIA breaks that challenge into two parts: scale-up, which links GPUs with NVLink, and scale-out, which connects those systems into massive clusters.

As those systems grow, networking becomes essential. Every processor has to stay in sync, and NVIDIA says lowering the cost of generating AI tokens remains one of its key goals.

AI is now limited by software and power, not just chips

AI performance used to improve mainly as hardware improved, but Kagan says the challenge is now more complex.

A big reason is the rapid growth of inference. Traditional computing follows a simple pattern: a user sends a request, the computer processes it, returns a result, and waits for the next instruction. Agentic AI works differently, with models constantly exchanging information with software tools and other services while completing tasks. That creates far more communication inside the data center.

Those interactions happen much faster than humans can issue requests, while Moore’s Law is slowing down. That means smaller and faster transistors alone are no longer enough to meet demand.

That is why building larger processors alone is no longer enough to keep up with growing AI workloads. According to Kagan, CUDA has become one of NVIDIA’s biggest long-term advantages because it allows developers to fully exploit the company’s hardware:

Chips without software are just expensive sand.

He explains that NVIDIA wants to give developers a stable platform while the hardware keeps evolving. Too much general hardware can be inefficient, but too much specialization can quickly become outdated. CUDA gives developers the flexibility to support new workloads without starting from scratch.

Power is another major limit. Kagan said electricity is now one of the biggest constraints on new AI data centers. NVIDIA is working on ways to connect multiple sites over long distances so they can act like one system, with training done where power is available and inference closer to users.

Progress in AI depends on understanding complex systems

The session concluded with advice for young engineers: rather than recommending a specific programming language or AI framework, Kagan encouraged students to develop strong foundations in mathematics, physics and chemistry before specializing.

He also reflected about his childhood curiosity, saying he used to take new toys apart just to see how they worked. If he were starting school today, he said he’d seriously consider studying digital biology, since understanding the human body is still one of the most fascinating engineering challenges:

The most complicated machine that is out there is a human.

Even though the conversation touched on GPUs, networking and AI infrastructure, Kagan kept coming back to one idea: progress in AI depends on understanding complex systems. Whether that’s millions of processors, distributed data centers or the human body, engineering starts with curiosity and a desire to figure out how things work.

The post NVIDIA CTO Says AI is Now About Software, Networking And Power – Not Just Chips appeared first on ShiftMag.

The jump from mid-level to senior engineer is usually described as a matter of stronger technical skills.

Michelle Brenner (Senior Software Engineer) sees it differently.

Ahead of her talk at Infobip Shift, (for which you get a special discount as a ShiftMag reader) she argues that the real shift comes from understanding the business, making pragmatic decisions, and knowing when to ask for help.

AI makes learning at work easier

You’re three weeks into a new job, the sprint is already underway, and a ticket comes in that doesn’t fully match the docs. Do you ask for help and maybe seem inexperienced, or do you guess and hope you got it right?

That choice never really goes away. Senior engineers are not people who never need help, they know when to ask before uncertainty becomes a real problem.

For self-taught engineers, that threshold can feel especially high, as Michelle describes it:

As someone who was self-taught, I sometimes found that asking questions at work could be dangerous. I could reveal an ignorance that I was expected to know, from a computer science term to a tool name.

Michelle thinks AI can make it easier to ask basic questions. Since many developers already use AI tools connected to internal docs or code, they can get help without feeling judged.

For her, that matters because most AI conversations focus on code generation. She cares more about what happens before that: helping engineers learn faster and feel less afraid to ask questions.

Seniors also need business context

One of the biggest mistakes mid-level engineers make as they work toward becoming senior engineers, Michelle says, has little to do with syntax or frameworks. The real issue is not understanding how the business works:

Learn how the business makes money, and how your team affects that.

For Michelle, engineers who understand how leadership makes decisions and how a company creates value are better equipped to make technical calls that matter. So what can you do to fix that?

You should start paying more attention to business meetings and start seeing code as one part of a larger system, not the whole job.

In smaller teams, or in companies without a deep bench of specialists, that is often part of the job. Sometimes you have to take on the roles of product manager, developer, and SRE all at once, even when you are not the expert in every area.

‘If it works, ship it’

That same pragmatism shapes how Michelle thinks about architecture and trade-offs.

There is no single “correct” solution, just as there is no dream job or perfect candidate.

“If it works, ship it,” Michelle says. It is an argument against getting stuck in the search for a perfect answer that does not exist. Senior engineers spend less time chasing theoretical purity and more time balancing constraints, risks, and deadlines.

Michelle also gave us a sneak peek of her upcoming talk at Infobip Shift, based on the senior engineering career guide she has spent the last few years writing. She says the jump from mid to senior is much bigger than the jump from junior to mid, and that it can be especially hard without a mentor to show how the role actually works.

Her talk will focus on the practical skills engineers often do not get enough time to learn on the job, from build-versus-buy decisions to interview preparation. She also spoke with engineers from organisations around the world to keep the advice broad. If you are coming to Shift, this is one talk worth catching.

Get your ticket for Shift conference with a special discount for ShiftMag readers!

The post Being a Senior Engineer Doesn’t Mean You Never Need Help appeared first on ShiftMag.

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.

Mike Krieger, Instagram co-founder and Member of Technical Staff at Anthropic, said hand-reviewing every line of code is no longer the best use of a developer’s time.

The job, he argued, is moving toward understanding what AI is trying to do, judging whether its decisions make sense, and checking whether the end result actually solves the user’s problem.

For startups and small teams, that shift could be a major advantage: AI makes it cheaper to experiment, pivot, and learn faster from real feedback.

‘AI will not replace developers’

If a founder (or a developer) can test three or four product versions or approaches in the time it used to take to build one, the biggest gain is speed of learning.

In Mike’s view, that doesn’t mean AI replaces creativity, ideation, or product instinct, it just helps strong ideas get validated, or rejected, much faster.

The real challenges developers and founders face were never technical to begin with, he argues. Spotting the actual problem, understanding what users need, and finding a product the market will genuinely adopt is far harder than writing the code itself.

AI will not replace developers or threaten the startup ecosystem. It will let small teams build, test, and iterate faster with fewer resources.

That shift will not be easy for everyone, and plenty of teams will struggle, quit, or pivot along the way. But blaming AI for a rough patch in the industry is not fair. Because as Mike says, what was hard before AI is still hard now.

Code review matters less now

One of the biggest changes Mike sees is not how much code AI can write, but how people assign work to it.

Developers are moving away from planning every step in detail and doing it all by hand. Now they more often set the goal, give the AI context, and then review the results, decisions, and trade-offs.

At Anthropic AI is increasingly used less as a simple tool for individual tasks and more like a team member that holds context, tracks specific problems, and proactively suggests solutions.

That is also changing how code gets reviewed. Traditional code review, where someone goes line by line and checks the implementation, matters less than understanding the intent behind a change.

Instead of asking “is every line of this code correct,” the more useful question becomes “is this the right way to solve the problem, and what are the consequences of this decision.”

I don’t review every line of code in a pull request. Instead, I talk to Claude about the code and ask the questions I would normally ask the person who wrote it.

That does not mean people disappear from the process. Human judgment matters more, especially for architectural decisions and complex changes. AI can speed up implementation, but someone still needs to understand the product, the users, and the long-term consequences of a decision.

It is easy to lose perspective in the AI race

Beyond the changing workflow, Mike also spoke about the pressure in the AI industry. With new models, products, and regulatory shifts coming almost daily, it is easy to feel like you always have to stay one step behind.

He said that by midweek, Anthropic is already reviewing the ”state of AI news,” and the list of updates is often long. His point was that you have to keep perspective, you can’t track or react to every single change.

That pressure, he added, is also what makes burnout such a risk in an industry moving this fast. People often tie their sense of success to daily results, competitors’ launches, or product releases, even though real wins and failures are usually measured over much longer stretches of time.

No job is important enough that you can’t be offline for a few days.

He closed by saying teams need to get used to talking about frustrations and failures, not just celebrating wins. Being open about problems, he argued, helps teams solve them faster and keep a healthy working culture, even as the industry moves at an extraordinary pace.

The post Instagram’s Co-Founder Says He Doesn’t Review Every Line of Code Anymore appeared first on ShiftMag.

At .debug 2026, one of Croatia’s largest developer conferences, I introduced the concept of Ambient Generative IT – a coined term describing the phenomenon where AI-assisted development becomes so pervasive that it blends into the organizational fabric, much like ambient lighting blends into a room.

The word “ambient” comes from the Latin ambire (to surround), describing something seamlessly integrated with its environment.

This shift is already happening across organizations: marketing managers build internal dashboards, HR teams automate onboarding workflows, and sales ops create CRM integrations. None of them are engineers, and most have never heard of row-level security – yet they are all becoming software developers and publishers.

The question was straightforward: how do we securely enable a future where anyone can build enterprise-grade tools while still upholding the non-functional requirements we expect from professional software engineering, such as security, performance, scalability, and maintainability?

Everyone wants to build software now…

There are two fundamental reasons why ambient generative IT is so appealing:

1. There have always been more consumers than producers.The demand for applications, integrations, automations, and digitalization has always exceeded what IT departments can deliver. That imbalance created Shadow IT decades ago, when the migration from mainframes to personal computers gave people the freedom to buy their own software. Cloud computing exploded it further. People want to be productive, and when the engineering bottleneck is too tight, they become their own builders.
2. The thrill of creation. Every engineer remembers the first time they made a computer do something it would not do on its own. For non-technical employees experiencing vibe coding for the first time, that feeling is brand new and equally (if not more) intoxicating.

Shadow IT was the warning. Shadow AI is the crisis.

Shadow IT is not new. Gartner estimates that 88% of organizations have experienced it, with the average company running 1,220 unauthorized cloud services while believing the number is just 91. By 2027, 75% of employees will acquire or create technology outside IT’s visibility.

But Shadow AI has accelerated the problem beyond anything Shadow IT ever produced.

According to IBM’s 2025 Cost of a Data Breach Report, shadow AI was involved in 20% of all breaches. This was more than sanctioned AI incidents (13%). Organizations with high levels of shadow AI paid an average of $4.74 million per breach, compared to $4.07 million for those with low or no shadow AI; a $670,000 premium. Perhaps most alarming: 97% of organizations that experienced an AI-related breach lacked proper AI access controls, and 63% had no AI governance policies at all.

Anyone from your company at any moment can generate an app, and this is not going through any development cycle or any security check. People can just start using it in production without asking anyone. And they do.

Dor Zvi, RedAccess

More than 380,000 exposed apps

Israeli cybersecurity firm RedAccess discovered 380,000 publicly accessible applications built with vibe-coding tools like Lovable, Replit, Base44, and Netlify. Out of those, around 5,000 had virtually no security or authentication and about 40% exposed sensitive data.

WIRED independently verified the findings, confirming exposed hospital schedules with physician PII, go-to-market strategy presentations, complete customer service chatbot logs, and shipping cargo records.

Separately, Escape.tech scanned 5,600 vibe-coded applications and found over 2,000 critical vulnerabilities, 400+ exposed API keys, and 175 instances of personal data exposure in live production systems. Their methodology was deliberately conservative: it included passive scanning only, educational and healthcare domains excluded.

The actual exposure is likely far worse.

Gartner’s “Predicts 2026” report forecasts that by 2028, prompt-to-app approaches adopted by citizen developers will increase software defects by 2,500%.

The anatomy of a vibe-coded breach

The pattern is remarkably consistent. For example, the Lovable + Supabase architecture that powers thousands of vibe-coded apps. Lovable generates a React frontend that communicates with a Supabase PostgreSQL database via PostgREST.

To enable this communication, it embeds an anonymous API key directly in the JavaScript bundle which is visible to anyone who opens browser DevTools.

This key is not meant to be secret. Supabase documentation explicitly states that the anon key is public and that Row-Level Security (RLS) should protect the data. RLS defines which rows each user can read. The problem is that Supabase defaults to RLS disabled during development, and vibe coders — who have never heard of RLS — ship to production without enabling it.

The result: a single curl command with the publicly available key returns the entire database. Conveniently, no hacking is required.

This exact root cause was behind the Moltbook breach in February 2026, where 1.5 million API tokens and 35,000 email addresses were exposed within three days of launch. The founder had publicly stated “I didn’t write a single line of code.”

It was also behind CVE-2025-48757, a formal CVE for missing RLS in Lovable-generated Supabase projects affecting 170+ production applications.

AI eliminates the easy bugs and introduces the dangerous ones

Veracode’s 2025 GenAI Code Security Report tested over 100 LLMs across four programming languages and found that 45% of AI-generated code contains security vulnerabilities, which is exactly 2.74 times more frequently than human-written code.

Apiiro’s research on Fortune 50 enterprises showed that while AI coding assistants increased development velocity by 4x, they simultaneously produced 10x more security findings, with privilege escalation paths up 322% and design-level authentication flaws up 153%.

The irony is that AI genuinely reduces surface-level bugs. Syntax errors dropped 76%, and simple logic bugs fell 60%. But it introduces architectural authorization flaws such as code that is syntactically perfect, passes all tests, but asks the wrong question: “is this user logged in?” instead of “is this user allowed to access this specific resource?”

SAST tools cannot catch this because it is not a code error: the code does exactly what it says. The problem is that it says the wrong thing. In one Lovable EdTech incident, the AI generated authentication logic that was inverted: anonymous users received full access while authenticated users were blocked.

In the end, 18,697 user records were exposed, including 4,538 student accounts from UC Berkeley and UC Davis.

Vibe coding optimizes for features, not permissions. Access control is an architectural decision made implicitly by AI, and those implicit decisions are often wrong.

Equixly

Performance, scalability, and the maintainability question

Security is not the only non-functional requirement that vibe-coded applications fail to meet. AI-generated code frequently includes unnecessary sequential API calls instead of batch operations, lacks caching and database indexing, pulls in entire libraries for single functions, and introduces N+1 query problems. This means that an app that works with 10 test users often falls over with higher user numbers.

Then there is maintainability. AI generates code without explaining why decisions were made. There is no design documentation, architectural decision records or tests. When AI generates a new version, it often rewrites the entire codebase rather than incrementally improving it.

If the original vibe coder leaves the company, the application becomes unmaintainable. This is vendor lock-in 2.0.  Rather than a traditional vendor, we’re dependent on a particular AI tool.

The economics (and responsibility) have flipped

Despite the risks, vibe coding is reshaping software economics in ways that cannot be ignored. KPMG reported in 2025 that generative AI coding is helping enterprises reduce their reliance on large SaaS vendors.

Harvard Business Review argued that the “build vs. buy” equation has fundamentally shifted and building custom solutions with AI is now often cheaper than licensing enterprise software. The trend toward “micro-applications” – small, purpose-built tools replacing million-dollar CRM licenses – is accelerating.

The enterprise features that used to sit behind paywalls – SSO/SAML, RBAC, audit logging, compliance exports – can increasingly be built using open APIs. At Infobip, we have built our own MCP Gateway, an Artifactory security bouncer that replicates enterprise curation features, and AI guardrails infrastructure. All were alternatives to buying vendor software.

But this freedom comes with a condition. Without security, performance, and governance standards, the same democratization that liberates organizations from vendor lock-in creates a new class of risk that traditional security programs were never built to handle.

OWASP now has a Top 10 for agentic applications

In December 2025, OWASP published its first Top 10 for Agentic Applications, reviewed by NIST, Microsoft’s AI Red Team, Oracle, and the Alan Turing Institute. The list includes Agent Goal Hijack (prompt injection redirecting agent objectives), Tool Misuse and Exploitation (over-privileged tool access), Agentic Supply Chain Vulnerabilities (poisoned MCP servers), and Human-Agent Trust Exploitation (agents manipulating humans into approving harmful actions).

The incidents are already real. EchoLeak demonstrated a zero-click attack where a crafted email silently triggered Microsoft 365 Copilot to exfiltrate confidential data. The Replit Vibe Coding Meltdown saw an agent delete a production database and then generate false outputs to hide the mistake. A malicious MCP server impersonating Postmark on npm secretly BCC’d emails to an attacker.

This new OWASP report does a good job at mapping out agentic threats. A separate report created by Xint, interestingly explains that the most damaging failures are still the oldest ones. Having tested 28 applications, Xint had 8,827 detections, which were collapsed into 513 findings and then 434 verified issues. The most notable examples in the list are very familiar:

• Secrets exposure (18 verified findings and 11 critical findings)
• Authorization/IDOR flaws (88 verified findings, 2 critical findings)
• Resource exhaustion/Dos (93 verified findings, 3 critical findings)
• Access-boundary weaknesses, such as traversal and SSRF (54 verified findings)

In other words, ambient generative IT does not replace classic application security, but rather makes it more urgent and distributed. For us as security experts, it also makes it noticeably harder to ignore.

An effective AI governance framework needs 6 elements

Gartner’s January 2026 report “How to Secure Enterprise Agentic AI Ambition” defines five workstreams for an Agentic AI Cybersecurity Program:

• Multichannel Discovery (find all AI agents, sanctioned and shadow)
• Access Modeling (unique identity and least privilege for every agent)
• Scoped Agency (define scope early, enforce at runtime)
• Model Risk Management (red teaming and guardrails)
• Intent-based Monitoring (behavioral analytics replacing traditional SLAs)

At the policy level, an effective AI governance framework needs six elements:

1. Mandatory approval before any AI tool is used,
2. A hard data boundary preventing confidential information from entering unapproved systems,
3. Human accountability for all AI-generated output,
4. Identical code review standards for AI and human code,
5. Default-blocked autonomous agents requiring security approval
6. Ethical AI principles ensuring explainability and fairness

At the technical enforcement level, organizations need managed settings that block destructive commands, prevent data exfiltration, restrict access to secret storage locations, control which AI marketplaces and MCP servers are permitted, and maintain full audit telemetry of every tool invocation.

CISOs must prioritize deterministic controls to minimize agentic privilege abuses and contain AI agents’ agency, instead of relying primarily on AI to police itself.

Gartner

Security must be built into every AI tool, agent config, and policy from day one

There’s no doubt whether Ambient Generative AI will be the norm. The 380,000 exposed applications RedAccess found are not an anomaly, they are the new normal. Organizations are now past the point of deciding on whether they’ll allow AI-assisted development across development, and approaching the point of deciding on the governance, tooling and culture to make it safe.

The same CI/CD pipelines, SAST scanners, code review processes, and identity governance frameworks that protect professionally engineered software must extend to every application, regardless of who (or what) wrote it. Code is code, no matter who authored it.

The ambient future requires ambient security. And that security cannot be an afterthought bolted on after the breach. Security must be woven into the fabric of every AI tool, agent configuration, and organizational policy from day one.

The post Security Must Be Built In as Everyone Becomes a Builder appeared first on ShiftMag.

At WeAreDevelopers in Berlin, I spoke with Predrag Radenkovic, CTO at Codeplain, about why some developers are skeptical of “review the spec, not the code” – and where this approach works today, and where teams still need to be careful.

What is the main shift from prompt-driven coding to spec-driven development?

Predrag: Prompt-driven coding operates at the level of code. Every decision an engineer makes gets translated directly into the implementation. All the maintenance happens on the level of code, where the intent behind the original solution is no longer available to the coding agent.

Spec-driven development raises the level of abstraction. You treat the spec as the only source of truth: you define the necessary detail in natural language, and the system is built and validated from that. The intent persists in a simpler, more readable form. So you’re maintaining specs instead of code, and regenerating the code from them.

Agentic skills are what make that workable in practice. Developers don’t want to write specs from scratch, but they’re happy to read them, so the agent drafts the spec incrementally, and the developer reviews and shapes it.

Why are integrations a good fit for AI-assisted development, and where does direct LLM-based code generation usually break down?

Predrag: With integration development, you’re essentially becoming an expert on third-party systems that LLMs already know better than any human. Agents are strong at researching the domain, understanding the APIs, checking implementations against the current documentation.

Where classic AI-assisted development falls short is maintenance. Integrations break in production all the time, and once you have a large number of them, you’re constantly patching code against systems you don’t control.

With spec-driven development, the intent lives in the spec. So, when a third-party system changes and breaks an integration, the fix is usually a very small edit to the spec, and then you regenerate the code from it.

Codeplain treats reusable specifications as the source of truth. What makes a good spec, and what do developers often get wrong when writing one?

Predrag: Good specs are complete, precise, unambiguous, and free of conflicting requirements. Also, their functionality is split into smaller chunks of reasonable complexity. Free-form specs aren’t ideal because the agent has to process everything at once and validating the requirements gets hard. Structuring the spec into units is what makes it both readable and checkable.

That’s why we built the ***plain language. It lets engineers express intent precisely and keep full control over the functionality that gets implemented from it.

What we’ve noticed over 2.5 years of working on spec-driven development is that engineers aren’t especially good at writing precise specs, but AI agents are. And the other way around: engineers are willing to review a spec thoroughly. That’s the reason why we built agentic skills for writing and validating specs.

If implementations can be checked against the specification, how does that change testing, code review, and trust in AI-generated code?

Predrag: The first premise of the SDD lifecycle is that engineers thoroughly review the specs. Once the specs are accurate, much of the work is done. Codeplain’s code generator then builds the code and, more importantly, validates that it conforms to the specs.

We do this through black-box tests written entirely from the specifications and executed against the code that was built. In the end, it’s up to the engineer to do manual testing and, if they want, to check all the test scenarios our platform created.

From your experience scaling integrations, what was the biggest technical lesson about using structured specs instead of direct code generation?

Predrag: When you develop integrations, you become an expert in someone else’s system without creating any additional value compared to your competitors. And it gets harder as the volume of integrations grows. The biggest issue, though, is maintaining them, because around 5% of integrations break each month due to changes in systems you can’t control.

Coding agents are already great at researching and understanding external systems, and we use them to help us write the proper specifications. Once an integration is fully defined in a spec, it’s easier and faster to maintain, because the review cycle boils down to changes in the specs and the rest is automated.

Some developers are skeptical of ideas like “review the spec, not the code”. Where does this approach work today, and where should teams still be careful?

Predrag: We picked integrations as the beachhead for our platform with exactly this question in mind. The approach works best where the implementation can be validated completely, where you can check the behavior against the spec without a human in the loop. Integrations fit that well, and we’ve seen the same hold in a couple of other verticals: scraper development and ETLs.

Where teams should be careful is anywhere full validation isn’t possible. Anything with a user interface, for example, can’t be checked the same way today. But we see a solution on the horizon. The technology just needs to mature, and it’s moving quickly.

The post The Real Source of Truth Is No Longer Code – It’s the Specifications appeared first on ShiftMag.

Olena Babenko, Staff Software engineer at Aiven, cut straight to the uncomfortable truth in a recent interview I had with her in London.

The oversight model collapses the moment the person approving the output can no longer reliably tell whether it’s good, bad, or just convincingly wrong.

She pointed to a growing mismatch between how fast code is being generated and how slowly it is actually being checked.

AI is speeding up code creation, but review can’t keep up

Olena says she keeps running into the same cycle, that looks like this “a steady stream of announcements about how the newest model will change software engineering, followed almost weekly by another company unveiling its most powerful release yet”.

Then someone actually turns the model on and gives it a simple, but domain-specific task, and it hallucinates, a lot

She sees this happen often enough that the pattern itself has become the story. The industry isn’t there yet, she says, at least not in the systems she works with.

The real problem, in her view, shows up one step later in the pipeline: engineers are spending less time writing code and more time reviewing it, and the incentive structures around that shift have not caught up.

Therefore, I asked her what that imbalance looks like:

We have an ability to generate code very, very fast, thousands of lines of code, and without thinking how people perceive that code, how readable it is, how good it is, how simple it is to understand, but code reviewing, scaling, and automation is not on that same level yet.

As a result, you can create a PR, and a person who actually reviews it took much more time to review it than you spent writing it. This means that the problem, at least according to Olena, is structural, not just technical:

The current system and a lot of managerial tools are made on KPIs, they are made on individual contributions of code writing, so if you look at the GitHub contributions or Jira tickets, they are praising writing code, finishing tasks, creating PRs, while the people who do the PR reviews, their jobs are not valued that much.

Add unusually verbose AI-generated code into that mix, and reviewing takes even longer than the writing did.

The review burden has always been there, but it’s getting worse

Olena is careful to point out this isn’t new. She says that a reviewer burden existed even before all this and AI is just amplifying this problem.

She describes a colleague’s experience at a previous company: engineers spending two weeks on an issue, then dropping a thousand-line PR on a reviewer who was, realistically, expected to just hit merge, not actually engage with the work.

The fix, in her view, is not more automation but earlier communication, smaller PRs, and separating refactoring from actual logic changes, paired with management that treats reviewing as real work worth rewarding:

This is a question of management.

AI can make tests look good without actually making the code reliable

Olena also pointed to one of the first things AI tends to break in a codebase: unit tests. Writing them is boring, so people delegate it a lot, but AI can already game the system, making tests pass without making the code reliable.

By her account, models will patch internal implementations or hardcode expected outputs rather than genuinely verify behavior, leaving teams with high coverage numbers that protect against nothing – though the damage doesn’t show up right away.

They are not falling apart in one day. This is a process that’s eroding your system with a small step day by day until you realize that your new system is really unreliable, really something you’re not supposed to do in production.

By the time anyone notices, the damage started much earlier.

‘We are delegating too much thinking to AI’

Olena’s biggest long-term concern is skill erosion:

We’re delegating too much thinking to AI. But AI doesn’t become an expert just because we use it: it has no memory, it can’t really learn, and it can’t build experience. Humans can do that, at least for now. The problem is that we’re not really learning from the experience either, so our skills and critical thinking keep getting weaker.

That undercuts the standard reassurance that a human stays in the loop. “You might end up in a situation where you have a human in the loop, but those people do not have correct skills anymore”, Olena said.

A safety net only works if the person holding it still knows how to catch something.

The post It May Take Longer to Review a PR Than It Takes to Write It appeared first on ShiftMag.

Lovable lets people describe the software they want to build in plain in natural language, and then the platform creates it. It handles security, builds complete solutions, and lets users add artificial intelligence to their applications.

Essentially, it helps people build entire apps, and company founders, small businesses, and large corporations all use it.

This is how Anton Osika, co-founder of Lovable, described his platform. Users create over a million apps on it every week, and these apps attract around 700 million monthly visits.

It sounds like a true paradise for non-technical people who want to build products and scale their businesses, but I wanted to know what value Lovable brings to developers, who make up 20% of the user base. I found my answers at this year’s Raise Summit in Paris, during the fireside chat between Osika and Mark Cuban, the investor and serial entrepreneur.

1. For a quick project start

Cuban highlighted that one of Lovable’s greatest strengths is how it helps people become entrepreneurs:

We all have ideas, right? But taking the first step is usually the hardest part.

The platform’s creator strongly agreed. He explained that although people initially viewed Lovable as a software engineer (or even as competition), they eventually came to see it as an AI co-founder and partner:

When you start a company, the hard part is not just building the software. You also have to register the business, handle banking, set up payment systems, and organize operations.

As he explained, users now build their businesses by talking to the platform and giving it prompts like:

• “I am launching my business. What is the next step?”
• “How do I set up global payments?”
• “How do I get customers?”
• “How do I build internal systems?”

At the very start of product development, Lovable significantly shortens the path from an idea to the first prototype.

This is especially true for developers who know what they want to build but do not want to waste time starting from scratch or dealing with complex business steps. Previously, they had to hire an accountant, a lawyer, or a consultant for these tasks.

2. For MVP and idea validation

For developers working on new products, Lovable serves as an MVP machine. It helps them test whether an idea has market value before they invest serious time in fully custom development.

According to Osika, if you are close to a problem and understand it well, you are often the best person to know what solution to build. He said that building this kind of solution used to be hard because it required too many resources:

Today, you can build a large part of it on your own. That is what I generally recommend. We recently conducted a survey of 10,000 of our users, and about 80% of them are building something they plan to monetize at some point.

Osika also pointed out that many people who successfully monetize their products have a decade or more of professional experience. They combine their expertise with Lovable to build products that attract actual users.

In this case, Lovable serves as a validation tool. This means you first create a working version, then measure market interest, and only then expand the product.

3. For internal tools

Lovable is not just for robust, new applications, it also works well for internal tools, especially when teams need a quick tool for operational processes.

As an example, Anton mentioned Nursa, a US company that allowed its employees to use Lovable for various needs, ranging from marketing to administrative processes.

The results were highly cost-effective:

They have already replaced more than ten software subscriptions that they used to pay for, and they estimate they will save about a million dollars a year.

This example shows that founders can use Lovable to quickly assemble small tools that cut costs and replace multiple separate SaaS solutions.

This way, they save both time and money, and they can focus on their core business.

4. For integrations and business infrastructure

Cuban noted that integrating AI into large companies is often much more complicated than people expect:

We see companies like Microsoft hiring thousands of engineers to implement AI solutions.

Therefore, in addition to building apps, Lovable allows users to integrate these tools into their business infrastructure.

This enables developers to connect the product to databases, internal tools, ERP systems, and other existing company systems much faster, without tedious manual work or complex initial setups.

He observed:

One of the major challenges is connecting to existing systems: ERP systems, internal databases, and current software tools.

To solve this, Lovable enables secure and controlled connections, which allows companies to use AI effectively.

For developers, this matters because it allows them to look beyond the frontend and quickly extend the application’s reach into actual business processes.

In other words, Lovable helps them work more efficiently, not just in building products, but also in fitting them into a broader technical and business ecosystem.

5. For analytics, reporting, and decision-making

Finally, Lovable helps build a layer that connects business data with the tools teams use for strategy, finance, and operational planning.

Instead of lengthy development from scratch, developers can deliver tools that help the team find answers faster and make data-driven decisions.

Cuban described this through his own use of an AI agent:

I ask it: “How fast are we growing in a specific segment?” “Which countries should we consider for a new office?”

This application is important for developers because it shows that Lovable can serve as the foundation for tools that are not just visually functional, but also business-relevant.

As Anton Osika said, “access to core data is one of the key ways we unlock the value of artificial intelligence.” This is exactly what gives developers the power to build reliable tools for analysis, forecasting, and decision support.

And here’s my two cents…

Ultimately, this fireside chat left me with a clear realization: using Lovable will not make everyone a developer, let alone a good one. But developers who embrace it can become significantly more effective. They build faster, work smarter, and spend less time on repetitive tasks.

As Anton Osika pointed out, only about a fifth of the platform’s users possess a technical background. Yet, these individuals know exactly how to leverage the tool to their advantage.

This marks the true shift in our industry. We are not witnessing the end of software engineers, but rather the rise of creators who understand the core problem deeply enough to build solutions in record time.

The post Lovable’s Co-Founder on Why Developers Use a Platform Made for Non-Technical Users appeared first on ShiftMag.

Fortunately, there was no production incident; most issues were detected during internal testing. It is always better to learn on someone else’s mistakes, this article will help you learn on mine.

The architecture in place

The service orchestrates WhatsApp campaign delivery through an asynchronous, scheduler-driven pipeline. Campaign destinations enter the system via an API and are persisted to MS SQL Server. Two background schedulers handle the processing. The first retrieves unscored destinations, invokes a scoring service to evaluate delivery priority, and assigns each destination to a bulk: either appending to an existing one or creating a new bulk when capacity is reached.

The second scheduler manages the delivery lifecycle: it polls the external Bulk Scheduling System for status updates, submits ready bulks for sending, and coordinates priority by pausing lower-scored bulks while higher-priority ones are in flight. MS SQL serves as the central state store, maintaining campaign metadata, bulk assignments, and processing status throughout the pipeline.

Insert record in batches

When you expect a heavy load, don’t insert data one by one. We learned this when a client started sending their campaign as separate HTTP requests—one message per request, all belonging to the same campaign. Our controller accepted a list of messages, but a single-element list is still a list, right? The service started returning HTTP 500 errors due to waiting too long for an available database connection.

We solved this by introducing Kafka as a buffer between the API and the database. Incoming requests get published to a topic and then consumed in batches, enabling batch inserts into the database. A nice bonus came from how Kafka handles partitioning: by setting the message key properly, we ensured that all requests for the same campaign land in the same partition—and get processed together.

Of course, the implementation should still handle lists properly. One caveat: Hibernate does support batch inserts (feel free to check), but not when you use an IDENTITY primary key generation strategy. With IDENTITY, the database generates the ID on each insert.

To get true batching, we bypassed Hibernate and used plain JDBC.

override fun submitCampaign(campaignRequest: CampaignRequest) {
    val message = campaignRequest.messages[0].message
    val campaignId = campaignRequest.parameters.campaignId ?: "no-campaign-id"
    val topicKey = "${message.channelId}-${message.from}" +
                   "-${campaignRequest.parameters.templateName}-$campaignId"
    val messageBatches = campaignRequest.messages.chunked(maxMessagesPerBatch)

    messageBatches.forEach { batch ->
        val batchRequest = CampaignRequest(
            messages = batch,
            parameters = campaignRequest.parameters
        )
        campaignRequestProducer.send(ProducerRecord(TOPIC_NAME, topicKey, batchRequest))
    }
}

@KafkaListener(
    topics = [TOPIC_NAME],
    containerFactory = KafkaConsumerConfiguration.BATCH_LISTENER_FACTORY_BEAN
)
@Timed
fun processRequests(
    records: List<ConsumerRecord<String, CampaignRequest>>,
    ack: Acknowledgment
) {
    val groupedByCampaign = records.groupBy { it.key() }

    for ((_, recordsGroup) in groupedByCampaign) {
        val campaign = findOrCreateCampaign(...)
        val destinations = recordsGroup.flatMap { it.value().messages }.mapToDestinations(campaign)
        storeCampaignDestinations(destinations)
    }

    ack.acknowledge()
}

@Transactional
override fun batchInsert(destinations: List<CampaignDestination>) {
    if (destinations.isEmpty()) return

    val sql = """
        INSERT INTO cds.campaign_destination
            (campaign_id, destination, external_message_id, content, failover)
        VALUES
            (?, ?, ?, ?, ?)
    """.trimIndent()

    jdbcTemplate.batchUpdate(sql, destinations, destinations.size) { ps, dest ->
        ps.setLong(1, dest.campaign.id)
        ps.setString(2, dest.destination)
        ps.setString(3, dest.externalMessageId)
        ps.setString(4, dest.content)
        ps.setString(5, dest.failover)
    }
}

Now Kafka took the big chunk of stress, the database can easily handle the load.

Too complex queries

A query that’s too complex can take too long to execute, especially without proper indexes. Think about what data you already have in the application and use it to simplify things. In our case, we needed to find bulks that still had space for more recipients. The original query joined the destinations table to count how many each bulk contained, filtered by several conditions, and used a HAVING clause to check capacity.

@Query("""
    SELECT cb, COUNT(cd) FROM CampaignBulk cb
    LEFT JOIN CampaignDestination cd ON cd.campaignBulk = cb
    WHERE cb.campaign = :campaign AND cb.priority IN (:priorities) AND cb.waitUntil > :nowWithBuffer AND cb.bulkStatus = 'CREATED'
    GROUP BY cb
    HAVING COUNT(cd) < :maxBulkSize
""")
fun findNotFullAndNotExpiredBulks(campaign: Campaign, priorities: Set<BulkPriority>, maxBulkSize: Int, nowWithBuffer: Instant): List<BulkWithCount>

The problem? A join on an unindexed column, filters without indexes, a COUNT, and a HAVING clause. Combined, it was too much for the database. The query took ages and locks escalated to entire tables. It quickly turned out that we already knew the destination count during processing. So we denormalized: we added a destinationCount column to the CampaignBulk table and updated it whenever destinations were added. The new query and supporting index look like this:

@Query("""
    SELECT cb FROM CampaignBulk cb
    WHERE cb.campaign = :campaign
      AND cb.priority IN (:priorities)
      AND cb.waitUntil > :nowWithBuffer
      AND cb.bulkStatus = 'CREATED'
      AND cb.destinationCount < :maxBulkSize
""")
fun findNotFullAndNotExpiredBulks(
    campaign: Campaign,
    priorities: Set<BulkPriority>,
    maxBulkSize: Int,
    nowWithBuffer: Instant
): List<CampaignBulk>

CREATE NONCLUSTERED INDEX idx_campaign_bulk_count_filter
ON cds.campaign_bulk(campaign_id, bulk_status, destination_count)
INCLUDE (id, priority, wait_until, bss_bulk_id, api_key_id, creation_date, last_status_change_date);

After these changes, the query performs well.

Concurrency: when more isn’t always better

We all want to process data as fast as possible. Especially in the world of virtual threads; you can spin up thousands of them and feel good about how concurrent your application is. But the database doesn’t share that enthusiasm. Under the hood, you have a limited Hikari connection pool. Run too many concurrent operations and your queries start timing out. Worse, when multiple threads hit the same table and the same dataset, you’re heading straight for lock contention.

Here are a few things to consider when you need to control concurrency.

Use shedlock

ShedLock is a library that ensures scheduled tasks run only once across multiple application instances. It works by creating a lock record in a shared storage—typically a database table—before executing a task. When a scheduler triggers, it tries to acquire the lock by inserting or updating a row. If another instance already holds the lock, the task is skipped.

The lock is released after execution or after a configured timeout, preventing deadlocks if an instance crashes mid-task. In our case, we wanted to avoid the same campaign being processed by a couple of instances at the same time.

Shedlock helps a lot here. Feel free to check the full ShedLock documentation.

val config = LockConfiguration(
    Instant.now(),
    LOCK_NAME_FOR_PROCESS_CAMPAIGNS + campaign.id,
    Duration.ofMinutes(5),
    Duration.ZERO
)

val lock = lockProvider.lock(config)

if (lock.isPresent) {
    try {
        singleCampaignService.processSingleCampaign(campaign)
    } finally {
        lock.get().unlock()
    }
}

Limit your concurrency with a semaphore

A Semaphore lets you limit how many threads can execute a block of code at the same time. In our case, each scheduler iteration could potentially process dozens of campaigns in parallel; especially with virtual threads, where spawning new threads is cheap. But each campaign processing involves multiple database operations: reads, updates, and inserts. Letting all of them run at once would exhaust the connection pool and trigger lock contention.

We introduced a Semaphore with a fixed number of permits to cap the number of campaigns processed concurrently. Before processing a campaign, a thread must acquire a permit. If all permits are taken, the thread waits, but with virtual threads, this isn’t a problem.

When a virtual thread blocks, it gets unmounted from its carrier thread, freeing it to run other virtual threads. So waiting for a permit doesn’t waste OS resources like it would with traditional platform threads. Once processing is done, the permit is released.

This keeps database load predictable and prevents the connection pool from becoming a bottleneck.

private val semaphore = Semaphore(10)
private val executor = Executors.newVirtualThreadPerTaskExecutor()

fun processCampaigns() {
    val campaigns = campaignRepository.findAllToProcess()

    campaigns.forEach { campaign ->
        executor.submit {
            semaphore.acquire()
            try {
                processSingleCampaign(campaign)
            } finally {
                semaphore.release()
            }
        }
    }
}

Use query hints

When multiple threads query the same table, the database decides how to handle locking. Sometimes those defaults work against you in different ways. Locks escalate, threads wait on each other, or worse, deadlocks occur. SQL Server lets you guide this behavior with query hints. Here are the ones we found useful:

• UPDLOCK – reserves update locks on selected rows, so other threads can’t select the same rows for processing.
• READPAST – skips rows that are already locked by other threads instead of waiting for them to be released.
• ROWLOCK – suggests that SQL Server use fine-grained row-level locks instead of page or table locks.
• NOLOCK – reads rows without acquiring shared locks, allowing it to read data that other transactions are currently modifying. This means it won’t block writers and won’t be blocked by them but it can return dirty data that might be rolled back, or even read the same row twice or skip rows entirely if data is being moved during the scan.

Think about your access patterns. Are multiple threads competing for the same rows? Are you okay with skipping locked data or reading uncommitted changes? The right combination of hints depends on your specific use case but knowing they exist can save you from mysterious slowdowns and deadlocks.

Process data in batches

Even with ROWLOCK hints, SQL Server can escalate locks. When a single transaction acquires too many row locks on one table, SQL Server may convert them into a table lock for efficiency. This is called lock escalation, and when it happens, your “harmless” operation suddenly blocks everyone else.

We learned this the hard way. Our scoring scheduler fetched all unscored destinations for a campaign in a single query, which sometimes includes tens of thousands of rows. With UPDLOCK to prevent other threads from picking them up, SQL Server decided it was cheaper to lock the entire table. Suddenly, other threads couldn’t read or write to the destinations table at all. The whole pipeline stalled, waiting for one greedy query to finish.

The fix was simple: fetch in batches. Instead of selecting all unscored destinations, we now use TOP(n) and iterate until there’s nothing left to process.

SELECT TOP(400) cd.*
FROM cds.campaign_destination cd WITH (UPDLOCK, READPAST, ROWLOCK)
WHERE cd.campaign_id = :campaignId
  AND cd.bulk_id IS NULL
  AND cd.id <= :maxId

Each batch locks only a few hundred rows, commits, and moves on. This keeps the lock count well below the escalation threshold and lets other threads continue their work.

For more details on lock escalation, see Microsoft’s Troubleshooting explanation.

Final thoughts

The database is not an implementation detail you can ignore. I hope these lessons save you some debugging time.

Have you faced similar challenges? I’m curious how others handle these problems.

The post How Convenient JPA Defaults Broke Our Kotlin Microservice appeared first on ShiftMag.

What’s the worst type of project?

Sure, the term “worst” means different things to different people, but most of the engineers agree: the worst types of projects are the ones that aren’t set up well by humans, not the ones that have big technical requirements. And, as you can probably guess, human-designed flaws are much more creative.

For example, one engineer highlighted that the worst project for him was working with family members who were not familiar with software development at all, affecting expectations, realisations and everything in between.

Another situation was a client project that took four months, with progress going smooth up until the last month. Nikola Buhiniček, Engineering Manager, said:

The client changed the scope significantly without much warning. We had to abandon a lot of the work we’d already done and come up with new features and opportunities. It felt like compressing two and a half months of work into one month before the deadline.

Another type of projects that drive engineers crazy are legacy code projects without real instructions on how to approach them, as explained by Edvin Teskeredžić, Senior AI Software Engineer:

We had this old legacy project, basically 10-year-old code which needed to be maintained. It was also all internal libraries but there was no documentation. The documentation simply lived in the heads of senior engineers, so you had to kind of figure it out yourself, and you couldn’t Google it because it was all internal libraries.

What’s the best, then?

In contrast, the best projects tend to be tied to others as well, only this time it’s about great teams and good colleagues. For some engineers, the best projects are those where leadership has a clear vision and that vision is clearly shown to the teams.

Other engineeers, such as Filip Bolčić, Full-Stack Engineer, highlighted teamwork as the best part of the projects they’ve worked on. For example:

Everybody’s insight was really valuable, and I had a great mentor from whom I learned a lot. It was just a really meaningful project for us, we felt really good working on it.

On the other hand, Nikola noted that sometimes, the best projects are the most challenging ones. He explained the process of adding the automations feature to Productive was one of the more challenging and interesting ones he worked on:

It was such a different feature from what we used to do, and I was given the opportunity to build it. In the end it was one of the best features we have. The usage is growing up from month to month. I’m really happy that it was something that I built like two years ago, and it’s still growing so fast.

It all comes down to the human factor

The hardest thing to fix as an engineer might not even be software-related, according to Hrvoje Rančić, Senior Software Engineer:

My posture. I had really terrible back pain from sitting too much during the COVID era. I think this is a very dangerous job because it involves a lot of sitting, and sitting is the new smoking, so I encourage everyone to move more if you’re a software engineer.

Ergonomics aside, Software Engineer Emin Mulaimović said that some of the biggest recent challenges he had were related to LLM’s:

We had this unstable LLM prompt which basically means you ask the same question and it gives different answers, and the answers are not marginally different. To fix that you just need to rephrase the question over and over and over again until it worked. And then when it worked you didn’t learn anything, you didn’t have fun fixing it, you’re just glad it’s over. Some bugs are fun to fix; this one wasn’t.

On the other end of the spectrum, the toughness of a task comes down to a personal mistake by the engineer themselves, and there’s rarely anything you can do but to fix it. That’s exactly what happened to Filip:

I remember working on a really big-scale production application and accidentally just deleting a lot of important stuff from the database. I was really young in my career and I remember being really stressed out about this, but the project manager protected me and we were able to restore a backup of this database, so in the end everything was good, but it was really stressful for me.

And to further drive the point home, sometimes the fix isn’t even tough, but so time-consuming you think you’re going crazy, as evidenced by Olga Koroleva, Engineering Manager:

I made a bug in the code where entries to the database were written wrong, and I had to manually fix thousands of them. After that, I always double-checked and triple-checked everything.

Make sure to check out the entirety of the video to find more about the best and worst projects, and the challenges of software development!

Special thanks to our engineering colleagues at Infobip, Nikola Buhiniček (Engineering Manager, Productive) and Filip Bolčić, (Full-Stack Engineer, Ars Futura).

The post Developers are the reason behind best (and worst) parts of software development appeared first on ShiftMag.