As companies move more of their knowledge into AI applications, PDFs, scans, reports, and invoices are becoming key data sources. The real challenge is preserving enough structure and context for AI systems to understand them properly.

Document extraction is becoming key in AI applications

For much of the history of enterprise software, documents typically sat at the end of a process. An application generated a report, invoice, or contract, and the PDF was the finished product. Mancinelli believes AI is changing that relationship:

Documents used to be the output – for example, a PDF you’d print or send out. Now they’re also a structured input that powers AI systems.

More precisely, the challenge for developers is turning documents that are often unstructured or semi-structured into structured information that downstream systems can use.

An LLM can ingest raw text, but simply extracting characters from a file does not always preserve what makes the original document meaningful. A heading has a different role from a paragraph. A value in a table depends on its row and column. A number beside “Total” means something different from the same number appearing somewhere else on the page.

That is why document extraction is becoming an important preprocessing layer in AI applications. The goal is not just to recover text, but to give models cleaner, better-organized context.

Bad PDF parsing can lose information that even a stronger model cannot recover

Anyone who has tried to build a production pipeline around real-world PDFs quickly discovers that documents are far less predictable than API responses or database records. Mancinelli points to three recurring problems:

First are complex layouts: you can have headers, tables, and different formats in the same document, and that creates a huge challenge for systems. Second is poor OCR, which can produce messy output. Third is the loss of context.

This distinction becomes especially important with RAG systems and other LLM-powered applications. If a document is badly parsed before it reaches a model, a more powerful model cannot necessarily recover information that was lost earlier in the pipeline.

For developers, that means data quality becomes an architectural issue rather than simply an AI-model issue.

Document processing depends on the use case

Where document processing happens is another architectural decision that becomes more important as AI moves into regulated and data-sensitive environments.

Mancinelli argues against treating cloud and self-hosted processing as an either-or decision. The right model depends on the application, its infrastructure, and the type of data involved.

For organizations working with particularly sensitive documents, processing files within their own environment can reduce the amount of data that has to move outside their infrastructure. Cloud services, meanwhile, can lower the infrastructure burden and make experimentation easier in some projects.

It’s not one or the other; each solution has its own merit. It depends on the use case.

That may sound obvious, but it becomes a meaningful engineering trade-off once document pipelines start handling contracts, financial records, healthcare documents, or other sensitive enterprise information. Privacy requirements, latency, scalability, and operational complexity all have to be considered alongside extraction accuracy.

A powerful SDK is useless if developers struggle to integrate it

There is also a more familiar developer problem: integration. No matter how sophisticated a document-processing engine is, developers eventually have to put it into a real application, maintain it, and debug it.

For Mancinelli, good documentation is therefore one of the most important characteristics of a production-ready SDK. Practical examples matter as well: developers should be able to see realistic implementations and adapt them instead of building every integration from scratch.

He also points to higher-level APIs as a way of reducing unnecessary implementation complexity:

The point is particularly relevant as AI infrastructure becomes more fragmented. Developers already have to connect models, vector databases, data sources, evaluation systems, observability tools, and application logic. Adding another complicated layer to the stack can quickly increase both development and maintenance costs.

A useful document SDK therefore has to solve two problems at once: the difficult underlying document-processing problem and the developer-experience problem surrounding it.

Data pipelines will become increasingly important

Predicting what software development will look like several years from now is difficult, and Mancinelli avoids picking a single technology that will dominate.

Instead, he expects data pipelines to become increasingly important as companies process larger and more complex collections of information.

One thing is sure: the complexity of the data is going to increase, and the amount of data is going to increase as well. That means data management pipelines will become even more critical.

For developers working with AI, that may be the more practical takeaway.

“The industry tends to focus heavily on what happens inside the model: larger context windows, new reasoning capabilities, faster inference, and increasingly capable agents. But production AI systems also depend on everything that happens before a prompt reaches the model”, Mancinelli said.

If the input is incomplete, badly extracted, or stripped of its structure, even an advanced LLM starts from a disadvantage.

As enterprise AI matures, document processing may become less a peripheral PDF problem and more a core part of the AI data stack, one where developers have to think carefully about structure, privacy, deployment, and, above all, context.

The post AI Is Only as Good as the Document Pipeline Behind It appeared first on ShiftMag.

It sounds like a small decision at first, but as Zohar explains, it can become a costly one later when teams have to deal with scale, reliability, latency, and re-architecture.

We also discussed what changes when you build for real-time AI workloads, and why predictable performance matters far more than averages when your users expect speed every time.

When teams pick a database today, what do they most often get wrong?

Zohar: Most people start by thinking about the databases they already know and have used in previous roles, rather than what they actually need for the specific use case in front of them.

As a result, we often see customers choose something familiar instead of evaluating variables such as latency, speed, scale, reliability, and consistency, and selecting the right solution for their particular problem.

