I started writing PHP code in 2005 in a small office in Surat, Gujarat, India. Manual deployments on Friday afternoons. No CI/CD. No Git discipline. XML files that I was absolutely convinced were a reasonable way to pass data between systems.

Twenty years later, I’m using AI to generate BRDs, push tickets to JIRA, and review code — and I’m doing it with a level of consistency and speed that my 2005 self would have found genuinely unbelievable.

That gap between then and now is what Kala Atelier is about.

The long version, for anyone who wants it

I’ve been in the IT industry since 2005. That covers more technology cycles than I care to count — the rise and fall of frameworks, the shift from on-premise to cloud, the era of mobile, the era of microservices, and now whatever we’re calling the current moment where AI is rewriting the rules of how software gets built.

I graduated from Sarvajanik College of Engineering and Technology with a degree in Information Technology in 2005. I went on to do a postgraduate diploma in IT from Symbiosis later. But most of what I actually know, I learned by doing.

My career followed a path that I suspect is familiar to a lot of engineers who stayed in the trenches long enough. Junior programmer. Senior developer. Team lead. Software architect. Technical project manager. Each step up the ladder meant more responsibility, more ambiguity, and a gradual realization that the most important problems in software development are rarely technical.

At Kintu Designs, where I worked as a senior PHP developer from 2006 to 2008, I got my first real exposure to what happens when code meets real business requirements. At Neal Infotech, I spent five years learning to lead — first technically, then organizationally. By the time I moved to Paperclip Software in 2013 as a software architect, I had a clear sense of what I valued: systems that last, teams that trust each other, and documentation that actually helps instead of collecting dust.

Since 2016, I’ve been Technical Project Manager and head of operations at Mavin Agency — working with cross-functional teams across time zones, managing everything from client requirement gathering and wireframing to cost estimation, resource planning, and delivery. In that role, I improved project delivery efficiency by 30% through structured process changes. That number sounds good on a resume but what it really means is: I spent a long time figuring out where time goes and eliminating the parts that weren’t earning their keep.

One of the biggest sources of waste, consistently, was documentation. Writing BRDs, FRDs, Confluence pages, JIRA tickets — the overhead involved in keeping these artefacts current, aligned, and actually useful to the team was enormous. We did it because we had to. Nobody enjoyed it.

Where AI comes in

I’m not someone who immediately gets excited about new tools. After two decades in this industry, you develop a healthy scepticism toward anything that promises to change everything. I’ve seen a lot of things promise to change everything.

But when I started seriously experimenting with Claude (Anthropic’s AI assistant) something was different. Not because it was impressive in a demo, but because it was useful in my actual workflow. I could hand it a rough project brief and get back a structured BRD that needed editing, not starting over. I could paste in a functional document and have it extract JIRA tickets that were actually accurate. I could ask it to review a code snippet and it would catch things I would have caught on a second pass, but I rarely had time for a second pass.

The productivity change was real. The quality change was real. The friction that used to surround documentation and planning that friction largely disappeared.

I started Kala Atelier because I wanted to write down exactly how I was doing it. Not in the abstract, not as a collection of tips but as a proper workflow, start to finish, with real prompts and real output. The ten-post series you’ll find on this site documents the entire journey for one project (a fictional client portal called ClientHub) from the initial BRD all the way through code review. Every prompt in that series is one I’ve actually used. Every output is representative of what Claude actually produces.

Why I write

I’ve been blogging in some form since 2017, mostly at blog.tejaspmehta.com — writing about technical management, engineering leadership, backend development, and whatever else I was thinking about at the time. It started as a way to organize my own thinking. It stayed because occasionally someone would tell me a post had helped them.

That’s the only reason anyone should blog. Not for traffic numbers or SEO rankings or to establish thought leadership. Because you have something figured out that someone else is still trying to work through, and writing it down is the most efficient way to help them.

Kala Atelier is a focused version of that. The specific thing I have figured out — or am in the process of figuring out — is how to use AI tools properly in a professional software development context. Not as a replacement for engineering judgment, but as an amplifier of it.

If you’re a developer trying to move faster. A tech lead trying to reduce the overhead on your team. A PM trying to write better requirements documents in less time. A senior engineer trying to do thorough code reviews without sacrificing the afternoon. This is for you.

The credentials, for anyone who needs them

I’ve led development teams at companies ranging from a small Surat-based software house to international operations managing projects across multiple time zones. I’ve done the full stack of technical work — PHP and MySQL development for over a decade, architectural design for scalable web applications, API integrations across major platforms including Google, Facebook, Amazon AWS, Stripe, and others. I’ve worked across open source platforms including WordPress, Drupal, Laravel, and Codeigniter. I’ve managed DevOps exposure on AWS and Azure. I write, I speak to clients, I review code, and I still have opinions about database schema design that I’m happy to share at length if you give me an opening.

Find me elsewhere