That becomes a major issue when they later have to revisit their decision and re-architect or refactor the solution. It can be time-consuming, costly, and extremely difficult.

As AI apps get more real-time and data-heavy, how should developers and CTOs rethink database architecture?

Zohar: Traditional web applications focused on human interaction and often relied on caches and in-memory data. When we talk about real-time systems and AI, however, we are talking about high-throughput, low-latency workloads that consume large amounts of data and need it immediately.

Because of this, teams sometimes use solutions that no longer fit their needs. They require systems that are reliable, predictable, fast, and scalable, which is something we see all the time. Aerospike was built for exactly that use case: real-time workloads, low latency, predictability, and high throughput.

From my perspective, when CTOs evaluate this kind of solution, they need to think about the future. They should consider what they need today, but also where the product and its infrastructure will need to be at the next stage. That is especially important for AI applications and real-time applications in general.

Many teams are adding vector search, graph databases, and real-time pipelines to their stack. When is that the right choice?

Zohar: When many customers think about AI, their first reaction is: ‘This is what my competitor is doing, so I need to do it too. Sometimes, when we examine the use case, we find it provides no real value. Teams choose to do it simply because everyone else is doing it.

These solutions shine when they provide a competitive advantage, and AI can be integrated into the system in a way that creates long-term value. If you integrate a graph database or vector-search solution simply because someone else is doing it, you are going to have a very difficult time.

From that point onward, everything you do can become a technological hurdle, which is exactly where you do not want to be. You need to focus on what will create the most value. If AI is one of those things, go for it. If it is not, you should probably consider other solutions.

What should engineering teams measure if they really want to understand database performance at scale?

Zohar: When it comes to database performance, predictability is the number-one factor. It should be the industry standard for anything involving low latency and high throughput.

Focusing on the average can put you in a dangerous position. Think of a swimming pool with an average depth of 30 centimeters: you can still drown in the deep end.

You need to think differently about performance. Focus on predictability and metrics such as P99 or even P99.9. Measure them at the application level, the database level, and across the overall user experience, because that is what will make your life easier later.

If you measure only the average, 50 percent of your users will experience latency worse than that figure. If you measure P99, the 99th percentile, only 1 percent of users will experience worse latency.

A long performance tail can be highly problematic for some use cases. Our main focus is providing long-term predictability at the high end, including P99.9 and beyond.

That predictability cannot depend on memory or caches. It needs to hold when reading from disk, NVMe, or other storage, without relying on prior activity, cache hits, or warming data into memory.

What do teams give up or gain when they move fast with managed tools versus building something custom?

Zohar: If you are a startup building a proof of concept or just getting started, using off-the-shelf tools is perfectly fine. Over the long term, however, those tools can impose strict limitations. They can be expensive, slow, or unreliable, and they may change without your consent or even your knowledge. They can help you build quickly and get to market fast.

But once you reach a more established stage, you need to find a different way to handle things.

That may mean building your own solutions, adopting a data platform, and unifying your stack. You look for ways to differentiate your product from competitors and make it more scalable, faster, and more valuable.

It all comes down to value. If your solution provides something no one else can, and that differentiation comes from a different architecture or infrastructure, then it makes sense.

Ultimately, it is not one approach or the other. You need to combine them: use common tools to solve common problems, while applying the right technologies to the uncommon, differentiating parts of each use case.

What database and infrastructure skills should software engineers focus on to stay relevant as AI changes development?

Zohar: I think AI is a major accelerator for developers, SREs, and DevOps teams, dramatically speeding up their work. Even so, people need to stay mindful and continue developing deep expertise in their field when working with AI.

It is like generating an image with AI. You enter a prompt and get a result, but it may not be exactly what you wanted or imagined. To the human eye, the problem is often immediately obvious: the image may show six fingers, strange features, or something else you did not expect. The same applies when you are writing code or analyzing logs.

You need enough expertise to evaluate the response critically. You have to ask why: Why did the AI give me that answer? Where did it come from? What did I learn, and how can I improve my solution?

Instead of using AI only to generate and build things, use it to learn. You can still use it to generate code or solve problems, but you need to be able to read the output, understand it, and guide the AI so that it produces results that make sense for you.

When you build an agentic system, use multiple agents, and pass outputs from one to another, you can sometimes lose that visibility. But if you preserve it over the long term, CTOs, developers, newcomers, and junior engineers can go very far, provided they understand what is actually happening.

From my perspective, AI is where the industry is heading. I use it every day and across many parts of my work, but I always remain critical. I plan before I act. It is not about wasting tokens; it is about creating value through my work.

The post Choose a Database Because It Fits the Workload, Not Because It’s Familiar 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.

In a recent conversation with a few Infobip engineers, we asked whether that promise holds up in practice – and the answer was clear: AI can generate code fast, but it still cannot understand the problem, define the boundaries, or own the consequences.

That part remains the developer’s job.

AI should be a tool for accelerating clearly defined tasks

Better context and clearer specifications make useful, maintainable, and secure output far more likely. As Zvonimir Petković, Staff Engineer, explained:

The quality of the code ultimately depends on the context given to the GenAI agent and the model underneath. The software engineer is still the one writing the specifications, and the better the specification and context, the better the code produced.

To maintain quality, he says, we need to isolate the code into smaller segments and check each one. Effective work with coding agents is less about one large prompt and more about small, controlled iterations.

That may mean changing the architecture, refactoring a component, or requesting a more precise implementation of a single interface. František Lučivjanský, Senior Principal Engineer, described a similar workflow:

I work with AI in smaller chunks. I give it a small part, review the result, and steer the agent: “This is not correct; do it this way.” I may also define the architecture differently – for example, by asking it to refactor one part first. These slow iterations help me maintain the same quality I would achieve manually.

Working in smaller chunks helps developers preserve a mental model of the system and review decisions while the code is still easy to change. AI serves as a tool for accelerating clearly defined tasks.

AI doesn’t create technical debt, people do

Faster code generation naturally raises questions about technical debt. Teams have more code to understand, test, and maintain, but AI did not create technical debt. Debt grows from deadlines, trade-offs, and decisions that prioritize short-term delivery over long-term maintainability.

For Tvrtko Ivasić, Application Security Intern, the answer is not to relax established controls, but to reinforce them:

We should preserve the standards established in the past: the security pillars, the SDLC pipeline, code review, SAST, and the rest of the process. If anything, the bar should be even higher because the code is now generated by AI rather than written by an engineer.

AI-generated code should go through the same SDLC as human-written code: code review, automated tests, SAST, and dependency checks.

František Lučivjanský notes that agents don’t remove the pressures behind technical debt, but they can help manage it more deliberately. They can also spot duplication, suggest refactors, write tests, or explain legacy code, but the value still depends on the engineer reviewing the output.

Vibe coding might evolve into agent engineering

Vibe coding may be enough for a hobby project or proof of concept, but problems begin when the same workflow reaches production without additional controls. Engineers may not need to write or memorize every line, but they still need to understand the architecture, system boundaries, scalability, and failure modes, enough to delegate implementation without delegating responsibility.

Asked whether vibe coding is a sustainable approach to software development or merely a short-term productivity boost, Zvonimir argued that it is likely to evolve:

Vibe coding is not just a short-term boost or a passing trend. “Dark factories” may represent the ultimate direction, with workflows that incorporate vibe coding and require us to look at the code less and less. I think it will evolve into agent engineering, and that is how software will be built in the future.

Companies that adopt this workflow may ship faster without sacrificing quality, spending less time on routine code and more on specifications, architecture, evaluation, and automated controls. The key is to understand where vibe coding creates speed, where it introduces risk, and how AI agents fit into proven software engineering principles – because responsibility for what reaches production remains unchanged.

Special thanks to our engineering colleagues from Infobip, the publisher of ShiftMag!

The post AI Helps Ship Faster, But It Doesn’t Do the Thinking appeared first on ShiftMag.

Put together, they form a consistent picture – not an official ladder, but a very real one that shows how engineers grow, gain influence, and move from writing code to shaping entire systems.

Compensation reveals the real hierarchy

At its core, Adobe uses a P-level system (Professional levels) that maps engineering growth from entry-level roles to company-wide technical leadership.

Adobe doesn’t hand out impressive titles quickly. But behind the modest titles, what’s actually expected of you keeps growing at every level. The ladder looks flat from the outside. From the inside, the gap between levels is real.

If titles are understated, compensation isn’t: across multiple sources, total compensation for software engineers at Adobe ranges from roughly $150K at the entry level to well above $500K at the top of the individual contributor track.

The numbers matter, but so does the curve. Pay grows steadily through early and mid-level roles and then jumps sharply after senior. That’s where Adobe starts paying for influence, not just output.

Senior level: where leverage begins

At P10 and P20, the job is straightforward: ship code, learn the systems, and figure out how Adobe builds and scales things. The goal is to become someone the team can rely on.

By P30, something shifts. Engineers stop executing tasks and start owning problems (taking a feature end-to-end), making real technical calls, and thinking about why something should be built, not just how.

At P40, the job changes for real. Senior engineers design systems, not just features. They cross team boundaries, shape architectural decisions, and lead bigger initiatives. For many, this is a long-term home – the next step demands a fundamentally different kind of growth.

Staff: the real career breakpoint

The jump from Senior (P40) to Staff (P50) is the most important one on the ladder. Same title family, completely different job.

Staff engineers operate as technical leaders without formal authority. They define architecture, guide technical direction, and shape roadmaps across teams. At Staff, you’re measured by what others can build because of you and compensation starts to reflect that.

Beyond Staff, engineering becomes increasingly strategic. Senior Staff engineers (P55) operate across domains, aligning engineering efforts with business goals and driving initiatives that span multiple teams.

Principal engineers (P60) move to a company-wide level of influence. They define technical vision, tackle ambiguous problems, and shape decisions that impact entire product lines. At this level, engineering is less about building and more about direction-setting.

Cross-company level mapping

One useful way to understand Adobe’s ladder is to map it against more transparent systems at companies like Microsoft. While titles and expectations vary slightly, the underlying progression is broadly aligned across Big Tech. Adobe’s levels tend to appear slightly compressed in naming, but comparable in scope, especially from Staff level onward.

The important nuance is that while the mapping is directionally accurate, scope matters more than exact title equivalence. A P50 at Adobe may operate closer to a strong L6 at Google or even edge into L7 territory, depending on the organization, reinforcing the idea that Adobe’s ladder is less about labels and more about impact.

What Adobe actually values?

One pattern runs through the whole ladder: scope drives everything.

• Early levels – Can you execute?
• Mid levels – Can you own?
• Senior – Can you design systems?
• Staff+ – Can you influence outcomes across teams?

That’s the real progression. The ladder feels invisible from the outside because titles aren’t the point — expanding impact is.

Adobe’s ladder stands out for how quietly it operates. No playbook, no loud framing, just one consistent logic: as you grow, you move from writing code to shaping systems to shaping decisions. At the top, one question defines everything: how much of the company changes because of your work?

The post Let’s Take A Look Inside Adobe’s Complete Career Ladder appeared first on ShiftMag.

A field that, just a few years ago, felt stable and full of opportunity now comes with more uncertainty -breaking in is harder, and staying relevant takes constant effort.

We spoke with software engineers who have more than 10 years of experience to hear how they’re navigating these changes.

Thinking back on your career, what’s helped you stay relevant as technologies and trends kept evolving?

Denis: “I was always looking for ways to improve my workflow, so I could spend more time on the interesting, creative parts of the job and less on repetitive, routine tasks. I focused on really understanding problems and possible solutions, which meant building deeper knowledge rather than relying on quick fixes from the internet. I read books, followed blogs, attended both live and online conferences, and learned from experienced people in the industry to get different perspectives and form my own conclusions.

To stay relevant, I focused on real user use cases and the problems behind them, building solutions that create real value.

I also made a point of staying close to the products, users, and solutions over time to see what actually works and what doesn’t, regardless of hype or trends.

Working in teams and collaborating closely helped a lot, as there are always tough questions and healthy discussions that lead to better decisions in the end.”

Marina: “Staying relevant over the years came down to curiosity and hands‑on learning. I regularly read blogs and watch online conferences to keep up with new technologies, but I learned the most by trying things out through small POCs. Experimenting helped me understand problems more deeply and see what really worked.  

Changing teams also played a big role. Working with people who had different backgrounds and experiences exposed me to new ways of thinking and pushed me to grow.  

Finally, working on real products in production environments (especially in larger teams) taught me lessons you simply can’t learn alone. Collaboration, shared ownership, and learning from others helped me continuously adapt as the industry evolved.”

Marko: “For me it’s a combination of continuous learning and a strong focus on fundamentals. I always tried to explore new technologies and different domains, but with an emphasis on really understanding the core principles behind them. That way, the knowledge stays useful even if my career moves in a different direction, and it becomes much easier to build on top of it later.

Just like for the other guys, another important factor was working on real products running in serious production environments, especially in larger teams. Collaboration, communication, and learning from others in a shared codebase bring insights you simply can’t get when working alone. Those experiences helped me grow not only technically, but also in how I approach problems and make decisions in the long run.

I’d describe myself as a cautious early adopter. I enjoy experimenting with new technologies, but I try to understand the fundamentals behind them first, so I can evaluate where they truly make sense and how they contribute real value rather than just following hype.

Finally, self-reflection played a big role. Regularly asking myself what skills I’m missing, how I can contribute more to my team or company, and then actively working towards that has led to many good long-term career decisions.”

Mario: “Talking to other people, watching what others build, and experimenting myself plus exploring open source projects, YouTube videos, and Udemy courses on 2x speed to quickly understand what’s possible with unfamiliar tools. I also follow Hacker News and similar newsletters.

But staying relevant isn’t just about knowing what’s new; it’s about knowing what’s actually worth adopting – and when.

Understanding the high-level concepts and the problem I’m trying to solve is what allows me to pick something that looks like the right tool. After that, trying it out and getting first-hand experience: how it feels under the fingers, and whether it really solves my problem and makes my life easier – is mostly the deciding factor for me, but not the only one. If I’m doing a quick throwaway POC, I can try anything and really find the best tool.

But if I’m working in a team environment where cognitive load is already high, I’m careful not to introduce new technologies every other day just because it’s the new cool shiny thing – even if it actually is the best tool. It’s a tradeoff, and one that needs careful consideration. And sometimes the best isn’t even needed – something that works is good enough.”

In your opinion, is long-term success more about being a deep specialist or a broad generalist? Has your perspective changed over time?

Denis: For long-term success (whatever that is), it’s generally better to develop M-shaped skills. That will take some time, but only with great collaboration and multiple deep expertise areas can you be innovative and versatile, bringing measurable value and not be easily replaceable.

Marina: Earlier in my career, I believed that being a T‑shaped developer was the ideal path and I assumed that trying to learn more than one thing deeply would only lead to superficial knowledge and that focusing on a single specialization was the safest way to grow. Over time, my view changed.

Through real-world experience, I realized it’s possible to build strong, meaningful expertise in multiple areas without losing depth. As systems became more complex, having deeper knowledge across several domains helped me understand the bigger picture better, make better technical decisions, and collaborate more effectively with others.

Today, I believe long‑term success comes from combining depth with breadth – developing strong expertise in more than one area and continuously expanding that range as technology evolves. This flexibility has helped me stay relevant and adapt as roles and technologies have changed.

Mario: I wonder if it’s possible to be M-shaped For a long time, I was a firm believer that T-shaped is the way to go – a broad overview, but with at least one area of genuine deep expertise. And I still think that’s a solid foundation for any engineer.

But over 20+ years, curiosity kept pulling me in different directions: low-level Linux internals, networking, compilers, containers, orchestration, and large-scale distributed systems, working at different layers of the stack. And each time, I went deep enough to solve a real problem. That experience adds up over time.

Understanding the problem and figuring out which layer it needs to be solved in matters more than the technology layer itself, and then it’s about stitching everything together.

Do that long enough, across enough domains, and you naturally grow more spikes. So my view has evolved – I started as a T-shaped believer, and somewhere along the way I became something closer to M-shaped. Not by design, but by following the problems. And if you ask me what I’m an expert at specifically, I’d say solving problems, if that counts as expertise. That’s at least what I currently strive for.

Marko: Today, I’d describe myself as somewhere between T-shaped and M-shaped, maybe N-shaped, still evolving. Early in my career, the T-shaped model made perfect sense, broad knowledge with depth in one area. Over time, as access to knowledge became easier and technologies evolved faster, I realized how valuable it is to develop depth in multiple areas

What ties all of this together is problem-solving. Technologies change, but problems remain. Being able to learn continuously, adapt, and apply concepts from one domain to seemingly unrelated problems becomes incredibly valuable over the long term.

If I were to advise myself 10 years ago or to others today, it would be to stay curious, keep learning, and surround yourself with people you can both learn from and teach. Also, don’t be afraid to broaden your horizons, look for ways to contribute beyond your narrow specialization, pick up complementary skills, and take some risks. Growth often happens outside your comfort zone.

How do you see AI tools impacting long-term developer careers?

Mario: AI impact is real, especially in engineering. We’re much faster at writing code, and I can smart-search unfamiliar codebases and quickly understand how things work (something that used to take a huge effort).

But there’s a price.

The amount of generated code is huge, yet humans still need to review, understand, and own it. AI isn’t the one waking up when something breaks. Creating PRs with AI is easy, being responsible for them is another story.

Our role has shifted to making sure code that looks ok is actually ok – fits the intended architecture, the broader system, the business rules, all the things AI isn’t aware of. The value is the same: understanding whether the code works as intended and preventing it from degrading into a ball of mud nobody can understand or fix at 3am.

What’s changed is how much harder that challenge has become with code being generated at this speed. Young developers are in a tight spot – suddenly expected to skip writing code by hand but still have the same depth of understanding.

And I’m not sure you can skip that part. There’s something about writing code by hand, hitting a wall, debugging it yourself, and feeling the pain of it not working that builds intuition you can’t shortcut. Even if AI is faster and easier. The best advice is to learn the concepts, fundamentals, and engineering best practices that hold regardless of AI.

You need to be able to look at AI-generated code and know whether a for loop is acceptable or a dictionary lookup fits better, that’s software engineering 101. AI can generate the code, but we still need to understand whether it actually fits.

Write as much code by hand as you can. Use AI to review it, ask for other options, and have it challenge your approach, and then actually think through the answers. That way you learn faster while still building real understanding.

And don’t skip debugging AI-generated code step by step; I do it regularly. It’s how you move from just looking at code to actually feeling it. That difference becomes obvious once you try it.

You’ll often be surprised how much you miss just by reading – sometimes it’s “this is not how I thought it worked”, sometimes it’s “I did not expect this at all.” Both are valuable, and both come from actually stepping through it.

Marko: AI tools already have a huge impact on my daily work, from writing code and understanding codebases to reviews, idea generation, debugging, and learning new topics. Overall, I see AI as a strong positive force for developers. It significantly reduces the time spent on repetitive or low-value coding tasks and frees up more space for thinking about architecture, system design, and solving complex problems that truly matter in production.

That said, some things won’t disappear. Understanding the problem and broader context, making architectural trade-offs, communicating well, and taking ownership are still firmly human. When something breaks at 2 a.m., it’s still engineers who make decisions and take responsibility. AI is powerful, but only as effective as the person using it.

For junior developers, don’t skip the fundamentals. Expectations are higher than ever, but strong foundations are key for a sustainable career. The good news is that access to knowledge and AI tools is better than ever. Use AI to accelerate learning, not replace understanding. Give yourself time, build experience, and master the basics—that investment pays off for decades.

Marina: AI tools will significantly change how developers work, but I don’t see them replacing strong engineers. Instead, they will amplify those who understand what they are building. For younger developers, the key is to learn with AI, not just watch AI work.  

It’s important to question AI output, understand why it made certain changes, and how those changes affect the system. Treat AI as a learning partner rather than a shortcut. Blindly accepting generated code can limit growth, while actively analysing and improving it builds real expertise.  

Younger developers should also focus heavily on architecture and system design. When you understand how systems are structured, how components interact, and what trade‑offs exist, AI becomes far more powerful. It’s much easier to ask the right questions (and get useful results) when you already understand the problem space.

Denis: AI tools have made coding skills almost irrelevant. Still, other skills and practices related to quality, such as trunk-based development, TDD, continuous delivery, modularity, cohesion, DDD, etc., are more valuable than before.

AI tools are a powerful amplifier, and they need guidance, so software engineers with those skills will remain relevant and in demand for a long time. Understanding of the (business) problem and the solution shouldn’t be outsourced to the AI. Software engineers still need to understand trade-offs, architecture, and code. 

The post What 4 engineers with 10+ years of experience say about staying relevant in the AI era appeared first on ShiftMag.

Just introducing new tools isn’t enough to make a real impact. What truly matters is how teams work -how they build, collaborate, and keep learning along the way, says Parsons.

He explained why many engineering leaders struggle with AI adoption, and how teams can move beyond just using AI tools to creating workflows where AI truly becomes a collaborator.

AI tools can’t be treated like any other software

Generative AI has sparked huge expectations across engineering teams. Many organizations assume that introducing tools like code assistants or LLM-powered platforms will instantly boost productivity.

But Parsons argues that the real hurdle isn’t the technology itself, it’s how well the organization understands and adapts to using it.

For CTOs and engineering leaders, this often leads to a common mistake: assuming developers can adopt AI tools as quickly and easily as they would a new IDE or software library. In reality, the shift goes much deeper:

It’s a fundamentally different way of working. You can’t simply give engineers an AI tool and expect them to start using it effectively right away. It requires time, experimentation, and a real shift in how teams approach development.

Unlike traditional software, AI is inherently non-deterministic – running the same prompt can yield different results. Teams may see promising outcomes in internal tests and assume it will behave consistently in production, only to find that real users often produce very different results.

People (not frameworks) drive organizational success

Parsons’ perspective on AI adoption is also shaped by his experience scaling engineering teams. During his time at Gower Street, he helped grow a small team into an organization of more than 50 people.

Early in that journey, he focused heavily on building the most efficient team structures and processes. Over time, however, he realized that organizational success depended much more on people than on frameworks:

If your engineering manager and product manager aren’t speaking to each other, introducing a weekly meeting won’t fix the problem.

The key to AI success? Track everything

Parsons starts with a surprisingly simple recommendation for AI adoptation: log everything. Every interaction, every model response, and every step in the AI pipeline should be recorded. These logs form the backbone for understanding how the system really performs in the real world.

From there, teams can go through the logs manually to see which responses are helpful, which are accurate, and which might cause problems.

At the beginning, the responses are often not that good. Sometimes they’re okay, sometimes quite bad, and occasionally surprisingly bad.

This hands-on review helps teams refine prompts, tweak workflows, and boost successful responses. Parsons suggests tracking AI performance just like engineering efficiency, using metrics like positive interactions and fewer errors.

You should explore meta‑prompting

One technique Parsons believes more leaders should explore is meta‑prompting – using AI to improve the prompts themselves.

Rather than trying to write the perfect prompt from the start, Parsons recommends letting the AI lead the conversation, asking one clarifying question at a time. This lets the model gather context gradually and deliver much better results.

Over time, teams can keep improving prompts by asking the AI what extra information it would have needed earlier, refining them step by step.

Parsons sees this iterative approach as part of a bigger shift: AI is evolving from a simple assistant into a collaborator, increasingly guiding problem-solving and asking questions like a coach.

We’ll start giving AI tasks and letting it run for some time without us being involved.

That shift will mean rethinking how teams collaborate with machines. Parsons points out that even the communication tools teams rely on may need to evolve to accommodate AI as an active participant in discussions and workflows.

The post Many Engineering Leaders Are Getting AI Adoption Wrong appeared first on ShiftMag.

From his experience leading AI product teams, Andrew Mende (Senior Product Manager, Machine Learning at Booking.com) explained what it truly takes to ship LLM-based products in production.

Making AI products reliable requires new workflows

For Mende, the buzz around AI is a rare shift, like the rise of smartphones. But what does it mean for product teams?

This moment unlocks new ways of solving customer problems that were previously impossible due to technical constraints.

He was clear: traditional product management approaches often fail with AI-driven products.

LLM-based systems behave differently, demand new workflows, and bring new types of risk.

Unlike deterministic software, LLMs are probabilistic (identical inputs can produce different outputs), making experimentation easy but production readiness challenging, and forcing teams to rethink how they test, evaluate, and monitor features.

One of the biggest traps, Mende explained, is confusing a successful prototype with a scalable solution:

It’s easy to paste a prompt into ChatGPT and see results; much harder to make it reliable across thousands of real customer inputs.

Teams need structured datasets, big tables of real customer examples, to track accuracy, spot regressions, and see if changes actually work. Without them, it’s all guesswork.

Focus on accuracy, cost, and speed

Mende’s practical approach to model selection focuses on accuracy, cost, and latency: start with the most capable model to see if the problem can be solved, then move to smaller or faster models to optimize performance.

This requires testing multiple configurations (context size, prompts, and parameters) since even small changes affect results. Beyond the model, context selection, prompt instructions, and external tools are critical:

For example, when a customer asks about a specific order, the system should fetch real-time data instead of relying on static knowledge. This combination of LLMs and tools turns simple prompts into full systems, but also increases complexity and maintenance costs.

LLMs can transform how users interact – if teams build the right infrastructure

Mende concluded his How to Web lecture by saying LLMs shine by transforming user interaction: for the first time, digital products can understand plain language, turning customer requests directly into actions.

This shift brings digital experiences closer to human conversations and enables new product patterns that were out of reach just a few years ago.

The challenge now, Mende explained, is not whether LLMs work, but whether teams are willing to build the evaluation, monitoring, and infrastructure required to make them truly useful.

The post Forget the Model, It’s Workflows That Make LLM Products Run appeared first on ShiftMag.

Not because developers weren’t already sensing this shift, but because he said it, and because he revealed something many wouldn’t openly admit:

It hurts the ego a bit.

This wasn’t just another AI hot take. A top expert openly admitted that software development has changed in a fundamental way. Karpathy was clear:

This is easily the biggest change to my basic coding workflow in 2 decades of programming and it happened over the course of the few weeks.

Karpathy, in his own words

Karpathy explains how, over the course of just a few weeks coding in Claude, his workflow flipped almost entirely. What was once mostly handwritten code is now largely driven by LLMs, guided through natural language.

I really am mostly programming in English now, a bit sheepishly telling the LLM what code to write… in words. It hurts the ego a bit, but the power to operate over software in large “code actions” is just too net useful.

That sentence carries more weight than it first appears. It openly acknowledges the productivity gains while naming the quiet discomfort many developers feel but rarely articulate. Even for Karpathy, something is unsettling about no longer being the one writing the code line by line.

This shift isn’t about convenience or a slightly better tool. Karpathy describes it as a phase change, not an incremental improvement.

The role of software engineers moves away from writing individual lines of code and toward orchestrating large code actions. LLMs don’t behave like perfect assistants; they act more like eager but sloppy junior developers: fast, capable, and occasionally careless. They don’t ask clarifying questions, they guess. And sometimes they guess wrong.

The result is faster output, but also a different kind of responsibility. Less mechanical, more abstract. Less about syntax, more about judgment.

Community reaction and a bruised identity

The reaction to Karpathy’s post helps explain why it resonated so widely. Some developers see this evolution as liberating, with fewer repetitive tasks, more leverage, and more time spent on meaningful problem-solving. Others see something more troubling: a slow erosion of the craft that shaped their professional identity.

A familiar split emerges: on one side are builders who embrace orchestration, prompting, and verification, on the other are developers who feel that if they’re not writing code, they’re not really programming anymore.

That tension is emotional, not technical. Programming has never been just a job. For many, it’s a source of pride. When that pride is challenged, even by efficiency, it stings.

What makes this moment particularly interesting is that Karpathy hasn’t been blindly optimistic about AI agents. In the past, he’s openly questioned their maturity, arguing that today’s agents are unreliable and far from fully autonomous.

This contrast is important. He’s saying these tools are too useful to ignore, but he’s also clear they’re still messy, fragile, and imperfect. This isn’t hype, it’s real challenges. And challenges are what spark meaningful discussion.

Am I really a developer if I’m not writing code?

This conversation goes beyond the usual AI discourse cycle. If top engineers are moving from writing code to guiding systems, if success is measured by results rather than lines of code, and if pride, not skill, is the main barrier, then something bigger is happening.

We’re not just changing tools, we’re renegotiating what it means to be a developer.

The real question isn’t if this trend will keep going. It’s this: If programming becomes mostly about language, judgment, and style, what happens to being defined by code?

Karpathy’s post doesn’t give answers but shows the tension. Is moving away from manual coding progress or loss? Empowerment or subtle deskilling?

And if top engineers admit it “hurts the ego,” what does that mean for the future of the profession?

By the end of 2025, LLM coding agents reached a level of coherence that triggered a shift in software engineering. Intelligence is now outpacing tools, workflows, and organizational structures. The industry is just starting to catch up, and 2026 is shaping up to be a fast-moving year as development learns to harness this new power.

The post Andrej Karpathy Admits Software Development Has Changed for Good appeared first on ShiftMag.

For centuries, painters thrived because society depended on their ability to capture reality. But when a better tool arrived – the camera – the ground beneath them shifted. The craft didn’t disappear, but the meaning of value changed forever.

“We’re facing something similar,” said Tejas Kumar (Developer Advocate, IBM) at the Shift conference in Kuala Lumpur. Citing tools like Cursor, Lovable, Bolt.new, Vero, and Windsor, he reminded developers that coding agents are already writing software faster (and often more reliably) than humans.

Developers must rely on first-principles reasoning

The data backs this up. Job openings across S&P 500 companies dropped sharply after ChatGPT’s release. Yes, market cycles and the zero-interest-rate hiring bubble played their part, but the trend points to something bigger: the profession is being reshaped, and developers need to understand how to stay relevant in the years ahead.

To navigate this landscape, Kumar argued, developers need to lean on first-principles reasoning. The term gets tossed around often in tech circles, but it’s rarely defined clearly. He offered a straightforward explanation:

First-principles reasoning means starting from what is invariant – the parts that never change – and building your understanding from there.

Invariants are the fundamental laws of reality – things like gravity, light, or the rising and setting of the sun. They remain constant, no matter what tools we create.

Returning to the Renaissance analogy, Kumar explained that both painters and cameras are simply different ways of capturing the same invariant: light. The tools change, but the underlying truth stays the same.

This approach, he argued, helps us understand the deep value of AI.

The goal isn’t to cling to the tools we’ve always used but to identify the underlying invariant that AI supports. In this case, it is reclaiming time and human agency – giving developers the freedom to focus on meaning while delegating repetitive work to machines.

The invariant in AI? It gives us back lost time

The point became unmistakable when Tejas demonstrated a multi-step AI agent in real time. Without typing a single keystroke, he watched as the agent opened Chrome, searched for the event schedule, parsed the results, and added the correct session to his calendar.

While my hands were off, what could I have been doing? I could’ve been at the gym. Out on a run. Playing with children I don’t have yet – but pray for every day. I could have been doing something meaningful. Instead, I’ve outsourced this tedious work to my agent- and in return, I get back life.

AI does not simply automate tasks. It returns lost hours and makes room for creativity, rest, curiosity, and focus. That, he argued, is the true invariant AI addresses.

Breakthroughs don’t need new toys – they need new tricks

As the keynote wrapped, Kumar recounted the telescope’s origins. In 1608, Dutch glassmakers used clear spyglasses horizontally to scan the horizon. A year later, Galileo pointed the same tool upward, unlocking new worlds.

“He literally saw Jupiter. He saw Saturn,” Tejas said. “A tool used differently became the telescope we know today.”

This story illustrates a timeless lesson: transformative breakthroughs often come not from inventing new tools, but from using existing ones in unexpected ways. In today’s era of open-source models, MCP servers, frameworks like LangFlow, and an unprecedented supply of freely accessible AI technologies, Kumar posed a question to developers that was simple, but profound:

How are we using these tools and how might we use them differently to achieve more, or even discover entirely new possibilities?

In the age of AI you need to be CREATIVE

Tejas invited developers to embrace the moment rather than fear it. Never before have engineers had access to such a vast array of powerful open-source tools. LangFlow itself, he reminded the audience, is fully MIT-licensed and easy to self-host, letting anyone build scalable agents through a visual interface.

But his message went beyond tools or licenses. It was a call to creativity, a call to agency – a reminder for developers to lift their gaze, imagine new possibilities, and see where these tools can take us when used in unexpected ways.

The post How Developers Can Leverage AI Today appeared first on ShiftMag.